idnits 2.17.1 draft-ietf-mmusic-sip-info-method-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 268, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 271, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Steve Donovan 2 draft-ietf-mmusic-sip-info-method-01.txt Matt Cannon 3 June 1999 MCI Worldcom 5 The SIP INFO Method 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference mate- 19 rial or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/lid-abstracts.txt. 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document proposes an extension to the Session Initiation Proto- 30 col. This extension adds the INFO method to the SIP protocol. The 31 intent of the INFO method is to allow for the carrying of session 32 related control information that is generated during a session. One 33 example of such session control information is ISUP and ISDN signal- 34 ing messages used to control telephony calls services. 36 Another example might include reporting of signal strength in a wire- 37 less mobility application. 39 1 Introduction 41 The SIP protocol handles the transport of session control information 42 during the setup and tear down stages of a SIP controlled session. 44 While SIP re-INVITEs can be used during a session to change the char- 45 acteristics of the session (generally to change the properties of 46 media flows related to the session), there is no general purpose 47 mechanism to carry session control information during the session. 49 Although it is true that users and/or user agents involved in the 50 session can communicate directly during the session, this does not 51 ensure that SIP proxy servers that are involved in the setup and tear 52 down of the session will also be involved in the exchange of mid- 53 session control information. 55 One good example of mid-session control information that will need to 56 be carried between SIP user agents is PSTN mid-call signaling mes- 57 sages. These messages exist for both SS7 based ISUP signaling and 58 ISDN DSS1 based signaling. 60 Another hypothetical use of mid-session control is the use of SIP to 61 support wireless mobility applications. In this scenario it can be 62 envisioned that mid session messages would be sent to a control 63 entity to report on the signal strength for a wireless handset from 64 various base stations. The control entity would then use this infor- 65 mation to control handoffs between the base stations. 67 It can also be envisioned that there will be non telephony inspired 68 uses of a mechanism for relaying mid session information between par- 69 ticipants of the session and to Proxy Servers interested in the ses- 70 sion. 72 This document proposes the addition of the INFO Request method to the 73 SIP specification to be used for carrying of mid session information 74 along the session signaling path. 76 2 Mid Call Telephony Signaling Messages 78 One use for the INFO method is the need to carry mid call signaling 79 information resulting from the interworking between an ISUP or ISDN 80 network/device and a SIP controlled network. 82 One specific example of this interworking is when the SIP controlled 83 network is used for transport between two PSTN locations. For this 84 type of call, there will be a PSTN leg from the calling party to the 85 SIP network, a SIP leg through the SIP network and a PSTN leg from 86 the SIP network to the called party. There needs to be a method to 87 carry mid-call PSTN signaling from the originating PSTN network, 88 through the SIP network to the destination PSTN network. 90 2.1 ISUP Messages 92 The following is a partial list of the mid-call ISUP messages: 94 Full Message Name Abbreviated ISUP Type 95 Name 96 ------------------------------------------------ 97 Facility Accepted FAA ANSI/ITU 98 Facility Reject FRJ ANSI/ITU 99 Facility Request FAR ANSI/ITU 100 Forward Transfer FOT ANSI/ITU 101 Identification Request IDR ITU 102 Identification Response IDF ITU 103 Facility Deactivated FAD ANSI 104 Facility Information FAI ANSI 105 Facility FAC ANSI/ITU 106 Information INF ANSI/ITU 107 Information Request INR ANSI/ITU 108 Pass Along Message PAM ANSI/ITU 109 Suspend SUS ANSI/ITU 110 Resume RES ANSI/ITU 111 User-to-User Information USR ANSI/ITU 113 2.2 Example PSTN Call Flow 115 The following is an example call flow showing the use of INFO message 116 for carrying PSTN mid-call signaling messages. 118 Orig PSTN Ingress GW SIP Server Egress GW Dest PSTN 119 GW1 SPS GW2 120 ------------>------------>------------>------------> 121 IAM Invite SPS Invite GW2 IAM 123 <-----------<------------<------------<------------ 124 ANM 200 OK 200 OK ANM 126 ------------>------------>------------>------------> 127 ACK SPS1 ACK SPS3 129 <-----------<------------<------------<------------ 130 USR INFO INFO USR 131 ISUP MIME ISUP MIME 132 USR USR 134 ------------>------------>------------>------------> 135 USR INFO INFO USR 136 ISUP MIME ISUP MIME 137 USR USR 139 <-----------<------------<------------<------------ 140 REL BYE BYE REL 142 ------------>------------>------------>------------> 143 RLC 200 OK 200 OK RLC 145 3 INFO Method 147 The INFO method is used for communicating mid-session control infor- 148 mation along the signaling path for the session. The signaling path 149 for the INFO method is the signaling path established as a result of 150 the session setup. This can be either direct signaling between the 151 calling and called user agent or a signaling path involving SIP proxy 152 servers that were involved in the session setup and added themselves 153 to the Record-Route header on the initial INVITE message. 155 The mid-session control information can be communicated in either an 156 INFO message header or as part of an attachment. 158 If the control information is telephony signaling information then 159 the signaling message shall be carried as part of an ISUP attachment 160 to the INFO message as described in draft-ietf-sigtran-mime- 161 isup-00.txt. 163 2.1 Header Field Support for INFO Method 165 The following table is an extension of tables 4 and 5 in the SIP 166 specification. Refer to Section 6 of the SIP Specification for a 167 description of the content of the table. 169 Header Where INFO 170 ------ ----- ---- 171 Accept R - 172 Accept-Encoding R - 173 Accept-Language R o 174 Allow 200 - 175 Allow 405 o 176 Authorization R o 177 Call-ID gc m 178 Contact R - 179 Contact 1xx - 180 Contact 2xx - 181 Contact 3xx - 182 Contact 485 - 183 Content-Encoding e o 184 Content-Length e o 185 Content-Type e * 186 CSeq gc m 187 Date g o 188 Encryption g o 189 Expires g - 190 From gc m 191 Hide R o 192 Max-Forwards R o 193 Organization g o 195 Header Where INFO 196 ------ ----- ---- 197 Priority R o 198 Proxy-Authenticate 407 o 199 Proxy-Authorization R o 200 Proxy-Require R o 201 Require R o 202 Retry-After R - 203 Retry-After 404,480,486 o 204 Retry-After 503 o 205 Retry-After 600,603 o 206 Response-Key R o 207 Record-Route R o 208 Record-Route 2xx o 209 Route R o 210 Server r o 211 Subject R - 212 Timestamp g o 213 To gc(1) m 214 Unsupported 420 o 215 User-Agent g o 216 Via gc(2) m 217 Warning r o 218 WWW-Authenticate 401 o 220 2.2 Responses to the INFO Request Method 222 A 200 OK response shall be sent if the INFO request was successful. 224 A 481 Call Leg/Transaction Does Not Exist shall be sent if the INFO 225 request does not match any existing call leg. 227 Other request failure (4xx), Server Failure (5xx) and Global Failure 228 (6xx) responses can also be sent for the INFO Request. 230 2.3 Message Body Inclusion 232 The INFO request may contain a message body. 234 2.4 Behavior of SIP User Agents 236 The protocol rules applied by the SIP User Agent shall be similar to 237 those used for the BYE request. However, the INFO message shall not 238 change the state of the session. 240 2.5 Behavior of SIP Proxy and Redirect Servers 242 2.5.1 Proxy Server 244 The protocol rules applied by the SIP Proxy Server shall be similar 245 to those applied used for the BYE request. However, the INFO message 246 shall not change the state of the session. 248 2.5.2 Forking Proxy Server 250 The protocol rules applied by the SIP Forking Proxy Server shall be 251 similar to those applied used for the BYE request. However, the INFO 252 message shall not change the state of the session. 254 2.5.3 Redirection Server 256 A redirection server should not receive the INFO method as it is a 257 part of the signaling path only at the initiation of the session. As 258 such, a redirection server should send a 403 Forbidden response. 260 2.6 Security Considerations 262 There are no security issues specific to the INFO method. The secu- 263 rity requirements specified in the SIP specification apply to the 264 INFO method. 266 3.0 References 268 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 269 Session Initiation Protocol", RFC 2543, March 1999. 271 [2] C. Huitema, "The multipart/sip-id media type", Internet Draft, 272 Internet Engineering Task Force, February 5, 1999. Work in Progress 274 4.0 Author's Address 276 Steve Donovan 277 MCI Worldcom 278 1493/678 279 901 International Parkway 280 Richardson, Texas 75081 281 Email: steven.r.donovan@wcom.com 283 Matthew Cannon 284 MCI Worldcom 285 9514/107 286 2400 North Glenville Drive 287 Richardson, Texas 75082 288 Email: matt.cannon@wcom.com