Internet Draft Steve Donovan draft-ietf-sip-info-method-00.txt MCI Worldcom October 1999 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. Other example uses of the INFO method include the carrying of encoded DTMF digits and the reporting of signal strength in a wireless mobil- ity application. Donovan draft-ietf-sip-info-method-00.txt Page 1 Internet Draft The SIP INFO Method October 1999 1 Introduction The SIP protocol defined 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 information along the SIP signaling path during the session. It is necessary for 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 SIP proxy servers to receive the mid-session signaling information. 1.1 Example Uses One example of mid-session control information that will need to be carried between SIP user agents is PSTN mid-call signaling messages. These messages exist 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 of session control information that needs to be carried during a session is DTMF or dial plus (referred to from here on as DTMF) digits. There are various telephony services implemented today that require the use of DTMF digits. Due to the design of these fea- tures, 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 con- trol path. This is due to 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 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 Donovan draft-ietf-sip-info-method-00.txt Page 2 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 are private then end-to-end encryption of the message body can be used to prevent intermediary proxy servers from seeing the content. It can also be envisioned that there will be other telephony and non- telephony uses of the INFO method. 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 to carry mid call signaling informa- tion resulting from the interworking between an ISUP or ISDN net- work/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. 2.1 ISUP Messages The following is a partial list 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 This section outlines alternatives that have been proposed for the carrying of mid-session signaling information. This includes using a re-INVITE, using the SIGTRAN defined protocol and using the INFO Donovan draft-ietf-sip-info-method-00.txt Page 4 Internet Draft The SIP INFO Method October 1999 method. 3.1 Re-INVITE One method for addressing the requirement to carry mid-session sig- naling information is to carry this information in an INVITE message that contains the same call identification information. This is referred to as a re-INVITE. This method is currently used to commu- nicate changes to an existing SIP session, for instance to change the codec used for a voice media stream or the updating 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, 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 or other PSTN signaling messages. 3.2 Sigtran There is work currently under way in the SIGTRAN working group to define a protocol for the reliable transport of PSTN signaling mes- sages. This would include carrying of the ISUP protocol over an IP network. One proposal would be to establish a SIGTRAN relationship for the transport 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 to the SIP INVITE and 200 OK messages. The primary drawback of this approach is that the SIGTRAN session would be between user agents (i.e.; between the ingress PSTN gateway and the egress PSTN gateway). As a result, proxy servers involved in setting up the session would not be able to receive any user agent to user agent SIGTRAN mid-session signaling information. A second objection to this approach is that it assumes that all of the mid-session information to be carried is telephony signaling information. This is 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, 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 Donovan draft-ietf-sip-info-method-00.txt Page 5 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 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 INFO message. The following is an example call flow showing the use 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 The SIP INFO Method October 1999 4 INFO Method The INFO method is used for communicating mid-session signaling information 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 agents 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. 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 and 5 in the [1]. Refer to Section 6 of [1] for a description of the content of 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 Donovan draft-ietf-sip-info-method-00.txt Page 7 Internet Draft The SIP INFO Method October 1999 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 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 Message Body Inclusion The INFO request may contain a message body. 4.4 Behavior of SIP User Agents Unless stated otherwise, the protocol rules defined in [1] for the BYE request shall apply to the INFO request. However, the INFO message shall not change the state of the session. 4.5 Behavior of SIP Proxy and Redirect Servers 4.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 request shall apply to the INFO request. However, the INFO message shall not change the state of the session. 4.5.2 Forking Proxy Server Unless stated otherwise, the protocol rules defined in [1] for the BYE request shall apply 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 a part of the signaling path only at the initiation of the session. As such, a redirection server should send a 403 Forbidden response to an INFO message. 4.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. 5.0 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 to address defini- tion of these entities. In addition, the INFO method does not add to the mechanisms of the SIP protocol for ensuring in-order delivery of mid-session signaling information. While the CSeq header will be incremented upon the transmission of new INFO messages, this should not be used to deter- mine 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. 5.0 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 Task Force, October, 1999. Work in Progress. Donovan draft-ietf-sip-info-method-00.txt Page 9 Internet Draft The SIP INFO Method October 1999 6.0 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