From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 1 14:06:11 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00112 for ; Thu, 1 Apr 1999 14:06:10 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BEB5E52AA; Thu, 1 Apr 1999 13:17:24 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2A5A952C1; Thu, 1 Apr 1999 13:17:24 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <002101be7c6c$126dcad0$1d646e0a@w01w010.millenicom.net> From: "Can Kiral" To: Subject: international costs Date: Thu, 1 Apr 1999 20:18:21 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01BE7C7C.C9ADC4B0" 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 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001E_01BE7C7C.C9ADC4B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do you know where I can get interconnection rates, settlement & = accounting rates, and traffic directions of international telcos? Thnks Can Kiral ------=_NextPart_000_001E_01BE7C7C.C9ADC4B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Do you know where I can get = interconnection=20 rates, settlement & accounting rates, and traffic directions of=20 international telcos?
 
Thnks
 
Can Kiral
 
------=_NextPart_000_001E_01BE7C7C.C9ADC4B0-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 04:49:00 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00073 for ; Tue, 6 Apr 1999 04:48:59 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 15D5E52B7; Tue, 6 Apr 1999 04:43:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6D67E52C1; Tue, 6 Apr 1999 04:43:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <001501be8008$e1f6e3a0$c21aa4a4@vipin.wipsys.soft.net> Reply-To: "Vipin Palawat" From: "Vipin Palawat" To: "Arjun RC" Cc: Subject: Re: SIP clarification Date: Tue, 6 Apr 1999 14:08:44 +0530 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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello Arjun, As my understanding, the REGISTERation request should be followed by a 2XX success response or some 4XX/5XX/6XX error response from SIP server to acknowledge the sucessful registration or error. If your message get lost or due to some other reason you did'nt get the response back then you have to retransmit the message again and wait for time out of response. Regards Vipin... ________________________________________________ Have a Nice Day!!! Vipin Palawat Wipro Infotech :Enterprise Solutions (Telecom Division) K-312, 5th Block , Koramangala, Bangalore - 560 095 (India) Ph: 91-80-5538301 Extn:2419 mailto:vipinpal@wipsys.soft.net -----Original Message----- From: Arjun RC To: iptel@lists.research.bell-labs.com Date: Tuesday, April 06, 1999 1:55 PM Subject: SIP clarification Hi, we are trying to implement a minimal version of SIP on UDP and have the following doubt: The RFC (2543) dated Mar '99 sights an example of Users REGISTERing with the SIP Server. However, it does not show the server sending a response (e.g 200 OK) for the same. (16.1 pg 120) However, section 10.4.1, pg 90 states that REGISTER should be retransmitted. Hence it seems logical that a response should be returned. Could anyone pls clarify the exact procedure (ie whether as response follows a register request) Thx Cheers ARC --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 05:39:04 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00341 for ; Tue, 6 Apr 1999 05:39:04 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6DEF752C6; Tue, 6 Apr 1999 05:33:12 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C3ECC52C7; Tue, 6 Apr 1999 05:33:11 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Tue, 6 Apr 1999 15:00:08 +0530 (IST) From: Arjun RC To: iptel@lists.research.bell-labs.com Cc: Vipin_Palawat Subject: Re: SIP clarification In-Reply-To: <6525674B.0030ED37.00@sampark.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi Vipin, Thanks for the clarification -- this is what we have assumed and implemented. The example must have been a overlook -- its was there in the Jan 099 Draft as well as the more recent RFC. Cheers ARC On Tue, 6 Apr -1, Vipin_Palawat wrote: Vipin> As my understanding, the REGISTERation request should be Vipin> followed by a 2XX success response or some 4XX/5XX/6XX error Vipin> response from SIP server to acknowledge the sucessful Vipin> registration or error. If your message get lost or due to -- I am grateful that I am not as judgmental as all those censorious, self-righteous people around me ------------------------------+----------------------------------+ (O): Hughes Software Systems |(R): 68/G, 2nd Narayanappa Block, | 146, Prestige Opal Bldng, |R.T. Nagar, | Infantry Rd, Bangalore-560001 |Bangalore-560032 | Ph:+91-80-2286390/91/92 |Ph:+91-80-3430565 | ------------------------------+----------------------------------+ http://arjun.cjb.net, http://hss068.hss.hns.com (intra HSS) --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 06:07:01 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00533 for ; Tue, 6 Apr 1999 06:07:01 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2845152BB; Tue, 6 Apr 1999 04:07:14 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9533D52BF; Tue, 6 Apr 1999 04:07:13 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: archow@hss.hns.com To: iptel@lists.research.bell-labs.com Date: Tue, 6 Apr 1999 04:05:56 -0400 Message-Id: <19990406080704.79B2E52BB@lists.research.bell-labs.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 07:05:38 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00942 for ; Tue, 6 Apr 1999 07:05:37 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7389C52BF; Tue, 6 Apr 1999 04:09:35 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 99B9352C1; Tue, 6 Apr 1999 04:09:34 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Tue, 6 Apr 1999 13:26:04 +0530 (IST) From: Arjun RC To: iptel@lists.research.bell-labs.com Subject: SIP clarification Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, we are trying to implement a minimal version of SIP on UDP and have the following doubt: The RFC (2543) dated Mar '99 sights an example of Users REGISTERing with the SIP Server. However, it does not show the server sending a response (e.g 200 OK) for the same. (16.1 pg 120) However, section 10.4.1, pg 90 states that REGISTER should be retransmitted. Hence it seems logical that a response should be returned. Could anyone pls clarify the exact procedure (ie whether as response follows a register request) Thx Cheers ARC --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 08:51:57 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04951 for ; Tue, 6 Apr 1999 08:51:57 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1130B52C3; Tue, 6 Apr 1999 08:47:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7B16752C8; Tue, 6 Apr 1999 08:47:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Tue, 6 Apr 1999 05:46:03 -0700 (PDT) From: Yahoo!Clubs Message-Id: <199904061246.FAA13438@e2.clubs.yahoo.com> To: iptel@lists.research.bell-labs.com Reply-To: ramiro_g@mailexcite.com Subject: You're invited! Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hello! You have been invited by elparto to join the Listed Yahoo! Club named "Internet Telephony". To become a member of this club, just go to the Web address below: http://edit.clubs.yahoo.com/config/sjg?.i=internettelephony&.a=i& You need to go to the address above to join the club, but you can take a look at the club by going to: http://clubs.yahoo.com/clubs/internettelephony You can learn more about elparto by looking at the Yahoo! Public Profile: http://profiles.yahoo.com/elparto A Yahoo! Club is a great way to bring friends, family or anyone you know together using the latest in Web technologies. Club members are able to take advantage of a club's private chat room, message boards and other features. You can also create your own free club focused on any interest, such as hobbies, families and industry associations. Clubs are either listed or unlisted. Listed clubs are available to the public while unlisted clubs are available exclusively to those who receive invitations. If you have no interest in joining this club, there is no need for you to do anything. You will not be enrolled as a member. Thanks, The Yahoo! Clubs team http://clubs.yahoo.com/ P.S. If you need some help on getting started, go to: http://help.yahoo.com/help/clubs/ --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 15:05:50 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15442 for ; Tue, 6 Apr 1999 15:05:49 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id F338352CA; Tue, 6 Apr 1999 14:33:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BDC0452CD; Tue, 6 Apr 1999 14:33:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <370A530B.8D95825B@cisco.com> Date: Tue, 06 Apr 1999 11:31:39 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com Subject: Evaluation of the gateway location proposals Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Iptellers, The consensus during the Minneapolis IPTEL meeting was that more detailed comparison of the two gateway location proposals is needed. Below I am providing an evaluation of the two proposals: GLP/SCSP and TBGP/BGP. 1. Introduction: GLP is based on SCSP which is a generic link-state based protocol for synchronizing the databases of a server group. GLP uses SCSP's message formats and defines new fields specific for call routing and gateway location. GLP uses SCSP's transport mechanism only for intra-domain synchronization of LSs. For inter-domain communication, GLP proposes a model that's based on BGP. At runtime, GLP defines a server group (the set of LSs) which uses SCSP for synchronization and update advertisement, i.e., GLP is a user of SCSP. TBGP is based on the BGP-4 and its multi-protocol extensions. It uses BGP's transport mechanism for both inter-domain and intra-domain. TBGP uses the same message formats defined by BGP, and benefits from the attributes already defined in BGP. In addition, TBGP defines new attributes to serve the specific goals of call routing and gateway location. With regards to implementation, BGP and TBGP are completely independent protocols. The two protocols do not interfere with each other at runtime. A TBGP speaker (or LS) does not have to be a BGP speaker. 2. Reliability: GLP runs on a reliable transport, e.g. TCP. In addition, GLP/SCSP uses request/response transactions. Responses are not simple Acks. They are long messages. This significant overhead is needed with intra-domain link-state protocols to achieve transitive closure and to make sure that all LSs in a domain have synced up following a routing change. However, it is still a significant overhead that may be avoided. The request/response mechanism does not add any benefit for inter-domain GLP. TBGP, on the other hand, relies on TCP for reliability. It uses Update messages only with no responses. This is sufficient. 3. Inter-Domain Topologies: Both protocols can support any general topology. 4. Intra-Domain Topologies: GLP can support any general topology. TBGP requires either a full mesh configuration or the use of route reflectors or confederations. It is possible to configure each TBGP speaker in a domain as a route reflector, and thereby to support any general topology. Questions: - What's so bad about route reflectors and confederations? - What's the need for supporting a general topology? All that's required is synchronizing the LSs of the same domain. It doesn't matter how they interconnected, as long as there sufficient redundancy in the topology. 5. Loop Avoidance: 5.1 Intra-domain Loop Detection: GLP detects loops using SCSP's Originator ID and Sequence Number fields. For TBGP, internal updates are limited to one hop only in case of a mesh, therefore there is no danger of loops. With route reflectors, loops are detected using the Originator_ID and Cluster_List attributes. 5.2 Inter domain Loop Detection: Nothing defined for GLP yet. TBGP uses BGP's AS_PATH (or call it AD_PATH) attribute to detect inter-domain loops. 6. Hold-down Timers and Route Flaps: GLP/SCSP does not specify any mechanisms for avoiding route flaps. TBGP leverages BGP's well defined mechanisms for reducing route flaps. BGP defines two timers: - MinRouteAdvertismentInterval (min. time between successive advertisements of routes to the same destination from the same TBGP speaker). - MinASOriginationInterval (min. time between two successive advertisements of routing changes within the TBGP speaker's own AD). 7. Policy Enforcement: GLP/SCSP does not specify any mechanisms for enforcing policies on the routes being advertised. BGP defines two useful attributes which are leveraged by TBGP: Multi_Exit_Disc and Local_Pref. Multi_Exit_Disc is used by an advertising AD with multiple entry points to indicate to its neighbors which entry point(s) into that domain are preferred. Local_Pref is used locally within an AD with multiple exit points to indicate which exit point(s) towards a certain destination are preferred. 8. Coping with Aggregation Side Effects: GLP/SCSP does not specify any mechanisms. TBGP can leverage two attributes already defined in BGP: Aggregator and Atomic_Aggregate. The Aggregator attribute indicates that an advertised prefix is an aggregate, and includes the number of the aggregating AD and the aggregating TBGP speaker's IP address. The Atomic_Aggregate attribute indicates that aggregation has resulted in loss of information for this prefix and therefore deaggregation is not appropriate. 9. Addressing Formats: GLP proposes to advertise E.164 ranges. During the meeting, it has been agreed that E.164 prefixes are more space-efficient. The multi-protocol extensions for BGP-4 (RFC 2283) have already defined fields for advertising E.164 prefixes in BGP messages. These extensions are used by TBGP. 10. Leveraging Existing Attributes: Most of BGP-4's fields and attributes can be used by TBGP, as evident from the above discussion. Still there are some attributes which are of no use to TBGP. for example the layer 3 NEXT_HOP attribute. GLP, on the other hand, will have to redefine several of BGP's existing attributes within the SCSP's message formats. Consider for example, the policy attributes and aggregation attributes discussed above. Also SCSP defines several mandatory fields which are redundant or of no use for GLP. E.g., the Sender ID and Recvr ID are not needed in every Update messages. The peers already recognize each other. Also the Cache Key field is not needed since the tables will be indexed by the E.164 prefixes. TBGP can define its own message formats and remove any useless fields from the current BGP messages, because BGP and TBGP are separate protocols. On the other hand, GLP can not remove useless fields from SCSP messages, because it is just a another user of SCSP. 11. Protocol Phases: GLP/SCSP has three phases: Hello, Cache Alignment, and Update. TBGP/BGP consists of two phases only: Hello and Update. It uses the same mechanisms of the update phase for aligning the call routing tables when a new connection between wo peers is established. 12. Security Consideration: Both protocols define optional fields to include authentication data. Both of them permit the use of different authentication mechanisms, and both provide sufficient space to include the 128-bit MD5 digests. However, TBGP messages can't carry authentication data larger than 128 bits, while SCSP messages can. 13. Routing Experience: This is not a feature of the protocol, but I think it is worth repeating that SCSP was not designed for, and was never used for, inter-domain routing. On the other hand, BGP has been specifically designed for inter-domain routing. It (a) is known to work, (b) is widely deployed in the Internet, (c) has an extensive operational experience, and (d) known to scale. Comments, objections, questions? Hussein -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 15:29:07 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15769 for ; Tue, 6 Apr 1999 15:29:07 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 193F952CC; Tue, 6 Apr 1999 15:23:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 88E0E52CE; Tue, 6 Apr 1999 15:23:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <370A5E88.3B7F5269@dnrc.bell-labs.com> Date: Tue, 06 Apr 1999 15:20:40 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Vipin Palawat Cc: Arjun RC , iptel@lists.research.bell-labs.com Subject: Re: SIP clarification References: <001501be8008$e1f6e3a0$c21aa4a4@vipin.wipsys.soft.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Yes, REGISTER like all other requests is responded to. The reliability mechanisms for all non-INVITE requests are described in section 10.4. In general, SIP issues like this are for the mmusic list, confctrl@isi.edu, not iptel. -Jonathan R. Vipin Palawat wrote: > > Hello Arjun, > > As my understanding, the REGISTERation request should be followed by a 2XX > success response or some 4XX/5XX/6XX error response from SIP server to > acknowledge the > sucessful registration or error. > > If your message get lost or due to some other reason you did'nt get the > response back then you have to retransmit the message again and wait for > time out of response. > > Regards > Vipin... > ________________________________________________ > Have a Nice Day!!! > > Vipin Palawat > Wipro Infotech :Enterprise Solutions (Telecom Division) > K-312, 5th Block , Koramangala, > Bangalore - 560 095 (India) > Ph: 91-80-5538301 Extn:2419 > mailto:vipinpal@wipsys.soft.net > > -----Original Message----- > From: Arjun RC > To: iptel@lists.research.bell-labs.com > Date: Tuesday, April 06, 1999 1:55 PM > Subject: SIP clarification > > Hi, > we are trying to implement a minimal version of SIP on UDP and have the > following > doubt: > > The RFC (2543) dated Mar '99 sights an example of Users REGISTERing with > the SIP Server. > However, it does not show the server sending a response (e.g 200 OK) for > the same. (16.1 pg 120) > > However, section 10.4.1, pg 90 states that REGISTER should be > retransmitted. Hence it seems logical that a response should be returned. > > Could anyone pls clarify the exact procedure (ie whether as response > follows a register request) > > Thx > Cheers > ARC > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 15:58:57 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16207 for ; Tue, 6 Apr 1999 15:58:57 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 77B8952CE; Tue, 6 Apr 1999 15:54:08 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E49F252CF; Tue, 6 Apr 1999 15:54:07 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Posted-Date: Tue, 6 Apr 1999 12:51:43 -0700 (MST) Message-ID: <370A6640.66532C9B@agcs.com> Date: Tue, 06 Apr 1999 12:53:36 -0700 From: "Nagaraj Vn" Organization: AG Communication Systems X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com Subject: [Fwd: H323 RAS signalling and call signal transport address] Content-Type: multipart/mixed; boundary="------------85EE4487C899F647C1F22260" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. --------------85EE4487C899F647C1F22260 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------85EE4487C899F647C1F22260 Content-Type: message/rfc822 Content-Disposition: inline Message-ID: <370A240F.55A0A2F3@agcs.com> Date: Tue, 06 Apr 1999 08:11:11 -0700 From: Nagaraj Vn Organization: AG Communication Systems X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: h323implementors@imtc.org Subject: H323 RAS signalling and call signal transport address Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am working on a VOIP project and looking into RAS messages defined in H.225. My question is about the Terminal Registration with a Gatekeeper using RRQ. The terminal has to send the call signal Transport address in the RRQ message. Does this mean that the terminal would be listening on the TCP transport address and the Gatekeeper can Connect to it to establish the 2way TCP connection? My thought is that the Terminal should be listening on the call signal Transport address otherwise the Gatekeeper cannot offer a terminating call to the Terminal. If above is true, then what is the use of the callSignal Transport address field in the RCF message sent by Gatekeeper? My initial understanding was that the Gatekeeper will be listening on the callSignal Transport address it sends in the RCF message to handle incoming calls. But, TCP being a 2way connection, and if what I mentioned in the first paragraph is true, then why should both the gatekeeper and the terminal be listening on 2 different TCP callSignal address? As the terminal should always initiate the RRQ in Gatekeeper routed call model, and the callSignal Transport address is mandatory in RRQ, the Gatekeeper can CONNECT to this TCP address before sending RCF, if doing preGrantedARQ, OR CONNECT to this TCP address when sending ACF OR when Gatekeeper is ready to offer a call to the terminal. Any comments are welcome. Thanks --------------85EE4487C899F647C1F22260-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 17:41:36 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18142 for ; Tue, 6 Apr 1999 17:41:35 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 94EA852D2; Tue, 6 Apr 1999 17:34:42 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EB1D752D4; Tue, 6 Apr 1999 17:34:41 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <370A7D51.C74400E9@dnrc.bell-labs.com> Date: Tue, 06 Apr 1999 17:32:01 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Jerry Scharf Cc: iptel@lists.research.bell-labs.com Subject: Re: is there a better list to ask H.323 questions of References: <005d01be8074$3a7413c0$1ebd98cc@leda.vayu.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit This is not the right list. This list is for the iptel working group in IETF. Please use the h323 implementors list for h.323 questions. Thanks, Jonathan R. Jerry Scharf wrote: > > I have seen several questions on H.323 go by here. I have one on V2 and was > wondering if there is a better place to ask it or if here is the right > place. > > thanks, > jerry > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 18:05:43 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18709 for ; Tue, 6 Apr 1999 18:05:43 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5D04952CD; Tue, 6 Apr 1999 17:27:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BE5E752CF; Tue, 6 Apr 1999 17:27:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Jerry Scharf" To: Subject: is there a better list to ask H.323 questions of Date: Tue, 6 Apr 1999 14:27:09 -0700 Message-ID: <005d01be8074$3a7413c0$1ebd98cc@leda.vayu.net> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I have seen several questions on H.323 go by here. I have one on V2 and was wondering if there is a better place to ask it or if here is the right place. thanks, jerry --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 18:47:46 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19618 for ; Tue, 6 Apr 1999 18:47:43 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9609452D0; Tue, 6 Apr 1999 18:43:22 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F2A1052CB; Tue, 6 Apr 1999 18:43:21 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: Buenos Aires New Travel To: Message-Id: <18161.236256.81913681 iptel@lists.research.bell-labs.com> Subject: Abri - Mayo / Tarifas Aereas Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 6 Apr 1999 19:41:51 -0300 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Estimados Amigos: Les hacemos llegar los mejores precios a los principales destinos para el resto de la temporada baja: San Pablo $ 222.- Canadian , Valido por 30 dias , hasta el 24/06 Rio de Janeiro $ 240.- Vasp , Valido por 90 dias , hasta el 20/07 Santiago de Chile $ 130.- KLM , Air France , British Airways , Valido por 30 dias Miami $ 549.- , Vasp , valido por 90 dias New York $ 649 Lunes a miercoles - $ 699 Jueves a Domingos , Aerolineas Argentinas, valido 30 dias , hasta 31/5 Madrid $ 799.- Spain Air , Valido por 30 dias. Paris $ 849 , 30 dias , 29/4 Londres $ 849.- , 30 dias , 31/05 Roma $ 845 , valido 14 dias , hasta 30/04 Sydney (Australia) , $ 1099.- valido 21 dias hasta el 31/05 Frankfurt $ 845.- Valido 14 dias KLM Cabotaje : Todas las cias aereas. Reservas Hoteleras en todo el mundo, con confirmacion y pago en Buenos Aires. Buenos Aires New Travel Esmeralda 1269 - 1007 - Capital Federal Tels. 4312-5004 / 4315-8148 / 4312-6160 / 4313-2490 E-Mail: info@newtravel.com.ar / reservas@newtravel.com.ar ______________________________________________________________________ Le pedimos disculpas si este mensaje no es de su interes,para no recibir este mensaje nuevamente conteste el mismo con OUT en el subject. ______________________________________________________________________ --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 6 18:57:08 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19780 for ; Tue, 6 Apr 1999 18:57:07 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C2DD852D1; Tue, 6 Apr 1999 18:51:17 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 20AD352CB; Tue, 6 Apr 1999 18:51:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199904062249.PAA07911@ca.mew.com> X-Sender: claude@158.118.11.12 X-Mailer: Macintosh Eudora Pro Version 3.1.1-Jr2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Apr 1999 15:49:27 -0700 To: iptel@lists.research.bell-labs.com From: Claude Huss Subject: remove me from this list Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 7 00:25:53 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24146 for ; Wed, 7 Apr 1999 00:25:53 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6DB5E52CB; Wed, 7 Apr 1999 00:17:52 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5B71E52D7; Wed, 7 Apr 1999 00:17:51 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: archow@hss.hns.com To: iptel@lists.research.bell-labs.com Date: Wed, 7 Apr 1999 00:15:12 -0400 Message-Id: <19990407041711.5ED8C52CB@lists.research.bell-labs.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 7 00:32:30 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24240 for ; Wed, 7 Apr 1999 00:32:28 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2E8ED52D4; Wed, 7 Apr 1999 00:18:08 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 85FDF52D3; Wed, 7 Apr 1999 00:17:59 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Wed, 7 Apr 1999 09:27:45 +0530 (IST) From: Arjun RC To: Nagaraj_Vn Cc: iptel@lists.research.bell-labs.com Subject: Re: [Fwd: H323 RAS signalling and call signal transport address] In-Reply-To: <6525674B.006E605D.00@sampark.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi Nagraj, On Wed, 7 Apr -1, Nagaraj_Vn wrote: Nag> If above is true, then what is the use of the callSignal Transport Nag> address field in the RCF message sent by Gatekeeper? My initial When a terminal does a RRQ it does not know whether it will be a caller or callee in a call. For example, if A wants to call B thru GK, A needs to know the CallSigAddr of GK and GK needs to know the CallSigAddr of B. So here, the GK needs to know the CallSigAddr of a terminal and a terminal needs to know the CallSigAddr of GK. I think that is why both specify their CallSigAddr at the time of Registration. Please correct me if Im wrong. Cheers ARC In accord to UNIX philosophy, PERL gives you enough rope to hang yourself. - Larry Wall, Randal Schwartz (Camel Book) ------------------------------+----------------------------------+ (O): Hughes Software Systems |(R): 68/G, 2nd Narayanappa Block, | 146, Prestige Opal Bldng, |R.T. Nagar, | Infantry Rd, Bangalore-560001 |Bangalore-560032 | Ph:+91-80-2286390/91/92 |Ph:+91-80-3430565 | ------------------------------+----------------------------------+ http://arjun.cjb.net, http://hss068.hss.hns.com (intra HSS) --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 7 01:32:35 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24662 for ; Wed, 7 Apr 1999 01:32:33 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 733B452B7; Wed, 7 Apr 1999 01:26:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BCFD852BB; Wed, 7 Apr 1999 01:26:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <370AEC61.DE67E7F5@dnrc.bell-labs.com> Date: Wed, 07 Apr 1999 01:25:53 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: list iptel Subject: Minutes of Minneapolis meeting Content-Type: multipart/mixed; boundary="------------FDBE1B152AEFB8CFB4B332D8" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. --------------FDBE1B152AEFB8CFB4B332D8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, I've finished a first draft of the minutes, which are enlosed with this email. Comments, omissions, or errors are welcome. I'd also ask those who are mentioned by name in the minutes (Jonathan Lennox, Matt Squire, Hussein Salama, Scott Petrack, Dave Oran, Gur Kimchi, Jim Luciani) to give this a more careful read and make sure you have not been misquoted. Unfortunately, these are due end of the day today, so I need feedback asap. Sorry for the short notice, I only received the minutes recently. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------------FDBE1B152AEFB8CFB4B332D8 Content-Type: text/plain; charset=us-ascii; name="iptel_minutes_mar99.txt" Content-Disposition: inline; filename="iptel_minutes_mar99.txt" Content-Transfer-Encoding: 7bit iptel Meeting Minutes 44th IETF Minneapolis, MN Tuesday, Mar 16 1300-1515 Minutes prepared by: Jonathan Rosenberg Minutes taken by: Joerg Ott The iptel working group met for a single, busy, two hour session. There were neraly 200 people in attendance. The session was multicast on the mbone. The meeting started with agenda bashing. The original agenda was reordered. Squire disussed the open attribute issues first, and then he discussed the SCSP approach for GLP. Following that, Hussein Salama presented the TBGP approach for GLP. Jonathan Lennox then discussed CPL transport issues, followed by the CPL itself. GLP Data Representation Issues ------------------------------ Matt Squire, Nortel Networks Slides at http://www.bell-labs.com/mailing-lists/iptel/glp_data.ppt [Slide 2] There are a number of things required for the GLP routing objects. The phone number prefix is the most important one, and then there are a number of attributes that describe the route to this prefix. Some of these are optional, and some should be mandatory. [Slide 3] One of the main issues is how to represent phone numbers. There has been much discussion of this on the list. The encoding must be determined, along with the set that can be represented (range, prefix, regular expression), and whether we need "black holes". For the encoding, the proposal was to use a hex (i.e., 4 bits) representation for each digit, as this was more compact than the other proposals (char = 8 bits per number, or BCD of 8 bits per number). The general sense that encoding determination was premature, since there hadn't been sufficient discussion on the list in this in particular. Furthermore, the encoding should depend on how we do aggregation and what the numbers represent. Then, the tough issue of number representation (ranges, prefixes, or regexp) was presented. It was first argued that ranges were not much more useful than prefixes. However, Scott Petrack raised an interesting requirement. A certain ISP owns every 123-4567 number in each area code in the US, used as their "universal dialup number". A gateway might like to service a number like this, but it can't be represented with either ranges or prefixes. Regular expressions could work. However, David Oran raised the important point that the definition of "longest prefix match" is ill defined in the case of regular expressions. Some notion of this concept would be needed in order to enable routing to properly occur. The discussion then moved to the issue of "black holes"; the problem being that a set of prefixes might not be aggregatable since one of the numbers needed to perform the aggregation simply doesn't exist. This prefix is essentially a "black hole" in the numbering space. The question is - do we worry about this, and if so, what to do? The issue is related to whether aggregation is performed semantically (the LS knows the structuring of numbering plans, and groups together numbers which are groupable, by region, for example) or syntactically (based purely on redundancy in the bits, like is done with IP addresses). The question of what does it mean to "not exist" was raised. Are these numbers which will never exist, or temporarily out of service? What happens if an LS advertises a route to an aggregate since it thinks one of the routes that was aggregated doesn't exist anyway, but it actually does? Another issue is whether these black holes might explicitly be communicated as part of the route itself. It wasn't clear that this was useful. It was mentioned that the representation should support syntactic aggregation, but that semantic aggregation was allowed. An LS could advertise any prefix so long as it was sure it could reach that prefix, however this determination is made. Effectively, advertising a prefix was a "promise" of the ability to deliver service to this prefix. There was no consensus on any of these issues. It was agreed more discussion is needed on the list. [Slide 4] The next issue was what kind of numbers are allowed in GLP. Consensus was reached on the list that routable PSTN numbers are certainly included. There was apparent consensus that private numbers were not permitted (GLP being an inter-domain protocol). The open issue was with numbers like 800 numbers, or numbers which did not have global uniqueness (800 numbers are like this, how they are routed depends on where the call comes from). It was proposed [slide 5] that the LS need not understand the properties of these various numbers, and that any properties be conveyed by attributes. Matts' slides discussed the various ways in which a particular number might be treated based on caller locale, private numbering plans, time of day, and so on [slides 6,7,8,9]. After some discussion, there seemed to be consensus that for numbers which were not globally unique, we add an attribute (perhaps not called scope, a term over-abused on the list) which effectively makes the number unique. This attribute is, in fact, considered as nothing but an extension of the number itself, so the same aggregation rules for numbers apply to it. As for time of day sensitivity, there seemed to be consensus to keep these things out of GLP. It was recognized that there was a need for a "translation service", which would take a number like an 800 number, and based on any number of parameters provided by a user, result in a translation to a routable PSTN number. Then, GLP could be used to find the gateway towards this routing number. This translation service seemed to be within the scope of the enum group, under formation. The next issue discussed was that of lifetime [Slide 10]. Gateway objects may have finite lifetimes. For example, an 800 number may only be valid for a certain amount of time. So, do we include the lifetime in the routing object as an attribute, or should the advertising LS simply withdraw the route when it expires. There was general consensus that the route should be explicitly withdrawn, and there would be no lifetime attribute. This is consistent with existing routing protocols. An interesting and related issue was brought up. In GLP, an LS need not change the next hop for a route it propagates. So, in the following case: GW1 -----> LSA ------> LSB LSA knows of GW1, and sends an advertisement for it to LSB. The next hop is listed as "GW1" in the advertisement to LSB. Now, if the peer relationship between LSA and LSB is lost, should LSB assume the route to GW1 is also lost? Since LSA is not a next hop for signaling, its status as up or down has no bearing on whether the call can be completed or not. There was no consensus on this issue. The next issue was signaling protocols. These are an attribute of a gateway [slide 11]. The question was which protocols? There was consensus that H.323 and SIP were yes. Since MGCP is a control protocol, and not a signaling protocol, MGCP seemed unneeded, along with SGCP and IPDC, its predecessors. With H.323, the question was whether RAS and Q.931 were separate or not. There was no decision. It was agreed that we would provide a few tags, and define IANA procedures for registering new ones for future signaling protocols. The final attribute issue discussed was capacity [slide 12]. The questions are absolute vs. relative, static vs. dynamic, and whether its a path, gateway attribute, or both. Also whether the metric is dimensioned or dimensionless. There was consensus at the last meeting that this metric was not dynamic, but represented the total capacity of the gateway. There was no objection to the decision to use a dimension for the metric in order to allow vendors to independently set the metric and use comparable values. There was no consensus on what the dimension should be (calls, bits/sec, etc.). Unfortunately, time ran out and the next presentation began. Gateway Location Protocol based on SCSP --------------------------------------- Matt Squire, Nortel Networks http://www.bell-labs.com/mailing-lists/iptel/glp_scsp.ppt Matt presented his arguments on why SCSP was a good choice as a basis for GLP. First off, GLP is an inter-domain protocol, so one immediately thinks of BGP. However, this is not a layer 3 protocol, and there are differences, so a different approach is warranted. SCSP provides database synchronization among autonomous servers. SCSP defines a server group (SG) as a collection of servers being synchronized. The idea with SCSP is that for interdomain exchanges, the SG has two, and exactly two, servers - the two peers. For interior exchange among GLP LS's in the same domain, there is a different SG [Slide 2]. SCSP supports arbitrary topologies for this interior synchronization. The model of a GLP LS was shown [Slide 3]. Through various server groups, it learns about gateways, and based on policy decisions, propagates these to other server groups. Matt then presented the reasons why GLP is not BGP: 1. BGP must always provide a next hop on the same LAN. However, since GLP is at a higher level, there is an underlying IP transport service. So, an LS can choose to not modify the next hop at all; it can be bypassed all together for signaling. The only reasons to actually change it are for (1) aggregation, or (2) collection of billing information from the signaling messages [Slide 4,5]. 2. In BGP, if there are two routes to a destination, only one is propagated. Basically, routes are "homogeneous" - they are all the same. Not true in GLP. Routes for the same prefix may be different if their attributes (like signaling protocol) are different, and so both may need to be propagated. BGP doesn't do this. [slide 6] 3. In BGP, the FIB is extracted purely based on destination address. This doesn't work in GLP. A "FIB" would need to also look at the parameters of the call signaling to determine which route is appropriate. Thats because GLP routes call signaling messages, which are much more complex than IP packets. [slide 7] 4. Efficiency and scaling requirements differ (fewer call setup messages compared to packets) [Slide 8]. However, Dave Oran pointed out that an LS may also route voice packets. He argued that this was useful for firewall traversal, and would motivate providing next hop information in general for GLP, for both signaling and media (next hop at the layer 7, GLP, definition). Next, Matt argued why SCSP was a good choice: 1. SCSP separates the synchronization of data from the semantics of the data itself [slide 9]. This is perfect for GLP, where we need a generic sync mechanism, and then need to add GLP specific attributes and data on top. SCSP was designed to be a "core" component, with instances defined for specific applications. 2. SCSP supports arbitrarily connected topologies for intra-domain synchronization [slide 10] 3. SCSP can run on any transport [slide 11] There was little discussion at this point; most of it followed the presentation on TBGP. Telephony Border Gateway Protocol (TBGP) ---------------------------------------- Hussein F. Salama, Cisco, hsalama@cisco.com Quick TBGP overview [Slide 2] - based on BGP-4 and its multiprotocol extensions - reliability, peering relationships, loop detection mechanisms - advertised reachability of PSTN destinations and IP destinations - multi-hop call routing. egress gw is just another hop on call route - route selection. intermediate domains apply policy on call route network admin control route selection - route aggregation BGP itself does not solve all the GLP problems. We propose an extension sthat taskes care of additonal needs. The first question is whether TBGP and BGP4 are the same (i.e., do we introduce telephone numbers into existing, running, BGP-4 systems). Answer is NO. TBGP runs separately from BGP4. But, we leverage experience from the specification to make a good protocol [slide 4]. TBGP supports multiple protocol types (SIP, H.323), route aggregation, route selection etc. How to handle the case where the media flows through the LS? [slide 5] Dave Oran then proposed a scheme for dynamic capacity metrics. The idea is that when a gateway has used all its capacity, it withraws routes to itself with its peers. When it has capacity, it puts it back. Normally, you need route-dampeners at next hops, so some of this oscillation would be avoided. This provides a way to propagate a sort-of-dynamic metric, but in a more scalable way. There were concerns raised about the scalability of this solution, and no consensus was reached on whether to do this. Hussein then discussed the Intra-domain vs. inter-domain call routing scenarios [slide 7]. He argued that these are much different problems, and that intra domain worries most about QoS and multihop call routing, while inter-domain worries about policy and cost, and QoS is much different. Thus, he countered the argument that SCSP was good since it helps solve the intra-domain problem. We should leave the intra-domain problem to another group, and weigh the protocols based on their ability to do inter-domain. The remainder of Hussein's slides focused on attribute issues, and since these were discussed already they were skipped. Concusions - TBGP satisfies all tranport requirements of the GLP framework - attributes are yet to be defined - well tested and scales well - we know how this works! - intra-domain call route is a separate problem Jim Luciani argued that SCSP's strength is to allow for arbitrary topologies, and that it could handle intra-domain QoS issues. Someone argued that since SCSP was similar to OSPF, it wouldn't handle things like AS path, which were needed in an inter-domain case. This was countered with the argument that we could make AS-path just another attribute that gets synchronized by SCSP between peers, and get this functionality. Another strength of SCSP was that the nodes that are synchronized don't need to understand the semantics of the data being synchronized, that is handled by the higher layers. The question was asked as to whether there were commercial and interoperable implementations of SCSP. The answer (from Jim) - yes, they are out there, and yes they are commercial. It was concluded that in the inter-domain case, the type of information being carried by BGP and SCSP would be similar, and thus the differences between the protocols was at a much more detailed level. To resolve the issue, the chair asked the authors to do a "homework assignment", and work on understanding detailed differences between the two proposals. This will then be taken to the list. At this point, the group left discussions of the GLP, and focused on the CPL. The first presentation was on transport. CPL and CGI Transport in SIP Register Paylaod --------------------------------------------- Jonathan Lennox, Columbia University http://www.bell-labs.com/mailing-lists/iptel/sipreg-minneapolis1.pdf Jonathan quickly went over his slides. The basic idea was that the CPL is uploaded to the server in a REGISTER message. There is a single server per user. The main issue is persistene. Normally, a SIP registration times out, and disappears unless refreshed. But, CPL's would not time out. They would be uploaded once, and never re-uploaded when the registration itself is refreshed. This generated some discussion about whether this model was right. One idea (Gur Kimchi) was that the REGISTER contains a script for the client, and when it registers, that script is used. When the client goes away, and the registration expires, so does its script, and then we use the script that was previously in place. Scott Petrack argued as to why do this in SIP at all? Why can't I use ftp, or http, or whatever? Clearly REGISTER was not meant to send user logic to a server. The answer was that SIP provides much of the transport service we need. It gives authentication, it uses the same identifiers we need to tie the script to a user, and its the same application. However, there was agreement that there need not be a single transport mechanism. Another issue was whether the "one-script" model is sufficient. We may need more. Jonathan R. raised the concern, however, that if more than one script exists, how would the server know which to execute when the call arrives? Rather, there is a single top level script, and the user can upload multiple files which get linked in to the script at specific points. This is really mutiple files, still a single script though. Dave Oran raised an important issue - that there is a difference between a *user* and a *client*. The client is one instance of the user. Both clients (like my cell phone or work PC) and users may have logic they'd like to upload. So, the framework should allow for scripts for users and clients. Scott Petrack added further that a single user may have multiple scripts, each at a different server. Jonathan Lennox then continued with his presentation, focusing on some of the open issues. It was suggested that even SNMP might be used for transport, and that the MIB specifies the script. Given the various options for transport, there was consensus that the transport problems should not be tackled in iptel. Rather, if someone wanted to use protocol X for transport of CPL, the CPL transport would be done in the group specifying protocol X. Jonathan Lennox was asked to repeat his presentation to mmusic for this reason. The next presentation was on the CPL itself. Call Processing Language ------------------------ Jonathan Lennox, Columbia University http://www.bell-labs.com/mailing-lists/iptel/cpl-minneapolis1.pdf Jonathan began by showing that the CPL model is based on a DAG (directly acyclic graph), which describes the flow for a service. Each node is a decision or an action, and the outputs represent decision results or action results [slide 2] He then summarized the features [slide 4]. There are switches for making decisions (based on time, or by string matches of fields in the request messages), and actions, such as proxy, redirect, and respond. There is also a location action for setting the destination of a proxy or redirect, and a lookup action for querying a database. There are also non-SIP actions, such as notify and log. Scott Petrack raised the issue about whether XML is an efficient representation. Jonathan L.'s response was that the XML is for transmission. Once it arrives at the server, it is parsed and stored in some internal format which can be efficiently executed. Thus, the parsing overhead is suffered only on registrations. Gur suggested a binary representation instead. Gur also asked if the script is persistent during the call. The answer was not in this version; the script is "done" once the call is established. We have left hooks for future scripts to specify services after the call is established. Matt Cannon asked if the script could specify logic for OPTIONS. Right now, no; but this could easily be added. Another question was whether the CPL should support decisions based on media types for the call (audio, video, etc.). There seemed to be consensus that this was a good thing to have. Jonathan then continued with the open issues. URL matching is currently done by string matching, which is nicely general but not very efficient, and it is hard to do certain things. Supporting URL specific decisions means that the script may no longer be H.323/SIP independent. Time switches also presented problems. Timezones are especially difficult, since there is no registry of names for timezones. So, the CPL assumes that the user and server sit in the same timezones. A question was asked as to why not just represent timezones as an offset from GMT? The answer is daylight savings time makes this offset variable. Jonathan L. asked the question about whether CPL should be configurable about whether to do recursion. Dave Oran responded that this stuff is really new, and we should absolutely stick with KISS, get something out the door, get some operational experience, and then build on that. So, the answer to the original question seemed no - there was consensus that specifying SIP recursion or not was outside the scope of CPL. With that, the meeting concluded. --------------FDBE1B152AEFB8CFB4B332D8-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 7 05:26:15 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02521 for ; Wed, 7 Apr 1999 05:26:15 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id BC28C52BB; Wed, 7 Apr 1999 05:21:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 221C452BF; Wed, 7 Apr 1999 05:21:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.5.32.19990407111742.007b1210@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 07 Apr 1999 11:17:42 +0200 To: conf@colmar.colmar.uha.fr From: Conf ICATM99 Subject: ICATM99 - Preliminary Program Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA02521 Please feel free to circulate this following preliminary program of ICATM99 to interested colleagues (see http://iutsun1.colmar.uha.fr/ICATM99.html for more information). Accept our sincere apologies if you receive multiple copies. ------------------------------------------------------------------ TECHNICAL PROGRAM 08:00 - 18:00 Conference Registration Monday June 21 08:30 - 09:00 Opening Address 09:00 - 10:00 Tutorial Session 1 Chair: M. Lee Mobile and Wireless ATM Networks - Third Generation Systems (UMTS/IMT2000) G. Omiyar, GTE Telecom, Egypt 10:00 - 10:30 Coffee Break 10:30 - 11:30 Tutorial Session 2 Chair: S. Rao Rich VPNs: the Best win-win Deal between a Carrier and its Customers S. Ritzenthaler, Newbridge, France 11:30 - 12:30 Tutorial Session 3 Chair: J. Crowcroft Implementing Ipv6 over ATM M. Souissi, F. Dupont, B. Leroy, INRIA Rocquencourt, France 12:30 - 14:00 Lunch - Restaurant Universitaire 14:00 - 15:30 Wireless ATM 1 Chair: G.S. Kuo A Hybrid Data/Header Interleaving Strategy for Wireless ATM Networks S.T. Sheu, T.F. Sheu, TamKang University, China A Deadlock Model for a Multi-Service Medium access Protocol Employing Multi-Slot N-ARY Stack Algorithm (MSSTART) F. Cameron, M. Zukerman, University of Melbourne, Australia Optimal DLC Protocol Configuration for Realistic Broadband Fixed Wireless Access Networks based on ATM S. Mangold, Aachen University of Technology, Germany 14:00 - 15:30 Flow Control in ATM: ABR 1 Chair: P. Rolin Guaranteeing Fairness and Protection in ABR by Means of Fair Queuing L.A. Guijarro, J.R. Vidal, J.Martinez, University of Valencia, Spain Fluid Analysis of a TCP Connection over ABR, in Presence of Exogenous Flow J.L. Costeux, CNET, France Bidirectional ABR Mechanism P. Homan, J. Bester, University of Ljubljana, Slovenia 15:30 - 15:45 Coffee Break 15:45 - 17:15 Wireless ATM 2 Chair: G. Omidyar Routing Protocols for Wireless Ad hoc ATM Networks A. Hettich, A. Kadelka, H. Kukulies, Aachen University of Technology, Germany Hand-Off and Synchronization Protocol for Supporting Multimedia Communications in an ATM based Wireless Network A. Leon, M. Esteve, J.C. Guerri, C. Palau, A. Pajares, Polytechnic University of Valencia, Spain A Flexible Signaling Protocol for Supporting Switched AAL Type 2 Connections in UMTS Terrestrial Radio Access Networks I.. Szabo, Ericsson, Hungary 15:45 - 17:15 Flow Control in ATM: ABR 2 Chair: G. Pujolle Evaluation of the Virtual Source/Virtual Destination-Technique for Available Bit Rate Traffic in ATM-Networks J. Baalmann, C. Cseh, University of Technology Aachen, Germany ABR Rate Control for Multimedia Traffic using Microeconomics E.W. Fulp, D.S. Reeves, North Carolina State University, USA Evaluation of the TCP Traffic over the ABR Service Targeted to Support Mass Storage Applications I. Mountzouris, G. Orphanos, A. Birbas, S. Koubias, G. Papadopoulos, University of Patras, Greece 17:15 - 17:30 Coffee Break 17:30 - 19:00 Management Chair: S. Rao Model-Based-Diagnosis for Fault Management in ATM Networks F. Krief, A. Osmani, Institut Galilée, France A Model of Fault Messages for Maintenance of UNI/NNI Resources in HANbit ACE64 ATM Switching System G. Kwon, ETRI, Korea Dynamic Management of Routing Tables and Connection Re-routing in ATM Networks S. Kumar, S.V. Raghavan, Indian Institute of Technology Madras, India 17:30 - 19:00 Multicast Chair: J.J. Pansiot Compound VC Mechanism for native Multicast in ATM Networks J. Mangues-Bafalluy, J. Domingo-Pascual, Polytechnic University of Catalunya, Spain IPv6 Multicasting over ATM Testbed J.S. Silva, N. Veiga, S. Duarte, F. Boavida, University of Coimbra, Portugal Design and Analysis of Multicast Delivery to Provide VCR Functionality in Video-on Demand Systems W. Poo, K.T. Lo, The Hong Kong Polytechnic University, Hong Kong ; J. Feng, City University of Hong Kong, Hong Kong Tuesday June 22 09:00 - 10:30 Real-Time Traffic Chair: M. Dickmann A Method for Accurate Time Synchronization through In-Service Monitoring in ATM Networks D. Vidal, University of the Balearic Islands, Spain Delay Jitter Guarantee for Real-Time Communications with ATM Network Z. Mammeri, University Paul Sabatier, France Hierarchical Vector Clock: Scalable Plausible Clock for Detecting Causality in Large Distributed Systems D.A. Khotimsky, Lucent Technologies, USA ; I.A. Zhuklinets, Mozhaysky Academy, Russia 09:00 - 10:30 IP over ATM 1 Chair: G. Girardi Shortcutting IP Flows over Large ATM Networks J. Schmitt, L. Wolf, M. Karsten, R. Steinmetz, Darmstadt University of Technology, Germany ; Y.O. Lorcy, C. Siebel, Deutsche Telekom, Germany Measurement-Based Simulation Model for TCP over ATM G. Seres, T. Elteto, A. Olah, Ericsson telecommunications, Hungary On the Efficiency of Packet telephony over IP and ATM M. Baldi, F. Risso, Polytechnic of Torino, Italy 10:30 - 11:00 Coffee Break 11:00 - 12:30 Traffic Control Chair: D. Kofman Networks Performance Based Connection Admission Control Model in ATM Networks: Immediate and Future Reservation Approaches M. Nour, University of Montreal, Canada ; A. Hafid University of Western Ontario, Canada ; M. Gendreau, University of Montreal, Canada Validating novel CAC algorithms on ATM testbeds J. Levendovszky, Z. Elek, C. Vegso, Technical University of Budapest, Hungary The Design of an Object-Oriented Simulation Tool for Evaluating ATM Network Resource Control Scheme J. Soldatos, D. Vergados, E. Vayias, N. Mitrou, National Technical University of Athens, Greece 11:00 - 12:30 IP over ATM 2 Chair: F. Vanney A Framework for Testing IP QoS over ATM Networks: Implementation and Practical Experiences N. Kroth, L. Mark, J. Tiemann, GMD, Germany A Study on Advanced Asynchronous Transfer Mode for High-Speed Computer Communication Networks K. Toyoshima, K. Hayashi, NTT, Japan VTOA/VoIP/ISDN Telephony Gateway A.M. Grilo, P.M. Carvalho, L.M. Medeiros, M.S. Nunes, INESC, Portugal 12:30 - 14:00 Lunch - Restaurant Universitaire 14:00 - 15:30 Quality of Service Chair: A. Benslimane Efficient Buffer Management and Scheduling in a Combined IntServ and DiffServ Architecture: a Performance Study G. Mamais, M. Markaki, G. Politis, I.S. Venieris, National Technical University of Athens, Greece Interaction of RSVP with ATM for the Support of Shortcut QoS Virtual Channels R. Cocca, S. Salsano, CoRiTeL, Italy ; M. Listanti, University of Rome, Italy Interactive Services over HFC Networks M.I. Borges Ribeiro, F. Fontes, J. Bastos, J. Loureiro, Portugal Telecom, Portugal 14:00 - 15:30 IP over ATM 3 Chair: M. Stuttgen Analysis on IP Label Switching Technology in Future Broadband Internet G.S. Kuo, H.C. Cheng, National Central University, Taiwan Analysis of Internet Services in IP over ATM Networks J. Aracil, M. Izal, D. Morato, University of Navarra, Spain Simulation and Analysis of IP/ATM Switching and Routing M.Z. Santos, L.G. Kiatake, F. Meylan, S.T. Kofuji, University of Sao Pailo, Brazil ; J.P. Coutiat, LAAS-CNRS, France 15:30 - 15:45 Coffee Break 15:45 - 17:15 Scheduling Chair: R. Muraine Flow Service Order: A Computationally Inexpensive Packet Scheduling Algorithm to Guarantee QoS for Real-Time Traffic S.R. Kulkarni, Indian Institute of Technology, India A Feasible Scheduling Algorithm for Per-VC Queuing ATM Switches P. Zhou, W.W. Yang, Nortel Networks, Canada Digital Neural Cell Schedulers for ATM Switch S.M. Lee, J.H. Chung, Y.C. Kim, M.M. Lee, Dongshin University, Korea 15:45 - 17:15 User Applications Chair: M. Potts ATM-Based Infrastructure for Teleteaching at University A. Klein, F. Bodendorf, University of Erlangen-Nuremberg, Germany Desktop Videoconferencing Performance and Quality of Service Evaluation on an ATM-based Metropolitan Area Network: OASICE Case Study H. Tobiet, Clemessy, France ; P. Lorenz, University of Haute Alsace, France Connecting Heterogeneous Supercomputers in Broadband Networks E. Pless, F. Hommes, GMD, Germany 17:15 - 17:30 Coffee Break 17:30 - 19:00 Management and multiplexing Chair: Z. Mammeri A Management System Providing Real Distribution of Management Tasks with Time and Space Independence F. Fontes, Portugal Telecom, Portugal ; T. De Miguel, A. Azcorra, University of Madrid, Spain Implementing Inverse Multiplexing for ATM A. Pires, Mitel Corporation, Canada The Heap-Sort Based ATM Cells Spacer T. Ha-Duong, MET, France 17:30 - 19:00 Protocols and Routing Chair: P. Droz Minimum Equivalent Subspanner Algorithms for Topology Aggregation in ATM Networks W. Chiou Lee, Motorola, USA Shared-Medium Architecture for ATM Local Network M. Soto, S. Sallent, Polytechnic University of Catalonia, Spain Analysis of the Crankback Probability in a Hierarchical PNNI Network J.L. Rougier, D. Kofman, ENST, France ; A.R. Ragozini, University of Napoli, Italy ; A. Gravey, CNET, France 20:00 Gala Dinner - Restaurant Meistermann Wednesday June 23 09:00 - 10:30 Intelligent Networks Chair: P. Lorenz Design and Implementation of an Intelligent Peripheral for Broadband Multimedia Applications H. Brandt, P. Todorova, GMD, Germany A TINA-Based Platform for Service Deployment and Usage J. P.C. Verhoosel, Telematics Institute, The Netherlands ; H.J. Batteram, J.L. Bakker, Lucents Technologies, The Netherlands Performance of the fair Intelligent Congestion Control for TCP Applications over ATM Networks D.B. Hoang, Q. Yu, University of Sydney, Australia 09:00 - 10:30 ATM Switches 1 Chair: Z. Hulicki RCES: A Replication/Contention/Elimination Strategy for Replication Baseline ATM Switch Architectures S.T. Sheu, Y.R. Chuang, TamKang University, China Advanced Frame Recovery in Switched Connection Inverse Multiplexing for ATM F.M. Chiussi, D.A. Khotimsky, S. Krishnan, Lucent Technologies, USA Implementation of an ATM Switch for PSTN/N-ISDN Services X. Gong, P. Zhang, W. Wang, S. Cheng, university of Posts and Telecom, China 10:30 - 11:00 Coffee Break 11:00 - 12:30 Error Detection and Correction Chair: O. Charles Implementation of an Error Detection-Recovery System based on Multimedia Collaboration Works: EDRS E.N. Ko, Sung Kyun Kwan University, South Korea New Error Control Enhancing Technique for Wireless ATM Networks M.M. Al-Khatib, M. Bayoumi, USL, USA A Parallel Reed-Solomon Coding/Decoding Structure for an ADSL Modem with Increased Interleaving for ATM Applications S. Toptchiyski, D. Sofos, V. Stylianakis, University of Patras, Greece 11:00 - 12:30 ATM Switches 2 Chair: S. Ritzenthaler An Efficient Address Assignment Strategy for Shared Multibuffer ATM Switches P.G. Lee, W.C. Kang, Y.H. Choi, Hongik University, Korea Implementation of Bifurcated Buffering in Input Buffer Banyan ATM Switch I.D. Radusinovic, Z.R. Petrovic, M.Pejanovic-Djurisic, University of Montenegro, Yugoslavia An Approximate Analysis of a Shared Buffer ATM Switch using Input Process Aggregation Technique J.Kim, C.H. Jun, Pohang University of Science and Technology, Korea ; K.P. Jun, Electronics and Telecommunications Research Institute, Korea 12:30 - 14:00 Lunch - Restaurant Universitaire 14:00 - 16:00 Performance Chair: H. Tobiet Performance Evaluation of a RR Switch for ABR Service D.H. Kim, Y.Z. Cho, Kyungpook National University, Korea Performance Models for IP Switching J. Zheng, V.O.K. Li, University of Hong Kong, Hong Kong Inverse Multiplexing for ATM Operation, Applications and Performance Evaluation Issues M. Aguilar-Igartua, J. Garcia-Haro, M. Postigo-Boix, Polytechnic University of Catalonia, Spain Performance Evaluation of Packet Discard Schemes in ATM Switches in Heterogeneous Traffic Environment Z. Jing, L. Li, University of Electronic Science and Technology, China ; H. Sun, Center for Advanced Computing and Communications, China 14:00 - 16:00 Video over ATM Chair: J. Montiel Error Resilient Protocol Architecture for the MPEG-2 Video Transmission over ATM Networks P. Cuenca, A. Garrido, F. Quiles, University of Castilla-La Mancha, Spain ; L. Orozco-Barbosa, University of Ottawa, Canada De-Jittering in the transport of MPEG-4 and MPEG-2 Video over ATM K. Shuaib, T. Saadawi, M. Lee, City College of New York, USA, B. Basch, GTE Laboratories, USA Proactive Management of MPEG Traffic in ATM Networks using Time Sequenced RLS Filters T.S. Randhawa, British Columbia Group, Canada ; R.H.S. Hardy, Simon Fraser University, Canada Linear Codes for End to end Cell Loss Recovery in VBR Video Transmission over ATM Networks Z. Alkhalifa, V.S.S. Nair, Southern Methodist University, USA 16:00 Closing Session ICATM'99 Registration Form Please mail the complete Registration Form to : Pascal LORENZ / ICATM'99 IUT/GTR - 34 rue du Grillenbreit - 68008 Colmar, France Phone : 33 (0)3 89 20 23 66   Fax : 33 (0)3 89 20 23 59   Mobile: 33 (0)6 03 65 80 42 Email : lorenz@colmar.uha.fr Title: _______ First Name: _____________ Last Name: ______________________ Institution: ___________________________________________________________ Street Address: ________________________________________________________ City: __________ State: ____________ Zip: ___________ Country: ____________ Phone: ____________________________ Fax: ______________________________ Email : ____________________________ Arrival Date :     ____ June 1999 at _____ Departure Date :   ____ June 1999 at _____ Conference Registration Fees: The Full registration fees include: attendance to the Conference, coffee breaks, 3 lunches, the gala dinner and the preprints. Academic rate:                IEE, IEEE, SEE Member                    2400 FF                       _________ FF (Membership # __________) non member                               2600 FF                       __________ FF Industry rate:                           4000 FF                       __________ FF Additional Conference Proceedings (FF 400):                            __________FF Additional Gala Dinner (FF 300):                                       __________FF                                      Total French Francs ..............   _________ Payment of Fees: __ By Foreign Check in French Francs to "Office du Tourisme de Colmar". __ By Bank Transfer to: Caisse d'Epargne d'Alsace, Avenue de la République, 68000 Colmar - France. Bank code: 16705 - Counter code: 09017 - Account number: 04100568821 - Key: 23 - Account name: Office du Tourisme de Colmar - Transfer Swift : BFCE FR PP 317 __ By Credit Card:      __ Mastercard      __ Visa      __ American Express Card number: _________________________ Expiration date: _________ Signature:   --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 7 10:53:23 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09789 for ; Wed, 7 Apr 1999 10:53:22 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2B1C352C1; Wed, 7 Apr 1999 10:48:01 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9ABC452C2; Wed, 7 Apr 1999 10:48:00 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <370B6F76.ACF59EF2@dnrc.bell-labs.com> Date: Wed, 07 Apr 1999 10:45:10 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "Hoefelmeyer, Ralph (MCI)" Cc: Jerry Scharf , iptel@lists.research.bell-labs.com Subject: Re: is there a better list to ask H.323 questions of References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I'm not on the list; I know of its existence but don't know how to join. Perhaps someone who is on this list can send instructions? Thanks, Jonathan R. > Hoefelmeyer, Ralph (MCI) wrote: > > It might help to tell everyone how to join the h323 implementers list > ... > > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com] > Sent: Tuesday, April 06, 1999 3:32 PM > To: Jerry Scharf > Cc: iptel@lists.research.bell-labs.com > Subject: Re: is there a better list to ask H.323 questions > of > > This is not the right list. This list is for the iptel working > group in > IETF. Please use the h323 implementors list for h.323 questions. > > Thanks, > Jonathan R. > > Jerry Scharf wrote: > > > > I have seen several questions on H.323 go by here. I have one > on V2 and was > > wondering if there is a better place to ask it or if here is > the right > > place. > > > > thanks, > > jerry > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing > List. > > -- > Jonathan D. Rosenberg Lucent Technologies > Member of Technical Staff 101 Crawfords Corner > Rd. > High Speed Networks Research Holmdel, NJ 07733 > FAX: (732) 834-5379 Rm. 4C-526 > EMAIL: jdrosen@bell-labs.com > URL: http://www.cs.columbia.edu/~jdrosen > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 7 11:06:21 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10026 for ; Wed, 7 Apr 1999 11:06:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D3FB352BF; Wed, 7 Apr 1999 11:01:14 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3CCE852C5; Wed, 7 Apr 1999 11:01:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.1.32.19990407085343.00be58f0@pop3.mail.mci.com> X-Sender: lgrimald@pop3.mail.mci.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 07 Apr 1999 08:53:43 -0600 To: Jonathan Rosenberg From: Linda Grimaldi Subject: Re: Minutes of Minneapolis meeting Cc: list iptel In-Reply-To: <370AEC61.DE67E7F5@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Folks, Regarding this excerpt from the meeting minutes, I don't see why supporting URL matching precludes using H.323. H.323v2 does support URLs as addresses in the alias fields. As long as other location types and generic string matching are also supported, it shouldn't be a problem. Also, while the timezone problem may be sticky, the assumption about the server and the user being in the same time zone makes the feature almost unusable, in my opinion. Seems to me that if the server knows the timezone it is in and it knows the timezone the user is in (user would presumably have to register updates as he moves around), it should be possible to calculate the difference. Time zone registrations include the state of daylight savings time (eg, EST vs EDT) and the calculation can be table driven, matching the time zone registered with the offset from GMT. I think this would work- there are probably better ways- but unless this issue is solved, there is precious little utility in TOD matching. Linda At 01:25 AM 4/7/99 -0400, Jonathan Rosenberg wrote: >Folks, > >> >Jonathan then continued with the open issues. URL matching is >currently done by string matching, which is nicely general but not >very efficient, and it is hard to do certain things. Supporting URL >specific decisions means that the script may no longer be H.323/SIP >independent. > >Time switches also presented problems. Timezones are especially >difficult, since there is no registry of names for timezones. So, the >CPL assumes that the user and server sit in the same timezones. A >question was asked as to why not just represent timezones as an offset >from GMT? The answer is daylight savings time makes this offset >variable. > Linda Grimaldi MCI WorldCom 2424 Garden of the Gods Road Colorado Springs, CO 80919 Tel. 719-592-9588 Email: linda.grimaldi@mci.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 7 11:10:25 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10101 for ; Wed, 7 Apr 1999 11:10:24 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D772F52AA; Wed, 7 Apr 1999 10:35:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 42D2552C1; Wed, 7 Apr 1999 10:35:16 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "Hoefelmeyer, Ralph (MCI)" To: "'Jonathan Rosenberg'" , Jerry Scharf Cc: iptel@lists.research.bell-labs.com Subject: RE: is there a better list to ask H.323 questions of Date: Wed, 7 Apr 1999 15:34:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE8103.CB084778" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk 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_01BE8103.CB084778 Content-Type: text/plain It might help to tell everyone how to join the h323 implementers list ... > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com] > Sent: Tuesday, April 06, 1999 3:32 PM > To: Jerry Scharf > Cc: iptel@lists.research.bell-labs.com > Subject: Re: is there a better list to ask H.323 questions of > > This is not the right list. This list is for the iptel working group in > IETF. Please use the h323 implementors list for h.323 questions. > > Thanks, > Jonathan R. > > Jerry Scharf wrote: > > > > I have seen several questions on H.323 go by here. I have one on V2 and > was > > wondering if there is a better place to ask it or if here is the right > > place. > > > > thanks, > > jerry > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > -- > Jonathan D. Rosenberg Lucent Technologies > Member of Technical Staff 101 Crawfords Corner Rd. > High Speed Networks Research Holmdel, NJ 07733 > FAX: (732) 834-5379 Rm. 4C-526 > EMAIL: jdrosen@bell-labs.com > URL: http://www.cs.columbia.edu/~jdrosen > > --------- > This message came from the IETF IPTEL Working Group Mailing List. ------_=_NextPart_001_01BE8103.CB084778 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: is there a better list to ask H.323 questions of

It might help to tell = everyone how to join the h323 implementers list ...

    -----Original Message-----
    From:   Jonathan Rosenberg = [SMTP:jdrosen@dnrc.bell-labs.com]
    Sent:   Tuesday, April 06, 1999 3:32 PM
    To:     Jerry Scharf
    Cc:     iptel@lists.research.bell-labs.com
    Subject:       = Re: is there a better list to ask = H.323 questions of

    This is not the right list. This = list is for the iptel working group in
    IETF. Please use the h323 = implementors list for h.323 questions.

    Thanks,
    Jonathan R.

    Jerry Scharf wrote:
    >
    > I have seen several = questions on H.323 go by here. I have one on V2 and was
    > wondering if there is a = better place to ask it or if here is the right
    > place.
    >
    > thanks,
    > jerry
    >
    > ---------
    > This message came from the = IETF IPTEL Working Group Mailing List.

    --
    Jonathan D. = Rosenberg          &nb= sp;            = Lucent Technologies
    Member of Technical = Staff           &= nbsp;       101 Crawfords Corner = Rd.
    High Speed Networks = Research          &nbs= p;     Holmdel, NJ 07733
    FAX:   (732) = 834-5379          &nbs= p;            = Rm. 4C-526
    EMAIL: = jdrosen@bell-labs.com
    URL: http://www.cs.columbia.edu/~jdrosen

    ---------
    This message came from the IETF = IPTEL Working Group Mailing List.

------_=_NextPart_001_01BE8103.CB084778-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 7 11:11:04 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10147 for ; Wed, 7 Apr 1999 11:11:03 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C4F8152D7; Wed, 7 Apr 1999 11:09:24 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2102C52CF; Wed, 7 Apr 1999 11:09:21 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Wed, 7 Apr 1999 17:08:47 +0200 (MET DST) From: Krijn Mossel X-Sender: kmossel@hvss122.nl.lucent.com Reply-To: Krijn Mossel To: Jonathan Rosenberg Cc: "Hoefelmeyer, Ralph (MCI)" , Jerry Scharf , iptel@lists.research.bell-labs.com Subject: Re: is there a better list to ask H.323 questions of In-Reply-To: <370B6F76.ACF59EF2@dnrc.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Anyone wanting to join the H.323 Implementors' mailing list should send an e-mail to h323implementors-request@imtc.org with "info" in the body. Krijn Mossel On Wed, 7 Apr 1999, Jonathan Rosenberg wrote: > I'm not on the list; I know of its existence but don't know how to join. > Perhaps someone who is on this list can send instructions? > > Thanks, > Jonathan R. > > > Hoefelmeyer, Ralph (MCI) wrote: > > > > It might help to tell everyone how to join the h323 implementers list --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 7 11:51:48 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11007 for ; Wed, 7 Apr 1999 11:51:47 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3845852C5; Wed, 7 Apr 1999 11:45:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8E6A752C6; Wed, 7 Apr 1999 11:45:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199904071544.LAA20181@mailhost.corpeast.BayNetworks.COM> X-Sender: jluciani@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 07 Apr 1999 11:44:55 -0400 To: list iptel From: "JAMES V. LUCIANI" Subject: Re: Minutes of Minneapolis meeting In-Reply-To: <370AEC61.DE67E7F5@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Have not done a careful inspection but did notice a boo boo... >The question was asked as to whether there were commercial and >interoperable implementations of SCSP. The answer (from Jim) - yes, >they are out there, and yes they are commercial. I was not the one who said this, but I subsequently found out that it is correct. Not sure if I should mention companies and products without the consent of those companies... However, if anyone has implementation info that they want to share please do so. FWIW, SCSP is used for LNNI, standards based NHRP NHS synch, ATM ARP sync and a few others. ==JIm --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 7 12:01:54 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11197 for ; Wed, 7 Apr 1999 12:01:53 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 45C0F52C6; Wed, 7 Apr 1999 11:47:38 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5F69E52C7; Wed, 7 Apr 1999 11:47:37 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <003501be810d$e9f10f80$346999ce@orit.radvision.com> Reply-To: "Orit Levin" From: "Orit Levin" To: "Jonathan Rosenberg" , "Hoefelmeyer, Ralph (MCI)" Cc: "Jerry Scharf" , Subject: Re: is there a better list to ask H.323 questions of Date: Wed, 7 Apr 1999 11:47:16 -0400 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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Below is the description for two mailing lists: implementors and H.323 general list ---------------- "h323implementors@imtc.org" You must send any posted email to the list with h323implementors@imtc.org. To send a message to the imtc-members list, send an email message to the "h323implementors@imtc.org" To subscribe to this list, just send an email message to majordomo@imtc.org in the message body simply type: "subscribe imtc-h.323 implementors (email address)" To unsubscribe yourself from the list, send an email message to majordomo@imtc.org in the message body simply type: "unsubscribe imtc-h.323 implementors (email address)" To insure "spam" mail is kept to a minimum, only people subscribed to the list will be able to post to it. Beck Horacek will be maintaing all mail lists. Please do not hesitate to contact her should you have any further comments or questions, at +1.925.277.1320. Interprise Ventures/IMTC ------------------------------------------------- To send a message to all the people currently subscribed to the list, just send mail to ITU-SG16@MAILBAG.INTEL.COM. This is called "sending mail to the list", because you send mail to a single address and LISTSERV makes copies for all the people who have subscribed. This address (ITU-SG16@MAILBAG.INTEL.COM) is also called the "list address". You must never try to send any command to that address, as it would be distributed to all the people who have subscribed. All commands must be sent to the "LISTSERV address", LISTSERV@MAILBAG.INTEL.COM. It is very important to understand the difference between the two, but fortunately it is not complicated. The LISTSERV address is like a FAX number that connects you to a machine, whereas the list address is like a normal voice line connecting you to a person. If you make a mistake and dial the FAX number when you wanted to talk to someone on the phone, you will quickly realize that you used the wrong number and call again. No harm will have been done. If on the other hand you accidentally make your FAX call someone's voice line, the person receiving the call will be inconvenienced, especially if your FAX then re-dials every 5 minutes. The fact that most people will eventually connect the FAX machine to the voice line to allow the FAX to go through and make the calls stop does not mean that you should continue to send FAXes to the voice number. People would just get mad at you. It works pretty much the same way with mailing lists, with the difference that you are calling hundreds or thousands of people at the same time, and consequently you can expect a lot of people to get upset if you consistently send commands to the list address. You may leave the list at any time by sending a "SIGNOFF ITU-SG16" command to LISTSERV@MAILBAG.INTEL.COM. You can also tell LISTSERV how you want it to confirm the receipt of messages you send to the list. If you do not trust the system, send a "SET ITU-SG16 REPRO" command and LISTSERV will send you a copy of your own messages, so that you can see that the message was distributed and did not get damaged on the way. After a while you may find that this is getting annoying, especially if your mail program does not tell you that the message is from you when it informs you that new mail has arrived from ITU-SG16. If you send a "SET ITU-SG16 ACK NOREPRO" command, LISTSERV will mail you a short acknowledgement instead, which will look different in your mailbox directory. With most mail programs you will know immediately that this is an acknowledgement you can read later. Finally, you can turn off acknowledgements completely with "SET ITU-SG16 NOACK NOREPRO". Following instructions from the list owner, your subscription options have been set to "REPRO MIME" rather than the usual LISTSERV defaults. For more information about subscription options, send a "QUERY ITU-SG16" command to LISTSERV@MAILBAG.INTEL.COM. Contributions sent to this list are automatically archived. You can get a list of the available archive files by sending an "INDEX ITU-SG16" command to LISTSERV@MAILBAG.INTEL.COM. You can then order these files with a "GET ITU-SG16 LOGxxxx" command, or using LISTSERV's database search facilities. Send an "INFO DATABASE" command for more information on the latter. This list is available in digest form. If you wish to receive the digested version of the postings, just issue a SET ITU-SG16 DIGEST command. More information on LISTSERV commands can be found in the LISTSERV reference card, which you can retrieve by sending an "INFO REFCARD" command to LISTSERV@MAILBAG.INTEL.COM. ------------------------------------------------- Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 (230) Fax: 201-529-3516 -----Original Message----- From: Jonathan Rosenberg To: Hoefelmeyer, Ralph (MCI) Cc: Jerry Scharf ; iptel@lists.research.bell-labs.com Date: Wednesday, April 07, 1999 10:47 AM Subject: Re: is there a better list to ask H.323 questions of >I'm not on the list; I know of its existence but don't know how to join. >Perhaps someone who is on this list can send instructions? > >Thanks, >Jonathan R. > >> Hoefelmeyer, Ralph (MCI) wrote: >> >> It might help to tell everyone how to join the h323 implementers list >> ... >> >> -----Original Message----- >> From: Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com] >> Sent: Tuesday, April 06, 1999 3:32 PM >> To: Jerry Scharf >> Cc: iptel@lists.research.bell-labs.com >> Subject: Re: is there a better list to ask H.323 questions >> of >> >> This is not the right list. This list is for the iptel working >> group in >> IETF. Please use the h323 implementors list for h.323 questions. >> >> Thanks, >> Jonathan R. >> >> Jerry Scharf wrote: >> > >> > I have seen several questions on H.323 go by here. I have one >> on V2 and was >> > wondering if there is a better place to ask it or if here is >> the right >> > place. >> > >> > thanks, >> > jerry >> > >> > --------- >> > This message came from the IETF IPTEL Working Group Mailing >> List. >> >> -- >> Jonathan D. Rosenberg Lucent Technologies >> Member of Technical Staff 101 Crawfords Corner >> Rd. >> High Speed Networks Research Holmdel, NJ 07733 >> FAX: (732) 834-5379 Rm. 4C-526 >> EMAIL: jdrosen@bell-labs.com >> URL: http://www.cs.columbia.edu/~jdrosen >> >> --------- >> This message came from the IETF IPTEL Working Group Mailing List. > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen > >--------- >This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 8 12:03:55 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03991 for ; Thu, 8 Apr 1999 12:03:55 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3E00052B7; Thu, 8 Apr 1999 11:07:50 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8B70C52C2; Thu, 8 Apr 1999 11:07:49 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.3.32.19990407104333.00863690@pop.ozemail.com.au> X-Sender: dclowes@pop.ozemail.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 07 Apr 1999 10:43:33 +1000 To: "Jerry Scharf" From: Douglas Clowes Subject: Re: is there a better list to ask H.323 questions of Cc: In-Reply-To: <005d01be8074$3a7413c0$1ebd98cc@leda.vayu.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk If you want to join the H323 implementors mailing list, you can send mail to with the following command in the body of your email message: subscribe h323implementors or from another account: subscribe h323implementors At 14:27 1999-04-06 -0700, Jerry Scharf wrote: >I have seen several questions on H.323 go by here. I have one on V2 and was >wondering if there is a better place to ask it or if here is the right >place. > >thanks, >jerry > > >--------- >This message came from the IETF IPTEL Working Group Mailing List. > > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 8 12:30:03 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04165 for ; Thu, 8 Apr 1999 12:30:02 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A2E7152C2; Thu, 8 Apr 1999 12:23:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E8E4652C3; Thu, 8 Apr 1999 12:23:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.32.19990408121635.00881600@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 08 Apr 1999 12:16:38 -0400 To: IPTEL IETF Mailing List From: Matt Squire Subject: Re: Evaluation of Gateway Location proposals Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk I'm already sorry for the length of this message, but I had to respond... So here are my comments on your comparison. Not surprisingly, I have a different view on several important aspects. > >1. Introduction: >GLP is based on SCSP which is a generic link-state based protocol for >synchronizing the databases of a server group. GLP uses SCSP's message >formats and defines new fields specific for call routing and gateway >location. GLP uses SCSP's transport mechanism only for intra-domain >synchronization of LSs. For inter-domain communication, GLP proposes a >model that's based on BGP. At runtime, GLP defines a server group (the >set of LSs) which uses SCSP for synchronization and update >advertisement, i.e., GLP is a user of SCSP. > >TBGP is based on the BGP-4 and its multi-protocol extensions. It uses >BGP's transport mechanism for both inter-domain and intra-domain. TBGP >uses the same message formats defined by BGP, and benefits from the >attributes already defined >in BGP. In addition, TBGP defines new attributes to serve the specific >goals of call routing and gateway location. With regards to >implementation, BGP and TBGP are completely independent protocols. The >two protocols do not interfere with each other at runtime. A TBGP >speaker (or LS) does not have to be a BGP speaker. I've tried to make this clear before, but have evidently not succceeded in full. GLP is based on the combination of BGP4 and SCSP, not just SCSP. SCSP is just used to move the data between servers and replaces the BGP transport mechansism. Behavior above the synchronization/transport is based on BGP4 as catered to the needs of IP telephony. Both proposals have the same basic BGP architecture for an LS: |-----------------------------------------| | Local routes | | /\ | | | | | Decision | | Process | | /\ | | | | \/ | | in-routes out-routes | |-----------------------------------------| Both proposals have a decision process based on local policies. Both proposals have routing objects which carry phone numbers, next-hops, and all kinds of other attributes. Any attribute supported in one proposal can be made to work in the other proposal. Lets look at some of the basic aspects of BGP4 (I'm just paging through the BGP spec now, so this list is not intended to be complete). 1) Attributes 2) Transport/communications (ie open, keep-alive, update, notification) 3) FSMs 4) Update processing (decision process, update-send, route selection) I'll briefly discuss each aspect below before getting into more specific comments on your comparison later. 1) Attributes I fully recognize that the attribute set as listed in the GLP draft is incomplete. I've concentrated the initial draft on the potential new attributes for iptel that do not exist in BGP. Other BGP attributes will be forthcoming, The TBGP draft has taken the approach that everything in BGP is fair game for iptel, and has assumed that other BGP attributes will work for us just fine. Although I agree that other BGP attributes are fair game, I've taken the approach that we need to inspect every BGP attribute in terms of the problem we are trying to solve, and have not assumed that they will work as defined in BGP4. BGP4 attributes that exist have been defined for a reason, so we need to understand that reason, see how it applies to call-routing, and adjust the attribute appropriately. The 7 attributes defined in the BGP4 RFC are ORIGIN, NEXT_HOP, AS_PATH, MED, LOCAL_PREF, ATOMIC_AGGREGATE, and AGGREGATOR. Just running through some thoughts off the top of my head: A) NEXT_HOP. We've already had discussions how the concept of a BGP4 next-hop differs from an iptel next-hop. GLP is not a hop-by-hop routing protocol like BGP4, and this has impacts on many aspects of the protocol. B) AS_PATH. I've already agreed that we need something like the AS_PATH. But we've also had discussions on the list about whether we want to talk about the path that the advertisement took, the path that call-routing messages will take, or both. In BGP4, this attribute serves both purposes. Do we need one or both kinds of paths? How does this affect other aspects of the protocol (route preferences and selection, loop prevention, attribute propagation, etc.)? Our definition of what paths we need has an effect on other aspects of the protocol. C) MED. The multi-exit discard attribute is used in BGP4 to differentiate multiple links between neighboring ASs so that one link is 'preferred' over the other. But we don't route hop-by-hop, and that brings up some issues. How is MED used when an routing advertisement contains a next-hop that is not in the advertising domain? In other words, is MED a property of the advertisement path, or of the potential signalling path, or what exactly? In any case, I think its definition as in BGP4 would need some reworking. D) ATOMIC_AGGREGATE. Atomic aggregate is used to indicate that a "less-specific NLRI" has been chosen without selecting a 'more specific NLRI". GLP needs to have multi-attributed routing decisions, hence the concept of more/less specific is not dependent only on the addresses/NLRI. Also, we have yet to agree that what we want is address prefixes - if we choose something else, then things get even more confusing. In general, the NLRI-centric nature of BGP is too restrictive for our needs. So I have issues with 4 of the 7 well-defined attributes of BGP4 as they are defined and used within BGP4. The application of these attributes to GLP is not the same as it is in BGP4. We don't route hop-by-hop, we use mutli-valued routing decisions, etc. These differences affect many aspects of the protocol, including attribute definitions and processing. Every attribute needs to be re-examined in our context before we ok its use. I think we've taken different approaches to including other BGP attributes in our proposals. I wanted to understand the reasons behind every attribute, see how it applies to iptel, and then come up with an attribute that works for us. I think you've taken the approach that all attributes are ok and we can fix how they work later. In either case, I hope we agree that the BGP4 definitions of some of its attributes are not sufficient for iptel. We need something like them, but not exactly the same thing. Independent of the manner in which we choose to implement GLP, we need something like BGP, but not really BGP. We have to write an entirely new specification, we can't just reference BGP and say that we're redefining these attributes, this process, these algorithms, etc. In either implementation scenario, to say that GLP has something because BGP has it is a flawed approach until we've performed analysis of the feature and how it is effected by things like the fact that GLP isn't a hop-by-hop routing algorithm, that the GLP routing decision is based on things other than the NLRI, etc. In general, attribute decisions are independent of the differences between the proposals. I knew my proposal was lacking in attributes when I wrote it. I also think the TBGP proposal needs to redefine BGP4 attributes for our purposes and not to just reference their use in BGP4. We need a new protocol, not a reference to BGP4. I also believe that any attribute can work with either approach. 2) Transport/communications. Will address later. 3) FSMs. These basicly describe how one gets to the 'established' state, so these are really dependent on the transport/communications. 4) Update processing (decision process, update-send) 4a) Decision process. The BGP4 decision process is NLRI-centric. This must be changed to support multi-attributed routing decisions. We certainly want to maintain the structure of the decision process of BGP4, but it CAN NOT be the same decision process. BGP4s decision process must be made more general to support our requirements. The whole concept of what aggregation is and how it is performed is completely differnet for GLP than it is for BGP4. We have strings not bits, we have routes with attributes, we have black holes, we haven't agreed on prefixes as our destination representation, etc. Our decision process is not the same as the BGP4 decision process. 4b) Update-send. Again, we should keep the structure but we have to get rid of the NLRI-centric aspects. Things like jitter, advertisement frequency, etc., can be handled independently of the transport (UPDATE vs SCSP). Although this is not in the first draft of GLP, it would need to go in there. > >2. Reliability: >GLP runs on a reliable transport, e.g. TCP. In addition, GLP/SCSP uses >request/response transactions. Responses are not simple Acks. They are >long messages. This significant overhead is needed with intra-domain >link-state protocols to achieve transitive closure and to make sure that >all LSs in a domain have synced up following a routing change. However, >it is still a significant overhead that may be avoided. The >request/response mechanism does not add any benefit for inter-domain >GLP. > >TBGP, on the other hand, relies on TCP for reliability. It uses Update >messages only with no responses. This is sufficient. > Onto a discussion of transport. To me, this is the major functional difference between the proposals. To begin, I strongly disagree with your last statement. TCP provides transport reliability, it does NOT provide for reliable communications between applications. Look at the numerous protocols that the IETF has defined over TCP. The majority of them have recognized the difference between application reliability and transport reliability, and include things like acks, timeouts, retries, etc. Generally, BGP4 implementations don't use off-the-rack TCP/IP stacks. In order to achieve application reliability using just TCP, you really have to integrate your application with the TCP stack. BGP4 TCP/IP stacks are finely tuned for BGP, the OS is catered toward routing and routing protocols, etc. They don't use a standard socket type interface over TCP-IP because they would lose their reliability. TCP is not sufficient for application reliability unless you application is integrated with TCP. Whatever we do, I hope we recognize this fact and avoid the pitfall of forcing GLP developers to hack the TCP stack because we don't build application reliability. On the other hand, SCSP is sufficient. SCSP was designed to get information from A to B (and to C, D, ...). When used between just two servers, as you point out later, it has more than is needed. We could certainly build another reliable transport protocol by adding retries, timeouts, acks, etc., into the BGP4 transport. If restricted to point-to-point relationships, then it would have less overhead than SCSP. I just question why we would want to do this. The IETF has already defined SCSP as a general method of moving data between servers. Why not just use a defined protocol instead of defining JARAP (just another reliable application protocol). The overhead of SCSP's generality is not wasted if we use that generality within a domain. Using SCSP frees us from worrying about transport and allows us to concentrate on what data we need and how we should process it. These are really the novel iptel specific aspects. Moving data around has been done many times by many protocols in many ways. We don't have to build another one. The use of SCSP would replace the open, update, and keep-alive in BGP4. This decision is independent of the changes required of BGP4 above transport, which I discussed earlier. However, deciding how version negotiation and error notification work when using SCSP is yet TBD. These functions are provided in the BGP4 transport which would need some work in my suggested approach. >3. Inter-Domain Topologies: >Both protocols can support any general topology. > >4. Intra-Domain Topologies: >GLP can support any general topology. > >TBGP requires either a full mesh configuration or the use of route >reflectors or confederations. It is possible to configure each TBGP >speaker in a domain as a route reflector, and thereby to support any >general topology. > >Questions: >- What's so bad about route reflectors and confederations? >- What's the need for supporting a general topology? All that's required >is synchronizing the LSs of the same domain. It doesn't matter how they >interconnected, as long as there sufficient redundancy in the topology. > Some people evidently think route reflecting has some downsides. See draft-dube-route-reflection-harmful-00.txt "Route Reflection Considered Harmful". In general, I think unnecessary restrictions are, in a word, unnecessary. They limit deployment scenarios. BGP4s topological restrictions are a reflection of its choice of transport, not of the routing processes above them. We are designing a new protocol. We need to leverage the experience of BGP, both good and bad. That means we don't have to make the same mistakes. In hindsight, the original BGP restriction on meshes was bad thing. There have been numerous proposals over the years to fix it (route reflectors, route servers, confederations, clusters, etc). However, all of these proposals have had to live within the confines of interoperability with existing BGP. We don't have to be interoperable with existing BGP implementations. We have the freedom to fix this problem in a more general way without interoperability concerns. GLP needs to get information from every server to every other server within the domain. That is the problem we have to solve. If we recognize that this is the issue, and that we don't have to limit ourselves to solutions that are compatible with BGP1 through BGP4, then we can do better than what was done in BGP. Let's step out of the box and look at the problem without the BGP interop constraints. >5. Loop Avoidance: >5.1 Intra-domain Loop Detection: >5.2 Inter domain Loop Detection: >6. Hold-down Timers and Route Flaps: >7. Policy Enforcement: >8. Coping with Aggregation Side Effects: > These are all attribute issues that can be addressed by either approach. TBGP does need to define new formats, in my approach we would. With either approach, we also need to re-examine the exact definition of the attributes and modify them as appropriate. >9. Addressing Formats: >GLP proposes to advertise E.164 ranges. During the meeting, it has been >agreed that E.164 prefixes are more space-efficient. > >The multi-protocol extensions for BGP-4 (RFC 2283) have already defined >fields for advertising E.164 prefixes in BGP messages. These extensions >are used by TBGP. Although we agreed that prefixes are more space efficient, I don't think we agreed that prefixes are the way to go. I think it was Scott that brought up the point of a company having the same number in many area codes. Although I have nothing against a decision for prefixes, I just don't think it was agreed upon. > >10. Leveraging Existing Attributes: >Most of BGP-4's fields and attributes can be used by TBGP, as evident >from the above discussion. Still there are some attributes which are of >no use to TBGP. for example the layer 3 NEXT_HOP attribute. > >GLP, on the other hand, will have to redefine several of BGP's existing >attributes within the SCSP's message formats. Consider for example, the >policy attributes and aggregation attributes discussed above. Also SCSP >defines several mandatory fields which are redundant or of no use for >GLP. E.g., the Sender ID and Recvr ID are not needed in every Update >messages. The peers already recognize each other. Also the Cache Key >field is not needed since the tables will be indexed by the E.164 >prefixes. As I mention above, there are subtle points with several attributes that arise because call routing differs from ip routing. Yes, TBGP can use the same attribute format. I don't consider this particular important. We still need to look at every attribute and redefine it as necessary. Formats are the least of our obstacles. SCSP fields are necessary for general database sync. In a peer-to-peer inter-domain link, you mention some that are redundant. In the intra-domain case where there are multiple servers, these fields are required. The cache key is a very useful and compact identifier for a data object. One can issue updates or withdraws on the data object without having to understand the data. This means that one can withdraw a route by performing a lookup on the cache key instead of an e164 address. This allows for a more efficient lookup for changing an existing data object. Yes, its redundant, but for a reason. > >TBGP can define its own message formats and remove any useless fields >from the current BGP messages, because BGP and TBGP are separate >protocols. On the other hand, GLP can not remove useless fields from >SCSP messages, because it is just a another user of SCSP. The other view is that TBGP MUST define its own message formats and remove useless fields from BGP messages. With SCSP we only define the data, not the protocol. To me, that means more work with the TBGP approach. I certainly agree that we could a protocol with less overhead than SCSP. See my previous arguments on why the BGP transport is insufficient for applications. > >11. Protocol Phases: >GLP/SCSP has three phases: Hello, Cache Alignment, and Update. > >TBGP/BGP consists of two phases only: Hello and Update. It uses the same >mechanisms of the update phase for aligning the call routing tables when >a new connection between wo peers is established. > >12. Security Consideration: >Both protocols define optional fields to include authentication data. >Both of them permit the use of different authentication mechanisms, and >both provide sufficient space to include the 128-bit MD5 digests. > >However, TBGP messages can't carry authentication data larger than 128 >bits, while SCSP messages can. > >13. Routing Experience: >This is not a feature of the protocol, but I think it is worth repeating >that SCSP was not designed for, and was never used for, inter-domain >routing. > >On the other hand, BGP has been specifically designed for inter-domain >routing. It (a) is known to work, (b) is widely deployed in the >Internet, (c) has an extensive operational experience, and (d) known to >scale. First, SCSP is not being proposed as an inter-domain routing protocol. It is being proposed as a method of moving data between servers. The data that it is being proposed to move is data that will be used for routing. So although you're right in that SCSP isn't a routing protocol of any sorts, I'm not proposing that it be made one. I want to separate the routing process from the process of moving the data around, so that this wg can build the routing process and algorithms. SCSP frees us from worrying about moving the data around. To me, this is a good thing. Second, you're absolutely right about BGP. But TBGP is not BGP. Its a new protocol. It has different attributes, different aggregation algorithms, different route selection, different routing decisions, etc. I consider it flawed logic to assume that a property of BGP translates into the same property in TBGP. We have no operational experience with TBGP, for example. Yes BGP works. But that's because of the experience developed over the years in its aggregation algorithms, routing decisions, experience with internet routing deployment and address distribution, etc. The IETF does not have years of experience with deployed call routing protocols. We don't have experience with the aggregation algorithms for the aggregation of strings and multi-valued routing objects. We don't have that experience with multi-valued routing decisions and processes. We can't rely on our handing out addresses in certain ways to help with aggregation. Etc, etc, etc. This is a new problem. We need to leverage our experience with BGP, but not be restricted by it, or to just assume that what is good for ip routing is good for call routing. In my opinion, there are really two major differences between the proposals. The first is ideological. I took the approach that we have to re-examine every attribute in BGP before accepting it, you took the approach where we accept it and re-examine it later. I think we both agree that this is a new protocol that requires a new spec, and that cannot just reference BGP4 to describe its behavior. We each want to leverage BGPs attributes. TBGP has an easier job cause it leverages the formats as well as the function, where with my proposal we have to redefine formats. The second aspect is the transport issue. I am in strong disagreement with the assumption that TCP provides application reliability. Hence, as an application protocol, BGP4's reliability measures are not sufficient. I proposed SCSP to give us this reliabilty and to free us from worring about transport issues such as retries, timeouts, etc. SCSP also has beneficial side effects as an intra-domain distribution system. If the wg feels that we'd rather design our own reliable application protocol, then I could live with that. I think we'd be wasting effort that could be better applied to other iptel problems, but these things happen. Counting on TCP for application reliability is just a bad idea. - Matt --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 8 21:05:46 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09058 for ; Thu, 8 Apr 1999 21:05:46 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DB46452C3; Thu, 8 Apr 1999 19:19:32 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 22F7352BB; Thu, 8 Apr 1999 19:19:28 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <1B08859602C8D211B66F0000C0769CFA0A487E@njc240po03.ho.att.com> From: "Ash, Gerald R (Jerry), NNAD" To: "'diff-serv@baynetworks.com'" , "'iptel@lists.research.bell-labs.com'" , "'pint@lists.research.bell-labs.com'" Cc: "Ash, Gerald R (Jerry), NNAD" Subject: Invitation Date: Thu, 8 Apr 1999 19:14:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hello, My name is Jerry Ash and I'm the Rapporteur of ITU-T Study Group 2, Question 2 on routing. At the 12/98 IETF meeting in Orlando, I presented some on-going ITU-T work entitled "E.MM -- Routing of Multimedia Connections when Interworking with TDM-, ATM-, and IP-Based Networks" (). As highlighted in our discussions, routing models in TDM-, ATM- and IP-based networks have evolved differently. However, as TDM-based PSTNs interwork more with IP and ATM networks, and perhaps evolve to incorporate IP/ATM technology themselves, we are interested in exploring the evolution of routing standards in such cases. As outlined in the liaison, we welcome the participation of the IETF in these on-going routing topics and recommendations. As a follow-up to that invitation, the E.MM Draft Recommendation (see abstract below) and other routing topics will next be discussed at the May 4-14, 1999 ITU-T Study Group 2 meeting in Geneva. Question 2 on Routing meets on 5/6, 5/7, and 5/10, and we invite contributions to and participation in these meetings and recommendations. In that regard, I would be happy to supply more detailed information on meeting logistics and/or a Word-version copy of the currently proposed E.MM Draft Recommendation. Thanks very much, Regards, Jerry Ash ------------------------------------------------------------ Gerald R. (Jerry) Ash Rapporteur, ITU-T Study Group 2, Question 2 (Routing) AT&T Manager, Routing Evolution Network Architecture & Development Room MT E3-3C37 200 Laurel Avenue Middletown, NJ 07748 USA Telephone 732-420-4578 Fax 732-368-6687 Email gash@att.com ------------------------------------------------------------ TITLE: E.MM - Routing of Multimedia Connections when Interworking with TDM-, ATM-, and IP-Based Networks ABSTRACT There are many network operators who have implemented multiple networks using different protocols, which include Public Switched Telephone Networks (PSTNs) which use Time Division Multiplexing (TDM) technology, Asynchronous Transfer Mode (ATM) technology, and/or Internet Protocol (IP) technology. The very rapid growth of data services driven primarily by multimedia internet services has led in turn to the rapid growth of ATM and IP technology being implemented and/or planned for PSTNs. Also there is interest in carrying traditional PSTN voice services over ATM- and IP-based networks, leading to the convergence in many instances of voice and data services onto a common network. However there is also a growing need to address the interworking of voice and data services over TDM-, ATM,- and IP-based PSTN networks, as all these network types will continue to exist and grow. This Recommendation addresses the routing aspects of interworking between these networks, and includes considerations of a) numbering, b) path selection, c) quality-of-service (QoS) resource management, and d) signaling and information exchange messaging. The most effective routing functionalities employed within each network type are recommended for application across network types, to enable and ease interworking and include the following: a) the E.164/NSAP based numbering/addressing method applied successfully in TDM- and ATM-based networks, b) the automatic generation of routing tables based on network topology and status applied successfully in TDM-, ATM-, and IP-based networks, c) the dynamic path selection methods applied successfully in TDM-based networks, d) the routing table design information exchange messaging applied successfully in TDM-based networks, e) the QoS resource management methods applied successfully in TDM-based networks, f) the automatic update and synchronization of topology database methods applied successfully in ATM- and IP-based networks, g) the topology update information exchange messaging methods applied successfully in ATM- and IP-based networks, and h) the connection/bandwidth-allocation control signaling methods applied successfully in ATM-based networks. The latter includes originating switch controlled (source) routing, specification of via and destination switches in a designated-transit-list/explicit-route parameter in the setup message, and return of control to the originating switch with a crankback/bandwidth-not-available parameter in the release message. Adapting these capabilities, or their equivalents, for use within each network type and for interworking between network types builds on these well studied, documented, deployed, and proven methods. It also increases the likelihood of backward compatibility to existing capabilities as new interworking standards are adopted and implemented. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 9 08:06:52 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01734 for ; Fri, 9 Apr 1999 08:06:52 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1E73E52B7; Thu, 8 Apr 1999 22:55:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8B9AD52C1; Thu, 8 Apr 1999 22:55:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199904090250.TAA04986@mailman.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 08 Apr 1999 22:44:34 -0400 To: "Ash, Gerald R (Jerry), NNAD" , "'iptel@lists.research.bell-labs.com'" From: Chip Sharp Subject: Re: Invitation In-Reply-To: <1B08859602C8D211B66F0000C0769CFA0A487E@njc240po03.ho.att.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Thanks for the invitation. I have a couple of questions below: At 07:14 PM 4/8/99 -0400, Ash, Gerald R (Jerry), NNAD wrote: >Hello, ...snip... >The most effective routing functionalities employed within each network type >are recommended for application across network types, to enable and ease >interworking and include the following: a) the E.164/NSAP based >numbering/addressing method applied successfully in TDM- and ATM-based >networks, b) the automatic generation of routing tables based on network >topology and status applied successfully in TDM-, ATM-, and IP-based >networks, c) the dynamic path selection methods applied successfully in >TDM-based networks, d) the routing table design information exchange >messaging applied successfully in TDM-based networks, e) the QoS resource >management methods applied successfully in TDM-based networks, f) the >automatic update and synchronization of topology database methods applied >successfully in ATM- and IP-based networks, g) the topology update >information exchange messaging methods applied successfully in ATM- and >IP-based networks, and h) the connection/bandwidth-allocation control >signaling methods applied successfully in ATM-based networks. The latter >includes originating switch controlled (source) routing, specification of >via and destination switches in a designated-transit-list/explicit-route >parameter in the setup message, and return of control to the originating >switch with a crankback/bandwidth-not-available parameter in the release >message. Adapting these capabilities, or their equivalents, for use within >each network type and for interworking between network types builds on these >well studied, documented, deployed, and proven methods. It also increases >the likelihood of backward compatibility to existing capabilities as new >interworking standards are adopted and implemented. ...snip... For b), c) and d), could you point me to the standards that describe the protocols and algorithms used for these capabilities in the TDM network? For example, what protocol is used for routing table design information exchange messaging between switches? This way we can read up on them before the meeting. Thanks, Chip -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. -------------------------------------------------- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 9 09:06:24 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02232 for ; Fri, 9 Apr 1999 09:06:23 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id F252652BB; Fri, 9 Apr 1999 09:01:17 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5AF2752BF; Fri, 9 Apr 1999 09:01:16 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <1B08859602C8D211B66F0000C0769CFA0A4886@njc240po03.ho.att.com> From: "Ash, Gerald R (Jerry), NNAD" To: "'Chip Sharp'" Cc: "Ash, Gerald R (Jerry), NNAD" , "'iptel@lists.research.bell-labs.com'" Subject: RE: Invitation Date: Fri, 9 Apr 1999 08:58:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Chip, As discussed in the E.MM draft, ITU-T Recommendations E.170, E.177, and E.DYN (draft) address items b), c), and d). E.MM seeks standardization of effective routing functionalities for interworking, including information exchange, that derive from standards/practice across TDM/ATM/IP network types. The draft contains more information and references. Thanks, Jerry Ash > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@cisco.com] > Sent: Thursday, April 08, 1999 10:45 PM > To: Ash, Gerald R (Jerry), NNAD; 'iptel@lists.research.bell-labs.com' > Subject: Re: Invitation > > Thanks for the invitation. I have a couple of questions below: > > At 07:14 PM 4/8/99 -0400, Ash, Gerald R (Jerry), NNAD wrote: > >Hello, > ...snip... > >The most effective routing functionalities employed within each network > type > >are recommended for application across network types, to enable and ease > >interworking and include the following: a) the E.164/NSAP based > >numbering/addressing method applied successfully in TDM- and ATM-based > >networks, b) the automatic generation of routing tables based on network > >topology and status applied successfully in TDM-, ATM-, and IP-based > >networks, c) the dynamic path selection methods applied successfully in > >TDM-based networks, d) the routing table design information exchange > >messaging applied successfully in TDM-based networks, e) the QoS resource > >management methods applied successfully in TDM-based networks, f) the > >automatic update and synchronization of topology database methods applied > >successfully in ATM- and IP-based networks, g) the topology update > >information exchange messaging methods applied successfully in ATM- and > >IP-based networks, and h) the connection/bandwidth-allocation control > >signaling methods applied successfully in ATM-based networks. The latter > >includes originating switch controlled (source) routing, specification of > >via and destination switches in a designated-transit-list/explicit-route > >parameter in the setup message, and return of control to the originating > >switch with a crankback/bandwidth-not-available parameter in the release > >message. Adapting these capabilities, or their equivalents, for use > within > >each network type and for interworking between network types builds on > these > >well studied, documented, deployed, and proven methods. It also > increases > >the likelihood of backward compatibility to existing capabilities as new > >interworking standards are adopted and implemented. > ...snip... > > For b), c) and d), could you point me to the standards that describe the > protocols and algorithms used for these capabilities in the TDM network? > For example, what protocol is used for routing table design information > exchange messaging between switches? This way we can read up on them > before the meeting. > > > Thanks, > Chip > -------------------------------------------------- > Chip Sharp voice: +1 (919) 851-2085 > Cisco Systems Consulting Eng. - Telco > Reality - Love it or Leave it. > -------------------------------------------------- > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 9 10:58:22 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03229 for ; Fri, 9 Apr 1999 10:58:21 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 280F152B7; Fri, 9 Apr 1999 10:53:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7FA0F52C1; Fri, 9 Apr 1999 10:53:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: Rahul_Chopra@3com.com X-Lotus-FromDomain: 3COM To: Chip Sharp Cc: "Ash, Gerald R (Jerry), NNAD" , "'iptel@lists.research.bell-labs.com'" Message-ID: <8825674E.0051A6CB.00@hqoutbound.ops.3com.com> Date: Fri, 9 Apr 1999 09:47:54 -0500 Subject: Re: Invitation Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Ash, Chip: I would appreciate a pointer to what CS pointed too. Thanks. Rahul Chopra Chip Sharp on 04/08/99 09:44:34 PM To: "Ash, Gerald R , "'iptel @lists.research.bell-labs.com'" cc: (Rahul Chopra/MW/US/3Com) Subject: Re: Invitation Thanks for the invitation. I have a couple of questions below: At 07:14 PM 4/8/99 -0400, Ash, Gerald R (Jerry), NNAD wrote: >Hello, ...snip... >The most effective routing functionalities employed within each network type >are recommended for application across network types, to enable and ease >interworking and include the following: a) the E.164/NSAP based >numbering/addressing method applied successfully in TDM- and ATM-based >networks, b) the automatic generation of routing tables based on network >topology and status applied successfully in TDM-, ATM-, and IP-based >networks, c) the dynamic path selection methods applied successfully in >TDM-based networks, d) the routing table design information exchange >messaging applied successfully in TDM-based networks, e) the QoS resource >management methods applied successfully in TDM-based networks, f) the >automatic update and synchronization of topology database methods applied >successfully in ATM- and IP-based networks, g) the topology update >information exchange messaging methods applied successfully in ATM- and >IP-based networks, and h) the connection/bandwidth-allocation control >signaling methods applied successfully in ATM-based networks. The latter >includes originating switch controlled (source) routing, specification of >via and destination switches in a designated-transit-list/explicit-route >parameter in the setup message, and return of control to the originating >switch with a crankback/bandwidth-not-available parameter in the release >message. Adapting these capabilities, or their equivalents, for use within >each network type and for interworking between network types builds on these >well studied, documented, deployed, and proven methods. It also increases >the likelihood of backward compatibility to existing capabilities as new >interworking standards are adopted and implemented. ...snip... For b), c) and d), could you point me to the standards that describe the protocols and algorithms used for these capabilities in the TDM network? For example, what protocol is used for routing table design information exchange messaging between switches? This way we can read up on them before the meeting. Thanks, Chip -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. -------------------------------------------------- --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat Apr 10 12:56:03 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21944 for ; Sat, 10 Apr 1999 12:56:03 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DF6EE52BB; Sat, 10 Apr 1999 11:57:25 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 481EB52C1; Sat, 10 Apr 1999 11:57:24 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Internal-ID: 370E72C200003FDD Message-ID: <370E72C200003FDD@mailnew.fibertel.com.ar> (added by mailnew.fibertel.com.ar) Date: Sat, 10 Apr 1999 12:56:47 -0300 From: Finanzas Subject: Seminarios Aplicativos de CÂlculo Financiero. Reply-To: finanzas.mail@poboxes.com To: iptel@lists.research.bell-labs.com X-Mailer: dbMail v1.3b1 by Mach5 Software. Please report spamming to dbspam@mach5.com. Content-Transfer-Encoding: Quoted-Printable MIME-Version: 1.0 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: Quoted-Printable AT.: iptel@lists.research.bell-labs.com TO:=20 GERENCIA DE ADMINISTRACION Y FINANZAS GERENCIA GENERAL GERENCIA COMERCIAL GERENCIA DE COMPRAS ATENCION: Seminarios Aplicativos de C=E1lculo Financiero. OBJETO: El seminario apunta a resolver pr=E1cticamente los problemas de c=E1lculo financiero que se le presentan a una empresa mediante el uso de= la m=E1s poderosa herramienta de software de c=E1lculo financiero del mercado arge= ntino. (Incluye en la matricula la provisi=F3n de la herramienta mencionada). DICTADOS POR: Profesionales en Ciencias Econ=F3micas con Expertise en la materia. LUGAR DE REALIZACION: Capital Federal. Interior ver Capacitaci=F3n a Distancia. MATERIAL DIDACTICO QUE SE ENTREGA: 25 ejercicios con su soluci=F3n, 1 Software estructurado con su correspondiente manual de uso (100 p=E1g.) y= el Certificado del Seminario. DURACION: 4 hs., con servicio de cafeter=EDa. MATRICULA: $ 100,-- + IVA (Incluye el software). FECHAS Y HORARIOS DISPONIBLES: Ma=F1ana: 13-04 15-04 16-04 20-04 22-04 23-04 27-04 29-04 30-04 Tarde: 15-04 16-04 22-04 23-04 29-04 30-04 Los horarios son: 9 a 13 hs. o 15 a 19 hs. TOPICOS DEL SEMINARIO APLICATIVO: - C=E1lculos Generales. - Unificaci=F3n de vencimientos. - Diversificaci=F3n de vencimientos. - Equivalencias de Tasas de Inter=E9s. - Aritm=E9tica de Fechas. - Rentas e Imposiciones. - Sistemas de Amortizaci=F3n. - Planes Financieros. - Carteras de Acciones. - T=EDtulos P=FAblicos. - D=EDas Promedio de Pago. - Descuento de cheques y facturas. CUPOS LIMITADOS: M=E1ximo 4 asistentes por seminario, confirme ya su asistencia por e-mail a: finanzas.mail@poboxes.com A los interesados rogamos enviar los datos siguientes y nos pondremos en contacto. NOMBRE Y APELLIDO: EMPRESA: CARGO: TELEFONO: ---------------------------------------------------- CAPACITACION A DISTANCIA: Si Ud. no tiene tiempo para asistir al seminario o es del interior y no puede viajar a Capital, puede solicitar nuestro "Pack de Capacitaci=F3n a Distancia", que le permitir=E1, en poco tiempo, una eficaz utilizaci=F3n = de nuestro software de c=E1lculo financiero. PACK DE AUTOAPRENDIZAJE: COSTO: $ 100,-- + $ 15,-- (gastos de env=EDo contrareembolso) + IVA. CONTIENE:=20 - Software de C=E1lculo Financiero (1 disquete 3,5" con el software para instalar en cualquier PC). - Manual de uso con m=FAltiples ejercicios. - 25 ejercicios resueltos del seminario (planteos y soluciones). - Gu=EDa oral de instalaci=F3n y de utilizaci=F3n de cada una de las herramientas. - Certificado del seminario. A los interesados en adquirir el pack, rogamos indicar: NOMBRE Y APELLIDO: DIRECCION DE ENVIO: LOCALIDAD: PROVINCIA: CP: PAIS: CANTIDAD SOLICITADA: EMPRESA: CARGO: DIRECCION DE FACTURACION: CUIT: COND. IVA: TELEFONOS: OBS.: Cordialmente, Lic. Andrea Alluvi Depto. Marketing Si este mensaje no es de su inter=E9s env=EDe un e-mail con el asunto: BAJAR iptel@lists.research.bell-labs.com a finanzas.mail@poboxes.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 14 22:30:46 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12330 for ; Wed, 14 Apr 1999 22:30:46 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2189252C5; Wed, 14 Apr 1999 22:25:30 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3983952B7; Wed, 14 Apr 1999 22:25:26 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199904150220.TAA18108@mailman.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 14 Apr 1999 22:20:11 -0400 To: iptel@lists.research.bell-labs.com From: Chip Sharp Subject: CPL Proposed to ITU SG16 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk FYI, At the last US State Dept ITAC-D meeting, a contribution was brought in submitting CPL to ITU SG16 for consideration. I believe the drafts were attached. Unfortunately I didn't get a copy and I had to leave before the discussion was ended so I don't know how it turned out. Thus I believe it might be an item of discussion in Santiago. Chip -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. -------------------------------------------------- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 14 22:37:43 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13059 for ; Wed, 14 Apr 1999 22:37:43 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B625A52C1; Wed, 14 Apr 1999 22:25:26 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D9F6B52C3; Wed, 14 Apr 1999 22:25:24 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <009401be86e7$ca5b48e0$741f0e0a@telkom.go.id> From: "Henri Setiawan" To: "IPTEL IETF Mailing List" References: <3.0.32.19990324082921.0079a390@bl-mail1.corpeast.baynetworks.com> <36F9AF74.F360B23A@dnrc.bell-labs.com> Subject: Measurement and testing parameter Date: Thu, 15 Apr 1999 09:29:29 +0700 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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dear folks, May be you have been evaluating several vendors solution on VoIP. Is there anyone have been testing the equipments ? Can you share about the measurement methods and testing parameter to classify the performance of the equipment ? Also, if you know the measurement equipment for testing please let me know. Other case, please explain to me how can we measure MOS ? Thank you Henri Setiawan R&D of PT Telkom Indonesia --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 14 22:46:34 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13234 for ; Wed, 14 Apr 1999 22:46:34 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5E9A752C7; Wed, 14 Apr 1999 22:31:24 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8530152CB; Wed, 14 Apr 1999 22:31:23 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <00c001be86e8$8478da80$741f0e0a@telkom.go.id> From: "Henri Setiawan" To: Cc: References: <370A240F.55A0A2F3@agcs.com> Subject: H.323 testing Date: Thu, 15 Apr 1999 09:34:39 +0700 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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dear folks, We plan to test several VoIP products for H.323 compliment. Is there anyone have done this test ? Please inform me regarding the methods, testing parameters and equipment to test. Thanks Henri S R&D of PT Telkom Indonesia. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 15 13:56:23 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09919 for ; Thu, 15 Apr 1999 13:56:23 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 213AC52C8; Thu, 15 Apr 1999 13:51:17 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5E06252CB; Thu, 15 Apr 1999 13:51:16 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990415175021.10504.rocketmail@web110.yahoomail.com> Date: Thu, 15 Apr 1999 10:50:21 -0700 (PDT) From: Tom Gray Subject: RE: Measurement and testing parameter To: "Hoefelmeyer, Ralph (MCI)" , "'Henri Setiawan'" , IPTEL IETF Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --- "Hoefelmeyer, Ralph (MCI)" wrote: > > What does "YM_M4I5S3S_4" stand for? > YM_M4I5S3S_5 is Mean Opinion Score. It is a metric which denotes the perceived quality of the voice connection. It has five categories going from Excellent to Unacceptable. This is an important aspect of YM_M4I5S3S_6 telephony since it will assess the capability of various YM_M4I5S3S_7 to meet human expectations. It will also be a measure of YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9 protocol. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 15 14:05:33 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10294 for ; Thu, 15 Apr 1999 14:05:32 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id CE01C52D0; Thu, 15 Apr 1999 13:55:24 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CBE1152CE; Thu, 15 Apr 1999 13:55:23 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "Hoefelmeyer, Ralph (MCI)" To: "'Tom Gray'" , "'Henri Setiawan'" , IPTEL IETF Mailing List Subject: RE: Measurement and testing parameter Date: Thu, 15 Apr 1999 17:53:33 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE8768.E183226E" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk 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_01BE8768.E183226E Content-Type: text/plain Tom, Thanks. So this MOS would be primarily dependent on the codex, assuming the transport layers delivers all of the packets? Please clarify your message, as you can see below it came through garbled. Cordially, Ralph > -----Original Message----- > From: Tom Gray [SMTP:tom_gray_intp@yahoo.com] > Sent: Thursday, April 15, 1999 11:50 AM > To: Hoefelmeyer, Ralph (MCI); 'Henri Setiawan'; IPTEL IETF Mailing List > Subject: RE: Measurement and testing parameter > > > > --- "Hoefelmeyer, Ralph (MCI)" > wrote: > > > > > What does "YM_M4I5S3S_4" stand for? > > > > > YM_M4I5S3S_5 is Mean Opinion Score. It is a metric which denotes the > perceived quality of the voice connection. It has five categories going > from Excellent to Unacceptable. This is an important aspect of > YM_M4I5S3S_6 telephony since it will assess the capability of various > YM_M4I5S3S_7 to meet human expectations. It will also be a measure of > YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9 protocol. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com ------_=_NextPart_001_01BE8768.E183226E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Measurement and testing parameter

Tom,
Thanks.  So this MOS = would be primarily dependent on the codex, assuming the transport = layers delivers all of the packets?

Please clarify your message, = as you can see below it came through garbled.
Cordially,
Ralph

    -----Original Message-----
    From:   Tom Gray [SMTP:tom_gray_intp@yahoo.com]
    Sent:   Thursday, April 15, 1999 11:50 AM
    To:     Hoefelmeyer, Ralph (MCI); 'Henri Setiawan'; IPTEL IETF = Mailing List
    Subject:       = RE: Measurement and testing = parameter



    --- "Hoefelmeyer, Ralph = (MCI)" <Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com>
    wrote:

    >
    > What does = "YM_M4I5S3S_4" stand for?
    >


    YM_M4I5S3S_5 is Mean Opinion = Score. It is a metric which denotes the
    perceived quality of the voice = connection. It has five categories going
    from Excellent to Unacceptable. = This is an important aspect of
    YM_M4I5S3S_6 telephony since it = will assess the capability of various
    YM_M4I5S3S_7 to meet human = expectations. It will also be a measure of
    YM_M4I5S3S_8 beyond compliance = to the YM_M4I5S3S_9 protocol.


    _________________________________________________________
    Do You Yahoo!?
    Get your free @yahoo.com = address at http://mail.yahoo.com

------_=_NextPart_001_01BE8768.E183226E-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 15 14:22:23 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10740 for ; Thu, 15 Apr 1999 14:22:23 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2FE3E52C6; Thu, 15 Apr 1999 14:17:14 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6942A52CB; Thu, 15 Apr 1999 14:17:13 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37162DBF.D04ED3B9@enfm.utcc.utoronto.ca> Date: Thu, 15 Apr 1999 14:19:43 -0400 From: Sam Mokbel Organization: ONet Networking X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: "Hoefelmeyer, Ralph (MCI)" Cc: "'Tom Gray'" , "'Henri Setiawan'" , IPTEL IETF Mailing List Subject: Re: Measurement and testing parameter References: Content-Type: multipart/alternative; boundary="------------FBA654F9D5477BA1CB4F8388" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --------------FBA654F9D5477BA1CB4F8388 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ralph, Even if the transport layer delivers all packets that does not necessarily mean that it is not having an effect on the MOS. The delay and delay variations of the packet arrival time can have a significant effect on MOS. Hoefelmeyer, Ralph (MCI) wrote: > > > Tom, > Thanks. So this MOS would be primarily dependent on the codex, > assuming the transport layers delivers all of the packets? > > Please clarify your message, as you can see below it came through > garbled. > Cordially, > Ralph > > -----Original Message----- > From: Tom Gray [SMTP:tom_gray_intp@yahoo.com] > Sent: Thursday, April 15, 1999 11:50 AM > To: Hoefelmeyer, Ralph (MCI); 'Henri Setiawan'; IPTEL IETF > Mailing List > Subject: RE: Measurement and testing parameter > > > --- "Hoefelmeyer, Ralph (MCI)" > > wrote: > > > > > What does "YM_M4I5S3S_4" stand for? > > > > YM_M4I5S3S_5 is Mean Opinion Score. It is a metric which denotes > the > perceived quality of the voice connection. It has five categories > going > from Excellent to Unacceptable. This is an important aspect of > YM_M4I5S3S_6 telephony since it will assess the capability of > various > YM_M4I5S3S_7 to meet human expectations. It will also be a > measure of > YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9 protocol. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > -- Sam Mokbel University of Toronto External Networking and Facilities Management 4 Bancroft Ave., Room 101 Toronto, Ontario M5S 1C1 Tel: (416) 978-3328 Fax: (416) 978-6620 --------------FBA654F9D5477BA1CB4F8388 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ralph,

Even if the transport layer delivers all packets that does not necessarily mean that it is not having an effect on the MOS. The delay and delay variations of the packet arrival time can have a significant effect on MOS.

Hoefelmeyer, Ralph (MCI) wrote:

 

Tom,
Thanks.  So this MOS would be primarily dependent on the codex, assuming the transport layers delivers all of the packets?

Please clarify your message, as you can see below it came through garbled.
Cordially,
Ralph

    -----Original Message-----
    From:   Tom Gray [SMTP:tom_gray_intp@yahoo.com]
    Sent:   Thursday, April 15, 1999 11:50 AM
    To:     Hoefelmeyer, Ralph (MCI); 'Henri Setiawan'; IPTEL IETF Mailing List
    Subject:        RE: Measurement and testing parameter
     

    --- "Hoefelmeyer, Ralph (MCI)" <Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com>
    wrote:

    >
    > What does "YM_M4I5S3S_4" stand for?
    >

    YM_M4I5S3S_5 is Mean Opinion Score. It is a metric which denotes the
    perceived quality of the voice connection. It has five categories going
    from Excellent to Unacceptable. This is an important aspect of
    YM_M4I5S3S_6 telephony since it will assess the capability of various
    YM_M4I5S3S_7 to meet human expectations. It will also be a measure of
    YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9 protocol.

    _________________________________________________________
    Do You Yahoo!?
    Get your free @yahoo.com address at http://mail.yahoo.com

--
Sam Mokbel
University of Toronto
External Networking and Facilities Management
4 Bancroft Ave., Room 101
Toronto, Ontario M5S 1C1
Tel: (416) 978-3328 Fax: (416) 978-6620
  --------------FBA654F9D5477BA1CB4F8388-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 15 14:54:08 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11704 for ; Thu, 15 Apr 1999 14:54:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5F3A752CA; Thu, 15 Apr 1999 13:35:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B948252CB; Thu, 15 Apr 1999 13:35:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "Hoefelmeyer, Ralph (MCI)" To: "'Henri Setiawan'" , IPTEL IETF Mailing List Subject: RE: Measurement and testing parameter Date: Thu, 15 Apr 1999 17:34:15 -0000 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE8766.2F750166" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk 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_01BE8766.2F750166 Content-Type: text/plain Henri, The predominant testing method is to determine interoperability between differing vendors equipment. Simply hook up the devices to a LAN, and across a small WAN, set up the IP addresses correctly, and start calling. Measure call setup times, time to process an address translation, time to set up the RTP channel, etc. One uses LAN analyzers to measure the various latencies, and to view the protocol exchanges. Hewlett-Packard has an H.323 analyzer in Beta now. I do not know of a SIP analyzer yet. This is for an IP centric network implementation. For testing between a circuit switched network and a packet based network, I do not know what one uses to watch telephony switch message exchanges. The problem in the SIP world is that there are lots of prototypes and no product on the market that I can buy today. If someone knows differently, please let me know ASAP. There are some H.323 devices, but even here, there is not much for production devices. Erricson has an H.323 Gatekeeper in use in Norway, but it is an NT box. There are other H.323 gatekeepers out there, but they have all of the problems one expects with H.323/RAS etc. (elemedia, RadVision, Cisco). Some are simply software elements one places on a server, others are proprietary hardware and software solutions. You should keep a watch out on the URL http://www.cs.columbia.edu/~hgs/sip/bakeoff.html for the results of the SIP Bake-off, an interoperability event held last week in New York City. What does "MOS" stand for? Cordially, Ralph Ralph S. Hoefelmeyer MCI WorldCom Engineer > -----Original Message----- > From: Henri Setiawan [SMTP:henry@risti.telkom.co.id] > Sent: Wednesday, April 14, 1999 8:29 PM > To: IPTEL IETF Mailing List > Subject: Measurement and testing parameter > > Dear folks, > > May be you have been evaluating several vendors solution on VoIP. Is there > anyone have been testing the equipments ? Can you share about the > measurement methods and testing parameter to classify the performance of > the > equipment ? Also, if you know the measurement equipment for testing please > let me know. > > Other case, please explain to me how can we measure MOS ? > > Thank you > > Henri Setiawan > R&D of PT Telkom Indonesia > > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. ------_=_NextPart_001_01BE8766.2F750166 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Measurement and testing parameter

Henri,
The predominant testing = method is to determine interoperability between differing vendors = equipment.  Simply hook up the devices to a LAN, and across a = small WAN, set up the IP addresses correctly, and start calling.  = Measure call setup times, time to process an address translation, time = to set up the RTP channel, etc.  One uses LAN analyzers to measure = the various latencies, and to view the protocol exchanges.  = Hewlett-Packard has an H.323 analyzer in Beta now.  I do not know = of a SIP analyzer yet.

This is for an IP centric = network implementation.  For testing between a circuit switched = network and a packet based network, I do not know what one uses to = watch telephony switch message exchanges.

The problem in the SIP world = is that there are lots of prototypes and no product on the market that = I can buy today.   If someone knows differently, please let = me know ASAP.

There are some H.323 devices, = but even here, there is not much for production devices.  Erricson = has an H.323 Gatekeeper in use in Norway, but it is an NT box. There = are other H.323 gatekeepers out there, but they have all of the = problems one expects with H.323/RAS etc. (elemedia, RadVision, Cisco). = Some are simply software elements one places on a server, others are = proprietary hardware and software solutions.

You should keep a watch out = on the URL http://www.cs.columbia.edu/~hgs/sip/bakeoff.html   for the results of the SIP Bake-off, an interoperability = event held last week in New York City.

What does "MOS" = stand for?

Cordially,
Ralph

Ralph S. Hoefelmeyer
MCI WorldCom Engineer


    -----Original Message-----
    From:   Henri Setiawan = [SMTP:henry@risti.telkom.co.id]
    Sent:   Wednesday, April 14, 1999 8:29 PM
    To:     IPTEL IETF Mailing List
    Subject:       = Measurement and testing = parameter

    Dear folks,

    May be you have been evaluating = several vendors solution on VoIP. Is there
    anyone have been testing the = equipments ? Can you share about the
    measurement methods and testing = parameter to classify the performance of the
    equipment ? Also, if you know = the measurement equipment for testing please
    let me know.

    Other case, please explain to me = how can we measure MOS ?

    Thank you

    Henri Setiawan
    R&D of PT Telkom = Indonesia



    ---------
    This message came from the IETF = IPTEL Working Group Mailing List.

------_=_NextPart_001_01BE8766.2F750166-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 15 15:01:44 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11958 for ; Thu, 15 Apr 1999 15:01:43 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id AE43452CB; Thu, 15 Apr 1999 14:51:17 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 16C5F52CC; Thu, 15 Apr 1999 14:51:16 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "Hoefelmeyer, Ralph (MCI)" To: "'Sam Mokbel'" Cc: "'Tom Gray'" , "'Henri Setiawan'" , IPTEL IETF Mailing List Subject: RE: Measurement and testing parameter Date: Thu, 15 Apr 1999 18:48:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE8770.961BFD7A" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk 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_01BE8770.961BFD7A Content-Type: text/plain Sam, Shouldn't the codec smooth this out? I am a network and software person, not a telephony expert ... yet, working on it. I would think there would be a buffering function within the codec to smooth the delay & delay variations out. Of course, if the delay is to long (whatever that means), then there is a noticeable gap in the voice stream. Thanks, Ralph > -----Original Message----- > From: Sam Mokbel [SMTP:smokbel@enfm.utcc.utoronto.ca] > Sent: Thursday, April 15, 1999 12:20 PM > To: Hoefelmeyer, Ralph (MCI) > Cc: 'Tom Gray'; 'Henri Setiawan'; IPTEL IETF Mailing List > Subject: Re: Measurement and testing parameter > > Ralph, > > Even if the transport layer delivers all packets that does not necessarily > mean that it is not having an effect on the MOS. The delay and delay > variations of the packet arrival time can have a significant effect on > MOS. > > Hoefelmeyer, Ralph (MCI) wrote: > > > > Tom, > Thanks. So this MOS would be primarily dependent on the codex, > assuming the transport layers delivers all of the packets? > > Please clarify your message, as you can see below it came through > garbled. > Cordially, > Ralph > > -----Original Message----- > From: Tom Gray [SMTP:tom_gray_intp@yahoo.com] > Sent: Thursday, April 15, 1999 11:50 AM > To: Hoefelmeyer, Ralph (MCI); 'Henri Setiawan'; IPTEL IETF > Mailing List > Subject: RE: Measurement and testing parameter > > > --- "Hoefelmeyer, Ralph (MCI)" > > wrote: > > > > > What does "YM_M4I5S3S_4" stand for? > > > > YM_M4I5S3S_5 is Mean Opinion Score. It is a metric which > denotes the > perceived quality of the voice connection. It has five categories > going > from Excellent to Unacceptable. This is an important aspect of > YM_M4I5S3S_6 telephony since it will assess the capability of > various > YM_M4I5S3S_7 to meet human expectations. It will also be a measure > of > YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9 protocol. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at > > -- > Sam Mokbel > University of Toronto > External Networking and Facilities Management > 4 Bancroft Ave., Room 101 > Toronto, Ontario M5S 1C1 > Tel: (416) 978-3328 Fax: (416) 978-6620 > ------_=_NextPart_001_01BE8770.961BFD7A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Measurement and testing parameter

Sam,
Shouldn't the codec smooth = this out?  I am a network and software person, not a telephony = expert ... yet, working on it.

I would think there would be = a buffering function within the codec to smooth the delay & delay = variations out.  Of course, if the delay is to long (whatever that = means), then there is a noticeable gap in the voice stream.

Thanks,
Ralph

    -----Original Message-----
    From:   Sam Mokbel = [SMTP:smokbel@enfm.utcc.utoronto.ca]
    Sent:   Thursday, April 15, 1999 12:20 PM
    To:     Hoefelmeyer, Ralph (MCI)
    Cc:     'Tom Gray'; 'Henri Setiawan'; IPTEL IETF Mailing = List
    Subject:       = Re: Measurement and testing = parameter

    Ralph,

    Even if the transport layer delivers all = packets that does not necessarily mean that it is not having an effect = on the MOS. The delay and delay variations of the packet arrival time = can have a significant effect on MOS.

    Hoefelmeyer, Ralph (MCI) wrote:

      =A0

      Tom,
      Thanks.=A0 So this MOS = would be primarily dependent on the codex, assuming the transport = layers delivers all of the packets? =

      Please clarify your message, = as you can see below it came through garbled.
      Cordially,
      Ralph

              -----Original Message-----
      From:=A0=A0 Tom Gray = [SMTP:tom_gray_intp@yahoo.com]
      Sent:=A0=A0 Thursday, April = 15, 1999 11:50 AM
      To:=A0=A0=A0=A0 Hoefelmeyer, Ralph = (MCI); 'Henri Setiawan'; IPTEL IETF Mailing List
      Subject:=A0=A0=A0=A0=A0=A0=A0 RE: Measurement = and testing parameter
      =A0

              --- "Hoefelmeyer, Ralph (MCI)" = <Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com>
      wrote:

              >
      > What does = "YM_M4I5S3S_4" stand for?
      >

              YM_M4I5S3S_5 is Mean Opinion Score. It is a metric = which denotes the
      perceived quality of the = voice connection. It has five categories going
      from Excellent to = Unacceptable. This is an important aspect of
      YM_M4I5S3S_6 telephony since = it will assess the capability of various
      YM_M4I5S3S_7 to meet human = expectations. It will also be a measure of
      YM_M4I5S3S_8 beyond = compliance to the YM_M4I5S3S_9 protocol. =

              _________________________________________________________
      Do You Yahoo!?
      Get your free @yahoo.com = address at <http://mail.yahoo.com>

    --
    Sam Mokbel
    University of Toronto
    External Networking and Facilities Management
    4 Bancroft Ave., Room 101
    Toronto, Ontario M5S 1C1
    Tel: (416) 978-3328 Fax: (416) 978-6620
    =A0

------_=_NextPart_001_01BE8770.961BFD7A-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 15 15:13:56 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12269 for ; Thu, 15 Apr 1999 15:13:56 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 57F1152CF; Thu, 15 Apr 1999 15:05:26 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9996552D1; Thu, 15 Apr 1999 15:05:25 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990415190353.24243.rocketmail@web118.yahoomail.com> Date: Thu, 15 Apr 1999 12:03:53 -0700 (PDT) From: Tom Gray Subject: RE: Measurement and testing parameter To: Tom Gray , "Hoefelmeyer, Ralph (MCI)" , "'Henri Setiawan'" , IPTEL IETF Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Yahoo seems to have a strange sense of humour. its spell checker changed my English words to some strange internal representaion. Here is another attempt. > What does "MOS" stand for? > MOS is Mean Opinion Score. It is a metric which denotes the perceived quality of the voice connection. It has five categories going from Excellent to Unacceptable. This is an important aspect of IP telephony since it will assess the capability of various implementations to meet human expectations. It will also be a measure of interoperability beyond compliance to the signaling protocol. > M-O-S is Mean Opinion Score. It is a metric > which denotes the > perceived quality of the voice connection. It has > five categories going > from Excellent to Unacceptable. This is an important > aspect of >IP telephony since it will assess the > capability of various > to meet human expectations. It will > also be a measure of > YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9 > protocol. > --- Tom Gray wrote: > > > --- "Hoefelmeyer, Ralph (MCI)" > > wrote: _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 15 15:22:03 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12609 for ; Thu, 15 Apr 1999 15:22:03 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 536C052B7; Thu, 15 Apr 1999 15:13:22 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8950252D5; Thu, 15 Apr 1999 15:13:21 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37163A83.1BDF44B2@enfm.utcc.utoronto.ca> Date: Thu, 15 Apr 1999 15:14:11 -0400 From: Sam Mokbel Organization: ONet Networking X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: "Hoefelmeyer, Ralph (MCI)" Cc: "'Tom Gray'" , "'Henri Setiawan'" , IPTEL IETF Mailing List Subject: Re: Measurement and testing parameter References: Content-Type: multipart/alternative; boundary="------------3C3D8B6678CAEFDA23C55E82" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --------------3C3D8B6678CAEFDA23C55E82 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sure, the Codec may be able to smooth out a lot of the jitter and delay. There are limits however to how long you can buffer and introduce additional engineered delays. I have seen suggestions that delays in excess of 150ms are not acceptable because they are noticeable to the human ear, assuming that echo is dealt with properly. Current data traffic patterns and networking protocols may introduce delays in excess of 150ms. Hoefelmeyer, Ralph (MCI) wrote: > > > Sam, > Shouldn't the codec smooth this out? I am a network and software > person, not a telephony expert ... yet, working on it. > > I would think there would be a buffering function within the codec to > smooth the delay & delay variations out. Of course, if the delay is > to long (whatever that means), then there is a noticeable gap in the > voice stream. > > Thanks, -- Sam Mokbel University of Toronto External Networking and Facilities Management 4 Bancroft Ave., Room 101 Toronto, Ontario M5S 1C1 Tel: (416) 978-3328 Fax: (416) 978-6620 --------------3C3D8B6678CAEFDA23C55E82 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sure, the Codec may be able to smooth out a lot of the jitter and delay. There are limits however to how long you can buffer and introduce additional engineered delays. I have seen suggestions that delays in excess of 150ms are not acceptable because they are noticeable to the human ear, assuming that echo is dealt with properly. Current data traffic patterns and networking protocols may introduce delays in excess of 150ms.

Hoefelmeyer, Ralph (MCI) wrote:

 

Sam,
Shouldn't the codec smooth this out?  I am a network and software person, not a telephony expert ... yet, working on it.

I would think there would be a buffering function within the codec to smooth the delay & delay variations out.  Of course, if the delay is to long (whatever that means), then there is a noticeable gap in the voice stream.

Thanks,

--
Sam Mokbel
University of Toronto
External Networking and Facilities Management
4 Bancroft Ave., Room 101
Toronto, Ontario M5S 1C1
Tel: (416) 978-3328 Fax: (416) 978-6620
  --------------3C3D8B6678CAEFDA23C55E82-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 15 17:00:15 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14430 for ; Thu, 15 Apr 1999 17:00:15 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C829152D3; Thu, 15 Apr 1999 16:55:17 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 208F252D4; Thu, 15 Apr 1999 16:55:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "DelRegno, Christopher (MCI)" To: "'Sam Mokbel'" , "Hoefelmeyer, Ralph (MCI)" Cc: "'Tom Gray'" , "'Henri Setiawan'" , IPTEL IETF Mailing List Subject: RE: Measurement and testing parameter Date: Thu, 15 Apr 1999 20:50:37 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE8781.9DC9E3DC" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk 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_01BE8781.9DC9E3DC Content-Type: text/plain; charset="windows-1252" Regarding PSTN signalling test equipment, there are many such devices from HP, etc. I have not seen one however that can simultaneously test both sides of a IP/PSTN call. MOS, as noted below, is Mean Opinion Score. Notice, Opinion. MOS is an objective way of measuring the subjective nature of voice quality and the individual's experience. MOS, from a provider's perspective should be measured end-to-end, since this is what the user experience will be based on. In codec development, we rely on MOS testing to determine the relative quality of that codec as compared to PCM. Further, in network analysis, MOS can be used to determine the quality of one network technology versus another, or one carrier's network vs. another. Traditionally, true MOS testing is very expensive. Most people use more limited, predictive testing such as DAM testing. These types of tests suggest what type of MOS score would result from a true evaluation, without the cost. However, DAM testing and the like doesn't guarantee the MOS score; it is only a predictor, and usually a pretty good one. While codecs may be able to smooth out network impairments within reason, they cannot smooth out ALL network impairments. Networks can vary wildly depending upon architecture, protocols, QOS, etc. For example, if latency increases too much, today's echo cancellors may not have a way to compensate, thereby increasing the echo. While every other parameter may be on target, this one problem will significantly affect the overall quality. I am sorry to say that there is no one device that can measure MOS on the fly, to my knowledge. Most testing requires the development of test cases and test content, running that content through pristine networks and conditions and then comparing the results with the results from varying codecs, network impairments, etc. Not necessarily an easy process. Hope that helps. Nick Christopher N. "Nick" DelRegno MCI WorldCom, Access Technology Development 400 International Pkwy, 1010/041 Richardson, TX 75081-6606 Tel: 972-729-3411 Fax: 972-907-8784 Email: Nick.DelRegno@mci.com -----Original Message----- From: Sam Mokbel [mailto:smokbel@enfm.utcc.utoronto.ca] Sent: Thursday, April 15, 1999 12:14 PM To: Hoefelmeyer, Ralph (MCI) Cc: 'Tom Gray'; 'Henri Setiawan'; IPTEL IETF Mailing List Subject: Re: Measurement and testing parameter Sure, the Codec may be able to smooth out a lot of the jitter and delay. There are limits however to how long you can buffer and introduce additional engineered delays. I have seen suggestions that delays in excess of 150ms are not acceptable because they are noticeable to the human ear, assuming that echo is dealt with properly. Current data traffic patterns and networking protocols may introduce delays in excess of 150ms. Hoefelmeyer, Ralph (MCI) wrote: Sam, Shouldn't the codec smooth this out? I am a network and software person, not a telephony expert ... yet, working on it. I would think there would be a buffering function within the codec to smooth the delay & delay variations out. Of course, if the delay is to long (whatever that means), then there is a noticeable gap in the voice stream. Thanks, -- Sam Mokbel University of Toronto External Networking and Facilities Management 4 Bancroft Ave., Room 101 Toronto, Ontario M5S 1C1 Tel: (416) 978-3328 Fax: (416) 978-6620 ------_=_NextPart_001_01BE8781.9DC9E3DC Content-Type: text/html; charset="windows-1252"

Regarding PSTN signalling test equipment, there are many such devices from HP, etc.  I have not seen one however that can simultaneously test both sides of a IP/PSTN call.
 
MOS, as noted below, is Mean Opinion Score.  Notice, Opinion.  MOS is an objective way of measuring the subjective nature of voice quality and the individual's experience.  MOS, from a provider's perspective should be measured end-to-end, since this is what the user experience will be based on.  In codec development, we rely on MOS testing to determine the relative quality of that codec as compared to PCM.  Further, in network analysis, MOS can be used to determine the quality of one network technology versus another, or one carrier's network vs. another.
 
Traditionally, true MOS testing is very expensive.  Most people use more limited, predictive testing such as DAM testing.  These types of tests suggest what type of MOS score would result from a true evaluation, without the cost.  However, DAM testing and the like doesn't guarantee the MOS score; it is only a predictor, and usually a pretty good one.
 
While codecs may be able to smooth out network impairments within reason, they cannot smooth out ALL network impairments.  Networks can vary wildly depending upon architecture, protocols, QOS, etc.  For example, if latency increases too much, today's echo cancellors may not have a way to compensate, thereby increasing the echo.  While every other parameter may be on target, this one problem will significantly affect the overall quality.
 
I am sorry to say that there is no one device that can measure MOS on the fly, to my knowledge.  Most testing requires the development of test cases and test content, running that content through pristine networks and conditions and then comparing the results with the results from varying codecs, network impairments, etc.  Not necessarily an easy process.
 
Hope that helps.
 
Nick

Christopher N. "Nick" DelRegno
MCI WorldCom, Access Technology Development
400 International Pkwy, 1010/041
Richardson, TX  75081-6606
Tel: 972-729-3411
Fax: 972-907-8784
Email: Nick.DelRegno@mci.com

 
 
-----Original Message-----
From: Sam Mokbel [mailto:smokbel@enfm.utcc.utoronto.ca]
Sent: Thursday, April 15, 1999 12:14 PM
To: Hoefelmeyer, Ralph (MCI)
Cc: 'Tom Gray'; 'Henri Setiawan'; IPTEL IETF Mailing List
Subject: Re: Measurement and testing parameter

Sure, the Codec may be able to smooth out a lot of the jitter and delay. There are limits however to how long you can buffer and introduce additional engineered delays. I have seen suggestions that delays in excess of 150ms are not acceptable because they are noticeable to the human ear, assuming that echo is dealt with properly. Current data traffic patterns and networking protocols may introduce delays in excess of 150ms.

Hoefelmeyer, Ralph (MCI) wrote:

 

Sam,
Shouldn't the codec smooth this out?  I am a network and software person, not a telephony expert ... yet, working on it.

I would think there would be a buffering function within the codec to smooth the delay & delay variations out.  Of course, if the delay is to long (whatever that means), then there is a noticeable gap in the voice stream.

Thanks,

--
Sam Mokbel
University of Toronto
External Networking and Facilities Management
4 Bancroft Ave., Room 101
Toronto, Ontario M5S 1C1
Tel: (416) 978-3328 Fax: (416) 978-6620
 

------_=_NextPart_001_01BE8781.9DC9E3DC-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 15 17:45:48 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15162 for ; Thu, 15 Apr 1999 17:45:48 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id EC67F52D2; Thu, 15 Apr 1999 17:41:17 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5D0F852D5; Thu, 15 Apr 1999 17:41:16 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Lotus-FromDomain: TERADYNE From: "Kevin Davis" To: iptel@lists.research.bell-labs.com Message-ID: <85256754.0076F481.00@notes.teradyne.com> Date: Thu, 15 Apr 1999 17:40:47 -0400 Subject: MOS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk >>MOS is Mean Opinion Score. It is a metric which denotes the >>perceived quality of the voice connection. It has five >>categories going from Excellent to Unacceptable. This is >>an important aspect of IP telephony .... As Tom has pointed out, MOS is a measure of percieved quality. The ITU-T calls it a "subjective" measure, which is to say it depends upon human listeners. In contrast to MOS, there is also an "objective" measure; see ITU-T P.861 - PSQM (Perceptual Speech Quality Measure). Both MOS and PSQM both will provide a numerical value to represent the quality level, there is no single function which maps one to the other. P.861 section 10.1 "Since the relationship between the MOS and PSQM values is not necessarily the same for different languages or even for different subjective tests within a language, it is difficult to determine a unique function which transforms the PSQM value to the estimated MOS value." The objective measure (PSQM) estimates the subjective measure. The latter (human perception of quality) is presumably what everyone really wants to know, but the it is the former which can be automated and provide higher consistency. P.861 section 10.1 "It is difficult to compare the MOSs obtained in different subjective experiments since subjective judgement is affected by the experimental settings ...." --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 16 12:30:26 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06659 for ; Fri, 16 Apr 1999 12:30:25 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B4B7152CC; Fri, 16 Apr 1999 12:25:14 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 302A552CD; Fri, 16 Apr 1999 12:25:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990416162402.13813.rocketmail@web117.yahoomail.com> Date: Fri, 16 Apr 1999 09:24:02 -0700 (PDT) From: Tom Gray Subject: RE: Measurement and testing parameter To: "'Tom Gray'" , "'Henri Setiawan'" , IPTEL IETF Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk It should be remembered that MOS is based on the. subjective opinions of real people about the quality of a voice connection. It is therefore based on their expectations of the service. With experience these expectations tend to rise and the expectations of the performance of teh PSTN network have risen over the years making MOS more stringent as time goes by. An MOS for IP tlephony needs to be developed to coincde with the expecations of the people who use it and the decision makers who will buy it. It is likely that these people, given IP telephony's other advantages, will not expect or require the same level of service from IPTel as the PSTN. Direct use of a PSTN MOS is probably not predictive or useful. Tom Gray _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 16 23:39:15 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21702 for ; Fri, 16 Apr 1999 23:39:15 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E6D7D52CD; Fri, 16 Apr 1999 22:47:22 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4CA5952D1; Fri, 16 Apr 1999 22:47:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Joe" Subject: IMPORTANTE ! To: goldlist943e@research.bell-labs.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Fri, 16 Apr 1999 22:23:53 -0500 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <19990417024704.F3E9C52CD@lists.research.bell-labs.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA21702 -------------------------------- BASES DE DATOS EN CD-ROM PARA MARKETING POR EMAIL -------------------------------- 10.000 EMAILS ARGENTINOS $ 99 20.000 EMAILS ARGENTINOS $ 199 30.000 EMAILS ARGENTINOS $ 299 -------------------------------- DATOS ACTUALIZADOS !!! -------------------------------- LLAME AL 4312-9666 -------------------------------- Los precios NO incluyen el IVA Oferta Valida hasta el 31/06/99 ////////////////////////////////////////////////////////////// REMOVE AT mailto:offlist@isleuthmail.com ////////////////////////////////////////////////////////////// --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Apr 19 10:00:21 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14663 for ; Mon, 19 Apr 1999 10:00:20 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7C2A452BB; Mon, 19 Apr 1999 08:33:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E65D352BF; Mon, 19 Apr 1999 08:33:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <033f01be8a61$7d3d9040$741f0e0a@telkom.go.id> From: "Henri Setiawan" To: "Tom Gray" , "IPTEL IETF Mailing List" References: <19990416162402.13813.rocketmail@web117.yahoomail.com> Subject: Re: Measurement and testing parameter Date: Mon, 19 Apr 1999 19:38:09 +0700 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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dear Tom, Thank you for your respon regarding my question on measurement and testing parameter, on my understanding tha MOS is not the only parameter to test VoIP products. So, what do you think about the other parameter ? Like delay, jitter, Codec or others QoS parameter ? According to you if we are only the user, what we must aware on this technology ? Testing the products one by one or just waiting until the technology is mature ? By the way what do you think about using VoIP as asubstitute for to date exchange ? Do you have any concept on this ? Thanks Henri S ----- Original Message ----- From: Tom Gray To: 'Tom Gray' ; 'Henri Setiawan' ; IPTEL IETF Mailing List Sent: Friday, April 16, 1999 2324 Subject: RE: Measurement and testing parameter > > > It should be remembered that MOS is based on the. subjective opinions > of real people about the quality of a voice connection. It is therefore > based on their expectations of the service. With experience these > expectations tend to rise and the expectations of the performance of > teh PSTN network have risen over the years making MOS more stringent as > time goes by. > > An MOS for IP tlephony needs to be developed to coincde with the > expecations of the people who use it and the decision makers who will > buy it. It is likely that these people, given IP telephony's other > advantages, will not expect or require the same level of service from > IPTel as the PSTN. Direct use of a PSTN MOS is probably not predictive > or useful. > > Tom Gray > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 20 02:07:49 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29517 for ; Tue, 20 Apr 1999 02:07:48 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B518852BF; Tue, 20 Apr 1999 02:01:14 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1F6B752C1; Tue, 20 Apr 1999 02:01:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <371C262F.D1C8C969@indosat.net.id> Date: Tue, 20 Apr 1999 14:01:03 +0700 From: Perry Erick Renaldo X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: IPtel Forum Subject: Re: Measurement and testing parameter References: <19990416162402.13813.rocketmail@web117.yahoomail.com> <033f01be8a61$7d3d9040$741f0e0a@telkom.go.id> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henry, If you want to test data-net product in order to get a clearer view on its performance you might need a standard test methodology. Robert Mandeville has developed a standard test methodology and approved by the IETF under the spell of RFC 2285. Might be a help. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 20 02:40:12 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02644 for ; Tue, 20 Apr 1999 02:40:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C09D652C1; Tue, 20 Apr 1999 02:35:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 136B452C2; Tue, 20 Apr 1999 02:35:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <019601be8af8$58916a40$741f0e0a@telkom.go.id> From: "Henri Setiawan" To: "Perry Erick Renaldo" , "IPtel Forum" References: <19990416162402.13813.rocketmail@web117.yahoomail.com> <033f01be8a61$7d3d9040$741f0e0a@telkom.go.id> <371C262F.D1C8C969@indosat.net.id> Subject: Re: Measurement and testing parameter Date: Tue, 20 Apr 1999 13:38:04 +0700 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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for your help. By the way, is there anyone who have the standard test methodology either it was release by IETF or other standard body or proprietary by vendor ? Please share with me. Regards, Henri S ----- Original Message ----- From: Perry Erick Renaldo To: IPtel Forum Sent: Tuesday, April 20, 1999 1401 Subject: Re: Measurement and testing parameter > Henry, > If you want to test data-net product in order to get a clearer view on > its performance you might need a standard test methodology. Robert > Mandeville has developed a standard test methodology and approved by the > IETF under the spell of RFC 2285. Might be a help. > > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 20 05:58:42 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03626 for ; Tue, 20 Apr 1999 05:58:42 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 044D252B7; Tue, 20 Apr 1999 05:53:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6BB4152C3; Tue, 20 Apr 1999 05:53:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "Tom-PT Taylor" To: Henri Setiawan , Perry Erick Renaldo , IPtel Forum Subject: RE: Measurement and testing parameter Date: Tue, 20 Apr 1999 04:51:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk ITU-T Study Group 12 are the experts on this stuff. For further information, have a look at http://www.itu.int/itudoc/itu-t/com12/index.html > -----Original Message----- > From: Henri Setiawan [SMTP:henry@risti.telkom.co.id] > Sent: Tuesday, April 20, 1999 2:38 AM > To: Perry Erick Renaldo; IPtel Forum > Subject: Re: Measurement and testing parameter > > Thanks for your help. > > By the way, is there anyone who have the standard test methodology either > it > was release by IETF or other standard body or proprietary by vendor ? > Please > share with me. > > Regards, > > Henri S > > ----- Original Message ----- > From: Perry Erick Renaldo > To: IPtel Forum > Sent: Tuesday, April 20, 1999 1401 > Subject: Re: Measurement and testing parameter > > > > Henry, > > If you want to test data-net product in order to get a clearer view on > > its performance you might need a standard test methodology. Robert > > Mandeville has developed a standard test methodology and approved by the > > IETF under the spell of RFC 2285. Might be a help. > > > > > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 20 16:39:02 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18016 for ; Tue, 20 Apr 1999 16:39:02 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 77DB852C5; Tue, 20 Apr 1999 16:31:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D1E9952C7; Tue, 20 Apr 1999 16:31:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.5.32.19990420130905.01b429c0@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 20 Apr 1999 13:09:05 -0700 To: iptel@lists.research.bell-labs.com From: Marty Bickford Subject: Education/Research Passes to iBAND2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hello Everyone, Stardust Forums is giving away a number of education and research passes to iBAND2. This technical conference is focused on Quality of Service-based Traffic Management, Measuring & Monitoring Traffic, Interdomain & Peered QoS & IP Multicast, Billing for Premium Services, & more If you fit this category, simply drop me some email. Of course, if you do work for an ISP, enterprise or vendor....you're invited too. Below are some of the highlights of iBAND2. Sincerely, Marty Bickford Conference Director ----------------------------------------------------------------- iBAND2 - The Internet Bandwidth Management Summit May 23-25, 1999 in San Francisco, California http://www.stardust.com/iband2/ ----------------------------------------------------------------- iBAND2 is a one-of-a-kind technical conference where attendees are immersed in the new Internet bandwidth technologies around the clock. It is your chance to explore the latest about smart bandwidth--it's not just about speed. Learn about the new bandwidth management technologies, deployment strategies, and business opportunities. Share the latest in-depth information not available anywhere else. If you are responsible for managing and growing network bandwidth, head for iBAND2. Explore ideas, insights and experiences with peers, partners and experts. Hear from the best and brightest minds in the Internet space. A must attend event for IP Network Professionals in enterprise, ISPs, and carrier organizations. Are you an enterprise executive looking to harness your network? Are you a network professional examining the future of your network? Are you a service provider looking to sell additional services and not just bandwidth? Discover how you can make and save money by offering new business services. Join us at iBAND2. Scroll down for details or click on a link. TECHNOLOGIES COVERED & WHITE PAPER http://www.stardust.com/iband2/tech_resources.htm QUALITY OF SERVICE (QoS) NETWORK SHOWCASE http://www.stardust.com/iband2/qos-showcase.htm FREE MP3 PLAYERS WITH PURCHASE OF CONFERENCE SESSIONS http://www.stardust.com/iband2/diamond.htm LEADING INTERNET TECHNOLOGISTS AT iBAND2 & THE AGENDA http://www.stardust.com/iband2/sessions.htm REGISTER TODAY & SAVE https://www.stardust.com/events/iband2/registration.htm TECHNOLOGIES COVERED & THE INTERNET BANDWIDTH MANAGEMENT WHITE PAPER -------------------------- iBAND2 is a one-of-a-kind technical and educational event, exploring the latest about smart bandwidth-- its not just about speed. Learn about the new bandwidth management technologies, deployment strategies, and business opportunities. Share the latest in-depth information not available anywhere else. Explore ideas with peers, partners and experts. Hot topics: * QoS, IP Multicast, DIFFSERV, RSVP, Policy, COPS, Directory Standards and Schema * Quality of Service-based Traffic Management, Measuring & Monitoring Traffic, Interdomain & Peered QoS & IP Multicast, Billing for Premium Services * Traffic prioritization, Voice over IP, SLA's, VPN's, Call Centers. Streaming Media, and more. Internet Bandwidth Management White Paper: Technologies, applications and business opportunities are the focus of an up-to-date 24 page white paper produced for iBAND. Download it today for free: http://www.stardust.com/iband2/whitepaper.hm QUALITY OF SERVICE (QoS) NETWORK SHOWCASE ----------------------------------------- 15 vendors are collaborating to build an end-to-end QoS Network. Attendees will experience the benefits and comparisons between applications with QoS enabled and disabled in a saturated network environment. Discuss the options and capabilities with the engineers who designed and built this extensive network. View policy management, directory services, traffic management and monitoring and more. http://www.stardust.com/iband2/qos-showcase.htm Participating companies include: 3Com, Cisco, Extreme, IPHighway, IPivot, Lucent, Microsoft, IBM, Intel, Novell, Orchestream, Qosnetics, Xedia, Netcom Systems, Nortel, and more. FREE MP3 PLAYERS WITH PURCHASE OF CONFERENCE SESSIONS ----------------------------------------- We know you can't attend more than one session at a time. In addition to receiving all materials electronically, Diamond Attendees receive a FREE Portable Conference Player (MP3 Player). We'll also include conference sessions from iBAND98 and MCAST99. http://www.stardust.com/iband2/diamond.htm THE LEADERS & THEIR SESSIONS ---------------------------------------------- Who will be there? Leading Internet technologists from the IETF, vendor and service providers. Our keynote: Scott Bradner of Harvard University. Mr. Bradner is the co director of the Transport Area in the IETF, is a member of the IESG, and an elected trustee of the Internet Society where he serves as the Vice President for Standards. He was also co director of the IETF IP next generation effort and is coeditor of "IPng: Internet Protocol Next Generation" from Addison-Wesley. Other distinguished presenters include: * Radia Perlman, Sun Microsystems * Shai Herzog, IPHighway * Bob Quinn, Stardust Forums * Winston Bumpus, Novell & DMTF * Benjamin Teitelbaum, Internet2 * Hal Sandick, Nortel * Yoram Bernet, Microsoft * Vasilis Theoharakis, 3Com * Rod Murchison, Newbridge * Ashley Stephenson, Xedia Corporation * Ed Perry, Hewlett-Packard * Charlie Muirhead, Orchestream * Mark Fishburn, NetCom Systems * Doug Sherman, 3Com * Adam Dunstan, Avici Systems * Tom Clarkson, IPivot * Jude O'Reilly, Aventail * Jeff Young, Cable & Wireless * Vijay Srinivasan, Torrent Networking Technologies * J. Christopher Landes, Lucent * and of course...many more. Click here for more details about the technical conference http://www.stardust.com/iband2/sessions.htm REGISTER ---------------------------------------------- ACT FAST. Sign up before April 23rd and save $200 http://www.stardust.com/iband2/ Nortel Networksis the Platinum Sponsor, IP Multicast Initiative & the Quality of Service Forum are Alliance Sponsors, and America's Network, Data Communications, InternetWeek and tele.com are Publication Sponsors of iBAND2. Contact Stardust Forums at (408)879-8080 with any questions regarding iBAND2. See you there. --- Marty Bickford - 408.879.8080 (8081-fax) Stardust Forums - http://www.stardust.com iBAND2(sm) - The Internet Bandwidth Management Summit --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 20 23:04:03 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23757 for ; Tue, 20 Apr 1999 23:04:03 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id CD0F852CC; Tue, 20 Apr 1999 22:57:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4882952CD; Tue, 20 Apr 1999 22:57:16 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Eric Ho" To: "IPTEL IETF Mailing List" Cc: "IPTEL IETF Mailing List" Subject: H.323 with ATM Date: Wed, 21 Apr 1999 10:53:30 +0800 Message-ID: <000001be8ba2$231ba650$0f2d90a9@eho-laptop.fore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <371D3C02.40DE9000@dnrc.bell-labs.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.fore.com id WAA13374 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23757 Hi, Could anyone please advise how VoIP is going to run over ATM (i.e., what kind of encapsulation or native ATM)? Thanks in advance! eh   ===================================================================== Eric Ho Direct: +852-27222766 FORE Systems, Inc. Main: +852-27222722 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 20 23:46:03 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24437 for ; Tue, 20 Apr 1999 23:46:02 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3425252C7; Tue, 20 Apr 1999 22:46:46 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 88B2C52CC; Tue, 20 Apr 1999 22:46:45 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <371D3C02.40DE9000@dnrc.bell-labs.com> Date: Tue, 20 Apr 1999 22:46:26 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Matt Squire Cc: IPTEL IETF Mailing List Subject: Re: Evaluation of Gateway Location proposals References: <3.0.32.19990408121635.00881600@bl-mail1.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Matt Squire wrote: > > I'm already sorry for the length of this message, but I had to > respond... > > So here are my comments on your comparison. Not surprisingly, I have a > different view on several important aspects. Let me summarize here: 1. I think we all agree that attributes will need to be treated, one at a time, thought out, and specified, for GLP. The difference between Matt's and Hussein's approach is one of direction - starting with BGP and modifying, or taking a more fresh approach. In the end, it doesn't really matter. So, for this thread, lets focus on things not having to do with attributes (which includes AS_PATH, MED, NEXT_HOP, etc.) 2. Matt raised numerous transport issues (TCP or not TCP). I think its fair to say we want to avoid designing a new transport protocol. There is work underway elsewhere (sigtran and slums) to do this, which we can leverage. It would seem to me that if something new is needed, this would also be independent of whether the protocol baseline is BGP or SCSP, since presumably one could use this new transport protocol with either. 3. To me, the MAIN differences between a BGP based approach and SCSP based approach are: a. how the data is synchronized between peers b. the intra-domain topology I think we are clear on (b), so (a) is the issue to explore. Hussein had made reference to a 2-stage exchange only being needed with BGP, while its three with SCSP. These are the kind of differences I think we need to explore here. I'd invite both authors to comment on the differences in how the data is exchanged and updated between peers. Lets stick with inter-domain for the moment... -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 21 07:18:30 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03262 for ; Wed, 21 Apr 1999 07:18:29 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id EFDF552CD; Wed, 21 Apr 1999 07:13:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6606D52CF; Wed, 21 Apr 1999 07:13:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Mailer: exmh version 2.0.2 To: Eric Ho Cc: iptel@lists.research.bell-labs.com Subject: Re: H.323 with ATM In-reply-to: Your message of "Wed, 21 Apr 1999 10:53:30 +0800." <000001be8ba2$231ba650$0f2d90a9@eho-laptop.fore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Apr 1999 12:11:09 +0100 Message-ID: <6555.924693069@cs.ucl.ac.uk> From: Nadia KAUSAR Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi I believe some people in a company called INESC are looking at various aspects of H.323 conferencing over ATM. also if it is H.323 conferencing and ATM issues you are interested in may be h323implementors@imtc.org will be a better mailing list? thanks Nadia --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 21 08:32:37 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03984 for ; Wed, 21 Apr 1999 08:32:36 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A31A552CE; Wed, 21 Apr 1999 08:27:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0D78E52D1; Wed, 21 Apr 1999 08:27:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: gregboop@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Eric Ho" Cc: "IPTEL IETF Mailing List" Message-ID: <8525675A.004453F1.00@d54mta03.raleigh.ibm.com> Date: Wed, 21 Apr 1999 08:26:16 -0400 Subject: Re: H.323 with ATM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk For VoIP using H.323; Annex C of the H.323 specification describes how to implement VoIP for ATM. A better mailing list to discuss H.323 however will be h323implementors@imtc.org. Best Regards, - Greg Boop Mgr - VoIP Development IBM NHD RTP, NC, USA +1 919 254 0319 gregboop@us.ibm.com "Eric Ho" on 04/20/99 10:53:30 PM To: "IPTEL IETF Mailing List" cc: "IPTEL IETF Mailing List" (bcc: Gregory Boop/Raleigh/IBM) Subject: H.323 with ATM Hi, Could anyone please advise how VoIP is going to run over ATM (i.e., what kind of encapsulation or native ATM)? Thanks in advance! eh ===================================================================== Eric Ho Direct: +852-27222766 FORE Systems, Inc. Main: +852-27222722 --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 21 10:18:55 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07139 for ; Wed, 21 Apr 1999 10:18:55 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0616C52D1; Wed, 21 Apr 1999 10:11:25 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4D0A552D4; Wed, 21 Apr 1999 10:11:24 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990421141140.16996.rocketmail@web114.yahoomail.com> Date: Wed, 21 Apr 1999 07:11:40 -0700 (PDT) From: Abhishek Singh Subject: Re: H.323 with ATM To: Eric Ho , IPTEL IETF Mailing List Cc: IPTEL IETF Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi Eric, There is work going on in the ATM Forum and it is called RMOA(realtime multimedia over ATM). Seems pretty good way for H.323 transport over ATM. Not aware of SIP efforts though. cheers Abhishek --- Eric Ho wrote: > Hi, > > Could anyone please advise how VoIP is going to run > over ATM > (i.e., what kind of encapsulation or native ATM)? > > Thanks in advance! > > eh > > >   > > ===================================================================== > Eric Ho > Direct: +852-27222766 > FORE Systems, Inc. > Main: +852-27222722 > > > > > --------- > This message came from the IETF IPTEL Working Group > Mailing List. > === Go to http://abhishekrs.eCode.com to pick up my online Business Card. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 21 10:35:42 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07584 for ; Wed, 21 Apr 1999 10:35:42 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 608D652D3; Wed, 21 Apr 1999 10:19:21 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B999A52D4; Wed, 21 Apr 1999 10:19:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <371DDE44.CBB66640@cs.columbia.edu> Date: Wed, 21 Apr 1999 10:18:44 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Abhishek Singh Cc: Eric Ho , IPTEL IETF Mailing List Subject: Re: H.323 with ATM References: <19990421141140.16996.rocketmail@web114.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Abhishek Singh wrote: > > Hi Eric, > > There is work going on in the ATM Forum and it is > called RMOA(realtime multimedia over ATM). Seems > pretty good way for H.323 transport over ATM. Not > aware of SIP efforts though. > This topis doesn't really belong here, but to answer the question: There is no particular need to specify how SIP works with ATM, as it works just fine either with ATM transport for media or for sending SIP across (say) AAL5. The only minor item to be settled is how to represent ATM addresses in SDP. Presumably, H.332-for-ATM will have to solve that problem. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 21 11:16:54 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08748 for ; Wed, 21 Apr 1999 11:16:53 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3F1A152CF; Wed, 21 Apr 1999 11:11:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 992A752D6; Wed, 21 Apr 1999 11:11:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990421151314.4011.rocketmail@web129.yahoomail.com> Date: Wed, 21 Apr 1999 08:13:14 -0700 (PDT) From: Abhishek Singh Subject: Re: H.323 with ATM To: Henning Schulzrinne Cc: Eric Ho , IPTEL IETF Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi Henning, RMOA is rather revolutiory. I know SIP would work over any damn thing, but so would H.323. But the beauty of RMOA work is that instead of using RTP/UDP/IP over ATM in an unintelligent way it does use the QOS feautures of ATM rather than using RTP. At the same time it also carries the RTP/UDP/IP headers(compressed) to ensure interoperability with non ATM networks(ie translating it back at the egress). They use something called Real Time AAL5. The same concept could be extended to SIP without much(any) effort. Wonder if anybody is doing that. cheers Abhishek --- Henning Schulzrinne wrote: > Abhishek Singh wrote: > > > > Hi Eric, > > > > There is work going on in the ATM Forum and it is > > called RMOA(realtime multimedia over ATM). Seems > > pretty good way for H.323 transport over ATM. Not > > aware of SIP efforts though. > > > This topis doesn't really belong here, but to answer > the question: > > There is no particular need to specify how SIP works > with ATM, as it > works just fine either with ATM transport for media > or for sending SIP > across (say) AAL5. The only minor item to be settled > is how to represent > ATM addresses in SDP. Presumably, H.332-for-ATM will > have to solve that > problem. > > > -- > Henning Schulzrinne > http://www.cs.columbia.edu/~hgs > > --------- > This message came from the IETF IPTEL Working Group > Mailing List. > === Go to http://abhishekrs.eCode.com to pick up my online Business Card. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 21 12:06:05 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10038 for ; Wed, 21 Apr 1999 12:06:04 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7FBF452D5; Wed, 21 Apr 1999 10:11:35 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D6F1552D3; Wed, 21 Apr 1999 10:11:28 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990421141140.16996.rocketmail@web114.yahoomail.com> Date: Wed, 21 Apr 1999 07:11:40 -0700 (PDT) From: Abhishek Singh Subject: Re: H.323 with ATM To: Eric Ho , IPTEL IETF Mailing List Cc: IPTEL IETF Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi Eric, There is work going on in the ATM Forum and it is called RMOA(realtime multimedia over ATM). Seems pretty good way for H.323 transport over ATM. Not aware of SIP efforts though. cheers Abhishek --- Eric Ho wrote: > Hi, > > Could anyone please advise how VoIP is going to run > over ATM > (i.e., what kind of encapsulation or native ATM)? > > Thanks in advance! > > eh > > >   > > ===================================================================== > Eric Ho > Direct: +852-27222766 > FORE Systems, Inc. > Main: +852-27222722 > > > > > --------- > This message came from the IETF IPTEL Working Group > Mailing List. > === Go to http://abhishekrs.eCode.com to pick up my online Business Card. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 21 12:30:36 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10701 for ; Wed, 21 Apr 1999 12:30:35 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 961F152D4; Wed, 21 Apr 1999 12:23:25 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D663052D7; Wed, 21 Apr 1999 12:23:24 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Cc: Abhishek Singh , Eric Ho , IPTEL IETF Mailing List Message-ID: <371DFA05.E4037B20@lucent.com> Date: Wed, 21 Apr 1999 11:17:09 -0500 From: "ronald h. davis" Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: Henning Schulzrinne Original-CC: Abhishek Singh , Eric Ho , IPTEL IETF Mailing List Subject: Re: H.323 with ATM References: <19990421141140.16996.rocketmail@web114.yahoomail.com> <371DDE44.CBB66640@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > There is no particular need to specify how SIP works with ATM, as it > works just fine either with ATM transport for media or for sending SIP > across (say) AAL5. The only minor item to be settled is how to represent > ATM addresses in SDP. Presumably, H.332-for-ATM will have to solve that > problem. > the simple answer to h.323 over atm is to say that any ip over atm mechanism can be used (classical ip over atm, mpoa, &c.). in this way, atm is invisible to h.323. however, annex c of h.323 goes further to define a method of carrying media channels directly over atm without the udp/ip overhead (i.e. rtp over aal 5). maybe you could fill us in, but i'm going to assume that there is no such specification for sip and therefore sip over atm uses ip over atm methods. -- __ ______ __ / __/ | lucent technologies, naperville il, usa _/ (_(_) / (_(_/_/_(_/ . ronald.h.davis@lucent.com author of "atm for public networks" published by mcgraw-hill http://www.amazon.com/exec/obidos/ASIN/0071344764 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 21 13:02:30 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11860 for ; Wed, 21 Apr 1999 13:02:30 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1F74D52D7; Wed, 21 Apr 1999 12:57:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 76B2D52D8; Wed, 21 Apr 1999 12:57:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <371E0304.4968B3CE@cs.columbia.edu> Date: Wed, 21 Apr 1999 12:55:32 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ronald h. davis" Cc: Abhishek Singh , Eric Ho , IPTEL IETF Mailing List , mmusic@isi.edu Subject: Re: H.323 with ATM References: <19990421141140.16996.rocketmail@web114.yahoomail.com> <371DDE44.CBB66640@cs.columbia.edu> <371DFA05.E4037B20@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "ronald h. davis" wrote: > > Henning Schulzrinne wrote: > > > > There is no particular need to specify how SIP works with ATM, as it > > works just fine either with ATM transport for media or for sending SIP > > across (say) AAL5. The only minor item to be settled is how to represent > > ATM addresses in SDP. Presumably, H.332-for-ATM will have to solve that > > problem. > > > > the simple answer to h.323 over atm is to say that any ip over atm > mechanism can be used (classical ip over atm, mpoa, &c.). in this > way, atm is invisible to h.323. however, annex c of h.323 goes further > to define a method of carrying media channels directly over atm without > the udp/ip overhead (i.e. rtp over aal 5). > > maybe you could fill us in, but i'm going to assume that there is no > such specification for sip and therefore sip over atm uses ip over atm > methods. That is incorrect. As discussed in more technical detail in the SIP FAQ or various papers, SIP as a *signaling* protocol runs over any packet-based medium (or indeed, any digital bit stream), even without the presence of IP or UDP. As a protocol, it also doesn't care whether the media streams use IP, ATM, or PSTN (see the PINT WG for details). Thus, one possible approach is to run SIP over UDP/IP and voice over ATM, as that avoids having to set up a VC just for signaling. You'll run into timeout problems, but you could send SIP by carrier pigeon, bottle mail, Tanenbaum's tape-in-station-wagon transport protocol or FedEx. Since SIP does not depend on RTP (it does not specify a complete application scenario as H.323 does), it could just as easily set up on RMOA connection across ATM, with the caveat of SDP naming conventions being needed. This should really move to mmusic... -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Apr 21 19:05:59 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27862 for ; Wed, 21 Apr 1999 19:05:59 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3FC4C52D6; Wed, 21 Apr 1999 17:08:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 944B652D9; Wed, 21 Apr 1999 17:08:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <371E3DA7.7A52475C@dnrc.bell-labs.com> Date: Wed, 21 Apr 1999 17:05:43 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Abhishek Singh Cc: Henning Schulzrinne , Eric Ho , IPTEL IETF Mailing List Subject: Re: H.323 with ATM References: <19990421151314.4011.rocketmail@web129.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Abhishek Singh wrote: > > Hi Henning, > > RMOA is rather revolutiory. I know SIP would work over > any damn thing, but so would H.323. But the beauty of > RMOA work is that instead of using RTP/UDP/IP over ATM > in an unintelligent way it does use the QOS feautures > of ATM rather than using RTP. Rather than using RTP?? RTP doesn't provide QoS... There is nothing which prevents you from taking an RTP packet at an ATM boundary, extracting it, and sending it over an ATM VC that has some QoS associated with it (CBR or something), RTP in tact. Whether or not you compress RTP is a separate issue. Of course, this poor edge box now has to do some application level processing instead of being a pure layer 3/2 device. Any end to end security will make it impossible for the box to find the RTP packets as well. It seems like it would be easier to stay at layer 3, and establish VC's based on RSVP or diffserv, or something like that... but thats a separate issue. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 22 05:38:16 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10724 for ; Thu, 22 Apr 1999 05:38:16 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8427452C3; Thu, 22 Apr 1999 05:31:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E394B52D9; Thu, 22 Apr 1999 05:31:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <99Apr23.002657idt.113796@firewall.radvision.rad.co.il> From: Ami Amir To: Jonathan Rosenberg , Abhishek Singh Cc: Henning Schulzrinne , Eric Ho , IPTEL IETF Mailing List Subject: RE: H.323 with ATM Date: Thu, 22 Apr 1999 12:28:06 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Am I just butting in? H.323 Annex C is all about how to run H.323 over ATM. FYI Ami -----Original Message----- From: Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com] Sent: Thursday, April 22, 1999 12:06 AM To: Abhishek Singh Cc: Henning Schulzrinne; Eric Ho; IPTEL IETF Mailing List Subject: Re: H.323 with ATM Abhishek Singh wrote: > > Hi Henning, > > RMOA is rather revolutiory. I know SIP would work over > any damn thing, but so would H.323. But the beauty of > RMOA work is that instead of using RTP/UDP/IP over ATM > in an unintelligent way it does use the QOS feautures > of ATM rather than using RTP. Rather than using RTP?? RTP doesn't provide QoS... There is nothing which prevents you from taking an RTP packet at an ATM boundary, extracting it, and sending it over an ATM VC that has some QoS associated with it (CBR or something), RTP in tact. Whether or not you compress RTP is a separate issue. Of course, this poor edge box now has to do some application level processing instead of being a pure layer 3/2 device. Any end to end security will make it impossible for the box to find the RTP packets as well. It seems like it would be easier to stay at layer 3, and establish VC's based on RSVP or diffserv, or something like that... but thats a separate issue. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 22 08:33:04 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12738 for ; Thu, 22 Apr 1999 08:33:04 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 26E6052DB; Thu, 22 Apr 1999 08:27:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 78C1852DD; Thu, 22 Apr 1999 08:27:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Thu, 22 Apr 1999 10:03:31 -0400 (EDT) From: "Francois D. Menard" To: Ami Amir Cc: Jonathan Rosenberg , Abhishek Singh , Henning Schulzrinne , Eric Ho , IPTEL IETF Mailing List Subject: RE: H.323 with ATM In-Reply-To: <99Apr23.002657idt.113796@firewall.radvision.rad.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk How does that align with the ATM Forum document written by Francois Audet of Nortel ? -=Francois=- On Thu, 22 Apr 1999, Ami Amir wrote: > Am I just butting in? > > H.323 Annex C is all about how to run H.323 over ATM. > > FYI > > Ami > > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com] > Sent: Thursday, April 22, 1999 12:06 AM > To: Abhishek Singh > Cc: Henning Schulzrinne; Eric Ho; IPTEL IETF Mailing List > Subject: Re: H.323 with ATM > > Abhishek Singh wrote: > > > > Hi Henning, > > > > RMOA is rather revolutiory. I know SIP would work over > > any damn thing, but so would H.323. But the beauty of > > RMOA work is that instead of using RTP/UDP/IP over ATM > > in an unintelligent way it does use the QOS feautures > > of ATM rather than using RTP. > > Rather than using RTP?? RTP doesn't provide QoS... There is nothing > which prevents you from taking an RTP packet at an ATM boundary, > extracting it, and sending it over an ATM VC that has some QoS > associated with it (CBR or something), RTP in tact. Whether or not > you > compress RTP is a separate issue. > > Of course, this poor edge box now has to do some application level > processing instead of being a pure layer 3/2 device. Any end to end > security will make it impossible for the box to find the RTP packets > as > well. It seems like it would be easier to stay at layer 3, and > establish > VC's based on RSVP or diffserv, or something like that... but thats > a > separate issue. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg Lucent Technologies > Member of Technical Staff 101 Crawfords Corner Rd. > High Speed Networks Research Holmdel, NJ 07733 > FAX: (732) 834-5379 Rm. 4C-526 > EMAIL: jdrosen@bell-labs.com > URL: http://www.cs.columbia.edu/~jdrosen > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 22 16:33:45 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28589 for ; Thu, 22 Apr 1999 16:33:42 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 32F3552DE; Thu, 22 Apr 1999 16:27:31 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 82F3D52DF; Thu, 22 Apr 1999 16:27:30 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <63E0DAD7784FD21188310000F80824B36FC8CD@zmpkdx02.us.nortel.com> From: "Francois Audet" To: "'iptel@lists.research.bell-labs.com'" Cc: "Mo Zonoun" Subject: RE: H.323 with ATM Date: Thu, 22 Apr 1999 15:25:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA28589 The RMOA "Gateway for H.323 Media Transport Over ATM" is essentially a finished document now and needs only to go throught the final ballot. H.323 Annex C assumes ATM end-to-end. The ATM Forum document focuses more on the case where the edges are not ATM. The intention is that ITU-T H.323v3 incorporates the ATM Forum's specification. In Annex C, the terminals themselves are ATM aware, so setting up SVCs is easier. In the ATM Forum's specification, it is a bit more difficult to figure out when to setup the SVCs, and how to used them bi-directionnaly. What Jonathan said is absolutely true. There is basically two parts to the spec: one dealing with how to set-up SVCs based on H.245/H.225.0 information, and the other on RTP header compression transported over AAL5 (the compression mechanism is derived from RTP/UDP/IP compression over PPP). (I would have preferred to have the document splitted in two) These two parts are distinct: the compession part could be used with other protocols like SIP of MEGACO. As far as diffserv or RSVP as the trigger, well, I guess it needs more thinking. I guess it also depends on the philosophy of what you want to do: do you need an explicit association between the SVC and the "call/connection" at the H.225.0/H.245 or not? ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com > -----Original Message----- > From: Francois D. Menard [mailto:fm-listproc@uyquist.fmmo.ca] > Sent: Thursday, April 22, 1999 7:04 AM > To: Ami Amir > Cc: Jonathan Rosenberg; Abhishek Singh; Henning Schulzrinne; Eric Ho; > IPTEL IETF Mailing List > Subject: RE: H.323 with ATM > > > > How does that align with the ATM Forum document written by > Francois Audet > of Nortel ? > > -=Francois=- > > On Thu, 22 Apr 1999, Ami Amir wrote: > > > Am I just butting in? > > > > H.323 Annex C is all about how to run H.323 over ATM. > > > > FYI > > > > Ami > > > > -----Original Message----- > > From: Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com] > > Sent: Thursday, April 22, 1999 12:06 AM > > To: Abhishek Singh > > Cc: Henning Schulzrinne; Eric Ho; IPTEL IETF Mailing List > > Subject: Re: H.323 with ATM > > > > Abhishek Singh wrote: > > > > > > Hi Henning, > > > > > > RMOA is rather revolutiory. I know SIP would work over > > > any damn thing, but so would H.323. But the beauty of > > > RMOA work is that instead of using RTP/UDP/IP over ATM > > > in an unintelligent way it does use the QOS feautures > > > of ATM rather than using RTP. > > > > Rather than using RTP?? RTP doesn't provide QoS... > There is nothing > > which prevents you from taking an RTP packet at an ATM boundary, > > extracting it, and sending it over an ATM VC that has some QoS > > associated with it (CBR or something), RTP in tact. > Whether or not > > you > > compress RTP is a separate issue. > > > > Of course, this poor edge box now has to do some > application level > > processing instead of being a pure layer 3/2 device. > Any end to end > > security will make it impossible for the box to find > the RTP packets > > as > > well. It seems like it would be easier to stay at layer 3, and > > establish > > VC's based on RSVP or diffserv, or something like > that... but thats > > a > > separate issue. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 23 09:06:12 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15453 for ; Fri, 23 Apr 1999 09:06:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 56A3E52CA; Fri, 23 Apr 1999 09:00:13 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C0E0D52D2; Fri, 23 Apr 1999 09:00:12 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Cc: "'iptel@lists.research.bell-labs.com'" , Mo Zonoun Message-ID: <37206D2B.C63083DD@lucent.com> Date: Fri, 23 Apr 1999 07:52:59 -0500 From: "ronald h. davis" Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: Francois Audet Original-CC: "'iptel@lists.research.bell-labs.com'" , Mo Zonoun Subject: Re: H.323 with ATM References: <63E0DAD7784FD21188310000F80824B36FC8CD@zmpkdx02.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Francois Audet wrote: > > The RMOA "Gateway for H.323 Media Transport Over ATM" is essentially a > finished document now and needs only to go throught the final ballot. > > H.323 Annex C assumes ATM end-to-end. The ATM Forum document focuses more > on the case where the edges are not ATM. The intention is that ITU-T > H.323v3 incorporates the ATM Forum's specification. > but from h.323 and h.323 annex c you can derive the same case as is described in the atm forum document. as i read the document, the c/d effectively implements the gatekeeper routed model for h.225/h.245 channels. > These two parts are distinct: the compession part could be used with other > protocols like SIP of MEGACO. As far as diffserv or RSVP as the trigger, > well, I guess it needs more thinking. I guess it also depends on the > philosophy of what you want to do: do you need an explicit association > between the SVC and the "call/connection" at the H.225.0/H.245 or not? > i'm a bit confused about the question but i would say that the answer is most definitely; if you're going to split call control signalling and bearer connection control signalling, then you need some means of correlating the two. i don't think this was the issue that jonathan had in mind but i say this because in the version of the atm forum contribution that i have, there was no mention of use of the broadband high layer information element or generic identifier transport information element to do this correlation. let me qualify this by saying that my copy is from october... as far as using rsvp or diffserv as a trigger for svc establishment, i would think that you would want to be able to do that as well if the intent is to have some means of providing end-to-end qos across atm and ip network boundaries. but this is the case of doing ip over atm which annex c sought to avoid. the annex c approach does get into application layer processing at the interworking node as jonathan mentioned, but you save the ip overhead. there is an internet draft by garrett, et. al. which describes the interworking of controlled load service and guaranteed service with atm. -- __ ______ __ / __/ | lucent technologies, naperville il, usa _/ (_(_) / (_(_/_/_(_/ . ronald.h.davis@lucent.com author of "atm for public networks" published by mcgraw-hill http://www.amazon.com/exec/obidos/ASIN/0071344764 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 23 10:15:41 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17913 for ; Fri, 23 Apr 1999 10:15:40 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4DB5952C6; Fri, 23 Apr 1999 10:07:50 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AF06152C8; Fri, 23 Apr 1999 10:07:49 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37207E0F.159BF0B1@dnrc.bell-labs.com> Date: Fri, 23 Apr 1999 10:05:03 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "ronald h. davis" Cc: Francois Audet , "'iptel@lists.research.bell-labs.com'" , Mo Zonoun Subject: Re: H.323 with ATM References: <63E0DAD7784FD21188310000F80824B36FC8CD@zmpkdx02.us.nortel.com> <37206D2B.C63083DD@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit ronald h. davis wrote: > > > These two parts are distinct: the compession part could be used with other > > protocols like SIP of MEGACO. As far as diffserv or RSVP as the trigger, > > well, I guess it needs more thinking. I guess it also depends on the > > philosophy of what you want to do: do you need an explicit association > > between the SVC and the "call/connection" at the H.225.0/H.245 or not? > > > > i'm a bit confused about the question but i would say that the > answer is most definitely; if you're going to split call control > signalling and bearer connection control signalling, then you need > some means of correlating the two. No, I don't think you need this explicit association. For regular IP over ATM, its completely absent. Remember, this case here is not ATM end to end (in which case you *would* need it), but rather IP on the periphery, with an ATM cloud in the middle (at least, this is my interpretation, correct me if I have completely misunderstood the model here). When the RSVP hits the ATM cloud, it causes an SVC to be set up (of course, RSVP and UNI signaling are in the opposite directions, but that can be handled). RTP packets come in, are sent through this SVC (possibly being compressed), and then completely reproduced (IP header and all), and the far end. They are then carried over normal IP to the end. The recipient wouldn't even notice that there was an SVC. The great advantage of using RSVP or diffserv as a trigger for SVC establishment is that is application independent. Lets not forget that IP telephony is only one of many IP apps which will need QoS. By making this QoS mechanism H.323 specific, you narrow the scope of the service that can be provided (only H.323, and only the version you support), make this edge box more complex, and in general break the end to end model. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Apr 26 12:15:01 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19266 for ; Mon, 26 Apr 1999 12:15:01 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4ADAE52BB; Mon, 26 Apr 1999 12:09:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AFCB252BF; Mon, 26 Apr 1999 12:09:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <63E0DAD7784FD21188310000F80824B36FC8D3@zmpkdx02.us.nortel.com> From: "Francois Audet" To: "'ronald h. davis'" Cc: "'iptel@lists.research.bell-labs.com'" , "Mo Zonoun" Subject: RE: H.323 with ATM Date: Mon, 26 Apr 1999 11:06:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > but from h.323 and h.323 annex c you can derive the same case as is > described in the atm forum document. as i read the document, the c/d > effectively implements the gatekeeper routed model for h.225/h.245 > channels. Yes. That is what we did. There are some additional complications on the signalling side since in Annex C, the terminal "knows" when to set-up SVCs. In the ATM Forum specification, the gateway relies on signalling to set-up the SVCs. The intention was not to superseed the Annex C specification, but to extend its application to cases involving ATM gateways, and also to add header compression. That is the reason why it will likely be included in the next version of H.323 (probably as a reference). > i'm a bit confused about the question but i would say that the > answer is most definitely; if you're going to split call control > signalling and bearer connection control signalling, then you need > some means of correlating the two. i don't think this was the issue > that jonathan had in mind but i say this because in the version of > the atm forum contribution that i have, there was no mention of use > of the broadband high layer information element or generic identifier > transport information element to do this correlation. let me qualify > this by saying that my copy is from october... Final version (April) includes the GIT. The reason why the B-HLI was not in there was because we knew from ITU-T SG11 that Annex C's use of B-HLI was troublesome and something had to be changed. > as far as using rsvp or diffserv as a trigger for svc establishment, > i would think that you would want to be able to do that as well if > the intent is to have some means of providing end-to-end qos across > atm and ip network boundaries. but this is the case of doing ip over > atm which annex c sought to avoid. the annex c approach does get into > application layer processing at the interworking node as jonathan > mentioned, but you save the ip overhead. there is an > internet draft by > garrett, et. al. which describes the interworking of controlled load > service and guaranteed service with atm. Agreed. There are probably cases for both approaches. This is what I meant origninally. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Apr 26 12:24:45 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19332 for ; Mon, 26 Apr 1999 12:24:45 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 12BF552C2; Mon, 26 Apr 1999 12:17:33 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 549A152BF; Mon, 26 Apr 1999 12:17:31 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <63E0DAD7784FD21188310000F80824B36FC8D5@zmpkdx02.us.nortel.com> From: "Francois Audet" To: "'Jonathan Rosenberg'" , "ronald h. davis" Cc: "'iptel@lists.research.bell-labs.com'" , "Mo Zonoun" Subject: RE: H.323 with ATM Date: Mon, 26 Apr 1999 12:16:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > No, I don't think you need this explicit association. For regular IP > over ATM, its completely absent. Remember, this case here is > not ATM end > to end (in which case you *would* need it), but rather IP on the > periphery, with an ATM cloud in the middle (at least, this is my > interpretation, correct me if I have completely misunderstood > the model > here). When the RSVP hits the ATM cloud, it causes an SVC to be set up > (of course, RSVP and UNI signaling are in the opposite directions, but > that can be handled). RTP packets come in, are sent through this SVC > (possibly being compressed), and then completely reproduced (IP header > and all), and the far end. They are then carried over normal IP to the > end. The recipient wouldn't even notice that there was an SVC. Yes, the model is the ATM cloud in the middle, the IP networks on the edges. > The great advantage of using RSVP or diffserv as a trigger for SVC > establishment is that is application independent. Lets not forget that > IP telephony is only one of many IP apps which will need QoS. > By making > this QoS mechanism H.323 specific, you narrow the scope of the service > that can be provided (only H.323, and only the version you support), > make this edge box more complex, and in general break the end to end > model. We looked at using lower-layer mechanism at the beginning, but couldn't find satisfactory methods. RSVP was felt as not being sufficiently deployed, diffserv didn't exist at the time. One of the issues was how to force the connection to go through the gateway. That being said, I would agree with you that there are probably ways to set-up individual SVCs based on some lower-level protocols as you mentioned. The H.245 method has the advantage of being very precise on what type of connection will be required at the SVC level. It does, however, as you note, have the disadvantage that the gateway has to maintain a substantial amount of software (the H.323 stack). As such, it would be a relatively complex device. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Apr 27 19:14:06 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02419 for ; Tue, 27 Apr 1999 19:14:05 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5E7CB52B7; Tue, 27 Apr 1999 19:09:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id ADFE752C1; Tue, 27 Apr 1999 19:09:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990427230803.6554.rocketmail@web105.yahoomail.com> Date: Tue, 27 Apr 1999 16:08:02 -0700 (PDT) From: Tom Gray Subject: Re: Measurement and testing parameter To: Henri Setiawan , IPTEL IETF Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk MOS is a subjective measurement of speech quality. It will be assessed for all sorts of network conditions. For the PSTN network, the most significant impairments found were loss, noise and echo so MOS is set for them. Other impairments have only an almost negligible effect compared to the big 3. Jitter is accomodated by delay so I would assume that it would fall under that parameter. There would probably have to be measurements to understand the effects of other network and codec impairments as well. After that is understood, relationships can be established so that thre can be a repeatable predidctions which will translate between network conditions and human perceived quality. --- Henri Setiawan wrote: > Dear Tom, > > Thank you for your respon regarding my question on > measurement and testing > parameter, on my understanding tha MOS is not the > only parameter to test > VoIP products. So, what do you think about the other > parameter ? Like delay, > jitter, Codec or others QoS parameter ? According to > you if we are only the > user, what we must aware on this technology ? > Testing the products one by > one or just waiting until the technology is mature ? > > By the way what do you think about using VoIP as > asubstitute for to date > exchange ? Do you have any concept on this ? > > Thanks > > Henri S > > ----- Original Message ----- > From: Tom Gray > To: 'Tom Gray' ; 'Henri > Setiawan' > ; IPTEL IETF Mailing List > > Sent: Friday, April 16, 1999 2324 > Subject: RE: Measurement and testing parameter > > > > > > > > It should be remembered that MOS is based on the. > subjective opinions > > of real people about the quality of a voice > connection. It is therefore > > based on their expectations of the service. With > experience these > > expectations tend to rise and the expectations of > the performance of > > teh PSTN network have risen over the years making > MOS more stringent as > > time goes by. > > > > An MOS for IP tlephony needs to be developed to > coincde with the > > expecations of the people who use it and the > decision makers who will > > buy it. It is likely that these people, given IP > telephony's other > > advantages, will not expect or require the same > level of service from > > IPTel as the PSTN. Direct use of a PSTN MOS is > probably not predictive > > or useful. > > > > Tom Gray > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at > http://mail.yahoo.com > > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Apr 29 14:02:47 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26795 for ; Thu, 29 Apr 1999 14:02:46 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5BF1A52C1; Thu, 29 Apr 1999 13:55:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BB74352C3; Thu, 29 Apr 1999 13:55:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.32.19990429134554.0088f100@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 29 Apr 1999 13:45:55 -0400 To: Jonathan Rosenberg From: Matt Squire Subject: Re: Evaluation of Gateway Location proposals Cc: IPTEL IETF Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > >2. Matt raised numerous transport issues (TCP or not TCP). I think its >fair to say we want to avoid designing a new transport protocol. There >is work underway elsewhere (sigtran and slums) to do this, which we can >leverage. It would seem to me that if something new is needed, this >would also be independent of whether the protocol baseline is BGP or >SCSP, since presumably one could use this new transport protocol with >either. > I certainly agree that we don't want a new transport protocol. But well short of designing a new transport is to design reliability into our application protocol (ie with acks, timeouts, re-transmissions, etc), just like most other application protocols. >3. To me, the MAIN differences between a BGP based approach and SCSP >based approach are: > a. how the data is synchronized between peers > b. the intra-domain topology > >I think we are clear on (b), so (a) is the issue to explore. Hussein had >made reference to a 2-stage exchange only being needed with BGP, while >its three with SCSP. These are the kind of differences I think we need >to explore here. I'd invite both authors to comment on the differences >in how the data is exchanged and updated between peers. Lets stick with >inter-domain for the moment... > Here's a brief synopsis of the data exchanges for each alternative. In both cases, the exchanges are just peer-to-peer. BGP *** BGP1) OPEN. OPEN messages are exchanged to bring the link up. Basically, two peers connect and send an open message to the other. A peer either acks the OPEN with a KEEP-ALIVE, or nacks the OPEN with a NOTIFICATION. When your OPEN gets ack'd, the peer connection is considered to be established (ie have bi-directional connectivity). BGP can also perform version negotiation and capabilities exchanges with the OPEN messages. BGP2) UPDATE. Once a peer connection is established (via ack'd OPENs), BGP peers exchange UPDATE messages. UPDATE messages are the messages that contain the routing information. Each UPDATE message may contain a number of withdrawn routes and a single feasible route. A withdrawn route is a route that should be removed from the peer's RIB-IN. A withdrawn route is defined by a address/prefix-length. A feasible route is defined as the NLRI (network layer reachability information, ie a list of address/prefix-length combinations) and its attributes. A key mandatory attribute is the NEXT-HOP attribute which gives the next-hop for the NLRI. Basically, you send an UPDATE for each possible NEXT-HOP in your routing database. KEEP-ALIVE messages are periodically going in the background to ensure that the link is up. BGP UPDATE and NOTIFICATION messages are not acknowledged as TCP acknowledgment is considered sufficient. SCSP **** SCSP1) Hello. Peers exchange Hello messages to ensure bi-directional connectivity between peers. This is equivalent to the BGP OPEN exchanges but without anything like version negotiation or capabilities exchange. Hello messages are also periodically exchanged in the background to ensure the link us still up. SCSP2) Cache Aligment. SCSP distinguishes between the state where two peers have had their databases synchronized and when they have not. When a peer connection first comes up (via Hello), the peers enter the Cache Alignment phase where the entire databases must be exchanged. First, there is a negotiation to determine who is the master and slave of the peering relationship. Next, the peers exchange summary records with each other, where a summary record is a short-version of the record - enough to identify it, but doesn't have the real data. This phase has no parallel in BGP. SCSP3) Cache State Update. A server maintiains a list of the records that it needs to get from its peer (the summary records in the previous phase). A server requests these records via a Solicit message (ie I need the full record for these summary records). The response to the the request is a Update Request message containing some/all of the records. A server continues to send further Solicit messages for records that it has not yet received. A server ack's that the records have been received with an Update Reply containing the summaries of recieved records. The Update Request messages are similar to the UPDATE messages of BGP. Acknowledgements in SCSP are done per-record (ie requests for a record are acknowledged by sending the record, record transmissions are acknowledged by sending a record summary in an Update Reply). SOME DIFFERENCES **************** I think Hussein's "2 vs 3" stages are identified above. SCSP has the added stage of Cache Alignment where database summaries are exchanged. BGP uses TCP, SCSP uses X (pick your transport). BGP exchanges and message formats are certainly more efficient, SCSP more generic. In the peer-to-peer case (ie inter-domain), some SCSP header fields are redundant (example: reciever and sender ID). SCSP does per-record acks and requests, which is flexible, but can be a pain in the ass and inefficient. BGP UPDATE/NOTIFICATION messages are unacknowledged and assume TCP provides reliability for the application. SCSP Update Requests can contain many records. BGP UPDATEs contain a single route (maybe multiple withdrawn routes). SCSP bases record identification on record summaries (source identifier, cache 'key' for record), so to replace a record you keeep the record summary and replace the data contents. BGP identifies records based on the contents (ie NLRI), so the data content is examined to determine new vs replacement. BGP includes version negotiation and capabilities exchange in the peering session establishment. SCSP has no such concept, the function would have to be included in the application above SCSP. Both use a similar keep-alive mechanism to determine peer status. SOME COMMENTARY *************** My personal view is that TCP is not enough for reliable application communications. I haven't heard anyone else argue for or against this position, so I'll stick with it. In order to get application reliability from a lower layer, you need a transport that either maintains the data or one that gives the application control over the acks. SLUMS is a potential transport that seems to take the latter approach. From the SLUMS BOF announcement, one of the in-scope requirements is - ability for application to indicate "a reply is coming" versus "no more coming now, go ahead and ack, don't delay" So SLUMS recognizes that apps may need to have input into the ack timing. I don't know enough about sigtran yet to say anything. Another alternative is that we put reliability into GLP so that messages (or records) get ack'd, retransmitted, timed-out, etc. This is the direction most other protocols have gone, and is as viable a solution as anything else. If we go this way, then we most likely need a "GLP Route Reflector" spec, etc, to parallel BGP. I don't think we can just say "we want to use that attribute/feature of that protocol in a similar way." The fact that we're an incompatible protocol to BGP means that any features that we want from BGP have to be recreated in a spec(s) for GLP. This may turn out to be mostly copying, or it may require some technical changes to the underlying operation. I suggested SCSP because it seemed to solve our transport needs. I wouldn't argue that SCSP is a simple protocol. We could build a reliable protocol that is more efficient and less complicated than SCSP. If SCSP gets used for more things in the future, then the costs of its implementation get leveraged as time passes. I have no idea whether that will or will not come to be. It certainly has limited applications now. So SCSP may be an ugly shoe, but it looked like it fit. I don't know whether the cost/complexity of being one of the earlier applications of SCSP is worth while. I thought it might be. I might have similar concerns about SLUMS after it gets defined. My crystal ball is a wee bit fuzzy at the moment. But that's enough out of me. - Matt --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 30 07:57:24 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21751 for ; Fri, 30 Apr 1999 07:57:24 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DF40752C5; Fri, 30 Apr 1999 06:51:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5261052C6; Fri, 30 Apr 1999 06:51:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: Jose Costa Requena Message-Id: <19990430134949jose@tct.hut.fi@default> Date: Fri Apr 30 13:49:49 1999 Content-Type: text/plain To: msquire@nortelnetworks.com Subject: Re: Evaluation of Gateway Location proposals Cc: iptel@lists.research.bell-labs.com X-Mailer: Pronto E-Mail [ver 4.0.2.6] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I just want to make some comments about the SCSP, because I have implemented it for distributed database synchronization. The SCSP has generic messages format that could seems inefficient but in this way it can be used for many applications. There are some header fields that seem redundant like the receiver and sender ID in the Mandatory Common part. From the implementation point of view it is useful when we have to choose the right Finite State Machine (FSM) that has to attend the DCS from which we have received that message. Thus checking the Sender ID we select the FSM that is implemented as an idividual object and inside the FSM we can check if the Receiver ID belongs to the DCS list that has the FSM to know if the packet is from one server in the SG. >SCSP does per-record acks and requests, which is flexible, but can be a >pain in the ass and inefficient. BGP UPDATE/NOTIFICATION messages are >unacknowledged and assume TCP provides reliability for the application. That's right, the SCSP does a little excess of message transactions to reach a consistent state in the database. A good alternative is to use a TCP connection at the beginning just to check if the connectivity is bidirectional or not. Thus, when the Hello Finite machine (HFSM) transits to the waiting state we use UDP for the rest of transactions. The unreliability of the UDP is corrected with the excess of acks and requests. Regarding the 2-stage exchange only being needed with BGP. In the SCSP we have 3-stage, but in Cache Alignment that is the other stage that the SCSP performs there is performed an initially information alignment.It could be inefficient, but in that stage each peer exchange only the summaries of the total data, in this way the next stage knows exactly the records that are needed to be updated. Those summaries are stored in the CRL instead of allocating the total amount of information. This feature is more efficient in the case that the records are quite big, but I agree that it will be inefficient in the case that the summary is comparable to the total record that must be updated. I hope that I have clarify some details that I have seen from the implementor point of view. Best Regards. Jose Helsinki University of Technology Laboratory of Telecommunications Technology Jose Costa Requena Research Scientist Room: SG 227B Tel: + 358 9 451 2475 email(internet): jose@tct.hut.fi --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 30 14:33:27 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09716 for ; Fri, 30 Apr 1999 14:33:26 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id F10E752C6; Fri, 30 Apr 1999 14:27:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5C65052C7; Fri, 30 Apr 1999 14:27:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <01BE934F.B76C9A80.amir@radvision.rad.co.il> From: Ami Amir To: "'Matt Squire'" , Jonathan Rosenberg Cc: IPTEL IETF Mailing List Subject: RE: Evaluation of Gateway Location proposals Date: Fri, 30 Apr 1999 19:59:37 +0300 Organization: RADVision X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi I am definitely NOT an expert - but one thing that should be kept in mind - the need to provide fault tollerance and redundancy. One cannot deploy a functional public phone system that deos not provide for redundancy at alkost every level. Ami -----Original Message----- From: Matt Squire [SMTP:msquire@NORTELNETWORKS.COM] Sent: Thursday, April 29, 1999 8:46 PM To: Jonathan Rosenberg Cc: IPTEL IETF Mailing List Subject: Re: Evaluation of Gateway Location proposals > >2. Matt raised numerous transport issues (TCP or not TCP). I think its >fair to say we want to avoid designing a new transport protocol. There >is work underway elsewhere (sigtran and slums) to do this, which we can >leverage. It would seem to me that if something new is needed, this >would also be independent of whether the protocol baseline is BGP or >SCSP, since presumably one could use this new transport protocol with >either. > I certainly agree that we don't want a new transport protocol. But well short of designing a new transport is to design reliability into our application protocol (ie with acks, timeouts, re-transmissions, etc), just like most other application protocols. >3. To me, the MAIN differences between a BGP based approach and SCSP >based approach are: > a. how the data is synchronized between peers > b. the intra-domain topology > >I think we are clear on (b), so (a) is the issue to explore. Hussein had >made reference to a 2-stage exchange only being needed with BGP, while >its three with SCSP. These are the kind of differences I think we need >to explore here. I'd invite both authors to comment on the differences >in how the data is exchanged and updated between peers. Lets stick with >inter-domain for the moment... > Here's a brief synopsis of the data exchanges for each alternative. In both cases, the exchanges are just peer-to-peer. BGP *** BGP1) OPEN. OPEN messages are exchanged to bring the link up. Basically, two peers connect and send an open message to the other. A peer either acks the OPEN with a KEEP-ALIVE, or nacks the OPEN with a NOTIFICATION. When your OPEN gets ack'd, the peer connection is considered to be established (ie have bi-directional connectivity). BGP can also perform version negotiation and capabilities exchanges with the OPEN messages. BGP2) UPDATE. Once a peer connection is established (via ack'd OPENs), BGP peers exchange UPDATE messages. UPDATE messages are the messages that contain the routing information. Each UPDATE message may contain a number of withdrawn routes and a single feasible route. A withdrawn route is a route that should be removed from the peer's RIB-IN. A withdrawn route is defined by a address/prefix-length. A feasible route is defined as the NLRI (network layer reachability information, ie a list of address/prefix-length combinations) and its attributes. A key mandatory attribute is the NEXT-HOP attribute which gives the next-hop for the NLRI. Basically, you send an UPDATE for each possible NEXT-HOP in your routing database. KEEP-ALIVE messages are periodically going in the background to ensure that the link is up. BGP UPDATE and NOTIFICATION messages are not acknowledged as TCP acknowledgment is considered sufficient. SCSP **** SCSP1) Hello. Peers exchange Hello messages to ensure bi-directional connectivity between peers. This is equivalent to the BGP OPEN exchanges but without anything like version negotiation or capabilities exchange. Hello messages are also periodically exchanged in the background to ensure the link us still up. SCSP2) Cache Aligment. SCSP distinguishes between the state where two peers have had their databases synchronized and when they have not. When a peer connection first comes up (via Hello), the peers enter the Cache Alignment phase where the entire databases must be exchanged. First, there is a negotiation to determine who is the master and slave of the peering relationship. Next, the peers exchange summary records with each other, where a summary record is a short-version of the record - enough to identify it, but doesn't have the real data. This phase has no parallel in BGP. SCSP3) Cache State Update. A server maintiains a list of the records that it needs to get from its peer (the summary records in the previous phase). A server requests these records via a Solicit message (ie I need the full record for these summary records). The response to the the request is a Update Request message containing some/all of the records. A server continues to send further Solicit messages for records that it has not yet received. A server ack's that the records have been received with an Update Reply containing the summaries of recieved records. The Update Request messages are similar to the UPDATE messages of BGP. Acknowledgements in SCSP are done per-record (ie requests for a record are acknowledged by sending the record, record transmissions are acknowledged by sending a record summary in an Update Reply). SOME DIFFERENCES **************** I think Hussein's "2 vs 3" stages are identified above. SCSP has the added stage of Cache Alignment where database summaries are exchanged. BGP uses TCP, SCSP uses X (pick your transport). BGP exchanges and message formats are certainly more efficient, SCSP more generic. In the peer-to-peer case (ie inter-domain), some SCSP header fields are redundant (example: reciever and sender ID). SCSP does per-record acks and requests, which is flexible, but can be a pain in the ass and inefficient. BGP UPDATE/NOTIFICATION messages are unacknowledged and assume TCP provides reliability for the application. SCSP Update Requests can contain many records. BGP UPDATEs contain a single route (maybe multiple withdrawn routes). SCSP bases record identification on record summaries (source identifier, cache 'key' for record), so to replace a record you keeep the record summary and replace the data contents. BGP identifies records based on the contents (ie NLRI), so the data content is examined to determine new vs replacement. BGP includes version negotiation and capabilities exchange in the peering session establishment. SCSP has no such concept, the function would have to be included in the application above SCSP. Both use a similar keep-alive mechanism to determine peer status. SOME COMMENTARY *************** My personal view is that TCP is not enough for reliable application communications. I haven't heard anyone else argue for or against this position, so I'll stick with it. In order to get application reliability from a lower layer, you need a transport that either maintains the data or one that gives the application control over the acks. SLUMS is a potential transport that seems to take the latter approach. From the SLUMS BOF announcement, one of the in-scope requirements is - ability for application to indicate "a reply is coming" versus "no more coming now, go ahead and ack, don't delay" So SLUMS recognizes that apps may need to have input into the ack timing. I don't know enough about sigtran yet to say anything. Another alternative is that we put reliability into GLP so that messages (or records) get ack'd, retransmitted, timed-out, etc. This is the direction most other protocols have gone, and is as viable a solution as anything else. If we go this way, then we most likely need a "GLP Route Reflector" spec, etc, to parallel BGP. I don't think we can just say "we want to use that attribute/feature of that protocol in a similar way." The fact that we're an incompatible protocol to BGP means that any features that we want from BGP have to be recreated in a spec(s) for GLP. This may turn out to be mostly copying, or it may require some technical changes to the underlying operation. I suggested SCSP because it seemed to solve our transport needs. I wouldn't argue that SCSP is a simple protocol. We could build a reliable protocol that is more efficient and less complicated than SCSP. If SCSP gets used for more things in the future, then the costs of its implementation get leveraged as time passes. I have no idea whether that will or will not come to be. It certainly has limited applications now. So SCSP may be an ugly shoe, but it looked like it fit. I don't know whether the cost/complexity of being one of the earlier applications of SCSP is worth while. I thought it might be. I might have similar concerns about SLUMS after it gets defined. My crystal ball is a wee bit fuzzy at the moment. But that's enough out of me. - Matt --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 30 14:43:59 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09947 for ; Fri, 30 Apr 1999 14:43:58 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 77A0352C7; Fri, 30 Apr 1999 14:35:26 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C15FA52CB; Fri, 30 Apr 1999 14:35:25 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <01BE9350.A07D8540.amir@radvision.rad.co.il> From: Ami Amir To: "'Matt Squire'" , Jonathan Rosenberg Cc: IPTEL IETF Mailing List Subject: RE: Evaluation of Gateway Location proposals Date: Fri, 30 Apr 1999 19:59:37 +0300 Organization: RADVision X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi I am definitely NOT an expert - but one thing that should be kept in mind - the need to provide fault tollerance and redundancy. One cannot deploy a functional public phone system that deos not provide for redundancy at alkost every level. Ami -----Original Message----- From: Matt Squire [SMTP:msquire@NORTELNETWORKS.COM] Sent: Thursday, April 29, 1999 8:46 PM To: Jonathan Rosenberg Cc: IPTEL IETF Mailing List Subject: Re: Evaluation of Gateway Location proposals > >2. Matt raised numerous transport issues (TCP or not TCP). I think its >fair to say we want to avoid designing a new transport protocol. There >is work underway elsewhere (sigtran and slums) to do this, which we can >leverage. It would seem to me that if something new is needed, this >would also be independent of whether the protocol baseline is BGP or >SCSP, since presumably one could use this new transport protocol with >either. > I certainly agree that we don't want a new transport protocol. But well short of designing a new transport is to design reliability into our application protocol (ie with acks, timeouts, re-transmissions, etc), just like most other application protocols. >3. To me, the MAIN differences between a BGP based approach and SCSP >based approach are: > a. how the data is synchronized between peers > b. the intra-domain topology > >I think we are clear on (b), so (a) is the issue to explore. Hussein had >made reference to a 2-stage exchange only being needed with BGP, while >its three with SCSP. These are the kind of differences I think we need >to explore here. I'd invite both authors to comment on the differences >in how the data is exchanged and updated between peers. Lets stick with >inter-domain for the moment... > Here's a brief synopsis of the data exchanges for each alternative. In both cases, the exchanges are just peer-to-peer. BGP *** BGP1) OPEN. OPEN messages are exchanged to bring the link up. Basically, two peers connect and send an open message to the other. A peer either acks the OPEN with a KEEP-ALIVE, or nacks the OPEN with a NOTIFICATION. When your OPEN gets ack'd, the peer connection is considered to be established (ie have bi-directional connectivity). BGP can also perform version negotiation and capabilities exchanges with the OPEN messages. BGP2) UPDATE. Once a peer connection is established (via ack'd OPENs), BGP peers exchange UPDATE messages. UPDATE messages are the messages that contain the routing information. Each UPDATE message may contain a number of withdrawn routes and a single feasible route. A withdrawn route is a route that should be removed from the peer's RIB-IN. A withdrawn route is defined by a address/prefix-length. A feasible route is defined as the NLRI (network layer reachability information, ie a list of address/prefix-length combinations) and its attributes. A key mandatory attribute is the NEXT-HOP attribute which gives the next-hop for the NLRI. Basically, you send an UPDATE for each possible NEXT-HOP in your routing database. KEEP-ALIVE messages are periodically going in the background to ensure that the link is up. BGP UPDATE and NOTIFICATION messages are not acknowledged as TCP acknowledgment is considered sufficient. SCSP **** SCSP1) Hello. Peers exchange Hello messages to ensure bi-directional connectivity between peers. This is equivalent to the BGP OPEN exchanges but without anything like version negotiation or capabilities exchange. Hello messages are also periodically exchanged in the background to ensure the link us still up. SCSP2) Cache Aligment. SCSP distinguishes between the state where two peers have had their databases synchronized and when they have not. When a peer connection first comes up (via Hello), the peers enter the Cache Alignment phase where the entire databases must be exchanged. First, there is a negotiation to determine who is the master and slave of the peering relationship. Next, the peers exchange summary records with each other, where a summary record is a short-version of the record - enough to identify it, but doesn't have the real data. This phase has no parallel in BGP. SCSP3) Cache State Update. A server maintiains a list of the records that it needs to get from its peer (the summary records in the previous phase). A server requests these records via a Solicit message (ie I need the full record for these summary records). The response to the the request is a Update Request message containing some/all of the records. A server continues to send further Solicit messages for records that it has not yet received. A server ack's that the records have been received with an Update Reply containing the summaries of recieved records. The Update Request messages are similar to the UPDATE messages of BGP. Acknowledgements in SCSP are done per-record (ie requests for a record are acknowledged by sending the record, record transmissions are acknowledged by sending a record summary in an Update Reply). SOME DIFFERENCES **************** I think Hussein's "2 vs 3" stages are identified above. SCSP has the added stage of Cache Alignment where database summaries are exchanged. BGP uses TCP, SCSP uses X (pick your transport). BGP exchanges and message formats are certainly more efficient, SCSP more generic. In the peer-to-peer case (ie inter-domain), some SCSP header fields are redundant (example: reciever and sender ID). SCSP does per-record acks and requests, which is flexible, but can be a pain in the ass and inefficient. BGP UPDATE/NOTIFICATION messages are unacknowledged and assume TCP provides reliability for the application. SCSP Update Requests can contain many records. BGP UPDATEs contain a single route (maybe multiple withdrawn routes). SCSP bases record identification on record summaries (source identifier, cache 'key' for record), so to replace a record you keeep the record summary and replace the data contents. BGP identifies records based on the contents (ie NLRI), so the data content is examined to determine new vs replacement. BGP includes version negotiation and capabilities exchange in the peering session establishment. SCSP has no such concept, the function would have to be included in the application above SCSP. Both use a similar keep-alive mechanism to determine peer status. SOME COMMENTARY *************** My personal view is that TCP is not enough for reliable application communications. I haven't heard anyone else argue for or against this position, so I'll stick with it. In order to get application reliability from a lower layer, you need a transport that either maintains the data or one that gives the application control over the acks. SLUMS is a potential transport that seems to take the latter approach. From the SLUMS BOF announcement, one of the in-scope requirements is - ability for application to indicate "a reply is coming" versus "no more coming now, go ahead and ack, don't delay" So SLUMS recognizes that apps may need to have input into the ack timing. I don't know enough about sigtran yet to say anything. Another alternative is that we put reliability into GLP so that messages (or records) get ack'd, retransmitted, timed-out, etc. This is the direction most other protocols have gone, and is as viable a solution as anything else. If we go this way, then we most likely need a "GLP Route Reflector" spec, etc, to parallel BGP. I don't think we can just say "we want to use that attribute/feature of that protocol in a similar way." The fact that we're an incompatible protocol to BGP means that any features that we want from BGP have to be recreated in a spec(s) for GLP. This may turn out to be mostly copying, or it may require some technical changes to the underlying operation. I suggested SCSP because it seemed to solve our transport needs. I wouldn't argue that SCSP is a simple protocol. We could build a reliable protocol that is more efficient and less complicated than SCSP. If SCSP gets used for more things in the future, then the costs of its implementation get leveraged as time passes. I have no idea whether that will or will not come to be. It certainly has limited applications now. So SCSP may be an ugly shoe, but it looked like it fit. I don't know whether the cost/complexity of being one of the earlier applications of SCSP is worth while. I thought it might be. I might have similar concerns about SLUMS after it gets defined. My crystal ball is a wee bit fuzzy at the moment. But that's enough out of me. - Matt --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Apr 30 15:01:55 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10302 for ; Fri, 30 Apr 1999 15:01:54 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 098AA52C8; Fri, 30 Apr 1999 14:57:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6203952CA; Fri, 30 Apr 1999 14:57:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <05b201be933a$fce9f590$511875c2@inescn.pt> From: "Carlos Alberto Rodrigues e Silva" To: , "IP Telephony" Subject: V/IP card Date: Fri, 30 Apr 1999 19:55:15 +0100 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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have a Voice Fax Gateway card to test, Micom V/IP CLEAR VOICE V/IP 2002 ISA FXE, and would like to know if there is any kind of developments in Linux. Thanks in advance. Best regards, Carlos --------- This message came from the IETF IPTEL Working Group Mailing List.