Internet DRAFT - draft-kuthan-info-payload
draft-kuthan-info-payload
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 <sip:a.g.bell@bell-tel.com>
To: National Banana Bank <sip:ivr@nababa.com>
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 <sip:a.g.bell@bell-tel.com>
To: National Banana Bank <sip:ivr@nababa.com>
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]
