Subject: Re: Detecting DTMF tones on a SIP voice session

From: "Gregory D. Girard" <[email-masked]>
Date: Thu, 28 Oct 1999 22:25:32 -0400

Thanks so much for the information. In my opinion, it important that one way
or the other makes its way into the new SIP standard as required elements.
Lucent, in particular, has absolutely no intention of doing anything to
allow third party call control of their Softswith. The reason is a separate
discussion that we can have some time. They do, however, tout a SIP
signaling interface. If SIP requires support for this feature, the Lucent
Softswitch will provide de facto support for third-party call control and
the critical DTMF functionality discussed. To allow the feature to remain a
simple SIP enhancement would not accomplish the goal of having SIP serve as
the universal IP Telephony call control and signaling interface that it
potentially could be.

Option 1 below is less desireable than option 2 for two reasons:

1- Requires one or more RTP streams even though application may only require
DTMF digit sequence to provide a service
2- Requires that digit sequences come in a serial fashion and may return too
much useless information.

In contrast, the INFO solution would allow the media gateway internal
functionality (as defined for MGCP) to match the digit map prior to
returning anything at all.

Just few thoughts. I'm glad to know that this was an area of recent
consideration and I was not just missing it.
Thanks,

Greg Girard

-----Original Message-----
From: Henning Schulzrinne <[email-masked]>
To: Gregory D. Girard <[email-masked]>
Cc: SIP List <[email-masked]>
Date: Thursday, October 28, 1999 10:07 PM
Subject: Re: Detecting DTMF tones on a SIP voice session

>Cc list trimmed, since everybody is presumably a list member. There are
>two short answers to the issue you raised:
>
>1) See the RTP proposal for carrying DTMF and other tones. It's listed
>on the AVT WG web page. This is the preferred mechanism as long as audio
>and DTMF are going the same way, as it has a low-latency redundancy
>mechanism and can readily be synchronized with the audio stream. It is
>also quite feasible to set up a SIP connection that transfers only DTMF
>using this mechanism. This proposal has undergone working group last
>call and will be submitted for IETF last call shortly.
>
>2) The use of the INFO method to carry DTMF within SIP has been
>discussed. This would, in spirit, be very similar to carrying ISUP
>information across the network, just that it is in-band signaling that
>is effectively replicated out-of-band. The definition is trivial:
>
>INFO ... SIP/2.0
>To: anywhere
>From: somewhere
>Content-type: application/dtmf
>
>*1
>
>or something like that.
>
>"Gregory D. Girard" wrote:
>>
>> To the extent that I am not a "SIP insider" and have not been deeply
>> involved in the evolution of SIP, I'm not exactly sure how to bring up a
new
>> subject in this forum. I am in the process of determining how to achieve
>> third-party call control through a Softswitch using SIP as the call
>> control/signaling interface. I am very familiar with the Lucent
Softswitch
>> model and believe that other Softswitch call control interfaces are
>> possible. To that end, I really need to find something out directly
related
>> to SIP functionality.
>>
>> In considering SIP as a call control interface to a Softswitch, it
becomes
>> very challenging to navigate an Interactive Voice Response session
without
>> the ability to collect DTMF input from the caller. Perhaps I missed
>> something, but I am unaware of any SIP capacity to transmit DTMF digit
>> information for a voice connection. I found no SIP messages relating to
the
>> feature, presumably because it requires an underlying DSP capability to
>> detect the DTMF digits. SIP implemenations appear not to have focussed on
>> this area.
>>
>> If I have overlooked some existing SIP functionality, please accept my
>> humble apologies and direct me to the righ place.
>>
>> On the other hand, if the "SIP community" has overlooked DTMF digit
>> collection/detection as a critical adunct necessary to make SIP work in a
>> real call control application, the read on.
>>
>> *** Would it be possible to extend SIP messages to enable a DTMF digit
map
>> to be specified for a specific SIP voice session ?
>>
>> This functionality may not make sense in all cases, however in the case
>> where a User Access Client and/or User Access Server is incorporated into
a
>> Softswitch, it would be very desirable for the Softswitch to be able to
>> collect DTMF digits for a voice session (according to a digit map) and
>> subsequently insert the results into the SIP message stream.
>>
>> Certainly one could argue that this feature is hardware-dependent in
terms
>> of DSP capabilities, voilates the purity of the SIP signaling model, and
>> belongs to an MGCP interface, but that would be missing the point. In
>> creating a connection to a Softswitch, the media gateways are completely
>> encapsulated by layers of Softswitch software. The MGCP client-server
pairs
>> used by the Softswitch to control one or more media gateways are not
>> externally addressible outside of the domain of the Softswitch because
the
>> Softswitch is fully responsible for managing the media gateways as its
own
>> internal "switching resource".
>>
>> An IVR application external to the softswitch cannot simply wrest control
of
>> a media gateway to create a connection for its own purposes.
Unfortunately,
>> the ability to present digit maps for DTMF collection on a given
connection
>> appears to only be available through the inaccessbile MCGP protocol
>> elements. Thus, my proposal is to extend that MGCP feature into SIP.
>>
>> Greg Girard
>>
>> Iperia, Inc.
>>
>> -----Original Message-----
>> From: Henning Schulzrinne <[email-masked]>
>> To: Jonathan Rosenberg <[email-masked]>
>> Cc: Rick Workman <[email-masked]>; Alan Johnston
>> <[email-masked]>; SIP List <[email-masked]>
>> Date: Thursday, October 28, 1999 8:03 PM
>> Subject: Re: I-D Action: SIP Call Flows and Service Examples
>>
>> >Jonathan Rosenberg wrote:
>> >>
>> >
>> >> Need it translate the tel URL before sending it to a local proxy? I
>> >> guess you can argue this either way. In one sense, changing it to
>> >> sip:[email-masked] is right since I am talking to the proxy at
>> >> mydomain.com; effectively I'm trying to reach this number through this
>> >> domain. On the other hand, the resource I am still trying to reach is
a
>> >> phone number, and the outbound domain is not really the namespace in
>> >> which this number is defined.
>> >
>> >I suppose it is up to the proxy to either accept or reject non-SIP URIs.
>> >I would guess that most current servers would not take too kindly to a
>> >tel: URI. (I just fixed our sipd server to allow this, to see how
>> >difficult this change might be. Two lines of code, as it turns out.)
>> >
>> >In general, a server should probably allow non-SIP request URIs (as well
>> >as in the To header of the REGISTER).
>> >
>> >This should probably be made explicit. The HTTP spec only seems to imply
>> >that something like
>> >
>> >GET sip:user@host HTTP/1.1
>> >
>> >would be illegal. (Having a real URI in the request line, like 'GET
>> >http://www.ieee.org HTTP/1.1' is fine, albeit not common except when
>> >addressing proxies.)
>> >
>> >
>> >> > If it's tel:#, it needs to be translated to sip:#@domain, at which
>> point
>> >> > the # is just an identifier. Why would you need a further
>> >> > identification? In particular, this is not fixed: in the future, the
>> >> > same # can well refer to a legacy "black" phone at night (at home)
and
>> >> > an IP phone during the day (at work).
>> >>
>> >> I was thinking along the lines of how enum gets integrated into the
SIP
>> >> architecture. We start with a phone number, and this number really is
a
>> >> "name"; using enum, we can translate it to a sip URL, mailto URL, and
so
>> >> on. In many cases, this number is a name for a terminal on the PSTN
with
>> >> the same number. In other words, the tel URL is just a normal POTS
line,
>> >> and this number has no entry in the enum database. Say some IP phone
>> >> makes a call to tel:1234567. The first outbound proxy uses enum, and
>> >> finds that this number is not in the database. So, it forwards it to
the
>> >> next hop proxy, using a tel URL in the request URI. This proxy doesn't
>> >> need to look it up in enum once more, as its been done. A similar
issue
>> >
>> >However, somewhere along the way, this has to be translated to a
>> >gateway. Why would this not be done at the same time?
>> >
>> >The first proxy has to forward this request *somewhere* on the Internet,
>> >so why not translate this into
>> >
>> >sip:#@somewhere;user=phone
>> >
>> >No information is lost. The next hop will then decide whether this is
>> >indeed a real phone, with a gateway to be contacted, or this actually
>> >isn't, due to some other remapping.
>> >
>> >> arises if the first number did exist in enum, but was mapped to
another
>> >> number (tel:1234567 -> tel:2125551213). This is basically LNP. The
next
>> >> hop proxy doesn't need to look up tel:2125551213 in enum.
>> >
>> >This depends on whether enum is a global database or whether certain
>> >translations are done locally. For example, you could have a global
>> >translation to a current carrier number ("LNP"), but only the current
>> >carrier keeps track of whether this number is currently on 24 ga twisted
>> >pair and 48 Volts or gets IPtone. Thus, it may have to do a second
>> >look-up anyway.
>> >
>> >>
>> >> I think what you are proposing is that translation to the SIP URL
>> >> basically implies that the lookup has been done. That works, but I
think
>> >> it might be combining two things together that are really different.
Not
>> >> sure...
>> >
>> >I'm just not sure that a single-lookup-model even works within the tel:
>> >context. Why have a proxy if it doesn't do a lookup - that's it's
>> >primary justification, after all...
>> >--
>> >Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>> >
>
>--
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 28 Oct 1999 22:41:48 -0400

> the universal IP Telephony call control and signaling interface that it

I'm not sure what it could be beyond a "simple SIP enhancement". IETF
doesn't do profiles listing features and extensions that products need
to support; the SoftSwitch consortium is certainly free to do this.

> DTMF digit sequence to provide a service

Why is this a problem?

> much useless information.

I'm not sure what "useless" information you are referring to. I'm afraid
I also don't know what you mean by "serial fashion". Both SIP and RTP
use UDP.

In my view, carrying DTMF in INFO messages makes sense primarily if the
(DTMF) signaling path is very different from the media path or if the
information needs to be visible to SIP proxies in the middle.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Oct 1999 00:22:28 -0400

> the universal IP Telephony call control and signaling interface that it

SIP does not, can not, and should not specify RTP payload formats and
codecs. DTMF is an example of such a codec. If your system wants to use
it, go ahead. SIP/SDP allows such information to be signaled.

> DTMF digit sequence to provide a service

I too don't understand this.

> returning anything at all.

Not true. I interpret your concern 2 as follows: "I don't want to send
each digit one at a time to the IVR system; I'd rather have some
internal logic based on digit maps that sends them in groups". If this
is the case, it can be done with either RTP or the INFO method. With
RTP, you would delay sending the packets containing DTMF until you had
matched the digit map, and then send them in a clump together. This
would allow you to use long durations for each digit (not too long, for
reliability purposes), making it more efficient.

An advantage of the RTP approach is that you don't restrict the user
interaction to DTMF. Many IVR systems these days allow both tone and
voice recognition - "say or press 1 to speak to a representative". Now,
if you ship DTMF over INFO, you will absolutely not be able to do this.
However, using DTMF RTP, which I believe to be the superior solution,
allows such applications to exist.

Whenever the device which needs to use DTMF for features is acting as a
UA, there is almost never a reason to use SIP to transport DTMF. RTP
works best in this case, and IVR falls into this category.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 210 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 29 Oct 1999 00:21:49 -0500

I posted a new I-D which also addresses the problem of the DTMF transport.
In particular, use of the SIP INFO method is suggested for applications with
a strong need for reliable in-order delivery. A phone-banking IVR is shown
as an example of this application class in the I-D  -- a loss or out-of-order
delivery of a single DTMF digit could  result in an undpredictable financial
transaction. MGCP/Megaco is suggested as the MIME encoding to make
passing the events across MGCP/Megaco and SIP as easy as possible.

I believe that if privacy is needed (e.g. for communicating sensitive banking
information)
SIP security will find a wide acceptance faster than RTP security. This is
another reason why to deploy the SIP INFO approach.

In general, the I-D is thought to be a catalog of uses of the SIP INFO mechanism

with an attached discussion of their reliability. Comments are appreciated.

Until the I-D appears find it enclosed in this E-mail's attachement.

Jiri

[...]

> DTMF digit sequence to provide a service

An additional RTP stream is required only in the particular case when there is
nothing else to be sent.
Otherwise, multiple payloads (e.g. DTMF along with G.729) will be carried in a
single RTP
stream. However, I do not think that having the DTMF/RTP stream in the former
case hurts.

--
Jiri Kuthan, MCI WorldCom, E-mail [email-masked], VNET 777-6536, phone
972-729-6536

Internet Engineering Task Force                              Jiri Kuthan
Internet Draft                                              MCI WorldCom
draft-kuthan-sip-infopayload-00.txt
October 17, 1999
Expires: April 2000

         Sample Uses of SIP INFO with Varying Reliability Needs

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 memo describes SIP applications that have a need for mid-
   session signaling and use the SIP INFO method for this purpose. In
   particular, attention is paid to the applications’ needs for
   reliable in-order delivery and mechanisms to accomplish it.

1 Introduction

   Session Initiation Protocol [1] is used to establish and terminate
   multimedia sessions in a transaction oriented manner. However, there
   are still applications with a need for mid-session signaling. This
   need is addressed by the SIP INFO [2] method, which establishes a
   mechanism for exchanging signaling information during an existing
   session.  The application specific data are encoded as MIME type [3]
   elements in the INFO requests. This Internet Draft describes
   applications, which may make use of the SIP INFO mechanism and
   suggests payload MIME types for them. This document also describes
   how the individual applications may handle packet loss and delay.

2 Sample Uses

   This section shows applications that may make use of the INFO
   method, suggests MIME types to be used by them  and discusses their
   reliability needs.

Kuthan                                                        [Page 1]

Internet Draft           SIP INFO Sample Uses             October 1999

2.1 DTMF Applications

   Transport of DTMF signaling is of great importance since there is a
   large existing base of DTMF applications. Transport over RTP has
   been proposed in [4]. Its reliability mechanism is based on
   redundancy. This may be critical for applications with a strong need
   for reliability especially if bursty loss occurs. Consider a phone
   banking application for example. After a user is asked by an IVR to
   enter an amount to be transferred she types the digits
   consecutively. If the IVR does not receive one of the DTMF digits or
   the digit order changes due to out-of-order delivery, the
   transaction may result in an unpredictable money transfer. Thus, a
   reliable transport channel is desired. Using SIP INFO method with
   underlying SIP reliability and ensuring in-order delivery (see the
   next section) makes DTMF signaling resilient to unreliable packet
   delivery even under bursty loss.

2.1.1 MIME Types

   Registering MGCP [5] or Megaco packages [6] as MIME types and using
   them for transport of DTMF tones (among others) features a text
   format which may be easily processed by gateway controllers. Using
   the binary format described in [4] is also possible but requires the
   gateway controllers to support it in addition to its native format.
   The text format will also make coupling with applications running on
   text-oriented operating systems easier.

2.1.2 Request Example

   In this example scenario a user is sending DTMF tones indicating an
   amount after having been prompted for by a phone banking IVR. The
   numbers are sent as a block in this case but they could also be sent
   individually. The number sequence "8726" is terminated by a pound
   tone lasting 2 seconds. MGCP encoding is used.
______________________________________________
   INFO sip:[email-masked] SIP/2.0
   Via: SIP/2.0/UDP kton.bell-tel.com
   From: A. Bell <sip:[email-masked]>
   To: National Banana Bank <sip:[email-masked]>
   Call-ID: [email-masked]
   CSeq: 2 INFO
   Subject: Money Transfer By Wire
   Content-Type: application/mgcp
   Content-Length: 75

   NTFY 123456 [email-masked] MGCP  1.0
   O: D/8, D/7, D/2, D/6, D/#, D/L
   _____________________________________________
2.2 Human-readable Text Applications

   In many cases it may be useful to supply a session party with
   additional textual information that relates to the current session.
   These may include charging information (e.g. "available minutes"
   announcement,  "last minute" warning, advice of charge, OSP [7]

Kuthan                                                        [Page 2]

Internet Draft           SIP INFO Sample Uses             October 1999

   messages), IVR messages in text for deaf users, user short messages
   (e.g. "check our web-page while being transferred", advertising),
   etc.

2.2.1 MIME Types

   Text/* (e.g. Text/Plain, Text/Html, etc.)

2.2.2 Request Example

   This example illustrates the use of SIP INFO for transporting
   textual charging information. A charged party is being informed that
   its call credit will expire soon.
   ______________________________________________
   INFO sip:[email-masked] SIP/2.0
   Via: SIP/2.0/UDP kton.bell-tel.com
   From: A. Bell <sip:[email-masked]>
   To: National Banana Bank <sip:[email-masked]>
   Call-ID: [email-masked]
   CSeq: 2 INFO
   Subject: Money Transfer By Wire
   Content-Type: text/plain
   Content-Length: 31

   Your credit is about to expire.
   _____________________________________________
2.3 Transported GSTN Signaling

   If a GSTN call is routed over a SIP network its native mid-session
   signaling may need to be transported in an INFO request. For
   example, an ISDN Info packet carrying Advice of Charge may be
   encapsulated in a SIP INFO request.

2.3.1 MIME Type

   See [8] for a definition of application/ISUP MIME type

2.4 Multipart Messages

   In some cases it may be useful to send multiple MIME messages in a
   single payload. For example, advice of charge may be sent in plain
   text as well as in HTML and its native GSTN format. Multipart MIME
   messages will be used for this purpose.

2.4.1 MIME Type

   Multipart

3 Out-of-order (O-o-O) Delivery

   Applications that use the SIP INFO method to perform mid-session
   signaling may suffer from packet loss and out-of-order delivery if
   an unreliable transport protocol like UDP is used. Currently, SIP
   handles packet loss by retransmission but does not address out-of-

Kuthan                                                        [Page 3]

Internet Draft           SIP INFO Sample Uses             October 1999

   order delivery since the current SIP message set is idempotent. An
   idempotent message arriving out-of-order may be processed
   immediately regardless of delay or even loss of preceding messages.
   If the preceding messages do arrive later they can be discarded.
   This is different with the INFO requests since applications using
   this method may require in-order delivery of a complete request
   sequence. The case is illustrated in the aforementioned phone-
   banking example where the out-of-order delivery of signaling
   information may result in a transfer of an incorrect amount.
   Mechanisms addressing this issue are discussed in the following
   text. Which of the mechanisms will be used depends on the
   applications since they may have different reliability requirements.

3.1  The Trivial Case: No O-o-O Delivery Handling

   Applications that do not need in-order delivery or use the INFO
   method to transport idempotent payload need no additional treatment.
   An example is notifying a caller of current total call charges. Such
   a notification is idempotent and the message with the highest
   sequence number completely overrides the meaning of all previous
   messages, regardless if they were received or not.

3.2  Buffering

   If the messages encapsulated in the INFO requests are not idempotent
   and in-order delivery is required, buffering may be used. A
   requirement is put on the receiver’s SIP API to delay processing of
   out-of-order INFO requests with the same content type until all
   preceding requests arrive. Processing of any other requests remains
   unaffected. The following example illustrates step-by-step what
   happens if some messages get lost:

   1) A receiver instructs its SIP API to delay processing of out-of-
      order INFO requests of a given content type.
   2) A sender sends a re-invitation R1 and two INFO messages I1 and I2
      of the given content type.
   3) R1 and I1 get lost but I2 reaches the receiver. The receiver
      replies and buffers the I2 and awaits preceding packets.
   4) A timeout expires at the sender and it resends R1.
   5) The receiver processes R1. I2 is still buffered.
   6) A timeout expires at the sender and it resends I1.
   7) The receiver receives I1 and starts processing it. When finished,
      it starts processing I2.

   Note that the retransmission delay may be slightly reduced if the
   sender retransmits after having received an out-of-order reply.

3.3  Re-sending Transmission Window (RTW)

   With buffering out-of-order packets (see above) a receiver may
   experience a higher delay if retransmission occurs. If a continuous
   stream of INFO messages is sent the retransmission penalty may be
   reduced be sending the content of all unacknowledged INFO requests
   (i.e. the transmission window) along with each INFO request. To

Kuthan                                                        [Page 4]

Internet Draft           SIP INFO Sample Uses             October 1999

   enable the receiver to interpret such INFO messages the payloads
   must include a sequence number indicating the position of the
   transmission window in the message stream. This mechanism is
   illustrated in the following DTMF/MGCP example:

   1) The sender sends the first digit (8). The application-specific
      sequence number is set to zero initially. INFO payload looks like
      this:

   NTFY 0 [email-masked] MGCP  1.0
   O: D/8

   2) The first packet gets lost.
   3) The sender generates next digit (7). Because the first digit has
      not been replied it sends a concatenation of the first digit and
      the second one. Note that the MGCP sequence number does not
      change because it indicates the position of the first digit in
      packet.

   NTFY 0 [email-masked] MGCP  1.0
   O: D/8, D/7

   3) The receiver gets the second packet and sends a reply.

   4) The sender receives the reply and generates a new digit (2)
   again. The MGCP sequence number is increased to two to indicate the
   position of the transmitted digit in the digit stream.

   NTFY 2 [email-masked] MGCP  1.0
   O: D/2

   Note that the message size grows with the number of "messages in
   pipe". Thus, this mechanism is useful for applications that generate
   rather short payloads so that the recommended size of SIP messages
   [1, Section 3] will not be exceeded.

3.4  Applying the Right Mechanism

   Which of the proposed mechanisms is used depends on the
   applications. They may even use a completely different mechanism for
   reliable in-order delivery. However the buffering technique is the
   most likely one to be adopted by typical applications. It provides
   reliable in-order delivery and there is no danger of packet size
   overflow like with the "Re-sending Transmission Window" (RTW)
   technique.

   The RTW technique may be preferred by applications that assume a
   continuous stream of short messages and need minimum delay. Under
   these conditions they will utilize the advantage of RTW: The
   incoming packets are processed immediately regardless whether they
   arrived in-order or not and no packets have to be buffered. If the
   message stream is not continuous the delay will increase from the
   sending rate to the retransmission period.

Kuthan                                                        [Page 5]

Internet Draft           SIP INFO Sample Uses             October 1999

   For instance, usage of the RTW seems to be reasonable for the
   aforementioned DTMF application. On the other hand the text
   application will use the buffering technique because the suggested
   text formats have no sequence numbers needed for RTW.

4 Glossary of Used Abbreviations

   MIME   Multipurpose Internet Mail Extension
   HTML   Hypertext Markup Language
   GSTN   General Switched Telephone Network
   SIP    Session Initiation Protocol
   ISUP   ISDN User Part
   UDP    User Datagram Protocol
   DTMF   Dual Tone Multi-Frequency
   RTP    Real-time Transport Protocol
   IVR    Interactive Voice Response
   OSP    Open Settlement Protocol

5 References

   [1]    M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg:
   "SIP: Session Initiation Protocol", RFC 2543, March 1999

   [2]    S. Donovan, M. Cannon: "The SIP INFO Method", Internet draft
   (draft-ietf-mmusic-sip-info-method-01), IETF, June 1999. Work in
   progress.

   [3]    N. Freed, N. Borenstein: "Multipurpose Internet Mail
   Extensions (MIME) Part Two: Media Types", RFC 2046, IETF, November
   1996.

   [4]    H. Schulzrinne, S. Petrack: "RTP Payload for DTMF Digits,
   Telephony Tones and Telephony Signals", Internet draft (draft-ietf-
   avt-tones-01), IETF, June 1999. Work in progress.

   [5]    M. Arango, A. Dugan, I. Elliott, C. Huitema,  S. Pickett:
   "Media Gateway Control Protocol (MGCP), Version 1.0", RFC 2705,
   IETF, October 1999.

   [6]    Klaus Hoffmann, Klaus Pulverer, Peter Blatherwick, Bob Bell,
   Markku Korpi, Tom Taylor, Richard Bach, and Christian Ruppelt:
   "Megaco/H.248 Generic Packages", Internet draft (draft-ietf-megaco-
   basicpkg-00), IETF, September 1999, Work in progress.

   [7]    ETSI-Tiphon: "Open Settlement Protocol (OSP) for Inter-Domain
   pricing, authorization and usage exchange", V 1.4.3, TS 101 321,
   October 1999.

   [8]    E. Zimmerer, A. Vemuri: "The SIP ISUP/MIME Type", Internet
   draft (draft-zimmerer-mmusic-sip-isup-mime-00), IETF, August 1999.
   Work in progress.

6 Author's Address

Kuthan                                                        [Page 6]

Internet Draft           SIP INFO Sample Uses             October 1999

   Jiri Kuthan
   MCI WorldCom
   2400 N. Glenville Dr.
   Richardson, TX 75082
   U.S.A.
   E-mail: [email-masked]

Kuthan                                                        [Page 7]