From extest-admin@lists.bell-labs.com Tue Jan 1 05:48: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 FAA10717 for ; Tue, 1 Jan 2002 05:48:56 -0500 (EST) 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 g01Amwo14416 for ; Tue, 1 Jan 2002 05:48:58 -0500 Date: Tue, 1 Jan 2002 05:48:58 -0500 Message-Id: <200201011048.g01Amwo14416@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 Tue Jan 1 08:56:32 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 IAA12595 for ; Tue, 1 Jan 2002 08:56:32 -0500 (EST) 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 g01Dt3o15294; Tue, 1 Jan 2002 08:55:04 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g01Dsro15279 for ; Tue, 1 Jan 2002 08:54:53 -0500 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 IAA29333; Tue, 1 Jan 2002 08:54:52 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g01DsqJ1011080; Tue, 1 Jan 2002 08:54:52 -0500 (EST) Message-ID: <3C31BFAC.378BD110@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com, iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC 2806 revision (tel url) 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, 01 Jan 2002 08:54:52 -0500 Content-Transfer-Encoding: 7bit Mike, Jon: thanks for your helpful comments. In rewriting the spec, I also found this dual use somewhat confusing. I'm all for shorter specs that we can actually get implementation reports for, so if I get the gist of your proposal: - Just a "tel" URL in this draft; no 'fax:' or 'modem:' - No post-dial strings or 'waiting-for-dial-tone' characters (p, w). - No carrier identification. For the record (and to conserve the text in case it needs to reappear), the new I-D will appear as is, but I will then push out a streamlined version unless somebody makes a convincing argument within the next week that the features above are vital and that they have implemented them or are planning to. (As usual for interop reports, I will be glad to treat such information as confidential; there is no need to make your intents and identity a matter of public record.) Note that special-purpose, private parameters are permissible. We should probably get IANA involved soon. I'd rather not delay the 2806bis draft in the desperate attempt to demonstrate interoperability of special features. Mpierce1@aol.com wrote: > > To all, > > I believe that mention of this RFC in Minneapolis in the March 2001 meeting > indicated that there was a general feeling that there were significant > problems with the current text and a rewrite was required. Based on this, I > will make some rather substantial comments on the current text, with the > understanding that they propose some significant changes to the concept and > details described. > > The text of RFC 2806 seems to confuse the controls that might be needed > between a controller and the device doing outgoing dialing (e.g., MGC and MG) > with what is required in the url to designate the destination (location). For > example, it takes the AT modem commands for pauses and waits for dial tone > and includes them with the url. While there may be cases in which one > specific network element (e.g., a MG) needs to apply these techniques in > order to send digits (DTMF or dial pulse) to another element (e.g., a circuit > switched PBX), the originator of the call knows nothing about this, so this > information should not be a part of the url. In fact, due to alternate > routing, two calls with the same url might be treated differently because > they are routed differently. This type of dialing in which the originator > needed to know the routing in order to formulate the digit string was > eliminated from most telephony switching environments long ago. > > The definition of specific "tel", "fax", and "modem" urls ignores the > existence of customer premise devices currently in use which allow the > connection of telephones, faxs, and modems on the same telephone line (using > the same telephone number). In reality, there is no difference in the urls > needed for the 3 cases mentioned. The current telephony network is based on > there being no difference within the network for these different uses. If > other information needs to be carried (e.g., to specify the type of modem > supported) this should be separate from the url and may be ignored by some > equipment. This type information should not be a part of the url, since it > does not provide an identification of the "resource location". If it did, > this would then imply, for example, that the following define different > locations, that is, must be routed differently: > > modem:+1-410-555-1234;type=v32b > modem:+1-410-555-1234;type=v21 > modem:+1-410-555-1234;type=x75 > > "Post dial" should not be a part of the url. The example given in Section 2.2 > of accessing a voice mailbox shows the mistake. The digits to be dialed by > the caller when accessing a voice mailbox depend on the voice prompt from > that mailbox system after setup of the initial call. For this reason, the > possible post-dialing digits can not be a part of the url. > > There is a fundamental problem in that the urls being described in this RFC > serve both as a user visible address (like on a letterhead or on a web page) > and as the inter-network element signaling protocol (e.g., part of SIP). It > is noted that E.123, which is referenced, only addresses the representation > of numbers, for example, on letterhead. This dual purpose of the url being > defined leads to confusion in the description. For example, while some > signaling relationships may need to be able to code the extra preliminary > prefix digits needed to do special things (like the "0w00" in the 5th example > in Section 2.6), this would never be a part of the url as printed or visible > on a web page, since it is dependent on the location and equipment of the > originator. > > In the telephony world, the digits 0-9 are represented in signaling only by > those numbers, However, the user may see the address with these numbers > replaced by letters. Since the url being defined here is intended to be seen > by the user (as also defined in E.123), it is essential that it be allowed to > include letters (not the A, B, C, D that are used to designate the extra 4 > codes possible on a DTMF key pad). As E.123 states, "diallable symbols ... > can be digits, letters, or other signs." Of course, this causes a problem if > one tries to incorporate the 4 extra DTMF codes into the same address string. > However, in the ITU-T E.164 numbering plan, these extra DTMF codes can not be > part of the address. The international number is limited to 15 digits, each > being a numeral 0-9. So, in the tel: url beginning with +, there is no > problem with allowing letters a-z. Of course, this depends on the association > between letters and numbers being as recommended in E.161. For this reason, > users are advised to avoid using letters to specify telephone numbers in > international service, but they may. > > The 1st, 2nd, and 3rd examples in Section 2.6 show a problem with this scheme > of treating tel, fax, and modem separately. The three examples use the same > number, which can really occur. As shown, the three identical numbers must > all result in exactly the same call setup regardless of the extra parameters. > Whether it is treated as a telephone or fax or modem call depends on the > kinds of equipment connected and the in-band signals which occur. > > The 4th example in Section 2.6 show the problem with the post-dial logic. > While there may be valid case to support the extra digits needed to directly > dial into a PBX at the destination in order to directly reach an extension, > that capability needs to be under control of the destination. Only the > destination knows whether DTMF or dial-pulse or something else is needed to > signal to the final entity. The originating entity does not even need to know > that there is an extension number present if it is a part of the complete > number (as happens in the US all the time with DID). If the extension number > is in addition to the regular international number (which is limited to 15 > digits), then the originating entity might know that there are additional > digits, but still has no knowledge of how the destination is going to signal > them (e.g., to a PBX). The other example of the origination entity needing of > enter DTMF to invoke a particular service would require an audible response > returned from the destination after call set before these additional DTMF > digits are sent. Therefore, they can not be part of the url in this case. > > The text of the 5th example indicates the problem with this form of the url. > It states "this kind of phone umber MUST NOT be used in an environment where > all users of this URL might not be able to successfully dial out by using > this number directly." Since such a phone number contained on a "company > intranet" or printed material would be accessible by many people in various > places, this will not work. The method used, and the format of the url, > should follow the procedures developed over many decades of such situations > in the telephony world. The telephone number needs to be shown in a standard > local or international format and the user needs to understand how to dial it > from their location (e.g., by dialing "0", waiting for dial tone, and then > dialling "00" for international access because the local telephone book says > to do this). Clearly, when the originating user has a computerized user agent > (SIP phone), it can do this thinking for the person based on dialing rules > that it has been provisioned with, so the human doesn't have to worry about > it. That means that the url on a web page must be in one of the standard > formats (no extra prefix digits). In some environments, there may in fact be > multiple ways to dial a specific destination. Today the user may decide which > to use and the new user agent (SIP phone) can also do so, so it should not be > a part of the url. > > Since the 6th example shows a telephone number in country code 1, it should > be following by a legitimate 10-digit number so as to not confuse. Further, > the idea should be represented with a better example. It is unknown of any > case in which an E.164 telephone number (in North America) would be > specified, but it is only "usable" within that area code. Perhaps the example > would be better if it were to specify a number usable only within a specific > country. > > I suggest that this RFC be pared down to simply defining the url for a > "telephone" number and that additional parameters that might control call > setup, such as modem capabilities, should be a part of SIP or a supplementary > draft that specifically describes additions to SIP for fax and modem calls. > > Mike Pierce > Artel > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jan 1 10:36: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 KAA13168 for ; Tue, 1 Jan 2002 10:36:21 -0500 (EST) 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 g01FZ6o15892; Tue, 1 Jan 2002 10:35:06 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g01FYSo15877 for ; Tue, 1 Jan 2002 10:34:28 -0500 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 KAA03325 for ; Tue, 1 Jan 2002 10:34:28 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g01FYRJ1012487 for ; Tue, 1 Jan 2002 10:34:27 -0500 (EST) Message-ID: <3C31D703.435808EC@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] More 2806bis: ISDN subaddresses to be removed 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, 01 Jan 2002 10:34:27 -0500 Content-Transfer-Encoding: 7bit Unless somebody steps forward and claims use, ISDN subaddresses are also on the way out. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jan 1 11:49:46 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 LAA13549 for ; Tue, 1 Jan 2002 11:49:45 -0500 (EST) 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 g01GM2o16179; Tue, 1 Jan 2002 11:22:02 -0500 Received: from zeus.anet-chi.com (root@zeus.anet-chi.com [207.7.4.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g01GL4o16159 for ; Tue, 1 Jan 2002 11:21:04 -0500 Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g01GKtXA026315; Tue, 1 Jan 2002 10:20:56 -0600 (CST) Message-ID: <000701c192f8$e1988b60$0100a8c0@RepliGate> From: "Jim Fleming" To: "Henning G. Schulzrinne" , References: <3C31D703.435808EC@cs.columbia.edu> Subject: Re: [IPTEL] More 2806bis: ISDN subaddresses to be removed MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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, 1 Jan 2002 11:16:56 -0800 Content-Transfer-Encoding: 7bit And also IPv4 addresses ?...for devices at the edge of the net...? Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info ----- Original Message ----- From: "Henning G. Schulzrinne" To: Sent: Tuesday, January 01, 2002 7:34 AM Subject: [IPTEL] More 2806bis: ISDN subaddresses to be removed > Unless somebody steps forward and claims use, ISDN subaddresses are also > on the way out. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ > 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 Jan 2 08:24: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 IAA03470 for ; Wed, 2 Jan 2002 08:24:28 -0500 (EST) 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 g02D4No21375; Wed, 2 Jan 2002 08:04:23 -0500 Received: from Mitel.COM ([216.191.234.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g02D3to21362 for ; Wed, 2 Jan 2002 08:03:56 -0500 Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id IAA26236; Wed, 2 Jan 2002 08:00:41 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256B35.004775A3 ; Wed, 2 Jan 2002 08:00:31 -0500 X-Lotus-FromDomain: MITEL From: Tom_Gray@Mitel.COM To: "Henning G. Schulzrinne" cc: Mpierce1@aol.com, iptel@lists.bell-labs.com Message-ID: <85256B35.004773FA.00@kanmta01.software.mitel.com> Subject: Re: [IPTEL] Comments on RFC 2806 revision (tel url) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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, 2 Jan 2002 08:00:31 -0500 From: Tom Gray@MITEL on 01/02/2002 08:00 AM With respect to the suggestion that the issue of 'wait for dial tone' belongs in the media gateway and should not be specified in the tel URL, comes the issue of how the media gateway can know how to do this? Contrary to what was said below, it seems to me that the originator would know that the 'wait for dial tone' is needed in typical cases and that this fact would not be known to media gateways.. With the example given below of the use of 'wait for dial tone' on a PBX with DISA or some similar functionality, a user would enter a public PSTN number followed by a number of digits. How would the MG know that the routing plan for the number should have a 'wait for dial tone' in it? The public PSTN number is likely one that the owners of the media gateway are unaware of. It would be very unlikely that they would have programmed their routes to behave in the proper manner. "Henning G. Schulzrinne" on 01/01/2002 08:54:52 AM To: Mpierce1@aol.com, iptel@lists.bell-labs.com cc: (bcc: Tom Gray/Kan/Mitel) Subject: Re: [IPTEL] Comments on RFC 2806 revision (tel url) Mike, Jon: thanks for your helpful comments. In rewriting the spec, I also found this dual use somewhat confusing. I'm all for shorter specs that we can actually get implementation reports for, so if I get the gist of your proposal: - Just a "tel" URL in this draft; no 'fax:' or 'modem:' - No post-dial strings or 'waiting-for-dial-tone' characters (p, w). - No carrier identification. For the record (and to conserve the text in case it needs to reappear), the new I-D will appear as is, but I will then push out a streamlined version unless somebody makes a convincing argument within the next week that the features above are vital and that they have implemented them or are planning to. (As usual for interop reports, I will be glad to treat such information as confidential; there is no need to make your intents and identity a matter of public record.) Note that special-purpose, private parameters are permissible. We should probably get IANA involved soon. I'd rather not delay the 2806bis draft in the desperate attempt to demonstrate interoperability of special features. Mpierce1@aol.com wrote: > > To all, > > I believe that mention of this RFC in Minneapolis in the March 2001 meeting > indicated that there was a general feeling that there were significant > problems with the current text and a rewrite was required. Based on this, I > will make some rather substantial comments on the current text, with the > understanding that they propose some significant changes to the concept and > details described. > > The text of RFC 2806 seems to confuse the controls that might be needed > between a controller and the device doing outgoing dialing (e.g., MGC and MG) > with what is required in the url to designate the destination (location). For > example, it takes the AT modem commands for pauses and waits for dial tone > and includes them with the url. While there may be cases in which one > specific network element (e.g., a MG) needs to apply these techniques in > order to send digits (DTMF or dial pulse) to another element (e.g., a circuit > switched PBX), the originator of the call knows nothing about this, so this > information should not be a part of the url. In fact, due to alternate > routing, two calls with the same url might be treated differently because > they are routed differently. This type of dialing in which the originator > needed to know the routing in order to formulate the digit string was > eliminated from most telephony switching environments long ago. > > The definition of specific "tel", "fax", and "modem" urls ignores the > existence of customer premise devices currently in use which allow the > connection of telephones, faxs, and modems on the same telephone line (using > the same telephone number). In reality, there is no difference in the urls > needed for the 3 cases mentioned. The current telephony network is based on > there being no difference within the network for these different uses. If > other information needs to be carried (e.g., to specify the type of modem > supported) this should be separate from the url and may be ignored by some > equipment. This type information should not be a part of the url, since it > does not provide an identification of the "resource location". If it did, > this would then imply, for example, that the following define different > locations, that is, must be routed differently: > > modem:+1-410-555-1234;type=v32b > modem:+1-410-555-1234;type=v21 > modem:+1-410-555-1234;type=x75 > > "Post dial" should not be a part of the url. The example given in Section 2.2 > of accessing a voice mailbox shows the mistake. The digits to be dialed by > the caller when accessing a voice mailbox depend on the voice prompt from > that mailbox system after setup of the initial call. For this reason, the > possible post-dialing digits can not be a part of the url. > > There is a fundamental problem in that the urls being described in this RFC > serve both as a user visible address (like on a letterhead or on a web page) > and as the inter-network element signaling protocol (e.g., part of SIP). It > is noted that E.123, which is referenced, only addresses the representation > of numbers, for example, on letterhead. This dual purpose of the url being > defined leads to confusion in the description. For example, while some > signaling relationships may need to be able to code the extra preliminary > prefix digits needed to do special things (like the "0w00" in the 5th example > in Section 2.6), this would never be a part of the url as printed or visible > on a web page, since it is dependent on the location and equipment of the > originator. > > In the telephony world, the digits 0-9 are represented in signaling only by > those numbers, However, the user may see the address with these numbers > replaced by letters. Since the url being defined here is intended to be seen > by the user (as also defined in E.123), it is essential that it be allowed to > include letters (not the A, B, C, D that are used to designate the extra 4 > codes possible on a DTMF key pad). As E.123 states, "diallable symbols ... > can be digits, letters, or other signs." Of course, this causes a problem if > one tries to incorporate the 4 extra DTMF codes into the same address string. > However, in the ITU-T E.164 numbering plan, these extra DTMF codes can not be > part of the address. The international number is limited to 15 digits, each > being a numeral 0-9. So, in the tel: url beginning with +, there is no > problem with allowing letters a-z. Of course, this depends on the association > between letters and numbers being as recommended in E.161. For this reason, > users are advised to avoid using letters to specify telephone numbers in > international service, but they may. > > The 1st, 2nd, and 3rd examples in Section 2.6 show a problem with this scheme > of treating tel, fax, and modem separately. The three examples use the same > number, which can really occur. As shown, the three identical numbers must > all result in exactly the same call setup regardless of the extra parameters. > Whether it is treated as a telephone or fax or modem call depends on the > kinds of equipment connected and the in-band signals which occur. > > The 4th example in Section 2.6 show the problem with the post-dial logic. > While there may be valid case to support the extra digits needed to directly > dial into a PBX at the destination in order to directly reach an extension, > that capability needs to be under control of the destination. Only the > destination knows whether DTMF or dial-pulse or something else is needed to > signal to the final entity. The originating entity does not even need to know > that there is an extension number present if it is a part of the complete > number (as happens in the US all the time with DID). If the extension number > is in addition to the regular international number (which is limited to 15 > digits), then the originating entity might know that there are additional > digits, but still has no knowledge of how the destination is going to signal > them (e.g., to a PBX). The other example of the origination entity needing of > enter DTMF to invoke a particular service would require an audible response > returned from the destination after call set before these additional DTMF > digits are sent. Therefore, they can not be part of the url in this case. > > The text of the 5th example indicates the problem with this form of the url. > It states "this kind of phone umber MUST NOT be used in an environment where > all users of this URL might not be able to successfully dial out by using > this number directly." Since such a phone number contained on a "company > intranet" or printed material would be accessible by many people in various > places, this will not work. The method used, and the format of the url, > should follow the procedures developed over many decades of such situations > in the telephony world. The telephone number needs to be shown in a standard > local or international format and the user needs to understand how to dial it > from their location (e.g., by dialing "0", waiting for dial tone, and then > dialling "00" for international access because the local telephone book says > to do this). Clearly, when the originating user has a computerized user agent > (SIP phone), it can do this thinking for the person based on dialing rules > that it has been provisioned with, so the human doesn't have to worry about > it. That means that the url on a web page must be in one of the standard > formats (no extra prefix digits). In some environments, there may in fact be > multiple ways to dial a specific destination. Today the user may decide which > to use and the new user agent (SIP phone) can also do so, so it should not be > a part of the url. > > Since the 6th example shows a telephone number in country code 1, it should > be following by a legitimate 10-digit number so as to not confuse. Further, > the idea should be represented with a better example. It is unknown of any > case in which an E.164 telephone number (in North America) would be > specified, but it is only "usable" within that area code. Perhaps the example > would be better if it were to specify a number usable only within a specific > country. > > I suggest that this RFC be pared down to simply defining the url for a > "telephone" number and that additional parameters that might control call > setup, such as modem capabilities, should be a part of SIP or a supplementary > draft that specifically describes additions to SIP for fax and modem calls. > > Mike Pierce > Artel > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 Jan 2 16:32: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 QAA11179 for ; Wed, 2 Jan 2002 16:32:16 -0500 (EST) 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 g02LF4o23551; Wed, 2 Jan 2002 16:15:04 -0500 Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g02LE5o23536 for ; Wed, 2 Jan 2002 16:14:05 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g02LDxn09835 for ; Wed, 2 Jan 2002 16:13:59 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029) id 3C06950500713063; Wed, 2 Jan 2002 16:13:10 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] draft meeting minutes Message-ID: <62DA45D4963FA747BA1B253E266760F9F21AA8@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] draft meeting minutes Thread-Index: AcGRtxmHn/d0tv2XEdWVVQCQJ2GH0wCCvS5A X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Roy, Radhika R, ALCTA" To: "Jonathan Rosenberg" Cc: "iptel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id g02LE5o23537 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, 2 Jan 2002 16:13:40 -0500 Content-Transfer-Encoding: 8bit Please see comments inline [RRR] -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Sunday, December 30, 2001 11:53 PM To: Roy, Radhika R, ALCTA Cc: iptel Subject: Re: [IPTEL] draft meeting minutes Roy, Radhika R, ALCTA wrote: > Comments inline [RRR] > >>The GW registration scenarios MUST not exclude any types of GWs. That >>is, we must NOT develop the SIP-ISUP GW registration protocol per se. >> > > > Radhika, this has been discussed on the list, and there was a consensus > hum taken on this subject at IETF 52. The consensus was that non-PSTN > gateways are OUT OF SCOPE. > > [RRR] I would appreciate if the technical reasons would have been > documented. (I have not seen in the meeting minutes.) Its an issue of scope and what problem people agree we are trying to solve. The problem we were chartered to solve, and the problem people want to solve, is managing the resources of a set of PSTN gateways fronted by a proxy. Thus, this is the problem that will drive requirements for the protocol. [RRR] Good that you have provided the technical points. Let me understand your points while you are defining the scope of the "registration protocol." Is there any document that we can look into because, now, you are saying that the managing of resources of the PSTN GW resources ONLY (not the other GWs although the title of your contribution says that the GW registration protocol)? [RRR] If there is an agreed upon written document of the scope, we would not spend time in debating the scope of the " GW registration protocol." > Now, it may be that the protocol that is > developed will work for them anyway, > > [RRR] Could you please clarify this? Do you mean that the registration > protocol can be used/extended for any types of GWs? No, I am saying exactly what it says above. The protocol will be driven by requirements to handle the case where a proxy fronts a set of PSTN gateways whose resources it wishes to manage. If, when we are done, it turns out that such a protocol can in fact be used for something that is not a PSTN gateway, well thats fine. But it doesn't drive requirements. [RRR] Let us add to clarify this more. It is rather SIP-ISUP GW from protocol point of view. The attributes like address family, capacity, QOS, etc. that are abstracted from the ISUP side, people call it as "PSTN" GW attributes (PSTN GW is a wrong term - an MGC/MG would have better because it is an application layer entity). In the SIP side, we are assuming that the SIP proxy and the LS are collocated, and the attributes (e.g., address family, capacity, QOS, etc) that abstracted from the SIP side are communicated via the LS. [RRR] In the same token, we also call SIP-H.323 GW. We are NOT talking about the protocol conversion per se. Like SIP-ISUP GW, we are also talking about the attributes of the GW from the SIP side as well as from the H.323 side. For example, address family, capacity, QOS, etc. are considered for the SIP-H.323 GW registration as well. [RRR] We hope that these clarifications will help to remove some mis-conceptions. So, we can now consider all kinds of GWs in the same baseline including SIP-ISUP, SIP-H.323, etc. > > but we are not considering > requirements to deal with SIP-H.323 gateways. > > [RRR] What are the additional requirements for the SIP-H.323 GWs that > the registration protocol will not work? You have asked for things like address families that are in the form of domain names. We will not consider that as a requirement. In any case, I don't think it makes any sense at all, since if you know the domain name, sounds like DNS is what you want. [RRR] The address families can include like E.164, email IDs, URL IDs, etc (as it has been done in H.323/H.225.0 Annex G). DNS may not be involved directly as it can be seen in the case of H.323/H.225.0 Annex G. I fought against the inclusion of domain-name based address families in TRIP in the first place for the same reasons. [RRR] It is a good news that you fought for something that is needed in TRIP where E.164 address families have been addressed. You might have also fought NOT to include the SIP-ISUP (PSTN) GW capacity, QOS, and other attributes that are very very complex to propagate among the LSs in the inter-Domain environment. You did all the right things for TRIP and I agree with you. [RRR] However, the above things do NOT need to be true for the GW registration protocol. A GW registers all its attributes including address families (E.164, email IDs, URL IDs, etc.), capacity, QOS, and others. How all these attributes will be propagated among the LSs either in the intra-Domain or in the inter-Domain is a separate issue. For example, TRIP allows to propagate only the E.164 address family among the LSs in inter-Domain environment, NOT the email IDs, URL IDs, capacity, QOS, or other attributes. [RRR] Now we can examine how other protocols have been developed in solving the above problem. For example, H.323 allows that a GW will be able to register all kinds of address families (e.g., E.164, email IDs, URL IDs, etc.), capacity, etc. H.323/H.225.0 allows how all these address families (e.g., E.164, email IDs, URL IDs, etc.) can be communicated among the GKs using the LRQ/LCF/LRJ messages in intra-Domain environment. And a complete H.323/H.225.0 Annex G protocol suit has been developed to transfer all these addresses (e.g., E.164, email IDs, URL IDs, etc.) among the GKs/BEs in inter-Domain environment along with other attributes. [RRR] So, our point has been that if we develop the GW registration protocol that registers all the attributes of a SIP-ISUP (PSTN) GW, we do not need to develop any NEW protocol to register the attributes of the SIP-H.323 GW from the SIP side (H.323 side is already taken care of by the H.323 protocol suits). For example, the GW registration protocol will have a field for address family and the same field can be used to register all addresses (e.g., E.164, email IDs, URL IDs, etc.) as desired. The thing that we need to take care of is that TRIP or I-TRIP will use ONLY the E.164 addresses (not email IDs, or URL IDs) among the LSs for propagation of routes. It is NOT a rocket science. > [RRR] I am assuming that we will develop the registration protocol > considering the SIP-ISUP GW first while the protocol can be extended for > other GWs as well. You are fixated on protocol conversions. That is not the problem at hand. [RRR] We are NOT talking about the protocol conversion like SIP-ISUP or SIP-H.323 as explained above. We are ONLY interested about the attributes (e.g., address family, capacity, QOS, etc) of the GW that is seen from the SIP proxy/LS side. We are NOT concerned about the ISUP or H.323 or SIP protocol per se. So, there is no reason that you should be concerned with. The type of SS7 protocol is not the primary point; [RRR] Agreed as clarified above. the primary point is that these are PSTN gateways, possibly large ones, with attributes that reflect the fact that there is PSTN connectivity. That means its things like ASR and PDD that need to be conveyed. [RRR] As I mentioned before, we are developing the GW registration protocol that will have the fields like address family, capacity, QOS, and others to satisfy the needs of the SIP-ISUP [PSTN] GW first. Once we do this, the same fields can also be used to satisfy the needs of the registration for other GWs like SIP-H.323 GW by default. We do NOT need to do any extra work. Let us keep our mind OPEN, because we are developing the GW registration protocol (not the TRIP [inter-Domain] or I-TRIP [intra-Domain] that works among the LSs ONLY for the E.164 address family). [RRR] The main thrust of our argument is that the same GW registration protocol that will be used to satisfy the needs of the SIP-ISUP [PSTN] GW will also be applicable to register the SIP-H.323 GW as explained above. -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 Wed Jan 2 19:37: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 TAA13344 for ; Wed, 2 Jan 2002 19:37:24 -0500 (EST) 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 g030a7o24704; Wed, 2 Jan 2002 19:36:07 -0500 Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g030ZOo24691 for ; Wed, 2 Jan 2002 19:35:24 -0500 Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA22764; Wed, 2 Jan 2002 19:35:18 -0500 (EST) 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 AAH16511; Wed, 2 Jan 2002 19:30:55 -0500 (EST) Message-Id: <4.3.2.7.2.20020102184820.00b0dcf0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Peterson, Jon" From: Michael Hammer Subject: RE: [IPTEL] draft meeting minutes Cc: iptel In-Reply-To: <70565611B164D511957A001083FCDD56CAAD48@va02.va.neustar.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, 02 Jan 2002 19:40:36 -0500 Jon, Carrier IDs are used as an attribute to affect routing. Carriers have multiple switching points that can be contacted through some type of signaling address. Within a switching center, there are multiple trunk groups to other switching centers which may belong to the same carrier or different carriers. Choosing a TG from that switching center determines what next switching center the call can be routed to, and by inference, what the next hop carrier will be. Therefore, the carrier ID can determine what TG will be selected from that switching center. The originating side wants to route to a given carrier and location and uses the inferred signaling address. The destination side maps the carrier to an appropriate trunk group to get to that carrier and destination user address. The 101 prefix dialing is just a method of indicating the carrier to use at by the switch terminating the local loop. The fact that the next switching center can reach another carrier through another TG would be irrelevant, if the information was facility-based and not subverted by business arrangements. But, given those business arrangements, what you are pointing out is that the CIC:TG relationship is not hierarchical and thus a TG could have multiple carriers associated with it. That holds true if circuits are shared across carriers and the originating user is not affected by this business arrangement (i.e. charged for the next-hop facilities used to reach the desired carrier). Question 1: If 2 carriers were reach able over the same T-3, with one directly reachable and the other indirectly reachable, would the gateway almost always allocate the one physical facility as 2 logical trunk groups anyway? (Thus restoring the TG infers CIC mapping.) We already know that any switch in the PSTN can reach any other. The real question is how to route such that the PSTN path is minimized at the expense of a more direct IP path (assumes that is the least cost path). The use of TG data should be of local significance only at the egress of the IP network. I agree with your call for some type of geographic attribute. But, I don't understand your final statement. I don't want to see carrier's charges on my bill, if as the caller I specify a particular long-distance or international carrier. Also, will the CIC always be based on national body registration, or will IANA or someone ever assign international CIC codes for global carriers? Mike At 05:37 AM 12/31/2001 -0600, Peterson, Jon wrote: >I wanted to speak a bit to the issue from the minutes below regarding the >ubiquitous availability of carriers through trunks in the PSTN, and the >relevance of the 'equal access' concept - especially since this a matter on >which Dave and I have differed for some time. > >There are a number of ways (thanks to equal access provisions) that a user >can directly or indirectly select a carrier, for example: > >- Having an entry in the LIDB for their address corresponding to the Carrier >Identification Code of their chosen carrier, so that inter-exchange calls >generated from their address always pick up this CIC (i.e. PIC LD). > >- Using a dial-around (101+XXX+address) to override the default CIC for >their line. > >- Dialing a freephone number whose SMS/800 dip returns a CIC code - >presumably once the call has been routed to the administrative domain of the >carrier, a further internal dip will be performed to translate the freephone >number into a geographic number. > >Dave is certainly correct that a CIC does not necessarily correspond to some >physical network - that is, the concept of a 'carrier' chosen by a user is >largely a matter of who issues your bill, not what physical infrastructure >your call crosses. For example, there are resellers of long-distance service >whose CICs are really just aliases for the CIC of a major carrier. Large >carriers may own several CICs they use to target their services. It's >certainly not some kind of one-to-one mapping from CICs to physical >infrastructure. > >HOWEVER, this doesn't mean that a decision isn't made, in some places in the >telephone network, about how a call is routed based on the CIC. In SS7, when >a CIC has been selected for a call, it is carried within the TNS or >(ANSIfied) CIC parameter of the Initial Address Message. The presence of >this parameter modifies how a call is routed through the telephone network, >especially at tandems. > >So, to bring this matter back to trunk groups, one view might be that a >given trunk group may be considered to be a route to a CIC if, when an SS7 >IAM message carrying this CIC is sent over the trunk group, this call will >(eventually) be routed to the administrative domain responsible for the CIC >(and presumably get delivered appropriately). One might contend, as an >opposing position, that only the carrier that owns the switch on the far >side of the trunk should be considered to be reachable through a trunk - but >I suspect that in an overflow situation most network would be content to >send calls for some other carrier through such a trunk group, even if it >introduced a middle-man network, complicating routing and potentially >settlement. > >The correct position is probably somewhere in the middle. One or more CICs >may be 'preferred' for a particular trunk by some switch in the network, >largely because of who happens to own the equipment on the other side, but >in addition all CICs are usually 'available' through such trunks. Something >similar, I think, is true of E.164 numbers; certain ranges may be preferred >(due to settlement concerns) for particular trunk groups, but all number >ranges are usually available. > >Finally, it's important to note that CICs are national in scope, and that >therefore trunk groups are most likely only routes to the set of CICs within >a particular nationality. There have been suggestions in the past that >identifiers for CICs in the gw reg mechanism should be concatenated with >some sort of country code to provide a scope of a CIC - I would agree that >this is probably necessary. Then we could refine our characterization of >trunk group CIC routes to one in which all carriers for a given nationality >could be 'available' through a trunk group. > >Jon Peterson >NeuStar, Inc. > > > Further discussion: > > > > Jon said that he believes this should always be about TGs - believes > > should treat PRI as a trunk. Cullen asked whether there would ever be > > more than one carrier on a single trunk? Jon said that there are a > > number of carriers for virtually every trunk. Due to EA. Dave Oran > > responded that this has nothing to do with it, as the EA concept user > > experience doesn't necessarily relate. Take it to the list. > > > >_______________________________________________ >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 Thu Jan 3 02:45: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 CAA27150 for ; Thu, 3 Jan 2002 02:45:27 -0500 (EST) 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 g037i3o26239; Thu, 3 Jan 2002 02:44:03 -0500 Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g037hAo26226 for ; Thu, 3 Jan 2002 02:43:10 -0500 Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g037h9b16755; Thu, 3 Jan 2002 01:43:09 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 01:43:09 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAD62@va02.va.neustar.com> From: "Peterson, Jon" To: "'Mpierce1@aol.com'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] Definition of "trunk group" 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: Thu, 3 Jan 2002 01:43:07 -0600 I agree with your definition of a trunk group; we arrived at a similar one on the mailing list earlier (i.e. roughly, a bundle of DS0's between two PSTN network entities that are grouped under some kind of common policy). I agree as well that this definition does not include what the resources are that are available through a trunk group; nor for the purposes of gateway registration does the definition of a gateway include the E.164 number ranges that can be reached through it (the TRIP model). My contention has been that considering the resources that are available through a trunk group may offer us slightly greater leverage on the problems we are trying to solve than considering the resources that are available through a gateway - partially because there are many varieties of gateways, and I believe slightly less variation amongst trunk groups. We discussed splitting TGs across multiple GWs at SLC - if I recall, I was willing to commit to that proposition with the small caveat that you can't split SS7 IMT TGs across PCs. However, I'm sure you'll acknowledge that it isn't uncommon for ISDN NFAS groups to straddle physical gateways, and I feel that our definition of TG should be broad enough to include these. The question of whether the 'route list' model gives us still more leverage than the 'trunk group' model is interesting; 'route list' certainly provides an even greater level of abstraction. Without going through a lot of semantic hair-splitting, I think that trunk groups provide just the right layer of abstraction. The question here is "What entities should the gwreg system provide the availability of?" I think trunk groups have state that changes dynamically, and that these states in turn determine the availability of network resources. A proxy server that receives registrations for such trunk groups would construct the 'route list,' as it were, of alternative trunk groups that meet the routing criteria of calls. I don't think a system in which 'route lists' were published to proxy servers through the gateway registration process would grant us much additional leverage on network design - in fact, I suspect it would just push the problems around a bit. Jon Peterson NeuStar, Inc > -----Original Message----- > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > Sent: Monday, December 31, 2001 11:12 AM > To: iptel@lists.bell-labs.com > Subject: [IPTEL] Definition of "trunk group" > > > I have the following comments concerning the use of the term > "trunk groups" > based on the presentation in SLC and the discussion on the list: > > I believe that a lot of the disagreement is related to the > definition and > concept of what a "trunk group" is. There was mention of a > "trunk group" > being those facilities through which one could get to a > specific destination > or reach a specific set of carriers. Also, the presentation > showed a trunk > group split across multiple Gateways. > > For reference, the following 2 definitions come from American > National > Standard T1.523-2001: > > trunk: 1. In a communications network, a single transmission > channel between > two points that are switching centers or nodes, or both. 2. > [A] circuit > between switchboards or other switching equipment, as > distinguished from > circuits which extend between central office switching equipment and > information origination/termination equipment. [47 CFR > Pt.36-A] Note: Trunks > may be used to interconnect switches, such as major, minor, > public and > private switches, to form networks. > > trunk group: Two or more trunks of the same type between two > given points. > > The definition of "trunk group" in telephony does not include > where you can > get to by going through it. As noted in SLC, in many cases, > all destinations > can be reached through a specific trunk group due to the > routing which the > next switch may do. Basic requirements in the US are that all > carriers can be > reached by the end user, so, in some cases, when talking > about a trunk group > from a Gateway which serves as the user's originating end > office, that trunk > group can reach every carrier and every destination. In > others, if the trunk > group in question connects to a specific carrier (the > termination "point" of > the trunk group), then it is likely that it can only reach > that one carrier. > When talking about a trunk group terminating at an end office > (or a Gateway) > then it can probably only reach destination connected to that > end office. > > It is not correct to depict a trunk group split between two > Gateways unless > the 2 Gateways are simply 2 physical devices which act as a > single switching > "point" controlled by a single MGC. In this case, the 2 > physical devices are > really 1 single Gateway for purposes of architecture and > signaling with other > MG/MGCs. > > This issue in IPTEL can be simplified if the definition for > "trunk group" in > T1.523 (which is consistent with the usage in ITU-T) is accepted. > > A further definition in T1.523 is: > > route list: A specific list of trunk groups. [After T1.667-1999] > > This is more similar to the term "trunk group" as being used > in the IPTEL > discussions. The function of "routing" a specific destination > address in any > switching element results in the determination of a "route > list", which > points to a list of trunk groups (alternate routes). > > Mike Pierce > Artel > _______________________________________________ > 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 Thu Jan 3 03:51: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 DAA27912 for ; Thu, 3 Jan 2002 03:51:03 -0500 (EST) 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 g038o2o26632; Thu, 3 Jan 2002 03:50:03 -0500 Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g038nIo26614 for ; Thu, 3 Jan 2002 03:49:18 -0500 Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g038nFb17549; Thu, 3 Jan 2002 02:49:15 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 02:49:15 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAD63@va02.va.neustar.com> From: "Peterson, Jon" To: "'Michael Hammer'" Cc: iptel Subject: RE: [IPTEL] draft meeting minutes 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: Thu, 3 Jan 2002 02:49:13 -0600 I don't think we're really disagreeing about much of what you say below. I agree with your account of how things operate in the PSTN. It sounds like we agree that the relationship of CICs to TGs is not in any simple way hierarchical. The primary purpose of my note on the CIC was to suggest a potential litmus test for whether or not a CIC was routable through a TG. I think that's an important definition for us all to agree on if we're going to consider propagating attributes like CICs in the gw reg protocol. In answer to the question you pose, I think my contention here is that one logical trunk group could have more than one CIC associated with it. Imagine a trivial VoIP network containing one proxy server and one PSTN gateway in which the gateway had a single trunk group aimed at an access tandem. Clearly, that trunk group would be the route for all CICs irrespective of whether it was directly or indirectly connected to any given carrier. Introduce a second trunk group going to a different access tandem, and perhaps this trunk group would be a better route for some set of CICs. But in neither case would you want to construct, say, one logical trunk group per CIC and overlay them all on the physical trunk(s) - that would be quite an administrative headache. I'm not sure I necessarily agree that the question with CICs is "how to route such that the PSTN path is minimized at the expense of a more direct IP path", or even that this is necessarily a least-cost problem. There have been significant head-end hop-off vs. tail-end hop-off arguments with regard to CIC routing levied here in the past. Fortunately, I think this is ultimately a routing policy question, and really any of these philosophies could be enabled by the CIC propagation systems we're discussing above. And, my final statement in my previous mail was intended only to illustrate that CICs are national in scope - that's all. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, January 02, 2002 4:41 PM > To: Peterson, Jon > Cc: iptel > Subject: RE: [IPTEL] draft meeting minutes > > > Jon, > > Carrier IDs are used as an attribute to affect routing. > Carriers have > multiple switching points that can be contacted through some type of > signaling address. Within a switching center, there are > multiple trunk > groups to other switching centers which may belong to the > same carrier or > different carriers. Choosing a TG from that switching center > determines > what next switching center the call can be routed to, and by > inference, > what the next hop carrier will be. Therefore, the carrier ID > can determine > what TG will be selected from that switching center. > > The originating side wants to route to a given carrier and > location and > uses the inferred signaling address. The destination side > maps the carrier > to an appropriate trunk group to get to that carrier and > destination user > address. > > The 101 prefix dialing is just a method of indicating the > carrier to use at > by the switch terminating the local loop. The fact that the > next switching > center can reach another carrier through another TG would be > irrelevant, if > the information was facility-based and not subverted by business > arrangements. But, given those business arrangements, what you are > pointing out is that the CIC:TG relationship is not > hierarchical and thus a > TG could have multiple carriers associated with it. That > holds true if > circuits are shared across carriers and the originating user is not > affected by this business arrangement (i.e. charged for the next-hop > facilities used to reach the desired carrier). > > Question 1: If 2 carriers were reach able over the same T-3, > with one > directly reachable and the other indirectly reachable, would > the gateway > almost always allocate the one physical facility as 2 logical > trunk groups > anyway? (Thus restoring the TG infers CIC mapping.) > > We already know that any switch in the PSTN can reach any > other. The real > question is how to route such that the PSTN path is minimized at the > expense of a more direct IP path (assumes that is the least cost > path). The use of TG data should be of local significance > only at the > egress of the IP network. > > I agree with your call for some type of geographic attribute. > But, I don't > understand your final statement. I don't want to see > carrier's charges on > my bill, if as the caller I specify a particular long-distance or > international carrier. Also, will the CIC always be based on > national body > registration, or will IANA or someone ever assign > international CIC codes > for global carriers? > > Mike > > > At 05:37 AM 12/31/2001 -0600, Peterson, Jon wrote: > > >I wanted to speak a bit to the issue from the minutes below > regarding the > >ubiquitous availability of carriers through trunks in the > PSTN, and the > >relevance of the 'equal access' concept - especially since > this a matter on > >which Dave and I have differed for some time. > > > >There are a number of ways (thanks to equal access > provisions) that a user > >can directly or indirectly select a carrier, for example: > > > >- Having an entry in the LIDB for their address > corresponding to the Carrier > >Identification Code of their chosen carrier, so that > inter-exchange calls > >generated from their address always pick up this CIC (i.e. PIC LD). > > > >- Using a dial-around (101+XXX+address) to override the > default CIC for > >their line. > > > >- Dialing a freephone number whose SMS/800 dip returns a CIC code - > >presumably once the call has been routed to the > administrative domain of the > >carrier, a further internal dip will be performed to > translate the freephone > >number into a geographic number. > > > >Dave is certainly correct that a CIC does not necessarily > correspond to some > >physical network - that is, the concept of a 'carrier' > chosen by a user is > >largely a matter of who issues your bill, not what physical > infrastructure > >your call crosses. For example, there are resellers of > long-distance service > >whose CICs are really just aliases for the CIC of a major > carrier. Large > >carriers may own several CICs they use to target their services. It's > >certainly not some kind of one-to-one mapping from CICs to physical > >infrastructure. > > > >HOWEVER, this doesn't mean that a decision isn't made, in > some places in the > >telephone network, about how a call is routed based on the > CIC. In SS7, when > >a CIC has been selected for a call, it is carried within the TNS or > >(ANSIfied) CIC parameter of the Initial Address Message. The > presence of > >this parameter modifies how a call is routed through the > telephone network, > >especially at tandems. > > > >So, to bring this matter back to trunk groups, one view > might be that a > >given trunk group may be considered to be a route to a CIC > if, when an SS7 > >IAM message carrying this CIC is sent over the trunk group, > this call will > >(eventually) be routed to the administrative domain > responsible for the CIC > >(and presumably get delivered appropriately). One might > contend, as an > >opposing position, that only the carrier that owns the > switch on the far > >side of the trunk should be considered to be reachable > through a trunk - but > >I suspect that in an overflow situation most network would > be content to > >send calls for some other carrier through such a trunk > group, even if it > >introduced a middle-man network, complicating routing and potentially > >settlement. > > > >The correct position is probably somewhere in the middle. > One or more CICs > >may be 'preferred' for a particular trunk by some switch in > the network, > >largely because of who happens to own the equipment on the > other side, but > >in addition all CICs are usually 'available' through such > trunks. Something > >similar, I think, is true of E.164 numbers; certain ranges > may be preferred > >(due to settlement concerns) for particular trunk groups, > but all number > >ranges are usually available. > > > >Finally, it's important to note that CICs are national in > scope, and that > >therefore trunk groups are most likely only routes to the > set of CICs within > >a particular nationality. There have been suggestions in the > past that > >identifiers for CICs in the gw reg mechanism should be > concatenated with > >some sort of country code to provide a scope of a CIC - I > would agree that > >this is probably necessary. Then we could refine our > characterization of > >trunk group CIC routes to one in which all carriers for a > given nationality > >could be 'available' through a trunk group. > > > >Jon Peterson > >NeuStar, Inc. > > > > > Further discussion: > > > > > > Jon said that he believes this should always be about TGs > - believes > > > should treat PRI as a trunk. Cullen asked whether there > would ever be > > > more than one carrier on a single trunk? Jon said that there are a > > > number of carriers for virtually every trunk. Due to EA. > Dave Oran > > > responded that this has nothing to do with it, as the EA > concept user > > > experience doesn't necessarily relate. Take it to the list. > > > > > >_______________________________________________ > >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 Thu Jan 3 11:03:49 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 LAA04855 for ; Thu, 3 Jan 2002 11:03:49 -0500 (EST) 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 g03FgDo28468; Thu, 3 Jan 2002 10:42:13 -0500 Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g03Ff1o28448 for ; Thu, 3 Jan 2002 10:41:01 -0500 Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA00734; Thu, 3 Jan 2002 10:40:56 -0500 (EST) 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 AAH19220; Thu, 3 Jan 2002 10:36:33 -0500 (EST) Message-Id: <4.3.2.7.2.20020103103235.00b57bf0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Peterson, Jon" From: Michael Hammer Subject: RE: [IPTEL] draft meeting minutes Cc: iptel In-Reply-To: <70565611B164D511957A001083FCDD56CAAD63@va02.va.neustar.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, 03 Jan 2002 10:47:13 -0500 Yes, I think our perspectives are consistent. What I have a problem with is getting wrapped around the axle with propagating routing information across the network, that in the end may not provide a useful discriminator for choosing one route over another. What makes one gateway hop-off point better than another? Are we minimizing PSTN (or other) network administrations that we must cross? Are we minimizing conversion points (RTP to TDM) that may introduce noise? Can a network capacity re-seller reduce the number of billing relationships? My starting axiom was that the call was routed into the IP world or started there for a reason, and that IP was the preferred path to effectively make all calls local. Your point that the existing CIC codes are inherently geographical on a large scale also points to the possible need to define geographic attributes on a smaller scale as well. Mike At 02:49 AM 1/3/2002 -0600, Peterson, Jon wrote: >I don't think we're really disagreeing about much of what you say below. I >agree with your account of how things operate in the PSTN. It sounds like we >agree that the relationship of CICs to TGs is not in any simple way >hierarchical. > >The primary purpose of my note on the CIC was to suggest a potential litmus >test for whether or not a CIC was routable through a TG. I think that's an >important definition for us all to agree on if we're going to consider >propagating attributes like CICs in the gw reg protocol. > >In answer to the question you pose, I think my contention here is that one >logical trunk group could have more than one CIC associated with it. Imagine >a trivial VoIP network containing one proxy server and one PSTN gateway in >which the gateway had a single trunk group aimed at an access tandem. >Clearly, that trunk group would be the route for all CICs irrespective of >whether it was directly or indirectly connected to any given carrier. >Introduce a second trunk group going to a different access tandem, and >perhaps this trunk group would be a better route for some set of CICs. But >in neither case would you want to construct, say, one logical trunk group >per CIC and overlay them all on the physical trunk(s) - that would be quite >an administrative headache. > >I'm not sure I necessarily agree that the question with CICs is "how to >route such that the PSTN path is minimized at the expense of a more direct >IP path", or even that this is necessarily a least-cost problem. There have >been significant head-end hop-off vs. tail-end hop-off arguments with regard >to CIC routing levied here in the past. Fortunately, I think this is >ultimately a routing policy question, and really any of these philosophies >could be enabled by the CIC propagation systems we're discussing above. > >And, my final statement in my previous mail was intended only to illustrate >that CICs are national in scope - that's all. > >Jon Peterson >NeuStar, Inc. > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Wednesday, January 02, 2002 4:41 PM > > To: Peterson, Jon > > Cc: iptel > > Subject: RE: [IPTEL] draft meeting minutes > > > > > > Jon, > > > > Carrier IDs are used as an attribute to affect routing. > > Carriers have > > multiple switching points that can be contacted through some type of > > signaling address. Within a switching center, there are > > multiple trunk > > groups to other switching centers which may belong to the > > same carrier or > > different carriers. Choosing a TG from that switching center > > determines > > what next switching center the call can be routed to, and by > > inference, > > what the next hop carrier will be. Therefore, the carrier ID > > can determine > > what TG will be selected from that switching center. > > > > The originating side wants to route to a given carrier and > > location and > > uses the inferred signaling address. The destination side > > maps the carrier > > to an appropriate trunk group to get to that carrier and > > destination user > > address. > > > > The 101 prefix dialing is just a method of indicating the > > carrier to use at > > by the switch terminating the local loop. The fact that the > > next switching > > center can reach another carrier through another TG would be > > irrelevant, if > > the information was facility-based and not subverted by business > > arrangements. But, given those business arrangements, what you are > > pointing out is that the CIC:TG relationship is not > > hierarchical and thus a > > TG could have multiple carriers associated with it. That > > holds true if > > circuits are shared across carriers and the originating user is not > > affected by this business arrangement (i.e. charged for the next-hop > > facilities used to reach the desired carrier). > > > > Question 1: If 2 carriers were reach able over the same T-3, > > with one > > directly reachable and the other indirectly reachable, would > > the gateway > > almost always allocate the one physical facility as 2 logical > > trunk groups > > anyway? (Thus restoring the TG infers CIC mapping.) > > > > We already know that any switch in the PSTN can reach any > > other. The real > > question is how to route such that the PSTN path is minimized at the > > expense of a more direct IP path (assumes that is the least cost > > path). The use of TG data should be of local significance > > only at the > > egress of the IP network. > > > > I agree with your call for some type of geographic attribute. > > But, I don't > > understand your final statement. I don't want to see > > carrier's charges on > > my bill, if as the caller I specify a particular long-distance or > > international carrier. Also, will the CIC always be based on > > national body > > registration, or will IANA or someone ever assign > > international CIC codes > > for global carriers? > > > > Mike > > > > > > At 05:37 AM 12/31/2001 -0600, Peterson, Jon wrote: > > > > >I wanted to speak a bit to the issue from the minutes below > > regarding the > > >ubiquitous availability of carriers through trunks in the > > PSTN, and the > > >relevance of the 'equal access' concept - especially since > > this a matter on > > >which Dave and I have differed for some time. > > > > > >There are a number of ways (thanks to equal access > > provisions) that a user > > >can directly or indirectly select a carrier, for example: > > > > > >- Having an entry in the LIDB for their address > > corresponding to the Carrier > > >Identification Code of their chosen carrier, so that > > inter-exchange calls > > >generated from their address always pick up this CIC (i.e. PIC LD). > > > > > >- Using a dial-around (101+XXX+address) to override the > > default CIC for > > >their line. > > > > > >- Dialing a freephone number whose SMS/800 dip returns a CIC code - > > >presumably once the call has been routed to the > > administrative domain of the > > >carrier, a further internal dip will be performed to > > translate the freephone > > >number into a geographic number. > > > > > >Dave is certainly correct that a CIC does not necessarily > > correspond to some > > >physical network - that is, the concept of a 'carrier' > > chosen by a user is > > >largely a matter of who issues your bill, not what physical > > infrastructure > > >your call crosses. For example, there are resellers of > > long-distance service > > >whose CICs are really just aliases for the CIC of a major > > carrier. Large > > >carriers may own several CICs they use to target their services. It's > > >certainly not some kind of one-to-one mapping from CICs to physical > > >infrastructure. > > > > > >HOWEVER, this doesn't mean that a decision isn't made, in > > some places in the > > >telephone network, about how a call is routed based on the > > CIC. In SS7, when > > >a CIC has been selected for a call, it is carried within the TNS or > > >(ANSIfied) CIC parameter of the Initial Address Message. The > > presence of > > >this parameter modifies how a call is routed through the > > telephone network, > > >especially at tandems. > > > > > >So, to bring this matter back to trunk groups, one view > > might be that a > > >given trunk group may be considered to be a route to a CIC > > if, when an SS7 > > >IAM message carrying this CIC is sent over the trunk group, > > this call will > > >(eventually) be routed to the administrative domain > > responsible for the CIC > > >(and presumably get delivered appropriately). One might > > contend, as an > > >opposing position, that only the carrier that owns the > > switch on the far > > >side of the trunk should be considered to be reachable > > through a trunk - but > > >I suspect that in an overflow situation most network would > > be content to > > >send calls for some other carrier through such a trunk > > group, even if it > > >introduced a middle-man network, complicating routing and potentially > > >settlement. > > > > > >The correct position is probably somewhere in the middle. > > One or more CICs > > >may be 'preferred' for a particular trunk by some switch in > > the network, > > >largely because of who happens to own the equipment on the > > other side, but > > >in addition all CICs are usually 'available' through such > > trunks. Something > > >similar, I think, is true of E.164 numbers; certain ranges > > may be preferred > > >(due to settlement concerns) for particular trunk groups, > > but all number > > >ranges are usually available. > > > > > >Finally, it's important to note that CICs are national in > > scope, and that > > >therefore trunk groups are most likely only routes to the > > set of CICs within > > >a particular nationality. There have been suggestions in the > > past that > > >identifiers for CICs in the gw reg mechanism should be > > concatenated with > > >some sort of country code to provide a scope of a CIC - I > > would agree that > > >this is probably necessary. Then we could refine our > > characterization of > > >trunk group CIC routes to one in which all carriers for a > > given nationality > > >could be 'available' through a trunk group. > > > > > >Jon Peterson > > >NeuStar, Inc. > > > > > > > Further discussion: > > > > > > > > Jon said that he believes this should always be about TGs > > - believes > > > > should treat PRI as a trunk. Cullen asked whether there > > would ever be > > > > more than one carrier on a single trunk? Jon said that there are a > > > > number of carriers for virtually every trunk. Due to EA. > > Dave Oran > > > > responded that this has nothing to do with it, as the EA > > concept user > > > > experience doesn't necessarily relate. Take it to the list. > > > > > > > >_______________________________________________ > > >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 Thu Jan 3 19:50:17 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 TAA14350 for ; Thu, 3 Jan 2002 19:50:17 -0500 (EST) 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 g040X3o30480; Thu, 3 Jan 2002 19:33:03 -0500 Received: from imo-m04.mx.aol.com (imo-m04.mx.aol.com [64.12.136.7]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g040Wjo30467 for ; Thu, 3 Jan 2002 19:32:45 -0500 Received: from JustMeUnOr@aol.com by imo-m04.mx.aol.com (mail_out_v31_r1.9.) id c.7e.2085859b (1320); Thu, 3 Jan 2002 19:32:31 -0500 (EST) From: JustMeUnOr@aol.com Message-ID: <7e.2085859b.2966521e@aol.com> Subject: Re: [IPTEL] draft meeting minutes To: mhammer@cisco.com, jon.peterson@neustar.biz, iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_7e.2085859b.2966521e_boundary" X-Mailer: AOL 6.0 for Windows US sub 10552 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, 3 Jan 2002 19:32:30 EST --part1_7e.2085859b.2966521e_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Maybe Im a little old fashioned in some of my beliefs, but... (Comments inline) mhammer@cisco.com writes: > > Yes, I think our perspectives are consistent. What I have a problem with > is getting wrapped around the axle with propagating routing information > across the network, that in the end may not provide a useful discriminator > for choosing one route over another. What makes one gateway hop-off point > better than another? > I Realize that routing intelligence in the L/S is what everyone's going for, but all in all, shouldent (In a carrier scenario, at least) the carrier originating the call be able to route it on critera they specify?? (E.G. QoS, E.164, Route costing via TG/Carrier preference, etc.) (-D) > Are we minimizing PSTN (or other) network administrations that we must cross? > Are we minimizing conversion points (RTP to TDM) that may introduce noise? > Can a network capacity re-seller reduce the number of billing relationships? > Someone had once introduced the suggestion that a G/W, or L/S could have the possibility to "Advertise" its going rate, while this sounds pretty viable for retail, this takes away any possibility of autonomous Least Cost Routing via Carrier Wholesale billing arangements/agreements... How would this be solved? (-D) > My starting axiom was that the call was routed into the IP world or started > there for a reason, and that IP was the preferred path to effectively make > all calls local. Your point that the existing CIC codes are inherently > geographical on a large scale also points to the possible need to define > geographic attributes on a smaller scale as well. > > Mike > Thanks, -Darby --part1_7e.2085859b.2966521e_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Maybe Im a little old fashioned in some of my beliefs, but...   (Comments inline)

mhammer@cisco.com writes:

Yes, I think our perspectives are consistent.  What I have a problem with
is getting wrapped around the axle with propagating routing information
across the network, that in the end may not provide a useful discriminator
for choosing one route over another.  What makes one gateway hop-off point
better than another?


I Realize that routing intelligence in the L/S is what everyone's going for, but all in all, shouldent (In a carrier scenario, at least) the carrier originating the call be able to route it on critera they specify??   (E.G. QoS, E.164, Route costing via TG/Carrier preference, etc.)  (-D)


Are we minimizing PSTN (or other) network administrations that we must cross?
Are we minimizing conversion points (RTP to TDM) that may introduce noise?
Can a network capacity re-seller reduce the number of billing relationships?



Someone had once introduced the suggestion that a G/W, or L/S could have the possibility to "Advertise" its going rate, while this sounds pretty viable for retail, this takes away any possibility of autonomous Least Cost Routing via Carrier Wholesale billing arangements/agreements...   How would this be solved? (-D)

My starting axiom was that the call was routed into the IP world or started
there for a reason, and that IP was the preferred path to effectively make
all calls local.  Your point that the existing CIC codes are inherently
geographical on a large scale also points to the possible need to define
geographic attributes on a smaller scale as well.

Mike

Thanks,
-Darby --part1_7e.2085859b.2966521e_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 Jan 3 20: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 UAA14527 for ; Thu, 3 Jan 2002 20:08:24 -0500 (EST) 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 g04172o30762; Thu, 3 Jan 2002 20:07:02 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0416Io30735 for ; Thu, 3 Jan 2002 20:06:18 -0500 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 UAA01290; Thu, 3 Jan 2002 20:06:17 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0416BJ1001901; Thu, 3 Jan 2002 20:06:12 -0500 (EST) Message-ID: <3C350003.FFCCA734@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: brett@broadsoft.com CC: iptel@lists.bell-labs.com Subject: Re: [IPTEL] New draft RFC 2806bis References: <001701c194bb$1e05b410$2b01a8c0@broadsoft.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: Thu, 03 Jan 2002 20:06:11 -0500 Content-Transfer-Encoding: 7bit Brett Tate wrote: > > This is from rfc2396 section 2.4.3: > "The space character is excluded because > significant spaces may disappear and > insignificant spaces may be introduced > when URI are transcribed or typeset or > subjected to the treatment of > word-processing programs. Whitespace is > also used to delimit URI in many contexts." And immediately below in 2.4.3 it says: "Data corresponding to excluded characters must be escaped in order to be properly represented within a URI." This is a common misunderstanding about URLs: Just about any character can appear in a URL, as long as it is escaped. It just can't be used as-is. Space, as is, also couldn't be used as a delimiter between parts of the URL. http://www.example.com/A%20filename%20with%20spaces is a perfectly valid URL. > > The last sentence might be a reason to > exclude spaces. Backwards compatibility > with rfc2806 might be another. > The latter reason is, of course, a concern. If there was a large installed base of non-changeable devices, I would be inclined to agree that this would not be worth the hassle. I have no opinion on this. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jan 3 20:18: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 UAA14616 for ; Thu, 3 Jan 2002 20:18:11 -0500 (EST) 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 g040w2o30657; Thu, 3 Jan 2002 19:58:02 -0500 Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g040vko30644 for ; Thu, 3 Jan 2002 19:57:46 -0500 Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g040viD09728; Thu, 3 Jan 2002 19:57:45 -0500 (EST) Reply-To: From: "Brett Tate" To: "'Henning Schulzrinne'" Cc: Subject: RE: [IPTEL] New draft RFC 2806bis Message-ID: <001701c194bb$1e05b410$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) In-Reply-To: <3C2DA160.677137A7@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal 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, 3 Jan 2002 19:59:51 -0500 Content-Transfer-Encoding: 7bit > I don't think this has been discussed > in the past. I agree with your analysis > - there is no technical reason why %20 > (space) couldn't be allowed as a visual > separator and since visual separators are > exchangeable, there's no reason you'd have > to put tel:+1%20212%20555%1234 on a bus or > business card. (%20 is not uncommon in > mailto and http URLs, as file names commonly > allow spaces and mailto permits headers.) > > In terms of backwards-compatibility: > Implementations MUST understand %-escapes > anywhere. Thus, > > tel:+1%32%31%32-%35%35%35-%31%32%33%34 > (for tel:+1212-555-1234) > > is a perfectly valid URL, albeit a bit unusual. > > Unfortunately, I have only heard from one > tel implementor so far. Since having > space-separators is common in everyday usage of > telephone numbers and E.123 even recommends it, > I'm inclined to allow it barring objections > from implementors. > This is from rfc2396 section 2.4.3: "The space character is excluded because significant spaces may disappear and insignificant spaces may be introduced when URI are transcribed or typeset or subjected to the treatment of word-processing programs. Whitespace is also used to delimit URI in many contexts." The last sentence might be a reason to exclude spaces. Backwards compatibility with rfc2806 might be another. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jan 4 11:07: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 LAA07156 for ; Fri, 4 Jan 2002 11:07:38 -0500 (EST) 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 g04G5Jo01893; Fri, 4 Jan 2002 11:05:19 -0500 Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g04G4eo01878 for ; Fri, 4 Jan 2002 11:04:40 -0500 Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA15902; Fri, 4 Jan 2002 11:04:34 -0500 (EST) 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 AAH26705; Fri, 4 Jan 2002 11:00:07 -0500 (EST) Message-Id: <4.3.2.7.2.20020104110333.00b24950@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Michael Hammer Subject: Re: [IPTEL] draft meeting minutes Cc: jon.peterson@neustar.biz, iptel@lists.bell-labs.com In-Reply-To: <7e.2085859b.2966521e@aol.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: Fri, 04 Jan 2002 11:10:46 -0500 Darby, I don't think anything I said precludes a carrier from making the routing decision based on their defined policy. Rather, I am saying that such decisions must be made based on the availability of meaningful data. If the data is not available locally at the originating routing point or available, but not very meaningful (i.e. all GWs can reach all carriers), then that negatively affects the ability to make those decisions. So, if you have criteria, but no data to match those criteria, then the data contained in the TRIP reporting is deficient. Mike At 07:32 PM 1/3/2002 -0500, JustMeUnOr@aol.com wrote: >Maybe Im a little old fashioned in some of my beliefs, but... (Comments >inline) > >mhammer@cisco.com writes: >> >>Yes, I think our perspectives are consistent. What I have a problem with >>is getting wrapped around the axle with propagating routing information >>across the network, that in the end may not provide a useful discriminator >>for choosing one route over another. What makes one gateway hop-off point >>better than another? > > >I Realize that routing intelligence in the L/S is what everyone's going >for, but all in all, shouldent (In a carrier scenario, at least) the >carrier originating the call be able to route it on critera they >specify?? (E.G. QoS, E.164, Route costing via TG/Carrier preference, >etc.) (-D) > > >>Are we minimizing PSTN (or other) network administrations that we must >>cross? >>Are we minimizing conversion points (RTP to TDM) that may introduce noise? >>Can a network capacity re-seller reduce the number of billing relationships? > > > >Someone had once introduced the suggestion that a G/W, or L/S could have >the possibility to "Advertise" its going rate, while this sounds pretty >viable for retail, this takes away any possibility of autonomous Least >Cost Routing via Carrier Wholesale billing arangements/agreements... How >would this be solved? (-D) > >>My starting axiom was that the call was routed into the IP world or started >>there for a reason, and that IP was the preferred path to effectively make >>all calls local. Your point that the existing CIC codes are inherently >>geographical on a large scale also points to the possible need to define >>geographic attributes on a smaller scale as well. >> >>Mike > >Thanks, >-Darby _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jan 4 12:18:50 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 MAA08886 for ; Fri, 4 Jan 2002 12:18:50 -0500 (EST) 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 g04H0Ho02196; Fri, 4 Jan 2002 12:00:17 -0500 Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g04Gx8o02169 for ; Fri, 4 Jan 2002 11:59:08 -0500 Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id g04GwMP13769; Fri, 4 Jan 2002 11:58:22 -0500 Message-Id: <5.1.0.14.2.20020104112448.0318bbc0@mail.pingtel.com> X-Sender: jbatson@mail.pingtel.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: JustMeUnOr@aol.com, mhammer@cisco.com, jon.peterson@neustar.biz, iptel@lists.bell-labs.com From: Jay Batson Subject: Re: [IPTEL] draft meeting minutes In-Reply-To: <7e.2085859b.2966521e@aol.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1269538589==_.ALT" 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, 04 Jan 2002 11:56:03 -0500 --=====================_1269538589==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:32 PM 1/3/02, JustMeUnOr@aol.com wrote: >mhammer@cisco.com writes: >>Yes, I think our perspectives are consistent. What I have a problem with >>is getting wrapped around the axle with propagating routing information >>across the network, that in the end may not provide a useful discriminator >>for choosing one route over another. What makes one gateway hop-off point >>better than another? >I Realize that routing intelligence in the L/S is what everyone's going >for, but all in all, shouldent (In a carrier scenario, at least) the >carrier originating the call be able to route it on critera they >specify?? (E.G. QoS, E.164, Route costing via TG/Carrier preference, >etc.) (-D) I assume you're *not* talking about the "routing" of the actual IP packets, but instead are talking about the forwarding of signalling information between IP network-attached servers or elements of some kind ... right? Because, of course, you *can't* (nor can you expect) to ask for packet routing preferences across IP networks. The guys who work on BGP and other packet routing protocols across the network aren't going to pay much attention to such requests, methinks.... Of course, I'm a total non-participant in all this, and could be completely missing the point here (e.g. maybe you're talking about routing in the PSTN and I'm just missing it). If so, my apologies for my lame comments. I just can't seem to avoid posting things to lists I'm totally unqualified to comment on. (The old software engineer in this exec just won't die no matter how hard I try.... ;-) -jb ---------- Jay Batson Pingtel Corp. jbatson@pingtel.com 781-938-5306 (office) 781-938-9650 (fax) --=====================_1269538589==_.ALT Content-Type: text/html; charset="us-ascii" At 07:32 PM 1/3/02, JustMeUnOr@aol.com wrote:
mhammer@cisco.com writes:
Yes, I think our perspectives are consistent.  What I have a problem with
is getting wrapped around the axle with propagating routing information
across the network, that in the end may not provide a useful discriminator
for choosing one route over another.  What makes one gateway hop-off point
better than another?
I Realize that routing intelligence in the L/S is what everyone's going for, but all in all, shouldent (In a carrier scenario, at least) the carrier originating the call be able to route it on critera they specify??   (E.G. QoS, E.164, Route costing via TG/Carrier preference, etc.)  (-D)

I assume you're *not* talking about the "routing" of the actual IP packets, but instead are talking about the forwarding of signalling information between IP network-attached servers or elements of some kind ... right?  Because, of course, you *can't* (nor can you expect) to ask for packet routing preferences across IP networks.  The guys who work on BGP and other packet routing protocols across the network aren't going to pay much attention to such requests, methinks....

Of course, I'm a total non-participant in all this, and could be completely missing the point here (e.g. maybe you're talking about routing in the PSTN and I'm just missing it).  If so, my apologies for my lame comments.  I just can't seem to avoid posting things to lists I'm totally unqualified to comment on.  (The old software engineer in this exec just won't die no matter how hard I try.... ;-)

-jb

----------
Jay Batson
Pingtel Corp.
jbatson@pingtel.com

781-938-5306 (office)
781-938-9650 (fax)
--=====================_1269538589==_.ALT-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jan 4 12:26: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 MAA09070 for ; Fri, 4 Jan 2002 12:26:55 -0500 (EST) 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 g04HA8o02308; Fri, 4 Jan 2002 12:10:08 -0500 Received: from imo-r09.mx.aol.com (imo-r09.mx.aol.com [152.163.225.105]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g04H0Co02187 for ; Fri, 4 Jan 2002 12:00:12 -0500 Received: from Mpierce1@aol.com by imo-r09.mx.aol.com (mail_out_v31_r1.9.) id g.4e.4689ac0 (4397); Fri, 4 Jan 2002 12:00:03 -0500 (EST) From: Mpierce1@aol.com Message-ID: <4e.4689ac0.29673993@aol.com> Subject: Re: [IPTEL] Definition of "trunk group" To: jon.peterson@neustar.biz, iptel@lists.bell-labs.com, mhammer@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 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, 4 Jan 2002 12:00:03 EST Content-Transfer-Encoding: 7bit In a message dated 1/3/02 2:43:27 AM Eastern Standard Time, jon.peterson@neustar.biz writes: > I agree with your definition of a trunk group; we arrived at a similar one > on the mailing list earlier (i.e. roughly, a bundle of DS0's between two > PSTN network entities that are grouped under some kind of common policy). > > (snip) > > The question of whether the 'route list' model gives us still more leverage > than the 'trunk group' model is interesting; 'route list' certainly provides > an even greater level of abstraction. Without going through a lot of > semantic hair-splitting, I think that trunk groups provide just the right > layer of abstraction. The question here is "What entities should the gwreg > system provide the availability of?" I think trunk groups have state that > changes dynamically, and that these states in turn determine the > availability of network resources. A proxy server that receives > registrations for such trunk groups would construct the 'route list,' as it > were, of alternative trunk groups that meet the routing criteria of calls. I > don't think a system in which 'route lists' were published to proxy servers > through the gateway registration process would grant us much additional > leverage on network design - in fact, I suspect it would just push the > problems around a bit. > > Jon Peterson > NeuStar, Inc > Jon, Although you said above that you agree with my definition of "Trunk Group" (copied from T1.523), your reply to Mike Hammer the same day still indicates that you have a very much different concept of what a "trunk group" is and how it is used in routing calls to specific carriers (based on the CIC). Mike Hammer's e-mail correctly described the routing. Interpretation of the CIC (or any other digits dialed) results in a pointer to a trunk group. Obviously, multiple CICs can point to the same trunk group, and, with alternate routing, each CIC can point to multiple trunks groups (in an ordered list defined as a "route list"). I guess this is what you mean by saying that this relationship is not "hierarchical". I would say it's not one-to-one or one-to-many, but rather many-to-many. In telephony routing "hierarchical" has had a different meaning. It confuses the issue to describe trunk groups in terms of what CICs (or E.164 number ranges) they can reach, which is what your comments still do. Further, your statement that "One or more CICs may be 'preferred' for a particular trunk [group] by some switch ..." does not correctly represent the dialed digit interpretation/alternate routing that takes place. I'm further confused by the references to "logical trunk groups" and what significance this has. It is possible for an implemenation to further subdivide actual (physical) trunk groups into some "logical" sub-grouping, for example, to help it prevent glare on two-way trunks, but I don't think this is an important concept to include in these discussions. Does "logical trunk group" have some additional meaning or significance? Regarding your comment on "whether the 'route list' model gives us still more leverage than the 'trunk group' model" --- the "trunk group" concept is fundamental to all descriptions of routing, since it represents the actual physical facilities (sometimes DS0s as you noted) between real network elements. The "route list" concept, on the other hand, represents the internal workings of a switch and does not impact the signaling between switches, so is less important. However, it is a useful concept and definition since it helps to have a common concept of how telephone calls are routed (what I call "alternate routing"). Mike Pierce Artel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jan 4 18:09: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 SAA15833 for ; Fri, 4 Jan 2002 18:09:02 -0500 (EST) 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 g04Mh4o03905; Fri, 4 Jan 2002 17:43:04 -0500 Received: from mail.tiscalinet.it (mail-2.tiscalinet.it [195.130.225.148]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g04Mgho03885 for ; Fri, 4 Jan 2002 17:42:43 -0500 Received: from cori1 (62.11.17.27) by mail.tiscalinet.it (5.5.053) id 3C335E07000B9904 for IPTEL@lists.bell-labs.com; Fri, 4 Jan 2002 23:42:40 +0100 Message-ID: <006101c19571$ee36dae0$58a4cdc1@cori1> From: "giuseppe de marco" To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_005D_01C1957A.4F536A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] I: FSM for ITRP 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, 4 Jan 2002 23:48:29 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_005D_01C1957A.4F536A20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_005E_01C1957A.4F536A20" ------=_NextPart_001_005E_01C1957A.4F536A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: giuseppe de marco=20 To: iptel-request@lists.bell-labs.com=20 Sent: Friday, January 04, 2002 11:04 PM Subject: FSM for ITRP Could anyone analyse my state machine for ITRP protocol? Thank you. Giuseppe De Marco Department of Information and Electrical Engineering (DIIIE) University of Salerno (Italy) phone: +39 089 964012 workingmail: gdemarco@unisa.it personal: inggdm@tiscalinet.it ------=_NextPart_001_005E_01C1957A.4F536A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 
----- Original Message -----=20
From: giuseppe de = marco=20
Sent: Friday, January 04, 2002 11:04 PM
Subject: FSM for ITRP

Could anyone analyse my state machine = for ITRP=20 protocol?
Thank you.
 
 
Giuseppe De Marco
Department of = Information and=20 Electrical Engineering (DIIIE)
University of Salerno = (Italy)
 
phone: +39 089 964012
workingmail: = gdemarco@unisa.it
personal: = ;    =20 inggdm@tiscalinet.it ------=_NextPart_001_005E_01C1957A.4F536A20-- ------=_NextPart_000_005D_01C1957A.4F536A20 Content-Type: application/msword; name="grafoitrp.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="grafoitrp.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJgAAAAAAAAAA EAAAKAAAAAEAAAD+////AAAAACUAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAOSAQBAAA8BK/AAAAAAAAEAAAAAAABAAAvQQAAA4AYmpiav3P/c8AAAAAAAAAAAAAAAAAAAAA AAAQBBYALg4AAJ+lAACfpQAAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnwAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAALwAAAAAAAAAvAAAALwA AAAAAAAAvAAAAAAAAAAEAwAAAAAAAAQDAAAAAAAABAMAABQAAAAAAAAAAAAAADgDAAAAAAAAPgYA AAAAAAA+BgAAAAAAAD4GAAAAAAAAPgYAAAwAAABKBgAAFAAAADgDAAAAAAAA3hYAALYAAABqBgAA AAAAAGoGAAAAAAAAagYAAAAAAABqBgAAAAAAAGoGAAAAAAAAWRUAAAAAAABZFQAAAAAAAFkVAAAA AAAAXRYAAAIAAABfFgAAAAAAAF8WAAAAAAAAXxYAAAAAAABfFgAAAAAAAF8WAAAAAAAAXxYAACQA AACUFwAAIAIAALQZAABGAAAAgxYAABUAAAAAAAAAAAAAAAAAAAAAAAAABAMAAAAAAABZFQAAAAAA AAAAAAAAAAAAAAAAAAAAAAANEgAATAMAAFkVAAAAAAAAWRUAAAAAAABZFQAAAAAAAIMWAAAAAAAA XRYAAAAAAAC8AAAAAAAAALwAAAAAAAAAagYAAAAAAAAAAAAAAAAAAGoGAACjCwAAmBYAABYAAABd FgAAAAAAAF0WAAAAAAAAXRYAAAAAAABZFQAAQAAAALwAAACkAQAAagYAAAAAAAAEAwAAAAAAAGoG AAAAAAAAXRYAAAAAAAAAAAAAAAAAAF0WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWRUAAAAAAABdFgAAAAAAAF0WAAAAAAAAXRYAAAAAAAAAAAAA AAAAAF0WAAAAAAAAYAIAAKQAAAAEAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXRYAAAAAAABqBgAAAAAAAF4GAAAMAAAAgNXiVjuV wQE4AwAABgMAAD4GAAAAAAAAmRUAAAAAAABdFgAAAAAAAAAAAAAAAAAAXRYAAAAAAACuFgAAMAAA AN4WAAAAAAAAXRYAAAAAAAD6GQAAAAAAAJkVAADEAAAA+hkAAAAAAABdFgAAAAAAAF0WAAAAAAAA GAMAABIAAAAqAwAADgAAALwAAAAAAAAAvAAAAAAAAAC8AAAAAAAAALwAAAAAAAAAAgDZAAAACAgI CAgICAgICAgICAgICAgICAgICAgICAgICA0NV2FpdC1HVw0NDSBJRExFDQ0NIFdhaXQtU0lQDQ0N IERFQw0NRElTQ09WRVINDURJU0NPVkVSDQ1SRUdJU1RFUg0NVGltZS1PdXQNDVJFSi9DRlJNDQ0o RGUpLVJFR0lTVEVSDQ1SRUpFQ1QNDUNPTkZJUk0NDURJU0NPVkVSDQ1DT05GSVJNDQ1LRUVQLUFM SVZFLCBVUERBVEUNDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA HAQAAB0EAAAmBAAAJwQAAC4EAAAvBAAAOgQAADsEAABBBAAAQgQAAEsEAABMBAAAVQQAAFYEAABf BAAAYAQAAGkEAABqBAAAcwQAAHQEAACCBAAAgwQAAIoEAACLBAAAkwQAAJQEAACdBAAAngQAAKYE AACnBAAAugQAAL0EAADzAOoA6gDqAOoA4QDhAOEA4QDhAOEA4QDhAOEA4QDqAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQ0oQAE9KAgBR SgIAXkoCAAAQQ0oOAE9KAgBRSgIAXkoCAAAYA2oAAAAAQ0oUAFUIAW1IAARuSAAEdQgBIAAEAAAd BAAAHgQAACYEAAAnBAAAKAQAAC4EAAAvBAAAMAQAADoEAAA7BAAAPAQAAEEEAABCBAAASwQAAEwE AABVBAAAVgQAAF8EAABgBAAAaQQAAGoEAABzBAAAdAQAAIIEAACDBAAAigQAAIsEAACTBAAAlAQA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAdAAQAAB0E AAC8BAAA/f0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQKUBAAAnQQA AJ4EAACmBAAApwQAALoEAAC7BAAAvAQAAL0EAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAACCwAMZBoAR+w gi4gsMZBIbBuBCKwbgQjkIkFJJBuBCWwAAAXsMQCGLDEAgyQxAIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAPAAoAAQBp AA8AAwAAAAAAAAAAADoAAEDx/wIAOgAMAAcATgBvAHIAbQBhAGwAZQAAAAIAAAAYAENKGABfSAEE YUoYAG1IEARzSBAEdEgQBAAAAAAAAAAAAAAAAAAAAAAAAE4AQUDy/6EATgAMAB8AQwBhAHIAYQB0 AHQAZQByAGUAIABwAHIAZQBkAGUAZgBpAG4AaQB0AG8AIABwAGEAcgBhAGcAcgBhAGYAbwAAAAAA AAAAAAAAAAAAAAAACgAAABIAAAAeAAAAJQAAAC8AAAA5AAAAQwAAAE0AAABXAAAAZgAAAG4AAAB3 AAAAgQAAAIoAAACeAAAAvQAAAAEAAAAAAAAAAAD/////AgQAAAAAAAABAAAAAAAAAAAA/////wME AAAAAAAAAQAAAAAAAAAAAP////8EBAAAAAAAAAEAAAAAAAAAAAD/////BQQAAAAAAAABAAAAAAAA AAAA/////w4EAAAAAAAAAQAAAAAAAAAAAP////8PBAAAAAAAAAEAAAAAAAAAAAD/////EQQAAAAA AAABAAAAAAAAAAAA/////xMEAAAAAAAAAQAAAAAAAAAAAP////8UBAAAAAAAAAEAAAAAAAAAAAD/ ////FQQAAAAAAAABAAAAAAAAAAAA/////xcEAAAAAAAAAQAAAAAAAAAAAP////8YBAAAAAAAAAEA AAAAAAAAAAD/////HAQAAAAAAAABAAAAAAAAAAAA/////x0EAAAAAAAAAQAAAAAAAAAAAP////8f BAAAAAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAABIAAAAeAAAAJQAAAC8AAAA5AAAA QwAAAE0AAABXAAAAZgAAAG4AAAB3AAAAgQAAAIoAAACeAAAAoQAAAAAAAAAAAAEAAAAAAAIAAAAA AAMAAAAAAAQAAAAAAAUAAAAAAAYAAAAAAAcAAAAAAAgAAAAAAAkAAAAAAAoAAAAAAAsAAAAAAAwA AAAAAA0AAAAAAA4AAAAAAP//AAAAAAAAAAC9AAAABQAADgAABwD/////AQAAAAQg//8BACImowAA AAAAAAAAAL0AAAAAAAAAAAAAAAAAHQAAAB4AAAAmAAAAJwAAACgAAAAuAAAALwAAADAAAAA6AAAA OwAAADwAAABBAAAAQgAAAEsAAABMAAAAVQAAAFYAAABfAAAAYAAAAGkAAABqAAAAcwAAAHQAAACC AAAAgwAAAIoAAACLAAAAkwAAAJQAAACdAAAAngAAAKYAAACnAAAAugAAAL4AAACYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICaQAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICaAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICaAAAAADAAAAAAAAAAgAAAAIAABAAAvQQA AAMAAAAABAAAlAQAAL0EAAAEAAAABgAAAAAEAAC8BAAABQAAAA8AAPA4AAAAAAAG8BgAAAAgBAAA AgAAAB8AAAABAAAAAQAAACAAAABAAB7xEAAAAP//AAD/////gICAAPcAABAADwAC8FoLAAAQAAjw CAAAAB0AAAAfBAAADwAD8PgKAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAI AAAAAAQAAAUAAAAPAATwSAAAAKIMCvAIAAAAHQQAAAAKAAAjAAvwDAAAAIAAAAAOAP8BAAAIAAAA EPAEAAAAAgAAAAAAEfAEAAAABQAAAAAADfAEAAAAAAAOAA8ABPBIAAAAogwK8AgAAAAcBAAAAAoA ACMAC/AMAAAAgAAAAA0A/wEAAAgAAAAQ8AQAAAAXAAAAAAAR8AQAAAAJAAAAAAAN8AQAAAAAAA0A DwAE8EgAAACiDArwCAAAABcEAAAACgAAIwAL8AwAAACAAAAACwD/AQAACAAAABDwBAAAAAMAAAAA ABHwBAAAAA0AAAAAAA3wBAAAAAAACwAPAATwSAAAAKIMCvAIAAAAFQQAAAAKAAAjAAvwDAAAAIAA AAAKAP8BAAAIAAAAEPAEAAAABQAAAAAAEfAEAAAADwAAAAAADfAEAAAAAAAKAA8ABPBIAAAAogwK 8AgAAAATBAAAAAoAACMAC/AMAAAAgAAAAAgA/wEAAAgAAAAQ8AQAAAAHAAAAAAAR8AQAAAAKAAAA AAAN8AQAAAAAAAgADwAE8FoAAAAyAArwCAAAAAIEAAAACgAAUwAL8B4AAACAAAAAAQCBAAAAAACC AAAAAACDAAAAAACEAAAAAAAAABDwBAAAABUAAAAAABHwBAAAAA4AAAAAAA3wBAAAAAAAAQAPAATw WgAAADIACvAIAAAAAwQAAAAKAABTAAvwHgAAAIAAAAACAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA AAAAEPAEAAAAFAAAAAAAEfAEAAAADAAAAAAADfAEAAAAAAACAA8ABPBaAAAAMgAK8AgAAAAEBAAA AAoAAFMAC/AeAAAAgAAAAAMAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAAAAQ8AQAAAATAAAAAAAR 8AQAAAAMAAAAAAAN8AQAAAAAAAMADwAE8FoAAAAyAArwCAAAAAUEAAAACgAAUwAL8B4AAACAAAAA BACBAAAAAACCAAAAAACDAAAAAACEAAAAAAAAABDwBAAAABYAAAAAABHwBAAAAAwAAAAAAA3wBAAA AAAABAAPAATwTgAAAEIBCvAIAAAABgQAAAAKAABTAAvwHgAAAEQBBAAAAH8BAAABAL8BAAAQANEB AQAAAP8BEAAQAAAAEPAEAAAAEgAAAAAAEfAEAAAACAAAAA8ABPBOAAAAQgEK8AgAAAAHBAAAQAoA AFMAC/AeAAAARAEEAAAAfwEAAAEAvwEAABAA0QEBAAAA/wEQABAAAAAQ8AQAAAARAAAAAAAR8AQA AAAIAAAADwAE8E4AAABCAQrwCAAAAAgEAACACgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAAEADR AQEAAAD/ARAAEAAAABDwBAAAABAAAAAAABHwBAAAAAgAAAAPAATwTgAAAEIBCvAIAAAACQQAAAAK AABTAAvwHgAAAEQBBAAAAH8BAAABAL8BAAAQANEBAQAAAP8BEAAQAAAAEPAEAAAADwAAAAAAEfAE AAAACAAAAA8ABPBOAAAAQgEK8AgAAAAKBAAAQAoAAFMAC/AeAAAARAEEAAAAfwEAAAEAvwEAABAA 0QEBAAAA/wEQABAAAAAQ8AQAAAAOAAAAAAAR8AQAAAAIAAAADwAE8E4AAABCAQrwCAAAAAsEAAAA CgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAAEADRAQEAAAD/ARAAEAAAABDwBAAAAA0AAAAAABHw BAAAAAoAAAAPAATwSAAAAEIBCvAIAAAADAQAAEAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQ AP8BEAAQAAAAEPAEAAAADAAAAAAAEfAEAAAACAAAAA8ABPBIAAAAQgEK8AgAAAANBAAAAAoAAEMA C/AYAAAARAEEAAAAfwEAAAEAvwEAABAA/wEQABAAAAAQ8AQAAAALAAAAAAAR8AQAAAAIAAAADwAE 8EgAAACiDArwCAAAAA4EAAAACgAAIwAL8AwAAACAAAAABQD/AQAACAAAABDwBAAAAAoAAAAAABHw BAAAAAoAAAAAAA3wBAAAAAAABQAPAATwSAAAAKIMCvAIAAAADwQAAAAKAAAjAAvwDAAAAIAAAAAG AP8BAAAIAAAAEPAEAAAACQAAAAAAEfAEAAAACQAAAAAADfAEAAAAAAAGAA8ABPBIAAAAogwK8AgA AAARBAAAAAoAACMAC/AMAAAAgAAAAAcA/wEAAAgAAAAQ8AQAAAAaAAAAAAAR8AQAAAAKAAAAAAAN 8AQAAAAAAAcADwAE8E4AAABCAQrwCAAAABIEAABACgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAA EADRAQEAAAD/ARAAEAAAABDwBAAAAAgAAAAAABHwBAAAAAkAAAAPAATwSAAAAKIMCvAIAAAAFAQA AAAKAAAjAAvwDAAAAIAAAAAJAP8BAAAIAAAAEPAEAAAABgAAAAAAEfAEAAAACgAAAAAADfAEAAAA AAAJAA8ABPBOAAAAQgEK8AgAAAAWBAAAAAoAAFMAC/AeAAAARAEEAAAAfwEAAAEAvwEAABAA0QEB AAAA/wEQABAAAAAQ8AQAAAAEAAAAAAAR8AQAAAAJAAAADwAE8EgAAACiDArwCAAAABgEAAAACgAA IwAL8AwAAACAAAAADAD/AQAACAAAABDwBAAAABsAAAAAABHwBAAAAAoAAAAAAA3wBAAAAAAADAAP AATw0gAAAAIACvAIAAAAGgQAAAAKAADDAAvwjgAAAEIBOgIAAEMBOgIAAEQBBAAAAEXBKAAAAEbB GAAAAH8BAQABAL8BAAAQANABAAAAANEBAQAAANQBAQAAANUBAQAAAP8BGAAYAAoACgDw/wAAhgEt AOEAWgA8ALQAHgAOAQAA/gF4ABwC0gA6AiwB0QGzAWgBOgIJAAwAAgAAQACtASAArQEgAK0BIACs AIAjACLxDAAAAI8DAAAAAJEDAAAAAAAAEPAEAAAAGQAAAAAAEfAEAAAACAAAAA8ABPDYAAAAAgAK 8AgAAAAbBAAAQAoAANMAC/CUAAAAQgE6AgAAQwE6AgAARAEEAAAARcEoAAAARsEYAAAAfwEBAAEA vwEAABAA0AEAAAAA0QEBAAAA1AEBAAAA1QEBAAAA/wEYABgAiAMAAAAACgAKAPD/AACGAS0A4QBa ADwAtAAeAA4BAAD+AXgAHALSADoCLAHRAbMBaAE6AgkADAACAABAAK0BIACtASAArQEgAKwAgCMA IvEMAAAAjwMAAAAAkQMAAAAAAAAQ8AQAAAAYAAAAAAAR8AQAAAAOAAAADwAE8L4AAAACAArwCAAA AB4EAAAACgAAwwAL8I4AAABCAeABAABDAaQBAABEAQQAAABFwSgAAABGwRgAAAB/AQEAAQC/AQAA EADQAQAAAADRAQEAAADUAQEAAADVAQEAAAD/ARgAGAAKAAoA8P88AKQBHgAOAQAAeAA8ADwAeAAA AGgBAACkATwA4AF4AMIBDgGkAaQBCQAMAAIAAEAArQEgAK0BIACtASAArACAAAAQ8AQAAAABAAAA AAAR8AQAAAABAAAADwAE8EgAAACiDArwCAAAAB8EAAAACgAAIwAL8AwAAACAAAAADwD/AQAACAAA ABDwBAAAAAAAAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAADwAPAATwQgAAABIACvAIAAAAAQQAAAAO AABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAAAAAAAB AAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAC9AAAAHwQA AHAIAAB8/P//eA8AAOT9//90AAAAAAAeBAAABAsAAFz+///kDAAAAAAAAHQAAAAAAB0EAADk/f// TP///9ACAAC0AAAAdAAAAAAAFwQAAFQGAAC0AAAAjAoAABwCAAB0AAAAAAAWBAAAoAUAABwCAACM CgAAHAIAAHQAAAAAABUEAACoDAAAOAQAAPwSAACgBQAAdAAAAAAAFAQAAFQGAACEAwAAQAsAAOwE AAB0AAAAAAATBAAAEA4AABwCAAD8EgAAhAMAAHQAAAAAABIEAABcDQAAHAIAAEgSAAAcAgAAdAAA AAAADwQAAFQGAADk/f//QAsAAEz///90AAAAAAAOBAAAXA0AAOT9//9IEgAATP///3QAAAAAAA0E AAA4BAAA0AIAALwHAAAkCQAAdAAAAAAADAQAACwQAADQAgAAsBMAACQJAAB0AAAAAAALBAAAvAcA ACQJAACMCgAAJAkAAHQAAAAAAAoEAABcDQAAJAkAACwQAAAkCQAAdAAAAAAACQQAAKgMAADQAgAA qAwAALwHAAB0AAAAAAAIBAAAQAsAANACAABACwAAvAcAAHQAAAAAAAcEAADsBAAAAAAAAEALAAAA AAAAdAAAAAAABgQAAKgMAAAAAAAA/BIAAAAAAAB0AAAAAAAEBAAASBIAAAAAAAAYFQAA0AIAAHQA AAAAAAMEAACMCgAAAAAAAFwNAADQAgAAdAAAAAAAAgQAANACAAAAAAAAoAUAANACAAB0AAAAAAAF BAAAjAoAALwHAABcDQAAjAoAAHQAAAAAABwEAADMFQAATP///7gaAAC0AAAAdAAAAAAAGwQAAP4B AAB6/v//OAQAALQAAAB0AAAAAAAaBAAAsBMAAHr+///qFQAAtAAAAHQAAAAAABEEAABIEgAAvAcA ADQXAAAkCQAAdAAAAAAAGAQAAGgBAAC8BwAAVAYAACQJAAB0AAAAAAAAAAAAHQAAAB4AAAAlAAAA MQAAADkAAAB4AAAAgQAAAKcAAACxAAAAvgAAAAcABwAcAAcAHAAHABwABwAcAAcAAAAAAB0AAAAe AAAAJQAAACgAAAAtAAAAMAAAADkAAAA8AAAAQAAAAEIAAABKAAAATAAAAFQAAABWAAAAXgAAAGAA AABoAAAAagAAAHIAAAB0AAAAgQAAAIMAAACJAAAAiwAAAJIAAACUAAAAnAAAAJ4AAAClAAAApwAA ALkAAAC+AAAABwAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAUABwAFAAcABQAHAP9AA4ABAAAAAAAAAAAAmM34AAEAAAAAAAAAAAAAAAAAAAAAAAAAAhAA AAAAAAAAvQAAAFAAAAgAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD/ /wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAMAAABHFpABAAACAgYDBQQFAgMEhzoAAAAA AAAAAAAAAAAAAP8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAF BQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYE AgICAgIEhzoAAAAAAAAAAAAAAAAAAP8AAAAAAAAAQQByAGkAYQBsAAAAIgAEAHEIiBgA8MQCAAAb AQAAAABRJGGmUSRhpgAAAAACAAAAAAAAAAAAAAAAAAEAAQAAAAQAAxABAAAAAAAAAAAAAAABAAEA AAABAAAAAAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG4EiQW0ALQAgYEeMAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAARQIAAAAAATKDEQDwEAAIAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP//EgAAAAAAAAAAAAAAAAAAAAcAZwBpAHUAIABnAGkAdQAHAGcAaQB1 ACAAZwBpAHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAA AAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAABkAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAApAAA AAQAAACwAAAABQAAAMAAAAAGAAAAzAAAAAcAAADYAAAACAAAAOgAAAAJAAAA+AAAABIAAAAEAQAA CgAAACABAAAMAAAALAEAAA0AAAA4AQAADgAAAEQBAAAPAAAATAEAABAAAABUAQAAEwAAAFwBAAAC AAAA5AQAAB4AAAABAAAAAABzAB4AAAABAAAAAABzAB4AAAAIAAAAZ2l1IGdpdQAeAAAAAQAAAABp dSAeAAAAAQAAAABpdSAeAAAABwAAAE5vcm1hbAAAHgAAAAgAAABnaXUgZ2l1AB4AAAACAAAAMgB1 IB4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4wAABAAAAAAAAAAAAAAABAAAAAAObfPDuVwQFAAAAA AObfPDuVwQEDAAAAAQAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALV zdWcLhsQk5cIACss+a4wAAAA7AAAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIAAAAAGAAAAiAAA ABEAAACQAAAAFwAAAJgAAAALAAAAoAAAABAAAACoAAAAEwAAALAAAAAWAAAAuAAAAA0AAADAAAAA DAAAAM0AAAACAAAA5AQAAB4AAAAFAAAAbm9uZQAAVGkDAAAAAQAAAAMAAAABAAAAAwAAAAAAAAAD AAAA/AoJAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAABAAAAAAwQAAAC AAAAHgAAAAcAAABUaXRvbG8AAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAD+////CQAAAAoA AAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAA/v///xYAAAAXAAAAGAAA ABkAAAAaAAAAGwAAABwAAAD+////HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAAP7////9//// JwAAAP7////+/////v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABG AAAAAAAAAAAAAAAAgNXiVjuVwQEpAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAD6GQAAAAAAAFcAbwByAGQARABv AGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIB BQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAA AAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAVAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8A cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAB0AAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAQAAAAYAAAD/////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG4AAAAAAAAATwBiAGoAZQBjAHQA UABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAIDV4lY7lcEBgNXiVjuVwQEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhwAAABEb2N1bWVudG8g ZGkgTWljcm9zb2Z0IFdvcmQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_005D_01C1957A.4F536A20-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jan 4 18:10:22 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 SAA15861 for ; Fri, 4 Jan 2002 18:10:22 -0500 (EST) 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 g04Moko03975; Fri, 4 Jan 2002 17:50:46 -0500 Received: from mail.tiscalinet.it (mail-1.tiscalinet.it [195.130.225.147]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g04Mgxo03892 for ; Fri, 4 Jan 2002 17:43:00 -0500 Received: from cori1 (62.11.17.27) by mail.tiscalinet.it (5.5.053) id 3C35BE2E000173C9 for IPTEL@lists.bell-labs.com; Fri, 4 Jan 2002 23:42:51 +0100 Message-ID: <006b01c19571$f68774c0$58a4cdc1@cori1> From: "giuseppe de marco" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C1957A.579C62E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] I: itrp coding 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, 4 Jan 2002 23:48:43 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C1957A.579C62E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: giuseppe de marco=20 To: iptel-request@lists.bell-labs.com=20 Sent: Friday, January 04, 2002 11:01 PM Subject: itrp coding I would implement ITRP using simple text coding. Does it have some mean? Giuseppe De Marco Department of Information and Electrical Engineering (DIIIE) University of Salerno (Italy) phone: +39 089 964012 workingmail: gdemarco@unisa.it personal: inggdm@tiscalinet.it ------=_NextPart_000_0068_01C1957A.579C62E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: giuseppe de = marco=20
Sent: Friday, January 04, 2002 11:01 PM
Subject: itrp coding

I would implement ITRP using simple = text coding.=20 Does it have some mean?
 
Giuseppe De Marco
Department of = Information and=20 Electrical Engineering (DIIIE)
University of Salerno = (Italy)
 
phone: +39 089 964012
workingmail: = gdemarco@unisa.it
personal: = ;    =20 inggdm@tiscalinet.it ------=_NextPart_000_0068_01C1957A.579C62E0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jan 4 18:41: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 SAA16251 for ; Fri, 4 Jan 2002 18:41:15 -0500 (EST) 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 g04NK2o04278; Fri, 4 Jan 2002 18:20:02 -0500 Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g04NJEo04260 for ; Fri, 4 Jan 2002 18:19:14 -0500 Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g04NJBb13880; Fri, 4 Jan 2002 17:19:11 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 17:19:11 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAD7B@va02.va.neustar.com> From: "Peterson, Jon" To: "'Michael Hammer'" Cc: iptel Subject: RE: [IPTEL] draft meeting minutes 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: Fri, 4 Jan 2002 17:19:01 -0600 I certainly think you have a valid concern; there definitely is a relationship between the attributes propagated by the gateway registration protocol and the routing decisions (for call setup signaling) made by the proxies that receive these registrations. TRIP strongly couples the two - in fact, TRIP provides for three major functions: 1) The protocol itself for propagating routes from one point to the next 2) Way of making forwarding decisions for calls based on discriminators propagated in the protocol (TRIBs) 3) Way of deciding what routes you will share with peers By ruling intradomain route propagation outside of the scope of the gw reg deliverable, we've essentially made the third item above out of scope. None of our existing requirements, I think, really address the second problem - nor have we necessarily agreed that this problem is even in the scope of gateway registration. I'd really like to hear people's opinions about that. I definitely agree that discriminators should provide enough data to allow meaningful routing decisions to be made by proxy servers; however, I don't think we should wed discriminators to any particular routing philosophy. I think ideally, the set of discriminators should be flexible enough to enable any of the hop-off philosophies you describe below, depending on the policy of the service provider accepting gateway registrations (a little MAAP, I know). I would be really cautious about any gw reg protocol that seemed to limit the sort of forwarding decisions that might be made within the proxy server. Note that, as I understand it, TRIP builds in some limitations here (like hierarchical discriminators). Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Thursday, January 03, 2002 7:47 AM > To: Peterson, Jon > Cc: iptel > Subject: RE: [IPTEL] draft meeting minutes > > > Yes, I think our perspectives are consistent. What I have a > problem with > is getting wrapped around the axle with propagating routing > information > across the network, that in the end may not provide a useful > discriminator > for choosing one route over another. What makes one gateway > hop-off point > better than another? > > Are we minimizing PSTN (or other) network administrations > that we must cross? > Are we minimizing conversion points (RTP to TDM) that may > introduce noise? > Can a network capacity re-seller reduce the number of billing > relationships? > > My starting axiom was that the call was routed into the IP > world or started > there for a reason, and that IP was the preferred path to > effectively make > all calls local. Your point that the existing CIC codes are > inherently > geographical on a large scale also points to the possible > need to define > geographic attributes on a smaller scale as well. > > Mike > > > At 02:49 AM 1/3/2002 -0600, Peterson, Jon wrote: > > >I don't think we're really disagreeing about much of what > you say below. I > >agree with your account of how things operate in the PSTN. > It sounds like we > >agree that the relationship of CICs to TGs is not in any simple way > >hierarchical. > > > >The primary purpose of my note on the CIC was to suggest a > potential litmus > >test for whether or not a CIC was routable through a TG. I > think that's an > >important definition for us all to agree on if we're going > to consider > >propagating attributes like CICs in the gw reg protocol. > > > >In answer to the question you pose, I think my contention > here is that one > >logical trunk group could have more than one CIC associated > with it. Imagine > >a trivial VoIP network containing one proxy server and one > PSTN gateway in > >which the gateway had a single trunk group aimed at an access tandem. > >Clearly, that trunk group would be the route for all CICs > irrespective of > >whether it was directly or indirectly connected to any given carrier. > >Introduce a second trunk group going to a different access > tandem, and > >perhaps this trunk group would be a better route for some > set of CICs. But > >in neither case would you want to construct, say, one > logical trunk group > >per CIC and overlay them all on the physical trunk(s) - that > would be quite > >an administrative headache. > > > >I'm not sure I necessarily agree that the question with CICs > is "how to > >route such that the PSTN path is minimized at the expense of > a more direct > >IP path", or even that this is necessarily a least-cost > problem. There have > >been significant head-end hop-off vs. tail-end hop-off > arguments with regard > >to CIC routing levied here in the past. Fortunately, I think this is > >ultimately a routing policy question, and really any of > these philosophies > >could be enabled by the CIC propagation systems we're > discussing above. > > > >And, my final statement in my previous mail was intended > only to illustrate > >that CICs are national in scope - that's all. > > > >Jon Peterson > >NeuStar, Inc. > > > > > -----Original Message----- > > > From: Michael Hammer [mailto:mhammer@cisco.com] > > > Sent: Wednesday, January 02, 2002 4:41 PM > > > To: Peterson, Jon > > > Cc: iptel > > > Subject: RE: [IPTEL] draft meeting minutes > > > > > > > > > Jon, > > > > > > Carrier IDs are used as an attribute to affect routing. > > > Carriers have > > > multiple switching points that can be contacted through > some type of > > > signaling address. Within a switching center, there are > > > multiple trunk > > > groups to other switching centers which may belong to the > > > same carrier or > > > different carriers. Choosing a TG from that switching center > > > determines > > > what next switching center the call can be routed to, and by > > > inference, > > > what the next hop carrier will be. Therefore, the carrier ID > > > can determine > > > what TG will be selected from that switching center. > > > > > > The originating side wants to route to a given carrier and > > > location and > > > uses the inferred signaling address. The destination side > > > maps the carrier > > > to an appropriate trunk group to get to that carrier and > > > destination user > > > address. > > > > > > The 101 prefix dialing is just a method of indicating the > > > carrier to use at > > > by the switch terminating the local loop. The fact that the > > > next switching > > > center can reach another carrier through another TG would be > > > irrelevant, if > > > the information was facility-based and not subverted by business > > > arrangements. But, given those business arrangements, > what you are > > > pointing out is that the CIC:TG relationship is not > > > hierarchical and thus a > > > TG could have multiple carriers associated with it. That > > > holds true if > > > circuits are shared across carriers and the originating > user is not > > > affected by this business arrangement (i.e. charged for > the next-hop > > > facilities used to reach the desired carrier). > > > > > > Question 1: If 2 carriers were reach able over the same T-3, > > > with one > > > directly reachable and the other indirectly reachable, would > > > the gateway > > > almost always allocate the one physical facility as 2 logical > > > trunk groups > > > anyway? (Thus restoring the TG infers CIC mapping.) > > > > > > We already know that any switch in the PSTN can reach any > > > other. The real > > > question is how to route such that the PSTN path is > minimized at the > > > expense of a more direct IP path (assumes that is the least cost > > > path). The use of TG data should be of local significance > > > only at the > > > egress of the IP network. > > > > > > I agree with your call for some type of geographic attribute. > > > But, I don't > > > understand your final statement. I don't want to see > > > carrier's charges on > > > my bill, if as the caller I specify a particular long-distance or > > > international carrier. Also, will the CIC always be based on > > > national body > > > registration, or will IANA or someone ever assign > > > international CIC codes > > > for global carriers? > > > > > > Mike > > > > > > > > > At 05:37 AM 12/31/2001 -0600, Peterson, Jon wrote: > > > > > > >I wanted to speak a bit to the issue from the minutes below > > > regarding the > > > >ubiquitous availability of carriers through trunks in the > > > PSTN, and the > > > >relevance of the 'equal access' concept - especially since > > > this a matter on > > > >which Dave and I have differed for some time. > > > > > > > >There are a number of ways (thanks to equal access > > > provisions) that a user > > > >can directly or indirectly select a carrier, for example: > > > > > > > >- Having an entry in the LIDB for their address > > > corresponding to the Carrier > > > >Identification Code of their chosen carrier, so that > > > inter-exchange calls > > > >generated from their address always pick up this CIC > (i.e. PIC LD). > > > > > > > >- Using a dial-around (101+XXX+address) to override the > > > default CIC for > > > >their line. > > > > > > > >- Dialing a freephone number whose SMS/800 dip returns a > CIC code - > > > >presumably once the call has been routed to the > > > administrative domain of the > > > >carrier, a further internal dip will be performed to > > > translate the freephone > > > >number into a geographic number. > > > > > > > >Dave is certainly correct that a CIC does not necessarily > > > correspond to some > > > >physical network - that is, the concept of a 'carrier' > > > chosen by a user is > > > >largely a matter of who issues your bill, not what physical > > > infrastructure > > > >your call crosses. For example, there are resellers of > > > long-distance service > > > >whose CICs are really just aliases for the CIC of a major > > > carrier. Large > > > >carriers may own several CICs they use to target their > services. It's > > > >certainly not some kind of one-to-one mapping from CICs > to physical > > > >infrastructure. > > > > > > > >HOWEVER, this doesn't mean that a decision isn't made, in > > > some places in the > > > >telephone network, about how a call is routed based on the > > > CIC. In SS7, when > > > >a CIC has been selected for a call, it is carried within > the TNS or > > > >(ANSIfied) CIC parameter of the Initial Address Message. The > > > presence of > > > >this parameter modifies how a call is routed through the > > > telephone network, > > > >especially at tandems. > > > > > > > >So, to bring this matter back to trunk groups, one view > > > might be that a > > > >given trunk group may be considered to be a route to a CIC > > > if, when an SS7 > > > >IAM message carrying this CIC is sent over the trunk group, > > > this call will > > > >(eventually) be routed to the administrative domain > > > responsible for the CIC > > > >(and presumably get delivered appropriately). One might > > > contend, as an > > > >opposing position, that only the carrier that owns the > > > switch on the far > > > >side of the trunk should be considered to be reachable > > > through a trunk - but > > > >I suspect that in an overflow situation most network would > > > be content to > > > >send calls for some other carrier through such a trunk > > > group, even if it > > > >introduced a middle-man network, complicating routing > and potentially > > > >settlement. > > > > > > > >The correct position is probably somewhere in the middle. > > > One or more CICs > > > >may be 'preferred' for a particular trunk by some switch in > > > the network, > > > >largely because of who happens to own the equipment on the > > > other side, but > > > >in addition all CICs are usually 'available' through such > > > trunks. Something > > > >similar, I think, is true of E.164 numbers; certain ranges > > > may be preferred > > > >(due to settlement concerns) for particular trunk groups, > > > but all number > > > >ranges are usually available. > > > > > > > >Finally, it's important to note that CICs are national in > > > scope, and that > > > >therefore trunk groups are most likely only routes to the > > > set of CICs within > > > >a particular nationality. There have been suggestions in the > > > past that > > > >identifiers for CICs in the gw reg mechanism should be > > > concatenated with > > > >some sort of country code to provide a scope of a CIC - I > > > would agree that > > > >this is probably necessary. Then we could refine our > > > characterization of > > > >trunk group CIC routes to one in which all carriers for a > > > given nationality > > > >could be 'available' through a trunk group. > > > > > > > >Jon Peterson > > > >NeuStar, Inc. > > > > > > > > > Further discussion: > > > > > > > > > > Jon said that he believes this should always be about TGs > > > - believes > > > > > should treat PRI as a trunk. Cullen asked whether there > > > would ever be > > > > > more than one carrier on a single trunk? Jon said > that there are a > > > > > number of carriers for virtually every trunk. Due to EA. > > > Dave Oran > > > > > responded that this has nothing to do with it, as the EA > > > concept user > > > > > experience doesn't necessarily relate. Take it to the list. > > > > > > > > > >_______________________________________________ > > > >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 > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jan 4 19:10: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 TAA16520 for ; Fri, 4 Jan 2002 19:10:07 -0500 (EST) 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 g04No3o04564; Fri, 4 Jan 2002 18:50:04 -0500 Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g04NnLo04546 for ; Fri, 4 Jan 2002 18:49:21 -0500 Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA22146; Fri, 4 Jan 2002 18:49:16 -0500 (EST) 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 AAH31171; Fri, 4 Jan 2002 18:44:53 -0500 (EST) Message-Id: <4.3.2.7.2.20020104184613.00b765b8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Peterson, Jon" From: Michael Hammer Subject: RE: [IPTEL] draft meeting minutes Cc: iptel In-Reply-To: <70565611B164D511957A001083FCDD56CAAD7B@va02.va.neustar.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: Fri, 04 Jan 2002 18:55:33 -0500 Jon, I am also assuming that, while some information may be provisioned directly into the LS or available through other protocol mechanisms, much of the data shared with peers internal or external to the administrative domain will be derived from the data learned through the GW-Reg. So, there may be stuff put in GW-reg because the follow-on protocols expect to be able to pass that data. Mike At 05:19 PM 1/4/2002 -0600, Peterson, Jon wrote: >I certainly think you have a valid concern; there definitely is a >relationship between the attributes propagated by the gateway registration >protocol and the routing decisions (for call setup signaling) made by the >proxies that receive these registrations. TRIP strongly couples the two - in >fact, TRIP provides for three major functions: > >1) The protocol itself for propagating routes from one point to the next >2) Way of making forwarding decisions for calls based on discriminators >propagated in the protocol (TRIBs) >3) Way of deciding what routes you will share with peers > >By ruling intradomain route propagation outside of the scope of the gw reg >deliverable, we've essentially made the third item above out of scope. None >of our existing requirements, I think, really address the second problem - >nor have we necessarily agreed that this problem is even in the scope of >gateway registration. I'd really like to hear people's opinions about that. > >I definitely agree that discriminators should provide enough data to allow >meaningful routing decisions to be made by proxy servers; however, I don't >think we should wed discriminators to any particular routing philosophy. I >think ideally, the set of discriminators should be flexible enough to enable >any of the hop-off philosophies you describe below, depending on the policy >of the service provider accepting gateway registrations (a little MAAP, I >know). I would be really cautious about any gw reg protocol that seemed to >limit the sort of forwarding decisions that might be made within the proxy >server. > >Note that, as I understand it, TRIP builds in some limitations here (like >hierarchical discriminators). > >Jon Peterson >NeuStar, Inc. > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Thursday, January 03, 2002 7:47 AM > > To: Peterson, Jon > > Cc: iptel > > Subject: RE: [IPTEL] draft meeting minutes > > > > > > Yes, I think our perspectives are consistent. What I have a > > problem with > > is getting wrapped around the axle with propagating routing > > information > > across the network, that in the end may not provide a useful > > discriminator > > for choosing one route over another. What makes one gateway > > hop-off point > > better than another? > > > > Are we minimizing PSTN (or other) network administrations > > that we must cross? > > Are we minimizing conversion points (RTP to TDM) that may > > introduce noise? > > Can a network capacity re-seller reduce the number of billing > > relationships? > > > > My starting axiom was that the call was routed into the IP > > world or started > > there for a reason, and that IP was the preferred path to > > effectively make > > all calls local. Your point that the existing CIC codes are > > inherently > > geographical on a large scale also points to the possible > > need to define > > geographic attributes on a smaller scale as well. > > > > Mike > > > > > > At 02:49 AM 1/3/2002 -0600, Peterson, Jon wrote: > > > > >I don't think we're really disagreeing about much of what > > you say below. I > > >agree with your account of how things operate in the PSTN. > > It sounds like we > > >agree that the relationship of CICs to TGs is not in any simple way > > >hierarchical. > > > > > >The primary purpose of my note on the CIC was to suggest a > > potential litmus > > >test for whether or not a CIC was routable through a TG. I > > think that's an > > >important definition for us all to agree on if we're going > > to consider > > >propagating attributes like CICs in the gw reg protocol. > > > > > >In answer to the question you pose, I think my contention > > here is that one > > >logical trunk group could have more than one CIC associated > > with it. Imagine > > >a trivial VoIP network containing one proxy server and one > > PSTN gateway in > > >which the gateway had a single trunk group aimed at an access tandem. > > >Clearly, that trunk group would be the route for all CICs > > irrespective of > > >whether it was directly or indirectly connected to any given carrier. > > >Introduce a second trunk group going to a different access > > tandem, and > > >perhaps this trunk group would be a better route for some > > set of CICs. But > > >in neither case would you want to construct, say, one > > logical trunk group > > >per CIC and overlay them all on the physical trunk(s) - that > > would be quite > > >an administrative headache. > > > > > >I'm not sure I necessarily agree that the question with CICs > > is "how to > > >route such that the PSTN path is minimized at the expense of > > a more direct > > >IP path", or even that this is necessarily a least-cost > > problem. There have > > >been significant head-end hop-off vs. tail-end hop-off > > arguments with regard > > >to CIC routing levied here in the past. Fortunately, I think this is > > >ultimately a routing policy question, and really any of > > these philosophies > > >could be enabled by the CIC propagation systems we're > > discussing above. > > > > > >And, my final statement in my previous mail was intended > > only to illustrate > > >that CICs are national in scope - that's all. > > > > > >Jon Peterson > > >NeuStar, Inc. > > > > > > > -----Original Message----- > > > > From: Michael Hammer [mailto:mhammer@cisco.com] > > > > Sent: Wednesday, January 02, 2002 4:41 PM > > > > To: Peterson, Jon > > > > Cc: iptel > > > > Subject: RE: [IPTEL] draft meeting minutes > > > > > > > > > > > > Jon, > > > > > > > > Carrier IDs are used as an attribute to affect routing. > > > > Carriers have > > > > multiple switching points that can be contacted through > > some type of > > > > signaling address. Within a switching center, there are > > > > multiple trunk > > > > groups to other switching centers which may belong to the > > > > same carrier or > > > > different carriers. Choosing a TG from that switching center > > > > determines > > > > what next switching center the call can be routed to, and by > > > > inference, > > > > what the next hop carrier will be. Therefore, the carrier ID > > > > can determine > > > > what TG will be selected from that switching center. > > > > > > > > The originating side wants to route to a given carrier and > > > > location and > > > > uses the inferred signaling address. The destination side > > > > maps the carrier > > > > to an appropriate trunk group to get to that carrier and > > > > destination user > > > > address. > > > > > > > > The 101 prefix dialing is just a method of indicating the > > > > carrier to use at > > > > by the switch terminating the local loop. The fact that the > > > > next switching > > > > center can reach another carrier through another TG would be > > > > irrelevant, if > > > > the information was facility-based and not subverted by business > > > > arrangements. But, given those business arrangements, > > what you are > > > > pointing out is that the CIC:TG relationship is not > > > > hierarchical and thus a > > > > TG could have multiple carriers associated with it. That > > > > holds true if > > > > circuits are shared across carriers and the originating > > user is not > > > > affected by this business arrangement (i.e. charged for > > the next-hop > > > > facilities used to reach the desired carrier). > > > > > > > > Question 1: If 2 carriers were reach able over the same T-3, > > > > with one > > > > directly reachable and the other indirectly reachable, would > > > > the gateway > > > > almost always allocate the one physical facility as 2 logical > > > > trunk groups > > > > anyway? (Thus restoring the TG infers CIC mapping.) > > > > > > > > We already know that any switch in the PSTN can reach any > > > > other. The real > > > > question is how to route such that the PSTN path is > > minimized at the > > > > expense of a more direct IP path (assumes that is the least cost > > > > path). The use of TG data should be of local significance > > > > only at the > > > > egress of the IP network. > > > > > > > > I agree with your call for some type of geographic attribute. > > > > But, I don't > > > > understand your final statement. I don't want to see > > > > carrier's charges on > > > > my bill, if as the caller I specify a particular long-distance or > > > > international carrier. Also, will the CIC always be based on > > > > national body > > > > registration, or will IANA or someone ever assign > > > > international CIC codes > > > > for global carriers? > > > > > > > > Mike > > > > > > > > > > > > At 05:37 AM 12/31/2001 -0600, Peterson, Jon wrote: > > > > > > > > >I wanted to speak a bit to the issue from the minutes below > > > > regarding the > > > > >ubiquitous availability of carriers through trunks in the > > > > PSTN, and the > > > > >relevance of the 'equal access' concept - especially since > > > > this a matter on > > > > >which Dave and I have differed for some time. > > > > > > > > > >There are a number of ways (thanks to equal access > > > > provisions) that a user > > > > >can directly or indirectly select a carrier, for example: > > > > > > > > > >- Having an entry in the LIDB for their address > > > > corresponding to the Carrier > > > > >Identification Code of their chosen carrier, so that > > > > inter-exchange calls > > > > >generated from their address always pick up this CIC > > (i.e. PIC LD). > > > > > > > > > >- Using a dial-around (101+XXX+address) to override the > > > > default CIC for > > > > >their line. > > > > > > > > > >- Dialing a freephone number whose SMS/800 dip returns a > > CIC code - > > > > >presumably once the call has been routed to the > > > > administrative domain of the > > > > >carrier, a further internal dip will be performed to > > > > translate the freephone > > > > >number into a geographic number. > > > > > > > > > >Dave is certainly correct that a CIC does not necessarily > > > > correspond to some > > > > >physical network - that is, the concept of a 'carrier' > > > > chosen by a user is > > > > >largely a matter of who issues your bill, not what physical > > > > infrastructure > > > > >your call crosses. For example, there are resellers of > > > > long-distance service > > > > >whose CICs are really just aliases for the CIC of a major > > > > carrier. Large > > > > >carriers may own several CICs they use to target their > > services. It's > > > > >certainly not some kind of one-to-one mapping from CICs > > to physical > > > > >infrastructure. > > > > > > > > > >HOWEVER, this doesn't mean that a decision isn't made, in > > > > some places in the > > > > >telephone network, about how a call is routed based on the > > > > CIC. In SS7, when > > > > >a CIC has been selected for a call, it is carried within > > the TNS or > > > > >(ANSIfied) CIC parameter of the Initial Address Message. The > > > > presence of > > > > >this parameter modifies how a call is routed through the > > > > telephone network, > > > > >especially at tandems. > > > > > > > > > >So, to bring this matter back to trunk groups, one view > > > > might be that a > > > > >given trunk group may be considered to be a route to a CIC > > > > if, when an SS7 > > > > >IAM message carrying this CIC is sent over the trunk group, > > > > this call will > > > > >(eventually) be routed to the administrative domain > > > > responsible for the CIC > > > > >(and presumably get delivered appropriately). One might > > > > contend, as an > > > > >opposing position, that only the carrier that owns the > > > > switch on the far > > > > >side of the trunk should be considered to be reachable > > > > through a trunk - but > > > > >I suspect that in an overflow situation most network would > > > > be content to > > > > >send calls for some other carrier through such a trunk > > > > group, even if it > > > > >introduced a middle-man network, complicating routing > > and potentially > > > > >settlement. > > > > > > > > > >The correct position is probably somewhere in the middle. > > > > One or more CICs > > > > >may be 'preferred' for a particular trunk by some switch in > > > > the network, > > > > >largely because of who happens to own the equipment on the > > > > other side, but > > > > >in addition all CICs are usually 'available' through such > > > > trunks. Something > > > > >similar, I think, is true of E.164 numbers; certain ranges > > > > may be preferred > > > > >(due to settlement concerns) for particular trunk groups, > > > > but all number > > > > >ranges are usually available. > > > > > > > > > >Finally, it's important to note that CICs are national in > > > > scope, and that > > > > >therefore trunk groups are most likely only routes to the > > > > set of CICs within > > > > >a particular nationality. There have been suggestions in the > > > > past that > > > > >identifiers for CICs in the gw reg mechanism should be > > > > concatenated with > > > > >some sort of country code to provide a scope of a CIC - I > > > > would agree that > > > > >this is probably necessary. Then we could refine our > > > > characterization of > > > > >trunk group CIC routes to one in which all carriers for a > > > > given nationality > > > > >could be 'available' through a trunk group. > > > > > > > > > >Jon Peterson > > > > >NeuStar, Inc. > > > > > > > > > > > Further discussion: > > > > > > > > > > > > Jon said that he believes this should always be about TGs > > > > - believes > > > > > > should treat PRI as a trunk. Cullen asked whether there > > > > would ever be > > > > > > more than one carrier on a single trunk? Jon said > > that there are a > > > > > > number of carriers for virtually every trunk. Due to EA. > > > > Dave Oran > > > > > > responded that this has nothing to do with it, as the EA > > > > concept user > > > > > > experience doesn't necessarily relate. Take it to the list. > > > > > > > > > > > >_______________________________________________ > > > > >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 > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jan 4 19:20: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 TAA16645 for ; Fri, 4 Jan 2002 19:20:03 -0500 (EST) 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 g05002o04753; Fri, 4 Jan 2002 19:00:02 -0500 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g04Nxfo04735 for ; Fri, 4 Jan 2002 18:59:41 -0500 Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g04Nxeb31795; Fri, 4 Jan 2002 18:59:40 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 17:59:39 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAD7C@va02.va.neustar.com> From: "Peterson, Jon" To: "'Mpierce1@aol.com'" , iptel@lists.bell-labs.com, mhammer@cisco.com Subject: RE: [IPTEL] Definition of "trunk group" 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: Fri, 4 Jan 2002 17:59:35 -0600 My email had suggested that we coin a new term, as it were, and define whether a CIC is 'reachable' through a trunk group based on certain specific criteria - I recognize that the 'reachability' of CICs is not an existing concept in the PSTN, and I apologize if this concept confuses you. Traditional PSTN switches do not support dynamic gateway registration, and yes, therefore the PSTN has no need for a protocol that propagates reachability information at all. Despite your reservations, we all really do agree, I think, on how CICs are routed in a traditional telephone switch. An IP telephony network of gateways is not, however, a traditional telephone switch, and I believe this concept of 'reachability' is useful in this new domain - it been used, for example, throughout the TRIP literature since its inception (i.e. E.164 numbers are 'reachable' through a particular gateway). In a similar spirit, my suggestion that CICs might be 'available' or 'preferred' with regard to a particular trunk group has no corrollary in traditional telephone networks. However, I suspect you understand the difference between a trunk being directly connected to a given carrier, and a trunk group (like one pointing to an access tandem) being identified as a route to multiple carriers. 'Available' and 'preferred' are attempts to capture these sorts of characteristics of a trunk group in the scope of 'reachability', not to speak to how characteristics might be processed during a route decision in a proxy. Propagating routes to proxies and making routing decisions within proxies are related but distinct problems - this WG is currently focused on the former, not the latter. I personally have no commitment to a concept of 'logical trunk groups' - this was raised by Mr. Hammer, and my response to him indicated that I wasn't sure how it would be applicable to this problem. Incidentally, 'hierarchical', in the sense that I believe Mr. Hammer used it, refers to how route discriminators are processed by the proxy server to make a routing decision, based on the TRIP concept that discriminators should be concatenated from most specific to least specific. Not all of the nomenclature used in this discussion is predicated on PSTN antecedents. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > Sent: Friday, January 04, 2002 9:00 AM > To: jon.peterson@neustar.biz; iptel@lists.bell-labs.com; > mhammer@cisco.com > Subject: Re: [IPTEL] Definition of "trunk group" > > > In a message dated 1/3/02 2:43:27 AM Eastern Standard Time, > jon.peterson@neustar.biz writes: > > > I agree with your definition of a trunk group; we arrived > at a similar one > > on the mailing list earlier (i.e. roughly, a bundle of > DS0's between two > > PSTN network entities that are grouped under some kind of > common policy). > > > > (snip) > > > > The question of whether the 'route list' model gives us > still more leverage > > than the 'trunk group' model is interesting; 'route list' > certainly > provides > > an even greater level of abstraction. Without going > through a lot of > > semantic hair-splitting, I think that trunk groups provide > just the right > > layer of abstraction. The question here is "What entities > should the gwreg > > system provide the availability of?" I think trunk groups > have state that > > changes dynamically, and that these states in turn determine the > > availability of network resources. A proxy server that receives > > registrations for such trunk groups would construct the > 'route list,' as it > > were, of alternative trunk groups that meet the routing > criteria of calls. > I > > don't think a system in which 'route lists' were published > to proxy servers > > through the gateway registration process would grant us > much additional > > leverage on network design - in fact, I suspect it would > just push the > > problems around a bit. > > > > Jon Peterson > > NeuStar, Inc > > > Jon, > > Although you said above that you agree with my definition of > "Trunk Group" > (copied from T1.523), your reply to Mike Hammer the same day > still indicates > that you have a very much different concept of what a "trunk > group" is and > how it is used in routing calls to specific carriers (based > on the CIC). Mike > Hammer's e-mail correctly described the routing. > Interpretation of the CIC > (or any other digits dialed) results in a pointer to a trunk group. > Obviously, multiple CICs can point to the same trunk group, and, with > alternate routing, each CIC can point to multiple trunks > groups (in an > ordered list defined as a "route list"). I guess this is what > you mean by > saying that this relationship is not "hierarchical". I would > say it's not > one-to-one or one-to-many, but rather many-to-many. In > telephony routing > "hierarchical" has had a different meaning. > > It confuses the issue to describe trunk groups in terms of > what CICs (or > E.164 number ranges) they can reach, which is what your > comments still do. > Further, your statement that "One or more CICs may be > 'preferred' for a > particular trunk [group] by some switch ..." does not > correctly represent the > dialed digit interpretation/alternate routing that takes place. > > I'm further confused by the references to "logical trunk > groups" and what > significance this has. It is possible for an implemenation to further > subdivide actual (physical) trunk groups into some "logical" > sub-grouping, > for example, to help it prevent glare on two-way trunks, but > I don't think > this is an important concept to include in these discussions. > Does "logical > trunk group" have some additional meaning or significance? > > Regarding your comment on "whether the 'route list' model > gives us still more > leverage than the 'trunk group' model" --- the "trunk group" > concept is > fundamental to all descriptions of routing, since it > represents the actual > physical facilities (sometimes DS0s as you noted) between > real network > elements. The "route list" concept, on the other hand, represents the > internal workings of a switch and does not impact the > signaling between > switches, so is less important. However, it is a useful concept and > definition since it helps to have a common concept of how > telephone calls are > routed (what I call "alternate routing"). > > Mike Pierce > Artel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jan 4 21:39: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 VAA18514 for ; Fri, 4 Jan 2002 21:39:00 -0500 (EST) 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 g052O4o05630; Fri, 4 Jan 2002 21:24:04 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g052Nho05617 for ; Fri, 4 Jan 2002 21:23:43 -0500 Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g052NxVZ007391; Fri, 4 Jan 2002 21:23:59 -0500 (EST) Message-ID: <3C3663A1.50903@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Mpierce1@aol.com CC: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC 2806 revision (tel url) 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, 04 Jan 2002 21:23:29 -0500 Content-Transfer-Encoding: 7bit The original motivation for the tel URL was not the same as its current usage. It was created to enable a PC with an internal fax/modem card to dial phone numbers when a URL is clicked. For example, when you click on tel:12345, your modem card would pick up and dial 12345. Since the URL is used directly to operate the modem, this is why things like pauses and post-dial digits were included. This usage is quite different from its usage to describe a telephony resource, which is how it is used in SIP. -Jonathan R. Mpierce1@aol.com wrote: > To all, > > I believe that mention of this RFC in Minneapolis in the March 2001 > meeting > indicated that there was a general feeling that there were significant > problems with the current text and a rewrite was required. Based on > this, I > will make some rather substantial comments on the current text, with the > > understanding that they propose some significant changes to the concept > and > details described. > > The text of RFC 2806 seems to confuse the controls that might be needed > between a controller and the device doing outgoing dialing (e.g., MGC > and MG) > with what is required in the url to designate the destination > (location). For > example, it takes the AT modem commands for pauses and waits for dial > tone > and includes them with the url. While there may be cases in which one > specific network element (e.g., a MG) needs to apply these techniques in > > order to send digits (DTMF or dial pulse) to another element (e.g., a > circuit > switched PBX), the originator of the call knows nothing about this, so > this > information should not be a part of the url. In fact, due to alternate > routing, two calls with the same url might be treated differently > because > they are routed differently. This type of dialing in which the > originator > needed to know the routing in order to formulate the digit string was > eliminated from most telephony switching environments long ago. > > The definition of specific "tel", "fax", and "modem" urls ignores the > existence of customer premise devices currently in use which allow the > connection of telephones, faxs, and modems on the same telephone line > (using > the same telephone number). In reality, there is no difference in the > urls > needed for the 3 cases mentioned. The current telephony network is based > on > there being no difference within the network for these different uses. > If > other information needs to be carried (e.g., to specify the type of > modem > supported) this should be separate from the url and may be ignored by > some > equipment. This type information should not be a part of the url, since > it > does not provide an identification of the "resource location". If it > did, > this would then imply, for example, that the following define different > locations, that is, must be routed differently: > > modem:+1-410-555-1234;type=v32b > modem:+1-410-555-1234;type=v21 > modem:+1-410-555-1234;type=x75 > > "Post dial" should not be a part of the url. The example given in > Section 2.2 > of accessing a voice mailbox shows the mistake. The digits to be dialed > by > the caller when accessing a voice mailbox depend on the voice prompt > from > that mailbox system after setup of the initial call. For this reason, > the > possible post-dialing digits can not be a part of the url. > > There is a fundamental problem in that the urls being described in this > RFC > serve both as a user visible address (like on a letterhead or on a web > page) > and as the inter-network element signaling protocol (e.g., part of SIP). > It > is noted that E.123, which is referenced, only addresses the > representation > of numbers, for example, on letterhead. This dual purpose of the url > being > defined leads to confusion in the description. For example, while some > signaling relationships may need to be able to code the extra > preliminary > prefix digits needed to do special things (like the "0w00" in the 5th > example > in Section 2.6), this would never be a part of the url as printed or > visible > on a web page, since it is dependent on the location and equipment of > the > originator. > > In the telephony world, the digits 0-9 are represented in signaling only > by > those numbers, However, the user may see the address with these numbers > replaced by letters. Since the url being defined here is intended to be > seen > by the user (as also defined in E.123), it is essential that it be > allowed to > include letters (not the A, B, C, D that are used to designate the extra > 4 > codes possible on a DTMF key pad). As E.123 states, "diallable symbols > ... > can be digits, letters, or other signs." Of course, this causes a > problem if > one tries to incorporate the 4 extra DTMF codes into the same address > string. > However, in the ITU-T E.164 numbering plan, these extra DTMF codes can > not be > part of the address. The international number is limited to 15 digits, > each > being a numeral 0-9. So, in the tel: url beginning with +, there is no > problem with allowing letters a-z. Of course, this depends on the > association > between letters and numbers being as recommended in E.161. For this > reason, > users are advised to avoid using letters to specify telephone numbers in > > international service, but they may. > > The 1st, 2nd, and 3rd examples in Section 2.6 show a problem with this > scheme > of treating tel, fax, and modem separately. The three examples use the > same > number, which can really occur. As shown, the three identical numbers > must > all result in exactly the same call setup regardless of the extra > parameters. > Whether it is treated as a telephone or fax or modem call depends on the > > kinds of equipment connected and the in-band signals which occur. > > The 4th example in Section 2.6 show the problem with the post-dial > logic. > While there may be valid case to support the extra digits needed to > directly > dial into a PBX at the destination in order to directly reach an > extension, > that capability needs to be under control of the destination. Only the > destination knows whether DTMF or dial-pulse or something else is needed > to > signal to the final entity. The originating entity does not even need to > know > that there is an extension number present if it is a part of the > complete > number (as happens in the US all the time with DID). If the extension > number > is in addition to the regular international number (which is limited to > 15 > digits), then the originating entity might know that there are > additional > digits, but still has no knowledge of how the destination is going to > signal > them (e.g., to a PBX). The other example of the origination entity > needing of > enter DTMF to invoke a particular service would require an audible > response > returned from the destination after call set before these additional > DTMF > digits are sent. Therefore, they can not be part of the url in this > case. > > The text of the 5th example indicates the problem with this form of the > url. > It states "this kind of phone umber MUST NOT be used in an environment > where > all users of this URL might not be able to successfully dial out by > using > this number directly." Since such a phone number contained on a "company > > intranet" or printed material would be accessible by many people in > various > places, this will not work. The method used, and the format of the url, > should follow the procedures developed over many decades of such > situations > in the telephony world. The telephone number needs to be shown in a > standard > local or international format and the user needs to understand how to > dial it > from their location (e.g., by dialing "0", waiting for dial tone, and > then > dialling "00" for international access because the local telephone book > says > to do this). Clearly, when the originating user has a computerized user > agent > (SIP phone), it can do this thinking for the person based on dialing > rules > that it has been provisioned with, so the human doesn't have to worry > about > it. That means that the url on a web page must be in one of the standard > > formats (no extra prefix digits). In some environments, there may in > fact be > multiple ways to dial a specific destination. Today the user may decide > which > to use and the new user agent (SIP phone) can also do so, so it should > not be > a part of the url. > > Since the 6th example shows a telephone number in country code 1, it > should > be following by a legitimate 10-digit number so as to not confuse. > Further, > the idea should be represented with a better example. It is unknown of > any > case in which an E.164 telephone number (in North America) would be > specified, but it is only "usable" within that area code. Perhaps the > example > would be better if it were to specify a number usable only within a > specific > country. > > I suggest that this RFC be pared down to simply defining the url for a > "telephone" number and that additional parameters that might control > call > setup, such as modem capabilities, should be a part of SIP or a > supplementary > draft that specifically describes additions to SIP for fax and modem > calls. > > Mike Pierce > Artel > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > > -- 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 Fri Jan 4 21:57: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 VAA18641 for ; Fri, 4 Jan 2002 21:57:35 -0500 (EST) 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 g052u6o05831; Fri, 4 Jan 2002 21:56:06 -0500 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 SMTP id g052t1o05811 for ; Fri, 4 Jan 2002 21:55:01 -0500 Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jan 4 21:49:05 EST 2002 Received: by lists.bell-labs.com (Postfix) id 7486F4439E; Fri, 4 Jan 2002 21:40:55 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id 43CE64439D for ; Fri, 4 Jan 2002 21:40:55 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id VAA25970; Fri, 4 Jan 2002 21:40:54 -0500 (EST) Message-ID: <3C3666A7.7554DAA7@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Mpierce1@aol.com, iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC 2806 revision (tel url) References: <3C3663A1.50903@dynamicsoft.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: Fri, 04 Jan 2002 21:36:23 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > The original motivation for the tel URL was not the same as its current > usage. It was created to enable a PC with an internal fax/modem card to > dial phone numbers when a URL is clicked. For example, when you click on > tel:12345, your modem card would pick up and dial 12345. Since the URL > is used directly to operate the modem, this is why things like pauses > and post-dial digits were included. > > This usage is quite different from its usage to describe a telephony > resource, which is how it is used in SIP. > Agreed; the question is if the first usage is useful. It doesn't seem to have attracted much use in practice. Part of the problem is that adding URL schemes to browsers is still somewhat painful, if possible at all. But I also think that this is like the perennial SDP and RTP URL proposals - URLs just aren't expressive enough to contain "programs" and complicated data structures. As I mentioned before, for a modem connection, one typically needs a whole lot more than a phone number and the number of stop bits, including various pieces of authentication and PPP information. For a fax URL, I'm not sure what this would do in a web page. Which object would get faxed? (I can see popping up an application that then prompts for the document to be faxed, similar to a mailto: URL.) This is a decision the WG that are the "customers" of this URL need to make. I'm basically of the opinion that unless there's a demonstrated need for a feature, it gets ditched. Otherwise, we'll never get RFCs beyond Proposed. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Jan 5 16:16: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 QAA07468 for ; Sat, 5 Jan 2002 16:16:10 -0500 (EST) 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 g05LD6o10182; Sat, 5 Jan 2002 16:13:06 -0500 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g05LCVo10169 for ; Sat, 5 Jan 2002 16:12:31 -0500 Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g05LC3k00462; Sat, 5 Jan 2002 13:12:03 -0800 (PST) Received: from oranlt (rtp-dial-1-67.cisco.com [10.83.97.67]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ABT01859; Sat, 5 Jan 2002 13:12:31 -0800 (PST) From: "David R. Oran" To: "'Henning G. Schulzrinne'" , Subject: RE: [IPTEL] More 2806bis: ISDN subaddresses to be removed Organization: Cisco Systems Message-ID: <019901c1962d$5f6fc620$3bee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <3C31D703.435808EC@cs.columbia.edu> Importance: Normal 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, 5 Jan 2002 16:09:50 -0500 Content-Transfer-Encoding: 7bit We're using them. Let me check with our implementers about whether this is critical. > -----Original Message----- > From: iptel-admin@lists.bell-labs.com > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Henning > G. Schulzrinne > Sent: Tuesday, January 01, 2002 10:34 AM > To: iptel@lists.bell-labs.com > Subject: [IPTEL] More 2806bis: ISDN subaddresses to be removed > > > Unless somebody steps forward and claims use, ISDN > subaddresses are also on the way out. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ > 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 Jan 6 20:00: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 UAA27955 for ; Sun, 6 Jan 2002 20:00:14 -0500 (EST) 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 g070aEo20953; Sun, 6 Jan 2002 19:36:14 -0500 Received: from imo-r10.mx.aol.com (imo-r10.mx.aol.com [152.163.225.106]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g070ZCo20933 for ; Sun, 6 Jan 2002 19:35:12 -0500 Received: from Mpierce1@aol.com by imo-r10.mx.aol.com (mail_out_v31_r1.9.) id r.f9.155cba12 (4208); Sun, 6 Jan 2002 19:35:05 -0500 (EST) From: Mpierce1@aol.com Message-ID: Subject: Re: [IPTEL] Comments on RFC 2806 revision (tel url) To: jdrosen@dynamicsoft.com CC: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 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, 6 Jan 2002 19:35:05 EST Content-Transfer-Encoding: 7bit In a message dated 1/4/02 9:24:10 PM Eastern Standard Time, jdrosen@dynamicsoft.com writes: > The original motivation for the tel URL was not the same as its current > usage. It was created to enable a PC with an internal fax/modem card to > dial phone numbers when a URL is clicked. For example, when you click on > tel:12345, your modem card would pick up and dial 12345. Since the URL > is used directly to operate the modem, this is why things like pauses > and post-dial digits were included. > > This usage is quite different from its usage to describe a telephony > resource, which is how it is used in SIP. > I presume from your comments that you support a significant rewrite of RFC 2806 and deletion of the things that were there to support PC/modem communication (like the AT command set I referred to) which would not be appropriate for specifying the destination telephone address. Following are additional comments/thoughts on this subject: Since the purpose is to define a telephony resource (a destination for a call), it would seem that there are three somewhat related uses for this url: 1. to represent the destination resource at the user interface for the human to enter/read 2. to represent the destination resource as seen by a user agent, for example in an A HREF html tag or the equivalent SIP user agent. 3. to represent the destination resource for inclusion in messages (e.g., in SIP) In other signaling systems, the above would be distinct formats. In SIP, there is an assumption that these 3 uses must be the same format, as in HTTP, which has led to the difficulty with defining/understanding how to treat spaces and other things. It seems that, independent of whatever is done in SIP or in other protocols, the representation to the user should use exactly what is currently standardized in E.123. That is, the international number, which could include spaces, hyphens, or dots as visual separators or letters in place of numbers. When the tel: url is used internally (in an A HREF tag or in a signaling message), all visual separators would be removed and letters would be converted to the appropriate numbers. There would need to be a specific decision on which of the procedure symbols defined in E.123 need to be included. My suggestions: 1. International prefix symbol - + used to indicate an international number (Note that this symbol is really defined in E.123 as indicating the need to dial an international prefix which is not included in the number since it depends on where one is dialing from. Here it is being used to indicate that an international number follows. This is pretty much the same in the end, but a slightly different definition.) 2. Parentheses - never used in an international number, but might be allowed in other numbers 3. Slash "/" to indicate multiple numbers - probably not allowed 4. ... to indicate in-dialing - actual uses of this are unknown 5. Tilde to indicate where another dial tone will occur - uses of this in real life as a part of the destination national or international number are unknown. It is defined in E.123 only as an indication to the human of where to expect another dial tone. It does not control signaling. Representation of international numbers should be easy, since this is already defined in E.123. This results in a truely "uniform" resource locator. If there is also a need to represent national numbers and private numbers, this causes difficulty in keeping them "uniform". Of course, E.123 defines the representation on printed material and includes the words "international" or "national" before the numbers, which the tel: url won't do. The absence of the "+" could mean national, however, the result is not "uniform" in the sense of being unique. Numbers from private number plans are much more of a problem since they are never unique. Considering the three uses of the tel: url listed above: The representation at the user interface has a meaning only to that user. That is, the person understands the context of the number they enter or see. The representation within an A HREF html tag or equivalent has no knowledge of the context. Either it is unique (e.g., an international number) or the user agent must assume a context or determine it by other means. Within the signaling message, the context must be explicit. Here there is no reason to support national numbers, since they are just a subset of the international number. The user agent could always fill in the complete number. Private number plans must be supported, and some way to identify the context ("domain"?) is desired. I do not believe it should be a part of the tel: url, since the identification of the "domain" applies to other things besides the telephone number. Since the purpose of the tel: url is to designate the destination resource, it should never include procedures for getting out of the originator's local environment. That is why dial tone detection and pauses, as used to control modems to get through the user's PBX, are not required. Mike Pierce Artel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Jan 6 20:07:15 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 UAA27993 for ; Sun, 6 Jan 2002 20:07:15 -0500 (EST) 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 g070o1o21022; Sun, 6 Jan 2002 19:50:01 -0500 Received: from imo-r10.mx.aol.com (imo-r10.mx.aol.com [152.163.225.106]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g070ZEo20940 for ; Sun, 6 Jan 2002 19:35:14 -0500 Received: from Mpierce1@aol.com by imo-r10.mx.aol.com (mail_out_v31_r1.9.) id g.a0.2032efc6 (4208); Sun, 6 Jan 2002 19:35:07 -0500 (EST) From: Mpierce1@aol.com Message-ID: Subject: Re: [IPTEL] Definition of "trunk group" To: jon.peterson@neustar.biz, iptel@lists.bell-labs.com, mhammer@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 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, 6 Jan 2002 19:35:07 EST Content-Transfer-Encoding: 7bit In a message dated 1/4/02 7:00:01 PM Eastern Standard Time, jon.peterson@neustar.biz writes: > My email had suggested that we coin a new term, as it were, and define > whether a CIC is 'reachable' through a trunk group based on certain specific > criteria - I recognize that the 'reachability' of CICs is not an existing > concept in the PSTN, and I apologize if this concept confuses you. > Traditional PSTN switches do not support dynamic gateway registration, and > yes, therefore the PSTN has no need for a protocol that propagates > reachability information at all. Despite your reservations, we all really do > agree, I think, on how CICs are routed in a traditional telephone switch. An > IP telephony network of gateways is not, however, a traditional telephone > switch, and I believe this concept of 'reachability' is useful in this new > domain - it been used, for example, throughout the TRIP literature since its > inception (i.e. E.164 numbers are 'reachable' through a particular gateway). > > In a similar spirit, my suggestion that CICs might be 'available' or > 'preferred' with regard to a particular trunk group has no corrollary in > traditional telephone networks. However, I suspect you understand the > difference between a trunk being directly connected to a given carrier, and > a trunk group (like one pointing to an access tandem) being identified as a > route to multiple carriers. 'Available' and 'preferred' are attempts to > capture these sorts of characteristics of a trunk group in the scope of > 'reachability', not to speak to how characteristics might be processed > during a route decision in a proxy. Propagating routes to proxies and making > routing decisions within proxies are related but distinct problems - this WG > is currently focused on the former, not the latter. > Yes, I realize that the issue is "propagation" of routes rather than how that data is actually used to route calls. But I believe that a solid understanding and agreement of how telephony routing occurs is required before too much detail on "propagation" is done. I think Mike Hammer's comments are addressing this issue. There is a fundamental difficulty, since the network architecture requires that many trunk groups handle all traffic, regardless of the CIC or destination address specified, but the route propagation is based on a different concept. Regardless of the functions of "route propagation", it seems to me that the function of "routing" still means that interpretation of the CIC (and other dialed information) results in the selection of an ordered list of trunk groups (physical facilities) by which a call can be routed (called a "route list" in T1.523). I especially have a concern with your statement that "CICs might be 'available' or 'preferred' with regard to a particular trunk group has no corrollary in traditional telephone networks". I don't think this statement represents the required routing logic (independent of how this information is propogated). I believe the required routing logic does have a direct corrollary in the traditional telephone network. The concepts of "available" and "preferred" are included by the ordered list of trunk groups. (The first trunk group is preferred, the second is preferred next, etc. All in the list are available.) The difficulty with indicating "preferred" and "available" in the route progagation procedure is that it can not indicate an actual order to be used in the actual route selection. It seems that there must first be a common agreement on what routing procedures are required. Only then can route propogation procedures be defined. Mike Pierce Artel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Jan 6 20:46: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 UAA28331 for ; Sun, 6 Jan 2002 20:46:33 -0500 (EST) 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 g071X2o21400; Sun, 6 Jan 2002 20:33:02 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g071WVo21387 for ; Sun, 6 Jan 2002 20:32:31 -0500 Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g071WlVZ007843; Sun, 6 Jan 2002 20:32:48 -0500 (EST) Message-ID: <3C38FAA0.3030601@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Mpierce1@aol.com CC: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC 2806 revision (tel url) 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, 06 Jan 2002 20:32:16 -0500 Content-Transfer-Encoding: 7bit Mpierce1@aol.com wrote: > In a message dated 1/4/02 9:24:10 PM Eastern Standard Time, >> This usage is quite different from its usage to describe a telephony >> resource, which is how it is used in SIP. >> >> > I presume from your comments that you support a significant rewrite of > RFC > 2806 and deletion of the things that were there to support PC/modem > communication (like the AT command set I referred to) which would not be > appropriate for specifying the destination telephone address. I was not supporting or not supporting anything, but merely making a statement of fact to help clarify. > Since the purpose is to define a telephony resource (a destination for a > call), it would seem that there are three somewhat related uses for this > url: > > 1. to represent the destination resource at the user interface for the > human > to enter/read > 2. to represent the destination resource as seen by a user agent, for > example > in an A HREF html tag or the equivalent SIP user agent. > 3. to represent the destination resource for inclusion in messages > (e.g., in > SIP) > > In other signaling systems, the above would be distinct formats. In SIP, > > there is an assumption that these 3 uses must be the same format, as in > HTTP, > which has led to the difficulty with defining/understanding how to treat > > spaces and other things. No, there is no difficulty at all. Your beef seems to be with the URI concept in general, but issues like inclusion of spaces and other such things are well documented and understood within URIs. I would strongly oppose attempting to define three separate representations for the three things above. -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 Sun Jan 6 21:11: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 VAA28572 for ; Sun, 6 Jan 2002 21:11:28 -0500 (EST) 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 g071v3o21629; Sun, 6 Jan 2002 20:57:03 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g071u4o21609 for ; Sun, 6 Jan 2002 20:56:04 -0500 Received: from metroliner.cs.columbia.edu (IDENT:root@metroliner.cs.columbia.edu [128.59.19.252]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA06215; Sun, 6 Jan 2002 20:56:03 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by metroliner.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id g071u2d23760; Sun, 6 Jan 2002 20:56:03 -0500 Message-ID: <3C39014C.5FFFDE4B@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Mpierce1@aol.com, iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC 2806 revision (tel url) References: <3C38FAA0.3030601@dynamicsoft.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: Sun, 06 Jan 2002 21:00:44 -0500 Content-Transfer-Encoding: 7bit > > No, there is no difficulty at all. Your beef seems to be with the URI > concept in general, but issues like inclusion of spaces and other such > things are well documented and understood within URIs. I would strongly > oppose attempting to define three separate representations for the three > things above. > One thing that makes tel URIs a bit different is this notion of visual separators. I'm not really aware of other URI schemes that have the notion of stripping certain "decorator" characters to arrive at a canonical representation. Also, it is not clear to me that these have to be in a URL. I don't see people putting tel URLs on a bus or business card - everybody recognizes phone numbers just find without this. If the tel URL is part of a web page, it's not visible to normal users that don't watch the bottom status bar. Thus, something like "Dial (800) 555-1212 for directory assistance." is most likely and it doesn't matter that the URL itself doesn't support () or spaces. In any event, if we are to make progress on what is, after all, a fairly small piece of the picture, I think we need to consider - not breaking 2806 backwards-compatibility gratuitously. This probably precludes adding additional visual separators, unless people tell me that implementations simply ignore punctuation until the first semicolon (which would be a smart move...). - describing features that are actually used. So far, a few people have come forward indicating at least tepid support for phone-context and maybe ISDN sub-addresses, so these are in the upcoming draft. - removing features that might be interesting, but nobody seems to have found a real-world use for. Various AT-style dial instructions and the modem/fax URL schemes seem to fall into this category. If such a use is identified in the future, both features can be added as separate drafts. To make this possible for dial strings, I'll probably add wording that anything after the first non-phonedigit character is to be ignored. (This was in 2806, so this is not news: "If it is not supported, local entities MUST ignore everything in the dial string after the first and the user SHOULD be notified." To repeat something I keep saying: eventually, we want to move things to Draft Standard. Draft Standard requires two interoperable implementations of every feature. Thus, this is the time to trim, not to add. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jan 7 13:07: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 NAA23007 for ; Mon, 7 Jan 2002 13:07:06 -0500 (EST) 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 g07I54o25646; Mon, 7 Jan 2002 13:05:05 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g07I4Go25631 for ; Mon, 7 Jan 2002 13:04:16 -0500 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 NAA29626 for ; Mon, 7 Jan 2002 13:04:16 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g07I4FJ1024622 for ; Mon, 7 Jan 2002 13:04:16 -0500 (EST) Message-ID: <3C39E31F.4AD48DE8@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] 2806bis: phone-context 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, 07 Jan 2002 13:04:15 -0500 Content-Transfer-Encoding: 7bit The phone-context parameter does appear to be used, judging from private email. One possibility would be to use IANA enterprise numbers for labeling. They are free and short. (We just got one for Columbia a few weeks ago; took about 10 minutes to fill out the form and a week to get the number.) See http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers Thus, something like ;phone-context=11862.cs (with CS being the department) would label the number within the Dept. of Computer Science at Columbia. Domain names are another possibility, but these dialing plans are not really DNS domains, so this is rather artificial. In any event, an entity would have to be programmed with a list of names to recognize. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jan 7 14:30:22 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 OAA25595 for ; Mon, 7 Jan 2002 14:30:22 -0500 (EST) 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 g07JSwo26395; Mon, 7 Jan 2002 14:28:58 -0500 Received: from web8104.in.yahoo.com (web8104.in.yahoo.com [203.199.70.104]) by share.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g04B4do00924 for ; Fri, 4 Jan 2002 06:04:40 -0500 Message-ID: <20020104110435.89174.qmail@web8104.in.yahoo.com> Received: from [203.190.136.98] by web8104.mail.in.yahoo.com via HTTP; Fri, 04 Jan 2002 11:04:35 GMT From: =?iso-8859-1?q?vipin=20gahlaut?= To: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [IPTEL] Query regarding application of TRIP 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, 4 Jan 2002 11:04:35 +0000 (GMT) Content-Transfer-Encoding: 8bit Hi Everybody I am not very much clear about the application of TRIP,as in case of H323 and and SIP messages are exchanged from one IP to other IP. The route between these 2 IP can be selected by router already placed. why we need to implement TRIP?? I will be highly obliged if somebody clears my doubt. Thanks & Best Regards Vipin ____________________________________________________________ Do You Yahoo!? Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.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 Jan 7 14:45:36 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 OAA25940 for ; Mon, 7 Jan 2002 14:45:36 -0500 (EST) 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 g07JL8o26296; Mon, 7 Jan 2002 14:21:08 -0500 Received: from atlas.raviant.com (atlas.raviant.com [63.173.107.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBSE8Ho04880 for ; Fri, 28 Dec 2001 09:08:17 -0500 Received: (from mail@localhost) by atlas.raviant.com (8.9.3+Sun/8.9.3) id IAA24951; Fri, 28 Dec 2001 08:06:05 -0600 (CST) Received: from inservercr.raviant.com(172.22.1.58) by atlas.raviant.com via smap (V2.1) id xma024949; Fri, 28 Dec 01 08:05:43 -0600 Received: from moo.Raviant.com (172.22.8.15 [172.22.8.15]) by inservercr.raviant.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VZ0T7R73; Fri, 28 Dec 2001 08:07:06 -0600 Message-Id: <5.1.0.14.2.20011228075140.02681c08@INserverCR.Raviant.com> X-Sender: RGumpert@INserverCR.Raviant.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Henning Schulzrinne From: "Richard H. Gumpertz" Subject: Re: [IPTEL] New draft RFC 2806bis Cc: iptel@lists.bell-labs.com In-Reply-To: <3C25572B.859A6005@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, 28 Dec 2001 08:07:21 -0600 I apologize if I am reopening something that has already been beat to death... Why is space prohibited as a visual-separator in telephone numbers? Yes, it has to be escaped, which can be ugly, but the end-user may not see that escaping. End users may be dealing with User Interfaces rather than raw URIs and so enhanced readability of the URI is NOT the issue; enhanced readability at the UI level is. Why not allow space as a visual-separator so that such information can be preserved? A sentence in 6.1.2 discouraging use of space (due to the ugliness of escaping) as a visual separator seems more appropriate than prohibition. On the other hand, I understand that allowing escaped spaces as visual separators might break existing implementations, which could be more costly than any benefit to be gained at this point in time by allowing them. Rick Gumpertz At 23:01 12/22/2001 -0500, Henning Schulzrinne wrote: >I will submit the draft below after the holidays, when the I-D editor >returns: > >http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-rfc2806bis-00.txt > >Comments are much appreciated. Much of the text has been rewritten, but >the document is meant to be backwards-compatible except for the omission >of the private context name. > >Henning >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel -- Richard H. Gumpertz, Ph.D. Raviant Networks, Inc. office: +1 (913) 266-5137 mobile: +1 (913) 484-8777 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jan 7 15:05: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 PAA26525 for ; Mon, 7 Jan 2002 15:05:33 -0500 (EST) 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 g07K42o26889; Mon, 7 Jan 2002 15:04:02 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g07K3ko26876 for ; Mon, 7 Jan 2002 15:03:46 -0500 Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g07K4DVZ008768; Mon, 7 Jan 2002 15:04:14 -0500 (EST) Message-ID: <3C39FF1D.6040402@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: vipin gahlaut CC: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Query regarding application of TRIP References: <20020104110435.89174.qmail@web8104.in.yahoo.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, 07 Jan 2002 15:03:41 -0500 Content-Transfer-Encoding: 7bit vipin gahlaut wrote: > Hi Everybody > > I am not very much clear about the application of > TRIP,as in case of H323 and and SIP messages are > exchanged from one IP to other IP. The route between > these 2 IP can be selected by router already placed. > why we need to implement TRIP?? Routing occurs at many layers. TRIP is concerned about exchange of application layer routing information for VOIP signaling between service provider domains. You should read http://www.ietf.org/rfc/rfc2871.txt. -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 Jan 7 15:36:48 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 PAA27365 for ; Mon, 7 Jan 2002 15:36:48 -0500 (EST) 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 g07KC2o27011; Mon, 7 Jan 2002 15:12:02 -0500 Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g07K5Xo26917 for ; Mon, 7 Jan 2002 15:05:33 -0500 Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g07K5WW01402 for ; Mon, 7 Jan 2002 14:05:32 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g07K5Wt03850 for ; Mon, 7 Jan 2002 14:05:32 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jan 07 14:05:31 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 14:05:31 -0600 Message-ID: From: "Sean Olson (EUS)" To: "'Richard H. Gumpertz'" , "'Henning Schulzrinne'" Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] New draft RFC 2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C197B6.A7523830" 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, 7 Jan 2002 14:05:29 -0600 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_01C197B6.A7523830 Content-Type: text/plain; charset="iso-8859-1" > >I apologize if I am reopening something that has already been >beat to death... > >Why is space prohibited as a visual-separator in telephone >numbers? Yes, it has to be escaped, which can be ugly, but >the end-user may not see that escaping. End users may be >dealing with User Interfaces rather than raw URIs and so >enhanced readability of the URI is NOT the issue; enhanced >readability at the UI level is. Why not allow space as a >visual-separator so that such information can be preserved? You just answered your own question. This is a UI level thing. Why put this in the signalling? Personally, I don't care one way or the other whether visual separators are allowed. It is extremely trivial to write code for either case. I can't believe this topic has generated so much discussion. /sean ------_=_NextPart_001_01C197B6.A7523830 Content-Type: text/html; charset="iso-8859-1" RE: [IPTEL] New draft RFC 2806bis

>
>I apologize if I am reopening something that has already been
>beat to death...
>
>Why is space prohibited as a visual-separator in telephone
>numbers?  Yes, it has to be escaped, which can be ugly, but
>the end-user may not see that escaping.  End users may be
>dealing with User Interfaces rather than raw URIs and so
>enhanced readability of the URI is NOT the issue; enhanced
>readability at the UI level is.  Why not allow space as a
>visual-separator so that such information can be preserved?

You just answered your own question. This is a UI level thing.
Why put this in the signalling? Personally, I don't care one
way or the other whether visual separators are allowed. It is
extremely trivial to write code for either case. I can't believe
this topic has generated so much discussion.

/sean

------_=_NextPart_001_01C197B6.A7523830-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jan 7 15:52: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 PAA27711 for ; Mon, 7 Jan 2002 15:52:23 -0500 (EST) 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 g07KR8o27157; Mon, 7 Jan 2002 15:27:08 -0500 Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g07KQ5o27144 for ; Mon, 7 Jan 2002 15:26:06 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g07KPsZ05214 for ; Mon, 7 Jan 2002 15:25:59 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029) id 3C06950500825661; Mon, 7 Jan 2002 15:25:05 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] Query regarding application of TRIP Message-ID: <62DA45D4963FA747BA1B253E266760F901051565@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] Query regarding application of TRIP X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcGXs8Kasyv1QAOkEdaSygAAwCUaDwAAQ4IQ From: "Roy, Radhika R, ALASO" To: "vipin gahlaut" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id g07KQ6o27145 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, 7 Jan 2002 15:25:36 -0500 Content-Transfer-Encoding: 8bit Hi, Vipin: You are right that TRIP does not help for SIP-H.323 IWF interworking the way TRIP has been standardized now. TRIP just addresses for routing of the E.164/Decimel/PentaDecimel numbers for inter-ITAD (or inter-Domain) communications only. That is, communications are made among the location servers of different administrative Telephony domains. It does not deal with the GWs as well. It even does not address the propagation of capacity, QOS, and other attributes. It has a very limited use. However, IPTEL is now defining the GW registration protocol within a given ITAD (intra-ITAD or intra-Domain) where a GW can register all its attributes like address families, capacity, QOS, and others to a location server(that is, the problems of propagation of routes, capacity, QOS, and/or other attributes among the location servers are decoupled). For inter-Domain TRIP, a location server will get its necessary attributes (e.g., E.164/Decimel/PentaDecimel numbers) once the GWs register with it while the other attributes (e.g., capacity, QOS, etc.) will NOT be used for inter-Domain (or inter-ITAD) communications. For intra-Domain communications among the location servers and GWs (SIP-ISUP Tel GW, SIP-H.323 Tel GW), a complete proposal has been made how all the attributes (e.g., address families [E.164/Decimel/PentaDecimel, email IDs, URL IDs, etc], capacity, QOS, etc.) can be used. You can see the proposal in the following URL: (http://www.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt). With this, you can also use SIP-H.323 GWs for IP-IP communications. More discussions will be held along this line because we are only developing the GW registration protocol as a first step. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: vipin gahlaut [mailto:vipin_gahlaut@yahoo.co.in] Sent: Friday, January 04, 2002 6:05 AM To: iptel@lists.bell-labs.com Subject: [IPTEL] Query regarding application of TRIP Hi Everybody I am not very much clear about the application of TRIP,as in case of H323 and and SIP messages are exchanged from one IP to other IP. The route between these 2 IP can be selected by router already placed. why we need to implement TRIP?? I will be highly obliged if somebody clears my doubt. Thanks & Best Regards Vipin ____________________________________________________________ Do You Yahoo!? Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com _______________________________________________ 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 Mon Jan 7 16:31: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 QAA28498 for ; Mon, 7 Jan 2002 16:31:52 -0500 (EST) 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 g07L46o27733; Mon, 7 Jan 2002 16:04:06 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g07L3Oo27720 for ; Mon, 7 Jan 2002 16:03:24 -0500 Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g07L3kVZ008885; Mon, 7 Jan 2002 16:03:46 -0500 (EST) Message-ID: <3C3A0D13.70901@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Roy, Radhika R, ALASO" CC: vipin gahlaut , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Query regarding application of TRIP References: <62DA45D4963FA747BA1B253E266760F901051565@OCCLUST04EVS1.ugd.att.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, 07 Jan 2002 16:03:15 -0500 Content-Transfer-Encoding: 7bit Roy, Radhika R, ALASO wrote: > Hi, Vipin: > > You are right that TRIP does not help for SIP-H.323 IWF interworking the > way TRIP has been standardized now. TRIP just addresses for routing of > the E.164/Decimel/PentaDecimel numbers for inter-ITAD (or inter-Domain) > communications only. That is, communications are made among the location > servers of different administrative Telephony domains. It does not deal > with the GWs as well. It even does not address the propagation of > capacity, QOS, and other attributes. It has a very limited use. Radhika, little benefit is gained by using this question to field an unrelated barrange of attacks against TRIP. It serves only to confuse the person who asked the question and distract the group. Your posts are very much becoming disruptive and purposefully counter productive. TRIP does not address capacity, Qos, and other attribute propagation inter-domain for GOOD REASON. > For intra-Domain communications among the location servers and GWs > (SIP-ISUP Tel GW, SIP-H.323 Tel GW), a complete proposal has been made > how all the attributes (e.g., address families > [E.164/Decimel/PentaDecimel, email IDs, URL IDs, etc], capacity, QOS, > etc.) can be used. You can see the proposal in the following URL: > (http://www.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt). With > this, you can also use SIP-H.323 GWs for IP-IP communications. I have said it several times, and I will say it once more. This draft is out of scope. The group is not considering intra-domain communications. -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 Tue Jan 8 07:33: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 HAA19811 for ; Tue, 8 Jan 2002 07:33:43 -0500 (EST) 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 g08CVIo32243; Tue, 8 Jan 2002 07:31:18 -0500 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g08CUho32223 for ; Tue, 8 Jan 2002 07:30:43 -0500 Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g08CUeb11337; Tue, 8 Jan 2002 07:30:40 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 06:30:40 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAD8D@va02.va.neustar.com> From: "Peterson, Jon" To: "'Michael Hammer'" Cc: iptel Subject: RE: [IPTEL] draft meeting minutes 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: Tue, 8 Jan 2002 06:30:37 -0600 That may be true, and it's probably something we shouldn't lose sight of - however, we have made a clear choice of scope to focus on the gateway registration problem rather than the intradomain route propagation problem, for the moment. I think (Jonathan can correct me if I'm out of line) the prevailing philosophy of the WG is that we consider gw reg as its own problem, and if it turns out that the result has applicability to, say, intradomain route propagation, that's fine, but intradomain route propagation can't be a source of requirements for the gw reg problem. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Friday, January 04, 2002 3:56 PM > To: Peterson, Jon > Cc: iptel > Subject: RE: [IPTEL] draft meeting minutes > > > Jon, > > I am also assuming that, while some information may be > provisioned directly > into the LS or available through other protocol mechanisms, > much of the > data shared with peers internal or external to the > administrative domain > will be derived from the data learned through the GW-Reg. > So, there may be > stuff put in GW-reg because the follow-on protocols expect to > be able to > pass that data. > > Mike > > > At 05:19 PM 1/4/2002 -0600, Peterson, Jon wrote: > >I certainly think you have a valid concern; there definitely is a > >relationship between the attributes propagated by the > gateway registration > >protocol and the routing decisions (for call setup > signaling) made by the > >proxies that receive these registrations. TRIP strongly > couples the two - in > >fact, TRIP provides for three major functions: > > > >1) The protocol itself for propagating routes from one point > to the next > >2) Way of making forwarding decisions for calls based on > discriminators > >propagated in the protocol (TRIBs) > >3) Way of deciding what routes you will share with peers > > > >By ruling intradomain route propagation outside of the scope > of the gw reg > >deliverable, we've essentially made the third item above out > of scope. None > >of our existing requirements, I think, really address the > second problem - > >nor have we necessarily agreed that this problem is even in > the scope of > >gateway registration. I'd really like to hear people's > opinions about that. > > > >I definitely agree that discriminators should provide enough > data to allow > >meaningful routing decisions to be made by proxy servers; > however, I don't > >think we should wed discriminators to any particular routing > philosophy. I > >think ideally, the set of discriminators should be flexible > enough to enable > >any of the hop-off philosophies you describe below, > depending on the policy > >of the service provider accepting gateway registrations (a > little MAAP, I > >know). I would be really cautious about any gw reg protocol > that seemed to > >limit the sort of forwarding decisions that might be made > within the proxy > >server. > > > >Note that, as I understand it, TRIP builds in some > limitations here (like > >hierarchical discriminators). > > > >Jon Peterson > >NeuStar, Inc. > > > > > -----Original Message----- > > > From: Michael Hammer [mailto:mhammer@cisco.com] > > > Sent: Thursday, January 03, 2002 7:47 AM > > > To: Peterson, Jon > > > Cc: iptel > > > Subject: RE: [IPTEL] draft meeting minutes > > > > > > > > > Yes, I think our perspectives are consistent. What I have a > > > problem with > > > is getting wrapped around the axle with propagating routing > > > information > > > across the network, that in the end may not provide a useful > > > discriminator > > > for choosing one route over another. What makes one gateway > > > hop-off point > > > better than another? > > > > > > Are we minimizing PSTN (or other) network administrations > > > that we must cross? > > > Are we minimizing conversion points (RTP to TDM) that may > > > introduce noise? > > > Can a network capacity re-seller reduce the number of billing > > > relationships? > > > > > > My starting axiom was that the call was routed into the IP > > > world or started > > > there for a reason, and that IP was the preferred path to > > > effectively make > > > all calls local. Your point that the existing CIC codes are > > > inherently > > > geographical on a large scale also points to the possible > > > need to define > > > geographic attributes on a smaller scale as well. > > > > > > Mike > > > > > > > > > At 02:49 AM 1/3/2002 -0600, Peterson, Jon wrote: > > > > > > >I don't think we're really disagreeing about much of what > > > you say below. I > > > >agree with your account of how things operate in the PSTN. > > > It sounds like we > > > >agree that the relationship of CICs to TGs is not in any > simple way > > > >hierarchical. > > > > > > > >The primary purpose of my note on the CIC was to suggest a > > > potential litmus > > > >test for whether or not a CIC was routable through a TG. I > > > think that's an > > > >important definition for us all to agree on if we're going > > > to consider > > > >propagating attributes like CICs in the gw reg protocol. > > > > > > > >In answer to the question you pose, I think my contention > > > here is that one > > > >logical trunk group could have more than one CIC associated > > > with it. Imagine > > > >a trivial VoIP network containing one proxy server and one > > > PSTN gateway in > > > >which the gateway had a single trunk group aimed at an > access tandem. > > > >Clearly, that trunk group would be the route for all CICs > > > irrespective of > > > >whether it was directly or indirectly connected to any > given carrier. > > > >Introduce a second trunk group going to a different access > > > tandem, and > > > >perhaps this trunk group would be a better route for some > > > set of CICs. But > > > >in neither case would you want to construct, say, one > > > logical trunk group > > > >per CIC and overlay them all on the physical trunk(s) - that > > > would be quite > > > >an administrative headache. > > > > > > > >I'm not sure I necessarily agree that the question with CICs > > > is "how to > > > >route such that the PSTN path is minimized at the expense of > > > a more direct > > > >IP path", or even that this is necessarily a least-cost > > > problem. There have > > > >been significant head-end hop-off vs. tail-end hop-off > > > arguments with regard > > > >to CIC routing levied here in the past. Fortunately, I > think this is > > > >ultimately a routing policy question, and really any of > > > these philosophies > > > >could be enabled by the CIC propagation systems we're > > > discussing above. > > > > > > > >And, my final statement in my previous mail was intended > > > only to illustrate > > > >that CICs are national in scope - that's all. > > > > > > > >Jon Peterson > > > >NeuStar, Inc. > > > > > > > > > -----Original Message----- > > > > > From: Michael Hammer [mailto:mhammer@cisco.com] > > > > > Sent: Wednesday, January 02, 2002 4:41 PM > > > > > To: Peterson, Jon > > > > > Cc: iptel > > > > > Subject: RE: [IPTEL] draft meeting minutes > > > > > > > > > > > > > > > Jon, > > > > > > > > > > Carrier IDs are used as an attribute to affect routing. > > > > > Carriers have > > > > > multiple switching points that can be contacted through > > > some type of > > > > > signaling address. Within a switching center, there are > > > > > multiple trunk > > > > > groups to other switching centers which may belong to the > > > > > same carrier or > > > > > different carriers. Choosing a TG from that switching center > > > > > determines > > > > > what next switching center the call can be routed to, and by > > > > > inference, > > > > > what the next hop carrier will be. Therefore, the carrier ID > > > > > can determine > > > > > what TG will be selected from that switching center. > > > > > > > > > > The originating side wants to route to a given carrier and > > > > > location and > > > > > uses the inferred signaling address. The destination side > > > > > maps the carrier > > > > > to an appropriate trunk group to get to that carrier and > > > > > destination user > > > > > address. > > > > > > > > > > The 101 prefix dialing is just a method of indicating the > > > > > carrier to use at > > > > > by the switch terminating the local loop. The fact that the > > > > > next switching > > > > > center can reach another carrier through another TG would be > > > > > irrelevant, if > > > > > the information was facility-based and not subverted > by business > > > > > arrangements. But, given those business arrangements, > > > what you are > > > > > pointing out is that the CIC:TG relationship is not > > > > > hierarchical and thus a > > > > > TG could have multiple carriers associated with it. That > > > > > holds true if > > > > > circuits are shared across carriers and the originating > > > user is not > > > > > affected by this business arrangement (i.e. charged for > > > the next-hop > > > > > facilities used to reach the desired carrier). > > > > > > > > > > Question 1: If 2 carriers were reach able over the same T-3, > > > > > with one > > > > > directly reachable and the other indirectly reachable, would > > > > > the gateway > > > > > almost always allocate the one physical facility as 2 logical > > > > > trunk groups > > > > > anyway? (Thus restoring the TG infers CIC mapping.) > > > > > > > > > > We already know that any switch in the PSTN can reach any > > > > > other. The real > > > > > question is how to route such that the PSTN path is > > > minimized at the > > > > > expense of a more direct IP path (assumes that is the > least cost > > > > > path). The use of TG data should be of local significance > > > > > only at the > > > > > egress of the IP network. > > > > > > > > > > I agree with your call for some type of geographic attribute. > > > > > But, I don't > > > > > understand your final statement. I don't want to see > > > > > carrier's charges on > > > > > my bill, if as the caller I specify a particular > long-distance or > > > > > international carrier. Also, will the CIC always be based on > > > > > national body > > > > > registration, or will IANA or someone ever assign > > > > > international CIC codes > > > > > for global carriers? > > > > > > > > > > Mike > > > > > > > > > > > > > > > At 05:37 AM 12/31/2001 -0600, Peterson, Jon wrote: > > > > > > > > > > >I wanted to speak a bit to the issue from the minutes below > > > > > regarding the > > > > > >ubiquitous availability of carriers through trunks in the > > > > > PSTN, and the > > > > > >relevance of the 'equal access' concept - especially since > > > > > this a matter on > > > > > >which Dave and I have differed for some time. > > > > > > > > > > > >There are a number of ways (thanks to equal access > > > > > provisions) that a user > > > > > >can directly or indirectly select a carrier, for example: > > > > > > > > > > > >- Having an entry in the LIDB for their address > > > > > corresponding to the Carrier > > > > > >Identification Code of their chosen carrier, so that > > > > > inter-exchange calls > > > > > >generated from their address always pick up this CIC > > > (i.e. PIC LD). > > > > > > > > > > > >- Using a dial-around (101+XXX+address) to override the > > > > > default CIC for > > > > > >their line. > > > > > > > > > > > >- Dialing a freephone number whose SMS/800 dip returns a > > > CIC code - > > > > > >presumably once the call has been routed to the > > > > > administrative domain of the > > > > > >carrier, a further internal dip will be performed to > > > > > translate the freephone > > > > > >number into a geographic number. > > > > > > > > > > > >Dave is certainly correct that a CIC does not necessarily > > > > > correspond to some > > > > > >physical network - that is, the concept of a 'carrier' > > > > > chosen by a user is > > > > > >largely a matter of who issues your bill, not what physical > > > > > infrastructure > > > > > >your call crosses. For example, there are resellers of > > > > > long-distance service > > > > > >whose CICs are really just aliases for the CIC of a major > > > > > carrier. Large > > > > > >carriers may own several CICs they use to target their > > > services. It's > > > > > >certainly not some kind of one-to-one mapping from CICs > > > to physical > > > > > >infrastructure. > > > > > > > > > > > >HOWEVER, this doesn't mean that a decision isn't made, in > > > > > some places in the > > > > > >telephone network, about how a call is routed based on the > > > > > CIC. In SS7, when > > > > > >a CIC has been selected for a call, it is carried within > > > the TNS or > > > > > >(ANSIfied) CIC parameter of the Initial Address Message. The > > > > > presence of > > > > > >this parameter modifies how a call is routed through the > > > > > telephone network, > > > > > >especially at tandems. > > > > > > > > > > > >So, to bring this matter back to trunk groups, one view > > > > > might be that a > > > > > >given trunk group may be considered to be a route to a CIC > > > > > if, when an SS7 > > > > > >IAM message carrying this CIC is sent over the trunk group, > > > > > this call will > > > > > >(eventually) be routed to the administrative domain > > > > > responsible for the CIC > > > > > >(and presumably get delivered appropriately). One might > > > > > contend, as an > > > > > >opposing position, that only the carrier that owns the > > > > > switch on the far > > > > > >side of the trunk should be considered to be reachable > > > > > through a trunk - but > > > > > >I suspect that in an overflow situation most network would > > > > > be content to > > > > > >send calls for some other carrier through such a trunk > > > > > group, even if it > > > > > >introduced a middle-man network, complicating routing > > > and potentially > > > > > >settlement. > > > > > > > > > > > >The correct position is probably somewhere in the middle. > > > > > One or more CICs > > > > > >may be 'preferred' for a particular trunk by some switch in > > > > > the network, > > > > > >largely because of who happens to own the equipment on the > > > > > other side, but > > > > > >in addition all CICs are usually 'available' through such > > > > > trunks. Something > > > > > >similar, I think, is true of E.164 numbers; certain ranges > > > > > may be preferred > > > > > >(due to settlement concerns) for particular trunk groups, > > > > > but all number > > > > > >ranges are usually available. > > > > > > > > > > > >Finally, it's important to note that CICs are national in > > > > > scope, and that > > > > > >therefore trunk groups are most likely only routes to the > > > > > set of CICs within > > > > > >a particular nationality. There have been suggestions in the > > > > > past that > > > > > >identifiers for CICs in the gw reg mechanism should be > > > > > concatenated with > > > > > >some sort of country code to provide a scope of a CIC - I > > > > > would agree that > > > > > >this is probably necessary. Then we could refine our > > > > > characterization of > > > > > >trunk group CIC routes to one in which all carriers for a > > > > > given nationality > > > > > >could be 'available' through a trunk group. > > > > > > > > > > > >Jon Peterson > > > > > >NeuStar, Inc. > > > > > > > > > > > > > Further discussion: > > > > > > > > > > > > > > Jon said that he believes this should always be about TGs > > > > > - believes > > > > > > > should treat PRI as a trunk. Cullen asked whether there > > > > > would ever be > > > > > > > more than one carrier on a single trunk? Jon said > > > that there are a > > > > > > > number of carriers for virtually every trunk. Due to EA. > > > > > Dave Oran > > > > > > > responded that this has nothing to do with it, as the EA > > > > > concept user > > > > > > > experience doesn't necessarily relate. Take it > to the list. > > > > > > > > > > > > > >_______________________________________________ > > > > > >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 > > > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jan 8 09:25:12 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 JAA22857 for ; Tue, 8 Jan 2002 09:25:12 -0500 (EST) 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 g08E57o00440; Tue, 8 Jan 2002 09:05:08 -0500 Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g08E48o00418 for ; Tue, 8 Jan 2002 09:04:08 -0500 Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g08E47b01222; Tue, 8 Jan 2002 08:04:07 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 08:04:07 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAD8E@va02.va.neustar.com> From: "Peterson, Jon" To: "'Mpierce1@aol.com'" , iptel@lists.bell-labs.com, mhammer@cisco.com Subject: RE: [IPTEL] Definition of "trunk group" 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: Tue, 8 Jan 2002 08:03:56 -0600 I think I understand our disconnect after reading this mail; towards the end I offer a fairly lengthy example which hopefully illustrates where I'm coming from. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > Sent: Sunday, January 06, 2002 4:35 PM > To: jon.peterson@neustar.biz; iptel@lists.bell-labs.com; > mhammer@cisco.com > Subject: Re: [IPTEL] Definition of "trunk group" > > [snip] > There is a fundamental > difficulty, since > the network architecture requires that many trunk groups > handle all traffic, > regardless of the CIC or destination address specified, but the route > propagation is based on a different concept. I don't think route propagation is based on a 'different concept' - I think we need to reconcile gateway registration to the realities of network architecture. That's been the overriding thread of my many mails on gateway registration and trunk groups. > > Regardless of the functions of "route propagation", it seems > to me that the > function of "routing" still means that interpretation of the > CIC (and other > dialed information) results in the selection of an ordered > list of trunk > groups (physical facilities) by which a call can be routed > (called a "route > list" in T1.523). Totally. I'm with you there. The construction of that route list will be performed within the proxy server that is provisioned by the gateway registration process. Thanks to all of the timely information it has learned from gw reg, the proxy server will construct a list that will be more likely to result in the prompt termination of the call than it would if it had no gw reg data. It will make this decision by inspecting the signaling for call setup (including the dialed number, a CIC if available, and so forth), and comparing these criteria with the attributes it has learned from the gw reg process, which tell the PS what possible terminations are available. > I especially have a concern with your > statement that "CICs > might be 'available' or 'preferred' with regard to a > particular trunk group > has no corrollary in traditional telephone networks". I don't > think this > statement represents the required routing logic (independent > of how this > information is propogated). The concepts of 'available' and 'preferred' in and of themselves, of course, do not represent the required routing logic. They are just data that are taken into account by the routing logic in a proxy server in order to construct a route list for a particular call. Incidentally, I'm not married to the terms 'preferred' and 'available'. I brought them up to give a sense of the role they might play in the construction of route lists. Probably better terms would be 'directly' and 'indirectly' available, where a CIC is 'directly' available through a trunk group iff the administrative domain of the switch on the other side of the trunk group is the administrative domain responsible for that CIC. > I believe the required routing > logic does have a > direct corrollary in the traditional telephone network. The > concepts of > "available" and "preferred" are included by the ordered list > of trunk groups. > (The first trunk group is preferred, the second is preferred > next, etc. All > in the list are available.) This is good - I think this is where our disconnect is. The problem I'm trying to solve is 'how does a proxy server construct an ordered route list for a particular call based on the information it receives from gateway registrations?". When you talk about how CICs are routed, you seem to assume that this route list has been provisioned by some other means, or that the information propagated by gw reg literally is the route list. Here's how I think it should work: The information that is propagated by the gateway registration protocol is a set of potential routes, just a set of TGs and some of the attributes of these trunk groups. These because actual routes for a specific call later, when a proxy server makes a routing decision. Consider a simplified example. A proxy server (PS) receives gateway registrations for three trunk groups, TG1, TG2 and TG3. For TG1, CIC 0288 is "preferred" and all other CICs are "available". For TG2, only CIC 5062 is "preferred". For TG3, all CICs are "available". These are the potential routes. Now imagine that a call comes to the PS, and the PS is required to make a routing decision - to construct the actual route list. We'll say that the call is for CIC 0288. The PS constructs, on the basis of the gateway registrations it has received, an ordered route list of: TG1, TG3. Why? TG1 is first because it is the only available trunk group that is "preferred" for the CIC associated with the call. TG2 is ineligible because 0288 is not available through TG2. TG3 is "available" for 0288 (as it is for all CICs), so it ends up on the route list as a less preferred option than TG1. With the route list for the call in mind, the PS routes forwards the call to the GW responsible for TG1. If the call doesn't succeed there for some avoidable reason, the PS will subsequently forward the call to the GW responsible for TG3. As a bit of back-story, how do the owners of the GWs decide on the "preferred" and "available" settings for their TGs with respect to particular CICs? Well, when the owner of the gateway on which TG1 is located turned up TG1, he provisioned the GW with a set of information about TG1. Maybe he learned this information directly from the carrier whose switch terminates the other end of TG1 - maybe he looked some of it up in the LERG - in any event he learns this information administratively. One such piece of information is that the carrier on the other side of TG1 (to which TG1 is "directly" connected) is addressed by CIC 0288. He also knows that this carrier is an IXC, and that all CICs are therefore "indirectly" available through this carrier. Finally, note that when a call arrives at the PS, it has many routable attributes other than a CIC. Calls also, for example, have a dialed number. The route selection algorithm in the PS, however, decided that it should look at the CIC before the dialed number, and use the CIC to figure out how to route the call, and that it should prefer "directly" available routes to "indirectly" available routes, and so on. This route selection algorithm, in my opinion, should if possible be independent of the gateway registration protocol - that is to say, the gw reg protocol should just provide the data and let the PS worry about how that data will be used to route calls. > The difficulty with indicating > "preferred" and > "available" in the route progagation procedure is that it can > not indicate an > actual order to be used in the actual route selection. Agreed, it can't. All it does, as my example above should show, is give the PS some data that is used by the route selection algorithm. This is critical because I don't think gateway registration should control the route selection algorithm itself - for example, by somehow providing an ordered list of TGs to the PS that will apply to some set of calls. Multiple gateways will be sending routes for various trunk groups to the PS in a gw reg message. Presumably, these gateways do not know about one another. The PS receives routes from these various gateways, and for a particular call the PS should be allowed to add TGs located on various GWs to the route list - therefore no GW should be dictating route lists to the PS. But with a few simple principles (prefer directly available routes to indirectly available routes, etc) for a route selection algorithm, the PS can make a good route list based on the data it receives. This is, in my opinion, the whole purpose of gateway registration. > > It seems that there must first be a common agreement on what routing > procedures are required. Only then can route propogation > procedures be > defined. > > Mike Pierce > Artel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jan 8 09:57: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 JAA24260 for ; Tue, 8 Jan 2002 09:57:37 -0500 (EST) 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 g08Eu7o00818; Tue, 8 Jan 2002 09:56:07 -0500 Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g08EtMo00797 for ; Tue, 8 Jan 2002 09:55:23 -0500 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g08Esxt26266; Tue, 8 Jan 2002 09:54:59 -0500 (EST) 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 g08EsuF00445; Tue, 8 Jan 2002 09:54:56 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 09:53:23 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102ADED@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Peterson, Jon'" Cc: "'Mpierce1@aol.com'" , iptel@lists.bell-labs.com, mhammer@cisco.com Subject: RE: [IPTEL] Definition of "trunk group" X-Mailer: Internet Mail Service (5.5.2653.19) 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, 8 Jan 2002 09:53:48 -0500 I think you're on the right track, Jon. There are basically two possibilities: that registration provides the data from which route lists can be constructed, as you suggest, or that proxies contain pre-defined route lists and registration data is used to verify the validity of individual entries within these lists. I agree with your argument that, because route lists will typically span multiple gateways, the registration data do not consist of route lists in themselves. If we accept your view, the aim of the exercise is to acquire registration data which support the construction of "good" route lists according to some criterion. What your examples illustrate for that criterion is a very rough topological distance measure: "direct" vs. "indirect" (assuming these are exactly what you meant by "preferred" vs. "alternate"). The "points" in this topology are individual service providers' networks. The questions raised if we follow this line are whether other measures of "goodness" have to be supported by the registration data and if so, which ones. Speaking of topology, at some point we may have to worry about loop prevention. One assumes that loops won't happen provided that a call passed to the switched domain stays there, but we can't count on that. This is probably a call signalling issue -- I'll try to see that it is addressed in the SIP-ISUP work being done in Study Group 11. Just pursuing the second alternative I mentioned in my opening paragraph for a moment: there is the possibility of a statically administered set of route lists within proxies. The role of gateway registration would then be to give a dynamic view of gateway and trunk group status, to make routing more effective within the preprovisioned framework. Given what I see as the slowly-varying nature of the switched network topology as I used the term above, preprovisioned routes could be "better" than those created dynamically, promote more stable network operation, yet gateway registration would provide an essential element of adaptiveness. I describe this alternative for logical completeness, but I expect it is a less-preferred method of operation. We can probably design gateway registration to support either method of operation. However, the detailed information requirements and possibly the required reporting frequency may be different between them. -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Tuesday, January 08, 2002 9:04 AM To: 'Mpierce1@aol.com'; iptel@lists.bell-labs.com; mhammer@cisco.com Subject: RE: [IPTEL] Definition of "trunk group" I think I understand our disconnect after reading this mail; towards the end I offer a fairly lengthy example which hopefully illustrates where I'm coming from. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > Sent: Sunday, January 06, 2002 4:35 PM > To: jon.peterson@neustar.biz; iptel@lists.bell-labs.com; > mhammer@cisco.com > Subject: Re: [IPTEL] Definition of "trunk group" > > [snip] > There is a fundamental > difficulty, since > the network architecture requires that many trunk groups > handle all traffic, > regardless of the CIC or destination address specified, but the route > propagation is based on a different concept. I don't think route propagation is based on a 'different concept' - I think we need to reconcile gateway registration to the realities of network architecture. That's been the overriding thread of my many mails on gateway registration and trunk groups. > > Regardless of the functions of "route propagation", it seems > to me that the > function of "routing" still means that interpretation of the > CIC (and other > dialed information) results in the selection of an ordered > list of trunk > groups (physical facilities) by which a call can be routed > (called a "route > list" in T1.523). Totally. I'm with you there. The construction of that route list will be performed within the proxy server that is provisioned by the gateway registration process. Thanks to all of the timely information it has learned from gw reg, the proxy server will construct a list that will be more likely to result in the prompt termination of the call than it would if it had no gw reg data. It will make this decision by inspecting the signaling for call setup (including the dialed number, a CIC if available, and so forth), and comparing these criteria with the attributes it has learned from the gw reg process, which tell the PS what possible terminations are available. > I especially have a concern with your > statement that "CICs > might be 'available' or 'preferred' with regard to a > particular trunk group > has no corrollary in traditional telephone networks". I don't > think this > statement represents the required routing logic (independent > of how this > information is propogated). The concepts of 'available' and 'preferred' in and of themselves, of course, do not represent the required routing logic. They are just data that are taken into account by the routing logic in a proxy server in order to construct a route list for a particular call. Incidentally, I'm not married to the terms 'preferred' and 'available'. I brought them up to give a sense of the role they might play in the construction of route lists. Probably better terms would be 'directly' and 'indirectly' available, where a CIC is 'directly' available through a trunk group iff the administrative domain of the switch on the other side of the trunk group is the administrative domain responsible for that CIC. > I believe the required routing > logic does have a > direct corrollary in the traditional telephone network. The > concepts of > "available" and "preferred" are included by the ordered list > of trunk groups. > (The first trunk group is preferred, the second is preferred > next, etc. All > in the list are available.) This is good - I think this is where our disconnect is. The problem I'm trying to solve is 'how does a proxy server construct an ordered route list for a particular call based on the information it receives from gateway registrations?". When you talk about how CICs are routed, you seem to assume that this route list has been provisioned by some other means, or that the information propagated by gw reg literally is the route list. Here's how I think it should work: The information that is propagated by the gateway registration protocol is a set of potential routes, just a set of TGs and some of the attributes of these trunk groups. These because actual routes for a specific call later, when a proxy server makes a routing decision. Consider a simplified example. A proxy server (PS) receives gateway registrations for three trunk groups, TG1, TG2 and TG3. For TG1, CIC 0288 is "preferred" and all other CICs are "available". For TG2, only CIC 5062 is "preferred". For TG3, all CICs are "available". These are the potential routes. Now imagine that a call comes to the PS, and the PS is required to make a routing decision - to construct the actual route list. We'll say that the call is for CIC 0288. The PS constructs, on the basis of the gateway registrations it has received, an ordered route list of: TG1, TG3. Why? TG1 is first because it is the only available trunk group that is "preferred" for the CIC associated with the call. TG2 is ineligible because 0288 is not available through TG2. TG3 is "available" for 0288 (as it is for all CICs), so it ends up on the route list as a less preferred option than TG1. With the route list for the call in mind, the PS routes forwards the call to the GW responsible for TG1. If the call doesn't succeed there for some avoidable reason, the PS will subsequently forward the call to the GW responsible for TG3. As a bit of back-story, how do the owners of the GWs decide on the "preferred" and "available" settings for their TGs with respect to particular CICs? Well, when the owner of the gateway on which TG1 is located turned up TG1, he provisioned the GW with a set of information about TG1. Maybe he learned this information directly from the carrier whose switch terminates the other end of TG1 - maybe he looked some of it up in the LERG - in any event he learns this information administratively. One such piece of information is that the carrier on the other side of TG1 (to which TG1 is "directly" connected) is addressed by CIC 0288. He also knows that this carrier is an IXC, and that all CICs are therefore "indirectly" available through this carrier. Finally, note that when a call arrives at the PS, it has many routable attributes other than a CIC. Calls also, for example, have a dialed number. The route selection algorithm in the PS, however, decided that it should look at the CIC before the dialed number, and use the CIC to figure out how to route the call, and that it should prefer "directly" available routes to "indirectly" available routes, and so on. This route selection algorithm, in my opinion, should if possible be independent of the gateway registration protocol - that is to say, the gw reg protocol should just provide the data and let the PS worry about how that data will be used to route calls. > The difficulty with indicating > "preferred" and > "available" in the route progagation procedure is that it can > not indicate an > actual order to be used in the actual route selection. Agreed, it can't. All it does, as my example above should show, is give the PS some data that is used by the route selection algorithm. This is critical because I don't think gateway registration should control the route selection algorithm itself - for example, by somehow providing an ordered list of TGs to the PS that will apply to some set of calls. Multiple gateways will be sending routes for various trunk groups to the PS in a gw reg message. Presumably, these gateways do not know about one another. The PS receives routes from these various gateways, and for a particular call the PS should be allowed to add TGs located on various GWs to the route list - therefore no GW should be dictating route lists to the PS. But with a few simple principles (prefer directly available routes to indirectly available routes, etc) for a route selection algorithm, the PS can make a good route list based on the data it receives. This is, in my opinion, the whole purpose of gateway registration. > > It seems that there must first be a common agreement on what routing > procedures are required. Only then can route propogation > procedures be > defined. > > Mike Pierce > Artel > _______________________________________________ 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 Jan 8 10:28:45 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 KAA25399 for ; Tue, 8 Jan 2002 10:28:45 -0500 (EST) 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 g08FR7o01021; Tue, 8 Jan 2002 10:27:07 -0500 Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g08FQRo01008 for ; Tue, 8 Jan 2002 10:26:27 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g08FQIW04783 for ; Tue, 8 Jan 2002 10:26:18 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029) id 3C0695050085A528; Tue, 8 Jan 2002 10:24:58 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] draft meeting minutes Message-ID: <62DA45D4963FA747BA1B253E266760F9010517FD@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] draft meeting minutes Thread-Index: AcGYQ9cBN9ynYwQwEdaY2QCQJ3s6pwAEUnHA X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Roy, Radhika R, ALASO" To: "Peterson, Jon" , "Michael Hammer" Cc: "iptel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id g08FQRo01009 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, 8 Jan 2002 10:25:32 -0500 Content-Transfer-Encoding: 8bit Please see comments inline [RRR]. -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Tuesday, January 08, 2002 7:31 AM To: 'Michael Hammer' Cc: iptel Subject: RE: [IPTEL] draft meeting minutes That may be true, and it's probably something we shouldn't lose sight of - however, we have made a clear choice of scope to focus on the gateway registration problem rather than the intradomain route propagation problem, for the moment. [RRR] I would rather agree with this because I have made a contribution for the complete protocol set ((http://www.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt)) for intra-Domain because the intra-Domain requires the following: 1. GW <-> LS communications and 2. LS <-> LS communications. [RRR] For the sake of making progress, I would rather propose, as Jon pointed out, let us start item 1 first (GW <-> LS) where registration and discovery are the most important features. The reason is that, in an intra-Domain, many GWs and one location server may a good start for a small network. In some cases, a single location server may be good enough among multiple SIP proxies (assuming proprietary protocol is used between the SIP proxies and the LS when they are not colocated). [RRR] However, we also need to address the item 2 sooner or later (and the above draft is a good start) because a large network will have multiple location servers. I think (Jonathan can correct me if I'm out of line) the prevailing philosophy of the WG is that we consider gw reg as its own problem, and if it turns out that the result has applicability to, say, intradomain route propagation, that's fine, but intradomain route propagation can't be a source of requirements for the gw reg problem. [RRR] A good test will be to look into the draft as referred above. But you are right that we need to address the intra-Domain communications at some point of time. In the meantime, I have sent a draft proposing the "Framework on Intra-Domain Communications Protocol." While we are developing the GW registration protocol, we can also keep our eyes open how the complete picture will look like when think about the "Intra-Domain" protocol. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Friday, January 04, 2002 3:56 PM > To: Peterson, Jon > Cc: iptel > Subject: RE: [IPTEL] draft meeting minutes > > > Jon, > > I am also assuming that, while some information may be > provisioned directly > into the LS or available through other protocol mechanisms, > much of the > data shared with peers internal or external to the > administrative domain > will be derived from the data learned through the GW-Reg. > So, there may be > stuff put in GW-reg because the follow-on protocols expect to > be able to > pass that data. > > Mike > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jan 8 10:37: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 KAA25889 for ; Tue, 8 Jan 2002 10:37:02 -0500 (EST) 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 g08FZ2o01106; Tue, 8 Jan 2002 10:35:02 -0500 Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g08FWCo01061 for ; Tue, 8 Jan 2002 10:32:12 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g08FVxn13223 for ; Tue, 8 Jan 2002 10:32:03 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029) id 3C0695050085AC96; Tue, 8 Jan 2002 10:30:51 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] Query regarding application of TRIP Message-ID: <62DA45D4963FA747BA1B253E266760F901051814@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] Query regarding application of TRIP Thread-Index: AcGXvsIeTVHfjwOxEdajbgCQJ60IGQAkuP0A X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Roy, Radhika R, ALASO" To: "Jonathan Rosenberg" Cc: "vipin gahlaut" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id g08FWOo01063 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, 8 Jan 2002 10:31:29 -0500 Content-Transfer-Encoding: 8bit Please see inline [RRR]. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, January 07, 2002 4:03 PM To: Roy, Radhika R, ALASO Cc: vipin gahlaut; iptel@lists.bell-labs.com Subject: Re: [IPTEL] Query regarding application of TRIP Roy, Radhika R, ALASO wrote: > Hi, Vipin: > > You are right that TRIP does not help for SIP-H.323 IWF interworking the > way TRIP has been standardized now. TRIP just addresses for routing of > the E.164/Decimel/PentaDecimel numbers for inter-ITAD (or inter-Domain) > communications only. That is, communications are made among the location > servers of different administrative Telephony domains. It does not deal > with the GWs as well. It even does not address the propagation of > capacity, QOS, and other attributes. It has a very limited use. Radhika, little benefit is gained by using this question to field an unrelated barrange of attacks against TRIP. It serves only to confuse the person who asked the question and distract the group. Your posts are very much becoming disruptive and purposefully counter productive. [RRR] This is what people like to know about TRIP from technical point of view (its weaknesses and strengths - modeled in the light of BGP). It is rather technical clarifications. TRIP does not address capacity, Qos, and other attribute propagation inter-domain for GOOD REASON. [RRR] This is the point that people like to know. It is rather technical clarifications (because some people think that something that is not used by TRIP is also NOT good for the GW registration protocol or otherwise). > For intra-Domain communications among the location servers and GWs > (SIP-ISUP Tel GW, SIP-H.323 Tel GW), a complete proposal has been made > how all the attributes (e.g., address families > [E.164/Decimel/PentaDecimel, email IDs, URL IDs, etc], capacity, QOS, > etc.) can be used. You can see the proposal in the following URL: > (http://www.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt). With > this, you can also use SIP-H.323 GWs for IP-IP communications. I have said it several times, and I will say it once more. This draft is out of scope. The group is not considering intra-domain communications. [RRR] The above draft has been referred to answer the questions of Vipin. If something is not a WG charter item now, it may be considered later. (If it takes too much time to make it is a WG charter, it can be considered for the informational RFC if we think to do so). [RRR] This draft has sent to see what comes out of the technical discussion. We have to see how the technical discussion on GW registration protocol goes on. This draft has many things and the GW registration and discovery are also a part of it in the context of the intra-Domain protocol. We have seen most of the technical discussion that is going on related to the GW registration protocol has been influenced by this draft. For example, all types of GWs will have the common attributes like address families, capacity, QOS, and others that can be registered with the location server. [RRR] Please also see another email sent in response to Jon Peterson's questions. This will also clarify more how the above draft is contributing to advance the goals of the IPTEL WG. -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 Tue Jan 8 12:04:46 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 MAA00057 for ; Tue, 8 Jan 2002 12:04:46 -0500 (EST) 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 g08Gc4o01794; Tue, 8 Jan 2002 11:38:08 -0500 Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g08GbRo01781 for ; Tue, 8 Jan 2002 11:37:27 -0500 Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA21489; Tue, 8 Jan 2002 11:37:21 -0500 (EST) 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 AAH46385; Tue, 8 Jan 2002 11:32:59 -0500 (EST) Message-Id: <4.3.2.7.2.20020108114049.00b99e18@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Tom-PT Taylor" From: Michael Hammer Subject: RE: [IPTEL] Definition of "trunk group" Cc: "'Peterson, Jon'" , "'Mpierce1@aol.com'" , iptel@lists.bell-labs.com In-Reply-To: <4D79C746863DD51197690002A52CDA000102ADED@zcard0kc.ca.norte l.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: Tue, 08 Jan 2002 11:43:44 -0500 Tom, Jon, I concur with your line of thought, although I think the terms "direct" and "indirect" are more descriptive and useful. Will these characteristics be propagated as attributes when advertising that a TG can reach a specific carrier? Mike At 09:53 AM 1/8/2002 -0500, Tom-PT Taylor wrote: >I think you're on the right track, Jon. There are basically two >possibilities: that registration provides the data from which route lists >can be constructed, as you suggest, or that proxies contain pre-defined >route lists and registration data is used to verify the validity of >individual entries within these lists. I agree with your argument that, >because route lists will typically span multiple gateways, the registration >data do not consist of route lists in themselves. > >If we accept your view, the aim of the exercise is to acquire registration >data which support the construction of "good" route lists according to some >criterion. What your examples illustrate for that criterion is a very rough >topological distance measure: "direct" vs. "indirect" (assuming these are >exactly what you meant by "preferred" vs. "alternate"). The "points" in >this topology are individual service providers' networks. The questions >raised if we follow this line are whether other measures of "goodness" have >to be supported by the registration data and if so, which ones. > >Speaking of topology, at some point we may have to worry about loop >prevention. One assumes that loops won't happen provided that a call passed >to the switched domain stays there, but we can't count on that. This is >probably a call signalling issue -- I'll try to see that it is addressed in >the SIP-ISUP work being done in Study Group 11. > >Just pursuing the second alternative I mentioned in my opening paragraph for >a moment: there is the possibility of a statically administered set of route >lists within proxies. The role of gateway registration would then be to >give a dynamic view of gateway and trunk group status, to make routing more >effective within the preprovisioned framework. Given what I see as the >slowly-varying nature of the switched network topology as I used the term >above, preprovisioned routes could be "better" than those created >dynamically, promote more stable network operation, yet gateway registration >would provide an essential element of adaptiveness. I describe this >alternative for logical completeness, but I expect it is a less-preferred >method of operation. > >We can probably design gateway registration to support either method of >operation. However, the detailed information requirements and possibly the >required reporting frequency may be different between them. > > >-----Original Message----- >From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >Sent: Tuesday, January 08, 2002 9:04 AM >To: 'Mpierce1@aol.com'; iptel@lists.bell-labs.com; mhammer@cisco.com >Subject: RE: [IPTEL] Definition of "trunk group" > > > >I think I understand our disconnect after reading this mail; towards the end >I offer a fairly lengthy example which hopefully illustrates where I'm >coming from. > >Jon Peterson >NeuStar, Inc. > > > -----Original Message----- > > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > > Sent: Sunday, January 06, 2002 4:35 PM > > To: jon.peterson@neustar.biz; iptel@lists.bell-labs.com; > > mhammer@cisco.com > > Subject: Re: [IPTEL] Definition of "trunk group" > > > > >[snip] > > There is a fundamental > > difficulty, since > > the network architecture requires that many trunk groups > > handle all traffic, > > regardless of the CIC or destination address specified, but the route > > propagation is based on a different concept. > >I don't think route propagation is based on a 'different concept' - I think >we need to reconcile gateway registration to the realities of network >architecture. That's been the overriding thread of my many mails on gateway >registration and trunk groups. > > > > > Regardless of the functions of "route propagation", it seems > > to me that the > > function of "routing" still means that interpretation of the > > CIC (and other > > dialed information) results in the selection of an ordered > > list of trunk > > groups (physical facilities) by which a call can be routed > > (called a "route > > list" in T1.523). > >Totally. I'm with you there. The construction of that route list will be >performed within the proxy server that is provisioned by the gateway >registration process. Thanks to all of the timely information it has learned >from gw reg, the proxy server will construct a list that will be more likely >to result in the prompt termination of the call than it would if it had no >gw reg data. It will make this decision by inspecting the signaling for call >setup (including the dialed number, a CIC if available, and so forth), and >comparing these criteria with the attributes it has learned from the gw reg >process, which tell the PS what possible terminations are available. > > > I especially have a concern with your > > statement that "CICs > > might be 'available' or 'preferred' with regard to a > > particular trunk group > > has no corrollary in traditional telephone networks". I don't > > think this > > statement represents the required routing logic (independent > > of how this > > information is propogated). > >The concepts of 'available' and 'preferred' in and of themselves, of course, >do not represent the required routing logic. They are just data that are >taken into account by the routing logic in a proxy server in order to >construct a route list for a particular call. > >Incidentally, I'm not married to the terms 'preferred' and 'available'. I >brought them up to give a sense of the role they might play in the >construction of route lists. Probably better terms would be 'directly' and >'indirectly' available, where a CIC is 'directly' available through a trunk >group iff the administrative domain of the switch on the other side of the >trunk group is the administrative domain responsible for that CIC. > > > I believe the required routing > > logic does have a > > direct corrollary in the traditional telephone network. The > > concepts of > > "available" and "preferred" are included by the ordered list > > of trunk groups. > > (The first trunk group is preferred, the second is preferred > > next, etc. All > > in the list are available.) > >This is good - I think this is where our disconnect is. The problem I'm >trying to solve is 'how does a proxy server construct an ordered route list >for a particular call based on the information it receives from gateway >registrations?". When you talk about how CICs are routed, you seem to assume >that this route list has been provisioned by some other means, or that the >information propagated by gw reg literally is the route list. > >Here's how I think it should work: The information that is propagated by the >gateway registration protocol is a set of potential routes, just a set of >TGs and some of the attributes of these trunk groups. These because actual >routes for a specific call later, when a proxy server makes a routing >decision. > >Consider a simplified example. A proxy server (PS) receives gateway >registrations for three trunk groups, TG1, TG2 and TG3. For TG1, CIC 0288 is >"preferred" and all other CICs are "available". For TG2, only CIC 5062 is >"preferred". For TG3, all CICs are "available". These are the potential >routes. > >Now imagine that a call comes to the PS, and the PS is required to make a >routing decision - to construct the actual route list. We'll say that the >call is for CIC 0288. The PS constructs, on the basis of the gateway >registrations it has received, an ordered route list of: TG1, TG3. Why? TG1 >is first because it is the only available trunk group that is "preferred" >for the CIC associated with the call. TG2 is ineligible because 0288 is not >available through TG2. TG3 is "available" for 0288 (as it is for all CICs), >so it ends up on the route list as a less preferred option than TG1. > >With the route list for the call in mind, the PS routes forwards the call to >the GW responsible for TG1. If the call doesn't succeed there for some >avoidable reason, the PS will subsequently forward the call to the GW >responsible for TG3. > >As a bit of back-story, how do the owners of the GWs decide on the >"preferred" and "available" settings for their TGs with respect to >particular CICs? Well, when the owner of the gateway on which TG1 is located >turned up TG1, he provisioned the GW with a set of information about TG1. >Maybe he learned this information directly from the carrier whose switch >terminates the other end of TG1 - maybe he looked some of it up in the LERG >- in any event he learns this information administratively. One such piece >of information is that the carrier on the other side of TG1 (to which TG1 is >"directly" connected) is addressed by CIC 0288. He also knows that this >carrier is an IXC, and that all CICs are therefore "indirectly" available >through this carrier. > >Finally, note that when a call arrives at the PS, it has many routable >attributes other than a CIC. Calls also, for example, have a dialed number. >The route selection algorithm in the PS, however, decided that it should >look at the CIC before the dialed number, and use the CIC to figure out how >to route the call, and that it should prefer "directly" available routes to >"indirectly" available routes, and so on. This route selection algorithm, in >my opinion, should if possible be independent of the gateway registration >protocol - that is to say, the gw reg protocol should just provide the data >and let the PS worry about how that data will be used to route calls. > > > The difficulty with indicating > > "preferred" and > > "available" in the route progagation procedure is that it can > > not indicate an > > actual order to be used in the actual route selection. > >Agreed, it can't. All it does, as my example above should show, is give the >PS some data that is used by the route selection algorithm. This is critical >because I don't think gateway registration should control the route >selection algorithm itself - for example, by somehow providing an ordered >list of TGs to the PS that will apply to some set of calls. Multiple >gateways will be sending routes for various trunk groups to the PS in a gw >reg message. Presumably, these gateways do not know about one another. The >PS receives routes from these various gateways, and for a particular call >the PS should be allowed to add TGs located on various GWs to the route list >- therefore no GW should be dictating route lists to the PS. > >But with a few simple principles (prefer directly available routes to >indirectly available routes, etc) for a route selection algorithm, the PS >can make a good route list based on the data it receives. This is, in my >opinion, the whole purpose of gateway registration. > > > > > It seems that there must first be a common agreement on what routing > > procedures are required. Only then can route propogation > > procedures be > > defined. > > > > Mike Pierce > > Artel > > >_______________________________________________ >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 Jan 8 15:32: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 PAA09431 for ; Tue, 8 Jan 2002 15:32:05 -0500 (EST) 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 g08KU7o02845; Tue, 8 Jan 2002 15:30:07 -0500 Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g08KT3o02827 for ; Tue, 8 Jan 2002 15:29:03 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g08KSSW14877 for ; Tue, 8 Jan 2002 15:28:28 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029) id 3C06950500872BF1; Tue, 8 Jan 2002 15:22:02 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] Definition of "trunk group"/Scope Message-ID: <62DA45D4963FA747BA1B253E266760F901051A89@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] Definition of "trunk group" Thread-Index: AcGYZ7GRegZMvgRZEdanAgCQJ3s5nwADxu6w X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Roy, Radhika R, ALASO" To: "Michael Hammer" , "Tom-PT Taylor" Cc: "Peterson, Jon" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id g08KT3o02828 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, 8 Jan 2002 14:58:25 -0500 Content-Transfer-Encoding: 8bit Hi, All: It appears that we have spent a good amount of time on this particular issue what are the items to be included in the trunk group. Thanks to all that we agreeing more and more in this area. Let us now turn our attention to some basic issues as follows: 1. What is the definition of (monolithic or decomposed) GWs? Are these GWs not doing the protocol conversion (e.g., SIP-ISUP, SIP-H.323, etc)? If it is so, it seems to be that the GW registration protocol that we are proposing will be used to facilitate the routing of the calls of SIP to ISUP/H.323 and vice versa. 2. The attributes that a GW will register with the location server must be abstracted in such a way that can be used in the signaling protocols (SIP, ISUP, H.323) in a meaningful way otherwise these [attributes] will be useless. Because the intra-Domain (as well as inter-Domain like TRIP) protocol is used in the "backend" of SIP Proxies to complete the calls (e.g., SIP-ISUP, SIP-H.323) and is NOT an end-to-end protocol. 3. If there is only one location server in an ITAD, we do not need to worry about the communications among the location servers. In this situation, we can develop the GW registration protocol very easily without worrying too much what needs to be propagated. 4. If we develop the protocol for communications among the location servers, as it appears, that some people are too much concerned what can be propagated or not. The GW attributes that we are considering can be address families, capacity, QOS, and/or others. We need to consider that we are focusing ONLY on the intra-Domain communications where only one IP Telephony administrator is responsible. Since we are NOT considering the inter-Domain communications like TRIP, we may not need to be overly concerned. That is, we can sort out our problems case by case basis because we will, unlike TRIP, be transferring all the attributes among the LSs within an ITAD. 5. If we consider item 4, it appears that we have to develop the complete intra-Domain protocol. Can we include this as a IPTEL WG item? If not, why not? 6. If we do not include item 4, we are left with a situation where we can assume that there is only ONE location server in an ITAD (as I explained in my earlier emails). How does it help to achieve the real objectives of the IPTEL WG (our proposed I-D shows that we only need one [or at best two] messages beyond the GW registration/discovery protocol)? Let us discuss the above points providing pros and cons from technical point of view. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Tuesday, January 08, 2002 11:44 AM To: Tom-PT Taylor Cc: 'Peterson, Jon'; 'Mpierce1@aol.com'; iptel@lists.bell-labs.com Subject: RE: [IPTEL] Definition of "trunk group" Tom, Jon, I concur with your line of thought, although I think the terms "direct" and "indirect" are more descriptive and useful. Will these characteristics be propagated as attributes when advertising that a TG can reach a specific carrier? Mike _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jan 10 09:44: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 JAA15651 for ; Thu, 10 Jan 2002 09:44:04 -0500 (EST) 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 g0AELSo13418; Thu, 10 Jan 2002 09:21:28 -0500 Received: from web8102.in.yahoo.com (web8102.in.yahoo.com [203.199.70.29]) by share.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g0A4kio11266 for ; Wed, 9 Jan 2002 23:46:44 -0500 Message-ID: <20020110044636.81983.qmail@web8102.in.yahoo.com> Received: from [203.190.136.98] by web8102.mail.in.yahoo.com via HTTP; Thu, 10 Jan 2002 04:46:36 GMT From: =?iso-8859-1?q?vipin=20gahlaut?= Subject: RE: [IPTEL] Query regarding application of TRIP To: iptel@lists.bell-labs.com In-Reply-To: <62DA45D4963FA747BA1B253E266760F901051814@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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, 10 Jan 2002 04:46:36 +0000 (GMT) Content-Transfer-Encoding: 8bit Hi Everybody, I am very much thankful to you to help me in understanding the registration mechanism betwen location server and gateway nad between LS to LS. I am reading the draft suggested by Radhika. Actually I am working in a Telecom company and we have a gateway solution which is a capable of interworking between SIP,POTS,H.323,SS7,R1 signalling. We also have implemented RAS protocol in H323 to register GW, and also have SIP register mechanism. Now we want to develop a full fledged Location Server, which can help in inter ITAD communication and also Intra ID communication, along with a comprehensive registration mechanism from GW to LS. Actually we want to avoid two registration mechanism for SIP and H323 and want to have a common solution for any protocol. Previously I was thinking to implement only TRIP, but after the suggestion of ITRP, I found ITRP will also help in long term. Do I need to implement both ITRP( for GW to LS) and TRIP ( for LS to LS )??? Please suggest me How should I proceed. Thanks for your suggestion and help. Best Regards Vipin --- "Roy, Radhika R, ALASO" wrote: > Please see inline [RRR]. > > -----Original Message----- > From: Jonathan Rosenberg > [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, January 07, 2002 4:03 PM > To: Roy, Radhika R, ALASO > Cc: vipin gahlaut; iptel@lists.bell-labs.com > Subject: Re: [IPTEL] Query regarding application of > TRIP > > > > > Roy, Radhika R, ALASO wrote: > > > Hi, Vipin: > > > > You are right that TRIP does not help for > SIP-H.323 IWF interworking the > > way TRIP has been standardized now. TRIP just > addresses for routing of > > the E.164/Decimel/PentaDecimel numbers for > inter-ITAD (or inter-Domain) > > communications only. That is, communications are > made among the location > > servers of different administrative Telephony > domains. It does not deal > > with the GWs as well. It even does not address the > propagation of > > capacity, QOS, and other attributes. It has a very > limited use. > > > Radhika, little benefit is gained by using this > question to field an > unrelated barrange of attacks against TRIP. It > serves only to confuse > the person who asked the question and distract the > group. Your posts are > very much becoming disruptive and purposefully > counter productive. > > [RRR] This is what people like to know about TRIP > from technical point of view (its weaknesses and > strengths - modeled in the light of BGP). It is > rather technical clarifications. > > TRIP does not address capacity, Qos, and other > attribute propagation > inter-domain for GOOD REASON. > > [RRR] This is the point that people like to know. It > is rather technical clarifications (because some > people think that something that is not used by TRIP > is also NOT good for the GW registration protocol or > otherwise). > > > > For intra-Domain communications among the location > servers and GWs > > (SIP-ISUP Tel GW, SIP-H.323 Tel GW), a complete > proposal has been made > > how all the attributes (e.g., address families > > [E.164/Decimel/PentaDecimel, email IDs, URL IDs, > etc], capacity, QOS, > > etc.) can be used. You can see the proposal in the > following URL: > > > (http://www.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt). > With > > this, you can also use SIP-H.323 GWs for IP-IP > communications. > > > I have said it several times, and I will say it once > more. This draft is > out of scope. The group is not considering > intra-domain communications. > > [RRR] The above draft has been referred to answer > the questions of Vipin. If something is not a WG > charter item now, it may be considered later. (If it > takes too much time to make it is a WG charter, it > can be considered for the informational RFC if we > think to do so). > > [RRR] This draft has sent to see what comes out of > the technical discussion. We have to see how the > technical discussion on GW registration protocol > goes on. This draft has many things and the GW > registration and discovery are also a part of it in > the context of the intra-Domain protocol. We have > seen most of the technical discussion that is going > on related to the GW registration protocol has been > influenced by this draft. For example, all types of > GWs will have the common attributes like address > families, capacity, QOS, and others that can be > registered with the location server. > > [RRR] Please also see another email sent in response > to Jon Peterson's questions. This will also clarify > more how the above draft is contributing to advance > the goals of the IPTEL WG. > > -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 ________________________________________________________________________ Looking for a job? Visit Yahoo! India Careers Visit http://in.careers.yahoo.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Jan 13 18:27: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 SAA15874 for ; Sun, 13 Jan 2002 18:27:07 -0500 (EST) 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 g0DNOEo03860; Sun, 13 Jan 2002 18:24:14 -0500 Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0DNNvo03847 for ; Sun, 13 Jan 2002 18:23:57 -0500 Received: from Mpierce1@aol.com by imo-d04.mx.aol.com (mail_out_v31_r1.9.) id g.124.a19737e (3701); Sun, 13 Jan 2002 18:23:44 -0500 (EST) From: Mpierce1@aol.com Message-ID: <124.a19737e.29737100@aol.com> Subject: Re: [IPTEL] Definition of "trunk group" To: jon.peterson@neustar.biz, iptel@lists.bell-labs.com, mhammer@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 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, 13 Jan 2002 18:23:44 EST Content-Transfer-Encoding: 7bit In a message dated 1/8/02 9:35:07 AM Eastern Standard Time, jon.peterson@neustar.biz writes: > I think I understand our disconnect after reading this mail; towards the end > I offer a fairly lengthy example which hopefully illustrates where I'm > coming from. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > > Sent: Sunday, January 06, 2002 4:35 PM > > To: jon.peterson@neustar.biz; iptel@lists.bell-labs.com; > > mhammer@cisco.com > > Subject: Re: [IPTEL] Definition of "trunk group" > > > > I believe the required routing logic does have a > > direct corrollary in the traditional telephone network. The concepts of > > "available" and "preferred" are included by the ordered list of trunk groups. > > (The first trunk group is preferred, the second is preferred next, etc. All > > in the list are available.) > > This is good - I think this is where our disconnect is. The problem I'm > trying to solve is 'how does a proxy server construct an ordered route list > for a particular call based on the information it receives from gateway > registrations?". When you talk about how CICs are routed, you seem to assume > that this route list has been provisioned by some other means, or that the > information propagated by gw reg literally is the route list. I understand that the idea is to construct the route list from the information derived during the GW registration process. The problem is describing the process, considering that the GW registration process only provides a small part of what is needed to construct a route list. Sometimes it is no more than a hint. > > Here's how I think it should work: The information that is propagated by the > gateway registration protocol is a set of potential routes, just a set of > TGs and some of the attributes of these trunk groups. These become actual > routes for a specific call later, when a proxy server makes a routing > decision. > > Consider a simplified example. A proxy server (PS) receives gateway > registrations for three trunk groups, TG1, TG2 and TG3. For TG1, CIC 0288 is > "preferred" and all other CICs are "available". For TG2, only CIC 5062 is > "preferred". For TG3, all CICs are "available". These are the potential > routes. > > Now imagine that a call comes to the PS, and the PS is required to make a > routing decision - to construct the actual route list. We'll say that the > call is for CIC 0288. The PS constructs, on the basis of the gateway > registrations it has received, an ordered route list of: TG1, TG3. Why? TG1 > is first because it is the only available trunk group that is "preferred" > for the CIC associated with the call. TG2 is ineligible because 0288 is not > available through TG2. TG3 is "available" for 0288 (as it is for all CICs), > so it ends up on the route list as a less preferred option than TG1. This simple case is obvious to the PS, since it got one "preferred" and one "available" choice for CIC=0288. (Actually, this isn't even obvious, since the determination of "preferred" and "available" was made by the GW, but the PS may have a legitimate reason to reverse the selection order based on other information it has, like the GW that said "available" is next door and the one that claimed "preferred" is on the other side of the world.) The difficult case is when the PS receives multiple "preferred" choices. In a particular network situation, each GW may be owned by a different company who makes their money by getting traffic to go through their GW. They would specifiy everything that they could possibly handle as "preferred" and never as just "available". Mike Pierce Artel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jan 14 13:48: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 NAA12335 for ; Mon, 14 Jan 2002 13:48:39 -0500 (EST) 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 g0EIQ6o08739; Mon, 14 Jan 2002 13:26:06 -0500 Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0EIPXo08726 for ; Mon, 14 Jan 2002 13:25:33 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0EIPPW21572 for ; Mon, 14 Jan 2002 13:25:26 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029) id 3C069505009D0D6B; Mon, 14 Jan 2002 13:14:23 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] Definition of "trunk group" Message-ID: <62DA45D4963FA747BA1B253E266760F90116B53F@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] Definition of "trunk group" Thread-Index: AcGcjJJ+walc2gh8EdanAgCQJ3s5nwAmROhQ X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Roy, Radhika R, ALASO" To: Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id g0EIPYo08727 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, 14 Jan 2002 13:14:58 -0500 Content-Transfer-Encoding: 8bit Comments inline [RRR] -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Sunday, January 13, 2002 6:24 PM To: jon.peterson@neustar.biz; iptel@lists.bell-labs.com; mhammer@cisco.com Subject: Re: [IPTEL] Definition of "trunk group" .... The difficult case is when the PS receives multiple "preferred" choices. In a particular network situation, each GW may be owned by a different company who makes their money by getting traffic to go through their GW. They would specifiy everything that they could possibly handle as "preferred" and never as just "available". [RRR] In intra-domain, it is assumed that all GWs will be administered by a single IP Telephony service provider. In this situation, the logic of "preferred" and "available" is expected to be maintained in accordance to the policy of the given service provider. Mike Pierce Artel _______________________________________________ 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 Mon Jan 14 16:25:22 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 QAA20069 for ; Mon, 14 Jan 2002 16:25:22 -0500 (EST) 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 g0EL1Fo09751; Mon, 14 Jan 2002 16:01:15 -0500 Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0EL02o09715 for ; Mon, 14 Jan 2002 16:00:02 -0500 Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA01410; Mon, 14 Jan 2002 15:59:56 -0500 (EST) 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 AAH87503; Mon, 14 Jan 2002 15:55:35 -0500 (EST) Message-Id: <4.3.2.7.2.20020114155716.00b21020@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Roy, Radhika R, ALASO" From: Michael Hammer Subject: RE: [IPTEL] Definition of "trunk group" Cc: , , In-Reply-To: <62DA45D4963FA747BA1B253E266760F90116B53F@OCCLUST04EVS1.ugd .att.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: Mon, 14 Jan 2002 15:59:32 -0500 That is why it may be better to separate the policy decision (which is preferred) from the basic facts. The use of terms "direct" and "indirect" meaning that a switch of that carrier is one hop from the gateway doing the advertising is factual and unambiguous. Mike At 01:14 PM 1/14/2002 -0500, Roy, Radhika R, ALASO wrote: >Comments inline [RRR] > >-----Original Message----- >From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] >Sent: Sunday, January 13, 2002 6:24 PM >To: jon.peterson@neustar.biz; iptel@lists.bell-labs.com; >mhammer@cisco.com >Subject: Re: [IPTEL] Definition of "trunk group" > >.... > >The difficult case is when the PS receives multiple "preferred" choices. In a >particular network situation, each GW may be owned by a different company who >makes their money by getting traffic to go through their GW. They would >specifiy everything that they could possibly handle as "preferred" and never >as just "available". > >[RRR] In intra-domain, it is assumed that all GWs will be administered by >a single IP Telephony service provider. In this situation, the logic of >"preferred" and "available" is expected to be maintained in accordance to >the policy of the given service provider. > >Mike Pierce >Artel >_______________________________________________ >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 Mon Jan 14 16:25:50 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 QAA20112 for ; Mon, 14 Jan 2002 16:25:50 -0500 (EST) 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 g0ELP3o09983; Mon, 14 Jan 2002 16:25:03 -0500 Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0ELOXo09968 for ; Mon, 14 Jan 2002 16:24:33 -0500 Received: from attrh1i.attrh.att.com ([135.71.62.10]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0ELOOZ18035 for ; Mon, 14 Jan 2002 16:24:25 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029) id 3C0BA3A5001EB4D4; Mon, 14 Jan 2002 16:24:03 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] Definition of "trunk group" Message-ID: <62DA45D4963FA747BA1B253E266760F90116B72A@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] Definition of "trunk group" Thread-Index: AcGdPnequ1VLGgkvEdanAgCQJ3s5nwAATkYw X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Roy, Radhika R, ALASO" To: "Michael Hammer" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id g0ELOYo09969 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, 14 Jan 2002 16:24:04 -0500 Content-Transfer-Encoding: 8bit Hi, Mike: You are right and I agree with you (because it is better NOT to standardize "subjective" terms related to policy per se). Thanks for your clarifications. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Monday, January 14, 2002 4:00 PM To: Roy, Radhika R, ALASO Cc: Mpierce1@aol.com; jon.peterson@neustar.biz; iptel@lists.bell-labs.com Subject: RE: [IPTEL] Definition of "trunk group" That is why it may be better to separate the policy decision (which is preferred) from the basic facts. The use of terms "direct" and "indirect" meaning that a switch of that carrier is one hop from the gateway doing the advertising is factual and unambiguous. Mike At 01:14 PM 1/14/2002 -0500, Roy, Radhika R, ALASO wrote: >Comments inline [RRR] > >-----Original Message----- >From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] >Sent: Sunday, January 13, 2002 6:24 PM >To: jon.peterson@neustar.biz; iptel@lists.bell-labs.com; >mhammer@cisco.com >Subject: Re: [IPTEL] Definition of "trunk group" > >.... > >The difficult case is when the PS receives multiple "preferred" choices. In a >particular network situation, each GW may be owned by a different company who >makes their money by getting traffic to go through their GW. They would >specifiy everything that they could possibly handle as "preferred" and never >as just "available". > >[RRR] In intra-domain, it is assumed that all GWs will be administered by >a single IP Telephony service provider. In this situation, the logic of >"preferred" and "available" is expected to be maintained in accordance to >the policy of the given service provider. > >Mike Pierce >Artel >_______________________________________________ >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 Jan 15 10:04:26 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 KAA26558 for ; Tue, 15 Jan 2002 10:04:26 -0500 (EST) 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 g0FF2Jo14742; Tue, 15 Jan 2002 10:02:19 -0500 Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0FF1uo14729 for ; Tue, 15 Jan 2002 10:01:56 -0500 Received: from Mpierce1@aol.com by imo-d06.mx.aol.com (mail_out_v31_r1.9.) id c.25.2162c369 (25508); Tue, 15 Jan 2002 10:01:29 -0500 (EST) From: Mpierce1@aol.com Message-ID: <25.2162c369.29759e49@aol.com> Subject: Re: [IPTEL] Definition of "trunk group" To: mhammer@cisco.com, rrroy@att.com CC: jon.peterson@neustar.biz, iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 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, 15 Jan 2002 10:01:29 EST Content-Transfer-Encoding: 7bit In a message dated 1/14/02 4:00:27 PM Eastern Standard Time, mhammer@cisco.com writes: > That is why it may be better to separate the policy decision (which is > preferred) from the basic facts. The use of terms "direct" and "indirect" > meaning that a switch of that carrier is one hop from the gateway doing the > advertising is factual and unambiguous. > > Mike I agree, policy decisions (or opinions) should not be included in signaling, except the problem remains that policy decisions (of the carrier) can still effect routing. Due to many factors, a carrier may desire to use the "indirect" route as the first choice. After all, the "direct" choice could be a GW with a path to a carrier's access point on the other side of the world, and the "indirect" one goes to a GW which then needs to go through another switch sitting in the same building in order to get to the carrier's access point which is also in the same building. Something needs to control the choice of routing based on more than just a "direct" or "indirect" attribute. 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 Jan 15 10:20: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 KAA28628 for ; Tue, 15 Jan 2002 10:20:53 -0500 (EST) 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 g0FFK3o14890; Tue, 15 Jan 2002 10:20:03 -0500 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0FFJoo14872 for ; Tue, 15 Jan 2002 10:19:50 -0500 Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0FFJtD22256; Tue, 15 Jan 2002 10:19:55 -0500 (EST) 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 AAI03142; Tue, 15 Jan 2002 10:15:23 -0500 (EST) Message-Id: <4.3.2.7.2.20020115101911.00b2fd68@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Michael Hammer Subject: Re: [IPTEL] Definition of "trunk group" Cc: rrroy@att.com, jon.peterson@neustar.biz, iptel@lists.bell-labs.com In-Reply-To: <25.2162c369.29759e49@aol.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: Tue, 15 Jan 2002 10:19:35 -0500 Agree. That was part of my intent in separating the two. Mike At 10:01 AM 1/15/2002 -0500, Mpierce1@aol.com wrote: >In a message dated 1/14/02 4:00:27 PM Eastern Standard Time, >mhammer@cisco.com writes: > > > That is why it may be better to separate the policy decision (which is > > preferred) from the basic facts. The use of terms "direct" and > "indirect" > > meaning that a switch of that carrier is one hop from the gateway doing >the > > advertising is factual and unambiguous. > > > > Mike > >I agree, policy decisions (or opinions) should not be included in signaling, >except the problem remains that policy decisions (of the carrier) can still >effect routing. Due to many factors, a carrier may desire to use the >"indirect" route as the first choice. After all, the "direct" choice could be >a GW with a path to a carrier's access point on the other side of the world, >and the "indirect" one goes to a GW which then needs to go through another >switch sitting in the same building in order to get to the carrier's access >point which is also in the same building. Something needs to control the >choice of routing based on more than just a "direct" or "indirect" attribute. > >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 Wed Jan 16 09:40:46 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 JAA09258 for ; Wed, 16 Jan 2002 09:40:45 -0500 (EST) 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 g0GEdFo20658; Wed, 16 Jan 2002 09:39:16 -0500 Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0GEcOo20637 for ; Wed, 16 Jan 2002 09:38:24 -0500 Received: from conference ([213.228.2.26]) by smtp2.cluster.oleane.net with SMTP id g0GEcMe41650 for ; Wed, 16 Jan 2002 15:38:22 +0100 (CET) Message-ID: <00d301c19e9b$af7849a0$1864a8c0@conference.local> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01C19EA4.01A80BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [IPTEL] The third annual MGC Conference 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, 16 Jan 2002 15:39:38 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_00CF_01C19EA4.01A80BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The third annual MGC Conference, scheduled to take place next May 21 to = 24 in Paris, will serve as an occasion for operators, cable operators, = standardization bodies and vendors to bring accurate technical answers = to these questions.=20 The call for papers dead line has been postponed to January 30. More details at: http://www.upperside.fr/mgcp2002/mgcp2002intro.htm ------=_NextPart_000_00CF_01C19EA4.01A80BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The third annual MGC = Conference,=20 scheduled to take place next May 21 to 24 in = Paris,=20 will serve as an occasion for operators, cable operators, = standardization bodies=20 and vendors to bring accurate technical answers to these questions. =
The call=20 for papers dead line has been postponed to January 30.
More details=20 at:
http://www.up= perside.fr/mgcp2002/mgcp2002intro.htm
------=_NextPart_000_00CF_01C19EA4.01A80BE0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jan 17 11:10: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 LAA20159 for ; Thu, 17 Jan 2002 11:10:08 -0500 (EST) 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 g0HG89o26882; Thu, 17 Jan 2002 11:08:10 -0500 Received: from tomts9-srv.bellnexxia.net (tomts9.bellnexxia.net [209.226.175.53]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0HG7No26869 for ; Thu, 17 Jan 2002 11:07:23 -0500 Received: from dizzy2 ([64.230.113.227]) by tomts9-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20020117160719.CULV22140.tomts9-srv.bellnexxia.net@dizzy2> for ; Thu, 17 Jan 2002 11:07:19 -0500 Message-ID: <002801c19f71$3d321de0$9772fea9@dizzy2> From: "David Zinman" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [IPTEL] [TRIP] draft-ietf-iptel-trip-mib-01.txt 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, 17 Jan 2002 11:08:44 -0500 Content-Transfer-Encoding: 7bit There is a new draft for the TRIP-MIB at: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-01.txt Among the changes, this draft incorporates the excellent suggestions from Kevin Lingle, Hussein Salama, and Bob Penfield. Changes from o Changed tripSupportedProtocols and tripAddressFamilies from OBJECT IDENTIFIER to OBJECT-IDENTITY. o Added tripRouteTRIBMask with syntax BITS to identify the type of TRIB the route belongs to. o Removed tripMinItadOriginationInterval and tripMinRouteAdvertisementInterval from the tripCfgTable because they also exist in the Peer table. o TripPeerRemoteItad made read-only because either the local application will determine the value. o Add tripRouteTypeTable as a sub-table to tripCfgTable (similar to tripPeerRouteTypeTable). o Add timestamp to route table (when received), and last change of peer state. o Removed tripRouteBest since the best would be represented by LocTRIB or AdjTRIBOut _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jan 17 11:49: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 LAA23935 for ; Thu, 17 Jan 2002 11:49:54 -0500 (EST) 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 g0HGV7o27051; Thu, 17 Jan 2002 11:31:07 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0HGU0o27031 for ; Thu, 17 Jan 2002 11:30:00 -0500 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0HGUWGe021723; Thu, 17 Jan 2002 11:30:33 -0500 (EST) Message-ID: <3C46FC04.4070006@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: David Zinman CC: iptel@lists.bell-labs.com Subject: Re: [IPTEL] [TRIP] draft-ietf-iptel-trip-mib-01.txt References: <002801c19f71$3d321de0$9772fea9@dizzy2> 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, 17 Jan 2002 11:29:56 -0500 Content-Transfer-Encoding: 7bit Thanks to David for doing a great job here. I think this closes the open issues, and that this document is now ready for delivery to the IESG for consideration as proposed. I will do that on Monday, to give people a few days or so to make sure they are satisfied with the draft. Thanks, Jonathan R. David Zinman wrote: > There is a new draft for the TRIP-MIB at: > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-01.txt > > Among the changes, this draft incorporates the excellent > suggestions from Kevin Lingle, Hussein Salama, and Bob Penfield. > > Changes from > > o Changed tripSupportedProtocols and tripAddressFamilies from > OBJECT IDENTIFIER to OBJECT-IDENTITY. > o Added tripRouteTRIBMask with syntax BITS to identify the type of > TRIB the route belongs to. > o Removed tripMinItadOriginationInterval and > tripMinRouteAdvertisementInterval from the tripCfgTable because > they also exist in the Peer table. > o TripPeerRemoteItad made read-only because either the local > application will determine the value. > o Add tripRouteTypeTable as a sub-table to tripCfgTable (similar to > tripPeerRouteTypeTable). > o Add timestamp to route table (when received), and last change > of peer state. > o Removed tripRouteBest since the best would be represented by > LocTRIB or AdjTRIBOut > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > > -- 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 Sun Jan 20 03:08: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 DAA07811 for ; Sun, 20 Jan 2002 03:08:10 -0500 (EST) 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 g0K7sno08882; Sun, 20 Jan 2002 02:54:49 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0K7rFo08869 for ; Sun, 20 Jan 2002 02:53:15 -0500 Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0K7rlGe024064 for ; Sun, 20 Jan 2002 02:53:49 -0500 (EST) Message-ID: <3C4A7765.8070602@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: iptel@lists.bell-labs.com References: <200201182031.g0IKVoR17876@gamma.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPTEL] Re: RFC 3219 on Telephony Routing over IP (TRIP) 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, 20 Jan 2002 02:53:09 -0500 Content-Transfer-Encoding: 7bit Folks, As you can see, TRIP has finally been published as RFC 3219! Thanks to Hussein for a great final review of the doc for typos and other nits before publication. -Jonathan R. RFC Editor wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 3219 > > Title: Telephony Routing over IP (TRIP) > Author(s): J. Rosenberg, H. Salama, M. Squire > Status: Standards Track > Date: January 2002 > Mailbox: jdrosen@dynamicsoft.com, hsalama@cisco.com, > msquire@windwire.com > Pages: 79 > Characters: 184618 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-iptel-trip-09.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3219.txt > > > This document presents the Telephony Routing over IP (TRIP). TRIP is > a policy driven inter-administrative domain protocol for advertising > the reachability of telephony destinations between location servers, > and for advertising attributes of the routes to those destinations. > TRIP's operation is independent of any signaling protocol, hence TRIP > can serve as the telephony routing protocol for any signaling > protocol. > > The Border Gateway Protocol (BGP-4) is used to distribute routing > information between administrative domains. TRIP is used to > distribute telephony routing information between telephony > administrative domains. The similarity between the two protocols is > obvious, and hence TRIP is modeled after BGP-4. > > This document is a product of the IP Telephony Working Group of the > IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > > > > ------------------------------------------------------------------------ > > Date: > > Fri, 18 Jan 2002 16:22:37 -0500 > > -- 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 Wed Jan 23 16:21: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 QAA25866 for ; Wed, 23 Jan 2002 16:21:23 -0500 (EST) 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 g0NLIVr00934; Wed, 23 Jan 2002 16:18:31 -0500 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 SMTP id g0NLHFr00919 for ; Wed, 23 Jan 2002 16:17:15 -0500 Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jan 23 16:11:20 EST 2002 Received: by lists.bell-labs.com (Postfix) id 56CB94439E; Wed, 23 Jan 2002 16:03:24 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from teton.mh.lucent.com (teton.mh.lucent.com [135.3.130.2]) by lists.bell-labs.com (Postfix) with ESMTP id ECF444439D for ; Wed, 23 Jan 2002 16:03:23 -0500 (EST) Received: from lucent.com (pctla2 [135.3.130.26]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id QAA15693; Wed, 23 Jan 2002 16:03:20 -0500 (EST) Message-ID: <3C4F245E.B2A721BC@lucent.com> From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] More 2806bis: ISDN subaddresses to be removed References: <3C31D703.435808EC@cs.columbia.edu> Content-Type: multipart/mixed; boundary="------------4AFDD2339D8F90A57313387A" 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, 23 Jan 2002 16:00:15 -0500 This is a multi-part message in MIME format. --------------4AFDD2339D8F90A57313387A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We do not use them currently in tel URLs, but we DO have VoIP products that use them and could need them in tel URLs in the future. I have not been personally involved with them but as I understand it, in some regions (e.g., Japan) they are used to address multiple devices on a single BRI line in a home or office. In such an environment, they would be needed to allow addressing only the desired device (e.g., voice phone and avoid getting fax machine). Our VoIP products can currently be configured to accept PSTN calls only if the correct subaddress is set, but do not currently place IP calls specifying a subaddress but may want to in the future. Why do we want to remove the feature? "Henning G. Schulzrinne" wrote: > Unless somebody steps forward and claims use, ISDN subaddresses are also > on the way out. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------4AFDD2339D8F90A57313387A Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard --------------4AFDD2339D8F90A57313387A-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jan 24 17:23:34 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 RAA08214 for ; Thu, 24 Jan 2002 17:23:34 -0500 (EST) 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 g0OMMpr06553; Thu, 24 Jan 2002 17:22:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0HBlso25545 for ; Thu, 17 Jan 2002 06:47:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12200; Thu, 17 Jan 2002 06:47:53 -0500 (EST) Message-Id: <200201171147.GAA12200@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-mib-01.txt 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, 17 Jan 2002 06:47:53 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : Management Information Base for Telephony Routing over IP (TRIP) Author(s) : J. Jiang, D. Walker, D. Zinman Filename : draft-ietf-iptel-trip-mib-01.txt Pages : 42 Date : 16-Jan-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage for Telephony Routing over IP (TRIP) [2] devices. Since TRIP [2] is modelled after the Border Gateway Protocol (BGP-4) [3], the managed objects for TRIP are also modelled after RFC1657 - Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-trip-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-trip-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020116142647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-trip-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-trip-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020116142647.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jan 24 17:26: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 RAA08273 for ; Thu, 24 Jan 2002 17:26:54 -0500 (EST) 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 g0OMPxr06595; Thu, 24 Jan 2002 17:25:59 -0500 Received: from pc7143.unige.ch (pc7143.unige.ch [129.194.71.43]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0HCNUo25774 for ; Thu, 17 Jan 2002 07:23:31 -0500 Received: from pc7143.unige.ch (localhost [127.0.0.1]) by pc7143.unige.ch (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g0HCRkC09873 for ; Thu, 17 Jan 2002 13:27:46 +0100 Message-Id: <200201171227.g0HCRkC09873@pc7143.unige.ch> From: info@ltssg3.epfl.ch To: iptel@lists.bell-labs.com Subject: [IPTEL] LAST CFP: IEEE ICME 2002, Int.Conf.MM & Expo 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 Jan 17 13:27:46 2002 Apologies for any duplication of this announcement _____________________________________________ ---> DEADLINE: FEBRUARY 15, 2002 !! CALL FOR PAPERS: ICME 2002 IEEE International Conference on Multimedia and Expo http://www.icme2002.org Swiss Federal Institute of Technology, EPFL, Lausanne, Switzerland August 26-29 2002 NEWS In addition to the regular tracks, seven high-quality Special Sessions are accepting submissions. Submit your paper today at http://www.icme2002.org ! ... Or remember the final deadline: February 15, 2002! GOALS OF THE CONFERENCE International Conference on Multimedia & Expo (ICME) is a major annual international conference organized with the objective of bringing together researchers, developers and practitioners from academia and industry working in all areas of multimedia. ICME serves as a forum for the dissemination of state-of-the-art research, development, and implementations of multimedia systems, technologies and applications. Co-sponsored by four IEEE societies (the Circuits and Systems Society, the Communications Society, the Computer Society and the Signal Processing Society) the third edition of ICME will be held in Lausanne, Switzerland. INSTRUCTIONS AND TOPICS Authors should submit a four-page manuscript in double-column format including authors' names, affiliations and a short abstract. Only electronic submission will be accepted. Submissions have to be made through the conference Web site: http://www.icme2002.org. A sample of the papers presented at the conference will be selected for a possible publication in an upcoming special issue of IEEE Transactions on Multimedia. There will also be a student best paper award as well as a best paper award. Topics covered include but are not limited to the following: * Audio, image and/or video processing * Components and technologies for multimedia systems * Human-machine interface and interaction * Multimedia applications * Multimedia hardware architectures * Multimedia communication and networking * Multimedia computing systems * Multimedia content access and distribution * Multimedia databases * Signal processing for media integration * Standards (e.g., MPEG) and related issues * System integration, integration of art and technologies * Virtual reality and computer graphics * Watermarking and security Seven special sessions have also been organized and are now open to submissions. CONFERENCE WEB SITE AND CONTACT Web: http://www.icme2002.org Contact: info@icme02.epfl.ch TUTORIALS, DEMO/EXHIBITS Proposals for Tutorials and Demo/Exhibits are also strongly encouraged. Authors are referred to the ICME website to additional information regarding submissions. IMPORTANT DATES Regular Papers Submission Due February 15, 2002 Tutorial Proposal Due March 1, 2002 Demo/Exhibit Proposal Due May 1, 2002 Thierry Pun, Univ. of Geneva, Switzerland Jean-Luc Dugelay, Eurecom, France ICME Publicity co-Chairs PS: feel free to distribute! ----------------------------------------------------------------------- To (un)subscribe the ICME 2002 information mailing list, e-mail to icme2002-request@ltssg3.epfl.ch with "(un)subscribe" in the body. ----------------------------------------------------------------------- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jan 24 17:29: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 RAA08348 for ; Thu, 24 Jan 2002 17:29:44 -0500 (EST) 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 g0OMT3r06645; Thu, 24 Jan 2002 17:29:03 -0500 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0IKVxo01680 for ; Fri, 18 Jan 2002 15:31:59 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g0IKVoR17876; Fri, 18 Jan 2002 12:31:50 -0800 (PST) Message-Id: <200201182031.g0IKVoR17876@gamma.isi.edu> Cc: rfc-ed@ISI.EDU, iptel@lists.bell-labs.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart From: RFC Editor Subject: [IPTEL] RFC 3219 on Telephony Routing over IP (TRIP) 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, 18 Jan 2002 12:31:50 -0800 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3219 Title: Telephony Routing over IP (TRIP) Author(s): J. Rosenberg, H. Salama, M. Squire Status: Standards Track Date: January 2002 Mailbox: jdrosen@dynamicsoft.com, hsalama@cisco.com, msquire@windwire.com Pages: 79 Characters: 184618 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-iptel-trip-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3219.txt This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4. This document is a product of the IP Telephony Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020118123005.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3219 --OtherAccess Content-Type: Message/External-body; name="rfc3219.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020118123005.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jan 24 17:31: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 RAA08381 for ; Thu, 24 Jan 2002 17:31:05 -0500 (EST) 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 g0OMDJr06467; Thu, 24 Jan 2002 17:13:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0HBloo25538 for ; Thu, 17 Jan 2002 06:47:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12184; Thu, 17 Jan 2002 06:47:48 -0500 (EST) Message-Id: <200201171147.GAA12184@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-cpl-06.txt,.ps 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, 17 Jan 2002 06:47:48 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : CPL: A Language for User Control of Internet Telephony Services Author(s) : J. Lennox, H. Schulzrinne Filename : draft-ietf-iptel-cpl-06.txt,.ps Pages : 69 Date : 16-Jan-02 The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. This document is a product of the IP Telephony (IPTEL) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at iptel@lists.research.bell-labs.com and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-cpl-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-cpl-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020116142632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-cpl-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-cpl-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020116142632.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jan 24 17:32: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 RAA08424 for ; Thu, 24 Jan 2002 17:32:18 -0500 (EST) 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 g0OMVar06695; Thu, 24 Jan 2002 17:31:36 -0500 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0LLs1o21843 for ; Mon, 21 Jan 2002 16:54:01 -0500 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0LLrtA16298; Mon, 21 Jan 2002 16:53:55 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAM73213; Mon, 21 Jan 2002 16:53:40 -0500 (EST) Message-ID: <3C4C8DE4.D65BCC4@cisco.com> From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com CC: jdrosen@dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] more comments on tripMIB (per draft-zinman-trip-mib-02.txt) 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, 21 Jan 2002 16:53:40 -0500 Content-Transfer-Encoding: 7bit some months back i offered david zinman comments on the draft trip mib. (see posting to this list on 8/31/2001 w/ subject containing draft-ietf-trip-mib-00.txt) i stopped short then of completing my review - left off at the tripRouteTable. here i'll pick up again from that point using draft-zinman-trip-mib-02.txt. general comment for the entire mib... more REFERENCE clauses for "trip things" would be good. now w/ RFC 3219 officially out, you'll have a good reference to quote. > -- TRIP Received Route Table. This table contains > -- all routes from all sources. Each entry consists > -- of a route and its associated path attributes. > > tripRouteTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripRouteEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The TRIP route table containing information about > reachable routes that are to be added to service by the > receiving LS." > ::= { tripMIBObjects 7 } > > tripRouteEntry OBJECT-TYPE > SYNTAX TripRouteEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a route to a called destination." > INDEX { applIndex, > tripRouteAppProtocol, > tripRouteAddressFamily, > tripRouteAddress, > tripRoutePeer > } as i've said before, indexing schemes like you have here are going to be cumbersome and difficult to understand. do app protocol and address families textual conventions really need to be defined as object identifiers? what's wrong with simple enumerated integers? > ::= { tripRouteTable 1 } > > TripRouteEntry ::= SEQUENCE { > tripRouteAppProtocol TripAppProtocol, > tripRouteAddressFamily TripAddressFamily, > tripRouteAddress OCTET STRING, > tripRoutePeer TripId, > tripRouteAddressSequenceNumber Integer32, > tripRouteAddressOriginatorId TripItad, > tripRouteNextHopServerIAddrType InetAddressType, > tripRouteNextHopServer InetAddress, > tripRouteNextHopServerPort Integer32, > tripRouteNextHopServerItad TripItad, > tripRouteMultiExitDisc Unsigned32, > tripRouteLocalPref Unsigned32, > tripRouteAdvertisementPath OCTET STRING, > tripRouteRoutedPath OCTET STRING, > tripRouteAtomicAggregate TruthValue, > tripRouteBest TruthValue, > tripRouteUnknown OCTET STRING, > tripRouteWithdrawn TruthValue, > tripRouteConverted TruthValue > } > > tripRouteAppProtocol OBJECT-TYPE > SYNTAX TripAppProtocol > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The protocol for which this routing table is > maintained." description sounds like this is specifying the protocol foe the entire table. it's just for this one entry. > ::= { tripRouteEntry 1 } > > tripRouteAddressFamily OBJECT-TYPE > SYNTAX TripAddressFamily > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Specifies the type of address for the destination > route." > ::= { tripRouteEntry 2 } > > tripRouteAddress OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(1..32)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This is an address (prefix) of the family type given by > Address Family of the destination." what is this an address of? that's what should be the main focus of the description. a sidebar (and important) is the family type. the family type relationship should be stated in terms of the other object: "... This address is interpreted based on the value of the tripRouteAddressFamily object in this entry." > ::= { tripRouteEntry 3 } > > tripRoutePeer OBJECT-TYPE > SYNTAX TripId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The identifier of the peer where the route information > was learned." > ::= { tripRouteEntry 4 } > > tripRouteAddressSequenceNumber OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the version of the destination route > originated by the location server identified by > tripRouteAddressOriginatorId intra-domain > attribute." > ::= { tripRouteEntry 5 } > > tripRouteAddressOriginatorId OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This is an intra-domain attribute indicating the > internal location server that originated the route > into the ITAD." > ::= { tripRouteEntry 6 } > > tripRouteNextHopServerIAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of Inet Address of the tripRouteNextHopServer." > REFERENCE > "RFC 2851, section 3." > ::= { tripRouteEntry 7 } > > tripRouteNextHopServer OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the next hop that messages of a given > protocol destined for tripRouteAddress should > be sent to." > ::= { tripRouteEntry 8 } > > tripRouteNextHopServerPort OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The port of the next hop server that this route > will use." > ::= { tripRouteEntry 9 } > consider draft-ietf-ops-rfc2851-update-06.txt InetPortNumber (presuming this is a transport level port number). > tripRouteNextHopServerItad OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the domain of the next hop." > ::= { tripRouteEntry 10 } > > tripRouteMultiExitDisc OBJECT-TYPE > SYNTAX Unsigned32 (0..4294967295) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "When two ITADs are connected by more than one set of peers, > it is used to descriminate between multiple exit points to > an adjacent ITAD." any special meaning for the value 0? > ::= { tripRouteEntry 11 } > > tripRouteLocalPref OBJECT-TYPE > SYNTAX Unsigned32 (0..4294967295) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicated the local LS's degree of preference for an > advertised route destination." any special meaning for the value 0? > ::= { tripRouteEntry 12 } > > tripRouteAdvertisementPath OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(4..252)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Identifies the ITADs through wich routing information "wich" -> "which" > carried in an advertisement has passed. > > This object is probably best represented as sequence of > integer. For SMI compatibility, though, it is represented > as OCTET STRING. This object is a sequence of ITADs in > network byte order." would it be better to borrow from RFC 3219 "5.4.1. AdvertisementPath Syntax" when defining the syntax of this object. > ::= { tripRouteEntry 13 } > > tripRouteRoutedPath OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(4..252)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Identifies the ITADs through which messages sent using > this route would pass. These are as subset of > tripRouteAdvertisementPath. > > This object is probably best represented as sequence of > integer. For SMI compatibility, though, it is represented > as OCTET STRING. This object is a sequence of ITADs in > network byte order." same comment as for tripRouteAdvertisementPath concerning alternative syntax. > ::= { tripRouteEntry 14 } > > tripRouteAtomicAggregate OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates that a route may traverse domains not listed in > tripRouteRoutedPath. If an LS selects the less specific > route from a set of overlapping routes, then this value > returns TRUE." not really a comment for this object but a larger question... this object is reflecting what is learned wrt a particular route, but is there some provision for configuring how this gets setup at the remote device that is originating the route information? not sure if that makes sense or not. > ::= { tripRouteEntry 15 } > > tripRouteBest OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "An indication of whether this route was chosen as the > best TRIP route." > ::= { tripRouteEntry 16 } > > tripRouteUnknown OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(0..255)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "One or more attributes not understood by this location > server." any counter somewhere to count such "not understood" events? > ::= { tripRouteEntry 17 } > > tripRouteWithdrawn OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates if this route is to be removed from service by > the receiving LS." how might this be provisioned? > ::= { tripRouteEntry 18 } > > tripRouteConverted OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates if this route has been converted to a > different application protocol than it had originally." what might cause that converions? > ::= { tripRouteEntry 19 } > > > -- > -- TRIP Received Route CommunityTable. add space between "Community" and "Table". > -- > > tripRouteCommunityTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripRouteCommunityEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table containing a list of TRIP communities associated > with a route." > REFERENCE > "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al, > section 5.9." i presume this reference should change to RFC 3219 now. > ::= { tripMIBObjects 8 } > > tripRouteCommunityEntry OBJECT-TYPE > SYNTAX TripRouteCommunityEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about communities associated with a route. An > entry with a tripRouteAddress of 00 and a tripRoutePeer of > 0 refers to the local LS." > INDEX { applIndex, > tripRouteAppProtocol, > tripRouteAddressFamily, > tripRouteAddress, > tripRoutePeer, > tripRouteCommunityId ouch! the indexes just keep getting larger ;) > } > ::= { tripRouteCommunityTable 1 } > > TripRouteCommunityEntry ::= SEQUENCE { > tripRouteCommunityId TripItad, > tripRouteCommunityItad TripItad > } > > tripRouteCommunityId OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The community identifier." > ::= { tripRouteCommunityEntry 1 } > > tripRouteCommunityItad OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The ITAD associated with this community." > ::= { tripRouteCommunityEntry 2 } > > -- > -- tripItadTopologyTable > -- > > tripItadTopologyTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripItadTopologyEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The sequence of link connections between peers within > an ITAD." > ::= { tripMIBObjects 9 } > > tripItadTopologyEntry OBJECT-TYPE > SYNTAX TripItadTopologyEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a peer of the location server identified > by tripOriginatorIdentifier." tripOriginatorIdentifier is references several times in the mib, but there is no object w/ that descriptor. what are you referring to here... tripItadTopologyOrigId?? > INDEX { applIndex, tripItadTopologyOrigId } > ::= { tripItadTopologyTable 1 } > > TripItadTopologyEntry ::= SEQUENCE { > tripItadTopologyOrigId TripItad, > tripItadTopologySeqNum Integer32 > } > > tripItadTopologyOrigId OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Indicates the internal location server that originated > the ITAD topology information into the ITAD." > ::= { tripItadTopologyEntry 1 } > > tripItadTopologySeqNum OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) Unsigned32?? > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the version of the ITAD topology > originated by the location server identified by > tripOriginatorIdentifier." here's another reference to tripOriginatorIdentifier. > ::= { tripItadTopologyEntry 2 } > > -- > -- tripItadTopologyIdTable > -- > > tripItadTopologyIdTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripItadTopologyIdEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The list of other location servers within the ITAD > domain that the location server identified by > tripOriginatorIdentifier is currently peering." here's another reference to tripOriginatorIdentifier. > ::= { tripMIBObjects 10 } > > tripItadTopologyIdEntry OBJECT-TYPE > SYNTAX TripItadTopologyIdEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a peer to the location server > identified by tripOriginatorIdentifier." > INDEX { applIndex, > tripItadTopologyOrigId, > tripItadTopologyId } > ::= { tripItadTopologyIdTable 1 } > > TripItadTopologyIdEntry ::= SEQUENCE { > tripItadTopologyId TripId, > tripItadTopologyIdRowStatus RowStatus > } > > tripItadTopologyId OBJECT-TYPE > SYNTAX TripId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The index into this entry. Indicates the other location > servers within the ITAD domain that this location server > identified by tripOriginatorIdentifier is currently > peering." why do you need this table? can't this tripItadTopologyId be another columnar object in tripItadTopologyTable? the id object is identified exactly the same way the seq number object from the other table is. any reason they can't co-exist in the same table?? > ::= { tripItadTopologyIdEntry 1 } > > tripItadTopologyIdRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object is used to instantiate a row in this table. > The normal row status values of createAndGo(4), > createAndWait(5) and delete(6) have no application in this > table." > ::= { tripItadTopologyIdEntry 2 } > > -- > -- Notification objects > -- > > tripNotifApplIndex OBJECT-TYPE > SYNTAX INTEGER (1..2147483647) > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "This object contains the applIndex as described > in RFC 2788. It is used to bind this notification > with a specific instance of TRIP entity." > ::= { tripMIBNotifications 1 } > > tripNotifPeerAddrInetType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The type of Inet Address of the tripNotifPeerAddr." > REFERENCE > "RFC 2851, section 3." > ::= { tripMIBNotifications 2 } > > tripNotifPeerAddr OBJECT-TYPE > SYNTAX InetAddress (SIZE(0..125)) > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The remote IP address of this entry's TRIP peer. The > size value of 125 has been assigned due to the sub > identifier of object types length limitation as > defined in SMIv2." > REFERENCE > "RFC 2851, section 3." > ::= { tripMIBNotifications 3 } > > tripNotifPeerErrCode OBJECT-TYPE > SYNTAX INTEGER { > messageHeader(1), > openMessage(2), > updateMessage(3), > holdTimerExpired(4), > finiteStateMachine(5), > cease(6), > tripNotification(7) > } > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "Notification message of TRIP error. The meaning of this > value is applicable to the following functions: > > 1 - message header. > All errors detected while processing the TRIP message > header. > 2 - open message. > All errors detected while processing the OPEN message. > 3 - update message. > All errors detected while processing the UPDATE message. > 4 - hold timer expired. > A notification generated when the hold timer expires. > 5 - finite state machine. > All errors detected by the TRIP Finite State Machine. > 6 - cease. > Any fatal error condition that the rest of the values > do not cover. > 7 - trip notification message. > Any error encountered while sending a notification > message." rather than numbers above, the usual convention is to use the enum labels... messageHeader - All errors detected while processing the TRIP message header. openMessage - All errors detected while processing the OPEN message. ... > ::= { tripMIBNotifications 4 } > > tripNotifPeerErrSubcode OBJECT-TYPE > SYNTAX Integer32 (1..7) > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The sub error code associated with error code. The meaning > of this value is dependent on the value of > tripNotifPeerErrCode. > > Message Header (1) Error Subcodes: > 1 - Bad Message Length. > 2 - Bad Message Type. > > OPEN Message (2) Error Subcodes: > 1 - Unsupported Version Number. > 2 - Bad Peer ITAD. > 3 - Bad TRIP Identifier. > 4 - Unsupported Optional Parameter. > 5 - Unacceptable Hold Time. > 6 - Unsupported Capability. > 7 - Capability Mismatch. > > UPDATE Message (3) Error Subcodes: > 1 - Malformed Attribute List. > 2 - Unrecognized Well-known Attribute. > 3 - Missing Well-known Mandatory Attribute. > 4 - Attribute Flags Error. > 5 - Attribute Length Error. > 6 - Invalid Attribute." if there could ever be more than 7 sub error codes defined, then don't restrict the range of values for this object. the SMI won't allow a range to be expanded in the future, so you'd end up having to deprecate the object and any notifs using it if new sub error codes were to come along. > ::= { tripMIBNotifications 5 } > > -- > -- Notifications > -- > tripEstablished NOTIFICATION-TYPE > STATUS current > DESCRIPTION > "The TRIP Established event is generated when the TRIP > FSM enters the ESTABLISHED state." > ::= { tripMIBNotifications 6 } no objects bound to this notif?? not even tripNotifApplIndex?? > > tripFSM NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode, > tripPeerState > } > STATUS current > DESCRIPTION > "The trip FSM Event is generated when any error is detected > by the TRIP Finite State Machine." > ::= { tripMIBNotifications 7 } > > tripOpenMessageError NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode, > tripPeerState > } > STATUS current > DESCRIPTION > "Errors detected while processing the OPEN message." > ::= { tripMIBNotifications 8 } > > tripUpdateMessageError NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode, > tripPeerState > } > STATUS current > DESCRIPTION > "Errors detected while processing the UPDATE message." > ::= { tripMIBNotifications 9 } > > tripHoldTimerExpired NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode, > tripPeerState > } > STATUS current > DESCRIPTION > "The system does not receive successive messages within the > period specified by the negotiated Hold Time." > ::= { tripMIBNotifications 10 } > > tripConnectionCollision NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex } > STATUS current > DESCRIPTION > "A pair of LSs tried to simultaneously to establish a > transport connection to each other." > ::= { tripMIBNotifications 11 } > > tripNotificationErr NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex } > STATUS current > DESCRIPTION > "Generated if there is an error detected in a TRIP > notification message sent with another cause. Note that > the TRIP notification refered to in this object is not > an SNMP notification, it is a specific message described > in the TRIP specification." > REFERENCE > "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al, > section 6.4." presumably RFC 3219 now. > ::= { tripMIBNotifications 12 } > > -- > -- Compliance Statements > -- > tripCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for TRIP entities." > > MODULE -- this module > MANDATORY-GROUPS { tripConfigGroup, > tripPeerTableConfigGroup, > tripRouteGroup, > tripItadTopologyGroup, > tripPeerTableStatsGroup } > > GROUP tripNotificationGroup > DESCRIPTION > "This group is optional. A TRIP entity can choose not to > send any notifications. If this group is implemented, the > tripNotifObjectGroup must also be implemented." > > GROUP tripNotifObjectGroup > DESCRIPTION > "This group is optional. A TRIP entity can choose not to > send any notifications. If this group is implemented, the > tripNotificationGroup must also be implemented." > > MODULE NETWORK-SERVICES-MIB > MANDATORY-GROUPS { applRFC1565Group } > > ::= { tripMIBCompliance 1 } > > > -- > -- Object and event conformance groups > -- > > tripConfigGroup OBJECT-GROUP > OBJECTS { > tripProtocolVersion, > tripLocalItad, > tripIdentifier, > tripOperStatus, > tripAdminStatus, > tripLocalAddrIAddrType, > tripLocalAddr, > tripLocalPort, > tripMinItadOriginationInterval, > tripMinRouteAdvertisementInterval, > tripMaxPurgeTime, > tripDisableTime, > tripSendReceiveMode, > tripSupportedCommunityItad, > tripSupportedCommunityRowStatus > } > STATUS current > DESCRIPTION > "The global objects for configuring trip." > ::= { tripMIBGroups 1 } > > tripPeerTableConfigGroup OBJECT-GROUP > OBJECTS { > tripPeerIdentifier, > tripPeerState, > tripPeerAdminStatus, > tripPeerNegotiatedVersion, > tripPeerSendReceiveMode, > tripPeerRemotePort, > tripPeerRemoteItad, > tripPeerConnectRetryInterval, > tripPeerMaxRetryInterval, > tripPeerHoldTime, > tripPeerKeepAlive, > tripPeerHoldTimeConfigured, > tripPeerKeepAliveConfigured, > tripPeerMinItadOriginationInterval, > tripPeerMinRouteAdvertisementInterval, > tripPeerMaxPurgeTime, > tripPeerDisableTime, > tripPeerRowStatus > } > > STATUS current > DESCRIPTION > "The global objects for configuring the TRIP peer table." > ::= { tripMIBGroups 2 } > > tripPeerTableStatsGroup OBJECT-GROUP > OBJECTS { > tripPeerInUpdates, > tripPeerOutUpdates, > tripPeerInTotalMessages, > tripPeerOutTotalMessages, > tripPeerFsmEstablishedTransitions, > tripPeerFsmEstablishedTime, > tripPeerInUpdateElapsedTime > } > > STATUS current > DESCRIPTION > "The global statistics the TRIP peer table." > ::= { tripMIBGroups 3 } > > tripRouteGroup OBJECT-GROUP > OBJECTS { > tripRouteAddressSequenceNumber, > tripRouteAddressOriginatorId, > tripRouteNextHopServerIAddrType, > tripRouteNextHopServer, > tripRouteNextHopServerPort, > tripRouteNextHopServerItad, > tripRouteMultiExitDisc, > tripRouteLocalPref, > tripRouteAdvertisementPath, > tripRouteRoutedPath, > tripRouteAtomicAggregate, > tripRouteBest, > tripRouteUnknown, > tripRouteWithdrawn, > tripRouteConverted, > tripRouteCommunityItad, > tripPeerRtTypeRowStatus > } > > STATUS current > DESCRIPTION > "The global objects for configuring route attribute." > ::= { tripMIBGroups 4 } > > tripItadTopologyGroup OBJECT-GROUP > OBJECTS { > tripItadTopologySeqNum, > tripItadTopologyIdRowStatus > } > STATUS current > DESCRIPTION > "The objects that define the TRIP ITAD topology." > ::= { tripMIBGroups 5 } > > tripNotificationGroup NOTIFICATION-GROUP > NOTIFICATIONS { > tripEstablished, > tripFSM, > tripOpenMessageError, > tripUpdateMessageError, > tripHoldTimerExpired, > tripConnectionCollision, > tripNotificationErr > } > STATUS current > DESCRIPTION > "A collection of notifications defined for TRIP." > ::= { tripMIBGroups 6 } > > tripNotifObjectGroup OBJECT-GROUP > OBJECTS { > tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode > } > STATUS current > DESCRIPTION > "The collection of objects that specify information for > TRIP notifications." > ::= { tripMIBGroups 7 } > > END kevin -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Jan 27 20:43: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 UAA05704 for ; Sun, 27 Jan 2002 20:43:08 -0500 (EST) 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 g0S1Q7r27913; Sun, 27 Jan 2002 20:26:08 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0S1Pbr27900 for ; Sun, 27 Jan 2002 20:25:37 -0500 Received: from metroliner.cs.columbia.edu (IDENT:root@metroliner.cs.columbia.edu [128.59.19.252]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA28217; Sun, 27 Jan 2002 20:25:32 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by metroliner.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id g0S1PUd31228; Sun, 27 Jan 2002 20:25:30 -0500 Message-ID: <3C54A9F3.110B5326@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: iptel@lists.bell-labs.com Subject: Re: [IPTEL] More 2806bis: ISDN subaddresses to be removed References: <3C31D703.435808EC@cs.columbia.edu> <3C4F245E.B2A721BC@lucent.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: Sun, 27 Jan 2002 20:31:31 -0500 Content-Transfer-Encoding: 7bit Thanks for the feedback. The general problem is that any feature that isn't used by two implementations has to go for elevation to Draft Standard. For now, I'm leaving it in the draft, in the hope that sufficient actual implementations will materialize. Terry L Anderson wrote: > > We do not use them currently in tel URLs, but we DO have VoIP products that > use them and could need them in tel URLs in the future. I have not been > personally involved with them but as I understand it, in some regions (e.g., > Japan) they are used to address multiple devices on a single BRI line in a > home or office. In such an environment, they would be needed to allow > addressing only the desired device (e.g., voice phone and avoid getting fax > machine). Our VoIP products can currently be configured to accept PSTN > calls only if the correct subaddress is set, but do not currently place IP > calls specifying a subaddress but may want to in the future. > > Why do we want to remove the feature? > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel