From extest-admin@lists.bell-labs.com Sun Jul 1 04:59:39 2001 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 SMTP id EAA08358 for ; Sun, 1 Jul 2001 04:59: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 4B10D44355 for ; Sun, 1 Jul 2001 05:00:20 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20010701090020.4B10D44355@lists.bell-labs.com> Date: Sun, 1 Jul 2001 05:00:20 -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%40lists.ietf.org From iptel-admin@lists.bell-labs.com Tue Jul 3 00:54:27 2001 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 SMTP id AAA03505 for ; Tue, 3 Jul 2001 00:54: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 A76354434E; Tue, 3 Jul 2001 00:55:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by lists.bell-labs.com (Postfix) with ESMTP id 1853644336 for ; Tue, 3 Jul 2001 00:54:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f634rYki004577 for ; Tue, 3 Jul 2001 00:53:34 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3CZ0ZNHL>; Tue, 3 Jul 2001 00:54:00 -0400 Message-ID: From: Jonathan Rosenberg To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] New charter Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 3 Jul 2001 00:54:00 -0400 Folks, At the last meeting, we came to some agreement on a new charter for the iptel group. I've worked the new charter, and Scott Bradner has also had a look through it, and is now forwarding it on to IESG. The new charter is enclosed. Comments and input solicited. ---------------------------------------- IP Telephony (iptel) Working Group Chair: Jonathan Rosenberg Transport Area Directors: Scott Bradner Allison Mankin Transport Area Advisor: Scott Bradner Description The focus of the IP Telephony (iptel) group is on the problems related to propagation of routing information for VoIP protocols. Specifically, both SIP and H.323 have the notion of signaling intermediaries (proxies in SIP and gatekeepers in H.323). When these devices receive call establishment messages, they must make a routing decision on where to forward the call setup messages. The iptel group has already defined a protocol, Telephony Routing over IP (TRIP), which solves one aspect of this problem. Specifically, it handles the case where calls need to be routed between domains. It allows for the exchange of routing information between these domains, so that policies can be applied to the resulting data to create a forwarding information base. However, this protocol does not address all the scenarios of route information exchange between servers. One important scenario is the propagation of routing information between gateways and the signaling servers in front of them. This is also known as "gateway registration". It allows the signaling server to make a routing decision about which gateway to use based on dynamic information about the gateway resources. Vendors have deployed proprietary solutions for this communications interface. A standard is needed. The group will generate a standards track document that defines a protocol (possibly based on TRIP) for this interface. The group will also generate a MIB document for TRIP. Note that the group is not working on elevating TRIP to Draft Standard at this time. Deliverables: 1. A proposed standard RFC for gateway to server route exchange. 2. A proposed standard TRIP MIB specification, based heavily on the existing BGP-4 MIB documents. Milestones: Sep 01: TRIP MIB Document submitted to IESG for consideration as proposed standard Jan 02 : Gateway to Server Route Exchange document submitted to IESG for consideration as proposed standard. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jul 6 11:05:27 2001 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 SMTP id LAA06699 for ; Fri, 6 Jul 2001 11:05: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 24D954438F; Fri, 6 Jul 2001 11:06:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by lists.bell-labs.com (Postfix) with ESMTP id 168C744336 for ; Fri, 6 Jul 2001 11:05:55 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f66F5Pki013016 for ; Fri, 6 Jul 2001 11:05:28 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3CZ0ZT9T>; Fri, 6 Jul 2001 11:05:53 -0400 Message-ID: From: Jonathan Rosenberg To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] our slot Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 6 Jul 2001 11:05:52 -0400 Folks, We are scheduled to meet for a single hour at IETF 51, from 1300 - 1400 on Tuesday, August 7. We're up againts rap, multi6,forces, sasl, and pilc at the moment, but these things often change. The agenda is brief for now; mostly a discussion of the new charter, and (hopefully) the updated TRIP-lite document that will be submitted shortly. If you have any other agenda items, please let me know. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jul 9 01:35:25 2001 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 SMTP id BAA22960 for ; Mon, 9 Jul 2001 01:35:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 805794433B; Mon, 9 Jul 2001 01:36:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ttmxr.tw.lucent.com (mxr.lucent.com.tw [203.66.231.3]) by lists.bell-labs.com (Postfix) with ESMTP id 4CA3B44337 for ; Mon, 9 Jul 2001 01:35:41 -0400 (EDT) Received: from khex01.tw.lucent.com (h192-11-71-28.outland.lucent.com [192.11.71.28]) by ttmxr.tw.lucent.com (8.9.3/8.9.3) with ESMTP id NAA56832 for ; Mon, 9 Jul 2001 13:56:15 +0800 (CST) (envelope-from jeffwu@tw.lucent.com) Received: by khex01.tw.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Jul 2001 13:40:43 +0800 Message-ID: <3808A35A1931D51184CA00306E0099101AF5EF@khex01.tw.lucent.com> From: Jeff Wu To: iptel@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="big5" Subject: [IPTEL] Subscription of replying ---Re : IPTEL digest, Vol 1 #236 - 1 msg Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 9 Jul 2001 13:40:43 +0800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA22960 > -----原始郵件----- > 寄件者: iptel-request@lists.bell-labs.com [SMTP:iptel-request@lists. > bell-labs.com] > 傳送時間: 2001年7月7日 AM 12:01 > 收件者: iptel@lists.bell-labs.com > 主旨: IPTEL digest, Vol 1 #236 - 1 msg > > Send IPTEL mailing list submissions to > iptel@lists.bell-labs.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.bell-labs.com/mailman/listinfo/iptel > or, via email, send a message with subject or body 'help' to > iptel-request@lists.bell-labs.com > > You can reach the person managing the list at > iptel-admin@lists.bell-labs.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPTEL digest..." > << AE(r)×: Today's Topics (1 msg) >> << ?l¥o: ¥1/4(c)R|Wat¥o >> << > AE(r)×: Digest Footer >> _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jul 9 15:59:18 2001 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 SMTP id PAA27278 for ; Mon, 9 Jul 2001 15:59: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 5452A44354; Mon, 9 Jul 2001 16:00:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by lists.bell-labs.com (Postfix) with ESMTP id 8846F44337 for ; Mon, 9 Jul 2001 15:32:06 -0400 (EDT) Received: from DAVID ([192.168.1.61]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3QYA5H5J; Mon, 9 Jul 2001 15:32:40 -0400 From: "David Zinman" To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0071_01C1088C.5129C4A0" 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.2314.1300 Subject: [IPTEL] FW: I-D ACTION:draft-zinman-trip-mib-02.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 9 Jul 2001 15:32:09 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_0071_01C1088C.5129C4A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----Original Message----- From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, July 06, 2001 6:51 AM To: IETF-Announce: ; Subject: I-D ACTION:draft-zinman-trip-mib-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Management Information Base for Telephony Routing over IP (TRIP) Author(s) : J. Jiang, D. Walker, D. Zinman Filename : draft-zinman-trip-mib-02.txt Pages : 40 Date : 05-Jul-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage for Telephony Routing over IP (TRIP) [2] devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zinman-trip-mib-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-zinman-trip-mib-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-zinman-trip-mib-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_000_0071_01C1088C.5129C4A0 Content-Type: Message/External-body; name="ATT00193.dat" Content-Disposition: attachment; filename="ATT00193.dat" Content-Transfer-Encoding: 7bit Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113954.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zinman-trip-mib-02.txt ------=_NextPart_000_0071_01C1088C.5129C4A0 Content-Type: Message/External-body; name="draft-zinman-trip-mib-02.txt" Content-Disposition: attachment; filename="draft-zinman-trip-mib-02.txt" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0071_01C1088C.5129C4A0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jul 10 15:33:19 2001 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 SMTP id PAA16758 for ; Tue, 10 Jul 2001 15:33: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 34CA34433A; Tue, 10 Jul 2001 15:34:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by lists.bell-labs.com (Postfix) with ESMTP id AA50644337 for ; Tue, 10 Jul 2001 15:33:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6AJWWki022796 for ; Tue, 10 Jul 2001 15:32:35 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3THBBPAD>; Tue, 10 Jul 2001 15:33:01 -0400 Message-ID: From: Jonathan Rosenberg To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [IPTEL] FW: The 51st IETF Draft Agenda - 51st IETF WGs/BOFs Scheduling Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 10 Jul 2001 15:33:00 -0400 Folks, According to the latest agenda, iptel is now on FRIDAY of IETF. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: agenda@ietf.org [mailto:agenda@ietf.org] Sent: Tuesday, July 10, 2001 2:59 PM To: iesg@ietf.org Cc: wgchairs@ietf.org; bofchairs@ietf.org; dinaras@ietf.org Subject: The 51st IETF Draft Agenda - 51st IETF WGs/BOFs Scheduling Please find below the draft agenda of the 51st IETF Meeting in London. You can also find it at http://www.ietf.org/meetings/agenda_51.txt. Today's draft of the agenda will appear on the IETF web page tomorrow. Would like to remind you that the cut-off date for submission requests is July 17 at 1700 ET. Thanks, Dinara Suleymanova ====================== (As of July 10, 2001) Draft Agenda of the Fifty-first IETF August 5-10, 2001 SUNDAY, August 5, 2001 1200-1900 Registration 1530-1600 Newcomer's Orientation 1600-1630 IETF Standards Process Orientation 1700-1900 Welcome Reception =========== MONDAY, August 6, 2001 0800-1930 IETF Registration - 0800-0900 Continental Breakfast 0900-1130 Morning Sessions APP apparea Applications Open Area Meeting APP webdav WWW Distributed Authoring and Versioning WG INT ipngwg IPNG WG OPS disman Distributed Management WG RTG manet Mobile Ad-hoc Networks WG SEC ipsp IP Security Policy WG SUB-IP mpls Multiprotocol Label Switching WG TSV sip Session Initiation Protocol WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG OPS policy Policy Framework WG OPS mboned MBONE Deployment WG RTG udlr UniDirectional Link Routing WG SEC ipsec IP Security Protocol WG TSV seamoby Context and Micro-mobility Routing WG USV uswg User Services WG 1500-1530 Break (Refreshments provided) 1530-1730 Afternoon Sessions II APP cdi Content Distribution Internetworking WG INT magma Multicast & Anycast Group Membership BOF INT l2tpext Layer Two Tunneling Protocol Extensions WG RTG msdp Multicast Source Discovery Protocol WG OPS sming Next Generation Structure of Management Information WG SEC pkix Public-Key Infrastructure (X.509) WG TSV nfsv4 Network File System Version 4 WG TSV rserpool Reliable Server Pooling WG 1730-1930 Break 1930-2200 Evening Sessions APP fax Internet Fax WG APP ldup LDAP Duplication/Replication/Update Protocols WG APP imapext Internet Message Access Protocol Extension WG INT dnsext DNS Extensions WG OPS rmonmib Remote Network Monitoring WG SEC inch Extended Incident Handling BOF TSV ips IP Storage WG TSV rmt Reliable Multicast Transport WG TUESDAY, August 7, 2001 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP ldapbis LDAP (v3) Revision WG OPS ngtrans Next Generation Transition WG OPS eos Evolution of SNMP WG SUB-IP gsmp General Switch Management Protocol WG TSV sip Session Initiation Protocol WG 1130-1300 Break 1300-1400 Afternoon Sessions I APP webi Web Intermediaries WG OPS rap Resource Allocation Protocol WG OPS multi6 Site Multihoming in IPv6 WG RTG forces Forwarding and Control Element Separation BOF SEC sasl SASL BOF TSV ippm IP Performance Metrics WG TSV spirits Service in the PSTN/IN Requesting InTernet Service WG 1415-1515 Afternoon Sessions II APP ldup LDAP Duplication/Replication/Update Protocols WG INT itrace ICMP Traceback WG INT ipoib IP over InfiniBand WG OPS entmib Entity MIB WG TSV pilc Performance Implications of Link Characteristics WG TSV rmt Reliable Multicast Transport WG 1515-1545 Break (Refreshments provided) 1545-1645 Afternoon Sessions III APP ldup LDAP Duplication/Replication/Update Protocols WG OPS dnsop Domain Name Server Operations WG INT ipoib IP over InfiniBand WG OPS& hubmib& Ethernet Interfaces and Hub MIB WG & AToM MIB WG INT atommib RTG rtgarea Routing Area Meeting TSV sigtran Signaling Transport WG TSV pwe3 Pseudo Wire Emulation Edge to Edge WG 1700-1800 Afternoon Sessions IV INT zeroconf Zero Configuration Networking WG OPS bridge Bridge MIB WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC ipsra IP Security Remote Access WG SUB-IP iporpr IP over Resilient Packet Rings WG TSV diffserv Differentiated Services WG TSV pwe3 Pseudo Wire Emulation Edge to Edge WG WEDNESDAY, August 8, 2001 0800-1700 IETF Registration 0800-0900 Continental Breakfast 0900-1130 Morning Sessions APP calsch Calendaring and Scheduling WG INT dhc Dynamic Host Configuration WG OPS opsarea Operations & Management Open Area RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC smime S/MIME Mail Security WG SUB-IP ccamp Common Control and Measurement Plane WG TSV avt Audio/Video Transport WG TSV midcom Middlebox Communication WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP deltav Web Versioning and Configuration Management WG INT ipngwg IPNG WG OPS aaa Authentication, Authorization and Accounting WG OPS rmonmib Remote Network Monitoring WG RTG idr Inter-Domain Routing WG SEC tls Transport Layer Security WG TSV sipping Session Initiation Protocol Proposal InstiGation WG 1500-1530 Break (Refreshments provided) 1530-1730 Afternoon Sessions II APP provreg Provisioning Registry Protocol WG OPS adslmib ADSL MIB WG OPS ipfx IP Flow Export BOF SEC krb-wg Kerberos WG SEC msec Multicast Security WG SUB-IP ipo IP over Optical WG TSV seamoby Context and Micro-mobility Routing WG 1730-1930 Break 1930-2200 Open Plenary - Welcome - IAB Open Plenary - IESG Open Plenary 2230 Late Night Session PGP Key Signing THURSDAY, August 9, 2001 0800-1700 IETF Registration 0800-0900 Continental Breakfast 0900-1130 Morning Sessions APP trade Internet Open Trading Protocol WG OPS rap Resource Allocation Protocol WG SEC sacred Securely Available Credentials WG SUB-IP ppvpn Provider Provisioned Virtual Private Networks WG Sub-IP tewg Internet Traffic Engineering WG TSV avt Audio/Video Transport WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP opes Open Pluggable Edge Services WG INT idn Internationalized Domain Name WG OPS aaa Authentication, Authorization and Accounting WG OPS hubmib Ethernet Interfaces and Hub MIB WG SEC kink Kerberized Internet Negotiation of Keys WG TSV mmusic Multiparty Multimedia Session Control WG 1500-1530 Break (Refreshments provided) 1530-1730 Afternoon Sessions II APP whoisfix Whois Enhancement BOF INT atommib AToM MIB WG INT ipcdn IP over Cable Data Network WG OPS bmwg Benchmarking Methodology WG OPS policy Policy Framework WG TSV megaco Media Gateway Control WG TSV sipping Session Initiation Protocol Proposal InstiGation WG FRIDAY, August 10, 2001 0800-1000 IETF Registration 0800-0900 Continental Breakfast 0900-1130 Morning Sessions APP ldapext LDAP Extension WG APP vpim Voice Profile for Internet Mail WG INT& dnsext& DNS Extensions WG & Next Generation Transition WG OPS ngtrans TSV ips IP Storage WG TSV iptel IP Telephony WG _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jul 10 21:35:17 2001 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 SMTP id VAA03339 for ; Tue, 10 Jul 2001 21:35: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 379D44433C; Tue, 10 Jul 2001 21:36:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by lists.bell-labs.com (Postfix) with ESMTP id 5473344337 for ; Tue, 10 Jul 2001 21:35:25 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6B1Ypki024395; Tue, 10 Jul 2001 21:34:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3VPSWHNB>; Tue, 10 Jul 2001 21:35:18 -0400 Message-ID: From: Jonathan Rosenberg To: "'iptel@lists.bell-labs.com'" Cc: "Bradner, Scott (E-mail)" , "Allison Mankin (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] Status of the iptel group Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 10 Jul 2001 21:35:18 -0400 Folks, As the IETF is approaching, our ADs have reminded us that we should be sending out a status update to the list to let people know where we stand on our current working items. Here is the status on all existing trip drafts that I am aware of: draft-ietf-iptel-cpl-04.txt We are still blocked on the iCal issue. There has been discussion on the calsch list about this for a while. Its quieted down now, but is supposed to be top priority for calsch. Progress has been made, though, and the simple answer is that it looks like much of iCal will be put back into CPL. THe nuances of bysetpos are the open issue. Perhaps Jonathan can give a more detailed status update on the calsch discussions? draft-ietf-iptel-trip-07.txt We've gotten IESG comments back on the TRIP spec, and have been updating it with those comments incorporated. We are still working on getting some more comments incorporated, and are waiting further input from IANA on some registration issues. Overall, progress seems to be good. draft-ietf-iptel-trip-authen-00.txt The current plan is to not pursue this work until it is made clear that there is a need. draft-jfp-trip-servicecodes-00.txt The agreement was that this work was interesting, but that there was still sufficient confusion on the problem statement that it was premature to pursue. draft-walker-trip-tns-01.txt There seems to be consensus to define an IANA registered address family for cic codes. As per the IANA procedures specified in TRIP, this doesn't require an RFC. So, the text will effectively turn into an IANA request for an address family once TRIP goes to RFC and the IANA registries are created. draft-zinman-trip-mib-02.txt There is agreement to add this to the charter. Once the charter is approved, this document will be renamed draft-ietf-iptel-trip-mib. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jul 13 11:51:14 2001 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 SMTP id LAA26545 for ; Fri, 13 Jul 2001 11:51: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 9D51E44337; Fri, 13 Jul 2001 11:52:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from web13905.mail.yahoo.com (web13905.mail.yahoo.com [216.136.175.68]) by lists.bell-labs.com (Postfix) with SMTP id B004E44336 for ; Fri, 13 Jul 2001 11:51:27 -0400 (EDT) Message-ID: <20010713155128.5779.qmail@web13905.mail.yahoo.com> Received: from [63.84.167.14] by web13905.mail.yahoo.com via HTTP; Fri, 13 Jul 2001 08:51:28 PDT From: Gustaf Lawson Subject: RE: [IPTEL] Multiple nodes in CPL To: Jonathan Rosenberg , "'Bogdan - Andrei IANCU'" , iptel@lists.bell-labs.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1549406458-995039488=:5638" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 13 Jul 2001 08:51:28 -0700 (PDT) --0-1549406458-995039488=:5638 Content-Type: text/plain; charset=us-ascii How can we track progress being made by iptel and calsch in resolving issues with the iCalendar subset used in the CPL? Does anyone have a timeline for consideration by the IESG? Gustaf Lawson Software Engineer IPeria, Inc. Burlington, MA Jonathan Rosenberg wrote: > -----Original Message----- > From: Bogdan - Andrei IANCU [mailto:iancu@fokus.gmd.de] > Sent: Monday, June 25, 2001 3:33 PM > To: iptel@lists.bell-labs.com > Subject: [IPTEL] Multiple nodes in CPL > > > Is it allowed for a node (excepting the switches, proxy and lookup) to > have more than one child nodes? No. > For example, in a sub-action tag can you put a mail and > reject (in this > order) node on the same row? > . > . > > > > No. It would be like: > > I raise this problem because in the CPL draft, for some nodes > it is not > specified anything about the output or the following node. For other > nodes, like reject, mail, log there is said that they have no output, > but other nodes can follow. From this I can conclude that is > possible to > have more than one node in a row, but the question remains: for which > nodes is it allowed (there are in the draft nodes without any comment > about)? No; "follow" here means a subtag relationship. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel --------------------------------- Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ --0-1549406458-995039488=:5638 Content-Type: text/html; charset=us-ascii

How can we track progress being made by iptel and calsch in resolving issues with the iCalendar subset used in the CPL? Does anyone have a timeline for consideration by the IESG?

Gustaf Lawson
Software Engineer
IPeria, Inc.
Burlington, MA

  Jonathan Rosenberg <jdrosen@dynamicsoft.com> wrote:





> -----Original Message-----
> From: Bogdan - Andrei IANCU [mailto:iancu@fokus.gmd.de]
> Sent: Monday, June 25, 2001 3:33 PM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] Multiple nodes in CPL
>
>
> Is it allowed for a node (excepting the switches, proxy and lookup) to
> have more than one child nodes?

No.

> For example, in a sub-action tag can you put a mail and
> reject (in this
> order) node on the same row?
> .
> .
>
>
>
>

No. It would be like:







>
> I raise this problem because in the CPL draft, for some nodes
> it is not
> specified anything about the output or the following node. For other
> nodes, like reject, mail, log there is said that they have no output,
> but other nodes can follow. From this I can conclude that is
> possible to
> have more than one node in a row, but the question remains: for which
> nodes is it allowed (there are in the draft nodes without any comment
> about)?

No; "follow" here means a subtag relationship.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com

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


Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 a year!
http://personal.mail.yahoo.com/ --0-1549406458-995039488=:5638-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jul 13 13:41:14 2001 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 SMTP id NAA12777 for ; Fri, 13 Jul 2001 13:41: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 4907044338; Fri, 13 Jul 2001 13:42:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail1.dynamicsoft.com (unknown [63.113.40.10]) by lists.bell-labs.com (Postfix) with ESMTP id A56E644336 for ; Fri, 13 Jul 2001 13:41:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DHePRX020708; Fri, 13 Jul 2001 13:40:25 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YYC40CL>; Fri, 13 Jul 2001 13:40:59 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gustaf Lawson'" , Jonathan Rosenberg , "'Bogdan - Andrei IANCU'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] Multiple nodes in CPL MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 13 Jul 2001 13:40:58 -0400 Most of the discussions are on the calsch list, so you should join that. As for the timeline - I am continually hoping it will be resolved soon. The ADs have told calsch that they are not to do any other work until these things are resolved. That was about 1 month back. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Gustaf Lawson [mailto:guslawson@yahoo.com] Sent: Friday, July 13, 2001 11:51 AM To: Jonathan Rosenberg; 'Bogdan - Andrei IANCU'; iptel@lists.bell-labs.com Subject: RE: [IPTEL] Multiple nodes in CPL How can we track progress being made by iptel and calsch in resolving issues with the iCalendar subset used in the CPL? Does anyone have a timeline for consideration by the IESG? Gustaf Lawson Software Engineer IPeria, Inc. Burlington, MA Jonathan Rosenberg wrote: > -----Original Message----- > From: Bogdan - Andrei IANCU [mailto:iancu@fokus.gmd.de] > Sent: Monday, June 25, 2001 3:33 PM > To: iptel@lists.bell-labs.com > Subject: [IPTEL] Multiple nodes in CPL > > > Is it allowed for a node (excepting the switches, proxy and lookup) to > have more than one child nodes? No. > For example, in a sub-action tag can you put a mail and > reject (in this > order) node on the same row? > . > . > > > > No. It would be like: > > I raise this problem because in the CPL draft, ! for some nodes > it is not > specified anything about the output or the following node. For other > nodes, like reject, mail, log there is said that they have no output, > but other nodes can follow. From this I can conclude that is > possible to > have more than one node in a row, but the question remains: for which > nodes is it allowed (there are in the draft nodes without any comment > about)? No; "follow" here means a subtag relationship. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Jul 15 03:46:19 2001 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 SMTP id DAA09787 for ; Sun, 15 Jul 2001 03:46: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 416FD4433F; Sun, 15 Jul 2001 03:47:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 5933E44336 for ; Sun, 15 Jul 2001 03:46:27 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f6F7kPO09143; Sun, 15 Jul 2001 09:46:26 +0200 (MEST) Received: from ericsson.com (ppp14.lmf.ericsson.se [131.160.102.14]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6F7kN524794; Sun, 15 Jul 2001 10:46:23 +0300 (EET DST) Message-ID: <3B514A51.B0032FEA@ericsson.com> From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] Status of the iptel group References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sun, 15 Jul 2001 10:46:25 +0300 Content-Transfer-Encoding: 7bit Jonathan: I saw that the Gateway Registration draft, draft-rs-trip-gw-01.txt is expired and you didn't mention anything about it in the status of the IPtel working group. However, the Gateway Registration is a working group item for IPtel. So I am a little bit confused now. Can you clarify the status of the Gateway Registration? Regards, Miguel Jonathan Rosenberg wrote: > > Folks, > > As the IETF is approaching, our ADs have reminded us that we should be > sending out a status update to the list to let people know where we stand on > our current working items. Here is the status on all existing trip drafts > that I am aware of: > > draft-ietf-iptel-cpl-04.txt > > We are still blocked on the iCal issue. There has been discussion on the > calsch list about this for a while. Its quieted down now, but is supposed to > be top priority for calsch. Progress has been made, though, and the simple > answer is that it looks like much of iCal will be put back into CPL. THe > nuances of bysetpos are the open issue. Perhaps Jonathan can give a more > detailed status update on the calsch discussions? > > draft-ietf-iptel-trip-07.txt > > We've gotten IESG comments back on the TRIP spec, and have been updating it > with those comments incorporated. We are still working on getting some more > comments incorporated, and are waiting further input from IANA on some > registration issues. Overall, progress seems to be good. > > draft-ietf-iptel-trip-authen-00.txt > > The current plan is to not pursue this work until it is made clear that > there is a need. > > draft-jfp-trip-servicecodes-00.txt > > The agreement was that this work was interesting, but that there was still > sufficient confusion on the problem statement that it was premature to > pursue. > > draft-walker-trip-tns-01.txt > > There seems to be consensus to define an IANA registered address family for > cic codes. As per the IANA procedures specified in TRIP, this doesn't > require an RFC. So, the text will effectively turn into an IANA request for > an address family once TRIP goes to RFC and the IANA registries are created. > > draft-zinman-trip-mib-02.txt > > There is agreement to add this to the charter. Once the charter is approved, > this document will be renamed draft-ietf-iptel-trip-mib. > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Jul 15 21:24:11 2001 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 SMTP id VAA27981 for ; Sun, 15 Jul 2001 21:24: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 22EF844340; Sun, 15 Jul 2001 21:25:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail1.dynamicsoft.com (unknown [63.113.40.10]) by lists.bell-labs.com (Postfix) with ESMTP id 809DA44336 for ; Sun, 15 Jul 2001 21:24:29 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6G1NrRX026789; Sun, 15 Jul 2001 21:23:53 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YYCVBHC>; Sun, 15 Jul 2001 21:24:27 -0400 Message-ID: From: Jonathan Rosenberg To: "'Miguel A. Garcia'" Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] Status of the iptel group MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sun, 15 Jul 2001 21:24:23 -0400 > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Sunday, July 15, 2001 3:46 AM > To: Jonathan Rosenberg > Cc: 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] Status of the iptel group > > > Jonathan: > > I saw that the Gateway Registration draft, > draft-rs-trip-gw-01.txt is expired and > you didn't mention anything about it in the status of the > IPtel working group. > However, the Gateway Registration is a working group item for > IPtel. So I am a > little bit confused now. > > Can you clarify the status of the Gateway Registration? Yes, my apologies for the confusion. draft-rs-trip-gw-01.txt has expired. I am updating it next week. It is part of the new charter of the iptel group, and I have heard from Scott that our new charter has also been tentatively approved. So, after IETF, I will be able to resubmit once more as draft-ietf-iptel-gw-reg-00.txt. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jul 17 13:34:34 2001 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 SMTP id NAA28356 for ; Tue, 17 Jul 2001 13:34: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 D4FEC44350; Tue, 17 Jul 2001 13:34:10 -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 D1B6C44336; Tue, 17 Jul 2001 13:22:51 -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 NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group Cc: iesg@ietf.org Subject: [IPTEL] Note Well Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 17 Jul 2001 13:16:53 -0400 Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jul 17 13:39:08 2001 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 SMTP id NAA29478 for ; Tue, 17 Jul 2001 13:39:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 941FE44336; Tue, 17 Jul 2001 13:34:33 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from roam.psg.com (H-135-207-10-122.research.att.com [135.207.10.122]) by lists.bell-labs.com (Postfix) with ESMTP id 50F6544336; Tue, 17 Jul 2001 13:28:10 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group Cc: iesg@ietf.org Message-Id: Subject: [IPTEL] Note Well Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 17 Jul 2001 13:25:25 -0400 Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jul 19 10:34:11 2001 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 SMTP id KAA12353 for ; Thu, 19 Jul 2001 10:34: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 9A01344338; Thu, 19 Jul 2001 10:35:04 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by lists.bell-labs.com (Postfix) with ESMTP id B577E44337 for ; Thu, 19 Jul 2001 10:34:10 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f6JEY0g08417 for ; Thu, 19 Jul 2001 15:34:00 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Thu, 19 Jul 2001 15:33:19 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 15:32:00 +0100 Message-ID: From: "Michael O'Doherty" To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1105F.901B4B90" Subject: [IPTEL] Half-Pint Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 19 Jul 2001 15:31:56 +0100 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_000_01C1105F.901B4B90 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1105F.901B4B90" ------_=_NextPart_001_01C1105F.901B4B90 Content-Type: text/plain; charset="iso-8859-1" Hi, I have submitted a new draft entitled 'Half-Pint' which as the name (kind of ...) suggests is a lightweight, restricted take on the functionality provided by the PINT protocol. The idea is to try to hit the high runner things that web developers wanting to integrate web applications with the PSTN want to do right now, and make it available in a way that web developers are familiar with and can work with right away. The natural place to discuss this would have been the PINT group, but unfortunately it is not around anymore, so I'm sending this notice onto to some other groups that may be interested in this type of thing to get feedback and comments. Cheers, Mick O'Doherty. P.S. I've attached the draft to this email as the version in the archives has picked up a few formatting errors somehow and is not quite fixed up yet. <> ------_=_NextPart_001_01C1105F.901B4B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Half-Pint

Hi,

I have submitted a new draft = entitled 'Half-Pint' which as the name (kind of ...) suggests is a = lightweight, restricted take on the functionality provided by the PINT = protocol.

The idea is to try to hit the = high runner things that web developers wanting to integrate web = applications with the PSTN want to do right now, and make it available = in a way that web developers are familiar with and can work with right = away.

The natural place to discuss = this would have been the PINT group, but unfortunately it is not around = anymore, so I'm sending this notice onto to some other groups that may = be interested in this type of thing to get feedback and = comments.

Cheers,

Mick O'Doherty.

P.S. I've attached the draft = to this email as the version in the archives has picked up a few = formatting errors somehow and is not quite fixed up yet.


= <<draft-odoherty-half-pint-00.txt>>

------_=_NextPart_001_01C1105F.901B4B90-- ------_=_NextPart_000_01C1105F.901B4B90 Content-Type: text/plain; name="draft-odoherty-half-pint-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-odoherty-half-pint-00.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force Transport Area working = Group =20 NTERNET-DRAFT Mick = O=92Doherty=20 draft-ODoherty-Half-Pint-00.txt = =20 Nortel Networks=20 July 2001 = =20 =20 =20 Half-Pint=20 =20 Status of this Memo=20 =20 =20 This document is an Internet-Draft and is in full conformance with = all=20 provisions of Section 10 of RFC2026 [1]. =20 =20 Internet-Drafts are working documents of the Internet Engineering = Task Force=20 (IETF), its areas, and its working groups. Note that other groups = may also=20 distribute working documents as Internet-Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six = months and=20 may be updated, replaced, or obsoleted by other documents at any = time. It is=20 inappropriate to use Internet- Drafts as reference material or to = cite them=20 other than as "work in progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 1. Abstract=20 =20 This document defines a simple protocol for interaction between the = PSTN and=20 applications in the IP domain. It is not intended to be a full INAP = or JAIN=20 like interface, rather to easily enable some of the more common = interactions=20 in a way that will allow application developers, with minimal = telephony=20 knowledge, to quickly integrate it into new and existing = applications. This=20 document includes simple Java HTTP Servlets which implement some = basic parts=20 of the protocol as an example (note similar approaches would work = for CGI=20 also). To get a quick feel for the protocol go straight to the = example=20 section near the end.=20 =20 2. Overview=20 =20 Half-Pint allows developers of web applications, or in fact any type = of=20 applications, to interact with the functionality provided by the = Public=20 Switched Telephony Network (PSTN) or any other telephony system that = conforms to the Half-Pint protocol.=20 =20 It supports application to telephony system initiated interactions, = such as=20 creating calls between two telephony agents, as well as telephony = system to=20 application initiated interactions such as notification of incoming = calls.=20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = It is intended to be very easy to integrate into Web applications = and to=20 provide a quick way to interact with a small set of common services. = In this=20 way it is limited when compared with Intelligent Network (IN) or = Java JAIN=20 like protocols, and it is not intended to compete with these more = complete=20 solutions.=20 =20 The protocol is best described by looking at the messages and = procedures=20 that compose it and the remainder of this document follows this = format.=20 =20 A quick way to get a feel for the protocol is to go straight to the = example=20 section at the end.=20 =20 The appendices include an example Java Servlet implementation that = shows how=20 a message might be generated and received.=20 =20 3. General format of messages=20 =20 The protocol is defined in this document using the ABNF scheme = defined in=20 [3].=20 =20 A half-pint message is defined as:=20 =20 Half-Pint-message =3D HalfPintVersion =20 Addressee=20 Sender=20 TransactionID =20 [ AuthenticationInfo ] =20 MessageTypeandParameterPair =20 =20 HalfPintVersion =3D (=93HalfPintVersion=94 | =93v=94) =93:=94 *token = =20 Addressee =3D (=93Addressee=94 | =93a=94) =93:=94 absoluteURI=20 =20 Sender =3D (=93Sender=94 | =93s=94) =93:=94 absoulteURI=20 =20 TransactionID =3D (=93TransactionID=94 | =93t=94) =93:=94 token [ = =93@=94 token]=20 =20 AuthenticationInfo =3D (=93AuthenticationInfo=94 | =93ai=94) =93:=94 = *token=20 =20 Token =3D 1*< any CHAR except CTL's or separators> ; as in SIP = spec [2]=20 =20 CTL =3D =20 =20 MessagetTypeandParameterPair =3D (=93MessagetType=94 | =93m=94) = =93:=94 =20 ( =93CreateCall=94 CreateCallParameterSet=20 | =93AddPartyToCall=94 AddPartyToCallParameterSet=20 | =93BookConferenceCall=94 BookConferenceCallParameterSet=20 | =93ConferenceCallResponse=94 = ConferenceCallResponseParameterSet=20 | =93GeneralResponse=94 GeneralResponseParameterSet=20 | =93RegisterCallAlert=94 RegisterCallAlertParameterSet=20 | =93CancelCallAlert=94 CancelCallALertParameterSet=20 | =93GetCallLog=94 GetCallLogParameterSet=20 | =93ClearCallLog=94 ClearCallLogParameterSet=20 | =93CallLog=94 CallLogParameterSet=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = | =93CallAlert=94 CallAlertParameterSet=20 | =93CallAlertResponse=94 CallAlertResponseParameterSet=20 | =93CallAlertError=94 CallAlertErrorParameterSet=20 | =93SetSubscriberService=94 SetSubscriberServiceParameterSet=20 | =93QuerySubscriberService=94 = QuerySubscriberServiceParameterSet=20 | =93SubscriberServiceStatus=94 = SubscriberServiceStatusParameterSet=20 | =93VoiceMailBoxQuery=94 VoiceMailBoxQueryParameterSet =20 | =93VoiceMailBoxResponse=94 VoiceMailBoxResponseParameterSet=20 | =93VoiceMailRequest=94 RetrieveVoiceMailParameterSet=20 | =93VoiceMail=94 VoiceMailParameterSet )=20 =20 =20 An example of a CreateCallMessage is shown below =96 the additional = parameters=20 are explained later in the document: =20 =20 HalfPintVersion : 1.0=20 Addressee : teleservice@teleprovider.org =20 Sender : 47.23.10.10=20 TransactionID : 12345 =20 AuthenticationInfo : X1943667 =20 MessageType : CreateCall=20 CallingParty : +441628770770=20 CalledParty : +12137632212=20 AnnouncementID : 5t443r=20 CompletionNotification : n=20 =20 =20 4. Message addressing, transaction id, and authentication info=20 =20 The Addressee, Sender and TransactionID parts of the message as = defined=20 above allow a receiver of a message to know who the message is for, = who it=20 is from and give a globally unique identifier for the transaction in = the=20 TransactionID. A transaction is a logical groupings of messages, such = as a=20 CreateCall and a Response or a CallAlert and a CallAlertError. In = general,=20 any message which is sent in reply to another message, should use the = transaction-id in the original message.=20 =20 In general it is expected that messages will be sent directly from = the=20 receiver to the sender, so the receiver of the message will just = check that=20 the message is from them (by looking at the Addressee field) and then = act on=20 it. However, messages can be proxied in which case the receiver looks = at the=20 Addressee and (if it decides to forward the message) sends it on to = the=20 receiver (or the next proxy in the path).=20 =20 The addressee and sender are defined as standard absolute URI=92s = for this=20 version of the document =96 further study is required to decide how = best to=20 represent these fields (for example do we need a new URL scheme = etc).=20 =20 In the case where a port number is not specified a default port of = 7071 will=20 be used.=20 =20 The TransactionID is similar to the call-id in the SIP protocol [2] = from=20 which this definition is taken and is simply to allow a particular = request=20 be uniquely identified: it MUST be a globally unique identifier and = MUST NOT=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = be reused for later calls. Use of cryptographically random = identifiers is=20 RECOMMENDED. Implementations MAY use the form "localid@host". = Call-IDs are=20 case-sensitive and are simply compared byte-by-byte.=20 =20 Authentication info is used to identify the sender of a message and = if=20 necessary to decide if they have permission to use a particular = service. The=20 implementation of Authentication info is a topic for further study.=20 =20 =20 5. General message sending and responding procedures =20 =20 When a Half Pint message is received that needs to be replied to, = the reply=20 MUST be sent to the destination specified in the Sender field in the = message.=20 =20 All Half Pint messages MUST have the destination address specified = in the=20 Addressee field of the message and this is the destination which the = message=20 must be delivered to by whatever transport system is being used.=20 =20 =20 6. Call Initiation messages and procedures =20 =20 The following messages are defined to allow an application request = that a=20 call be initiated between two specified parties by the PSTN = interface proxy:=20 =20 6.1 CreateCall =20 =20 Overview=20 --------=20 CreateCall is used to request that a telephony proxy create a call = between=20 the parties identified in the parameters of the message. The call = will be=20 created by first ringing the =91calling party=92 and presenting them = with=20 ringing tone and then establishing a call between them and the = =91called=20 party=92. When the called party answers the call is fully set up.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for CreateCall is:=20 =20 CreateCallParameterSet =3D CallingParty=20 CalledParty=20 [AnnouncementID] =20 CompletionNotification=20 [CLIPresentation]=20 =20 CallingParty =3D (=93CallingParty=94 | =93cp=94) =93:=94 *token=20 CalledParty =3D (=93CalledParty=94 | =93cdp=94) =93:=94*token=20 AnnouncementID =3D (=93AnnouncementID=94 | =93aid=94) =93:=94 *token = CompletionNotification =3D (=93CompletionNotifictaion=94 | =93cn=94) = =93:=94 (=93y=94 | =93n=94)=20 CLIPresentation =3D (=93CLIPresentation =94 | =93cli=94) =93:=94 = Restrict=20 | Present=20 Restrict =3D =93Restrict=94 | =93r=94=20 Present =3D =93Present=94 | =93p=94=20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = =20 =20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The application or entity generating this message, having built the = message=20 with all the correct information including the TransactionID, should = wait=20 for a GeneralResponse with a matching TransactionID to confirm that = the=20 telephony proxy that the message was sent to received the message. = The=20 General response will indicate if the request was successful or not. = This=20 indicates that the telephony proxy has agreed to make the requested = call,=20 not that the call has already been successfully set up. If no = response is=20 received within a certain time the application may decide to resend = the=20 message until 5 attempts have been made. The timeout period is left = as=20 implementation detail.=20 =20 Additionally, if an announcementID is included the receiver MUST = play the=20 announcement before setting up the call. If they do not have the = ability to=20 do this, then they MUST indicate that they cannot service the entire = request=20 with a General Request as mentioned above. The value of the = announcement ID=20 must be something that the receiver of the message will understand. = How this=20 is communicated is left to a implementation/deployment decision (for = instance a service provider may provide a special code for a = customer=20 announcement or may provide a list of standard announcement ids.=20 Additionally they may provide some secure facility for a customer to = load=20 there own announcement id and then provide a unique id for it).=20 =20 If the application has requested CompletionNotification then it = should be=20 ready to accept an additional GeneralResponse message, indictaing = either=20 that the call has been successfully set up (responseType =3D = =91ok=92) or that it=20 has not been set up for some reason (response type =3D =91error=92). = In both these=20 cases the responseText field MUST begin with = =91CreateCallConfirmation=92.=20 =20 If the application wishes to specify whether the CLI should be = restricted or=20 not it can specify this with the CLIPresentation parameter. If the = parameter=20 is not set the default setting for the user is set. Note that if = this=20 parameter is used it must be checked that it is supported by and = within the=20 rules of the telephony network.=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message should determine if it has the capability = to=20 service this request and if it does it should return a = GeneralResponse=20 message with a ResponseType of =91OK=92. If it does not it should = return a=20 GeneralResponse message with a ResponseType of = =91CannotServiceRequest=92.=20 =20 If it is servicing the request the receiver must either directly, or = through=20 some other mechanism set up a call firstly to the CallingParty, = connecting=20 them to a ringing tone, and then establish a call to the CalledParty. = If an=20 AnnouncementID was specified, the CallingParty is first connected to = the=20 announcement before being connected to the RingingTone (or the = CalledParty=20 if the Announcement is used in place of the RingintTone). If the=20 AnnouncementID is not receognised a GeneralResponse with an = ResponseType of=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = =91Error=92 should be returned. Similarly, if CLIPresentation was = specified as=20 either Present or Restrict and this cannot be done, then a = GeneralResponse=20 with an ResponseType of =93CannotServiceRequest=94 MUST be sent and = additionally=20 a ResponseText reason in a human readable format can be given. =20 =20 If the application which sent the CreateCall message indicated that = it=20 wanted notification of call setup, an additional GeneralResponse = message=20 must be sent back to the application indicating whether the call was = set up=20 successfully or not =96 if the call was set up successfully the = responseType=20 Parameter is set to =91ok=92 and if not then it is set to = =91error=92. The=20 responseText parameter MUST begin with the text = =91CreateCallConfirmation=92.=20 =20 =20 =20 6.2 AddPartyToCall=20 =20 Overview=20 --------=20 AddPartyToCall is used to request that a telephony proxy add a party = to an=20 existing call. The call is identified by one of the subscriber = numbers=20 involved in the call. =20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for AddPartyToCall is:=20 =20 AddPartyToCallParameterSet =3D SubscriberNumToAdd=20 SubscriberNumber=20 [CLIPresentation]=20 =20 =20 SubscriberNumToAdd =3D (=93SubscriberNumToAdd=94 | =93sna=94) = =93:=94 *token=20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) = =93:=94*token=20 CLIPresentation =3D (=93CLIPresentation =94 | =93cli=94) =93:=94 = Restrict=20 | Present=20 Restrict =3D =93Restrict=94 | =93r=94=20 Present =3D =93Present=94 | =93p=94 = =20 =20 =20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The application or entity generating this message, having built the = message=20 with all the correct information including the TransactionID, should = wait=20 for a GeneralResponse with a matching TransactionID and a = ResponseType of=20 =91ok=92 to confirm that the new party was added to the call, or a = ResponseType=20 other than =91ok=92 if the Party was not added to the call.=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message should determine if it has the capability = to=20 service this request and if it does it should return a = GeneralResponse=20 message with a ResponseType of =91OK=92once it has added the party. = If it does=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = not it should return a GeneralResponse message with a ResponseType of = =91CannotServiceRequest=92.=20 =20 If it determines that the Subscriber number which identifies the call = that=20 that the new party is to be added to is not involved in a call, it = again=20 returns a GeneralResponse message with a ResponseType of =91error=92 = and may=20 additionally indicate in the ResponseText that the SubscriberNumber = was not=20 in a call.=20 =20 If CLIPresentation is present and is set to a value that it cannot = comply=20 with, it should send a GeneralResponse message with a ResponseType of = =91CannotServiceRequest=92 and may additionally indicate in the = ResponseText why=20 it was not able to comply in a human readable form.=20 =20 =20 =20 6.3 BookConferenceCall=20 =20 Overview=20 --------=20 BookConferenceCall is used to request that a telephony proxy create = a=20 conference call at a specified time and for a specified maximum = number of=20 participants. The telephony proxy will return host and participant = dial in=20 numbers, as well as password for each in a ConferenceCallResponse = message.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for BookConferenceCall is:=20 =20 BookConferenceCallParameterSet =3D StartTime=20 EndTime=20 MaxParticipants=20 =20 =20 StartTime =3D (=93StartTime=94 | =93s=94) =93:=94 DateAndTime=20 EndTime =3D (=93EndTime=94 | =93e=94) =93:=94 DateAndTime=20 MaxParticipants =3D (=93MaxParticipants=94 | =93mp=94) =93:=94 = *Digit=20 DateAndTime =3D (=93DateAndTime=94 | =93d=94) =93:=94 Date Time=20 Date =3D Day.Month.Year=20 Time =3D hour.min=20 Day =3D =93Mon=94 | =93Tue=94 | =93Wed=94 | =93Thur=94 | =93Fri=94 | = =93Sat=94 | =93Sun=94=20 Month =3D firstdigit.seconddigit=20 Year =3D 4*4Digit=20 Firstdigit =3D %x30-31; can be =930=94 or =931=94=20 Seconddigit =3D %x30-39; can be =930=94 to =939=94=20 Hour =3D hourfirstdigit.hourseconddigit=20 Hourfirstdigit =3D %x30-32; can be =930=94 or =931=94 or =932=94=20 Hourseconddigit =3D %x30-39; can be =930=94 to =939=94=20 Min =3D Minfirstdigit.Minseconddigit=20 Minfirstdigit =3D %x30-35; can be =930=94 or =931=94 or =932=94 or = =933=94 or =934=94 or =935=94=20 Minseconddigit =3D %x30-39; can be =930=94 to =939=94=20 =20 =20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = =20 Procedures for the generator of the message=20 -------------------------------------------=20 The application or entity generating this message, having built the = message=20 with all the correct information including the TransactionID, should = wait=20 for a ConferenceCallResponse with a matching TransactionID to = confirm that=20 the telephony proxy that the message was sent to received the = messageand has=20 agreed to set up the conference call. If the telephony proxy has not = agreed=20 to set up the call this will be indicated in the = ConferenceCallResponse. If=20 no response is received within a certain time the application may = decide to=20 resend the message until 5 attempts have been made. The timeout = period is=20 left as implementation detail.=20 =20 If the telephony Proxy has agreed to set up the call then the = application=20 should store and/or pass on to the user(s) the host and participant = numbers=20 and passwords.=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message should determine if it has the capability = to=20 service this request and if it does and the resources are available = at the=20 requested time, it should return a ConferenceCallResponse message = with a=20 confirmation parameter of =91y=92. If it does not it should return a=20 ConferenceCallResponse message with a confirmation parameter of = =91n=92.=20 =20 If it is servicing the request it must also include the host and = participant=20 numbers and paswords.=20 =20 =20 6.4 ConferenceCallResponse=20 =20 Overview=20 --------=20 ConferenceCallResponse is used by a telephony proxy to respond to a=20 BookConferenceCall message.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for ConferenceCallResponse is:=20 =20 ConferenceCallResponseParameterSet =3D Confirmation=20 [HostNumber=20 HostPassword=20 ParticipantNumber=20 ParticipantPassword ] =20 =20 Confirmation =3D (=93Confirmation=94 | =93c=94) =93:=94 (=93y=94 | = =93n=94)=20 HostNumber =3D (=93HostNumber=94 | =93hn=94) =93:=94*token=20 HostPassword =3D (=93HostPassword=94 | =93hp=94) =93:=94*token=20 ParticipantNumber =3D (=93ParticipantNumber=94 | =93pn=94) = =93:=94*token=20 ParticipantPassword =3D (=93ParticipantPassword=94 | =93pp=94) = =93:=94*token=20 =20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = Procedures for the generator of the message=20 -------------------------------------------=20 The application or entity generating this message, having built the = message=20 with all the correct information including the TransactionID, sends = the=20 message and does not expect a response. The host number and = participant=20 numbers refer to the numbers the host and the participants should = dial in=20 with. The password indicates the password they should enter when = prompted.=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message will receive this in response to a=20 BookConferenceCall message and should cancel any timers associated = with the=20 transaction.=20 =20 =20 7. Call Alert messages and procedures=20 =20 These messages allow a telephony proxy to notify an application = about an=20 incoming call and provide a number of alternative actions that the=20 application can take in response.=20 =20 7.1 RegisterCallAlert=20 =20 Overview=20 --------=20 RegisterCallAlert is used by a subscriber to indicate that they want = to be=20 notified with a CallAlert message when a call is received on the = specified=20 number. It may also be used by an application to indicate that it = wants to=20 be notified of incoming calls to a particular number (the telephony = proxy=20 must decide based on the authentication information whether to grant = this to=20 a particular user to avoid misuse of this feature =96 this is an=20 implementation and deployment decision).=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for RegisterCallAlert is:=20 =20 RegisterCallAlertParameterSet =3D SubscriberNumber=20 *URItoAlert=20 =20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 URItoAlert =3D (=93URItoAlert=94 | =93U=94) =93:=94 absoluteURI=20 =20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The application or entity generating this message, having built the = message=20 with all the correct information including the TransactionID, should = wait=20 for a GeneralResponse with a matching TransactionID to confirm that = the=20 telephony proxy has accepted this request and will generate = CallAlert=20 Messages when appropriate and send them to each URIlisted in the URI = to=20 alert list.=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = =20 If there was already registered URI=92s to be aletered for this = Subscriber=20 number the new URI=92s are added to the list to be alerted.=20 =20 Message timeout and retry timeout handling are as for the CreateCall = message. =20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message should determine if it has the capability = to=20 service this request and if it does it should return a = GeneralResponse=20 message with a ResponseType of =91ok=92. If it does not it should = return a=20 GeneralResponse message with a ResponseType of = =91CannotServiceRequest=92.=20 =20 7.2 CancelCallAlert=20 =20 Overview=20 --------=20 CancelCallALert is used by a subscriber to indicate that they no = longer want=20 to be notified with a CallAlert message when a call is received on = the=20 specified number. It may also be used by an application to indicate = that it=20 no longer wants to be notified of incoming calls to a particular = number (the=20 telephony proxy must decide based on the authentication information = whether=20 to grant this to a particular user to avoid misuse of this feature = =96 this is=20 an implementation and deployment decision).=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for CancelCallAlert is:=20 =20 CancelCallAlertParameterSet =3D SubscriberNumber=20 [*URItoAlert]=20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 URItoAlert =3D (=93URItoAlert=94 | =93U=94) =93:=94 absoluteURI=20 =20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The application or entity generating this message, having built the = message=20 with all the correct information including the TransactionID, should = wait=20 for a GeneralResponse with a matching TransactionID to confirm that = the=20 telephony proxy has accepted this request and will not generate = CallAlert=20 messages to the specified URI when a call arrives on the specified = number.=20 =20 If there are no URItoAlert=92s in the message then all the = previously=20 registered URI=92s for this subscriber number are cancelled.=20 =20 Message timeout and retry timeout handling are as for the CreateCall = message. =20 =20 =20 Procedures for the receiver of the message=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = ------------------------------------------=20 The receiver of the message should cancel any notification associated = with=20 this number and send back a successful general response message. If = it had=20 no notification set on this number it should still reply with a = Successful=20 General Response message.=20 =20 7.3 CallAlert =20 =20 Overview=20 --------=20 CallAlert is used to indicate that a Call has been received on a = particular=20 subscriber number. It may contain a set of allowed actions that may = be=20 included in a CallAlertResponse message.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for CallAlert is:=20 =20 CallAlertParameterSet =3D CallingParty=20 CalledParty=20 [ForwardedFromParty]=20 *AlertParameters=20 =20 CallingParty =3D (=93CallingParty=94 | =93cp=94) =93:=94 *token=20 CalledParty =3D (=93CalledParty=94 | =93cdp=94) =93:=94 *token=20 ForwardedFromParty =3D (=93ForwardedFromParty=94 | =93fp=94) =93:=94 = *token=20 AlertParameters =3D ContactURL =20 | CallingName =20 | CallingPictureURL=20 | ActionOption=20 ContactURL =3D (=93ContactURL=94 | =93ctu=94) =93:=94 AbsoluteURI=20 CallingName =3D (=93CallingName=94 | =93cln=94) =93:=94 *token=20 CallingPictureURL =3D (=93CallingPictureURL=94 | =93picU=94) =93:=94 = AbsoluteURI=20 ActionOption =3D ActionLabel=20 [ActionText] =20 ActionText =3D *Token=20 ActionLabel =3D PreDefinedAction=20 | SenderDefinedAction=20 SenderDefinedAction =3D *Token=20 PreDefinedAction =3D =93RejectCall=94=20 | =93ForwardCallTo=94 =93:=94 *token=20 | =93SendToVoiceMail=94=20 =20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The telephony proxy generates this message for each device that is=20 registered to be notified when a call is received on this number. It = builds=20 the messages with all the applicable headers including a = transaction-id per=20 message and sends them out. The ActionOptions fields indicate the = actions=20 (if any) that the receiver of the message may choose and send back = in a=20 CallAlertResponse message. The Actions may be one or more of the set = of=20 predefined actions, or a sender defined action represented by a text = string.=20 The actions, whether predefined or User defined may be accompanied = by a text=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = string which should be suitable for display to a human user, if the=20 receiving application is capable of and wishes to present it. If the = call=20 was previously forwarded and this information is available it should = be=20 included in the ForwardedFromParty parameter.=20 =20 Once the message has been sent a Response is expected and the sender = should=20 wait for this. Message retry and timeout is the same as for Create = Message=20 and the timeout period is left to the implementation, but for this = case it=20 must allow for the telephony call which is associated with this = message and=20 which will almost certainly have its own timers and timeouts.=20 =20 When the Response is received, the telephony Proxy should apply = whatever=20 action the Response indicates. If no Action is indicated, or if the = original=20 message did not include any action options, then the message is = simply a=20 confirmation that the message was received and the call telephony = Server=20 should apply the default action, which is to allow the call to = continue as=20 it would normally.=20 =20 If the Response contains an action which is not supported by the = Telephony=20 Proxy or which it does not wish to allow for this subscriber number = or=20 sending application, or the response does not correspond to any call = or=20 CallAlert message sent by the telephony Proxy it MUST reply to the = message=20 with a CallAlertError message with a the reason set appropriately = and=20 optionally a Human readable error message.=20 =20 Once the first response has been received all further responses = (from other=20 devices the CallAlert was sent to for example) are ignored and a=20 CallAlertError message is sent back to the sender with a code of=20 =91NoCallAlertSent=92.=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message should look at the allowed actions (if = any) and=20 decide by whatever means it wants (e.g. interaction with a human = user, rules=20 table, algorithm etc) which action (if any) it wants to take. If it = does not=20 recognize any of the actions in the case where the actions are user = defined,=20 then it simply responds with a CallALert message with no Action = included.=20 The same reply is used for the case where the CallAlert contained no=20 ActionOptions.=20 =20 =20 7.4 CallAlertResponse =20 =20 Overview=20 --------=20 CallAlertResponse is sent in reply to a CallAlert message to = acknowledge=20 receipt of the CallAlert and to indicate which (if any) of the = allowed=20 Actions has been selected.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for CallAlertResponse is:=20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = CallAlertResponseParameterSet =3D ActionLabel=20 =20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 This message is sent in response to a CallAlert Message so the = procedures=20 are as for the receiver of CallAlert Messages above.=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 If the receiver has sent a CallAlert which led to this response then = the=20 procedures are as defined in the generator of CallAlert messages = above. =20 =20 If the receiver had not generated a CallAlert message and hence did = not=20 expect this message then a CallAlertError message is generated with a = reason=20 of =91NoCallAlertSent=92 and optionally a human readable error = message in the=20 CallError parameter.=20 =20 =20 7.5 CallAlertError =20 =20 Overview=20 --------=20 CallAlertError is used to indicate that an Error has been generated = during a=20 CallAlert interaction, usually because the CallAlertResponse has = some=20 problem with it. =20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for CallAlert is:=20 =20 CallAlertErrorParameterSet =3D ErrorType=20 ErrorMessage=20 =20 ErrorType =3D =93NoCallAlertSent=94=20 | =93ResponseFromOtherDeviceReceived=94=20 | =93UnknownAction=94=20 | =93ActionNotAllowed=94=20 | =93CallError=94=20 =20 ErrorMessage =3D *Token=20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The cases in which a CallAlert Error message can be generated are = described=20 in the CallAlert and CallAlertResponse sections above. The generator = builds=20 and sends the message with the appropriate error code and an error = message=20 which can be presented to a human user if appropriate. =20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = The receiver of the message should look at Error code and Error = message and=20 raise an alarm or notify the user as appropriate. =20 =20 =20 8. Call Log Messages=20 =20 These messages allow an application or user query and manipulate = call log=20 details for a specified subscriber number.=20 =20 8.1 GetCallLog=20 =20 Overview=20 --------=20 GetCallLog is used to request a log of incoming, outgoing or both = incoming=20 and outgoing calls from a telephony proxy. The requester can specify = how=20 many calls back in the call history they want to go. =20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for GetCallLog is:=20 =20 GetCallLogParameterSet =3D SubscriberNumber=20 Direction=20 [NumberOfCalls] =20 =20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 Direction =3D (=93Direction=94 | =93D=94) =93:=94 DirectionString=20 DirectionString =3D (=93Incoming=94 | =93I=94) |(=93Outgoing=94 | = =93O=94) | (=93both=94 | =93b=94)=20 NumberOfCalls =3D Integer=20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The application or entity generating this message, having built the = message=20 with all the correct information including the TransactionID, should = wait=20 for a CallLog message with a matching TransactionID.=20 =20 Message timeout and retry timeout handling are as for the CreateCall = message.=20 =20 Note that the NumberOfCalls Parameter can be used to get the last 5, = 10 etc=20 calls, or simply the last one call making this effectively a get = last call=20 message.=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message should reply with a CallLog message for = the=20 specified direction(s) if it is capable of servicing the request or = with a=20 GeneralResponse message with a ResponseType of = =91CannotServiceRequest=92 if it=20 is not.=20 =20 =20 8.2 ClearCallLog=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = =20 Overview=20 --------=20 ClearCallLog is used to Clear the Call Log for the specified = direction(s) on=20 the telephony proxy for a particular Subscriber number. =20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for ClearCallLog is:=20 =20 ClearCallLogParameterSet =3D SubscriberNumber=20 Direction=20 =20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 Direction =3D (=93Direction=94 | =93D=94) =93:=94 DirectionString=20 DirectionString =3D (=93Incoming=94 | =93I=94) |(=93Outgoing=94 | = =93O=94) | (=93both=94 | =93b=94)=20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The application or entity generating this message, having built the = message=20 with all the correct information including the TransactionID, should = wait=20 for a General Response message with a matching TransactionID.=20 =20 Message timeout and retry timeout handling are as for the CreateCall = message. =20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message should reply with a GeneralREsponse = message with=20 a ResposneType of =91ok=92 if it is capable of servicing the request = or with a=20 GeneralResponse message with a ResponseType of = =91CannotServiceRequest=92 if it=20 is not.=20 =20 =20 8.3 CallLog=20 =20 Overview=20 --------=20 CallLog is used to send a Call Log to an entity that has requested = one.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for CallLog is:=20 =20 CallLogParameterSet =3D SubscriberNumber=20 * (Direction=20 CallLogReport)=20 =20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 Direction =3D (=93Direction=94 | =93D=94) =93:=94 DirectionString=20 DirectionString =3D (=93Incoming=94 | =93I=94) |(=93Outgoing=94 | = =93O=94) | (=93both=94 | =93b=94)=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = CallLogReport =3D *token| url=20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The application or entity generating this message, having built the = message=20 with all the correct information including the TransactionID, sends = the=20 message and does not expect a response. The Log Report will consist = of a=20 field indicating the direction and then the text for the Call Log = for that=20 direction. The format of the Call Log is left to implementations, = but HTML,=20 XML or standard Text are probably appropriate. If the length of the = callLog=20 is too long for the transport system (for instance if UDP is being = used and=20 the total message length exceed 1500 bytes) it may be more = appropriate to=20 send a URL to the call log, which the receiver can then use to = retrieve it.=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message will receive this in response to a = GetCallLog=20 message. If the message contains a URL for the call log the receiver = should=20 access this URL to retrieve the log.=20 =20 =20 9. Subscriber Service Management Services=20 =20 These messages allow a subscribers service to be set and queried = through the=20 telephony Proxy. The format of the service specific information is = not=20 specified as part of this document (for now).=20 =20 9.1 SetSubscriberService =20 =20 Overview=20 --------=20 This message is used to set a service for a particular telephony = subscriber =20 (directory number). Note that setting the service means set it to = some=20 state, not necessarily just setting it on =96 this message can be = used to set=20 a service off also for example.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for SetSubscriberService is:=20 =20 SetSubscriberServiceParameterSet =3D SubscriberNumber=20 ServiceName=20 ServiceInfo=20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 ServiceName =3D (=93ServiceName=94 | =93svn=94) =93:=94 *token=20 ServiceInfo =3D (=93ServiceInfo=94 | =93svi=94) =93:=94 *token=20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The generator of this message is responsible for setting the Service = name=20 and Service info appropriately, so that the telephony proxy = recognizes it.=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = For now there is no format specified for this information, as many = services=20 are possible with diverse parameter requirements. It is up to the = sender of=20 the message to use a scheme that will be understood by the receiver. = It may=20 be worth in the future allowing a scheme to specify the format of = this=20 information (e.g. by referring to a XML DTD)- this can be left for = further=20 study for now.=20 =20 The generator of the message waits for a General Response message = which will=20 indicate either that the request was successfully serviced or that = there was=20 an error. Message retry and timeout is the same as for Create = Message=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message should service the request if it can and = return=20 a General Response message with the ResponseType set to =91ok=92. If = it cannot=20 service the response (e.g. it does not recognize the service info = format) it=20 should repond with a GeneralResponse with the ResponseType set to=20 =91CannotServiceRequest=92 and optionally a human readable error = message in the=20 ResponseText.=20 =20 =20 9.2 QuerySubscriberService=20 =20 Overview=20 --------=20 This message is used to query the status of a service or a number of = services for a particular telephony subscriber (directory number).=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for QuerySubscriberService is:=20 =20 QuerySubscriberServiceParameterSet =3D SubscriberNumber=20 [ *ServiceName ]=20 =20 =20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 ServiceName =3D (=93ServiceName=94 | =93svn=94) =93:=94 *token=20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The generator of this message generate the message with either the = names of=20 all the services that they want status info on, with no service = names in=20 which case the status of all services will be returned.=20 =20 The generator of the message waits for a SubscriberServiceStatus = message=20 which will indicate either that the request was successfully = serviced or a=20 GeneralResponse message which will indicate that there was an error. = Message=20 retry and timeout is the same as for Create Message=20 =20 =20 Procedures for the receiver of the message=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = ------------------------------------------=20 The receiver of the message should service the request if it can and = return=20 a SubscriberServiceStatus message. If it cannot service the response = (e.g.=20 it does not recognize the service info format) it should respond with = a=20 GeneralResponse with the ResponseType set to = =91CannotServiceRequest=92 and=20 optionally a human readable error message in the ResponseText.=20 =20 =20 9.3 SubscriberServiceStatus=20 =20 Overview=20 --------=20 This message is used to report the status of a service or a set of = services=20 for a particular telephony subscriber (directory number).=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for SubscriberServiceStatus is:=20 =20 SubscriberServiceStatusParameterSet =3D SubscriberNumber=20 *[ServiceName=20 ServiceInfo]=20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 ServiceName =3D (=93ServiceName=94 | =93svn=94) =93:=94 *token=20 ServiceInfo =3D (=93ServiceInfo=94 | =93svi=94) =93:=94 *token=20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 This message is generated in response to a QuerySubscriberService = message.=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message checks the Status and makes it available = to the=20 end user (or another process).=20 =20 =20 10. Voicemail Messages=20 =20 These message allow a user or application interact with a = subscribers=20 voicemail via the telephony Proxy.=20 =20 10.1 VoiceMailBoxQuery=20 =20 Overview=20 --------=20 VoiceMailBoxQuery is used to query the status of the mailbox for a=20 particular subscriber number.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for VoiceMailBoxQuery is:=20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = VoiceMailBoxQueryParameterSet =3D SubscriberNumber=20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 =20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The generator of this message build the complete message including = the=20 TransactionID and sends the message to the telephony proxy.=20 =20 Once the message has been sent a Response is expected and the sender = should=20 wait for this. Message retry and timeout is the same as for Create = Message=20 and the timeout period is left to the implementation.=20 =20 If the request is successful a VoiceMailBoxResponse message will be=20 received. If there is a problem a GeneralResponse message with an=20 appropriate error code will be received.=20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message should determine if it can service the = request=20 and if so it should do so and return a VoiceMailBoxResponse message.=20 =20 If it cannot service the request it should send a GeneralResponse = message=20 with the ResponseType set to =91CannotServiceRequest=92.=20 =20 =20 10.2 VoiceMailBoxResponse=20 =20 Overview=20 --------=20 VoiceMailBoxResponse is used to reply to a VoiceMailBoxQuery = message,=20 providing the status of the mailbox for a particular subscriber = number.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for VoiceMailBoxResponse is:=20 =20 VoiceMailBoxResponseParameterSet =3D SubscriberNumber=20 NumberOfVoiceMails=20 *[VoiceMailRecord]=20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 NumberofVoiceMails =3D (=93NumberOfVoiceMails=94 | =93nv=94) =93:=94 = *Digit=20 VoiceMailRecord =3D VoiceMailID=20 CallingNumber=20 DateAndTime=20 Duration=20 ReadTag=20 [Urgency]=20 =20 VoiceMailID =3D (=93VoiceMailID=94 | =93vmi=94) =93:=94 *token =20 CallingNumber =3D (=93CallingNumber=94 | =93cn=94) =93:=94 *token=20 DateAndTime =3D (=93DateAndTime=94 | =93d=94) =93:=94 Date Time; see = BookConferenceCall=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = Duration =3D (=93Duration =94 | =93du=94) =93:=94 *digit=20 ReadTag =3D (=93ReadTag=94 | =93r=94) =93:=94 (=93y=94 | =93n=94)=20 Urgency =3D (=93Urgency=94 | =93u=94) =93:=94 *token=20 =20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The generator of this message builds this message in response to a=20 VoiceMailQQueryMessage. =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message takes the information in the message and = makes=20 it available to a user or another application.=20 =20 =20 10.3 VoiceMailRequest=20 =20 Overview=20 --------=20 VoiceMailRequest is used to request an action on a particular = voicemail for=20 a given subscriber number.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for VoiceMailRequest is:=20 =20 VoiceMailRequestParameterSet =3D SubscriberNumber=20 VoiceMailID=20 RequestType=20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 VoiceMailID =3D (=93VoiceMailID=94 | =93vmi=94) =93:=94 *token =20 RequestType =3D (=93RequestType=94 | =93r=94) =93:=94 = RetreiveRequestType=20 | =93Delete=94=20 | ForwardRequestType=20 =20 =20 RetreiveRequestType =3D (=93Retrieve in format=94 | =93rf=94) = =93:=94 *token=20 ForwardRequestType =3D (=93Forward to=94 | =93ft=94) =93:=94 *token=20 =20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 The generator of this message must know the specific VoiceMailID = that they=20 want the request to apply to. They then build and send the message = and wait=20 for a VoiceMailResponse message, or a GeneralResponse message. = Timeout is as=20 for the CreateCall message.=20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message looks at the VoiceMailID and the = requesttype and=20 determines if it can service the request. If it can it does so and = replies=20 with a GeneralResponse message with the ResponseType set to =91ok=92, = or if=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = retrieval of a voicemail was requested with a VoiceMail message. If = it=20 cannot it returns a GeneralResponse with the ResponseType set to=20 =91CannotServiceRequest=92.=20 =20 In the case of a =91retreive in format=92 request where the format is = not=20 recognised or not supported, the receiver replies with a = GeneralResponse=20 message with the ResponseType set to =91cannotServiceRequest=92 and = optionally=20 the ResponseText explaining in a human readable form that the = requested=20 format was not recognised or not supported.=20 =20 =20 10.4 VoiceMail=20 =20 Overview=20 --------=20 VoiceMail is used to reply to a VoiceMailRequest with a Voicemail.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for VoiceMailResponse is:=20 =20 VoiceMailResponseParameterSet =3D SubscriberNumber=20 VoiceMailID=20 Format=20 VoiceMail=20 =20 SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 = *token=20 VoiceMailID =3D (=93VoiceMailID=94 | =93vmi=94) =93:=94 *token =20 Format =3D (=93Format=94 | =93f=94) =93:=94 *token=20 VoiceMail =3D (=93VoiceMail=94 | =93v=94) =93:=94 Vmail=20 Vmail =3D *token =20 | absoluteURI=20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 This message is generally sent in response to a VoiceMailRequest = message.=20 The sender of this message (VoiceMail) must ensure that the format = field=20 matches the format of the Voicemail sent. It may be better in many = cases to=20 send a URI for the voicemail than the voicemail itself. If it is = included in=20 the message directly, then the format field tells the receiver how = to=20 interpret the data represented by *token.=20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver of the message looks at the format field and uses it to = present=20 the VoiceMail to a user or another application.=20 =20 =20 11. Misc Messages=20 =20 Messages whose scope is general.=20 =20 11.1 GeneralResponse =20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = Overview=20 --------=20 GeneralResponse is used to respond to a received message when there = is no=20 specific message for the purpose.=20 =20 Message Parameters=20 ------------------=20 The definition of the parameters for GeneralResponse is:=20 =20 GeneralResponseParameterSet =3D ResponseType=20 [Responsetext] =20 =20 ResponseType =3D (=93ResponseType=94 | =93rt=94) =93:=94 =20 ( =93OK=94=20 | =93Error=94=20 | =93UnexpectedMessage=94=20 | =93UnrecognisedMessage=94=20 | =93CannotServiceRequest=94=20 | *token )=20 =20 ResponseText =3D (=93ResponseText=94 | =93rtx=94) =93:=94 *token=20 =20 =20 Procedures for the generator of the message=20 -------------------------------------------=20 This generator builds the message with the TransactioID equal to the = received message and the ResponseType set appropriately. The = optional=20 ResponseText can be used to include an error message that is = understandable=20 by a human user.=20 =20 =20 Procedures for the receiver of the message=20 ------------------------------------------=20 The receiver checks the error code and takes whatever alerting, = maintenance,=20 or recovery action is appropriate. This message does not require a = response.=20 =20 =20 =20 12. Unrecognised or unexpected messages=20 =20 The default behaviour for unexpected or unrecognised received = messages is to=20 simply ignore them.=20 =20 For this reason it is important that all Half Pint messages which = are resent=20 on timeout, stick to the limit of 5 retries before abandoning.=20 =20 An entity supporting Half-Pint can send back a GeneralResponse = message with=20 a ResponseType of UnexpcetedMessage or UnrecognisedMessage if it = wishes.=20 =20 =20 13. Message set transported directly on UDP=20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = While how a Half-Pint message is transported is not specified, and = many=20 different options are available, transport over UDP is both simple = and=20 likely so it is worth mentioning briefly.=20 =20 With UDP the Half-Pint messages can be transported directly on top = of UDP=20 over IP. Each UDP datagram should contain one half-pint message. As = is=20 common practice (for example see SIP spec [2]), datagrams should not = be=20 larger than the path maximum transmission unit (MTU) or 1500 bytes = if the=20 MTU is unknown. However, implementations must be able to handle = messages up=20 to the maximum datagram size for UDP which is 65,535 bytes.=20 =20 =20 14. Versioning and Extending the Half-Pint Protocol=20 =20 All new versions of Half-Pint should be backwardly compatible =96 = i.e. they=20 must support the message format and procedures from previous = versions.=20 =20 Therefore, if a Half-Pint implementation receives a message from a = previous=20 Version it should handle the message as specified in the spec for = the=20 previous version.=20 =20 If a Half-Pint implementation receives a message from a version = newer than=20 itself, it responds with a General Response message indicating which = version=20 it supports. The sender of the message can decide how to react to = this,=20 perhaps by reverting to an earlier version of the message or by = abandoning=20 the request.=20 =20 =20 15. Examples=20 =20 Click to Call service=20 ---------------------=20 A common requirement is to provide a facility for a web user to = click on a=20 button and have a call set up between them and the web site owner = (or some=20 other party). This type of service can easily be realised with the = Half Pint=20 Protocol as follows:=20 =20 1) The user clicks on a button on =91ACME inc=92 website to request = to speak to=20 a company representative.=20 2) The web application generates a CreateCall message with the users = number=20 as the Calling number and the company=92s Call Centre as the Called = number.=20 The users number which is put in the message can either be prompted = for or=20 retrieved from some database about the user.=20 3) The telephony Proxy receives the message and generates the call.=20 4) The Users phone rings and when they answer it the call is placed = to the=20 company=92s Call Centre.=20 5) The Call Centre representative answers and is connected to the = user.=20 Information such as the users account details, if they are a regular = customer, can be made available based on the Calling users CLI. =20 =20 Call Notification Service=20 -------------------------=20 A user working on their computer, or watching their television can = have an=20 alert pop up on the computer or TV screen alerting them about an = incoming=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = call and indicating who is calling. The user may decide to answer = the call,=20 send it to voicemail or forward it to some other number. The flow = for this=20 service is as follows:=20 =20 1) The user registers with the telephony Proxy for the call alerting = service.=20 2) When a call comes in for the user a Call Alert message is sent to = the=20 devices specified in the Call Alerting registration.=20 3) The user decides what action to take and if they decide, for = example, to=20 send the call to voicemail, the user interacts with the computer or = the TV=20 GUI and a CallAlertResponse message is generated and sent back to = the=20 Telephony Proxy.=20 =20 Note that the user will also hear their phone ring (providing they = are in=20 the vicinity of it, of course !) when the call arrives. When some = action is=20 taken such as forwarding to Voicemail, the ringing stops.=20 =20 =20 Conference Call Application=20 ---------------------------=20 A web based conference call controller service might work as = follows:=20 =20 1) The organizer of the conference call enters the details of the = conference=20 call into a web based conference service. They might schedule a = particular=20 conference for the following day at noon. They also may specify = email=20 addresses of the other participants so that they can be notified of = the call=20 by email. The web conference controller application sends a=20 BookConferenceCall message to the telephony proxy with the = appropriate=20 details.=20 2) The next day the telephony proxy creates the conference call (or = takes=20 control of the conference equipment =96 the call itself may not be = created=20 until the first participant dials in depending on the way the = telephony=20 system works) at 11:55 and waits for the host or participants to = dial in. If=20 other participants dial in before the host they will be not be = allowed enter=20 the conference until the host has arrived and will be put on hold = (and=20 likely will be able to listen to either some advertising/branding or = =91Greensleeves=92).=20 3) The host and participants can enter the conference either by = clicking on=20 a URL included in the email notification, which will cause the web=20 conferencing controller application to use the CreateCall message to = add the=20 user to the conference call, or by dialing directly a number = specified in=20 the email. =20 =20 16. Acknowledgements=20 =20 This protocol is a simple extension and formalization of work done = in Nortel=20 Networks by the following people: Dave Armstrong, Steve Perkins, = Laurent=20 Phelep, John Storrie and Bryan Miller.=20 =20 17. References=20 =20 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP = 9, RFC=20 2026, October 1996.=20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = 2 Handley, et al., "RFC 2543 SIP: Session Initiation Protocol March = =20 1999=94=20 =20 3 Crocker & Overell, =93Augmented BNF for Syntax Specifications: = ABNF=94=20 =20 =20 Author=92s Address=20 =20 Mick O=92Doherty =20 Nortel Networks =20 Concorde Road=20 Maidenhead=20 Berkshire=20 SL6 4AG=20 England=20 mdoherty@nortelnetworks.com=20 =20 =20 =20 =20 =20 Appendix A =96 Example HTTP servlets=20 =20 The example code below consists of three classes. It does not fully=20 implement a web server based implementation of Half Pint, but it = gives=20 enough to suggest one example of an architecture that could.=20 =20 The first Class is CreateCall which extends the standard HTTPServlet = class=20 and based on the parameters it retrieves, builds and sends a Half = Pint=20 CreateCall message. If the user has asked for confirmation of the = create=20 call message, a HTML redirect page is sent back to the user to refer = the=20 user to the servlet implemented by the third class below.=20 =20 The second class is a message handler that simply waits on a = particular port=20 (7071 in this case) and stores received half pint messages into a = hash=20 table.=20 =20 The third class is another servlet that is invoked by a redirect = HTML Meta=20 tag from the first servlet. It regularly checks the hash table that = the=20 second class is populating with received half pint messages, for the = message=20 that matches the transaction id of the original Half Pint message = sent by=20 the first class. When it finds the message it removes it from the = hash table=20 and informs the user that the call was created successfully.=20 =20 First Class =96 CreateCall=20 ------------------------=20 =20 import java.io.*;=20 import java.text.*;=20 import java.util.*;=20 import java.net.*;=20 import javax.servlet.*;=20 import javax.servlet.http.*;=20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = /**=20 * CreateCall Servlet=20 *=20 * Instances of this class, like all servlets, wait around for for = their=20 doPost or doGet=20 * methods to be invoked after they have been initialised. doGet = will build=20 and send a=20 * Half-Pint CreateCall message. doPost simply calls doGet.=20 *=20 */=20 =20 public class CreateCall extends HttpServlet {=20 =20 =20 =20 /* init method */=20 =20 public void init() throws ServletException {=20 =20 =20 = getServletContext().setAttribute("HalfPint.incomingMsgHndlrRunning",=20 "No");=20 }=20 =20 =20 /* doGet method - main method of the servlet called by the Servlet = engine=20 or=20 through doPost */=20 =20 public void doGet(HttpServletRequest request,=20 HttpServletResponse response)=20 throws IOException, ServletException=20 {=20 =20 PrintWriter out =3D response.getWriter();=20 response.setContentType("text/html");=20 =20 /* Build the message based on the parameters and the = environment=20 variables.=20 Note - transactioID's should really be created locally */=20 =20 CreateCallMessage ccMessage =3D new CreateCallMessage();=20 =20 ccMessage.halfPintVersion =3D "1.0";=20 ccMessage.addressee =3D request.getParameter("addresse");=20 ccMessage.transactionID =3D = request.getParameter("transactionID");=20 ccMessage.authenticationInfo =3D=20 request.getParameter("authenticationInfo");=20 ccMessage.messageType =3D "CreateCall";=20 ccMessage.callingParty =3D = request.getParameter("callingParty");=20 ccMessage.calledParty =3D request.getParameter("calledParty");=20 ccMessage.completionNotifictaion =3D=20 request.getParameter("completionNotifictaion");=20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = /* Send the message. Note some of the setup could be moved to = init code=20 */=20 =20 byte[] messageBytes =3D (ccMessage.buildMessage()).getBytes();=20 InetAddress telephonyProxyAddress =3D = InetAddress.getByName("X.X.X.X");=20 int telephonyProxyPort =3D 7071;=20 DatagramPacket packet =3D new DatagramPacket(messageBytes,=20 messageBytes.length,=20 telephonyProxyAddress, = telephonyProxyPort);=20 DatagramSocket ds =3D new DatagramSocket();=20 =20 ds.send( packet );=20 ds.close();=20 =20 /* Is confirmation required ? */=20 =20 if (ccMessage.completionNotifictaion.equalsIgnoreCase("yes") |=20 ccMessage.completionNotifictaion.equalsIgnoreCase("y") ) {=20 /* Spawn the message waiting handler first checking to see if = it=20 is already alive */=20 if ( ((String)=20 = getServletContext().getAttribute("HalfPint.incomingMsgHndlrRunning")).eq= uals IgnoreCase("No") ) { // there are better ways to do this=20 =20 = getServletContext().setAttribute("HalfPint.incomingMsgHndlrRunning",=20 "Yes");=20 IncomingHPMsgHandler incomingMsgHndlr =3D new=20 IncomingHPMsgHandler();=20 Thread incomingMsgHndlrThread =3D new=20 Thread(incomingMsgHndlr);=20 incomingMsgHndlrThread.start();=20 }=20 =20 /* Generate the wait page */=20 out.println("Page to wait and check for=20 responses");=20 out.println("");=20 out.println("");=20 out.println("");=20 out.println("If your browser doesn't automatically = refresh=20 within a few seconds");=20 out.println("you may want check =20 href=3D\"http:XXXXXX\"manually every few seconds");=20 out.println("");=20 =20 } else {=20 /* Generate the 'job done' page */=20 out.println(" ");=20 out.println("

Job done - call created

");=20 out.println(" ");=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = }=20 =20 out.close();=20 }=20 =20 =20 /* doPost method - simply calls doGet */=20 =20 public void doPost(HttpServletRequest request,=20 HttpServletResponse response)=20 throws IOException, ServletException=20 {=20 doGet(request, response);=20 }=20 =20 }=20 =20 =20 =20 Second Class =96 IncomingHPMsgHandler=20 -----------------------------------=20 =20 import java.net.*;=20 =20 /**=20 * IncomingHPMsgHndlr=20 *=20 * This Class represents an object which sits around waiting for = incoming=20 Half-Pint messages=20 * and then stores them so others can check them.=20 *=20 */=20 =20 public class IncomingHPMsgHandler implements Runnable {=20 =20 public void run() {=20 =20 /* Get a reference to the shared singleton ReceivedMessages = instance=20 */=20 ReceivedHalfPintMsgs receivedMsgsHashtable =3D=20 ReceivedHalfPintMsgs.getInstance();=20 =20 HalfPintMessage receivedMessage =3D null;=20 DatagramSocket ds =3D null;=20 =20 /* Bind to port */=20 try {=20 ds =3D new DatagramSocket(7071);=20 } catch (Exception e) {=20 System.out.println("error opening socket in=20 IncomingHPMsgHndlr");=20 return;=20 }=20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = /* When an incoming message is received store it */=20 while (true) {=20 DatagramPacket packet =3D new DatagramPacket( new byte = [1024],=20 1024);=20 =20 try {=20 ds.receive(packet);=20 } catch (Exception e) {=20 System.out.println("Exception is" + e);=20 System.out.println("error receiving packet in=20 IncomingHPMsgHndlr");=20 }=20 =20 receivedMessage =3D = HalfPintMessage.createHPMessage(new=20 String(packet.getData()));=20 =20 if (receivedMessage !=3D null) {=20 = receivedMsgsHashtable.addReceivedMsg(receivedMessage);=20 }=20 else=20 System.out.println("received message was null");=20 =20 }=20 }=20 =20 }=20 =20 =20 =20 =20 =20 Third Class =96 CreateCallConfirmationCheck=20 -----------------------------------------=20 =20 import java.io.*;=20 import java.text.*;=20 import java.util.*;=20 import javax.servlet.*;=20 import javax.servlet.http.*;=20 =20 /**=20 * CreateCallConfirmationCheck Servlet=20 *=20 * Instances of this class, like all servlets, wait around for for = their=20 doPost or doGet=20 * methods to be invoked after they have been initialised. doGet = check to=20 see if a confirmation #=20 * has been received for the Create Call message corresponding to = the=20 transaction rceived.=20 *=20 */=20 =20 public class CreateCallConfirmationCheck extends HttpServlet {=20 =20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = /* doGet method - main method of the servlet called by the Servlet = engine=20 or=20 through doPost */=20 =20 public void doGet(HttpServletRequest request,=20 HttpServletResponse response)=20 throws IOException, ServletException=20 {=20 =20 PrintWriter out =3D response.getWriter();=20 response.setContentType("text/html");=20 =20 /* Get a reference to the shared ReceivedMessages instance */=20 ReceivedHalfPintMsgs receivedMsgsHashtable =3D=20 ReceivedHalfPintMsgs.getInstance();=20 =20 /* The message type we are expecting is a = GeneralResponseMessage but=20 use a HalfPint=20 message for now in case the wrong message type was received = */=20 HalfPintMessage confirmMsgReceived;=20 =20 /* Check hashtable to see if the confirmation message has been = received=20 and if it has=20 reply that it has. If not then send a waiting page */=20 =20 String transactionID =3D request.getParameter("transactionID"); = =20 if(transactionID =3D=3D null) {=20 /* Problem - tell the client */=20 out.println(" ");=20 out.println("

Error - no transaction id !!!

");=20 out.println(" ");=20 } else=20 {=20 if ((confirmMsgReceived =3D=20 receivedMsgsHashtable.getReceivedMsg(transactionID)) =3D=3D null) {=20 /* Generate the wait page as the confirmation = has not=20 been received yet */=20 out.println("Page to wait and = check for=20 responses");=20 out.println("");=20 out.println("");=20 out.println("");=20 out.println("If your browser doesn't = automatically=20 refresh within a few seconds");=20 out.println("you may want check =20 href=3D\"http:XXXXXX\"manually every few seconds");=20 out.println("");=20 } else {=20 /* Check that the call was created successfully = */=20 =20 O=92Doherty Page = 1 =0A= =0C Internet Draft Half-Pint July 2001 = =20 = if(!(confirmMsgReceived.messageType.equalsIgnoreCase("GeneralResponse") )) {=20 // UnexpectedMessageHandling;=20 System.out.println("Unexected message = when=20 waiting for a General response to a Create Call");=20 } else {=20 /* Check to see if the received = response is an=20 'OK' */=20 GeneralResponseMessage grm =3D=20 (GeneralResponseMessage) confirmMsgReceived;=20 if = (grm.responseType.equalsIgnoreCase("ok")) {=20 /* Generate the 'job done' page = */=20 out.println(" ");=20 out.println("

Job done - = call=20 created

");=20 out.println(" "); = } else {=20 /* Call was not created - tell = the=20 client */=20 out.println(" ");=20 out.println("

Call not = created=20 !!!

");=20 out.println("

Error code :" = + =20 grm.responseType + "

");=20 out.println(" "); = }=20 }=20 }=20 }=20 =20 out.close();=20 }=20 =20 =20 /* doPost method - simply calls doGet */=20 =20 public void doPost(HttpServletRequest request,=20 HttpServletResponse response)=20 throws IOException, ServletException=20 {=20 doGet(request, response);=20 }=20 =20 }=20 =20 =20 =20 =20 =20 =20 =20 =20 O=92Doherty Page = 1 =0A= =0C ------_=_NextPart_000_01C1105F.901B4B90-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Jul 22 00:06:10 2001 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 SMTP id AAA16989 for ; Sun, 22 Jul 2001 00:06: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 7106544339; Sun, 22 Jul 2001 00:07:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by lists.bell-labs.com (Postfix) with ESMTP id 4800344337 for ; Sun, 22 Jul 2001 00:06:12 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6M45cki023269 for ; Sun, 22 Jul 2001 00:05:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 22 Jul 2001 00:06:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] draft-rs-trip-gw update! Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sun, 22 Jul 2001 00:06:08 -0400 Folks, As you know, our new charter was approved by the IESG, and as such, we have a January '02 deliverable for a protocol between gateways and proxies (aka LS in trip terminology) for "gateway registration". As such, I did a revision of draft-rs-trip-gw, which I submitted on Friday. Until it appears in the archives, you can grab a copy at: http://www.jdrosen.net/papers/draft-rs-trip-gw-02.txt I didn't get to this in time in order to rename in draft-ietf-iptel-*, but that will happen after the meeting. Anyway, we've discussed this document a few times now, and we still get caught up in the issue of whether this problem really is or isn't a trip problem. We need to nail that one immediately (i.e, at this meeting). I want to start an email dialog to facilitate that. To help things along, the document now contains requirements, and then analyzes a few protocols in terms of how they meet the requirements. There are some open issues listed, which we need to debate. Here are some of the more beefy ones: REQ 8: Extensible attributes: The proxy may need to know other information about the gateways - ISUP variant support, codec support, etc., in order to route a call to a gateway. The protocol has to provide a way for this kind of information to be easily added. OPEN ISSUE: Are these attributes characteristic of routes, or of the gateway itself? TRIP defines them as attributes of routes, and this means that they would be copied for each route that gets propagated. For other attributes, like capacity, it could not be copied, and the capacity would have to be divided amongst routes. How would that be done? Points to a potential open hold in TRIP usage for this application. REQ 11: Independent Policies: The protocol should allow two different proxies within the same ITAD to make different decisions on which gateway to use for the same call. This might be desirable for load balancing purposes, for example. OPEN ISSUE: This is an important one to discuss, since it is the main differentiator between a routing protocol and a database protocol. If we don't need different proxies to get different answers about gateway availability depending on which proxy asks, its not a routing problem, and then TRIP may not be the ideal candidate for this usage! I'd like your comments on these, or other, open issues in the document. Lets get things moving again! Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel