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