WDIFF

draft-ietf-sip-info-method-00.txt --> draft-ietf-sip-info-method-01.txt

draft-ietf-sip-info-method-00.txt
draft-ietf-sip-info-method-01.txt MCI Worldcom
October 1999
January 2000

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
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/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.
Protocol (SIP). 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 signaling messages used to control telephony calls call services.

Other

This and other example uses of the INFO method include may be standardized in
the carrying future.

Donovan draft-ietf-sip-info-method-01.txt [Page 1]

Internet Draft The SIP INFO Method January 2000

Table of encoded
DTMF digits and Contents

1 Introduction................................................3
1.1 Example Uses................................................3
2 INFO Method.................................................4
2.1 Header Field Support for INFO Method........................4
2.2 Responses to the reporting INFO Request Method........................4
2.3 Message Body Inclusion......................................6
2.4 Behavior of signal strength in a wireless mobil-
ity application. SIP User Agents.................................6
2.5 Behavior of SIP Proxy and Redirect Servers..................7
2.5.1 Proxy Server................................................7
2.5.2 Forking Proxy Server........................................7
2.5.3 Redirection Server..........................................7
2.6 Security Considerations.....................................7
3. INFO Message Bodies.........................................7
4. Guidelines for extensions making use of INFO................8
5. References..................................................8
6. Acknowledgments.............................................9
7. Author's Address............................................9
Full Copyright Statement...................................10

Donovan draft-ietf-sip-info-method-00.txt Page 1 draft-ietf-sip-info-method-01.txt [Page 2]

Internet Draft The SIP INFO Method October 1999

1 January 2000

1. Introduction

The SIP protocol defined described in [1] defines session control messages
used during the setup and tear down stages of a SIP controlled
session.

In addition, the SIP re-INVITE can be used during a session to change
the characteristics of the session. This is generally to change the
properties of media flows related to the session or to update the
session timer as defined in [2].

However, there is no general-purpose mechanism to carry session con-
trol
control information along the SIP signaling path during the session.

The purpose of the INFO message is to carry application level
information along the SIP signaling path.

The INFO method is not used to change the state of SIP calls, or the
parameters of the sessions SIP initiates. It merely sends optional
application layer information, generally related to the session.

It is necessary for that the mid-session signaling information traverse
the post session setup SIP signaling path. This is the path taken by
SIP re-INVITEs, BYEs and other SIP requests sent that are tied to an
individual session. This will allow allows SIP proxy servers to receive receive, and
potentially act on, the mid-session signaling information.

1.1 Example Uses

One example of mid-session control information that will need

This document proposes an extension to be
carried between SIP user agents is PSTN mid-call signaling messages.
These messages exist by defining the new INFO
method. The INFO method would be used for both SS7 based ISUP signaling and ISDN DSS1
based signaling. This example is explained in more detail in a fol-
lowing section of this document.

A second type the carrying of session control mid-call
signaling information that needs to be carried
during a along the session is DTMF or dial plus (referred to from here on as
DTMF) digits. There signaling path.

1.1 Example Uses

The following are various telephony services implemented today
that require the use a few of DTMF digits. Due to the design potential uses of these fea-
tures, the INFO message:

- Carrying mid-call PSTN signaling messages between PSTN
gateways.

- Carrying DTMF digits generated during a SIP session.

- Carrying wireless signal strength information needs to be carried both as part of the
media stream (in the RTP flow) and as part in support of the signaling
wireless mobility applications.

- Carrying account balance information.

- Carrying images or con-
trol path. This is due to other non streaming information between the fact that there is an implicit separa-
tion of the media and control path in the SIP protocol. Thus, SIP
Proxy Servers that implement services that require DTMF based control
and that are not in the media path require a mechanism to be notified
of when DTMF digits are entered by one of the user agents.

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 the INFO method could be used for a
UAS (either the called user agent
participants of an intermediary server) to
update the calling user on account status. For instance, the called
user agent could communicate through the INFO method the message that
the user's credit is about to expire. This could be via a text mes-
sage body attached to the INFO message. The use of the SIP INFO session.

Donovan draft-ietf-sip-info-method-00.txt Page 2 draft-ietf-sip-info-method-01.txt [Page 3]

Internet Draft The SIP INFO Method October 1999

method for this type of communication would allow the calling user
agents IP address information to remain hidden from the UAS (assuming
that an intermediary element is performing an address translation
function for the calling user agent).

If the contents of the message body January 2000

These are private then end-to-end
encryption of the message body can be used to prevent intermediary
proxy servers from seeing the content. just potential uses; this document does not specify such
uses nor does it necessarily recommend them.

It can also be envisioned that there will be other telephony and non-
telephony
non-telephony uses of the INFO method.

This document proposes the addition of the

2. INFO Method

The INFO Request method to the
SIP specification to be is used for carrying of communicating mid-session signaling
information along the session signaling path.

2 Mid Call Telephony Signaling Messages

One use path for the call.

The INFO method is not used to carry mid call signaling informa-
tion resulting from change the interworking between an ISUP or ISDN net-
work/device and a SIP controlled network.

One specific example state 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 calls, nor
does it change the SIP network to state of sessions initiated by SIP. Rather, it
provides additional optional information which can further enhance
the called party. There needs to be a method to
carry mid-call PSTN application using SIP.

The signaling from the originating PSTN network,
through the SIP network, to path for the destination PSTN network.

2.1 ISUP Messages

The following INFO method is the signaling path
established as a partial list result of the mid-call ISUP messages:

Donovan draft-ietf-sip-info-method-00.txt Page 3

Internet Draft The SIP INFO Method October 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.2 Example PSTN Call Flow

The following is an example call flow showing PSTN mid-call signaling
messages.

Orig PSTN Dest PSTN
------------>
IAM

<-----------
ACM

<-----------
ANM

------------>
USR

<-----------
USR

------------>
REL

<-----------
REL

3 Implementation Alternatives setup. This section outlines alternatives that have been proposed for the
carrying of mid-session can be either direct
signaling information. This includes using a
re-INVITE, using between the SIGTRAN defined protocol calling and using the INFO

Donovan draft-ietf-sip-info-method-00.txt Page 4

Internet Draft The called user agents or a signaling
path involving SIP INFO Method October 1999

method.

3.1 Re-INVITE

One method for addressing proxy servers that were involved in the requirement call setup
and added themselves to carry the Record-Route header on the initial INVITE
message.

The mid-session sig-
naling information is to carry this information can be communicated in either an INVITE INFO
message
that contains the same call identification information. This is
referred to header or as part of a re-INVITE. This method is currently message body. The definition of the
message body and/or message headers used to commu-
nicate changes to an existing SIP session, for instance to change carry the
codec used for a voice media stream or mid-session
information is outside the updating scope of the session
timer.

While this would work for mid-session signaling, it has the problem
that it further overloads the INVITE method. In addition, document.

There are no specific semantics associated with INFO. The semantics
are derived from the cur-
rent re-INVITE is used to communication a desired change in the ses-
sion. Mid-session signaling information will generally not be used
to make changes to the SIP session, especially if the information
carried is ISUP body or other PSTN signaling messages.

3.2 Sigtran

There is work currently under way new headers defined for usage in the SIGTRAN working group to
define a protocol INFO.

2.1 Header Field Support for the reliable transport of PSTN signaling mes-
sages. This would include carrying INFO Method

Tables 1 and 2 are extensions of tables 4 and 5 in the ISUP protocol over an IP
network.

One proposal would be [1]. Refer
to establish a SIGTRAN relationship Section 6 of [1] for a description of the
transport content of mid-session signaling information. It could be envi-
sioned that the SIGTRAN session setup could be achieved by adding a
SIGTRAN session description message body
tables.

2.2 Responses to the SIP INVITE and INFO Request Method

A 200 OK
messages.

The primary drawback of this approach is that the SIGTRAN session
would response MUST be between user agents (i.e.; between the ingress PSTN gateway
and the egress PSTN gateway). As sent by a result, proxy servers involved in
setting up UAS for an INFO request with
no message body if the session would not be able to receive any user agent to
user agent SIGTRAN mid-session signaling information. INFO request was successfully received for
an existing call. Beyond that, no additional operations are
required.

A second objection to this approach is that it assumes that all of
the mid-session information to 481 Call Leg/Transaction Does Not Exist MUST be carried is telephony signaling
information. This is sent by a limiting assumption as there are non-tele-
phony uses of mid-session signaling.

A further drawback to this approach is the complexity that it would
put on user agents. User agents would need to setup and manage two
signaling relationships for every session. In addition, UAS if
the user
agent were a PSTN gateway, then it would need to build PSTN signaling
messages based on both SIP and SIGTRAN messages received.

3.3 INFO request does not match any existing call leg.

Donovan draft-ietf-sip-info-method-00.txt Page 5 draft-ietf-sip-info-method-01.txt [Page 4]

Internet Draft The SIP INFO Method October 1999

The mechanism proposed in this draft is to add a new method to the
SIP protocol. This method, called the January 2000

Header Where INFO method, would be used to
carry any mid-session signaling information along the SIP signaling
path, between the calling and called user agents.

3.3.1 Example PSTN Call Flow with the
------ ----- ----
Accept R o
Accept-Encoding R o
Accept-Language R o
Allow 200 -
Allow 405 o
Authorization R o
Call-ID gc m
Contact R o
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 o
From gc m
Hide R o
Max-Forwards R o
Organization g o

Figure 1 Summary of header fields, A-0

Handling of INFO message.

The following messages that contain message bodies is an example call flow showing outside
the use scope of INFO message
for carrying PSTN mid-call signaling messages.

Orig PSTN Ingress GW SIP Server Egress GW Dest PSTN
GW1 SPS GW2
------------>------------>------------>------------>
IAM Invite Invite IAM

<-----------<------------<------------<------------
ACM 180 Ringing 180 Ringing ACM

<-----------<------------<------------<------------
ANM 200 OK 200 OK ANM

------------>------------>
ACK ACK

<-----------<------------<------------<------------
USR INFO INFO USR
ISUP MIME ISUP MIME
USR USR

------------>------------>
200 OK 200 OK

------------>------------>------------>------------>
USR INFO INFO USR
ISUP MIME ISUP MIME
USR USR

<------------<------------
200 OK 200 OK

<-----------<------------<------------<------------
REL BYE BYE REL

------------>
RLC

------------>------------>
200 OK 200 OK

------------>
RLC

Donovan draft-ietf-sip-info-method-00.txt Page 6

Internet Draft this document. The documents defining the message
bodies will also need to define the SIP protocol rules associated
with those message bodies.

If a server receives an INFO Method October 1999

4 INFO Method

The request with a body it understands,
but it has no knowledge of INFO method is used associated processing rules for communicating mid-session signaling
information along
the signaling path for body, the session. The signaling
path for body MAY be rendered and displayed to the user. The
INFO method is the signaling path established as responded to with a
result of the session setup. This can be either direct signaling
between the calling and called user agents or 200 OK.

Bodies which imply a signaling path
involving SIP proxy servers that were involved change in the session setup
and added themselves to the Record-Route header on SIP call state or the initial INVITE
message.

The mid-session control information can sessions
initiated by SIP MUST NOT be communicated sent in either an INFO message header or as part of an attachment. The definition of
the attachments used to carry the mid-session information is outside
the scope of this document.

4.1 Header Field Support for INFO Method

The following table is an extension of tables 4 message.

Other request failure (4xx), Server Failure (5xx) and 5 in the [1].
Refer to Section 6 of [1] for a description of the content of Global
Failure (6xx) responses MAY be sent for the
table.

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 Request.

Donovan draft-ietf-sip-info-method-00.txt Page 7 draft-ietf-sip-info-method-01.txt [Page 5]

Internet Draft The SIP INFO Method October 1999 January 2000

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 - o
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

4.2 Responses to the INFO Request Method

A 200 OK response shall be sent if the INFO request was successfully
received.

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.

4.3

Figure 2 Summary of header fields, P-Z

2.3 Message Body Inclusion

The INFO request may MAY contain a message body.

4.4

2.4 Behavior of SIP User Agents

Unless stated otherwise, the protocol rules defined for the INFO
request governing the usage of tags, Route and Record-Route,
retransmission and reliability, CSeq incrementing and message
formatting follow those in [1] as defined for the BYE request.

An INFO request shall apply MAY be cancelled. A UAS receiving a CANCEL for
an INFO request SHOULD respond to the INFO request. with a "487 Request
Cancelled" response if a final response has not been sent to
the INFO and then behave as if the request were never received.

However, the INFO message shall not MUST NOT change the state of the session.

4.5 SIP
call, or the sessions initiated by SIP.

Donovan draft-ietf-sip-info-method-01.txt [Page 6]

Internet Draft The SIP INFO Method January 2000

2.5 Behavior of SIP Proxy and Redirect Servers

4.5.1

2.5.1 Proxy Server

Donovan draft-ietf-sip-info-method-00.txt Page 8

Internet Draft The SIP INFO Method October 1999

Unless stated otherwise, the protocol rules defined in [1] for the
BYE INFO
request shall apply at a proxy are identical to those for a BYE request as
specified in [1].

2.5.2 Forking Proxy Server

Unless stated otherwise, the INFO request.

However, protocol rules for the INFO message shall not change the state of the session.

4.5.2 Forking Proxy
request at a proxy are identical to those for a BYE request as
specified in [1].

2.5.3 Redirection Server

Unless stated otherwise, the protocol rules defined in [1] for the
BYE INFO
request shall apply at a proxy are identical to the INFO request.

However, the INFO message shall not change the state of the session.

4.5.3 Redirection Server

A redirection server should not receive the INFO method, as it is those for a
part of BYE request as
specified in [1].

2.6 Security Considerations

If the signaling path only at contents of the initiation message body are private then end-to-end
encryption of the session. As
such, a redirection server should send a 403 Forbidden response message body can be used to an
INFO message.

4.6 Security Considerations prevent unauthorized
access to the content.

There are no other security issues specific to the INFO method.
The secu-
rity security requirements specified in the SIP specification apply
to the INFO method.

5.0

3. INFO Message Bodies

The purpose of the INFO message is to carry mid-session information
between SIP user agents. This information will generally be carried
in message bodies, although it can be carried in headers in the INFO
message.

The definition of the message bodies or any new headers created for
the INFO method is outside the scope of this document. It is
expected that separate documents will be created created to address
definition of these entities.

In addition, the INFO method does not define additional mechanisms
for ensuring in-order delivery. While the CSeq header will be
incremented upon the transmission of new INFO messages, this should
not be used to determine the sequence of INFO information. This is
due to the fact that there could be gaps in the INFO message CSeq
count caused by a user agent sending re-INVITES or other SIP
messages.

Donovan draft-ietf-sip-info-method-01.txt [Page 7]

Internet Draft The SIP INFO Method January 2000

4. Guidelines for extensions making use of INFO

The following are considerations that should be taken into account
when defining SIP extensions that make use of the INFO method.

- Consideration should be taken on the size of message bodies to be
carried by INFO messages. The message bodies should be kept small
due to the potential for the message to be carried over UDP and the
potential for fragmentation of larger messages.

- There is potential that INFO messages could be forked by a SIP
Proxy Server. The implications of this forking of the information
in the INFO message SHOULD be taken into account.

- The use of multi-part message bodies may be helpful when defining
the message bodies to address defini-
tion of these entities.

In addition, be carried by the INFO method does not add to message.

- The extensions that use the mechanisms of INFO message MUST NOT rely on the
SIP protocol for ensuring in-order delivery of mid-session signaling
information. While
INFO message to do anything that effects the CSeq header will be incremented upon SIP call state or the
transmission
state of new related sessions.

- The INFO messages, extension defined in this should document does not be used to deter-
mine depend on
the sequence use of INFO information. This is due to the fact that
there could be gaps in Require or Proxy-Require headers. Extensions using
the INFO message CSeq count caused by a user
agent sending re-INVITES or other may need the use of these mechanisms. However,
the use of Require and Proxy-Require should be avoided, if
possible, in order to improve interoperability between SIP messages. 5.0
entities.

5. References

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

[2] S. Donovan, "SIP Session Timer", Internet Draft, Internet Engineer-
ing
Engineering Task Force, October, 1999. Work in Progress.

Donovan draft-ietf-sip-info-method-00.txt Page 9 draft-ietf-sip-info-method-01.txt [Page 8]

Internet Draft The SIP INFO Method October 1999

6.0 January 2000

6. Acknowledgements

The author would like to thank Matthew Cannon for his contributions
to this document. In addition, the author would like to thank the
members of the MMUSIC and SIP, especially Jonathan Rosenberg, working
groups for comments and suggestions on how to improve the document.

7. Author's Address

Steve Donovan
MCI Worldcom
1493/678
901 International Parkway
Richardson, Texas 75081
Email: steven.r.donovan@wcom.com

Donovan draft-ietf-sip-info-method-00.txt Page 10 draft-ietf-sip-info-method-01.txt [Page 9]

Internet Draft The SIP INFO Method January 2000

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Donovan draft-ietf-sip-info-method-01.txt [Page 10]
----