Internet Draft Viral Bharatia draft-culpepper-sip-info-event-00.txt Ellis "Skip" Cave April 18, 2000 Bert Culpepper Expires: October 2000 InterVoice-Brite, Inc. SIP INFO Method for Event Reporting Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the use of the SIP INFO Method for communicating mid-call events in SIP [1] sessions. Two new MIME types are described, according to the rules defined in RFC 2046 [2], for use in the INFO message. These media types can be used within a SIP INFO message to request, and report, event detection between SIP network entities. Emphasis is placed on DTMF signaling to communicate user indications when using SIP between a Media Gateway Controller (MGC) and a SIP application. 1. Introduction The SIP INFO method [3] can be used to support interworking between the PSTN and SIP networks. It provides a mechanism to carry application level information along the SIP signaling path. The SIP BCP-T [4] addresses inter MGC (also known as a Softswitch) communication using SIP and describes the use of the SIP INFO method for carrying mid-session signaling messages. In addition, mid-call events, including DTMF signaling, that are detectable by a gateway Culpepper, et. al. [Page 1] Internet Draft SIP INFO Method for Event Reporting April 2000 are necessary for deploying enhanced telephony services in a SIP network. This document describes the use of the SIP INFO method, and two MIME types, for requesting and reporting events along the SIP signaling path. The scenario for PSTN and SIP interworking, where the SIP INFO method for event reporting is useful, is in the use of a third party platform that provides enhanced services. The network scenario is shown below. +-----+ +-----+ +-----+ | MGC |---SIP-T---| ESP |---SIP-T---| MGC | +-----+ +-----+ +-----+ | | MGCP/Megaco MGCP/Megaco | | +------+ +----+ +----+ +------+ | PSTN |---| MG |---------RTP Session---------| MG |---| PSTN | +------+ +----+ +----+ +------+ The migration of telecommunications traffic from circuit-based networks to packet-based networks will require the interaction of "intelligent platforms" with subscriber terminals. The functionality described in this document will allow the migration of enhanced service platforms (ESPs) to the SIP network. Enhanced services can be deployed in network entities other than the MGC, similar to their deployment in the PSTN. One set of events that is required for enhanced services present in the PSTN is the start of DTMF tone and either the end of the DTMF tone or the duration of the DTMF tone. DTMF events are of particular interest due to the large number of IVR-based applications present in the PSTN. Events possible from SIP-enabled terminals such as keystrokes are for further study and not addressed in this document. 2. Existing DTMF Notification Methods One of the uses for the SIP INFO method described in the draft [3] is carrying DTMF digits generated during a session. The SIP BCP-T specifies the use of MIME media types for carrying ISUP and QSIG objects (see [5]) and focuses on call set up and tear down. The methods derived from this draft for DTMF support are limited to a digit string that is collected at the Signaling Gateway (SG). DTMF digits are transported in a Q.931 Keypad Facility information element as user-to-user data in an ISUP USR message. This method requires SIP signaling gateway functionality in the Media Gateway (MG) to provide event detection and notification for all access circuit types (e.g., ISDN, CAS, and analog). Methods have been proposed for carrying telephony events and DTMF in the media stream. These methods solve tone distortion due to various Culpepper, et. al. [Page 2] Internet Draft SIP INFO Method for Event Reporting April 2000 vocoders and address the synchronization of the DTMF tones with the rest of the media. But for many telephony services, exact synchronization is not necessary. The methods also require the SIP application to process the media when it is not necessary otherwise. In addition, packet loss can be a factor when interested in the duration of DTMF tones. Two communications protocols for use between a MG and a MGC do provide support for DTMF digit notification, and notification of other events detectable by the MG. These are the Media Gateway Control Protocol (MGCP) [6] and the Megaco Protocol [7]. However, these protocols limit the deployment of enhanced telecommunications services to the MGC. The event request and notification do not extend past the controlling MGC. It is desirable to deploy enhanced telecommunications services within a SIP entity without requiring it to have direct control of the MGs or to process the media streams. The reliability and order of delivery for DTMF notification by MGCs are addressed in [8]. However, the ability of a SIP entity or application to request that digit accumulation be performed by the MG is not addressed. Nor is the ability to provide a digit mask addressed. A general method, using the SIP INFO Method, for transporting DTMF digits between two SIP entities and for specifying digit collection to be performed by a SIP client is described in [9]. This method provides a SIP entity with significant control over digit collection and detail concerning the results of the collection. The method is very useful in a SIP network but requires capabilities outside of the MG-to-MGC protocols mentioned above. Through support of the application of the SIP INFO Method as described in this document by the MGC, event requests and notification can take place between a MGC and a SIP network entity. Specifically, a SIP entity can request that the MGC enable detection of MG supported events and that the MGC pass on event notification from the MG to the requesting SIP entity. The use of a Digit Map in the event request addresses DTMF accumulation and order of delivery issues. The use of the SIP INFO Method for DTMF tone reporting also eliminates the issues associated with packet loss in the media stream. SIP messages can be re-transmitted if not acknowledged by the receiving entity. 3. DTMF Timing Issues Duration of DTMF tones is important to enhanced services, as is the length of time a subscriber is allowed to provide information to the service. MGCP and Megaco both provide support for tone duration and Culpepper, et. al. [Page 3] Internet Draft SIP INFO Method for Event Reporting April 2000 timers. Support is limited somewhat but what is provided is sufficient for existing services. MGCP defines a Long Duration Indicator and an Interdigit Timer. The Long Duration Indicator's value is 2 seconds for the DTMF Package. That is, keys that are pressed and held for more than 2 seconds can be reported. Event notification will occur when the digit is detected (the DTMF digit) and a second notification (the Long Duration Indicator) will occur 2 seconds later. The Interdigit Timer, defined as 4 seconds, can be used with or without a Digit Map. Its function differs when used by itself and with a Digit Map. The two behaviors are T(partial) and T(critical). The default values are 16 seconds and 4 seconds respectively, although their values depend on specific provisioning within the gateway. The use of these timers does provide functionality required by enhanced services. Specifically, control over the time a user is given to enter digits, and indication of a timeout when waiting for user responses. Megaco supports the use of a Long Duration indicator and three timers when collecting digits at the gateway. A duration modifier and a Start timer, Short timer, and Long timer can be used with a DigitMap. The duration modifier is used to detect digits of duration longer than the long-duration threshold. The value of the long-duration threshold is provisioned in the gateway. The actual tone duration of a long duration event will not be known, only that the tone's duration exceeded the threshold provisioned in the gateway. The three timers are configurable parameters and allow greater flexibility than MGCP when waiting for digits. 4. INFO Method SIP INFO messages can be used to specify the events to be reported by the MGC. Depending on the protocol used between the MGC and MG, the content of the INFO message can be the command parameter used by the MGC to specify the events to be detected and reported by the MG. For MGCP, the INFO message content would be the RequestedEvents parameter used in a NotificationRequest command. For Megaco, the INFO message content would be the EventsDescriptor used in an Add or Modify command. SIP INFO messages can also be used by the MGC to report events detected by the MG. Again, depending on the protocol used between the MGC and MG, the content of the INFO message can be the command parameter used by the MG to report observed events. For MGCP, the content of the INFO message would be the ObservedEvents parameter present in the Notify command. For Megaco, the INFO message content would be the ObservedEventsDescriptor transmitted in the Notify command. For both MGCP and Megaco, the event request can be global in scope (i.e., for all calls processed by the MG) or on a per call basis. An Culpepper, et. al. [Page 4] Internet Draft SIP INFO Method for Event Reporting April 2000 MG event request that is global in scope is considered unusual for a SIP entity and not addressed in this document. 4.1 Processing Rules The processing of INFO messages with message bodies as described in this draft should follow those defined in "The SIP INFO Method" [3]. If a SIP UA receives an INFO request with a message body that it does not understand, it is to respond with a 415 Unsupported Media Type message. Specifically, if a MGC receives an event request that it does not understand or a MGC to MG protocol that it does not support, the MGC can respond to the requesting SIP UA with a 415 Unsupported Media Type message. The INFO Method ([3]) draft does not specifically mention the behavior for User Agent Clients that receive INFO requests. The use of the INFO Method described in this draft requires that UACs process INFO messages in the same manner as UASs. The primary purpose for the use of the INFO Method described herein is to allow a services platform to request event notification on calls placed to it. 5. Proposed Media Types Two media types are defined for MGCP and Megaco event requests and notifications by the following information: Media type name: application Media subtype name: mgcp-event/megaco-event Required parameters: none Optional parameters: version Encoding scheme: text The media subtype is used to indicate the MGC to MG protocol, either mgcp-event or megaco-event. The 'version' parameter is used to specify the specific protocol's version. These parameters allow the receiving entity to recognize and parse the message correctly. If not specified, the default version is assumed to be 1.0 for MGCP and 1.0 for Megaco. Encoding the event request and notification in text format is specified in this document due to the support for text encoding of message parameters by both MGCP and Megaco. A typical header would look like the following: Content-Type: application/mgcp-event; version=1.0 Content-Transfer-Encoding: text 5.1 MGCP Event Request Culpepper, et. al. [Page 5] Internet Draft SIP INFO Method for Event Reporting April 2000 The MGCP event request payload is the RequestedEvents and optional DigitMap parameters defined for MGCP. The request can be any combination of events and actions as specified for the RequestedEvents parameter. 5.2 MGCP Event Notification The ObservedEvents parameter present in the MGCP Notify command is the payload for the event notification. The notification can be any event as specified for the ObservedEvent parameter. 5.3 Megaco Event Request The Megaco event request payload is the EventsDescriptor and optional DigitMapDescriptor parameters defined for Megaco. The request can be any combination of events and actions as specified for the EventsDescriptor parameter. 5.4 Megaco Event Notification The payload for the Megaco event notification is the ObservedEventsDescriptor transmitted in the Notify command by the MG to the MGC. 6. Examples The message body of a SIP INFO message used to request that DTMF digits be detected and reported follows. The event notification from the MG will occur as each DTMF digit is detected. In this example the MGCP protocol is used for the MGC to MG communications. Content-Type: application/mgcp-event; version=1.0 Content-Transfer-Encoding: text R: D/[0-9*#A-D](N) The message body of a SIP INFO message used to request that ten DTMF digits be accumulated and reported follows, only the digits 0 through 9 are processed. The event notification from the MG will occur after ten digits have been detected or upon timeout. In this example the MGCP protocol is used for the MGC to MG communications. Content-Type: application/mgcp-event; version=1.0 Content-Transfer-Encoding: text R: D/[0-9T](D) D: (XXXXXXXXXX) The next example is a request for collecting 4 digits using the Megago protocol. The event detection requested is from the DTMF Detection package. The event notification will occur after 4 digits Culpepper, et. al. [Page 6] Internet Draft SIP INFO Method for Event Reporting April 2000 have been detected or upon timeout. The user is given 5 seconds to start entering digits and 5 seconds to enter the next digit. Content-Type: application/megaco-event; version=1.0 Content-Transfer-Encoding: text E=445632[dd[DM=4digitPIN]] DM=4digitPIN [T:05, S:05, L:16, ([0-9]S[0-9]S[0-9]S[0-9])] The message body of a SIP INFO message used to indicate a user has pressed the "#" key and held it for longer than 2 seconds follows. The MGCP protocol is used for the inter MGC to MG communications. Content-Type: application/mgcp-event; version=1.0 Content-Transfer-Encoding: text O: D/#, D/L The message body containing a MGCP RequestedEvents parameter asking the MG to report a hook flash upon detection follows. Content-Type: application/mgcp-event; version=1.0 Content-Transfer-Encoding: text R: L/[hf](N) 7. Practical Considerations Support of event notification as described in this draft requires some additional protocol support in the MGC and in the SIP UA. Considerations for both the MGC and SIP UA are described below. 7.1 Required MGC Functionality Support of the message bodies described in this draft requires MGC functionality as follows. When an INFO request is received at the MGC, the MGC is expected to perform the conversion of the call identifying parameters in the SIP INFO message header to the corresponding parameters in the MGC to MG protocol. The MGC can use the same method it uses to correlate a SIP BYE request to a MGCP DeleteConnection command or a Megaco Subtract command. The MGC is expected to format event detection requests into the appropriate command for the protocol and MG, then send the command to the MG. The MGC is also expected to encode and transmit event notifications received from a MG to the requesting SIP UA. This requires the MGC to maintain additional state information for the call upon receiving an INFO event request so that event notifications received from the MG are reported to the SIP UA. Culpepper, et. al. [Page 7] Internet Draft SIP INFO Method for Event Reporting April 2000 Many MGC (Softswitch) manufacturers provide a third-party application development environment in which the functionality described in the previous two paragraphs can be implemented. MGCP defines Endpoints (e.g., DS0, analog line, etc.) and their Connections to the packet network. MGCP also states that for some Endpoints, MGs should support several Connections between the Endpoint and the packet network and that one or more Connections can belong to a call. The ability of the MG to support multiple Connections (RTP sessions) per Endpoint is not a consideration for the event detection and reporting capabilities described in this draft. The event detection and reporting of interest is specific to the Endpoint and not its Connections. The use of a Package designator in the event request also helps reduce any ambiguity in which media source event detection and reporting is desired for. Megaco defines Contexts and Terminations (RTP Stream, SCN Bearer Channel, etc.). Contexts can contain multiple Terminations but a Termination can only belong to one Context. A typical "call" handled by a MG will involve a single Termination toward the PSTN (although it can involve multiple Terminations toward the PSTN). This connection model can present a challenge to SIP entities requesting event detection and notification. A call's TerminationID is not known beyond the controlling MGC. However, Terminations have associated Packages and event requests contain the Package ID. An MGC can use the Package specified in the EventDescriptor and RTP session information associated with the SIP Call-ID to determine the Terminations for which to request event notification by the MG. The Terminations of interest are those that support the specified Package (e. g., Tone Detection, DTMF Detection, Call Progress Tones Detection). 7.2 SIP User Agent Functionality SIP User Agents will necessarily have to know how to format and parse MGCP and Megaco event requests and notifications. They also need to determine which if any MGC-to-MG protocol is supported by the end point (MGC) with which it is interacting. It is envisioned that ESPs will be deployed in conjunction with "well known" MGCs. In this case, the MGC-to-MG protocol can be provisioned in the ESP along with other MGC-related criteria. The response to an event notification request will also indicate the receiving SIP UA's support of the indicated MGC-to-MG protocol. A discovery process can be defined by which one SIP UA can determine another SIP UA's support of the use of the INFO Method for event reporting and its supported MGC-to-MG protocol. The definition of a discovery process is outside the scope of this document. Culpepper, et. al. [Page 8] Internet Draft SIP INFO Method for Event Reporting April 2000 8. Security Considerations DTMF media types may have security considerations due to customer- related information contained in the media types. However, the security mechanisms described in RFC 2543 (SIP - Session Initiation Protocol) are sufficient to support security of the encapsulated DTMF digit information. End-to-end encryption can be used on message bodies that contain DTMF digits. No new security considerations are thought necessary. 9. Authors Viral Bharatia InterVoice-Brite, Inc. 17811 Waterview Parkway Dallas, TX 75252 Phone: 972-454-8208 Email: vbharati@intervoice.com Ellis "Skip" Cave InterVoice-Brite, Inc. 17811 Waterview Parkway Dallas, TX 75252 Phone: 972-454-8800 Email: skip@intervoice.com Bert Culpepper InterVoice-Brite, Inc. 701 International Parkway Heathrow, FL 32746 Phone: 407-357-1536 Email: bert.culpepper@intervoice-brite.com 10. References [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, IETF, March 1999. [2] N. Freed, N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part Two: Media Types" RFC 2046, IETF, November 1996. [3] S. Donovan, "The SIP INFO Method", IETF, March 2000, Work in progress. [4] E. Zimmerer, A. Vemuri, V. Nadkarni, B. Morgan, S. Mayer, G. Camarillo, "SIP Best Current Practice for Telephony Interworking", IETF, October 1999, Work in progress. [5] E. Zimmerer, A. Vemuri, L. Ong, M. Zonoun, M. Watson, "MIME media types for ISUP and QSIG Objects", IETF, January 2000, Work in progress. Culpepper, et. al. [Page 9] Internet Draft SIP INFO Method for Event Reporting April 2000 [6] M. Arango, A. Dugan, I. Elliot, C. Huitema, S. Picket "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, IETF, October 1999. [7] F. Cuervo, B. Hill, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers, "Megaco Protocol", IETF, February 2000, Work in progress. [8] J. Kuthan, "Sample Uses of SIP INFO with Varying Reliability Needs", IETF October 1999, Work in progress. [9] T. Choudhuri, C. Haun, P. Sollee, S. Orton, S. Whynot, "SIP INFO Method for DTMF Digit Transport and Collection", IETF, April 2000, Work in progress. Culpepper, et. al. [Page 10]