draft-ietf-mmusic-sip-info-method-00.txt   draft-ietf-mmusic-sip-info-method-01.txt 
Internet Engineering Task Force Steven R. Donovan Internet Draft Steve Donovan
INTERNET DRAFT MCI Worldcom draft-ietf-mmusic-sip-info-method-01.txt Matt Cannon
February 8, 1999 Expires August 8, 1999 June 1999 MCI Worldcom
<draft-ietf-mmusic-sip-info-method-00.txt>
The SIP INFO Method The SIP INFO Method
Status of this document Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that other
may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference mate-
or to cite them other than as "work in progress." rial or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/lid-abstracts.txt.
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), The list of Internet-Draft Shadow Directories can be accessed at
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
Abstract Abstract
This document proposes an extension to the Session Initiation Protocol. This document proposes an extension to the Session Initiation Proto-
This extension adds the INFO method to the SIP protocol. The intent col. This extension adds the INFO method to the SIP protocol. The
of the INFO method is to allow for the carrying of session related intent of the INFO method is to allow for the carrying of session
control information that is generated during a session. Examples of related control information that is generated during a session. One
such session control information are ISUP/ISDN signaling messages example of such session control information is ISUP and ISDN signal-
and DTMF digits used to control telephony services. ing messages used to control telephony calls services.
Internet draft The SIP INFO Method February 8, 1999 Another example might include reporting of signal strength in a wire-
less mobility application.
1.0 Introduction 1 Introduction
There are situations where session related control information needs to The SIP protocol handles the transport of session control information
be sent during a session. This information is separate from the media during the setup and tear down stages of a SIP controlled session.
that is being exchanged as part of the session.
Two examples of this are motivated by telephony related services: While SIP re-INVITEs can be used during a session to change the char-
acteristics of the session (generally to change the properties of
media flows related to the session), there is no general purpose
mechanism to carry session control information during the session.
1 - Mid Call Telephony Signaling Messages Although it is true that users and/or user agents involved in the
2 - DTMF Digit/Dial Plus Control of Telephony Services session can communicate directly during the session, this does not
ensure that SIP proxy servers that are involved in the setup and tear
down of the session will also be involved in the exchange of mid-
session control information.
One good example of mid-session control information that will need to
be carried between SIP user agents is PSTN mid-call signaling mes-
sages. These messages exist for both SS7 based ISUP signaling and
ISDN DSS1 based signaling.
Another hypothetical use of mid-session control is the use of SIP to
support wireless mobility applications. In this scenario it can be
envisioned that mid session messages would be sent to a control
entity to report on the signal strength for a wireless handset from
various base stations. The control entity would then use this infor-
mation to control handoffs between the base stations.
It can also be envisioned that there will be non telephony inspired It can also be envisioned that there will be non telephony inspired
uses of a mechanism for relaying mid session information between uses of a mechanism for relaying mid session information between par-
participants of the session and to Proxy Servers interested in the ticipants of the session and to Proxy Servers interested in the ses-
session. sion.
This document proposes the addition of the INFO Request method to the This document proposes the addition of the INFO Request method to the
SIP specification. SIP specification to be used for carrying of mid session information
along the session signaling path.
1.1 Mid Call Telephony Signaling Messages 2 Mid Call Telephony Signaling Messages
The first use for the INFO method is the need to carry mid call One use for the INFO method is the need to carry mid call signaling
signaling information resulting from the interworking between an ISUP information resulting from the interworking between an ISUP or ISDN
or ISDN network/device and a SIP controlled network. network/device and a SIP controlled network.
One specific example of this interworking is when the SIP controlled One specific example of this interworking is when the SIP controlled
network is used for transport between two PSTN locations. For this network is used for transport between two PSTN locations. For this
call, there will be a PSTN leg from the calling party to the SIP type of call, there will be a PSTN leg from the calling party to the
network, a SIP leg through the SIP network and a PSTN leg from the SIP SIP network, a SIP leg through the SIP network and a PSTN leg from
network to the called party. There needs to be a method to carry mid- the SIP network to the called party. There needs to be a method to
call PSTN signaling that is originated by the calling party through the carry mid-call PSTN signaling from the originating PSTN network,
SIP network to the called party. through the SIP network to the destination PSTN network.
1.2 DTMF Digit/Dial Plus Control of Telephony Services 2.1 ISUP Messages
The second type of telephony session control information that needs to The following is a partial list of the mid-call ISUP messages:
be carried during a session is DTMF or dial plus (refered to from here
on as DTMF) generated information. There are various telephony services
implemented today which require the use of DTMF digits. Due to the
design of these features, the DTMF information needs to be carried both
as part of the media stream (in the RTP flow) and as part of the
signaling or control path. This is due to the fact that there is an
implicit separation of the media and control path in the SIP protocol.
Thus, SIP Proxy Servers that implement services that require DTMF
control and that are not in the media path require a mechanism to be
notified of the DTMF digits.
Internet draft The SIP INFO Method February 8, 1999 Full Message Name Abbreviated ISUP Type
Name
------------------------------------------------
Facility Accepted FAA ANSI/ITU
Facility Reject FRJ ANSI/ITU
Facility Request FAR ANSI/ITU
Forward Transfer FOT ANSI/ITU
Identification Request IDR ITU
Identification Response IDF ITU
Facility Deactivated FAD ANSI
Facility Information FAI ANSI
Facility FAC ANSI/ITU
Information INF ANSI/ITU
Information Request INR ANSI/ITU
Pass Along Message PAM ANSI/ITU
Suspend SUS ANSI/ITU
Resume RES ANSI/ITU
User-to-User Information USR ANSI/ITU
2.0 INFO Method 2.2 Example PSTN Call Flow
The INFO method is used for communicating mid-session control The following is an example call flow showing the use of INFO message
information along the signaling path for the session. The signaling for carrying PSTN mid-call signaling messages.
path for the INFO method is the signaling path established as a
result of the session setup.
The mid-session control information can be communicated in either Orig PSTN Ingress GW SIP Server Egress GW Dest PSTN
an INFO message header or as part of an attachment. GW1 SPS GW2
------------>------------>------------>------------>
IAM Invite SPS Invite GW2 IAM
If the control information is telephony signaling information than the <-----------<------------<------------<------------
signaling message would be carried as part of an ISUP attachment to the ANM 200 OK 200 OK ANM
INFO message as described in draft-ietf-sigtran-mime-isup-00.txt.
The method for carrying the DTMF information in the INFO message has ------------>------------>------------>------------>
not yet been defined and is outside the scope of this document. ACK SPS1 ACK SPS3
<-----------<------------<------------<------------
USR INFO INFO USR
ISUP MIME ISUP MIME
USR USR
------------>------------>------------>------------>
USR INFO INFO USR
ISUP MIME ISUP MIME
USR USR
<-----------<------------<------------<------------
REL BYE BYE REL
------------>------------>------------>------------>
RLC 200 OK 200 OK RLC
3 INFO Method
The INFO method is used for communicating mid-session control infor-
mation along the signaling path for the session. The signaling path
for the INFO method is the signaling path established as a result of
the session setup. This can be either direct signaling between the
calling and called user agent or a signaling path involving SIP proxy
servers that were involved in the session setup and added themselves
to the Record-Route header on the initial INVITE message.
The mid-session control information can be communicated in either an
INFO message header or as part of an attachment.
If the control information is telephony signaling information then
the signaling message shall be carried as part of an ISUP attachment
to the INFO message as described in draft-ietf-sigtran-mime-
isup-00.txt.
2.1 Header Field Support for INFO Method 2.1 Header Field Support for INFO Method
The following table is an extension of tables 4 and 5 in the SIP The following table is an extension of tables 4 and 5 in the SIP
specification. Refer to the SIP Specification for a description of specification. Refer to Section 6 of the SIP Specification for a
the content of the table. description of the content of the table.
Header Where INFO Header Where INFO
------ ----- ---- ------ ----- ----
Accept R - Accept R -
Accept-Encoding R - Accept-Encoding R -
Accept-Language R o Accept-Language R o
Allow 200 - Allow 200 -
Allow 405 o Allow 405 o
Authorization R o Authorization R o
Call-ID gc m Call-ID gc m
skipping to change at page 3, line 51 skipping to change at line 190
Contact 2xx - Contact 2xx -
Contact 3xx - Contact 3xx -
Contact 485 - Contact 485 -
Content-Encoding e o Content-Encoding e o
Content-Length e o Content-Length e o
Content-Type e * Content-Type e *
CSeq gc m CSeq gc m
Date g o Date g o
Encryption g o Encryption g o
Expires g - Expires g -
>From gc m From gc m
Hide R o Hide R o
Max-Forwards R o Max-Forwards R o
Organization g o Organization g o
Internet draft The SIP INFO Method February 8, 1999
Header Where INFO Header Where INFO
------ ----- ---- ------ ----- ----
Priority R o Priority R o
Proxy-Authenticate 407 o Proxy-Authenticate 407 o
Proxy-Authorization R o Proxy-Authorization R o
Proxy-Require R o Proxy-Require R o
Require R o Require R o
Retry-After R - Retry-After R -
Retry-After 404,480,486 o Retry-After 404,480,486 o
Retry-After 503 o Retry-After 503 o
skipping to change at page 4, line 36 skipping to change at line 224
Unsupported 420 o Unsupported 420 o
User-Agent g o User-Agent g o
Via gc(2) m Via gc(2) m
Warning r o Warning r o
WWW-Authenticate 401 o WWW-Authenticate 401 o
2.2 Responses to the INFO Request Method 2.2 Responses to the INFO Request Method
A 200 OK response shall be sent if the INFO request was successful. A 200 OK response shall be sent if the INFO request was successful.
Request Failure (4xx), Server Failure (5xx) and Global Failure (6xx) A 481 Call Leg/Transaction Does Not Exist shall be sent if the INFO
responses can also be sent for the INFO Request. request does not match any existing call leg.
Other request failure (4xx), Server Failure (5xx) and Global Failure
(6xx) responses can also be sent for the INFO Request.
2.3 Message Body Inclusion 2.3 Message Body Inclusion
The INFO request may contain a message body. The INFO request may contain a message body.
2.4 Behavior of SIP User Agents 2.4 Behavior of SIP User Agents
The protocol rules applied by the SIP User Agent shall be similar to The protocol rules applied by the SIP User Agent shall be similar to
those applied used for the BYE request. However, the INFO message shall those used for the BYE request. However, the INFO message shall not
shall not change the state of the session. change the state of the session.
2.5 Behavior of SIP Proxy and Redirect Servers 2.5 Behavior of SIP Proxy and Redirect Servers
2.5.1 Proxy Server 2.5.1 Proxy Server
The protocol rules applied by the SIP Proxy Server shall be similar to The protocol rules applied by the SIP Proxy Server shall be similar
those applied used for the BYE request. However, the INFO message shall to those applied used for the BYE request. However, the INFO message
shall not change the state of the session. shall not change the state of the session.
Internet draft The SIP INFO Method February 8, 1999
2.5.2 Forking Proxy Server 2.5.2 Forking Proxy Server
The protocol rules applied by the SIP Forking Proxy Server shall be The protocol rules applied by the SIP Forking Proxy Server shall be
similar to those applied used for the BYE request. However, the INFO similar to those applied used for the BYE request. However, the INFO
message shall shall not change the state of the session. message shall not change the state of the session.
2.5.3 Redirection Server 2.5.3 Redirection Server
A redirection server should not receive the INFO method as it is a part A redirection server should not receive the INFO method as it is a
of the signaling path only at the initiation of the session. As part of the signaling path only at the initiation of the session. As
such, a redirection server should send a 403 Forbidden response. such, a redirection server should send a 403 Forbidden response.
2.6 Security Considerations 2.6 Security Considerations
There are no security issues specific to the INFO method. The security There are no security issues specific to the INFO method. The secu-
requirements specified in the SIP specification apply to the INFO rity requirements specified in the SIP specification apply to the
method. INFO method.
3.0 References 3.0 References
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
"SIP: Session Initiation Protocol", Internet Draft, Internet Session Initiation Protocol", RFC 2543, March 1999.
Engineering Task Force, January 15, 1999. Work in progress.
[2] C. Huitema, "The multipart/sip-id media type", Internet Draft, [2] C. Huitema, "The multipart/sip-id media type", Internet Draft,
Internet Engineering Task Force, February 5, 1999. Work in Internet Engineering Task Force, February 5, 1999. Work in Progress
Progress
4.0 Author's Address 4.0 Author's Address
Steve Donovan Steve Donovan
MCI Worldcom MCI Worldcom
1493/678 1493/678
901 International Parkway 901 International Parkway
Richardson, Texas 75081 Richardson, Texas 75081
Email: steven.r.donovan@mci.com Email: steven.r.donovan@wcom.com
Matthew Cannon
MCI Worldcom
9514/107
2400 North Glenville Drive
Richardson, Texas 75082
Email: matt.cannon@wcom.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/