[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 draft-ietf-sip-info-method
Internet Draft Steve Donovan
draft-ietf-mmusic-sip-info-method-01.txt Matt Cannon
June 1999 MCI Worldcom
The SIP INFO Method
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 mate-
rial 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/lid-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes an extension to the Session Initiation Proto-
col. This extension adds the INFO method to the SIP protocol. The
intent of the INFO method is to allow for the carrying of session
related control information that is generated during a session. One
example of such session control information is ISUP and ISDN signal-
ing messages used to control telephony calls services.
Another example might include reporting of signal strength in a wire-
less mobility application.
Donovan, Cannon draft-ietf-mmusic-sip-info-method-01.txt Page 1
Internet Draft The SIP INFO Method June 1999
1 Introduction
The SIP protocol handles the transport of session control information
during the setup and tear down stages of a SIP controlled session.
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.
Although it is true that users and/or user agents involved in the
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
uses of a mechanism for relaying mid session information between par-
ticipants of the session and to Proxy Servers interested in the ses-
sion.
This document proposes the addition of the INFO Request method to the
SIP specification to be used for carrying of mid session information
along the session signaling path.
2 Mid Call Telephony Signaling Messages
One use for the INFO method is the need to carry mid call signaling
information resulting from the interworking between an ISUP or ISDN
network/device and a SIP controlled network.
One specific example of this interworking is when the SIP controlled
network is used for transport between two PSTN locations. For this
type of call, there will be a PSTN leg from the calling party to the
SIP network, a SIP leg through the SIP network and a PSTN leg from
the SIP network to the called party. There needs to be a method to
carry mid-call PSTN signaling from the originating PSTN network,
through the SIP network to the destination PSTN network.
Donovan, Cannon draft-ietf-mmusic-sip-info-method-01.txt Page 2
Internet Draft The SIP INFO Method June 1999
2.1 ISUP Messages
The following is a partial list of the mid-call ISUP messages:
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.2 Example PSTN Call Flow
The following is an example call flow showing the use of INFO message
for carrying PSTN mid-call signaling messages.
Donovan, Cannon draft-ietf-mmusic-sip-info-method-01.txt Page 3
Internet Draft The SIP INFO Method June 1999
Orig PSTN Ingress GW SIP Server Egress GW Dest PSTN
GW1 SPS GW2
------------>------------>------------>------------>
IAM Invite SPS Invite GW2 IAM
<-----------<------------<------------<------------
ANM 200 OK 200 OK ANM
------------>------------>------------>------------>
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
The following table is an extension of tables 4 and 5 in the SIP
specification. Refer to Section 6 of the SIP Specification for a
description of the content of the table.
Donovan, Cannon draft-ietf-mmusic-sip-info-method-01.txt Page 4
Internet Draft The SIP INFO Method June 1999
Header Where INFO
------ ----- ----
Accept R -
Accept-Encoding R -
Accept-Language R o
Allow 200 -
Allow 405 o
Authorization R o
Call-ID gc m
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx -
Contact 485 -
Content-Encoding e o
Content-Length e o
Content-Type e *
CSeq gc m
Date g o
Encryption g o
Expires g -
From gc m
Hide R o
Max-Forwards R o
Organization g o
Header Where INFO
------ ----- ----
Priority R o
Proxy-Authenticate 407 o
Proxy-Authorization R o
Proxy-Require R o
Require R o
Retry-After R -
Retry-After 404,480,486 o
Retry-After 503 o
Retry-After 600,603 o
Response-Key R o
Record-Route R o
Record-Route 2xx o
Route R o
Server r o
Subject R -
Timestamp g o
To gc(1) m
Unsupported 420 o
User-Agent g o
Via gc(2) m
Warning r o
WWW-Authenticate 401 o
Donovan, Cannon draft-ietf-mmusic-sip-info-method-01.txt Page 5
Internet Draft The SIP INFO Method June 1999
2.2 Responses to the INFO Request Method
A 200 OK response shall be sent if the INFO request was successful.
A 481 Call Leg/Transaction Does Not Exist shall be sent if the INFO
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
The INFO request may contain a message body.
2.4 Behavior of SIP User Agents
The protocol rules applied by the SIP User Agent shall be similar to
those used for the BYE request. However, the INFO message shall not
change the state of the session.
2.5 Behavior of SIP Proxy and Redirect Servers
2.5.1 Proxy Server
The protocol rules applied by the SIP Proxy Server shall be similar
to those applied used for the BYE request. However, the INFO message
shall not change the state of the session.
2.5.2 Forking Proxy Server
The protocol rules applied by the SIP Forking Proxy Server shall be
similar to those applied used for the BYE request. However, the INFO
message shall not change the state of the session.
2.5.3 Redirection Server
A redirection server should not receive the INFO method as it is a
part of the signaling path only at the initiation of the session. As
such, a redirection server should send a 403 Forbidden response.
2.6 Security Considerations
There are no security issues specific to the INFO method. The secu-
rity requirements specified in the SIP specification apply to the
INFO method.
3.0 References
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
Session Initiation Protocol", RFC 2543, March 1999.
Donovan, Cannon draft-ietf-mmusic-sip-info-method-01.txt Page 6
Internet Draft The SIP INFO Method June 1999
[2] C. Huitema, "The multipart/sip-id media type", Internet Draft,
Internet Engineering Task Force, February 5, 1999. Work in Progress
4.0 Author's Address
Steve Donovan
MCI Worldcom
1493/678
901 International Parkway
Richardson, Texas 75081
Email: steven.r.donovan@wcom.com
Matthew Cannon
MCI Worldcom
9514/107
2400 North Glenville Drive
Richardson, Texas 75082
Email: matt.cannon@wcom.com
Donovan, Cannon draft-ietf-mmusic-sip-info-method-01.txt Page 7
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/