From mailman-owner@lists.bell-labs.com Thu Jun 1 05:26:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17962 for ; Thu, 1 Jun 2000 05:26:17 -0400 (EDT) From: mailman-owner@lists.bell-labs.com Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C820044AE3 for ; Thu, 1 Jun 2000 05:08:28 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: iptel-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: Message-Id: <20000601090828.C820044AE3@lists.bell-labs.com> Date: Thu, 1 Jun 2000 05:08:28 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com Gfcn http://lists.bell-labs.com/mailman/options/iptel/iptel-archive@lists.ietf.org From iptel-admin@lists.bell-labs.com Thu Jun 1 15:52:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02107 for ; Thu, 1 Jun 2000 15:52:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6184D44395; Thu, 1 Jun 2000 15:43:03 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 7442D44337 for ; Wed, 31 May 2000 18:36:47 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 31 18:44:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id AB3E644344; Wed, 31 May 2000 18:31:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 82B3F44341 for ; Wed, 31 May 2000 18:31:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9769352C4; Wed, 31 May 2000 18:31:28 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B609F52AB for ; Wed, 31 May 2000 18:31:25 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 31 18:30:38 EDT 2000 Received: from boreas.isi.edu ([128.9.160.161]) by dusty; Wed May 31 18:30:36 EDT 2000 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id PAA26407; Wed, 31 May 2000 15:30:20 -0700 (PDT) Message-Id: <200005312230.PAA26407@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, iptel@lists.research.bell-labs.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 31 May 2000 15:30:20 -0700 From: RFC Editor Subject: [IPTEL] RFC 2824 on CPL-F Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2824 Title: Call Processing Language Framework and Requirements Author(s): J. Lennox, H. Schulzrinne Status: Informational Date: May 2000 Mailbox: lennox@cs.columbia.edu, schulzrinne@cs.columbia.edu Pages: 25 Characters: 58711 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-iptel-cpl-framework-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2824.txt A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This document describes an architectural framework for such a mechanism, which we call a call processing language. It also outlines requirements for such a language. This document is a product of the IP Telephony Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000531152830.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2824 --OtherAccess Content-Type: Message/External-body; name="rfc2824.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000531152830.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 1 15:56:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02214 for ; Thu, 1 Jun 2000 15:56:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B32FF443A3; Thu, 1 Jun 2000 15:43:27 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 96AD04438A for ; Thu, 1 Jun 2000 06:22:04 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18406; Thu, 1 Jun 2000 06:31:21 -0400 (EDT) Message-Id: <200006011031.GAA18406@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Thu, 01 Jun 2000 06:31:20 -0400 Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : Telephony Routing over IP (TRIP) Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-trip-02.txt Pages : 71 Date : 31-May-00 This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIPÆs operation is independent of any signaling protocol,hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-trip-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-trip-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000531085237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-trip-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-trip-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000531085237.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 2 09:36:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02085 for ; Fri, 2 Jun 2000 09:36:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CA7844337; Fri, 2 Jun 2000 09:25:51 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 0CFC844336 for ; Fri, 2 Jun 2000 08:11:22 -0400 (EDT) Received: from 213.108.3.159 by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 2 Jun 2000 13:20:30 +0100 Message-ID: <002e01bfcc8c$ff195040$9f036cd5@kallisto> From: Dimitris Terzis To: iptel Date: Fri, 2 Jun 2000 13:20:40 +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 Subject: [IPTEL] TRIP questions Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi there... I am trying to figure out how the establishment of the end-to-end paths for signalling and media will happen, in an IP Telephony network using TRIP for call routing. Given the generalised definition of a VoIP gateway, as provided by MEGACO (RFC 2805 etc.), the Signalling Gateway, the Media Gateway and the Media Gateway Controller can be completely independent components, even substantially spaced apart. Suppose that I run TRIP. Then, at each hop, the relative LS can give me the NextHopServer, which (presumably) is the signalling server of the protocol defining this route (destination), apart from the first hop, where the enquiry may come from the user terminal (e.g., a SIP UAC). This way, signalling messages can reach the other end of the path, which can be several hops away from the caller. I am not clear as to what the implied behaviour, AFTER the acceptance of the call at the signalling level, will be. How is the media path determined? Not by TRIP, of course, but is TRIP's position that "we just assist in finding the signalling path, then let the signalling servers deal with the establishment of the media path"? Also, what is the anticipated number of gateways participating in a GSTN-to-IP call, for the TRIP routing model? Is it always one per different network cloud traversed ("The selection of an egress gateway for a telephony call, traversing an IP network towards an ultimate destination in the PSTN" (and vice versa), as mentioned in Section 3 (Introduction))? Finally, at the start of Section 3, the text reads "TRIP can be used to exchange attributes necessary to enforce policies and to select call routes based on path or gateway characteristics." Is it at all envisaged that the advertised (signalling) routes will/could also contain media-realted attributes (e.g., codecs) of a gateway (for example, using the Capability Information parameter)? Thanks for the attention. Regards, Dimitris --------------------------------------------------------------- Dimitris Terzis PhD Candidate - Department of Computer Science, UCL E-Mail: D.Terzis@cs.ucl.ac.uk URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/ --------------------------------------------------------------- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 2 12:11:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06190 for ; Fri, 2 Jun 2000 12:11:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DEBFE443BC; Fri, 2 Jun 2000 12:01:15 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EB75B4438F for ; Fri, 2 Jun 2000 12:01:12 -0400 (EDT) Received: from dynamicsoft.com (1Cust93.tnt2.freehold.nj.da.uu.net [63.17.114.93]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA12912; Fri, 2 Jun 2000 12:11:55 -0400 (EDT) Message-ID: <3937DC81.1CB9748A@dynamicsoft.com> Date: Fri, 02 Jun 2000 12:10:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dimitris Terzis Cc: iptel Subject: Re: [IPTEL] TRIP questions References: <002e01bfcc8c$ff195040$9f036cd5@kallisto> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dimitris Terzis wrote: > > Hi there... > > I am trying to figure out how the establishment of the end-to-end paths > for signalling and media will happen, in an IP Telephony network using > TRIP for call routing. > > Given the generalised definition of a VoIP gateway, as provided by > MEGACO (RFC 2805 etc.), the Signalling Gateway, the Media Gateway > and the Media Gateway Controller can be completely independent > components, even substantially spaced apart. > > Suppose that I run TRIP. Then, at each hop, the relative LS can give me the > NextHopServer, which (presumably) is the signalling server of the protocol > defining this route (destination), apart from the first hop, where the > enquiry may come from the user terminal (e.g., a SIP UAC). This way, > signalling messages can reach the other end of the path, which can be > several hops away from the caller. > > I am not clear as to what the implied behaviour, AFTER the > acceptance of the call at the signalling level, will be. How is the media > path > determined? The purpose of the signaling messages is to exchange, between end systems (PCs, softphones, softswitches, or whatever), the IP addresses to use for media. Thus, "routing" of media itself is handled directly by the IP network. > Not by TRIP, of course, but is TRIP's position that "we just > assist in finding the signalling path, then let the signalling servers deal > with > the establishment of the media path"? Signaling servers have no role in the establishment of the media path, nor does TRIP. > > Also, what is the anticipated number of gateways participating in a > GSTN-to-IP call, for the TRIP routing model? Is it always one per different > network cloud traversed ("The selection of an egress gateway for a telephony > call, traversing an IP network towards an ultimate destination in the PSTN" > (and vice versa), as mentioned in Section 3 (Introduction))? TRIP would not help in a GSTN to IP call, rather in an IP to GSTN call. How many gateways in such a scenario? Not sure what that means. Clearly only one gateway terminates the call. The number of gateways that can be propagated through TRIP itself is huge, and thats the point for having TRIP in the first place. > > Finally, at the start of Section 3, the text reads "TRIP can be used to > exchange attributes necessary to enforce policies and to select call routes > based on path or gateway characteristics." Is it at all envisaged that the > advertised (signalling) routes will/could also contain media-realted > attributes (e.g., codecs) of a gateway (for example, using the > Capability Information parameter)? We discussed this. It would not be part of the capability information in TRIP itself, as that refers to TRIP capabilities negotiation between peers. The problem with such attributes is that they are not aggregatable, and so we decided to leave them out of TRIP for now. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 2 17:51:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15639 for ; Fri, 2 Jun 2000 17:51:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A477443C5; Fri, 2 Jun 2000 17:41:05 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 18B5344397 for ; Fri, 2 Jun 2000 10:41:53 -0400 (EDT) Received: by dnspri.npac.com; id JAA26730; Fri, 2 Jun 2000 09:51:20 -0500 (CDT) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma026618; Fri, 2 Jun 00 09:50:55 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Fri, 2 Jun 2000 09:50:32 -0500 Message-ID: From: James Yu To: "'jdrosen@dynamicsoft.com'" Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt Date: Fri, 2 Jun 2000 09:49:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Jonathan, By glancing through the document quickly, I did not find any text describing the nature/type of the phone numbers or number ranges mentioned in the TRIP document. For calls terminated to those countries that support number portability (NP), the server (in Internet) may have both the subscriber phone number and the network routing number (or routing number) after retrieving the NP information. How to retrieve the NP information is outside the scope of the TRIP discussion. For calls terminated to countries that do not support NP, the subscriber phone numbers are used as the network routing number for call routing. IMHO, the network routing number instead of the subscriber phone number should be used for call routing (e.g., TRIP table lookup) because the "network routing number" applies to both NP and non-NP environments. In the North America, the network routing numbers are called Location Routing Numbers (LRNs). They "look" like subscriber phone numbers (e.g., the same length) and can overlap with the subscriber phone numbers. In some European countries, special digit (e.g., A and B) are used to differentiate the network routing numbers from the subscriber phone numbers. Those network routing numbers may have shorter length than their national subscriber phone numbers and their values do not overlap with the subscriber phone numbers. The TRIP document should be specific about the nature/type of number, the network routing number, that is to be advertised. This is particularly important for the North American markets. So if a GW can reach a particular GSTN switch or network that is allocated a network routing number (every switch or network is allocated a network routing number in the NP environment). It can use the TRIP to broadcast its reachability to that switch or network. The network routing numbers for NP are usually national numbers. I assume that the number ranges broadcasted using TRIP are "international" numbers (e.g., with country code). If TRIP broadcasts the network routing numbers or the prefixes of the network routing numbers (e.g., the first six digits of the LRN is unique), the information in the TRIP tables will remain "static." There won't be many changes due to the changes to the network routing numbers used by the GSTN switches or networks. The likely changes would be from the GWs themselves because they may add or delete the GWs they can reach. If TRIP is used to broadcast reachability of subscriber phone numbers in the NP environment, the TRIP broadcast will propagate through various domains everytime there is a number porting event. For countries that have implmented NP and the network routing numbers overlap with the subscriber phone numbers, it is very important for TRIP to specify the nature/type of the numbers to be broadcasted. Otherwise, some may broadcast the network routing numbers and others may broadcast the subscriber phone numbers. James James Yu Principal Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue, NW, Suite 550 Washington, D.C. 20005 USA +1-202-533-2814 (B) +1-202-533-2976 (Fax) +1-202-256-1200 (Mobile) james.yu@neustar.com http://www.neustar.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 2 18:25:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16290 for ; Fri, 2 Jun 2000 18:25:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E4BEB443CE; Fri, 2 Jun 2000 18:16:06 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 3D7064433F for ; Fri, 2 Jun 2000 18:16:03 -0400 (EDT) Received: from 213.108.4.171 by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 2 Jun 2000 23:25:17 +0100 Message-ID: <002b01bfcce1$7cb35a60$b7036cd5@kallisto> From: Dimitris Terzis To: Jonathan Rosenberg Cc: iptel References: <002e01bfcc8c$ff195040$9f036cd5@kallisto> <3937DC81.1CB9748A@dynamicsoft.com> Subject: Re: [IPTEL] TRIP questions Date: Fri, 2 Jun 2000 23:25:38 +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: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, Thanks for your comments. I have a rather different model of operation in mind, which (on a second reading), I have to admit made what I was asking much less clear (mea culpa). So, I 'll try to give it another run... > The purpose of the signaling messages is to exchange, between end > systems (PCs, softphones, softswitches, or whatever), the IP addresses > to use for media. Thus, "routing" of media itself is handled directly by > the IP network. Of course, but what happens _above_ the network layer? Suppose that, for some reason, I want to have a _specific_ set of gateways in my media path during a call. Is there any way to build such a path with TRIP information? This rather gets closer to source routing... > > Not by TRIP, of course, but is TRIP's position that "we just > > assist in finding the signalling path, then let the signalling servers > > deal with the establishment of the media path"? > > Signaling servers have no role in the establishment of the media path, > nor does TRIP. I just mean that they will distribute the IP addresses for the media, as you point out above. As for the role of TRIP, please refer to my previous question. > TRIP would not help in a GSTN to IP call, rather in an IP to GSTN call. > How many gateways in such a scenario? Not sure what that means. Clearly > only one gateway terminates the call. The number of gateways that can be > propagated through TRIP itself is huge, and thats the point for having > TRIP in the first place. Of course only one gateway terminates the call, but would you completely rule out the possibility of needing more than one gateway on an end-to-end call path? Or a "pure IP" call, where the gateway would be needed for, say, media conversion only? (You can also see this as a special case of GSTN-to-IP, or GSTN-toIP-toIP if you prefer, although I did not mean any direction in the original message). > > Finally, at the start of Section 3, the text reads "TRIP can be used to > > exchange attributes necessary to enforce policies and to select call > > routes based on path or gateway characteristics." Is it at all envisaged > > that the advertised (signalling) routes will/could also contain media-realted > > attributes (e.g., codecs) of a gateway (for example, using the > > Capability Information parameter)? > > We discussed this. It would not be part of the capability information in > TRIP itself, as that refers to TRIP capabilities negotiation between > peers. The problem with such attributes is that they are not > aggregatable, and so we decided to leave them out of TRIP for now. Sure, and this philosophy is clearly mentioned throughout the TRIP spec. I was just trying to figure out whether we could find a way of deciding to include some gateway(s) in the media path, based on advertised capabilities (a source route maybe?) I am referring to the generalised generalised concept of a gateway here, where you would expect even the signalling servers to be part of a gateway (its MGC, to be exact)... Cheers, Dimitris --------------------------------------------------------------- Dimitris Terzis PhD Candidate - Department of Computer Science, UCL E-Mail: D.Terzis@cs.ucl.ac.uk URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/ --------------------------------------------------------------- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 2 19:12:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16820 for ; Fri, 2 Jun 2000 19:12:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8CCC7443E1; Fri, 2 Jun 2000 19:02:35 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by lists.bell-labs.com (Postfix) with ESMTP id 2500A443C5 for ; Fri, 2 Jun 2000 19:02:32 -0400 (EDT) Received: from cisco.com (dhcp-171-71-147-143.cisco.com [171.71.147.143]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA29034; Fri, 2 Jun 2000 16:11:56 -0700 (PDT) Message-ID: <39383EC3.37CC1B68@cisco.com> Date: Fri, 02 Jun 2000 16:09:55 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: Dimitris Terzis Cc: Jonathan Rosenberg , iptel Subject: Re: [IPTEL] TRIP questions References: <002e01bfcc8c$ff195040$9f036cd5@kallisto> <3937DC81.1CB9748A@dynamicsoft.com> <002b01bfcce1$7cb35a60$b7036cd5@kallisto> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dimitris Terzis wrote: > > Jonathan, > > Thanks for your comments. I have a rather different model of operation in > mind, which (on a second reading), I have to admit made what I was asking > much less clear (mea culpa). So, I 'll try to give it another run... > > > The purpose of the signaling messages is to exchange, between end > > systems (PCs, softphones, softswitches, or whatever), the IP addresses > > to use for media. Thus, "routing" of media itself is handled directly by > > the IP network. > > Of course, but what happens _above_ the network layer? Suppose that, for > some reason, I want to have a _specific_ set of gateways in my media path > during a call. Is there any way to build such a path with TRIP information? > This rather gets closer to source routing... Routing the media is outside the scope of TRIP, but the signaling servers involved in call setup can do source routing by manipulating the transport addresses of the media streams. > > > > Not by TRIP, of course, but is TRIP's position that "we just > > > assist in finding the signalling path, then let the signalling servers > > > deal with the establishment of the media path"? > > > > Signaling servers have no role in the establishment of the media path, > > nor does TRIP. We've discussed this before. In some cases, it is desirable to control the media path, and to insert media proxies along that path. For example, QoS and Accounting at intermediate domains. However, this is definitely outside the scope of TRIP. > > I just mean that they will distribute the IP addresses for the media, as you > point out above. As for the role of TRIP, please refer to my previous > question. > > > TRIP would not help in a GSTN to IP call, rather in an IP to GSTN call. > > How many gateways in such a scenario? Not sure what that means. Clearly > > only one gateway terminates the call. The number of gateways that can be > > propagated through TRIP itself is huge, and thats the point for having > > TRIP in the first place. > > Of course only one gateway terminates the call, but would you completely > rule out the possibility of needing more than one gateway on an end-to-end > call path? Or a "pure IP" call, where the gateway would be needed for, say, > media conversion only? (You can also see this as a special case of > GSTN-to-IP, or GSTN-toIP-toIP if you prefer, although I did not mean any > direction in the original message). A call with multiple intermediate signaling servers (signaling proxies) is possible, that's what TRIP is about. Having multiple media proxies along the media path is also possible, but outside the scope of TRIP. A pure IP call is also possible, if the IP destination has an E.164 number assigned to it, because E.164 is the only destination address family TRIP currently supports. Hussein > > > > Finally, at the start of Section 3, the text reads "TRIP can be used to > > > exchange attributes necessary to enforce policies and to select call > > > routes based on path or gateway characteristics." Is it at all envisaged > > > that the advertised (signalling) routes will/could also contain > media-realted > > > attributes (e.g., codecs) of a gateway (for example, using the > > > Capability Information parameter)? > > > > We discussed this. It would not be part of the capability information in > > TRIP itself, as that refers to TRIP capabilities negotiation between > > peers. The problem with such attributes is that they are not > > aggregatable, and so we decided to leave them out of TRIP for now. > > Sure, and this philosophy is clearly mentioned throughout the TRIP spec. > I was just trying to figure out whether we could find a way of deciding > to include some gateway(s) in the media path, based on advertised > capabilities (a source route maybe?) I am referring to the generalised > generalised concept of a gateway here, where you would expect even the > signalling servers to be part of a gateway (its MGC, to be exact)... > > Cheers, > > Dimitris > > --------------------------------------------------------------- > Dimitris Terzis > PhD Candidate - Department of Computer Science, UCL > E-Mail: D.Terzis@cs.ucl.ac.uk > URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/ > --------------------------------------------------------------- > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- 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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 2 20:51:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17889 for ; Fri, 2 Jun 2000 20:51:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 71BB3443F6; Fri, 2 Jun 2000 20:41:45 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by lists.bell-labs.com (Postfix) with ESMTP id 4F608443CA for ; Fri, 2 Jun 2000 20:41:42 -0400 (EDT) Received: from cisco.com (dhcp-171-71-147-143.cisco.com [171.71.147.143]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA12470; Fri, 2 Jun 2000 17:51:12 -0700 (PDT) Message-ID: <3938560F.64CABB1E@cisco.com> Date: Fri, 02 Jun 2000 17:49:19 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: James Yu Cc: "'jdrosen@dynamicsoft.com'" , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Yu wrote: > > Jonathan, > > By glancing through the document quickly, I did not find any text describing > the nature/type of the phone numbers or number ranges mentioned in the TRIP > document. For calls terminated to those countries that support number > portability (NP), the server (in Internet) may have both the subscriber > phone number and the network routing number (or routing number) after > retrieving the NP information. How to retrieve the NP information is > outside the scope of the TRIP discussion. For calls terminated to > countries that do not support NP, the subscriber phone numbers are used as > the network routing number for call routing. IMHO, the network routing > number instead of the subscriber phone number should be used for call > routing (e.g., TRIP table lookup) because the "network routing number" > applies to both NP and non-NP environments. From TRIP's perspective all numbers/prefixes it advertises are routing numbers, otherwise these numbers/prefixes should not have been injected into TRIP in first place. This has been stated clearly in Section 11 of the "Framework for Telephony Routing over IP" draft. It says: "Since TRIP is a routing protocol, the routes it propagates should be to routable numbers, not to names which are eventually translated to routable numbers." > > In the North America, the network routing numbers are called Location > Routing Numbers (LRNs). They "look" like subscriber phone numbers (e.g., > the same length) and can overlap with the subscriber phone numbers. In some > European countries, special digit (e.g., A and B) are used to differentiate > the network routing numbers from the subscriber phone numbers. Those I think TRIP should be extended advertising these European formats. Is this an extended form of E.164, or should it be a separate address family? > network routing numbers may have shorter length than their national > subscriber phone numbers and their values do not overlap with the subscriber > phone numbers. The TRIP document should be specific about the nature/type > of number, the network routing number, that is to be advertised. This is > particularly important for the North American markets. So if a GW can reach > a particular GSTN switch or network that is allocated a network routing > number (every switch or network is allocated a network routing number in the > NP environment). It can use the TRIP to broadcast its reachability to that > switch or network. > > The network routing numbers for NP are usually national numbers. I assume > that the number ranges broadcasted using TRIP are "international" numbers > (e.g., with country code). > Is there a reason that prevents expanding routing numbers to full E.164 numbers before injecting them into TRIP? Hussein > If TRIP broadcasts the network routing numbers or the prefixes of the > network routing numbers (e.g., the first six digits of the LRN is unique), > the information in the TRIP tables will remain "static." There won't be > many changes due to the changes to the network routing numbers used by the > GSTN switches or networks. The likely changes would be from the GWs > themselves because they may add or delete the GWs they can reach. > > If TRIP is used to broadcast reachability of subscriber phone numbers in the > NP environment, the TRIP broadcast will propagate through various domains > everytime there is a number porting event. For countries that have > implmented NP and the network routing numbers overlap with the subscriber > phone numbers, it is very important for TRIP to specify the nature/type of > the numbers to be broadcasted. Otherwise, some may broadcast the network > routing numbers and others may broadcast the subscriber phone numbers. > > James > > James Yu > Principal Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue, NW, > Suite 550 > Washington, D.C. 20005 > USA > +1-202-533-2814 (B) > +1-202-533-2976 (Fax) > +1-202-256-1200 (Mobile) > james.yu@neustar.com > http://www.neustar.com > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- 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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Jun 3 00:04:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21795 for ; Sat, 3 Jun 2000 00:04:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1ED1644402; Fri, 2 Jun 2000 23:54:39 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C64EA443CB for ; Fri, 2 Jun 2000 23:54:35 -0400 (EDT) Received: from dynamicsoft.com (1Cust93.tnt2.freehold.nj.da.uu.net [63.17.114.93]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00457; Sat, 3 Jun 2000 00:05:15 -0400 (EDT) Message-ID: <393883AC.3C7AEA6@dynamicsoft.com> Date: Sat, 03 Jun 2000 00:03:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dimitris Terzis Cc: iptel Subject: Re: [IPTEL] TRIP questions References: <002e01bfcc8c$ff195040$9f036cd5@kallisto> <3937DC81.1CB9748A@dynamicsoft.com> <002b01bfcce1$7cb35a60$b7036cd5@kallisto> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dimitris Terzis wrote: > > Jonathan, > > Thanks for your comments. I have a rather different model of operation in > mind, which (on a second reading), I have to admit made what I was asking > much less clear (mea culpa). So, I 'll try to give it another run... > > > The purpose of the signaling messages is to exchange, between end > > systems (PCs, softphones, softswitches, or whatever), the IP addresses > > to use for media. Thus, "routing" of media itself is handled directly by > > the IP network. > > Of course, but what happens _above_ the network layer? Suppose that, for > some reason, I want to have a _specific_ set of gateways in my media path > during a call. Is there any way to build such a path with TRIP information? > This rather gets closer to source routing... What do you mean by set of gateways? IP-PSTN gateways? The TRIP model is a call that begins in some entity with IP access (could be a gateway itself), terminates on one IP to PSTN gateway, and then ends within the PSTN. There is no provision for routing calls that are IP->PSTN->IP->PSTN->IP..... this is nearly impossible since it requires integration with PSTN routing. If you mean location servers - well, you could have them modify the signaling messages to force the media through them, as Hussein suggests. I still argue that in most cases this is a bad thing. > > TRIP would not help in a GSTN to IP call, rather in an IP to GSTN call. > > How many gateways in such a scenario? Not sure what that means. Clearly > > only one gateway terminates the call. The number of gateways that can be > > propagated through TRIP itself is huge, and thats the point for having > > TRIP in the first place. > > Of course only one gateway terminates the call, but would you completely > rule out the possibility of needing more than one gateway on an end-to-end > call path? Or a "pure IP" call, where the gateway would be needed for, say, > media conversion only? (You can also see this as a special case of > GSTN-to-IP, or GSTN-toIP-toIP if you prefer, although I did not mean any > direction in the original message). Then these are not gateways in the sense as defined by TRIP. Maybe you can explain the application you have in mind? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Jun 3 06:16:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05191 for ; Sat, 3 Jun 2000 06:16:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A359443A2; Sat, 3 Jun 2000 06:07:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 120C44438F for ; Sat, 3 Jun 2000 06:06:59 -0400 (EDT) Received: from 213.108.9.162 by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 3 Jun 2000 11:16:06 +0100 Message-ID: <001601bfcd44$ca7fb320$a2096cd5@kallisto> From: Dimitris Terzis To: Jonathan Rosenberg Cc: iptel References: <002e01bfcc8c$ff195040$9f036cd5@kallisto> <3937DC81.1CB9748A@dynamicsoft.com> <002b01bfcce1$7cb35a60$b7036cd5@kallisto> <393883AC.3C7AEA6@dynamicsoft.com> Subject: Re: [IPTEL] TRIP questions Date: Sat, 3 Jun 2000 11:15:14 +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: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > Of course, but what happens _above_ the network layer? Suppose that, for > > some reason, I want to have a _specific_ set of gateways in my media path > > during a call. Is there any way to build such a path with TRIP information? > > This rather gets closer to source routing... > > What do you mean by set of gateways? IP-PSTN gateways? More closer to MEGACO gateways (see also description at the end of this message). > The TRIP model is > a call that begins in some entity with IP access (could be a gateway > itself), terminates on one IP to PSTN gateway, and then ends within the > PSTN. Is therefore TRIP only "unidirectional"? We already could do the other way using phone numbers for terminals (which doesn't sound a bad idea at all to me), but also I don't see why an expansion of the supported advertised address families to IP would harm the protocol... > There is no provision for routing calls that are > IP->PSTN->IP->PSTN->IP..... this is nearly impossible since it requires > integration with PSTN routing. Absolutely... > If you mean location servers - well, you could have them modify the > signaling messages to force the media through them, as Hussein suggests. > I still argue that in most cases this is a bad thing. For Location Servers, I agree, if only because they 're not supposed to do that... I actually have in mind gateways, but more general than the ones we currently have in mind (see text a few paragraphs below). > > Of course only one gateway terminates the call, but would you completely > > rule out the possibility of needing more than one gateway on an end-to-end > > call path? Or a "pure IP" call, where the gateway would be needed for, say, > > media conversion only? (You can also see this as a special case of > > GSTN-to-IP, or GSTN-toIP-toIP if you prefer, although I did not mean any > > direction in the original message). > > Then these are not gateways in the sense as defined by TRIP. Maybe you > can explain the application you have in mind? Yes. I am thinking of a (perhaps theoretical) global IP Telephony Network, where terminals (either GSTN or IP) are reachable in any combination. Addressing is dual: There is one E.164 address per IP destination, and every GSTN number is reachable via a corresponding IP address (the one of its access gateway). The concept of a gateway also puzzles me. One good thing in the plain vanilla telephony network is that all the "gateways" (i.e., the switches) are integrated (or tightly coupled) devices, by contrast to IP, where, at the application layer, we have Location Servers (to use TRIP terminology - I prefer the expression "Call Routers"), Signalling Servers, Signalling Gateways (with varying opinions as to what they do), etc., etc., etc., let alone the multiplicity of devices at the network layer and below (which we can ignore, though). My opinion is that, if we are ever to see global IP Telephony (which I personally doubt), we need a more clear framework, at least for the core components of the network, which means, among other things, unifying all these devices according to their role. Now, it might not be conceivable making a combined LS + gateway (i.e, an IP Telephony corresponding of the GSTN switch), but at least we could do that about the gateways. Given the different types of signalling and media entities in an IP Telephony call, a unified gateway (a gateway framework , if you prefer) can only be perceived as an entity general enough to enclose all these entities in one "package". This should be generic enough as to allow us, with very little additional logic, to "mutate" it to anything from a single SIP Proxy to a full-blown network of multiple signalling and media components, advertised to the outside world as a unique entity. There is, of course, the concept of the MEGACO gateway, but this is so closely modelled after the H.323 one, that I am not absolutely convinced it is the answer (possibly with a bit more work on it). In the above (perhaps ideal) model, the type of terminals on either end of a connection is irrelevant and you might expect that, for a "long-distance" call, you will have _several_ gateways on the path, the same way it currently happens in GSTN. Of course, I realise that TRIP's model is much more specific (down to earth, if you like) than the one I describe (hence the double figure of "this is outside the scope of TRIP" comments I 've already got in this thread! :-), but the original intention of the message was to verify how much of this we could do with TRIP. I 've been watching this whole effort since TBGP and GLP and went through all TRIP's drafts, but (to the expense of being considered an... alien) I thought I could resort to the source for best information! :-) Thanks for the time and the very useful comments. Regards, Dimitris --------------------------------------------------------------- Dimitris Terzis PhD Candidate - Department of Computer Science, UCL E-Mail: D.Terzis@cs.ucl.ac.uk URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/ --------------------------------------------------------------- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Jun 4 23:12:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13240 for ; Sun, 4 Jun 2000 23:12:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 313A8443A7; Sun, 4 Jun 2000 23:02:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DC4944436E for ; Sun, 4 Jun 2000 23:01:58 -0400 (EDT) Received: from dynamicsoft.com (1Cust107.tnt4.freehold.nj.da.uu.net [63.36.112.107]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00531; Sun, 4 Jun 2000 23:13:03 -0400 (EDT) Message-ID: <393B1A71.58739DF2@dynamicsoft.com> Date: Sun, 04 Jun 2000 23:11:45 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dimitris Terzis Cc: iptel Subject: Re: [IPTEL] TRIP questions References: <002e01bfcc8c$ff195040$9f036cd5@kallisto> <3937DC81.1CB9748A@dynamicsoft.com> <002b01bfcce1$7cb35a60$b7036cd5@kallisto> <393883AC.3C7AEA6@dynamicsoft.com> <001601bfcd44$ca7fb320$a2096cd5@kallisto> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dimitris Terzis wrote: > > > The TRIP model is > > a call that begins in some entity with IP access (could be a gateway > > itself), terminates on one IP to PSTN gateway, and then ends within the > > PSTN. > > Is therefore TRIP only "unidirectional"? We already could do the other way > using phone numbers for terminals (which doesn't sound a bad idea at all to > me), In this case it is not a routing problem, but a naming problem. See the ENUM working group for a solution to that. > but also I don't see why an expansion of the supported advertised > address families to IP would harm the protocol... It would not; and the set of families is indeed extensible. > > > Of course only one gateway terminates the call, but would you completely > > > rule out the possibility of needing more than one gateway on an > end-to-end > > > call path? Or a "pure IP" call, where the gateway would be needed for, > say, > > > media conversion only? (You can also see this as a special case of > > > GSTN-to-IP, or GSTN-toIP-toIP if you prefer, although I did not mean any > > > direction in the original message). > > > > Then these are not gateways in the sense as defined by TRIP. Maybe you > > can explain the application you have in mind? > > Yes. I am thinking of a (perhaps theoretical) global IP Telephony Network, > where terminals (either GSTN or IP) are reachable in any combination. > Addressing is dual: There is one E.164 address per IP destination, and every > GSTN number is reachable via a corresponding IP address (the one of its > access gateway). > > The concept of a gateway also puzzles me. One good thing in the plain > vanilla telephony network is that all the "gateways" (i.e., the switches) > are integrated (or tightly coupled) devices, by contrast to IP, where, at > the application layer, we have Location Servers (to use TRIP terminology - I > prefer the expression "Call Routers"), Signalling Servers, Signalling > Gateways (with varying opinions as to what they do), etc., etc., etc., let > alone the multiplicity of devices at the network layer and below (which we > can ignore, though). > > My opinion is that, if we are ever to see global IP Telephony (which I > personally doubt), we need a more clear framework, at least for the core > components of the network, which means, among other things, unifying all > these devices according to their role. Now, it might not be conceivable > making a combined LS + gateway (i.e, an IP Telephony corresponding of the > GSTN switch), but at least we could do that about the gateways. ?? THis is exactly the opposite of the trend, which is to decompose these monster gateways into now FOUR components - signaling gateway, media gateway, gateway controller, and applications server. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 5 07:06:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28460 for ; Mon, 5 Jun 2000 07:06:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 177294438E; Mon, 5 Jun 2000 06:57:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id AB78B44384 for ; Mon, 5 Jun 2000 06:56:57 -0400 (EDT) Received: from 213.108.3.27 by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 5 Jun 2000 12:06:37 +0100 Message-ID: <003c01bfcede$3360b2a0$1b036cd5@kallisto> From: Dimitris Terzis To: Jonathan Rosenberg Cc: iptel References: <002e01bfcc8c$ff195040$9f036cd5@kallisto> <3937DC81.1CB9748A@dynamicsoft.com> <002b01bfcce1$7cb35a60$b7036cd5@kallisto> <393883AC.3C7AEA6@dynamicsoft.com> <001601bfcd44$ca7fb320$a2096cd5@kallisto> <393B1A71.58739DF2@dynamicsoft.com> Subject: Re: [IPTEL] TRIP questions Date: Mon, 5 Jun 2000 12:07:05 +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: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi... > > My opinion is that, if we are ever to see global IP Telephony (which I > > personally doubt), we need a more clear framework, at least for the core > > components of the network, which means, among other things, unifying all > > these devices according to their role. Now, it might not be conceivable > > making a combined LS + gateway (i.e, an IP Telephony corresponding of the > > GSTN switch), but at least we could do that about the gateways. > > ?? THis is exactly the opposite of the trend, which is to decompose > these monster gateways into now FOUR components - signaling gateway, > media gateway, gateway controller, and applications server I know... Well, it's another point of view. I think the important part is the larger picture, i.e., how to provide for a trully large-scale ISTN (IP Switched Telephone Network), and this rather depends more on routing, than on how you define the gateway _internally_... Cheers, Dimitris --------------------------------------------------------------- Dimitris Terzis PhD Candidate - Department of Computer Science, UCL E-Mail: D.Terzis@cs.ucl.ac.uk URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/ --------------------------------------------------------------- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 5 07:17:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28568 for ; Mon, 5 Jun 2000 07:17:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7EA92443A2; Mon, 5 Jun 2000 07:07:07 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 2B4A64433C for ; Mon, 5 Jun 2000 07:06:59 -0400 (EDT) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id QAA17505 for ; Mon, 5 Jun 2000 16:55:23 GMT Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA3833 for ; Mon, 5 Jun 2000 16:46:41 +0530 Received: from RISHI ([164.164.8.246]) by wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LLBFXL9P; Mon, 5 Jun 2000 16:47:47 +0530 Message-ID: <002c01bfcede$d319fae0$f608a4a4@wipsys.soft.net> From: "Rishi Choudhary" To: "iptel" References: <002e01bfcc8c$ff195040$9f036cd5@kallisto> <3937DC81.1CB9748A@dynamicsoft.com> <002b01bfcce1$7cb35a60$b7036cd5@kallisto> <393883AC.3C7AEA6@dynamicsoft.com> <001601bfcd44$ca7fb320$a2096cd5@kallisto> Date: Mon, 5 Jun 2000 16:41:40 +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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [IPTEL] Regarding Interoperability between VoIP Protocol stacks Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit I would need your help to understand the interoperability issue between different VoIP stacks. Are there any design issues to be considered , while developing an independent stack , so that we do not have problems later when you try to introduc einteroperability of this stack with any other stack. Moreover, does Interoperability functionality sits on top of the stacks. What I mean is, can we develop two stacks independently and work on interoperability between the two at a later period of time. Are there any guidelines on that ??? Regards Rishi Choudhary Wipro Technologies Bangalore _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 5 08:47:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00689 for ; Mon, 5 Jun 2000 08:47:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B30D4439D; Mon, 5 Jun 2000 08:36:46 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 6FDE84437E for ; Mon, 5 Jun 2000 08:36:43 -0400 (EDT) Received: from 213.108.4.219 by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 5 Jun 2000 13:46:30 +0100 Message-ID: <006601bfceec$282859c0$1b036cd5@kallisto> From: Dimitris Terzis To: iptel Date: Mon, 5 Jun 2000 13:47:04 +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 Subject: [IPTEL] Telephone newtork statistics Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi... I am looking for good referrence(s) with very recent statistics on the international GSTN, and particularly for things like number of switches per hierarchical level, proportion of switches per level (e.g., SSP/STP/SCP for SS7), and similar information. Generic web searches I 've tried proved of not much help, and the few telecoms newsgroups in Usent are so busy moderating themselves that no similar question can get through. Does anyone know of pointers to information like this? Thanks, Dimitris --------------------------------------------------------------- Dimitris Terzis PhD Candidate - Department of Computer Science, UCL E-Mail: D.Terzis@cs.ucl.ac.uk URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/ --------------------------------------------------------------- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 5 13:17:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06838 for ; Mon, 5 Jun 2000 13:17:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8F57F4437E; Mon, 5 Jun 2000 13:06:58 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id 7231A44336 for ; Mon, 5 Jun 2000 13:06:55 -0400 (EDT) Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAAA27; Mon, 5 Jun 2000 13:16:56 -0400 From: "Dave Oran" To: "Jonathan Rosenberg" , "Dimitris Terzis" Cc: "iptel" Subject: RE: [IPTEL] TRIP questions Date: Mon, 5 Jun 2000 13:16:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <393883AC.3C7AEA6@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > Of course, but what happens _above_ the network layer? Suppose that, for > > some reason, I want to have a _specific_ set of gateways in my > media path > > during a call. Is there any way to build such a path with TRIP > information? > > This rather gets closer to source routing... > > What do you mean by set of gateways? IP-PSTN gateways? The TRIP model is > a call that begins in some entity with IP access (could be a gateway > itself), terminates on one IP to PSTN gateway, and then ends within the > PSTN. There is no provision for routing calls that are > IP->PSTN->IP->PSTN->IP..... this is nearly impossible since it requires > integration with PSTN routing. > Well, if you think of the PSTN as either a single hop for which you inject a static route into TRIP, or an IGP-based thing where you get the information separately (e.g. from an SCP) and inject it, then actually this isn't so hard. In fact, I think it's kind of neat that TRIP could do this fairly easily as long as you make sure that each signaling hop is in the media path and capable of packet/circuit conversion. Of course the practical value of this is highly questionable, because the intermediate transcoding and de-jittering at each PSTN interconnect point will quickly add up to pretty poor voice quality and rather long delays. Dave. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 5 21:43:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13422 for ; Mon, 5 Jun 2000 21:43:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5BA9244356; Mon, 5 Jun 2000 21:33:38 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36]) by lists.bell-labs.com (Postfix) with ESMTP id 3195544336 for ; Mon, 5 Jun 2000 21:33:30 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg15e1.nortelnetworks.com; Mon, 5 Jun 2000 21:43:11 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 21:43:10 -0400 Message-ID: <28560036253BD41191A10000F8BCBD1128FB@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "Choudhary, Rishi [Partner:WBNG:7P81]" , iptel Subject: RE: [IPTEL] Regarding Interoperability between VoIP Protocol stac ks Date: Mon, 5 Jun 2000 21:43:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCF58.917EA110" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com 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_01BFCF58.917EA110 Content-Type: text/plain A stack by definition is a layered collection of protocol entities. Each layer has its role in terms of signalling performance, reliability, and security. I assume from your question that you are talking about application-layer interoperability, with an application-layer interworking function to provide it. From a semantic point of view this can be developed without worrying about what is down below, but you have to make sure your new stack as a whole meets the engineering assumptions which the other one has built in. > -----Original Message----- > From: Choudhary, Rishi [Partner:WBNG:7P81] > Sent: Monday, June 05, 2000 7:12 AM > To: iptel > Subject: [IPTEL] Regarding Interoperability between VoIP Protocol > stacks > > I would need your help to understand the interoperability issue between > different VoIP stacks. > > Are there any design issues to be considered , while developing an > independent stack , so that we do not have problems later when you try to > introduc einteroperability of this stack with any other stack. Moreover, > does Interoperability functionality sits on top of the stacks. What I mean > is, can we develop two stacks independently and work on interoperability > between the two at a later period of time. > > Are there any guidelines on that ??? > > > Regards > Rishi Choudhary > > Wipro Technologies > Bangalore > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel ------_=_NextPart_001_01BFCF58.917EA110 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [IPTEL] Regarding Interoperability between VoIP Protocol = stacks

A stack by = definition is a layered collection of protocol entities.  Each = layer has its role in terms of signalling performance, reliability, and = security.  I assume from your question that you are talking about = application-layer interoperability, with an application-layer = interworking function to provide it.  From a semantic point of = view this can be developed without worrying about what is down below, = but you have to make sure your new stack as a whole meets the = engineering assumptions which the other one has built in.

    -----Original Message-----
    From:   Choudhary, Rishi [Partner:WBNG:7P81]
    Sent:   Monday, June 05, 2000 7:12 AM
    To:     iptel
    Subject:       = [IPTEL] Regarding Interoperability = between VoIP Protocol stacks

    I would need your help to understand = the interoperability issue between
    different VoIP stacks.

    Are there any design issues to be = considered , while developing an
    independent stack , so that we do not = have problems later when you try to
    introduc einteroperability of this = stack with any other stack. Moreover,
    does Interoperability functionality = sits on top of the stacks. What I mean
    is, can we develop two stacks = independently and work on interoperability
    between the two at  a later = period of time.

    Are there any guidelines on that = ???


    Regards
    Rishi Choudhary

    Wipro Technologies
    Bangalore



    _______________________________________________
    IPTEL mailing list
    IPTEL@lists.bell-labs.com
    http://lists.bell-labs.com/mailman/listinfo/iptel<= /FONT>

------_=_NextPart_001_01BFCF58.917EA110-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 5 22:55:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15673 for ; Mon, 5 Jun 2000 22:55:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 56FDA4435E; Mon, 5 Jun 2000 22:45:06 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id DB6B644336 for ; Mon, 5 Jun 2000 22:45:02 -0400 (EDT) Received: by dnspri.npac.com; id VAA17390; Mon, 5 Jun 2000 21:54:59 -0500 (CDT) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma017363; Mon, 5 Jun 00 21:54:27 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 5 Jun 2000 21:54:02 -0500 Message-ID: From: James Yu To: "'hsalama@cisco.com'" Cc: "'jdrosen@dynamicsoft.com'" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt Date: Mon, 5 Jun 2000 21:53:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com > > From TRIP's perspective all numbers/prefixes it advertises are routing > numbers, otherwise these numbers/prefixes should not have > been injected > into TRIP in first place. This has been stated clearly in > Section 11 of > the "Framework for Telephony Routing over IP" draft. It says: "Since > TRIP is a routing protocol, the routes it propagates should be to > routable numbers, not to names which are eventually translated to > routable numbers." > I'm glad to see that this particular point (roting number vs. subscriber number) has been clarified in the TRIP document. Thanks for pointing that out. May be that statement should be put in the abstract to make that point clear. > > > > In the North America, the network routing numbers are > called Location > > Routing Numbers (LRNs). They "look" like subscriber phone > numbers (e.g., > > the same length) and can overlap with the subscriber phone > numbers. In some > > European countries, special digit (e.g., A and B) are used > to differentiate > > the network routing numbers from the subscriber phone > numbers. Those > > I think TRIP should be extended advertising these European formats. Is > this an extended form of E.164, or should it be a separate address > family? Some of the routing numbers (or routig prefixes, as they are usually prefixes to the dialed called party number) contain the digits outside 0-9 (e.g., A, B, C, D, E, and F). They are valid routing numbers (national numbers) either within one network (used by a particular network) or between networks. Since they don't just contain digits 0-9, we may not say that they follow E.164 format. But they should be viewed as valid routing numbers. In this case, a valid digit in a routng number can be from 0 (0000) to F (1111). After adding the country code to the routing numbers in Europe, those "international" routing numbers probably can be used for routing. The country code will allow the call to be routed to that country. After removing the country code by a gateway at that country, the "national" routing number can then be used for routing. Since the routing number is cancatenated with the dialed called party number (they are carried in the Called Party Number paramter)in some NP implementations in Europe, the "routing number" we are discussing should be limited to the "routing number" or "routing prefix" instead of the "routing number + dialed called party number." For example, UK uses "5xxxxx" as a routing number/prefix where "xxxxx" identifies the carrier. A carrier can assign additional numbers after "5xxxxx" which can point to a network, a switch/exchange, or even a line card at a switch/exchange. In that case, "5xxxxx" plus the "addtional digits" would be treated us the routing number. I believe that this routing number is not longer than 15 digits. Any comment from people in Europe? > > Is there a reason that prevents expanding routing numbers to > full E.164 > numbers before injecting them into TRIP? > If "5xxxxx+x....x" is treated as a routing prefix (no exception within the range), then there is no need to expand a routing number to full E.164 numbers. In some countries, the E.164 numbers have variable length of digits. They don't have a fixed length of digits (in North America, we have 11 digits for all "international" NANP numbers). James _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 6 02:44:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29081 for ; Tue, 6 Jun 2000 02:44:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7D07844353; Tue, 6 Jun 2000 02:34:20 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail.vsys.com (mail.vsys.com [63.93.241.11]) by lists.bell-labs.com (Postfix) with ESMTP id 5670344336 for ; Tue, 6 Jun 2000 02:34:17 -0400 (EDT) Received: from bobpc (1Cust7.tnt31.atl2.da.uu.net [63.38.64.7]) by mail.vsys.com (8.9.3+3.2W/8.9.3) with SMTP id AAA04398; Tue, 6 Jun 2000 00:41:18 -0700 (PDT) From: "Bob Wise" To: "Rishi Choudhary" , "iptel" Subject: RE: [IPTEL] Regarding Interoperability between VoIP Protocol stacks Date: Tue, 6 Jun 2000 00:43:16 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <002c01bfcede$d319fae0$f608a4a4@wipsys.soft.net> Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit The APIs and message sets on top of the stacks are not standarized, but I do suggest you look at the JAIN work which is attempting to do that for Java applications. Of course, for really high-performance applications, Java is not appropriate. We have been able in our softswitch system to not only abstract between different H.323 implementations, but also between H.323 and MGCP stack implementations, so it can be done. -Bob ----------- Bob Wise Chief Architect Vsys, Inc. - "The Softswitch Company" www.vsys.com -----Original Message----- From: iptel-admin@lists.bell-labs.com [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Rishi Choudhary Sent: Monday, June 05, 2000 5:12 AM To: iptel Subject: [IPTEL] Regarding Interoperability between VoIP Protocol stacks I would need your help to understand the interoperability issue between different VoIP stacks. Are there any design issues to be considered , while developing an independent stack , so that we do not have problems later when you try to introduc einteroperability of this stack with any other stack. Moreover, does Interoperability functionality sits on top of the stacks. What I mean is, can we develop two stacks independently and work on interoperability between the two at a later period of time. Are there any guidelines on that ??? Regards Rishi Choudhary Wipro Technologies Bangalore _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 7 20:12:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23048 for ; Wed, 7 Jun 2000 20:12:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2BDD344336; Wed, 7 Jun 2000 20:02:08 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id A401544336 for ; Tue, 6 Jun 2000 19:45:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue Jun 6 19:54:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9173A44344; Tue, 6 Jun 2000 19:41:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 5FFE144341 for ; Tue, 6 Jun 2000 19:41:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5B4CA52C4; Tue, 6 Jun 2000 19:41:23 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 644AB52B6 for ; Tue, 6 Jun 2000 19:41:20 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Jun 6 19:39:59 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Tue Jun 6 19:39:58 EDT 2000 Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA07309; Tue, 6 Jun 2000 19:41:06 -0400 (EDT) Message-ID: <393D8BD8.DDEC1A04@dynamicsoft.com> Date: Tue, 06 Jun 2000 19:40:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net, sip , "iptel, list" , megaco@standards.nortelnetworks.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Availability of RTP library source code in C Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Folks, I am pleased to finally announce the availability of source code for RTPlib, and RTP library in C developed jointly by myself, Daniel Rubenstein from U.Mass Amherst, and Henning Schulzrinne and Jonathan Lennox from Columbia University. The library is fairly complete, implementing some of the harder things, such as SSRC collision, mixers, and RTCP timer reconsideration, in a transparent manner. It comes with HTML documentation and example applications. The library is free for non-commercial and research usage. It has been run and tested primarily on Solaris, but has also been used on NT. You can obtain the software at: http://www.bell-labs.com/topic/swdist/ Thanks! -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 7 20:16:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23062 for ; Wed, 7 Jun 2000 20:16:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 28872443D2; Wed, 7 Jun 2000 20:02:24 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 439D344336 for ; Wed, 7 Jun 2000 03:31:55 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jun 7 03:40:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id D257B44344; Wed, 7 Jun 2000 03:27:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 9F88444341 for ; Wed, 7 Jun 2000 03:27:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C238352C4; Wed, 7 Jun 2000 03:27:22 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0510752B6 for ; Wed, 7 Jun 2000 03:27:20 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jun 7 03:26:54 EDT 2000 Received: from maliwan.psu.ac.th ([192.100.77.4]) by dusty; Wed Jun 7 03:26:49 EDT 2000 Received: from hoya (gateway.coe.psu.ac.th [203.154.146.4]) by maliwan.psu.ac.th (8.9.1/8.9.1) with SMTP id OAA22403 for ; Wed, 7 Jun 2000 14:26:35 +0700 (GMT) Message-ID: <003101bfd053$72136580$8300a8c0@coe.psu.ac.th> From: "Suntichai Chuaywong" To: Date: Wed, 7 Jun 2000 14:38:27 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01BFD08E.0AC55060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] How to use ASN Compiler Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_002C_01BFD08E.0AC55060 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable When do we use ASN Compiler in H.323 Application and how we use it ? = If you have an ASN Compiler, please send it to me and example of using = it. ------=_NextPart_000_002C_01BFD08E.0AC55060 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
    When do we use ASN = Compiler in=20 H.323 Application and how we use it ?
If you have an ASN Compiler, please = send it to me=20 and example of using it.
------=_NextPart_000_002C_01BFD08E.0AC55060-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 8 17:56:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17719 for ; Thu, 8 Jun 2000 17:56:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 44DA744421; Thu, 8 Jun 2000 17:27:14 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 346B14433A for ; Thu, 8 Jun 2000 17:27:11 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA13545; Thu, 8 Jun 2000 17:38:49 -0400 (EDT) Message-ID: <39401235.65C6DF53@dynamicsoft.com> Date: Thu, 08 Jun 2000 17:37:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Yu Cc: "'hsalama@cisco.com'" , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Yu wrote: > > > > > > > In the North America, the network routing numbers are > > called Location > > > Routing Numbers (LRNs). They "look" like subscriber phone > > numbers (e.g., > > > the same length) and can overlap with the subscriber phone > > numbers. In some > > > European countries, special digit (e.g., A and B) are used > > to differentiate > > > the network routing numbers from the subscriber phone > > numbers. Those > > > > I think TRIP should be extended advertising these European formats. Is > > this an extended form of E.164, or should it be a separate address > > family? > > Some of the routing numbers (or routig prefixes, as they are usually > prefixes to the dialed called party number) contain the digits outside 0-9 > (e.g., A, B, C, D, E, and F). They are valid routing numbers (national > numbers) either within one network (used by a particular network) or between > networks. Since they don't just contain digits 0-9, we may not say that > they follow E.164 format. Oh yuck. I'm curious how this impacts the aggregatability of such numbers? Are they assigned in such a way that they can still be aggregated even though there are these random letters in the phone number? Is there any kind of hierarchy in these numbers? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 9 00:40:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23861 for ; Fri, 9 Jun 2000 00:40:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 26153443E4; Fri, 9 Jun 2000 00:29:55 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id A86834433A for ; Fri, 9 Jun 2000 00:29:51 -0400 (EDT) Received: by dnspri.npac.com; id XAA10696; Thu, 8 Jun 2000 23:40:13 -0500 (CDT) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma010677; Thu, 8 Jun 00 23:39:46 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Thu, 8 Jun 2000 23:39:20 -0500 Message-ID: From: James Yu To: "'Jonathan Rosenberg'" Cc: "'hsalama@cisco.com'" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt Date: Thu, 8 Jun 2000 23:38:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com My understanding about the reason of using the digit A, B, ... or F is to avoid taking away the valid E.164 numbers from being assigned as subscriber numbers. In ISUP Called Party Number parameter, there is a Nature of Address (NOA) field. Some countries assigned a new NOA value (country-specific) to indicate that routing number is concatenated with the dialed called party number and may implicitly indicate that NP database dip has been performed. If we use "rn" parameter in tel URL to carry the routing number, we may need to define the rn in a way to allow 0-9 and A-F. The routing number, for example, "5xxxxx+ additional digits defined by the assigned carrier" in UK, may have hierarchy where "5" indicates a routing number for NP and "xxxxx" identifies the carrier. The "additional digits" may have hierarchy. For example, BT may define the routing number to identify the line card (concentrator) at the switch. This implies that those "additional digits" can be divided at least into two levels: one identifies the switch and the other the line card. James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, June 08, 2000 5:38 PM > To: James Yu > Cc: 'hsalama@cisco.com'; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt > > > > > James Yu wrote: > > > > > > > > > > In the North America, the network routing numbers are > > > called Location > > > > Routing Numbers (LRNs). They "look" like subscriber phone > > > numbers (e.g., > > > > the same length) and can overlap with the subscriber phone > > > numbers. In some > > > > European countries, special digit (e.g., A and B) are used > > > to differentiate > > > > the network routing numbers from the subscriber phone > > > numbers. Those > > > > > > I think TRIP should be extended advertising these > European formats. Is > > > this an extended form of E.164, or should it be a separate address > > > family? > > > > Some of the routing numbers (or routig prefixes, as they are usually > > prefixes to the dialed called party number) contain the > digits outside 0-9 > > (e.g., A, B, C, D, E, and F). They are valid routing > numbers (national > > numbers) either within one network (used by a particular > network) or between > > networks. Since they don't just contain digits 0-9, we may > not say that > > they follow E.164 format. > > Oh yuck. > > I'm curious how this impacts the aggregatability of such numbers? Are > they assigned in such a way that they can still be aggregated even > though there are these random letters in the phone number? Is > there any > kind of hierarchy in these numbers? > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 9 07:46:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09062 for ; Fri, 9 Jun 2000 07:46:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C1964441F; Fri, 9 Jun 2000 07:31:42 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.71]) by lists.bell-labs.com (Postfix) with SMTP id 2378244339 for ; Fri, 9 Jun 2000 07:31:39 -0400 (EDT) Received: from slsms2a.stgl.netd.alcatel.de by mailrelay2.alcatel.de with SMTP (XT-PP) with ESMTP; Fri, 9 Jun 2000 13:32:29 +0200 Received: from localhost (root@localhost) by slsms2a.stgl.netd.alcatel.de (8.8.6 (PHNE_17190)/8.8.6) with SMTP id NAA02082; Fri, 9 Jun 2000 13:33:08 +0200 (METDST) From: M.Muench@alcatel.de X-OpenMail-Hops: 1 Date: Fri, 9 Jun 2000 13:32:57 +0200 Message-Id: Subject: RE: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt MIME-Version: 1.0 To: james.yu@neustar.com, jdrosen@dynamicsoft.com Cc: hsalama@cisco.com, iptel@lists.bell-labs.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit I can agree with the explanation of the use of hexadecimal digits in the Routing Number. But not all values "A-F" can be used. Value "B and C" are standardised as digits for special operator functions. Value "F" has never been used for the Routing Number or other applications, because this value is standardised and used as the "End of Signal" indication in the routing process. That means that subsequent digits are not accepted and therefore discarded. So for the Routing Number the following digits can be used: 1) hexadecimal digits A, D, E; the use of B and C is country specific or 2) free number blocks of the numbering range Please take this correction into account if the relevant text will be included in the next draft of TRIP. Kind regards, Monika Muench Alcatel SEL AG, Germany ---------- From: james.yu@neustar.com To: jdrosen@dynamicsoft.com Cc: hsalama@cisco.com; iptel@lists.bell-labs.com Subject: RE: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt Date: Friday, June 09, 2000 6:38AM My understanding about the reason of using the digit A, B, ... or F is to avoid taking away the valid E.164 numbers from being assigned as subscriber numbers. In ISUP Called Party Number parameter, there is a Nature of Address (NOA) field. Some countries assigned a new NOA value (country-specific) to indicate that routing number is concatenated with the dialed called party number and may implicitly indicate that NP database dip has been performed. If we use "rn" parameter in tel URL to carry the routing number, we may need to define the rn in a way to allow 0-9 and A-F. The routing number, for example, "5xxxxx+ additional digits defined by the assigned carrier" in UK, may have hierarchy where "5" indicates a routing number for NP and "xxxxx" identifies the carrier. The "additional digits" may have hierarchy. For example, BT may define the routing number to identify the line card (concentrator) at the switch. This implies that those "additional digits" can be divided at least into two levels: one identifies the switch and the other the line card. James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, June 08, 2000 5:38 PM > To: James Yu > Cc: 'hsalama@cisco.com'; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt > > > > > James Yu wrote: > > > > > > > > > > In the North America, the network routing numbers are > > > called Location > > > > Routing Numbers (LRNs). They "look" like subscriber phone > > > numbers (e.g., > > > > the same length) and can overlap with the subscriber phone > > > numbers. In some > > > > European countries, special digit (e.g., A and B) are used > > > to differentiate > > > > the network routing numbers from the subscriber phone > > > numbers. Those > > > > > > I think TRIP should be extended advertising these > European formats. Is > > > this an extended form of E.164, or should it be a separate address > > > family? > > > > Some of the routing numbers (or routig prefixes, as they are usually > > prefixes to the dialed called party number) contain the > digits outside 0-9 > > (e.g., A, B, C, D, E, and F). They are valid routing > numbers (national > > numbers) either within one network (used by a particular > network) or between > > networks. Since they don't just contain digits 0-9, we may > not say that > > they follow E.164 format. > > Oh yuck. > > I'm curious how this impacts the aggregatability of such numbers? Are > they assigned in such a way that they can still be aggregated even > though there are these random letters in the phone number? Is > there any > kind of hierarchy in these numbers? > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 9 12:41:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14775 for ; Fri, 9 Jun 2000 12:41:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9D4B044337; Fri, 9 Jun 2000 12:29:33 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 7A4E944336 for ; Wed, 7 Jun 2000 23:39:47 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jun 7 23:48:17 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9C93F44345; Wed, 7 Jun 2000 23:35:08 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 75EDF44341 for ; Wed, 7 Jun 2000 23:35:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D497452C4; Wed, 7 Jun 2000 23:35:20 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 2A63252B6 for ; Wed, 7 Jun 2000 23:35:18 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Jun 7 23:33:47 EDT 2000 Received: from maliwan.psu.ac.th ([192.100.77.4]) by dusty; Wed Jun 7 23:33:46 EDT 2000 Received: from hoya (gateway.coe.psu.ac.th [203.154.146.4]) by maliwan.psu.ac.th (8.9.1/8.9.1) with SMTP id KAA11860; Thu, 8 Jun 2000 10:33:35 +0700 (GMT) Message-ID: <002401bfd0fc$0ffae4a0$8300a8c0@coe.psu.ac.th> From: "Suntichai Chuaywong" To: Cc: Date: Thu, 8 Jun 2000 10:45:30 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01BFD136.AA580E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] How to use ASN.1 Compiler Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_001F_01BFD136.AA580E80 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable What is ASN.1 Compiler and when do we use ASN.1 Compiler in H.323 = application ? If you have ASN.1 Compiler, please send it to me with some example of using it ------=_NextPart_000_001F_01BFD136.AA580E80 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
What is ASN.1 Compiler and when do we = use ASN.1=20 Compiler in H.323 application ? If you have ASN.1 Compiler,
please send it to me with some example = of using=20 it
------=_NextPart_000_001F_01BFD136.AA580E80-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 9 12:47:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14882 for ; Fri, 9 Jun 2000 12:47:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 136554434D; Fri, 9 Jun 2000 12:29:37 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 635C344336 for ; Wed, 7 Jun 2000 23:35:48 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jun 7 23:44:23 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0EDD044344; Wed, 7 Jun 2000 23:31:14 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id D995A44341 for ; Wed, 7 Jun 2000 23:31:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 188F252C4; Wed, 7 Jun 2000 23:31:22 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 44B7752B6 for ; Wed, 7 Jun 2000 23:31:19 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jun 7 23:29:49 EDT 2000 Received: from maliwan.psu.ac.th ([192.100.77.4]) by dusty; Wed Jun 7 23:29:48 EDT 2000 Received: from hoya (gateway.coe.psu.ac.th [203.154.146.4]) by maliwan.psu.ac.th (8.9.1/8.9.1) with SMTP id KAA09285 for ; Thu, 8 Jun 2000 10:28:32 +0700 (GMT) Message-ID: <000201bfd0fb$5bd1ad60$8300a8c0@coe.psu.ac.th> From: "Suntichai Chuaywong" To: Date: Wed, 7 Jun 2000 23:00:19 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01BFD0D4.27321120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] How to use ASN.1 Compiler Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_001F_01BFD0D4.27321120 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable I wonder what ASN.1 Compiler use for and when to use it in H.323 = application ? If you have ASN.1 compiler, please send it to me with some example of using it = Thank you very much = Suntichai Chuaywong ------=_NextPart_000_001F_01BFD0D4.27321120 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
I wonder what ASN.1 Compiler use for = and=20 when to use it in H.323 application ? If you have ASN.1 compiler,=20 please
send it to me with some example of = using=20 it
       =20             =    =20             =    =20             =    =20             Thank you very=20 much
       =20             =    =20             =    =20             =    =20             =    =20 Suntichai Chuaywong
------=_NextPart_000_001F_01BFD0D4.27321120-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 9 12:56:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15106 for ; Fri, 9 Jun 2000 12:56:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A75CA44364; Fri, 9 Jun 2000 12:29:50 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 8F0A644389 for ; Thu, 8 Jun 2000 11:01:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 8 11:10:22 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 78B7E44344; Thu, 8 Jun 2000 10:57:11 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 46DEC44341 for ; Thu, 8 Jun 2000 10:57:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A0D9D52C4; Thu, 8 Jun 2000 10:57:22 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C79AD52AB for ; Thu, 8 Jun 2000 10:57:19 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jun 8 10:56:52 EDT 2000 Received: from oss.oss.com ([207.207.205.89]) by dusty; Thu Jun 8 10:56:52 EDT 2000 Received: from sparky.oss.com by oss.oss.com ; 8 JUN 100 10:56:45 EDT Date: Thu, 8 Jun 2000 10:56:45 -0400 (EDT) From: Bancroft Scott To: "Nadathur, Srivathsan" , iptel@lists.research.bell-labs.com Cc: "'support@oss.com'" Subject: Re: FW: [IPTEL] How to use ASN Compiler In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com On Thu, 8 Jun 2000, Nadathur, Srivathsan wrote: > When do we use ASN Compiler in H.323 Application and how we use it ? > If you have an ASN Compiler, please send it to me and example of using it. You use the ASN.1 compiler to compile the H.323 ASN.1-defined messages. The output of the ASN.1 compiler consist of files that contain C structs, C++ classes or Java classes, depending on whether you are using the OSS ASN.1/C, ASN.1/C++ or ASN.1/Java product. You then use the classes/structs defined in these files in writing your application. Let me know if the above is not sufficiently clear to you. You can also bet a better idea as to the possibilities by looking at: http://www.oss.com/products/tools.html http://www.oss.com/products/application.html http://www.oss.com/products/asn1cpp/tools_cpp.html http://www.oss.com/products/asn1java/javatools.html http://www.oss.com/products/asn1java/javaapp.html If you would like a trial license of the OSS ASN.1 Tools please send email to info@oss.com. If you have any technical questions, please send email to support@oss.com. ------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 baos@oss.com Tech Support :1-732-302-9669 x-200 http://www.oss.com Fax :1-732-302-0023 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 9 13:20:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15629 for ; Fri, 9 Jun 2000 13:20:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 96D15443B5; Fri, 9 Jun 2000 12:33:32 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 8279744336 for ; Fri, 9 Jun 2000 12:23:35 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 9 12:32:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C06B744344; Fri, 9 Jun 2000 12:19:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 9951844341 for ; Fri, 9 Jun 2000 12:19:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 312EA52C4; Fri, 9 Jun 2000 12:19:22 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4FD2152AB for ; Fri, 9 Jun 2000 12:19:19 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jun 9 12:17:09 EDT 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Fri Jun 9 12:17:08 EDT 2000 Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA09460; Fri, 9 Jun 2000 12:17:07 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id MAA11207; Fri, 9 Jun 2000 12:17:04 -0400 (EDT) Date: Fri, 9 Jun 2000 12:17:04 -0400 (EDT) Message-Id: <200006091617.MAA11207@ind.cs.columbia.edu> From: Jonathan Lennox To: Amit Bhadoria Cc: iptel@lists.research.bell-labs.com, schulzrinne@opus.cs.columbia.edu In-Reply-To: References: Subject: [IPTEL] Re: CPL Timezone offset Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com On Thu, June 8 2000, "Amit Bhadoria" wrote to "iptel@lists.research.bell-labs.com, lennox@cs.columbia.edu, schulzrinne@opus.cs.columbia.edu" saying: > hi, > > i'm working on an implementation of CPL (draft-ietf-iptel-cpl-01). The > reffered document specifies a syntax for the "standard" and "daylight" > offset tags of "timezone" (section 9 and fig 17). > > presently, the document specifies that the parameters of theses offset > tags specify "... a set of instants when the time zone rule takes effect, > I N T H E L O C A L T I M E O F T H E ``O T H E R'' > O F F S E T ..." > > if there are more than two offsets defined for a particular timezone, > keeping a reference to this ``OTHER'' is difficult (if not ambiguous!), > making the implementation very ugly (due to brute force approach). > > in my opinion, there needs to be one more parameter in the offset tags, > that referes to the "abbr" field of the ``OTHER'' offset (after which it > becomes effective). > > please suggest if there is some other elegant implementation poosible. At the IPTel meeting at the last IETF, it seemed that rough consensus was that no one liked the way the most recent CPL draft defined timezones. After investigating the issue a fair amount, I've determined that a) it's much harder than I thought, and b) other groups have faced the same problem. My current thought is to simply reference the timezones defined by iCal; this is the best way of leveraging others' work, though it does unfortunately impose a requirement that CPL implementors understand a rather complex separate protocol language. The other possibility would be to reference the Olson TZ database , but unfortunately that isn't a normative reference. There've been some efforts to generate a normative set of time zone names from that database for use in iCal, but I don't believe very much has come of this so far. The suggestion you gave above -- of referencing the abbreviation of the other zone -- doesn't unfortunately work, due to things like the Australian timezones "Eastern Standard Time" and "Eastern Summer Time" which have the same abbreviation. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 9 13:27:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15720 for ; Fri, 9 Jun 2000 13:27:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1924F443C6; Fri, 9 Jun 2000 12:33:38 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 2B80944337 for ; Fri, 9 Jun 2000 11:13:37 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 9 11:23:30 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 679A544346; Fri, 9 Jun 2000 10:59:09 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 3527544345 for ; Fri, 9 Jun 2000 10:59:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E3E6752C4; Fri, 9 Jun 2000 10:59:21 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EC5C152AB for ; Fri, 9 Jun 2000 10:59:19 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Jun 9 10:57:37 EDT 2000 Received: from mail-blue.research.att.com ([135.207.30.102]) by dusty; Fri Jun 9 10:57:37 EDT 2000 Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id B85A14CE2D for ; Fri, 9 Jun 2000 10:57:35 -0400 (EDT) Received: from research.att.com (fpdhcp073.research.att.com [135.207.28.73]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id KAA20194 for ; Fri, 9 Jun 2000 10:57:35 -0400 (EDT) Message-ID: <394104B1.A4CD53C2@research.att.com> Date: Fri, 09 Jun 2000 10:52:33 -0400 From: "Gregory W. Bond" Organization: AT&T Labs - Research, Florham Park, NJ X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] 3rd CFP (EXTENDED DEADLINE): IP Telecom Services Workshop 2000 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit [Please accept our apologies for multiple copies of this call.] ------------- THIRD CALL FOR PAPERS --------------- ------------- EXTENDED DEADLINE --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 submission deadline: June 23, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. The IPTS 2000 Program Committee invites submission of papers on substantial, original and previously unpublished research in IP telecom services, including, but not limited to: - service architectures (e.g. AIN, SoftSwitch, JAIN, Parlay, DFC) - service creation environments - protocols, standards and interoperability (e.g. H.323, SIP, MGCP, Megaco/H.248, etc.) - service programming languages - service management - billing, fault tolerance, monitoring - novel services We welcome papers describing original research; position papers describing research interests in the field, work in progress, or future directions of research; project or system descriptions. IMPORTANT DATES June 23, 2000 Submission deadline July 21, 2000 Notification of acceptance August 25, 2000 Final version of papers September 11, 2000 IPTS 2000 PAPER SUBMISSIONS Papers must describe original, previously unpublished work that has not been simultaneously submitted for publication elsewhere. They must be written in English, not exceeding 6 pages including figures, tables and references in 10-12 point font on 8.5x11-inch (US letter) paper. The first page must include an abstract of up to 200 words, keywords, and email address of the corresponding author. All papers must be submitted electronically unless specifically approved by the Workshop Co-Chairs. Submissions in PostScript or PDF format should be sent to mailto:ipts2000@research.att.com. Authors of accepted papers are expected to present their contribution at the workshop. The proceedings will be published in hardcopy and on the web. REVIEW PROCEDURE All submissions will be subject to academic peer review by the IPTS 2000 Program Committee under the chairmanship of the Workshop Co-Chairs. Each paper will receive three written reviews, and reviews will be returned to the authors. The Workshop Co-Chairs have final authority over the review process and all decisions relating to acceptance of papers. Review criteria include originality of ideas, technical soundness, significance of results, and quality of presentation. CONFERENCE VENUE AND RELATED EVENTS IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Details about Fall 2000 VON can be found at http://pulver.com. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com). WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 9 13:33:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15868 for ; Fri, 9 Jun 2000 13:33:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31D18443DB; Fri, 9 Jun 2000 12:33:48 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 011AB44417 for ; Fri, 9 Jun 2000 06:41:47 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 9 06:51:30 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5FC4344345; Fri, 9 Jun 2000 06:25:12 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 188EB44346 for ; Fri, 9 Jun 2000 06:25:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 05AFB52C4; Fri, 9 Jun 2000 06:25:23 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3633852C8 for ; Fri, 9 Jun 2000 06:25:21 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Jun 9 06:23:27 EDT 2000 Received: from smtp2.cluster.oleane.net ([195.25.12.17]) by dusty; Fri Jun 9 06:23:26 EDT 2000 Received: from oleane (dyn-1-2-224.Vin.dialup.oleane.fr [194.2.4.224]) by smtp2.cluster.oleane.net with SMTP id MAA10437 for ; Fri, 9 Jun 2000 12:23:53 +0200 (CEST) Message-ID: <002d01bfd1fc$84e18840$7501a8c0@oleane.oleane.com> From: "Peter Lewis" To: Date: Fri, 9 Jun 2000 12:21:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01BFD20D.45788F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [IPTEL] MGC CALL FOR PAPER Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0029_01BFD20D.45788F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, MGCP/Megaco Conference 14 to 17 November 2000. Second edition: = deployment experiences, operational issues, interoperability status. Please get more details on the call for papers online: http://www.upperside.fr/bamgc2yk.htm ------=_NextPart_000_0029_01BFD20D.45788F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
MGCP/Megaco Conference 14 to 17 = November 2000.=20 Second edition: deployment experiences, operational issues, = interoperability=20 status.
Please get = more details on=20 the call for papers online:
http://www.upperside.fr/bam= gc2yk.htm
------=_NextPart_000_0029_01BFD20D.45788F80-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 9 13:38:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15954 for ; Fri, 9 Jun 2000 13:38:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B6643443E5; Fri, 9 Jun 2000 12:33:48 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 304EB4433A for ; Thu, 8 Jun 2000 21:23:40 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Thu Jun 8 21:32:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A383944344; Thu, 8 Jun 2000 21:19:09 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7324C44341 for ; Thu, 8 Jun 2000 21:19:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 33AC652C4; Thu, 8 Jun 2000 21:19:21 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 757F352B6 for ; Thu, 8 Jun 2000 21:19:18 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jun 8 21:18:17 EDT 2000 Received: from sampras.private.vovida.com ([209.237.8.98]) by dusty; Thu Jun 8 21:18:16 EDT 2000 Received: from localhost (amitb@localhost) by sampras.private.vovida.com (8.9.3/8.9.3) with ESMTP id SAA16805; Thu, 8 Jun 2000 18:18:15 -0700 X-Authentication-Warning: sampras.private.vovida.com: amitb owned process doing -bs Date: Thu, 8 Jun 2000 18:18:15 -0700 (PDT) From: Amit Bhadoria X-Sender: amitb@sampras.private.vovida.com To: iptel@lists.research.bell-labs.com Cc: lennox@cs.columbia.edu, schulzrinne@cs.columbia.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [IPTEL] CPL Timezone offset Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com hi, i'm working on an implementation of CPL (draft-ietf-iptel-cpl-01). The reffered document specifies a syntax for the "standard" and "daylight" offset tags of "timezone" (section 9 and fig 17). presently, the document specifies that the parameters of theses offset tags specify "... a set of instants when the time zone rule takes effect, I N T H E L O C A L T I M E O F T H E ``O T H E R'' O F F S E T ..." if there are more than two offsets defined for a particular timezone, keeping a reference to this ``OTHER'' is difficult (if not ambiguous!), making the implementation very ugly (due to brute force approach). in my opinion, there needs to be one more parameter in the offset tags, that referes to the "abbr" field of the ``OTHER'' offset (after which it becomes effective). please suggest if there is some other elegant implementation poosible. thanks and regards, -amit. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 13 07:41:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03524 for ; Tue, 13 Jun 2000 07:41:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A18A4433E; Tue, 13 Jun 2000 07:30:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 846A444336 for ; Tue, 13 Jun 2000 01:47:17 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e5D5wBr04564 for ; Tue, 13 Jun 2000 07:58:11 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA25585 for ; Tue, 13 Jun 2000 08:58:09 +0300 (EET DST) Message-ID: <3945CD52.22F836D6@lmf.ericsson.se> Date: Tue, 13 Jun 2000 08:57:38 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: iptel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Length in OPEN Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Why is it needed the "optional parameter length" in the OPEN message if the length of the whole message is already present in the fixed-sized header? Thanks, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 13 10:59:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10623 for ; Tue, 13 Jun 2000 10:59:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5364444353; Tue, 13 Jun 2000 10:48:26 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.71]) by lists.bell-labs.com (Postfix) with SMTP id D3C6D44336 for ; Tue, 13 Jun 2000 10:48:22 -0400 (EDT) Received: from slsms2a.stgl.netd.alcatel.de by mailrelay2.alcatel.de with SMTP (XT-PP) with ESMTP; Tue, 13 Jun 2000 16:58:27 +0200 Received: from localhost (root@localhost) by slsms2a.stgl.netd.alcatel.de (8.8.6 (PHNE_17190)/8.8.6) with SMTP id QAA18712; Tue, 13 Jun 2000 16:59:06 +0200 (METDST) From: M.Muench@alcatel.de X-OpenMail-Hops: 1 Date: Tue, 13 Jun 2000 16:59:01 +0200 Message-Id: Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt MIME-Version: 1.0 To: hsalama@cisco.com, james.yu@neustar.com, jdrosen@dynamicsoft.com, iptel@lists.bell-labs.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Some important information with regard to the Routeing Number used in telecommunication networks, if Number Portability has to be supported: ====================================================================== In the existing networks, routeing is a quite complex procedure. Several input data are used (e.g. information from and on the origin, information on the destination, signalling capabilities, bearer requirements). Before Number Portability, there was no real distinction between the Directory Number and the Routeing Number; now, for a call without Number Portability, the same still applies - there is no real distinction between the Directory Number and the Routeing Number. Both are represented by one and the same E.164-number which is transferred in one parameter (Called Party Number parameter). By the introduction of Number Portability, this has changed. There is a need for a split into a Directory Number (DN) and a Routeing Number (RN), also from a protocol point of view. The DN does not change, while the RN is used for routeing purposes. From an ISUP perspective, three addressing mechanisms for the RN have been specified in Q.769.1. ETSI has endorsed Q.769.1 with one exception: The NP-method "Dropback" is not supported. Again - as far as the addressing mechanisms are concerned, there is no difference between ITU-T and ETSI. Number Portability is used only in a national environment and has never been planned for international use, i.e. in the case of international calls, it is always seen as the responsibility of the destination country to perform Number Portability (especially the data base query). Example: An "All Call Query" in the origination country for an international call is not planned to be used for Number Portability. When the call enters the network of the destination network then e.g. the "All Call Query" solution can be used to retrieve the Routeing Number. If the data base query for international calls should be performed in the origination country, several problems have to be solved, e.g. administrating ALL routing numbers (worldwide!) and keeping them up to date. In general for the coding of the Routeing Number in ISUP the same principles apply as for the called party number otherwise a worldwide function of telecommunication would not work if basic routeing procedures would be changed. However, the Number Portability relevant parts of the ISUP protocol are for "national use". Therefore, (bilateral?) agreements on the ISUP protocol issues are needed as well. NOTE: The coding and the rules can be found in ITU-T ISUP Recommendation Q.763, Q.764 (12/99), and Q.769.1. As far as ETSI is concerned: see above. Kind regards, Monika Muench Alcatel SEL AG, Germany ---------- From: hsalama@cisco.com To: Muench, Monika / selh2 Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt Date: Monday, June 12, 2000 9:05AM Monika, Are the formats of European routning numbers standardized somewhere? Could you please point me to the relevant standards? Thank you. Hussein M.Muench@alcatel.de wrote: > > I can agree with the explanation of the use of hexadecimal digits in the > Routing Number. > But not all values "A-F" can be used. Value "B and C" are standardised as > digits for special operator functions. > Value "F" has never been used for the Routing Number or other applications, > because this value is standardised and used as the "End of Signal" > indication in the routing process. That means that subsequent digits are > not accepted and therefore discarded. > > So for the Routing Number the following digits can be used: > > 1) hexadecimal digits A, D, E; > the use of B and C is country specific > > or > > 2) free number blocks of the numbering range > > Please take this correction into account if the relevant text will be > included in the next draft of TRIP. > > Kind regards, > > Monika Muench > Alcatel SEL AG, Germany > > ---------- > From: james.yu@neustar.com > To: jdrosen@dynamicsoft.com > Cc: hsalama@cisco.com; iptel@lists.bell-labs.com > Subject: RE: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt > Date: Friday, June 09, 2000 6:38AM > > My understanding about the reason of using the digit A, B, ... or F is to > avoid taking away the valid E.164 numbers from being assigned as subscriber > numbers. In ISUP Called Party Number parameter, there is a Nature of > Address (NOA) field. Some countries assigned a new NOA value > (country-specific) to indicate that routing number is concatenated with the > dialed called party number and may implicitly indicate that NP database dip > has been performed. If we use "rn" parameter in tel URL to carry the > routing number, we may need to define the rn in a way to allow 0-9 and A-F. > > The routing number, for example, "5xxxxx+ additional digits defined by the > assigned carrier" in UK, may have hierarchy where "5" indicates a routing > number for NP and "xxxxx" identifies the carrier. The "additional digits" > may have hierarchy. For example, BT may define the routing number to > identify the line card (concentrator) at the switch. This implies that > those "additional digits" can be divided at least into two levels: one > identifies the switch and the other the line card. > > James > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, June 08, 2000 5:38 PM > > To: James Yu > > Cc: 'hsalama@cisco.com'; 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-02.txt > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > > In the North America, the network routing numbers are > > > > called Location > > > > > Routing Numbers (LRNs). They "look" like subscriber phone > > > > numbers (e.g., > > > > > the same length) and can overlap with the subscriber phone > > > > numbers. In some > > > > > European countries, special digit (e.g., A and B) are used > > > > to differentiate > > > > > the network routing numbers from the subscriber phone > > > > numbers. Those > > > > > > > > I think TRIP should be extended advertising these > > European formats. Is > > > > this an extended form of E.164, or should it be a separate address > > > > family? > > > > > > Some of the routing numbers (or routig prefixes, as they are usually > > > prefixes to the dialed called party number) contain the > > digits outside 0-9 > > > (e.g., A, B, C, D, E, and F). They are valid routing > > numbers (national > > > numbers) either within one network (used by a particular > > network) or between > > > networks. Since they don't just contain digits 0-9, we may > > not say that > > > they follow E.164 format. > > > > Oh yuck. > > > > I'm curious how this impacts the aggregatability of such numbers? Are > > they assigned in such a way that they can still be aggregated even > > though there are these random letters in the phone number? Is > > there any > > kind of hierarchy in these numbers? > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- 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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 13 13:48:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16711 for ; Tue, 13 Jun 2000 13:48:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D5CFA44368; Tue, 13 Jun 2000 13:37:24 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by lists.bell-labs.com (Postfix) with ESMTP id 698FC44336 for ; Tue, 13 Jun 2000 13:37:21 -0400 (EDT) Received: from cisco.com (dhcp-171-71-147-141.cisco.com [171.71.147.141]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA27965; Tue, 13 Jun 2000 10:48:16 -0700 (PDT) Message-ID: <39467363.22030676@cisco.com> Date: Tue, 13 Jun 2000 10:46:11 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: Gonzalo Camarillo Cc: iptel Subject: Re: [IPTEL] Length in OPEN References: <3945CD52.22F836D6@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > Hi, > > Why is it needed the "optional parameter length" in the OPEN message if > the length of the whole message is already present in the fixed-sized > header? TRIP inherited this format from BGP. I don't know why the "optional parameters length" was included in BGP's OPEN message header. However, unless I am missing something, removing this two-byte field will not save us much, because the OPEN message only occurs once a session anyways. Hussein > > Thanks, > > Gonzalo > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- 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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 14 08:09:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17039 for ; Wed, 14 Jun 2000 08:09:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 049044437C; Wed, 14 Jun 2000 07:58:04 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from maliwan.psu.ac.th (unknown [192.100.77.4]) by lists.bell-labs.com (Postfix) with ESMTP id 8252D44336 for ; Wed, 14 Jun 2000 01:19:47 -0400 (EDT) Received: from hoya (gateway.coe.psu.ac.th [203.154.146.4]) by maliwan.psu.ac.th (8.9.1/8.9.1) with SMTP id MAA12085 for ; Wed, 14 Jun 2000 12:30:07 +0700 (GMT) Message-ID: <004801bfd5c1$f073f980$8300a8c0@coe.psu.ac.th> From: "Suntichai Chusywong" To: Date: Wed, 14 Jun 2000 12:29:27 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01BFD5FC.2E2C6700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] =?windows-874?B?51doZXJlIGNhbiBJIGdldCBmcmVlIEFTTi4xIENvbXBpbGVy?= Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_002D_01BFD5FC.2E2C6700 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable Where can I get free ASN.1 Compiler? ------=_NextPart_000_002D_01BFD5FC.2E2C6700 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
Where can I get free ASN.1 = Compiler?
 
------=_NextPart_000_002D_01BFD5FC.2E2C6700-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 14 12:44:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27743 for ; Wed, 14 Jun 2000 12:44:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9DD084434F; Wed, 14 Jun 2000 12:33:25 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mps3.leeds.ac.uk (sunserv5.leeds.ac.uk [129.11.16.35]) by lists.bell-labs.com (Postfix) with ESMTP id 2DC0E44336 for ; Wed, 14 Jun 2000 12:33:22 -0400 (EDT) Received: from electeng.leeds.ac.uk (electeng.leeds.ac.uk [129.11.178.99]) by mps3.leeds.ac.uk (8.9.3/8.9.3) with ESMTP id RAA09472; Wed, 14 Jun 2000 17:42:59 +0100 (BST) Received: from ELECTENG/SpoolDir by electeng.leeds.ac.uk (Mercury 1.43); 14 Jun 100 17:56:00 GMT Received: from SpoolDir by ELECTENG (Mercury 1.43); 14 Jun 100 17:55:24 GMT Received: from EENET.leeds.ac.uk (129.11.176.219) by electeng.leeds.ac.uk (Mercury 1.40); 14 Jun 100 17:55:16 GMT From: "Erickson Trejo-Reyes" To: "James Yu" , Cc: Date: Wed, 14 Jun 2000 17:43:46 +0100 Message-ID: <01bfd61f$b5ab5ce0$dbb00b81@EENET.leeds.ac.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01BFD628.176FC4E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Subject: [IPTEL] Call admission control Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_005E_01BFD628.176FC4E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everybody, =20 Does any of you have some references for specific call admission control = techniques that might have been considered for traffic engineering in = the IP for avoiding congestion in networks carrying telephony flows? = Thanks in advance, Erickson Trejo-Reyes University of Leeds Institute of Integrated Information Systems eenet@electeng.leeds.ac.uk Tel: +44 (113) 233-2019 Fax: +44 (113) 233-2032 ------=_NextPart_000_005E_01BFD628.176FC4E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi=20 everybody,

 

Does=20 any of you have some references for specific call admission control = techniques=20 that might have been considered for traffic engineering in the IP for = avoiding=20 congestion in networks carrying telephony flows? Thanks in=20 advance,
 
 
Erickson = Trejo-Reyes
University of = Leeds
Institute of Integrated = Information=20 Systems
eenet@electeng.leeds.ac.uk=
Tel: +44 (113) = 233-2019
Fax: +44 (113)=20 233-2032
------=_NextPart_000_005E_01BFD628.176FC4E0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 14 12:50:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27932 for ; Wed, 14 Jun 2000 12:50:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1B3844389; Wed, 14 Jun 2000 12:39:12 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from titan.ed.aculab.com (router.ed.aculab.com [129.215.188.198]) by lists.bell-labs.com (Postfix) with ESMTP id 9DE7544336 for ; Wed, 14 Jun 2000 12:39:09 -0400 (EDT) Received: from miranda (miranda.ed.aculab.com [192.168.3.14]) by titan.ed.aculab.com (8.9.3/8.9.3) with SMTP id RAA12668 for ; Wed, 14 Jun 2000 17:50:16 +0100 From: "Lesley Scott" To: Date: Wed, 14 Jun 2000 17:50:16 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: [IPTEL] h.245 logical channel conflict resolution Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, I'm looking for some input into the area of conflict resolution with unidirectional logical channel signalling procedures. My understanding of the H.245 specification is that the master terminal is expected to recognize conflicts between simultaneous open logical channel requests. If the master receives an open logical channel request from the slave which it determines to be incompatible with an open logical channel request that it has sent, it must reject the request from the slave. This being the case, when an OpenLogicalChannelReject is received by the slave terminal, how should it respond ??? Should it reattempt to open a logical channel that is compatible ?? The H.245 spec doesn't seem to address this. I hope someone can help me to clarify this somewhat shady area. thanks in advance Lesley Scott Aculab plc _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 14 13:59:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00156 for ; Wed, 14 Jun 2000 13:59:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 176CE443A1; Wed, 14 Jun 2000 13:46:53 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from qlink.queensu.ca (Qlink.QueensU.CA [130.15.129.2]) by lists.bell-labs.com (Postfix) with ESMTP id 96F7E4439C for ; Wed, 14 Jun 2000 13:46:49 -0400 (EDT) Received: from localhost (6jpm1@localhost) by qlink.queensu.ca (8.10.1/8.10.1) with ESMTP id e5EHvuO28799 for ; Wed, 14 Jun 2000 13:57:56 -0400 (EDT) Date: Wed, 14 Jun 2000 13:57:56 -0400 (EDT) From: "Mills, Jeff" <6jpm1@qlink.queensu.ca> To: iptel@lists.bell-labs.com Subject: [IPTEL] DTMF and packet loss Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Hello, I am looking for information regarding the effects of DTMF tones on packet loss in IP networks. As well, I'm also looking for more information about the distortion of DTMF tones during coding and packetization. Basically anything to do with DTMF and IP networks. Any help would be very much appreciated, even any suggestions as to where I could find good information would be appreciated. Thanks very much, Jeff Mills Queen's University Kingston, Ontario, Canada _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 14 15:36:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02795 for ; Wed, 14 Jun 2000 15:36:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F44A4438E; Wed, 14 Jun 2000 15:25:08 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id 285C9443A9 for ; Wed, 14 Jun 2000 12:44:16 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FW500801LO8RM@firewall.mcit.com> for iptel@lists.bell-labs.com; Wed, 14 Jun 2000 16:55:20 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FW5005O3LO874@firewall.mcit.com>; Wed, 14 Jun 2000 16:55:20 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) id <0FW500L01LO8MD@dgismtp01.wcomnet.com>; Wed, 14 Jun 2000 16:55:20 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FW500L01LNYFU@dgismtp01.wcomnet.com>; Wed, 14 Jun 2000 16:55:20 +0000 (GMT) Received: from C25776A ([166.44.138.246]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FW500L05LNSEU@dgismtp01.wcomnet.com>; Wed, 14 Jun 2000 16:55:08 +0000 (GMT) Date: Wed, 14 Jun 2000 17:54:49 -0500 From: Henry Sinnreich Subject: RE: [IPTEL] Call admission control In-reply-to: <01bfd61f$b5ab5ce0$dbb00b81@EENET.leeds.ac.uk> To: Erickson Trejo-Reyes , James Yu , hsalama@cisco.com Cc: iptel@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/alternative; boundary="Boundary_(ID_03xdaFEZr9Zb6FHCHPF6hg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. --Boundary_(ID_03xdaFEZr9Zb6FHCHPF6hg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Having enough bandwidth is a first step that comes to my mind. Predications show voice traffic will be only several % points on IP networks and the Internet, so why bother to complicate life just for voice. My two cents. Henry -----Original Message----- From: iptel-admin@lists.bell-labs.com [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Erickson Trejo-Reyes Sent: Wednesday, June 14, 2000 11:44 AM To: James Yu; hsalama@cisco.com Cc: iptel@lists.bell-labs.com Subject: [IPTEL] Call admission control Hi everybody, Does any of you have some references for specific call admission control techniques that might have been considered for traffic engineering in the IP for avoiding congestion in networks carrying telephony flows? Thanks in advance, Erickson Trejo-Reyes University of Leeds Institute of Integrated Information Systems eenet@electeng.leeds.ac.uk Tel: +44 (113) 233-2019 Fax: +44 (113) 233-2032 --Boundary_(ID_03xdaFEZr9Zb6FHCHPF6hg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Having=20 enough bandwidth is a first step that comes to my mind. Predications = show voice=20 traffic will be only several % points on IP networks and the Internet, = so why=20 bother to complicate life just for voice. My two = cents.
 
Henry
-----Original Message-----
From:=20 iptel-admin@lists.bell-labs.com = [mailto:iptel-admin@lists.bell-labs.com]On=20 Behalf Of Erickson Trejo-Reyes
Sent: Wednesday, June 14, = 2000=20 11:44 AM
To: James Yu; hsalama@cisco.com
Cc:=20 iptel@lists.bell-labs.com
Subject: [IPTEL] Call admission=20 control

Hi=20 everybody,

 

Does=20 any of you have some references for specific call admission control = techniques=20 that might have been considered for traffic engineering in the IP for = avoiding=20 congestion in networks carrying telephony flows? Thanks in=20 advance,
 
 
Erickson = Trejo-Reyes
University of = Leeds
Institute of Integrated = Information=20 Systems
eenet@electeng.leeds.ac.uk=
Tel: +44 (113)=20 233-2019
Fax: +44 (113)=20 233-2032
--Boundary_(ID_03xdaFEZr9Zb6FHCHPF6hg)-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 14 15:40:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02885 for ; Wed, 14 Jun 2000 15:40:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 770224439B; Wed, 14 Jun 2000 15:25:12 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from maliwan.psu.ac.th (unknown [192.100.77.4]) by lists.bell-labs.com (Postfix) with ESMTP id EA49344336 for ; Wed, 14 Jun 2000 15:02:31 -0400 (EDT) Received: from hoya (gateway.coe.psu.ac.th [203.154.146.4]) by maliwan.psu.ac.th (8.9.1/8.9.1) with SMTP id CAA04779 for ; Thu, 15 Jun 2000 02:13:30 +0700 (GMT) Message-ID: <001501bfd634$f75eeca0$8300a8c0@coe.psu.ac.th> From: "Suntichai Chusywong" To: Date: Thu, 15 Jun 2000 02:15:24 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01BFD66F.90AF8880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] Where can I get free ASN.1 Compiler Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0012_01BFD66F.90AF8880 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable Where can I get free ASN.1 Compiler? It will help me finish my project ------=_NextPart_000_0012_01BFD66F.90AF8880 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
Where can I get free ASN.1 Compiler? It = will help=20 me finish my project
------=_NextPart_000_0012_01BFD66F.90AF8880-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 14 16:37:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03946 for ; Wed, 14 Jun 2000 16:37:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E82D644388; Wed, 14 Jun 2000 16:26:14 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ns1.cirilium.com (ns1.cirilium.com [207.13.202.251]) by lists.bell-labs.com (Postfix) with ESMTP id 71B9344338 for ; Wed, 14 Jun 2000 16:26:10 -0400 (EDT) Received: from cirilium1.cirilium.com (mailserver.cirilium.com [10.40.3.4]) by ns1.cirilium.com (8.9.3/8.8.7) with ESMTP id NAA24960 for ; Wed, 14 Jun 2000 13:38:12 -0700 Received: from lcoxnt1 ([10.40.3.241]) by cirilium1.cirilium.com (Lotus Domino Release 5.0.3) with SMTP id 2000061413370347:3000 ; Wed, 14 Jun 2000 13:37:03 -0700 Message-Id: <4.1.20000614130745.00a4ca70@mail.neta.com> X-Sender: lcox@mail.neta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 14 Jun 2000 13:39:21 -0700 To: iptel@lists.bell-labs.com From: Larry Cox Subject: Re: [IPTEL] Call admission control In-Reply-To: <01bfd61f$b5ab5ce0$dbb00b81@EENET.leeds.ac.uk> Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at 06/14/2000 01:37:03 PM, Serialize by Router on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at 06/14/2000 01:37:18 PM, Serialize complete at 06/14/2000 01:37:18 PM Content-Type: text/plain; charset="us-ascii" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com At 05:43 PM 6/14/00 +0100, Erickson Trejo-Reyes wrote: > Hi everybody, > > >Does any of you have some references for specific call admission control >techniques that might have been considered for traffic engineering in the >IP for avoiding congestion in networks carrying telephony flows? >Thanks in advance, As you are probably already aware, the problem is both very serious and rather difficult to resolve. In a public Internet environment, even with significant free bandwidth, packet voice is frequently completely incomprehensible. Packet jitter can turn voice into nearly completely random noise. At present, the preferred procedure is to create a separate network dedicated to voice. The problem with this is a complete negation of the primary reason for using VoIP. If you have a separate network anyway, the existing circuit switched network is a known quantity with very high reliability and voice over ATM is more efficient than voice over IP. RSVP-TE, Diffserv, and MPLS appear to be the direction that the industry is going. The combination will allow for traffic engineering, priority of service for time critical streams, and failure recovery. You may want to check the MPLS list. They are working with the issues related to latency and jitter. They are also working toward traffic engineering and resolving the failure recovery problem. send an email to . I do not remember if subscribe needs to be in the subject line or the body. I think that I sent both. Larry _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 14 16:50:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04082 for ; Wed, 14 Jun 2000 16:50:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 317DC443B1; Wed, 14 Jun 2000 16:39:12 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cybertron.div8.net (cr703217-a.ktchnr1.on.wave.home.com [24.42.217.5]) by lists.bell-labs.com (Postfix) with ESMTP id EA81C44338 for ; Wed, 14 Jun 2000 16:39:08 -0400 (EDT) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for iptel@lists.bell-labs.com; Wed, 14 Jun 2000 16:50:17 -0400 (EDT) Date: Wed, 14 Jun 2000 16:50:17 -0400 From: Billy Biggs To: Larry Cox Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Call admission control Message-ID: <20000614165016.A25730@div8.net> References: <01bfd61f$b5ab5ce0$dbb00b81@EENET.leeds.ac.uk> <4.1.20000614130745.00a4ca70@mail.neta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <4.1.20000614130745.00a4ca70@mail.neta.com>; from lcox@neta.com on Wed, Jun 14, 2000 at 01:39:21PM -0700 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Larry Cox (lcox@neta.com): > >Does any of you have some references for specific call admission control > >techniques that might have been considered for traffic engineering in the > >IP for avoiding congestion in networks carrying telephony flows? > >Thanks in advance, > > As you are probably already aware, the problem is both very serious and > rather difficult to resolve. In a public Internet environment, even with > significant free bandwidth, packet voice is frequently completely > incomprehensible. Packet jitter can turn voice into nearly completely > random noise. Larry, Not that this is the right forum or even the right thread, I'm very curious about your statements on the unreliability of packet voice over the public Internet. I've now had several trans-atlantic telephone calls over the public Internet, and often use packet voice for shorter range (100ms avg lag, 20 hops) Internet calls. 64kbps u-law, RTP encapsulated in each direction. I have never experienced the audio to be 'incomprehensible'. Even with no traffic shaping or control, and even when talking to people on cable modems with reasonable amounts of traffic, it's still much better than most cellphones. Do you have any references to papers or web pages which indicate that strong admission control or traffic management is useful beyond very extreme networks or specifc cases of heavy bandwidth applications? In general, TCP seems back off quite happily. -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 15 18:28:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16119 for ; Thu, 15 Jun 2000 18:28:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 862EE443B8; Thu, 15 Jun 2000 18:16:28 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id DD02244336 for ; Thu, 15 Jun 2000 16:44:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 15 16:54:21 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5A55244346; Thu, 15 Jun 2000 16:41:11 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 3411E44345 for ; Thu, 15 Jun 2000 16:41:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 92E2C52C4; Thu, 15 Jun 2000 16:41:19 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 80CBD52AB for ; Thu, 15 Jun 2000 16:41:16 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jun 15 16:40:34 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu Jun 15 16:40:33 EDT 2000 Received: from dynamicsoft.com (1Cust213.tnt2.freehold.nj.da.uu.net [63.17.114.213]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA22917; Thu, 15 Jun 2000 16:41:18 -0400 (EDT) Message-ID: <39493F3E.B7753B1F@dynamicsoft.com> Date: Thu, 15 Jun 2000 16:40:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IMPP WG Cc: sip , rem-conf@es.net, "iptel, list" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] proposal for IMPP Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Folks, Some colleagues and I have put together a suite of protocols for IMPP, based partly on SIP. Its actually seven separate drafts, althouth the core is just two. They have been submitted to the I-D editor, but you can grab them right now from: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-presence-00.txt Core presence protocol. We've written it to be understandable by non SIP experts, and to also indicate what parts of SIP you do and don't need for presence. Don't be scared by the size (70 pages), nearly half are example message flows. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-im-00.txt Core IM protocol. Also written to be both a tutorial on SIP and explain how to do IM. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-qauth-00.txt A mini-protocol for authorizing subscriptions, to support, among other things, the ability for subscriptions to happen when the presentity is offline. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-pidf-00.txt An XML PIDF format, optional in our architecture. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-lpidf-00.txt A really thin pidf, good for wireless devices, since it uses the same parser SIP uses. This is mandatory to support in our architecture. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-watcherinfo-00.txt A format for watcher info. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-buddylist-00.txt Something we never discussed on the list before; a buddylist document, much akin to bookmarks, which you can store on a server. This way, when you go to a different machine, you can fetch your buddylist, and get your presence services there. Comments and questions are welcome, of course. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 15 22:33:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22180 for ; Thu, 15 Jun 2000 22:33:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C0F744346; Thu, 15 Jun 2000 22:21:42 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id E623944336 for ; Thu, 15 Jun 2000 18:24:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 15 18:34:24 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 8611144347; Thu, 15 Jun 2000 18:21:14 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 58DD344345 for ; Thu, 15 Jun 2000 18:21:14 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DB16852C4; Thu, 15 Jun 2000 18:21:17 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D8AD552AB for ; Thu, 15 Jun 2000 18:21:15 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jun 15 18:19:11 EDT 2000 Received: from sd_exchange.nuera.com ([204.216.240.98]) by dusty; Thu Jun 15 18:19:09 EDT 2000 Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 15:19:03 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE7F35E6@sd_exchange.nuera.com> From: "Fox, Mike" To: Jonathan Rosenberg , IMPP WG Cc: sip , rem-conf@es.net, "iptel, list" Date: Thu, 15 Jun 2000 15:18:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] RE: proposal for IMPP Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Why stop at XML for IMPP? Why not XML for SIP? Simple Object Access Protocol may be the right way. Call it SIP Control by Unified Methods. SOAP SCUM Best regards, Mike Fox _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 15 22:35:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22203 for ; Thu, 15 Jun 2000 22:35:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 973F74439B; Thu, 15 Jun 2000 22:22:00 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from Aries.utstar.com (mail.utstar.com [205.185.99.6]) by lists.bell-labs.com (Postfix) with ESMTP id 0604B44383 for ; Thu, 15 Jun 2000 19:51:52 -0400 (EDT) Received: from JAMES-YANG.wacos (w234.z209220043.sjc-ca.dsl.cnc.net [209.220.43.234]) by Aries.utstar.com (8.10.0/8.10.0) with SMTP id e5G030g15852; Thu, 15 Jun 2000 20:03:01 -0400 (EDT) Received: by JAMES-YANG.wacos with Microsoft Mail id <01BFD6EB.87C55B60@JAMES-YANG.wacos>; Thu, 15 Jun 2000 17:02:47 -0700 Message-ID: <01BFD6EB.87C55B60@JAMES-YANG.wacos> From: "james.yang" To: "'Billy Biggs'" , Larry Cox Cc: "iptel@lists.bell-labs.com" Subject: RE: [IPTEL] Call admission control Date: Thu, 15 Jun 2000 17:02:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA22203 Hi, Call admission control is a traditional concept derived from PSTN, ISDN, SONET and ATM networks. Because there is no global resource management on IP network, any effort on call-based resource allocation or traffic engineering in network layer (IP) is opposite to the fundament of Internet. Existing technologies for providing QoS guaranteed call on Internet is session layer control such as RSVP, RTP and MPLS. But they assume that the network has unlimited resource. If you desire to make traffic engineering on resource-limited Internet and refuse some new calls while the traffic is in congestion somewhere, you need a global resource management server, which surveys the traffic on routers and links, as well as free process capacity in routers and residual bandwidth on links. All access points act as the agent of the server and execute admission control functions. Is it possible? No. The only solution for this issue is hierarchical dynamic statistical routing optimization protocol. It intends to update routing tables dynamically in order to reserve enough free resource on routers and links for further use. It can be used with any resource reservation protocol. I have taken a very careful study on it and propose a framework for it, but I don't know whether it has been realized and implemented by now. James -----Original Message----- From: Billy Biggs [SMTP:vektor@div8.net] Sent: Wednesday, June 14, 2000 1:50 PM To: Larry Cox Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Call admission control Larry Cox (lcox@neta.com): > >Does any of you have some references for specific call admission control > >techniques that might have been considered for traffic engineering in the > >IP for avoiding congestion in networks carrying telephony flows? > >Thanks in advance, > > As you are probably already aware, the problem is both very serious and > rather difficult to resolve. In a public Internet environment, even with > significant free bandwidth, packet voice is frequently completely > incomprehensible. Packet jitter can turn voice into nearly completely > random noise. Larry, Not that this is the right forum or even the right thread, I'm very curious about your statements on the unreliability of packet voice over the public Internet. I've now had several trans-atlantic telephone calls over the public Internet, and often use packet voice for shorter range (100ms avg lag, 20 hops) Internet calls. 64kbps u-law, RTP encapsulated in each direction. I have never experienced the audio to be 'incomprehensible'. Even with no traffic shaping or control, and even when talking to people on cable modems with reasonable amounts of traffic, it's still much better than most cellphones. Do you have any references to papers or web pages which indicate that strong admission control or traffic management is useful beyond very extreme networks or specifc cases of heavy bandwidth applications? In general, TCP seems back off quite happily. -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 19 15:50:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21900 for ; Mon, 19 Jun 2000 15:50:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 494E64433C; Mon, 19 Jun 2000 15:38:01 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id BDDA544336 for ; Mon, 19 Jun 2000 14:22:12 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jun 19 14:32:30 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 413A644346; Mon, 19 Jun 2000 14:19:21 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 1A2EC44345 for ; Mon, 19 Jun 2000 14:19:21 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 988D252C4; Mon, 19 Jun 2000 14:19:17 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A181252AB for ; Mon, 19 Jun 2000 14:19:14 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Jun 19 14:18:26 EDT 2000 Received: from maliwan.psu.ac.th ([192.100.77.4]) by dusty; Mon Jun 19 14:18:24 EDT 2000 Received: from hoya (gateway.coe.psu.ac.th [203.154.146.4]) by maliwan.psu.ac.th (8.9.1/8.9.1) with SMTP id BAA26523; Tue, 20 Jun 2000 01:18:15 +0700 (GMT) Message-ID: <002f01bfda1b$1489a380$8300a8c0@coe.psu.ac.th> From: "Suntichai Chusywong" To: Cc: Date: Tue, 20 Jun 2000 01:20:11 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01BFDA55.AE04F8E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] Master - Slave Determination Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_002C_01BFDA55.AE04F8E0 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable I wonder when Master - Slave Determinaiton message wil be sent, before = or after sending Terminal Capability Set message? After Determining = which Endpoint is master, what do we use this result for? I don't understand how to encoding H.245 message, what will I do if I = want to encode these message easily. If you have any tool to help me, = please send me =20 Thank = you very much=20 = Suntichai Chuaywong ------=_NextPart_000_002C_01BFDA55.AE04F8E0 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
I wonder when Master - Slave=20 Determinaiton message wil be sent, before or after sending Terminal = Capability Set message? After Determining which Endpoint is master, what = do we=20 use this result for?
 
 I don't understand how to = encoding H.245=20 message, what will I do if I want to encode these message easily. If you = have=20 any tool to help me, please send me
        =
        =    =20             =    =20             =    =20             =    =20     Thank you very much
        =    =20             =    =20             =    =20             =    =20             =    =20 Suntichai Chuaywong
------=_NextPart_000_002C_01BFDA55.AE04F8E0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 20 11:15:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25625 for ; Tue, 20 Jun 2000 11:15:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D383944354; Tue, 20 Jun 2000 11:02:41 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 127944435D for ; Tue, 20 Jun 2000 10:46:07 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jun 20 10:56:21 EDT 2000 Received: by lists.bell-labs.com (Postfix) id BA2A74434C; Tue, 20 Jun 2000 10:43:11 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 9140A44349 for ; Tue, 20 Jun 2000 10:43:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E07FB52C4; Tue, 20 Jun 2000 10:43:18 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 02DEF52AB for ; Tue, 20 Jun 2000 10:43:14 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Jun 20 10:41:45 EDT 2000 Received: from ertpg15e1.nortelnetworks.com ([47.234.0.36]) by dusty; Tue Jun 20 10:41:40 EDT 2000 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg15e1.nortelnetworks.com; Tue, 20 Jun 2000 10:38:02 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 10:36:25 -0400 Message-ID: <28560036253BD41191A10000F8BCBD11480AE7@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Suntichai Chusywong'" , iptel Subject: RE: [IPTEL] Master - Slave Determination Date: Tue, 20 Jun 2000 10:36:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDAC4.E89EBF8A" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com 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_01BFDAC4.E89EBF8A Content-Type: text/plain Terminal Capability Set comes first. See Rec. H.323 section 8.2. Encoding H.245 requires detailed understanding of ASN.1 Packed Encoding Rules (very few people are willing to undertake this task) or use of a commercial compiler provided by OSS. You can also buy stacks from various providers. If you want to acquire the documents defining ASN.1 Packed Encoding Rules (ITU-T Recommendations X.680 and X.691), you can purchase them from the ITU-T at http://www.itu.int/ITU-T/index.html > -----Original Message----- > From: Suntichai Chusywong [SMTP:s4110400@maliwan.psu.ac.th] > Sent: Monday, June 19, 2000 2:20 PM > To: iptel > Cc: s4110400 > Subject: [IPTEL] Master - Slave Determination > > I wonder when Master - Slave Determinaiton message wil be sent, before or > after sending Terminal Capability Set message? After Determining which > Endpoint is master, what do we use this result for? > > I don't understand how to encoding H.245 message, what will I do if I > want to encode these message easily. If you have any tool to help me, > please send me > > Thank you > very much > > Suntichai Chuaywong ------_=_NextPart_001_01BFDAC4.E89EBF8A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IPTEL] Master - Slave Determination

Terminal Capability = Set comes first.  See Rec. H.323 section 8.2.  Encoding H.245 = requires detailed understanding of ASN.1 Packed Encoding Rules (very = few people are willing to undertake this task) or use of a commercial = compiler provided by OSS.  You can also buy stacks from various = providers.  If you want to acquire the documents defining ASN.1 = Packed Encoding Rules (ITU-T Recommendations X.680 and X.691), you can = purchase them from the ITU-T at http://www.itu.int/ITU-T/index.html =

    -----Original Message-----
    From:   Suntichai Chusywong = [SMTP:s4110400@maliwan.psu.ac.th]
    Sent:   Monday, June 19, 2000 2:20 PM
    To:     iptel
    Cc:     s4110400
    Subject:       = [IPTEL] Master - Slave = Determination

    I wonder when Master - Slave = Determinaiton=A0message wil be = sent, before or after sending Terminal Capability Set message? After = Determining which Endpoint is master, what do we use this result = for?

    =A0
    =A0I don't understand how to encoding = H.245 message, what will I do if I want to encode these message easily. = If you have any tool to help me, please send me

    =A0=A0=A0 =A0=A0=A0=20
    =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Thank you = very much=20
    =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 =A0=A0=A0 Suntichai Chuaywong

------_=_NextPart_001_01BFDAC4.E89EBF8A-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 20 13:05:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29433 for ; Tue, 20 Jun 2000 13:05:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BD9B644364; Tue, 20 Jun 2000 12:53:02 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 02F244434F for ; Tue, 20 Jun 2000 12:20:05 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jun 20 12:30:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 53EDD4434A; Tue, 20 Jun 2000 12:17:09 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 2DAC144349 for ; Tue, 20 Jun 2000 12:17:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id EF11B52C4; Tue, 20 Jun 2000 12:17:16 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 1424552AB for ; Tue, 20 Jun 2000 12:17:13 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Jun 20 12:15:54 EDT 2000 Received: from maliwan.psu.ac.th ([192.100.77.4]) by dusty; Tue Jun 20 12:15:52 EDT 2000 Received: from hoya (gateway.coe.psu.ac.th [203.154.146.4]) by maliwan.psu.ac.th (8.9.1/8.9.1) with SMTP id XAA10969 for ; Tue, 20 Jun 2000 23:15:41 +0700 (GMT) Message-ID: <001801bfdad3$1edb33e0$8300a8c0@coe.psu.ac.th> From: "Suntichai Chusywong" To: Date: Tue, 20 Jun 2000 23:17:36 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01BFDB0D.B8B216C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] Master - Slave Determination Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0015_01BFDB0D.B8B216C0 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable I wonder when Master - Slave Determinaiton message wil be sent, before = or after sending Terminal Capability Set message? After Determining = which Endpoint is master, what do we use this result for? =20 Thank = you very much=20 = Suntichai Chuaywong ------=_NextPart_000_0015_01BFDB0D.B8B216C0 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
I wonder when Master - Slave=20 Determinaiton message wil be sent, before or after sending Terminal = Capability Set message? After Determining which Endpoint is master, what = do we=20 use this result for?
 
        =
        =    =20             =    =20             =    =20             =    =20     Thank you very much
        =    =20             =    =20             =    =20             =    =20             =    =20 Suntichai Chuaywong
------=_NextPart_000_0015_01BFDB0D.B8B216C0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 20 20:24:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06722 for ; Tue, 20 Jun 2000 20:24:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7D1104435D; Tue, 20 Jun 2000 20:12:21 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from seattle_exs1.nutel.net (unknown [63.211.198.144]) by lists.bell-labs.com (Postfix) with ESMTP id 06AC04433A for ; Tue, 20 Jun 2000 20:12:18 -0400 (EDT) Received: by 144.bzln.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 17:25:41 -0700 Message-ID: <70D677608846D41184E20050DA7AA6600D41D1@144.bzln.com> From: Ron Traficante To: "'Lesley Scott'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] h.245 logical channel conflict resolution Date: Tue, 20 Jun 2000 17:25:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com May have an answer to this - would be interested in any other input though: Referencing H.245 (February 6, 1998) - it appears that when the slave sends out the OpenLogicalChannel, it then goes into the Awaiting Establishment state - (refer to Figure 10 in section 8.4.2.5.) Upon receipt of the OpenLogicalChannelRej - the slave should reset T103, send a Release Indication to the protocol user, and go into the Released state (Figure 13 section 8.4.4.5). At this point, it appears from figure 10 that it is "legal" from the H.245 protocol standpoint to reenter the awaiting establishment state, which would imply that the protocol user has the option to resend another OpenLogicalChannel. -----Original Message----- From: Lesley Scott [mailto:lesley.scott@aculab.com] Sent: Wednesday, June 14, 2000 9:50 AM To: iptel@lists.bell-labs.com Subject: [IPTEL] h.245 logical channel conflict resolution Hi, I'm looking for some input into the area of conflict resolution with unidirectional logical channel signalling procedures. My understanding of the H.245 specification is that the master terminal is expected to recognize conflicts between simultaneous open logical channel requests. If the master receives an open logical channel request from the slave which it determines to be incompatible with an open logical channel request that it has sent, it must reject the request from the slave. This being the case, when an OpenLogicalChannelReject is received by the slave terminal, how should it respond ??? Should it reattempt to open a logical channel that is compatible ?? The H.245 spec doesn't seem to address this. I hope someone can help me to clarify this somewhat shady area. thanks in advance Lesley Scott Aculab plc _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 20 20:28:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06788 for ; Tue, 20 Jun 2000 20:28:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 908684436F; Tue, 20 Jun 2000 20:14:48 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from seattle_exs1.nutel.net (unknown [63.211.198.144]) by lists.bell-labs.com (Postfix) with ESMTP id 1191844369 for ; Tue, 20 Jun 2000 20:14:45 -0400 (EDT) Received: by 144.bzln.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 17:28:09 -0700 Message-ID: <70D677608846D41184E20050DA7AA6600D41D2@144.bzln.com> From: Ron Traficante To: "'Suntichai Chusywong'" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] Master - Slave Determination Date: Tue, 20 Jun 2000 17:28:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDB17.92ED6368" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com 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_01BFDB17.92ED6368 Content-Type: text/plain; charset="windows-874" Since the portion of your question regarding message order has already been answered - I will take a crack at the second part regarding what the result is used for. There are cases where two or more endpoints/terminals may initiate events simultaneously where there is a resource conflict - in this case it is necessary for the master endpoint to in order to resolve the conflict. A very good example is the logical channel determination, where each endpoint needs to establish a unique channel for the data streams, and since they are half-duplex, each two way "conversation" requires two channels. Thus - if both endpoints choose the same logical channel for it's part of the conversation, this results in a conflict. How this is "resolved" is an issue of another message on this board as well. Additionally - in H.235, the master is also responsible for the distribution of the encryption keys for media channels to other terminals. -----Original Message----- From: Suntichai Chusywong [mailto:s4110400@maliwan.psu.ac.th] Sent: Tuesday, June 20, 2000 9:18 AM To: iptel@lists.research.bell-labs.com Subject: [IPTEL] Master - Slave Determination I wonder when Master - Slave Determinaiton message wil be sent, before or after sending Terminal Capability Set message? After Determining which Endpoint is master, what do we use this result for? Thank you very much Suntichai Chuaywong ------_=_NextPart_001_01BFDB17.92ED6368 Content-Type: text/html; charset="windows-874"
Since the portion of your question regarding message order has already been answered - I will take a crack at the second part regarding what the result is used for.
 
There are cases where two or more endpoints/terminals may initiate events simultaneously where there is a resource conflict - in this case it is necessary for the master endpoint to in order to resolve the conflict.  A very good example is the logical channel determination, where each endpoint needs to establish a unique channel for the data streams, and since they are half-duplex, each two way "conversation" requires two channels.  Thus - if both endpoints choose the same logical channel for it's part of the conversation, this results in a conflict.  How this is "resolved" is an issue of another message on this board as well. 
 
Additionally - in H.235, the master is also responsible for the distribution of the encryption keys for media channels to other terminals. 
-----Original Message-----
From: Suntichai Chusywong [mailto:s4110400@maliwan.psu.ac.th]
Sent: Tuesday, June 20, 2000 9:18 AM
To: iptel@lists.research.bell-labs.com
Subject: [IPTEL] Master - Slave Determination

I wonder when Master - Slave Determinaiton message wil be sent, before or after sending Terminal Capability Set message? After Determining which Endpoint is master, what do we use this result for?
 
       
                                                                Thank you very much
                                                                            Suntichai Chuaywong
------_=_NextPart_001_01BFDB17.92ED6368-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 21 08:44:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29581 for ; Wed, 21 Jun 2000 08:44:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 176274433A; Wed, 21 Jun 2000 08:32:38 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 9D3AF4433A for ; Tue, 20 Jun 2000 20:06:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jun 20 20:16:23 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1DEC344348; Tue, 20 Jun 2000 20:03:14 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E925F44347 for ; Tue, 20 Jun 2000 20:03:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id EEF1F52C4; Tue, 20 Jun 2000 20:03:17 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 31B5452B6 for ; Tue, 20 Jun 2000 20:03:14 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Jun 20 20:02:46 EDT 2000 Received: from seattle_exs1.nutel.net ([63.211.198.144]) by dusty; Tue Jun 20 20:02:45 EDT 2000 Received: by 144.bzln.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 17:04:10 -0700 Message-ID: <70D677608846D41184E20050DA7AA6600D41D0@144.bzln.com> From: Ron Traficante To: "'Suntichai Chusywong'" , iptel@lists.research.bell-labs.com Subject: RE: [IPTEL] Master - Slave Determination Date: Tue, 20 Jun 2000 17:04:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDB14.38FBCF1E" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com 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_01BFDB14.38FBCF1E Content-Type: text/plain; charset="windows-874" Since the portion of your question regarding message order has already been answered - I will take a crack at the second part regarding what the result is used for. There are cases where two or more endpoints/terminals may initiate events simultaneously where there is a resource conflict - in this case it is necessary for the master endpoint to in order to resolve the conflict. A very good example is the logical channel determination, where each endpoint needs to establish a unique channel for the data streams, and since they are half-duplex, each two way "conversation" requires two channels. Thus - if both endpoints choose the same logical channel for it's part of the conversation, this results in a conflict. How this is "resolved" is an issue of another message on this board as well. Additionally - in H.235, the master is also responsible for the distribution of the encryption keys for media channels to other terminals. -----Original Message----- From: Suntichai Chusywong [mailto:s4110400@maliwan.psu.ac.th] Sent: Tuesday, June 20, 2000 9:18 AM To: iptel@lists.research.bell-labs.com Subject: [IPTEL] Master - Slave Determination I wonder when Master - Slave Determinaiton message wil be sent, before or after sending Terminal Capability Set message? After Determining which Endpoint is master, what do we use this result for? Thank you very much Suntichai Chuaywong ------_=_NextPart_001_01BFDB14.38FBCF1E Content-Type: text/html; charset="windows-874"
Since the portion of your question regarding message order has already been answered - I will take a crack at the second part regarding what the result is used for.
 
There are cases where two or more endpoints/terminals may initiate events simultaneously where there is a resource conflict - in this case it is necessary for the master endpoint to in order to resolve the conflict.  A very good example is the logical channel determination, where each endpoint needs to establish a unique channel for the data streams, and since they are half-duplex, each two way "conversation" requires two channels.  Thus - if both endpoints choose the same logical channel for it's part of the conversation, this results in a conflict.  How this is "resolved" is an issue of another message on this board as well. 
 
Additionally - in H.235, the master is also responsible for the distribution of the encryption keys for media channels to other terminals. 
-----Original Message-----
From: Suntichai Chusywong [mailto:s4110400@maliwan.psu.ac.th]
Sent: Tuesday, June 20, 2000 9:18 AM
To: iptel@lists.research.bell-labs.com
Subject: [IPTEL] Master - Slave Determination

I wonder when Master - Slave Determinaiton message wil be sent, before or after sending Terminal Capability Set message? After Determining which Endpoint is master, what do we use this result for?
 
       
                                                                Thank you very much
                                                                            Suntichai Chuaywong
------_=_NextPart_001_01BFDB14.38FBCF1E-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 21 12:10:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05888 for ; Wed, 21 Jun 2000 12:10:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 40EE844373; Wed, 21 Jun 2000 11:58:20 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 3CBA34435A for ; Wed, 21 Jun 2000 11:58:16 -0400 (EDT) Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA03613; Wed, 21 Jun 2000 17:08:28 +0100 (BST) Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id RAA29686; Wed, 21 Jun 2000 17:08:27 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Wed, 21 Jun 2000 17:08:27 +0000 (GMT) From: James Undery To: lennox@cs.columbia.edu Cc: iptel@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [IPTEL] draft-ietf-cpl-01 the DTD Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Hi, Just a quick observation, I know The CPL DTD got a mauling on the iptel mailing group a while back, but I think Nilo missed a mistake in the DTD, is what the text describes, rather than in the draft's DTD. I am also interested in how seriously XML schemas are being considered as I think there are some areas where the DTD could be tightened up, but, don't want to waste time if the DTD is binned in favour of a schema. James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 22 10:10:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06480 for ; Thu, 22 Jun 2000 10:10:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 258234438B; Thu, 22 Jun 2000 09:58:25 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 980AF44339 for ; Wed, 21 Jun 2000 15:42:00 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jun 21 15:52:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2624B44348; Wed, 21 Jun 2000 15:39:11 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E896C44347 for ; Wed, 21 Jun 2000 15:39:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id BAEB152C4; Wed, 21 Jun 2000 15:39:16 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C699D52B6 for ; Wed, 21 Jun 2000 15:39:13 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jun 21 15:38:39 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed Jun 21 15:38:38 EDT 2000 Received: from dynamicsoft.com (1Cust239.tnt2.freehold.nj.da.uu.net [63.17.114.239]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA16118; Wed, 21 Jun 2000 15:39:41 -0400 (EDT) Message-ID: <395119F9.FC266BA5@dynamicsoft.com> Date: Wed, 21 Jun 2000 15:39:37 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Suntichai Chusywong Cc: iptel@lists.research.bell-labs.com Subject: Re: [IPTEL] Master - Slave Determination References: <002f01bfda1b$1489a380$8300a8c0@coe.psu.ac.th> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit This list is not meant for H.323 questions. Please use the H.323 implementors list (which I always lose my reference to --- someone?) -Jonathan R. > Suntichai Chusywong wrote: > > I wonder when Master - Slave Determinaiton message wil be sent, before > or after sending Terminal Capability Set message? After Determining > which Endpoint is master, what do we use this result for? > > I don't understand how to encoding H.245 message, what will I do if I > want to encode these message easily. If you have any tool to help me, > please send me > > Thank > you very much > > Suntichai Chuaywong -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 22 11:01:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07539 for ; Thu, 22 Jun 2000 11:01:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7BB13443A0; Thu, 22 Jun 2000 10:48:27 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 3E37F4437F for ; Thu, 22 Jun 2000 10:48:24 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Thu, 22 Jun 2000 09:55:49 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 09:58:56 -0500 Message-ID: <2E532B03F035D3119AF40000F80932C37B6EAC@crchy28d.us.nortel.com> From: "Shantala Manchenahally" To: lennox@cs.columbia.edu Cc: iptel@lists.bell-labs.com, "Trip Ingle" Subject: [IPTEL] draft-ietf-cpl-01 the DTD Date: Thu, 22 Jun 2000 09:58:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDC5A.635D7AC2" X-Orig: Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com 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_01BFDC5A.635D7AC2 Content-Type: text/plain; charset="iso-8859-1" Hi, I need a few clarifications regarding the timezone element. The timezone element as described in the text seems to be rather than in the draft's DTD. My understanding is that the standard and daylight element(if present) have to occur as a pair with atmost one occurence for a particular year and timezone. The DTD, however, does allow the possibility of defining more than one set of (standard & daylight) per year per timezone. Is this required ? Also the entity ZoneParams has attribute 'offset' missing from the attribute list in the DTD. Thanks, Shantala. ------_=_NextPart_001_01BFDC5A.635D7AC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [IPTEL] draft-ietf-cpl-01 the DTD

Hi,

I need a few clarifications regarding the timezone = element.

The timezone element as described in the text seems = to be

        <!ELEMENT timezone ( standard, daylight? )+ >

rather than

        <!ELEMENT timezone ( standard, daylight? ) >

in the draft's DTD.

My understanding is that the standard and daylight = element(if present) have to occur as a pair with atmost one occurence = for a  particular year and timezone. The DTD, however, does allow = the possibility of defining more than one set of  (standard & = daylight) per year per timezone. Is this required ?

Also the entity ZoneParams has  attribute = 'offset' missing from the attribute list in the DTD.


Thanks,
Shantala.

------_=_NextPart_001_01BFDC5A.635D7AC2-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 22 11:28:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08392 for ; Thu, 22 Jun 2000 11:28:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4FF61443A9; Thu, 22 Jun 2000 11:08:30 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id B514A443A6 for ; Thu, 22 Jun 2000 11:08:24 -0400 (EDT) Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA22657; Thu, 22 Jun 2000 16:18:45 +0100 (BST) Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id QAA02787; Thu, 22 Jun 2000 16:18:43 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Thu, 22 Jun 2000 16:18:43 +0000 (GMT) From: James Undery To: Shantala Manchenahally Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] draft-ietf-cpl-01 the DTD In-Reply-To: <2E532B03F035D3119AF40000F80932C37B6EAC@crchy28d.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com On Thu, 22 Jun 2000, Shantala Manchenahally wrote: > Hi, > > I need a few clarifications regarding the timezone element. > > The timezone element as described in the text seems to be > > This is stricter than my version and doesn't allow a universal 'standard' with 'daylight' different for different years. > > rather than > > > > in the draft's DTD. > > My understanding is that the standard and daylight element(if present) have > to occur as a pair with atmost one occurence for a particular year and > timezone. The DTD, however, does allow the possibility of defining more than > one set of (standard & daylight) per year per timezone. Is this required ? > Your version doesn't provide that, your reading should be expressed as obviously some semantics are lost here. > Also the entity ZoneParams has attribute 'offset' missing from the > attribute list in the DTD. > not in 01 James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 22 12:49:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10070 for ; Thu, 22 Jun 2000 12:49:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82DDB44392; Thu, 22 Jun 2000 12:37:17 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 2D18C44339 for ; Thu, 22 Jun 2000 10:27:51 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Thu Jun 22 10:38:59 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 4CF2E44349; Thu, 22 Jun 2000 10:25:50 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 209C944347 for ; Thu, 22 Jun 2000 10:25:50 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A433C52C4; Thu, 22 Jun 2000 10:25:15 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id B54D952AB for ; Thu, 22 Jun 2000 10:25:12 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Jun 22 10:23:40 EDT 2000 Received: from hvmta02-stg.us.psimail.psi.net ([38.202.36.30]) by dusty; Thu Jun 22 10:23:38 EDT 2000 Received: from orit ([38.150.216.6]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20000622142332.DBXH26052.hvmta02-stg@orit> for ; Thu, 22 Jun 2000 10:23:32 -0400 Message-ID: <002901bfdc56$8ca22d00$73d896c0@orit.us.radvision.com> Reply-To: "Orit Levin" From: "Orit Levin" To: Subject: Re: [IPTEL] H.323 Reflector [Was: Master - Slave Determination] Date: Thu, 22 Jun 2000 10:31:27 -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: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Here it is. Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com Below is the description for two mailing lists: Implementers 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. ------------------------------------------------- -----Original Message----- From: Jonathan Rosenberg To: Suntichai Chusywong Cc: iptel@lists.research.bell-labs.com Date: Thursday, June 22, 2000 10:12 AM Subject: Re: [IPTEL] Master - Slave Determination >This list is not meant for H.323 questions. Please use the H.323 >implementors list (which I always lose my reference to --- someone?) > >-Jonathan R. > >> Suntichai Chusywong wrote: >> >> I wonder when Master - Slave Determinaiton message wil be sent, before >> or after sending Terminal Capability Set message? After Determining >> which Endpoint is master, what do we use this result for? >> >> I don't understand how to encoding H.245 message, what will I do if I >> want to encode these message easily. If you have any tool to help me, >> please send me >> >> Thank >> you very much >> >> Suntichai Chuaywong > >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >http://www.dynamicsoft.com > > > >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 22 12:53:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10151 for ; Thu, 22 Jun 2000 12:53:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 991FA443B6; Thu, 22 Jun 2000 12:37:36 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id CED0444392 for ; Thu, 22 Jun 2000 11:23:48 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Thu Jun 22 11:34:16 EDT 2000 Received: by lists.bell-labs.com (Postfix) id ADC0944349; Thu, 22 Jun 2000 11:21:07 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 8474844347 for ; Thu, 22 Jun 2000 11:21:07 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8923252C4; Thu, 22 Jun 2000 11:21:13 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 10AA052B6 for ; Thu, 22 Jun 2000 11:21:12 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Jun 22 11:20:27 EDT 2000 Received: from mel.alcatel.fr ([212.208.74.132]) by dusty; Thu Jun 22 11:20:25 EDT 2000 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id RAA19398 for ; Thu, 22 Jun 2000 17:19:49 +0200 From: Satish.Yadav@amns.alcatel.fr Received: from amns.alcatel.fr (dnsamns.amns.alcatel.fr [159.217.103.207]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with SMTP id RAA06141 for ; Thu, 22 Jun 2000 17:19:34 +0200 (MET DST) Received: from POP3 Client by amns.alcatel.fr (ccMail Link to SMTP R8.10.00) id AA961689092; Thu, 22 Jun 2000 21:53:45 +0530 Message-Id: <0006229616.AA961689092@amns.alcatel.fr> X-Mailer: ccMail Link to SMTP R8.10.00 Date: Thu, 22 Jun 2000 20:47:34 +0530 To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: "cc:Mail Note Part" Subject: [IPTEL] unsubscribe Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit -----Original Message----- From: Ron Traficante [mailto:ront@bzln.com] Sent: 20 June 2000 21:34 To: 'Suntichai Chusywong'; iptel@lists.research.bell-labs.com Subject: RE: [IPTEL] Master - Slave Determination Since the portion of your question regarding message order has already been answered - I will take a crack at the second part regarding what the result is used for. There are cases where two or more endpoints/terminals may initiate events simultaneously where there is a resource conflict - in this case it is necessary for the master endpoint to in order to resolve the conflict. A very good example is the logical channel determination, where each endpoint needs to establish a unique channel for the data streams, and since they are half-duplex, each two way "conversation" requires two channels. Thus - if both endpoints choose the same logical channel for it's part of the conversation, this results in a conflict. How this is "resolved" is an issue of another message on this board as well. Additionally - in H.235, the master is also responsible for the distribution of the encryption keys for media channels to other terminals. -----Original Message----- From: Suntichai Chusywong [mailto:s4110400@maliwan.psu.ac.th] Sent: Tuesday, June 20, 2000 9:18 AM To: iptel@lists.research.bell-labs.com Subject: [IPTEL] Master - Slave Determination I wonder when Master - Slave Determinaiton message wil be sent, before or after sending Terminal Capability Set message? After Determining which Endpoint is master, what do we use this result for? Thank you very much Suntichai Chuaywong _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 22 14:40:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12688 for ; Thu, 22 Jun 2000 14:40:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 157D6443AD; Thu, 22 Jun 2000 14:24:07 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by lists.bell-labs.com (Postfix) with ESMTP id 104F5443AB for ; Thu, 22 Jun 2000 14:24:03 -0400 (EDT) Received: from ss8networks.com (gw-ss8networks.storm.ca [209.87.234.122]) by tonnant.cnchost.com id OAA24763; Thu, 22 Jun 2000 14:36:14 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <39525C1E.B37EB226@ss8networks.com> Date: Thu, 22 Jun 2000 14:34:06 -0400 From: Dave Walker Organization: SS8 Networks Inc X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: iptel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] TRIP tie-breakers Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit In section 10.2.2.1 of draft-ietf-iptel-trip-02.txt, there are three means of breaking ties among equally preferred routes to the same destination. One is using MED. The other two use the TRIP ID of some LS: a) If the local LS is configured to use the MultiExitDisc attribute to break ties, and the candidate routes differ in the value of the MultiExitDisc attribute, then select the route that has the larger value of MultiExitDisc. b) If at least one of the routes was advertised by an LS in a neighboring ITAD, then select the route that was advertised by the LS that has the smallest TRIP ID. c) Otherwise, select the route that was advertised by the internal LS that has the lowest TRIP ID. I have a simple question on (a). Since this algorithm is pretty much lifted from BGP, why does it give preference to the largest value of MED, when BGP uses the smallest? In other respects, the usage of MED in TRIP is the same as in BGP (i.e. routes with lower MED value are preferred). I don't understand the difference between (b) and (c). It seems to me that they're the same. In both cases, the lowest TRIP ID is selected. It's possible that (b) intends that the lowest TRIP ID be selected from among the external routes, but that's not what it says (according to my interpretation). BGP's algorithm for breaking phase 2 ties explicitly says that the selection is only from among the external routes. Because of the change in the use of MED for tie-breaking (see above), I'm uneasy about using BGP for what I think is undefined functionality in TRIP. Now if the intention for (b) is that the preferred route is the one that was advertised by an external LS (as per BGP), my next question is why? It seems to me that if I were a service provider, I'd prefer to use my own gateways (internal routes) over someone else's. Regards, Dave Walker SS8 Networks Ottawa, Canada _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 22 15:18:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13437 for ; Thu, 22 Jun 2000 15:18:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D63344384; Thu, 22 Jun 2000 15:05:54 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by lists.bell-labs.com (Postfix) with ESMTP id CF27244339 for ; Thu, 22 Jun 2000 15:05:50 -0400 (EDT) Received: (from dhaval@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA00826; Thu, 22 Jun 2000 12:18:01 -0700 (PDT) From: Dhaval Shah Message-Id: <200006221918.MAA00826@sigma.cisco.com> Subject: Re: [IPTEL] Length in OPEN To: hsalama@cisco.com Date: Thu, 22 Jun 2000 12:18:01 -0700 (PDT) Cc: Gonzalo.Camarillo@lmf.ericsson.se (Gonzalo Camarillo), iptel@lists.bell-labs.com (iptel) In-Reply-To: <39467363.22030676@cisco.com> from "Hussein F. Salama" at Jun 13, 2000 10:46:11 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Gonzalo Camarillo wrote: > > > > Hi, > > > > Why is it needed the "optional parameter length" in the OPEN message if > > the length of the whole message is already present in the fixed-sized > > header? > > TRIP inherited this format from BGP. I don't know why the "optional > parameters length" was included in BGP's OPEN message header. However, > unless I am missing something, removing this two-byte field will not > save us much, because the OPEN message only occurs once a session > anyways. Is there any reason to keep it if TRIP doesn't need it? Also, the optional parameter length in BGP is 1 byte. Any reason why TRIP has 2 bytes? Thanx, Dhaval > > Hussein > > > > > Thanks, > > > > Gonzalo > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland > > > > _______________________________________________ > > IPTEL mailing list > > IPTEL@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/iptel > > -- > 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 > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 23 20:06:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23184 for ; Fri, 23 Jun 2000 20:06:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 19D94443A7; Fri, 23 Jun 2000 19:53:18 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id C0C1044336 for ; Fri, 23 Jun 2000 19:53:14 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA23041; Fri, 23 Jun 2000 17:05:49 -0700 (PDT) Received: from cisco.com (dhcp-171-71-147-141.cisco.com [171.71.147.141]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABM00383 (AUTH hsalama); Fri, 23 Jun 2000 17:05:37 -0700 (PDT) Message-ID: <3953FACD.4F534C7E@cisco.com> Date: Fri, 23 Jun 2000 17:03:25 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: Dave Walker Cc: iptel Subject: Re: [IPTEL] TRIP tie-breakers References: <39525C1E.B37EB226@ss8networks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dave Walker wrote: > > In section 10.2.2.1 of draft-ietf-iptel-trip-02.txt, there are > three means of breaking ties among equally preferred routes to > the same destination. One is using MED. The other two use the > TRIP ID of some LS: > > a) If the local LS is configured to use the MultiExitDisc > attribute to break ties, and the candidate routes differ > in the value of the MultiExitDisc attribute, then select the > route that has the larger value of MultiExitDisc. This statement needs to be tightened up, such that only routes from the same neighboring ITAD are compared with each other in step a). > b) If at least one of the routes was advertised by an LS in a > neighboring ITAD, then select the route that was advertised > by the LS that has the smallest TRIP ID. > c) Otherwise, select the route that was advertised by the internal > LS that has the lowest TRIP ID. > > I have a simple question on (a). Since this algorithm is pretty > much lifted from BGP, why does it give preference to the largest > value of MED, when BGP uses the smallest? In other respects, the > usage of MED in TRIP is the same as in BGP (i.e. routes with lower > MED value are preferred). Thanks for pointing this out. The purpose of this divergence from BGP was to make the LocalPreference attribute and the MED attribute consistent: higher value means higher preference. It seems that the change was made in this paragraph only. This will be fixed in the next revision. > > I don't understand the difference between (b) and (c). It seems > to me that they're the same. They're different. Step b) eliminates all internal routes and breaks the tie between the external routes. TRIP gets to Step c) only if the tie is among internal routes only. Step c) breaks the tie between these internal routes. > In both cases, the lowest TRIP ID > is selected. It's possible that (b) intends that the lowest > TRIP ID be selected from among the external routes, Correct. > but that's > not what it says (according to my interpretation). BGP's algorithm > for breaking phase 2 ties explicitly says that the selection is > only from among the external routes. Because of the change in > the use of MED for tie-breaking (see above), I'm uneasy about > using BGP for what I think is undefined functionality in TRIP. We had a discussion about the use of MED in TRIP before (check iptel archives), but we decided at the end to use it exactly the same way it is defined in BGP, with the exception mentioned above on how to interpret the MED value. > > Now if the intention for (b) is that the preferred route is > the one that was advertised by an external LS (as per BGP), my > next question is why? It seems to me that if I were a service > provider, I'd prefer to use my own gateways (internal routes) > over someone else's. In BGP, when a BGP speaker receives a route from an external peer and another route from an internal peer, both to the same destination, this means that the destination must be located outside the local AS. The route from an external peer is preferred, because it is the shortest path out of the local AS. The wording may not be clear in TRIP. However, TRIP's approach is different from BGP's. A "route advertised by an internal LS" is a route to a local GW in the same ITAD. A "route advertised by an LS in a neighboring ITAD" is a route to a GW outside the local ITAD. It doesn't matter whether the route was received from an internal peer or from an external peer, what matters is the location of the terminating GW. What you're proposing makes sense. I think, there will be more ITADs which encourage calls to terminate on their local than ITADs which prefer to terminate calls on external GWs and keep their local GWs as a last resort only. So it should be preferable to route calls to local GWs and not to external GWs. Hussein > > Regards, > > Dave Walker > SS8 Networks > Ottawa, Canada > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- 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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 28 08:37:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20970 for ; Wed, 28 Jun 2000 08:37:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DD75F4433B; Wed, 28 Jun 2000 08:37:00 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id AD91544336 for ; Tue, 27 Jun 2000 18:20:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jun 27 18:18:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1C46F44348; Tue, 27 Jun 2000 18:05:09 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id EDF1744347 for ; Tue, 27 Jun 2000 18:05:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9E72152C4; Tue, 27 Jun 2000 18:05:11 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id C540252AB for ; Tue, 27 Jun 2000 18:05:08 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Jun 27 18:04:00 EDT 2000 Received: from diablo.cisco.com ([171.68.224.210]) by dusty; Tue Jun 27 18:03:59 EDT 2000 Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA22164; Tue, 27 Jun 2000 15:02:49 -0700 (PDT) Message-Id: <4.1.20000627150221.009f5100@diablo.cisco.com> Message-Id: <4.1.20000627150221.009f5100@diablo.cisco.com> X-Sender: jmpolk@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 27 Jun 2000 15:03:23 -0500 To: "Fox, Mike" , Jonathan Rosenberg , IMPP WG From: "James M. Polk" Cc: sip , rem-conf@es.net, "iptel, list" In-Reply-To: <613A6A6A3F09D3118F5C00508B2C24FE7F35E6@sd_exchange.nuera.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1302240==_.ALT" Subject: [IPTEL] RE: proposal for IMPP Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com --=====================_1302240==_.ALT Content-Type: text/plain; charset="us-ascii" Mike How long did it take you to think of this acronym? If less than an hour -- you need a life, man! ;-) cheers At 03:18 PM 6/15/2000 -0700, Fox, Mike wrote: >Why stop at XML for IMPP? Why not XML for SIP? Simple Object Access Protocol >may be the right way. Call it SIP Control by Unified Methods. > >SOAP SCUM > > >Best regards, >Mike Fox > > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1302240==_.ALT Content-Type: text/html; charset="us-ascii"
Mike

How long did it take you to think of this acronym? If less than an hour -- you need a life, man!

;-)

cheers

At 03:18 PM 6/15/2000 -0700, Fox, Mike wrote:
>Why stop at XML for IMPP? Why not XML for SIP? Simple Object Access Protocol
>may be the right way. Call it SIP Control by Unified Methods.
>
>SOAP SCUM
>
>
>Best regards,
>Mike Fox
>
>
*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1302240==_.ALT-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel