idnits 2.17.1 draft-roach-mmusic-sip-pstn-require-header-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines == 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 84: '... document MUST provide for transpa...' RFC 2119 keyword, line 90: '...in this document SHOULD NOT behave in ...' RFC 2119 keyword, line 99: '...ny circumstances; however, they SHOULD...' RFC 2119 keyword, line 110: '...in this document MUST understand the m...' RFC 2119 keyword, line 116: '... this document MUST behave in such a...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Nodes which do not perform PSTN interworking are not required to generate packets of type "line" and "trunk," nor are they required to interpret any of the extended RTP payload signalling; however, they MUST not treat receipt of such packets as an error. -- 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.) -- The document date (January 2000) is 8868 days in the past. Is this intentional? 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: '9' is defined on line 330, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Adam Roach 2 Internet Draft Ericsson Inc. 3 Category: Standards Track June 1999 4 Expires January 2000 5 7 SIP PSTN Interworking Umbrella "Require:" Header 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To view the entire list of current Internet-Drafts, please check 32 the "1id-abstracts.txt" listing contained in the Internet-Drafts 33 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 34 (Northern Europe), ftp.nis.garr.it (Southern Europe), 35 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 36 ftp.isi.edu (US West Coast). 38 Abstract 40 This document outlines a new value for the SIP "Require:" header 41 which denotes compliance with a number of mechanisms necessary to 42 interwork smoothly with existing telephony networks. 44 1. Introduction 46 There have been a number of extensions to the SIP protocol ( ref 47 [1] ) proposed to provide smooth interoperation between SIP and 48 the PSTN network. Most of these are negotiated by means of 49 "Require:" and "Proxy-Require:" headers. 51 It has not yet been made clear which of these extensions are 52 expected to be supported by nodes which need to interoperate with 53 the PSTN. 55 Additionally, since each extension may add up to two additional 56 headers, and many calls involving interworking will be carrying 57 bodies with multiple payloads, the risk of overflowing an MTU 58 during UDP communications is becoming a potential problem. 60 This draft seeks to alleviate these problems by adding the 61 capability to imply a set of SIP extensions necessary for 62 fully-functional PSTN interworking with a single pair of 63 "Require" and "Proxy-Require" headers. 65 2. Included Features 67 The following sections outline the extensions required for 68 full-featured PSTN interworking and the rationale for their 69 inclusion. Note that some features do not apply to native SIP 70 clients, and only place requirements on those nodes which 71 interface with the existing telephony infrastructure. These 72 extensions are noted as appropriate. 74 2.1. Transparent Transit of ISUP messages 76 To provide users the ability to take advantage of the full range 77 of services afforded by the existing telephone network when 78 placing calls from PSTN to PSTN across a SIP network, SIP 79 messages will need to carry ISUP payloads from gateway to 80 gateway. 82 All nodes which serve as SIP/PSTN interworking points and 83 generate or accept the "Require:" header value defined in this 84 document MUST provide for transparent transmission of ISUP 85 messages in the body of SIP messages to trusted clients. This 86 behavior is outlined in "The application/ISUP media type" ( ref 87 [2] ) and "ISUP Parameters Expected in SIP Messages" ( ref [6] ). 89 Proxy servers which accept the "Proxy-Require:" header value 90 defined in this document SHOULD NOT behave in a way to preclude 91 the transmission of ISUP bodies; they should pass any ISUP bodies 92 through untouched. Exceptions include proxies which serve as 93 policy enforcement points between providers' networks or to 94 non-trusted clients. 96 UAC/UAS nodes which generate or accept the "Require:" header 97 value defined in this document but do not serve as PSTN 98 interworking points are not required to understand or generate 99 ISUP messages under any circumstances; however, they SHOULD 100 silently discard any ISUP bodies or body parts without generating 101 an error code. 103 2.2. Understanding of Multipart Bodies 105 In most PSTN interworking situations, the SIP body will be 106 required to carry session information in addition to ISUP and/or 107 billing information. 109 All nodes which generate or accept the "Require:" header value 110 defined in this document MUST understand the multipart body 111 extension defined in "The multipart/sip-id media type" ( ref [3] 112 ). Generation of SIP messages which are not multipart is, 113 however, still allowable. 115 Proxies which accept the "Proxy-Require:" header value defined in 116 this document MUST behave in such a way as to not preclude the 117 transmission of multipart bodies. 119 2.3. In-Band Transmission of DTMF information 121 Since the codec selected for voice transmission may not be 122 ideally suited for carrying DTMF information, a symbolic method 123 of transmitting this information in-band is necessary. 125 All nodes which generate or accept the "Require:" header value 126 defined in this document and have direct control over the audio 127 stream SHOULD be capable of generating in-band signalling 128 representing DTMF information as defined in "RTP Payload for DTMF 129 Digits, Telephony Tones and Telephony Signals" ( ref [4] ). 131 Nodes which do not perform PSTN interworking are not required to 132 generate packets of type "line" and "trunk," nor are they 133 required to interpret any of the extended RTP payload signalling; 134 however, they MUST not treat receipt of such packets as an error. 136 Nodes which do perform PSTN interworking SHOULD understand and 137 generate "tone," "line," and "trunk" payloads as defined in the 138 previously referenced document, when and if such payloads are 139 applicable. 141 Those nodes which do not have direct control over the audio 142 stream (e.g. media gateway controllers) have no requirements 143 placed on them by this section. 145 Media gateways may claim full compliance with this document if 146 they generate and understand "tone," "line," and "trunk" payloads 147 as defined in the previously referenced document. 149 2.4. Out-of-Band Transmission of DTMF information 151 In addition to the need to faithfully carry telephony tones 152 across the audio channel, PSTN interworking situations will 153 require the capability on the part of SIP nodes to collect 154 further digits from the end user. This may be used, for example, 155 to provide authentication information to a SIP node via DTMF. 157 All nodes which generate or accept the "Require:" header value 158 defined in this document and have direct control over the audio 159 stream SHOULD understand the SUBSCRIBE and NOTIFY extension 160 designed for transport of DTMF information. This document is not 161 yet written. 163 Proxy servers which accept the "Proxy-Require:" header value 164 defined in this document MUST either understand the SUBSCRIBE and 165 NOTIFY extensions mentioned above or allow SUBSCRIBE and NOTIFY 166 requests and responses to pass between endpoints. 168 2.5. Reliable Transmission of Provisional Responses 170 Since provisional messages, such as "180 Ringing," will probably 171 be used by most PSTN interworking implementations to trigger 172 generation of messages indicating that a complete address has 173 been collected, the reliable transmission of such messages is 174 very important to prevent calls from timing out during the setup 175 phase. 177 All nodes which generate or accept the "Require:" and/or 178 "Proxy-Require:" header values defined in this document MUST 179 implement the extension defined in "Reliability of Provisional 180 Responses in SIP" ( ref [7] ). 182 2.6. Provisional Media Streams 184 To allow the transmission of messages and tones before a final 185 connection has been established, SIP nodes which interwork with 186 the PSTN need to be able to establish temporary media connections 187 during this period. 189 All nodes which generate the "Require:" header values defined in 190 this document MUST support receipt of temporary provisional media 191 streams, as specified in "Provisional SIP Responses with Media" ( 192 ref [5] ). 194 All nodes which serve as SIP/PSTN interworking points and accept 195 the "Require:" header value defined in this document SHOULD 196 transmit provisional media streams whenever appropriate (e.g. to 197 deliver remote ring-tone). 199 2.7. Mandatory Provisional Responses 201 As previously mentioned, the transmission of provisional 202 responses serves an important role in PSTN interworking 203 situations. To this end, such responses are required to be used 204 consistently by clients. 206 All nodes which accept the "Require:" header value defined in 207 this document MUST generate a provisional response with a code 208 between 180 and 199 inclusive once it has determined that the 209 INVITE request contains sufficient information to uniquely 210 identify an end device. 212 2.8. Mid-Call Transactions Which do not Change SIP State 214 When interworking with PSTN, there are several situations when 215 PSTN nodes will need to send messages which do not correspond to 216 any SIP operations to each other across a SIP network. 218 To allow transit of such methods, proxies which accept the 219 "Proxy-Require:" header value defined in this document SHOULD 220 allow INFO messages to be carried between endpoints. Exceptions 221 include proxies which serve as policy enforcement points between 222 providers' networks or to non-trusted clients; if the proxy 223 elects to block transmission of the INFO message, it SHOULD 224 return "405 Method Not Allowed." 226 UAC/UAS nodes which generate or accept the "Require:" header 227 value defined in this document but do not serve as PSTN 228 interworking points are not required to generate or understand 229 INFO messages (in which case they may return "501 Not 230 Implemented"); however, they MUST NOT treat such messages as 231 fatal errors. 233 Nodes which do serve as PSTN interworking points SHOULD accept 234 "405 Method Not Allowed" and "501 Not Implemented" responses to 235 INFO requests as non-fatal. 237 2.9. Call Control Services 239 To facilitate the implementation of value-added services, many of 240 which require some degree of third party call control, units 241 which support PSTN interworking will also need to support basic 242 call control services. 244 All nodes which accept or generate the "Require:" header values 245 defined in this document MUST understand the extensions defined 246 in "SIP Call Control Services" ( ref [8] ). 248 3. "Require:" and "Proxy-Require:" Headers 250 The method for indicating protocol extensions is that described 251 in sections 6.28 and 6.30 of "SIP: Session Initiation Protocol" ( 252 ref [1] ). 254 Note that the headers defined in this document will be used 255 instead of, not in addition to, the "Require:" and 256 "Proxy-Require:" headers defined in the referenced documents. 258 3.1. Values 259 The header value defined for the purpose of denoting the need for 260 the above services is "org.ietf.sip.pstn-interwork". When using 261 the extensions described in this document, the client MUST 262 include the extension name in both a "Require:" and a 263 "Proxy-Require:" header for all INVITE requests. 265 3.2. Negotiation 267 If a server requires the extensions described in this document 268 but receives no appropriate "Require:" header from the client, it 269 SHOULD respond with a "403 Forbidden" response which contains a 270 "Warning:" header. The value of the warning code will be reserved 271 from the IANA at a later date. Clients understanding the warning 272 code SHOULD then automatically re-issue the INVITE request with 273 appropriate headers. 275 If a server supports but does not require the extensions defined 276 in this document and receives an INVITE which does not contain an 277 appropriate "Require:" header, it SHOULD include the above 278 mentioned "Warning:" header in all responses, including 100 and 279 200 class responses. 281 A client which supports but does not require the extensions 282 defined in this document will respond to any 100 or 200 class 283 messages containing the above mentioned "Warning:" header by 284 re-issuing the INVITE request with an appropriate set of 285 "Require:" and "Proxy-Require:" headers. The client MAY cache the 286 fact that a particular URI supports PSTN interworking extensions. 288 If, upon re-issuing the INVITE, the client receives a 420 289 response (e.g. from a proxy), it SHOULD re-issue the original 290 INVITE request. The client MAY cache the fact that the path to a 291 particular URI does not support PSTN interworking extensions. If 292 such information is not cached, the client MUST take other 293 precautions to ensure that it does not become locked in a loop 294 (e.g. INVITE, 403, INVITE, 200, INVITE, 403...). 296 4. References 298 [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: 299 Session Initiation Protocol", RFC 2543, IETF; March 1999. 301 [2] Christian Huitema, "The application/ISUP media type", 302 Internet Draft , IETF; 303 Feb. 1999. Work in progress. 305 [3] Christian Huitema, "The multipart/sip-id media type", 306 Internet Draft , 307 IETF; Feb. 1999. Work in progress. 309 [4] H. Schulzrinne/S Petrack, "RTP Payload for DTMF Digits, 310 Telephony Tones and Telephony Signals", Internet Draft 311 , IETF; June 1999. Work in progress. 313 [5] Adam Roach, "Provisional SIP Responses with Media", Internet 314 Draft , 315 IETF; June 1999. Work in progress. 317 [6] Adam Roach, "ISUP Parameters Expected in SIP Messages", 318 Internet Draft , 319 IETF; June 1999. Work in progress. 321 [7] J. Rosenberg/H. Schulzrinne, "Reliability of Provisional 322 Responses in SIP", Internet Draft 323 , IETF; May 1999. Work 324 in progress. 326 [8] H. Schulzrinne/J. Rosenberg, "SIP Call Control Services", 327 Internet Draft , IETF; 328 June/July 1999. Work in progress (not yet released). 330 [9] Steven R. Donovan, "The SIP INFO Method", Internet Draft 331 , IETF; Feb. 1999. 332 Work in progress. 334 5. Security Considerations 336 This memo adds no security considerations beyond those applicable 337 to the referenced documents. 339 6. Author's Address 341 Adam Roach 342 Ericsson Inc. 343 Mailstop L-04 344 851 International Pkwy. 345 Richardson, TX 75081 346 USA 347 Phone: 972-583-7594 348 Fax: 972-669-0154 349 E-Mail: adam.roach@ericsson.com