From owner-iptel-outgoing@lists.research.bell-labs.com Fri Oct 1 20:50:39 1999 Received: from lists.research.bell-labs.com ([135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25354 for ; Fri, 1 Oct 1999 20:50:38 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5661552E6; Fri, 1 Oct 1999 20:45:31 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A388B52E9; Fri, 1 Oct 1999 20:45:30 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Fri, 1 Oct 1999 17:44:17 -0700 (MST) From: Barbara M DeSutter Message-Id: <199910020044.RAA16823@slope.cig.mot.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: iptel@lists.research.bell-labs.com Subject: SIP equiv of H.323/225 messages Cc: desutter@cig.mot.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, Does anyone know the SIP equivalent to the H.323/H.225 Address Confirmation (ACF) and Admission Request (ARQ) messages? Thanks, Barb -- Technical information contained here is exportable under ECCN5E992 NLR. Barbara DeSutter Email: P16684@email.mot.com or desutter@cig.mot.com Motorola - CIG Phone: 480-441-1200 AZ25 - H707 Pager: 1-800-759-8888 (PIN 1372422) 8201 E. McDowell Rd. Fax: 480-675-2434 Scottsdale, AZ 85252 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat Oct 2 13:54:37 1999 Received: from lists.research.bell-labs.com ([135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13963 for ; Sat, 2 Oct 1999 13:54:36 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 98F7852DD; Sat, 2 Oct 1999 13:49:31 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1054D52DF; Sat, 2 Oct 1999 13:49:30 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <024b01bf0cfe$3026d120$0201a8c0@mds.local> From: "Paul E. Jones" To: "Barbara M DeSutter" , Cc: References: <199910020044.RAA16823@slope.cig.mot.com> Subject: Re: SIP equiv of H.323/225 messages Date: Sat, 2 Oct 1999 13:47:00 -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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Barbara, SIP does not have the concept of a network-centric "gatekeeper" like H.323, and thus has no need for such messages. SIP starts a call with INVITE, which equates to an H.323 SETUP. However, some groups are insisting on killing the "simple" SIP protocol by adding complexity necessary to support PSTN networks and bill for calls. H.323 has been flamed for this complexity... so why these independent SIP groups are doing this just isn't rational. It is important to be aware that there are at least two groups who are mutilating SIP, in my opinion. One is pushing SIP BCP ("Best Common Practices", formerly SIP+) and the other is pushing SIP DCS ("Distributed Call State"). Neither are completely interoperable and DCS just completely breaks away from the SIP ideology. Best Regards, Paul ----- Original Message ----- From: Barbara M DeSutter To: Cc: Sent: Friday, October 01, 1999 8:44 PM Subject: SIP equiv of H.323/225 messages > Hi, > > Does anyone know the SIP equivalent to the H.323/H.225 Address Confirmation > (ACF) and Admission Request (ARQ) messages? > > Thanks, > Barb > > -- > Technical information contained here is exportable under ECCN5E992 NLR. > > Barbara DeSutter Email: P16684@email.mot.com or desutter@cig.mot.com > Motorola - CIG Phone: 480-441-1200 > AZ25 - H707 Pager: 1-800-759-8888 (PIN 1372422) > 8201 E. McDowell Rd. Fax: 480-675-2434 > Scottsdale, AZ 85252 > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat Oct 2 14:48:21 1999 Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14202 for ; Sat, 2 Oct 1999 14:48:20 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C3EFA52E2; Sat, 2 Oct 1999 14:42:28 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6A1E652DE; Sat, 2 Oct 1999 14:42:23 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37F65246.9EB9EBC9@dnrc.bell-labs.com> Date: Sat, 02 Oct 1999 14:43:18 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Barbara M DeSutter Cc: iptel@lists.research.bell-labs.com, sip@lists.research.bell-labs.com Subject: Re: SIP equiv of H.323/225 messages References: <199910020044.RAA16823@slope.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit ACF is Admission Confirm, not Address Confirm. In any case, the BRQ/ARQ message sets are not present in SIP, as has been pointed out. As the media paths and signaling can be completely separate (imagine yahoo providing SIP services, but media transport is provided by the users internet service provider), in many (actually, most) cases, the SIP server will not have sufficient information to usefully perform admission control for calls based on network capacity. I have argued that the same is true for a gateekeper. This function is best delegated to COPS servers, bandwidth brokers, and other devices which provide cross-application QoS services. However, a SIP server can perform "admission control" based on policy. Its quite simple. When the INVITE arrives at a proxy, it can simply reject the request if the server policy determines that the call is not allowed to be initiated. Since the SDP in the SIP INVITE conveys codec information, one might even reject calls based on the total amount of bandwidth used by all calls initiated through the proxy. This isn't going to be all that useful for controlling network resource usage, but it is allowable from a pure policy perspective. -Jonathan R. Barbara M DeSutter wrote: > > Hi, > > Does anyone know the SIP equivalent to the H.323/H.225 Address Confirmation > (ACF) and Admission Request (ARQ) messages? > > Thanks, > Barb > > -- > Technical information contained here is exportable under ECCN5E992 NLR. > > Barbara DeSutter Email: P16684@email.mot.com or desutter@cig.mot.com > Motorola - CIG Phone: 480-441-1200 > AZ25 - H707 Pager: 1-800-759-8888 (PIN 1372422) > 8201 E. McDowell Rd. Fax: 480-675-2434 > Scottsdale, AZ 85252 > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sun Oct 3 10:36:40 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08140 for ; Sun, 3 Oct 1999 10:36:39 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2689A52DF; Sun, 3 Oct 1999 10:31:33 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 68D2752E3; Sun, 3 Oct 1999 10:31:32 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Sun, 03 Oct 1999 09:30:25 -0500 From: Henry Sinnreich Subject: RE: SIP equiv of H.323/225 messages In-reply-to: <024b01bf0cfe$3026d120$0201a8c0@mds.local> To: "Paul E. Jones" , Barbara M DeSutter , iptel@lists.research.bell-labs.com Cc: desutter@cig.mot.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > breaks away from the SIP ideology. Let's see the bottle as half full. The internal implementations exemplified by Paul validate SIP in the sense that if anyone wants to build a service delivery architecture, would chose SIP. I also agree with Paul in the sense, that all ships will rise with the tide if we develop complete specifications for global interoperability. The newly formed SIP working group has its work cut out for this purpose. Please see the attached. Henry From: Media Gateway Control (megaco) [MEGACO@STANDARDS.NORTELNETWORKS.COM] on behalf of Jonathan Rosenberg [jdrosen@DNRC.BELL-LABS.COM] Sent: Tuesday, September 28, 1999 11:27 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: [Fwd: WG ACTION: Session Initiation Protocol (sip)] Folks, My apologies for the broad cross-posting, but I wanted to make sure folks see this. As those who attended mmusic in Oslo may recall, there was agreement that the work of mmusic was becoming too much. In particular, the SIP related activities were enough to warrant its own group. The mmusic session devoted some time to deciding on what a new group would look like. It was agreed that such a group SHOULD NOT focus on pure IP telephony aspects of SIP, but rather its broadest application. As such, a new sip working group has been formed. its charter is to fully own SIP, including its movement to draft, and any extensions which may arise. It is within the charter that maintaining the generality and broad application of SIP, and keeping it simple, are primary goals of the groups activity. Note that the email below is incorrect regarding the area; the sip working group is within the transport area. From here on, we would like to use the sip mailing list (sip@lists.research.bell-labs.com) for SIP related discussion. mmusic is still active, and is going to continue work on sap, sdp, rtsp, and those non-SIP things. As such, please use the mmusic list (confctrl@isi.edu) for discussion of those issues. ************************************* NOTE: YOU WILL NOT BE AUTOMATICALLY SUBSCRIBED TO THE SIP MAILING LIST. YOU MUST SUBSCRIBE YOURSELF USING THE PROCEDURES ON THE SIP WEB PAGE http://www.bell-labs.com/mailing-lists/sip/ WHICH SAYS TO SEND MAIL TO sip-request@lists.research.bell-labs.com WITH THE SINGLE WORD subscribe IN THE BODY DO NOT SEND SUBSCRIPTION REQUESTS TO confctrl@isi.edu OR sip@lists.research.bell-labs.com ************************************* Thanks, Jonathan Rosenberg Joerg Ott Dean Willis sip co-chairs -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen > -----Original Message----- > From: owner-iptel@lists.research.bell-labs.com > [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of Paul E. > Jones > Sent: Saturday, October 02, 1999 12:47 PM > To: Barbara M DeSutter; iptel@lists.research.bell-labs.com > Cc: desutter@cig.mot.com > Subject: Re: SIP equiv of H.323/225 messages > > > Barbara, > > SIP does not have the concept of a network-centric "gatekeeper" > like H.323, > and thus has no need for such messages. SIP starts a call with INVITE, > which equates to an H.323 SETUP. > > However, some groups are insisting on killing the "simple" SIP protocol by > adding complexity necessary to support PSTN networks and bill for calls. > H.323 has been flamed for this complexity... so why these independent SIP > groups are doing this just isn't rational. > > It is important to be aware that there are at least two groups who are > mutilating SIP, in my opinion. One is pushing SIP BCP ("Best Common > Practices", formerly SIP+) and the other is pushing SIP DCS ("Distributed > Call State"). Neither are completely interoperable and DCS just > completely > breaks away from the SIP ideology. > > Best Regards, > Paul > > ----- Original Message ----- > From: Barbara M DeSutter > To: > Cc: > Sent: Friday, October 01, 1999 8:44 PM > Subject: SIP equiv of H.323/225 messages > > > > Hi, > > > > Does anyone know the SIP equivalent to the H.323/H.225 Address > Confirmation > > (ACF) and Admission Request (ARQ) messages? > > > > Thanks, > > Barb > > > > -- > > Technical information contained here is exportable under ECCN5E992 NLR. > > > > Barbara DeSutter Email: P16684@email.mot.com or > desutter@cig.mot.com > > Motorola - CIG Phone: 480-441-1200 > > AZ25 - H707 Pager: 1-800-759-8888 (PIN 1372422) > > 8201 E. McDowell Rd. Fax: 480-675-2434 > > Scottsdale, AZ 85252 > > > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Oct 12 10:37:21 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16970 for ; Tue, 12 Oct 1999 10:37:20 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4132252BB; Tue, 12 Oct 1999 10:31:27 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A830652DC; Tue, 12 Oct 1999 10:31:26 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <4B7BD6BF05FCD21188810004AC56729247B254@winnamur_srv1> From: KAMINSKI Alain To: iptel@lists.research.bell-labs.com Subject: Question on Internet Telephony Gateway Location Date: Tue, 12 Oct 1999 16:26:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hello, Leaning over the gateway location issue, I'd like to ask you about the different solutions being worked out. As far as I found papers on the topic, I'm aware of GLP and T-BGP. Are these two protocols the only actors for ITGL ? I also found little documentation about BMA. Is BMA still a likely solution ? Does ITGL still make any sense in a MeGaCo/SIP environment where SIP users/servers could take advantage of the call agent (or MGC) to find their way to the appropriate GSTN gateway ? Thank you for your feedback ! Have a nice day, Alain ______________________________________ Alain KAMINSKI Telecom Engineer - Backbone team WIN S.A.Rue Marie-Henriette, 60 B-5000 Namur Mobile phone : + 32 (0) 477 67 38 39 Work Phone : + 32 (0) 81 711 734 Fax : + 32 (0) 81 711 742 mailto:alain.kaminski@win.be Web: http://www.win.be/ --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Oct 13 00:08:35 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03407 for ; Wed, 13 Oct 1999 00:08:35 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5FC1952DC; Tue, 12 Oct 1999 23:00:27 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A6E3A52E0; Tue, 12 Oct 1999 23:00:26 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3803F623.4344CE74@dnrc.bell-labs.com> Date: Tue, 12 Oct 1999 23:01:55 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: KAMINSKI Alain Cc: iptel@lists.research.bell-labs.com Subject: Re: Question on Internet Telephony Gateway Location References: <4B7BD6BF05FCD21188810004AC56729247B254@winnamur_srv1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit KAMINSKI Alain wrote: > > Hello, > > Leaning over the gateway location issue, I'd like to ask you about > the different solutions being worked out. As far as I found papers on the > topic, > I'm aware of GLP and T-BGP. > > Are these two protocols the only actors for ITGL ? We're finishing up merging these proposals into a single solution, called TRIP (telephony routing over ip). Draft should be out real soon now.. > > I also found little documentation about BMA. Is BMA still a likely solution > ? No. BMA (BMA = Brokered Multicast Advertisements) was solving a similar problem but with a much different set of assumptions. The idea there was an open market for gateways, without any notion of inter-provider relationships. It also relies on wide area multicast, which is non-existent now. > > Does ITGL still make any sense in a MeGaCo/SIP environment where > SIP users/servers could take advantage of the call agent (or MGC) to find > their > way to the appropriate GSTN gateway ? It certainly makes sense there. In the megaco/sip model, the originating MGC needs to figure out the address of a SIP server to forward the calls to, so they can eventually terminate on an MGC that controls a gateway which can terminate a call. As a result, TRIP (formerly known as GLP) is very appropriate to use between SIP servers and MGC's, which are referred to as "Location Servers" or LS's in the TRIP framework. Of course, this need only arises when you assume there is more than one MGC and/or more than one provider handling a call. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Oct 15 08:37:04 1999 Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07854 for ; Fri, 15 Oct 1999 08:37:04 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7268952B6; Fri, 15 Oct 1999 08:31:29 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C9D5452DD; Fri, 15 Oct 1999 08:31:28 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com To: iptel@lists.research.bell-labs.com Date: Fri, 15 Oct 1999 08:29:29 -0400 Message-ID: <007e01bf1708$a62234a0$0701a8c0@oleane.com> From: "Peter Lewis" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk To: Subject: Media Gateway Control Date: Fri, 15 Oct 1999 14:27:05 +0200 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01BF1719.5AF83360" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0077_01BF1719.5AF83360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MGCP, Megaco, H.248: performing seamless interoperation between IP and = PSTN networks. The international rendez-vous in Paris, 15-17 December 1999. More infos:=20 http://www.upperside.fr/bamgc.htm ------=_NextPart_000_0077_01BF1719.5AF83360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
MGCP, Megaco, H.248: performing seamless = interoperation=20 between IP and PSTN
networks. The international rendez-vous in Paris, = 15-17=20 December 1999.

More infos:
http://www.upperside.fr/bamgc.= htm
 
------=_NextPart_000_0077_01BF1719.5AF83360-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Oct 15 17:42:44 1999 Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22289 for ; Fri, 15 Oct 1999 17:42:43 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id AD0FC52DE; Fri, 15 Oct 1999 17:37:31 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1C4B952E2; Fri, 15 Oct 1999 17:37:31 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <38079E07.34FE303F@cisco.com> Date: Fri, 15 Oct 1999 17:35:03 -0400 From: Bryan Byerly Reply-To: byerly@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com, byerly@cisco.com Subject: Newbie questions on CPL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Let me preface by saying that I really like the idea of enabling users/sysadmins the ability to dynamically configure their calling options. CPL appears to be one way to empower those users/sysadmins. I have a few newbie questions on the draft of CPL: 1) In section 5.2 Redirect: "Redirect causes the server to direct the calling party to attempt to place its call to the currently specified set of locations. This immediately terminates execution of the CPL script, so this node has no outputs. This node also has no arguments other than the standard Link ID target (see Section 7)" a) Can/should these redirects be forked in parallel or sequentially? b) Does it matter? c) If so, how should the preference be specified in the CPL script? 2) In section 6.2 Log: Is the "name" field of the Log node referring to: i) the name of a log file on the local server. ii) a specific entry to log into a log file on the local server 3) Regarding section 6.2 Log: Assuming that the "name" field implies the name of the log file: a) What syntax should be used to indicate that the server should log to a remote (event logging) server? b) To address remote logging, should: i) a separate field be introduced to indicate the name of the remote logging server. (I assume the absence of this field would imply the local server be used as default) OR ii) should the name be used as a url to indicate the remote pathname of the event logging server? OR eg. my.remote.logging.server.com/log_directory/logFile.log iii) I shutup and go away because remote logging is not currently going to be addressed. :) OR iv) other ideas? 4) How do I indicate to turn off the logging? (This question applies whether logging occurs locally or remotely) i) Reload another script which does NOT including a Log node. ii) other ideas? 5) Is there a more recent version of the draft that is available? 6) Although not particularly useful, I like example 8.3 :) 7) Regarding section 9 Security Considerations: Although CPL is designed to prevent loops within a single node, there still appears to be a danger of loops if a user can install scripts on two or more nodes. I can imagine a mischevious user (Malory) installing two (or more) scripts that result in an email-bomb (or other annoyance) to a third party. It is my understanding that this should not be a problem when using SIP due to the VIA header checking (which prevents such looping). However, I don't believe H.323 does any such checking... Let me give the above example a try: Script installed on crl-enabled-serverA: ------------------------------ ? < call> < /location> Script installed on crl-enabled-serverB: ------------------------------ ? < /location> In the above code, I guess could also be replaced with . It's not apparent to me how to fix such a problem without making the CPL language useless. * Questions/comments/criticisms of coding errors? 8) Here's the list of things I've gleaned from the draft that the CPL script Verifier should check when a script is loaded on a server: 0) Verify XML syntax. 1) Verify support for all variables. [Section 3] 2) Verify support for all comparators. [Section 3.1] 3) Verify support for all basic locations. [Section 4.1] 4) Verify existance of all mandatory syntax requirements. (i.e. Verify presence of all mandatory fields.) 5) Verify all "links" are local [Section 7] (i.e. Verify all links are in the same script.) 6) Verify there are no (local) cycles created by links. (i.e. For all links, verify no links are to parents.) [Section 7] * What did I get wrong or am missing? 9) Is COPS the (perhaps unofficially) recommended means of transferring CPL scripts? What other mechanism would you suggest? Cheers! Bryan (Any/all opinions expressed are personal and should not be construed to be those of anyone else.) --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Oct 15 18:03:06 1999 Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22496 for ; Fri, 15 Oct 1999 18:03:06 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B00CB52E2; Fri, 15 Oct 1999 17:57:27 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 35C1A52E3; Fri, 15 Oct 1999 17:57:27 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Fri, 15 Oct 1999 16:56:21 -0500 (EST) From: Samanvitha Rao To: iptel@lists.research.bell-labs.com Subject: Default Next hop Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, I had a question about Location Servers (as specified in the GLP docs). When a LS is queried for a destination telephone number that it does not know of, should it return an error code, or can there be the notion of a default next hop signaling server? Is this completely left to the discretion of the domain admin? Thanks, Samanvitha --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat Oct 16 02:09:19 1999 Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07373 for ; Sat, 16 Oct 1999 02:09:19 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id CFCA952E3; Sat, 16 Oct 1999 02:04:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4065652E6; Sat, 16 Oct 1999 02:04:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <380815BB.22627900@dnrc.bell-labs.com> Date: Sat, 16 Oct 1999 02:05:47 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Samanvitha Rao Cc: iptel@lists.research.bell-labs.com Subject: Re: Default Next hop References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Samanvitha Rao wrote: > > Hi, > > I had a question about Location Servers (as specified in the GLP docs). > When a LS is queried for a destination telephone number that it does not > know of, should it return an error code, or can there be the notion of a > default next hop signaling server? Is this completely left to the > discretion of the domain admin? This all has nothing to do with GLP (now TRIP). TRIP distributes the information that allows the LS to build a database of telephony routes. How it is queried for this information, and how it responds when it doesn't have proper information, is not part of TRIP. As the framework document describes, this is part of the "front end", for which there are many possibilities. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Oct 18 14:43:37 1999 Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16012 for ; Mon, 18 Oct 1999 14:43:37 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id CD9F552BB; Mon, 18 Oct 1999 14:37:28 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 46AEB52DC; Mon, 18 Oct 1999 14:37:28 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Mon, 18 Oct 1999 14:35:06 -0400 (EDT) Message-Id: <199910181835.OAA00299@conrail.cs.columbia.edu> From: Jonathan Lennox To: iptel@lists.research.bell-labs.com Subject: Re: Newbie questions on CPL In-Reply-To: <38079E07.34FE303F@cisco.com> References: <38079E07.34FE303F@cisco.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk On Fri, October 15 1999, "Bryan Byerly" wrote to "iptel@lists.research.bell-labs.com, byerly@cisco.com" saying: > Hello, > > Let me preface by saying that I really like the idea of enabling > users/sysadmins the ability to dynamically configure > their calling options. CPL appears to be one way to > empower those users/sysadmins. Thanks! I'm glad there's growing interest in the CPL. > I have a few newbie questions on the draft of CPL: > > 1) In section 5.2 Redirect: > "Redirect causes the server to direct the calling party to attempt > to place its call to the currently specified set of locations. > This immediately terminates execution of the CPL script, > so this node has no outputs. This node also has no arguments > other than the standard Link ID target (see Section 7)" > > a) Can/should these redirects be forked in parallel or > sequentially? > b) Does it matter? > c) If so, how should the preference be specified in the CPL script? My model was a SIP-style 3xx-class response (probably 302) with a list of Contact: addresses. What the caller (or upstream node) does with the 3xx is up to it -- parallel, sequential, overlapping, whatever. If you need firmer control of the behavior, you have to do it yourself, with nodes. Does H.323 have a similar concept? > 2) In section 6.2 Log: > Is the "name" field of the Log node referring to: > i) the name of a log file on the local server. > ii) a specific entry to log into a log file on the local server Well, I don't want to require any specific model of filesystems or whatever for the CPL server. As it's currently implemented, it certainly *could* be a filename; but it could just as easily be a syslog tag, or whatever. The name is just intended to be a way of discriminating various different logging streams, and what the CPL server does with the names is an implementation decision. Thus (regarding your point 3) I didn't want to get into the issue of remote vs. local logfiles, though I suppose a particular server could locally define some remote vs. local syntax. Do people think that the CPL should specify this stuff? > 4) How do I indicate to turn off the logging? > (This question applies whether logging occurs locally or remotely) > i) Reload another script which does NOT including a Log node. > ii) other ideas? Add a new script, yes -- they're intended to be quite dynamic. Or have some out-of-band means. > 5) Is there a more recent version of the draft that is available? Not yet. Soon, hopefully. > 7) Regarding section 9 Security Considerations: > Although CPL is designed to prevent loops within a single node, > there still appears to be a danger of loops if a user can install > scripts on two or more nodes. I can imagine a mischevious user > (Malory) installing two (or more) scripts that result in an > email-bomb (or other annoyance) to a third party. > > It is my understanding that this should not be a problem when > using SIP due to the VIA header checking > (which prevents such looping). > However, I don't believe H.323 does any such checking... This is true, but it's not specific to CPL -- it can occur with any service deployment mechanism unless the protocol has some way of checking it. Even if we were somehow to kludge some support into CPL to fix it (which I don't see how is possible), other service deployment mechanisms (including calling up your service provider and saying "Hi, can you forward all my calls to h323:Malory@serverB.telco.com?") is going to have the same problem. > 8) Here's the list of things I've gleaned from the draft > that the CPL script Verifier should check when a > script is loaded on a server: > 0) Verify XML syntax. > 1) Verify support for all variables. [Section 3] > 2) Verify support for all comparators. [Section 3.1] > 3) Verify support for all basic locations. [Section 4.1] > 4) Verify existance of all mandatory syntax requirements. > (i.e. Verify presence of all mandatory fields.) > 5) Verify all "links" are local [Section 7] > (i.e. Verify all links are in the same script.) > 6) Verify there are no (local) cycles created by links. > (i.e. For all links, verify no links are to parents.) > [Section 7] > > * What did I get wrong or am missing? This seems right; for the next draft I should add an appendix listing all these. The only constraint I would have is that the rules for validating acyclicity are a bit trickier than you've described -- basically "direct" arrows and "link" arrows need to be treated identically when walking the tree checking for cycles. > 9) Is COPS the (perhaps unofficially) recommended means of > transferring CPL scripts? It could certainly be one method. I'm not too familiar with COPS, but if you want to write something up I'd be glad to look over it. > What other mechanism would you suggest? I wrote draft-ietf-iptel-sip-reg-payload-00, which shouldn't have expired yet; if it has, it's available from my web page . -- Jonathan Lennox lennox@cs.columbia.edu --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Oct 19 02:06:04 1999 Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06657 for ; Tue, 19 Oct 1999 02:06:03 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4475852DF; Tue, 19 Oct 1999 02:00:49 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A123352E4; Tue, 19 Oct 1999 02:00:48 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <380C0968.B30605B4@dnrc.bell-labs.com> Date: Tue, 19 Oct 1999 02:02:16 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox Cc: iptel@lists.research.bell-labs.com Subject: Re: Newbie questions on CPL References: <38079E07.34FE303F@cisco.com> <199910181835.OAA00299@conrail.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > > > I have a few newbie questions on the draft of CPL: > > > > 1) In section 5.2 Redirect: > > "Redirect causes the server to direct the calling party to attempt > > to place its call to the currently specified set of locations. > > This immediately terminates execution of the CPL script, > > so this node has no outputs. This node also has no arguments > > other than the standard Link ID target (see Section 7)" > > > > a) Can/should these redirects be forked in parallel or > > sequentially? > > b) Does it matter? > > c) If so, how should the preference be specified in the CPL script? > > My model was a SIP-style 3xx-class response (probably 302) with a list of > Contact: addresses. What the caller (or upstream node) does with the 3xx is > up to it -- parallel, sequential, overlapping, whatever. If you need firmer > control of the behavior, you have to do it yourself, with nodes. > > Does H.323 have a similar concept? My interpretation of this question was different. I read it as follows: proxy A, executing a CPL, forwards a request to B, also running a CPL. B redirects to three addresses. These are received at A. Does A recurse on these? If so, is this done in parallel or sequentially? If this is indeed the question (and it is a good one), I don't believe the current CPL draft addresses this. I would argue that, at most, we might specify an attribute of the proxy tag, called recurse, so that: would cause recursion. Absence of this attribute, or the value "no", would disable recursion. We could also specify parallel or sequential, so that we have another attribute: I think both are reasonable, and fairly simple. > > > 2) In section 6.2 Log: > > Is the "name" field of the Log node referring to: > > i) the name of a log file on the local server. > > ii) a specific entry to log into a log file on the local server > > Well, I don't want to require any specific model of filesystems or whatever > for the CPL server. As it's currently implemented, it certainly *could* be > a filename; but it could just as easily be a syslog tag, or whatever. The > name is just intended to be a way of discriminating various different > logging streams, and what the CPL server does with the names is an > implementation decision. To support interoperability, though, we do need to say something about this. Otherwise, a user can put name="log3" in the CPL, but the server only allows name="syslog". I believe the spec should say that the name is nothing more than a unique identifier, and that servers should pretty much allow anything here, and not associate any semantic with it. It need not be the name of the file. The filename itself on the server might be composed of the user name and the log name, so that the log name need be unique only within the log names used by the user. > > 4) How do I indicate to turn off the logging? > > (This question applies whether logging occurs locally or remotely) > > i) Reload another script which does NOT including a Log node. > > ii) other ideas? > > Add a new script, yes -- they're intended to be quite dynamic. Or have some > out-of-band means. I also interpret this question differently. The question, to me, implies that Bryan viewed the logging as a continuous operation, not a discrete event. If it were a continuous operation, it would need to be turned on and off in some way. As a discrete event (which I believe it is), a single log entry is generated every time the log action is encountered in the CPL execution. This model for logging does raise some interesting questions: 1. lets say the log action is specified after a proxy action. In this case, is the response to the proxied request logged? In general, are the log contents dependent on where in the CPL the log action appears? 2. What happens if multiple log actions are taken within the execution of a script? > > 9) Is COPS the (perhaps unofficially) recommended means of > > transferring CPL scripts? > > It could certainly be one method. I'm not too familiar with COPS, but if > you want to write something up I'd be glad to look over it. I think COPS is targeted mainly at QoS related policy. I haven't heard anyone suggest its usage yet for CPL. The protocols that have been discussed are SIP REGISTERs (see Jonathan L's draft below), http, and ftp. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Oct 20 23:13:21 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29301 for ; Wed, 20 Oct 1999 23:13:21 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5D4E552D5; Wed, 20 Oct 1999 23:08:06 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BF74752DC; Wed, 20 Oct 1999 23:08:05 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <380D7CDF.E682A550@ericsson.com> Date: Wed, 20 Oct 1999 11:27:11 +0300 From: Ulf Andersson Organization: EUS/GT/A X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: sip@lists.research.bell-labs.com, ensc-tia@sfu.ca, sip-implementors@cs.columbia.edu, confctrl@isi.edu, iptel@lists.research.bell-labs.com, eriietf@kk.ericsson.se Subject: 3rd SIP Bake-Off Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello! The third SIP bake-off will be hosted by Ericsson in Dallas, Texas, December 6-8, 1999. For information and registration please visit http://www.sipbakeoff.org. The deadline for requesting special equipment and connections is October 30th. The deadline for general registration is November 15th. Please note that the bake-off is open only to implementors with working SIP implementations. It is not a trade show, public demonstration, conference or workshop, and individual results of all testing will remain confidential. A press release will be prepared at the end of the event to announce the results. Welcome! Ulf Andersson Ericsson Inc ulf.andersson@ericsson.com (972) 583-7537 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Oct 21 05:57:07 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13240 for ; Thu, 21 Oct 1999 05:57:07 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4D32152DB; Thu, 21 Oct 1999 05:51:54 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BA21E52DD; Thu, 21 Oct 1999 05:51:53 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <380EE290.833B5960@dnrc.bell-labs.com> Date: Thu, 21 Oct 1999 05:53:20 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "iptel, list" Subject: updated TRIP framework Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I've just submitted an updated TRIP (ex-GLP) framework document. There is no change except for replacing GLP with TRIP. As soon as this appears, it will go to IESG again as informational. If you are interested, you can take a look at the updated version at: http://www.bell-labs.com/mailing-lists/iptel/draft-ietf-iptel-gwloc-framework-05.txt We will hopefully have an actual GLP protocol document before the deadline as well. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Oct 22 22:53:41 1999 Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16219 for ; Fri, 22 Oct 1999 22:53:40 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1D94552E1; Fri, 22 Oct 1999 22:44:55 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7D80C52E2; Fri, 22 Oct 1999 22:44:54 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Delivered-To: tal@lists.research.bell-labs.com Date: Thu, 21 Oct 1999 17:37:37 -0500 From: Dean Willis Subject: SIP Working Group Interim Meeting November 7 at IETF Site To: IETF SIP Cc: IETF Pint , IETF Confctrl , IETF-Owner-Iptel Message-id: <000801bf1c14$e055b460$de9523a6@directlink.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit There will be an interim meeting of the SIP Working Group on Sunday, November 7 1999 from 10:00 AM to 7:00 PM. This is the day before the fall IETF meeting in DC. If we wrap early there may be some snacks left at the Sunday social. We currently plan to meet in the Olympia room of the Omni Shoreham Hotel. This is the hotel hosting the IETF meeting for the remainder of the week. The agenda people claim the room will support upwards of 100 attendees. The purpose of the interim meeting is to familiarize the SIP working group with the PacketCable DCS specification efforts, which also use SIP. The goal is to promote the completeness and interoperability of the SIP specification. The current agenda is: 10:00 to 11:15: DCS presentation 11:15 to 11:30: Break 11:30 to 12:45: DCS presentation 12:45 to 14:15: Lunch (not provide, brown bag or go out) 14:15 to 15:30: DCS presentation 15:30 to 15:45: Break 15:45 to 17:00; Discussion 17:00 to 17:15: Break 17:15 to 19:00: Discussion (refreshments smuggled from social room?) During the DCS presentations, we hope to focus on the design rationale of the PacketCable DCS aproach rather than on exploring alernatives. In other words, questions should be confined to "what" and "why" rather than "why not". The moderator will be ruthless -- there's a lot of material to cover. Please hold on discussion of alternatives until the "Discussion" periods. Thanks. I'm personally planning to arrive in DC on Saturday. Others may be able to travel early on Sunday. I think this meeting provides a tremendous opportunity to move the entire industy forward. I hope to see you all there! -- Dean Willis SIP WG co-chair --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Oct 22 23:03:13 1999 Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16310 for ; Fri, 22 Oct 1999 23:03:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B9EC252E4; Fri, 22 Oct 1999 22:45:59 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AA35752EA; Fri, 22 Oct 1999 22:45:58 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199910221055.GAA05711@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-iptel-gwloc-framework-05.txt Date: Fri, 22 Oct 1999 06:55:26 -0400 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --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 : A Framework for Telephony Routing over IP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-iptel-gwloc-framework-05.txt Pages : 24 Date : 21-Oct-99 This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-gwloc-framework-05.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-gwloc-framework-05.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-gwloc-framework-05.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: <19991021142258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-gwloc-framework-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-gwloc-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991021142258.I-D@ietf.org> --OtherAccess-- --NextPart-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Oct 25 11:01:17 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13483 for ; Mon, 25 Oct 1999 11:01:16 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E88CF52DF; Mon, 25 Oct 1999 10:32:45 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3293352E0; Mon, 25 Oct 1999 10:32:45 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <01BF1ECA.5F450890.rhondar@genesyslab.co.uk> From: Rhonda Ruhbach Reply-To: "rhondar@genesyslab.co.uk" To: "'byerly@cisco.com'" , "iptel@lists.research.bell-labs.com" Subject: RE: Newbie questions on CPL Date: Mon, 25 Oct 1999 09:21:51 +0200 Organization: Genesys Germany X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Please be aware that I am receiving emails that I do not think should come to me. It appears that I am on a 'Blind Copy' distribution. Regards, Rhonda Ruhbach Head of Professional Services, DACH Genesys Germany Mobile: +49 (0)172-897-1601 Email: rhondar@genesyslab.co.uk -----Original Message----- From: Bryan Byerly [SMTP:byerly@cisco.com] Sent: Friday, October 15, 1999 11:35 PM To: iptel@lists.research.bell-labs.com; byerly@cisco.com Subject: Newbie questions on CPL Hello, Let me preface by saying that I really like the idea of enabling users/sysadmins the ability to dynamically configure their calling options. CPL appears to be one way to empower those users/sysadmins. I have a few newbie questions on the draft of CPL: 1) In section 5.2 Redirect: "Redirect causes the server to direct the calling party to attempt to place its call to the currently specified set of locations. This immediately terminates execution of the CPL script, so this node has no outputs. This node also has no arguments other than the standard Link ID target (see Section 7)" a) Can/should these redirects be forked in parallel or sequentially? b) Does it matter? c) If so, how should the preference be specified in the CPL script? 2) In section 6.2 Log: Is the "name" field of the Log node referring to: i) the name of a log file on the local server. ii) a specific entry to log into a log file on the local server 3) Regarding section 6.2 Log: Assuming that the "name" field implies the name of the log file: a) What syntax should be used to indicate that the server should log to a remote (event logging) server? b) To address remote logging, should: i) a separate field be introduced to indicate the name of the remote logging server. (I assume the absence of this field would imply the local server be used as default) OR ii) should the name be used as a url to indicate the remote pathname of the event logging server? OR eg. my.remote.logging.server.com/log_directory/logFile.log iii) I shutup and go away because remote logging is not currently going to be addressed. :) OR iv) other ideas? 4) How do I indicate to turn off the logging? (This question applies whether logging occurs locally or remotely) i) Reload another script which does NOT including a Log node. ii) other ideas? 5) Is there a more recent version of the draft that is available? 6) Although not particularly useful, I like example 8.3 :) 7) Regarding section 9 Security Considerations: Although CPL is designed to prevent loops within a single node, there still appears to be a danger of loops if a user can install scripts on two or more nodes. I can imagine a mischevious user (Malory) installing two (or more) scripts that result in an email-bomb (or other annoyance) to a third party. It is my understanding that this should not be a problem when using SIP due to the VIA header checking (which prevents such looping). However, I don't believe H.323 does any such checking... Let me give the above example a try: Script installed on crl-enabled-serverA: ------------------------------ ? < call> < /location> Script installed on crl-enabled-serverB: ------------------------------ ? < /location> In the above code, I guess could also be replaced with . It's not apparent to me how to fix such a problem without making the CPL language useless. * Questions/comments/criticisms of coding errors? 8) Here's the list of things I've gleaned from the draft that the CPL script Verifier should check when a script is loaded on a server: 0) Verify XML syntax. 1) Verify support for all variables. [Section 3] 2) Verify support for all comparators. [Section 3.1] 3) Verify support for all basic locations. [Section 4.1] 4) Verify existance of all mandatory syntax requirements. (i.e. Verify presence of all mandatory fields.) 5) Verify all "links" are local [Section 7] (i.e. Verify all links are in the same script.) 6) Verify there are no (local) cycles created by links. (i.e. For all links, verify no links are to parents.) [Section 7] * What did I get wrong or am missing? 9) Is COPS the (perhaps unofficially) recommended means of transferring CPL scripts? What other mechanism would you suggest? Cheers! Bryan (Any/all opinions expressed are personal and should not be construed to be those of anyone else.) --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Oct 25 11:18:05 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14620 for ; Mon, 25 Oct 1999 11:18:04 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6808452E0; Mon, 25 Oct 1999 10:55:09 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8BB6752F3; Mon, 25 Oct 1999 10:34:03 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199910251057.GAA02998@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-iptel-trip-00.txt Date: Mon, 25 Oct 1999 06:57:44 -0400 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --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 Information Protocol (TRIP) Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-trip-00.txt Pages : 63 Date : 22-Oct-99 This document presents the Telephony Routing Information Protocol (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-00.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-00.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-00.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: <19991022135609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-trip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-trip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022135609.I-D@ietf.org> --OtherAccess-- --NextPart-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Oct 25 20:01:55 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08546 for ; Mon, 25 Oct 1999 20:01:54 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3C89652ED; Mon, 25 Oct 1999 19:56:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9B9AC52F5; Mon, 25 Oct 1999 19:56:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <6106E99A99E6D21190FA0008C71BD6AD016D32@genesyslab.de> From: Rhonda Ruhbach To: Internet-Drafts@ietf.org, IETF-Announce: ; Cc: iptel@lists.research.bell-labs.com Subject: RE: I-D ACTION:draft-ietf-iptel-trip-00.txt Date: Mon, 25 Oct 1999 18:32:46 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hello, Please be aware that I am receiving emails that I do not think should come to me. It appears that I am on a 'Blind Copy' distribution. Regards, Rhonda Ruhbach Head of Professional Services, DACH Genesys Germany Mobile: +49 (0)172-897-1601 Email: rhondar@genesyslab.co.uk -----Original Message----- From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] Sent: Monday, October 25, 1999 12:58 PM To: IETF-Announce: ; Cc: iptel@lists.research.bell-labs.com Subject: I-D ACTION:draft-ietf-iptel-trip-00.txt << File: access-type = mail-server >> << File: draft-ietf-iptel-trip-00.txt >> 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 Information Protocol (TRIP) Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-trip-00.txt Pages : 63 Date : 22-Oct-99 This document presents the Telephony Routing Information Protocol (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-00.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-00.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-00.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. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Oct 26 06:42:06 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00810 for ; Tue, 26 Oct 1999 06:42:05 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9BF7652D5; Tue, 26 Oct 1999 06:35:47 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 21E7452E7; Tue, 26 Oct 1999 06:35:46 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <4B7BD6BF05FCD21188810004AC56729247B2BC@winnamur_srv1> From: KAMINSKI Alain To: iptel@lists.research.bell-labs.com Subject: Comments on draft-ietf-iptel-trip-00.txt Date: Tue, 26 Oct 1999 12:33:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Some comments 1. I fear people (like me :) ) might get confused with TRIP and GLP relationship. draft-ietf-iptel-gwloc-framework-05.txt has replaced in its text all "GLP" by "TRIP". But in this draft, TRIP is defined as an instance of GLP (as defined in draft-ietf-iptel-gwloc-framework-03). I think it will be useful to harmonise inter-draft terms asap. 2. To my understanding, TRIP was meant to merge GLP and TBGP approaches in a single protocol. However, according to draft-ietf-iptel-glp-tbgp-01.txt : "The primary function of a TBGP speaker in administrative domain A is to advertise to TBGP speakers in other administrative domains reachability information of: - PSTN destinations (black phones) via gateways in domain A, - IP destinations (e.g., H.323 terminals or SIP terminals) in domain A." So it seems to me that TBGP is also covering location of IP destinations as opposed to TRIP. Is this difference still making TRIP and TBGP separate protocols ? 3. A insignificant correction... "3. Introduction The gateway location and call routing problem has been introduced in [1]. It is considered one of the most difficult problems in IP telephony. " ^^^^ Have a nice day, Alain ______________________________________ Alain KAMINSKI Network Technology Engineer WIN S.A.Rue Marie-Henriette, 60 B-5000 Namur BELGIUM Mobile phone : + 32 (0) 477 67 38 39 Work Phone : + 32 (0) 81 711 734 Fax : + 32 (0) 81 711 742 mailto:alain.kaminski@win.be Web: http://www.win.be/ --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Oct 26 06:50:38 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00851 for ; Tue, 26 Oct 1999 06:50:38 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7694A52EA; Tue, 26 Oct 1999 06:35:52 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E8E4752DB; Tue, 26 Oct 1999 06:35:48 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <4B7BD6BF05FCD21188810004AC56729247B2BB@winnamur_srv1> From: KAMINSKI Alain To: iptel@lists.research.bell-labs.com Subject: Comment on draft-ietf-iptel-gwloc-framework-05.txt Date: Tue, 26 Oct 1999 12:33:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk A minor remark... GLP is appearing in all figures instead of TRIP. Have a nice day, Alain ______________________________________ Alain KAMINSKI Network Technology Engineer WIN S.A.Rue Marie-Henriette, 60 B-5000 Namur BELGIUM Mobile phone : + 32 (0) 477 67 38 39 Work Phone : + 32 (0) 81 711 734 Fax : + 32 (0) 81 711 742 mailto:alain.kaminski@win.be Web: http://www.win.be/ --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Oct 26 09:20:36 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03938 for ; Tue, 26 Oct 1999 09:20:35 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3036D52F0; Tue, 26 Oct 1999 09:15:32 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7F69E52F1; Tue, 26 Oct 1999 09:15:31 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3815A977.9C64111@dynamicsoft.com> Date: Tue, 26 Oct 1999 09:15:35 -0400 From: Jonathan Rosenberg Organization: Dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: KAMINSKI Alain Cc: iptel@lists.research.bell-labs.com Subject: Re: Comments on draft-ietf-iptel-trip-00.txt References: <4B7BD6BF05FCD21188810004AC56729247B2BC@winnamur_srv1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit KAMINSKI Alain wrote: > > Some comments > > 1. > I fear people (like me :) ) might get confused with TRIP and GLP > relationship. > > draft-ietf-iptel-gwloc-framework-05.txt has replaced in its text all "GLP" > by "TRIP". > > But in this draft, TRIP is defined as an instance of GLP (as defined in > draft-ietf-iptel-gwloc-framework-03). -03 is an old draft. The relationship is simple. GLP was the name of the protocol we were chartered to define. Its now called TRIP. TBGP was a proposal for GLP/TRIP. TBGP, and the other proposal, based on SCSP, have been merged, and submitted as a draft. This protocol will be called TRIP. > > I think it will be useful to harmonise inter-draft terms asap. There is no need to harmonize terms across drafts. Drafts evolve and change all the time. Here, we changed the name of the protocol. > > 2. To my understanding, TRIP was meant to merge GLP and TBGP approaches in a > single protocol. TRIP combines aspects of the TBGP proposal and the SCSP-based proposal (which was also called GLP). > > However, according to draft-ietf-iptel-glp-tbgp-01.txt : > "The primary function of a TBGP speaker in administrative domain A is > to advertise to TBGP speakers in other administrative domains reachability > information of: > - PSTN destinations (black phones) via gateways in domain A, > - IP destinations (e.g., H.323 terminals or SIP terminals) in > domain A." > > So it seems to me that TBGP is also covering location of IP destinations as > opposed to TRIP. Matt, Hussein, and I came to consensus that in the merged protocol, TRIP, we would not support IP address propagation to reach H.323 terminals or SIP UAs. This is because these devices are end systems; determining an IP address for them is a name to address translation problem, and is best handled by directories like DNS (see the recently resurrected enum group). However, a gateway is an intermediary point, and its IP address is actually one hop of a route towards the end system (here, a phone). In this case, what we are after is a name to route translation, and that is much different. We have had numerous discussions on this subject on the list. I should note, however, that we have made TRIP fairly flexible in address formats. All routes are represented as a tuple of {address family, address length, address} , although we only define E.164 as an address family. > > Is this difference still making TRIP and TBGP separate protocols ? This group will produce one, and only one protocol, called TRIP. > > 3. > > A insignificant correction... > > "3. Introduction > The gateway location and call routing problem has been introduced in > [1]. It is considered one of the most difficult problems in IP > telephony. " > ^^^^ Thanks. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 210 Dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Oct 26 10:02:39 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04964 for ; Tue, 26 Oct 1999 10:02:38 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D1DE352E5; Tue, 26 Oct 1999 09:57:32 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 52A6B52F2; Tue, 26 Oct 1999 09:57:32 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.32.19991026091945.00ab7e10@zbl6c008.corpeast.baynetworks.com> X-Sender: msquire@zbl6c008.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 26 Oct 1999 09:19:47 -0400 To: KAMINSKI Alain , iptel@lists.research.bell-labs.com From: "Matt Squire" Subject: Re: Comments on draft-ietf-iptel-trip-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk At 12:33 PM 10/26/99 +0200, KAMINSKI Alain wrote: >Some comments > >1. >I fear people (like me :) ) might get confused with TRIP and GLP >relationship. > >draft-ietf-iptel-gwloc-framework-05.txt has replaced in its text all "GLP" >by "TRIP". > >But in this draft, TRIP is defined as an instance of GLP (as defined in >draft-ietf-iptel-gwloc-framework-03). > >I think it will be useful to harmonise inter-draft terms asap. > Miscommunication between the authors. Will be addressed. > >2. To my understanding, TRIP was meant to merge GLP and TBGP approaches in a >single protocol. > >However, according to draft-ietf-iptel-glp-tbgp-01.txt : >"The primary function of a TBGP speaker in administrative domain A is >to advertise to TBGP speakers in other administrative domains reachability >information of: > - PSTN destinations (black phones) via gateways in domain A, > - IP destinations (e.g., H.323 terminals or SIP terminals) in > domain A." > >So it seems to me that TBGP is also covering location of IP destinations as >opposed to TRIP. > >Is this difference still making TRIP and TBGP separate protocols ? > Any of the protocols discussed in this group have mapped E164 prefixes to IP addresses via next-hop semantics. Any of them can be used for 'host' routes, which in this case, may be likely H323 or SIP terminals. Including a large number of host routes is of course detrimental to scalability in any protocol. This perceived difference is no difference at all. Matt Squire Nortel Networks innovations.lab msquire@nortelnetworks.com (919)992-9048 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Oct 27 15:34:28 1999 Received: from lists.research.bell-labs.com (lists.research.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02866 for ; Wed, 27 Oct 1999 15:34:26 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5F87452F7; Wed, 27 Oct 1999 15:17:58 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DB20152F4; Wed, 27 Oct 1999 15:17:55 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199910261123.HAA01273@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-iptel-trip-00.txt Date: Tue, 26 Oct 1999 07:23:00 -0400 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --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 Information Protocol (TRIP) Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-trip-00.txt Pages : 63 Date : 22-Oct-99 This document presents the Telephony Routing Information Protocol (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-00.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-00.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-00.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: <19991022135609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-trip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-trip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022135609.I-D@ietf.org> --OtherAccess-- --NextPart-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Oct 29 08:08:37 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19973 for ; Fri, 29 Oct 1999 08:08:37 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B124B52F6; Fri, 29 Oct 1999 08:03:28 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1F0A052F8; Fri, 29 Oct 1999 08:03:28 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199910291201.IAA19700@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-iptel-cpl-framework-01.txt Date: Fri, 29 Oct 1999 08:01:43 -0400 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --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 : Call Processing Language Framework and Requirements Author(s) : J. Lennox, H. Schulzrinne Filename : draft-ietf-iptel-cpl-framework-01.txt Pages : 24 Date : 28-Oct-99 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-framework-01.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-cpl-framework-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-cpl-framework-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991028141740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-cpl-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-cpl-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991028141740.I-D@ietf.org> --OtherAccess-- --NextPart-- --------- This message came from the IETF IPTEL Working Group Mailing List.