Internet Engineering Task Force Jiri Kuthan Internet Draft MCI WorldCom draft-kuthan-info-payload-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:ivr@nababa.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: National Banana Bank Call-ID: 3298420296@kton.bell-tel.com CSeq: 2 INFO Subject: Money Transfer By Wire Content-Type: application/mgcp Content-Length: 75 NTFY 123456 a.g.bell@bell-tel.com 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:ivr@nababa.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: National Banana Bank Call-ID: 3298420296@kton.bell-tel.com 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 a.g.bell@bell-tel.com 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 a.g.bell@bell-tel.com 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 a.g.bell@bell-tel.com 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: jiri.kuthan@wcom.com Kuthan [Page 7]