Internet Engineering Task Force Adam Roach Internet Draft Ericsson Inc. Category: Standards Track June 1999 Expires January 2000 SIP PSTN Interworking Umbrella "Require:" Header Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 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/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document outlines a new value for the SIP "Require:" header which denotes compliance with a number of mechanisms necessary to interwork smoothly with existing telephony networks. 1. Introduction There have been a number of extensions to the SIP protocol ( ref [1] ) proposed to provide smooth interoperation between SIP and the PSTN network. Most of these are negotiated by means of "Require:" and "Proxy-Require:" headers. It has not yet been made clear which of these extensions are expected to be supported by nodes which need to interoperate with the PSTN. Additionally, since each extension may add up to two additional headers, and many calls involving interworking will be carrying bodies with multiple payloads, the risk of overflowing an MTU during UDP communications is becoming a potential problem. Roach [Page 1] Internet Draft June 1999 This draft seeks to alleviate these problems by adding the capability to imply a set of SIP extensions necessary for fully-functional PSTN interworking with a single pair of "Require" and "Proxy-Require" headers. 2. Included Features The following sections outline the extensions required for full-featured PSTN interworking and the rationale for their inclusion. Note that some features do not apply to native SIP clients, and only place requirements on those nodes which interface with the existing telephony infrastructure. These extensions are noted as appropriate. 2.1. Transparent Transit of ISUP messages To provide users the ability to take advantage of the full range of services afforded by the existing telephone network when placing calls from PSTN to PSTN across a SIP network, SIP messages will need to carry ISUP payloads from gateway to gateway. All nodes which serve as SIP/PSTN interworking points and generate or accept the "Require:" header value defined in this document MUST provide for transparent transmission of ISUP messages in the body of SIP messages to trusted clients. This behavior is outlined in "The application/ISUP media type" ( ref [2] ) and "ISUP Parameters Expected in SIP Messages" ( ref [6] ). Proxy servers which accept the "Proxy-Require:" header value defined in this document SHOULD NOT behave in a way to preclude the transmission of ISUP bodies; they should pass any ISUP bodies through untouched. Exceptions include proxies which serve as policy enforcement points between providers' networks or to non-trusted clients. UAC/UAS nodes which generate or accept the "Require:" header value defined in this document but do not serve as PSTN interworking points are not required to understand or generate ISUP messages under any circumstances; however, they SHOULD silently discard any ISUP bodies or body parts without generating an error code. 2.2. Understanding of Multipart Bodies In most PSTN interworking situations, the SIP body will be required to carry session information in addition to ISUP and/or billing information. All nodes which generate or accept the "Require:" header value Roach [Page 2] Internet Draft June 1999 defined in this document MUST understand the multipart body extension defined in "The multipart/sip-id media type" ( ref [3] ). Generation of SIP messages which are not multipart is, however, still allowable. Proxies which accept the "Proxy-Require:" header value defined in this document MUST behave in such a way as to not preclude the transmission of multipart bodies. 2.3. In-Band Transmission of DTMF information Since the codec selected for voice transmission may not be ideally suited for carrying DTMF information, a symbolic method of transmitting this information in-band is necessary. All nodes which generate or accept the "Require:" header value defined in this document and have direct control over the audio stream SHOULD be capable of generating in-band signalling representing DTMF information as defined in "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals" ( ref [4] ). 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. Nodes which do perform PSTN interworking SHOULD understand and generate "tone," "line," and "trunk" payloads as defined in the previously referenced document, when and if such payloads are applicable. Those nodes which do not have direct control over the audio stream (e.g. media gateway controllers) have no requirements placed on them by this section. Media gateways may claim full compliance with this document if they generate and understand "tone," "line," and "trunk" payloads as defined in the previously referenced document. 2.4. Out-of-Band Transmission of DTMF information In addition to the need to faithfully carry telephony tones across the audio channel, PSTN interworking situations will require the capability on the part of SIP nodes to collect further digits from the end user. This may be used, for example, to provide authentication information to a SIP node via DTMF. All nodes which generate or accept the "Require:" header value defined in this document and have direct control over the audio stream SHOULD understand the SUBSCRIBE and NOTIFY extension Roach [Page 3] Internet Draft June 1999 designed for transport of DTMF information. This document is not yet written. Proxy servers which accept the "Proxy-Require:" header value defined in this document MUST either understand the SUBSCRIBE and NOTIFY extensions mentioned above or allow SUBSCRIBE and NOTIFY requests and responses to pass between endpoints. 2.5. Reliable Transmission of Provisional Responses Since provisional messages, such as "180 Ringing," will probably be used by most PSTN interworking implementations to trigger generation of messages indicating that a complete address has been collected, the reliable transmission of such messages is very important to prevent calls from timing out during the setup phase. All nodes which generate or accept the "Require:" and/or "Proxy-Require:" header values defined in this document MUST implement the extension defined in "Reliability of Provisional Responses in SIP" ( ref [7] ). 2.6. Provisional Media Streams To allow the transmission of messages and tones before a final connection has been established, SIP nodes which interwork with the PSTN need to be able to establish temporary media connections during this period. All nodes which generate the "Require:" header values defined in this document MUST support receipt of temporary provisional media streams, as specified in "Provisional SIP Responses with Media" ( ref [5] ). All nodes which serve as SIP/PSTN interworking points and accept the "Require:" header value defined in this document SHOULD transmit provisional media streams whenever appropriate (e.g. to deliver remote ring-tone). 2.7. Mandatory Provisional Responses As previously mentioned, the transmission of provisional responses serves an important role in PSTN interworking situations. To this end, such responses are required to be used consistently by clients. All nodes which accept the "Require:" header value defined in this document MUST generate a provisional response with a code between 180 and 199 inclusive once it has determined that the INVITE request contains sufficient information to uniquely Roach [Page 4] Internet Draft June 1999 identify an end device. 2.8. Mid-Call Transactions Which do not Change SIP State When interworking with PSTN, there are several situations when PSTN nodes will need to send messages which do not correspond to any SIP operations to each other across a SIP network. To allow transit of such methods, proxies which accept the "Proxy-Require:" header value defined in this document SHOULD allow INFO messages to be carried between endpoints. Exceptions include proxies which serve as policy enforcement points between providers' networks or to non-trusted clients; if the proxy elects to block transmission of the INFO message, it SHOULD return "405 Method Not Allowed." UAC/UAS nodes which generate or accept the "Require:" header value defined in this document but do not serve as PSTN interworking points are not required to generate or understand INFO messages (in which case they may return "501 Not Implemented"); however, they MUST NOT treat such messages as fatal errors. Nodes which do serve as PSTN interworking points SHOULD accept "405 Method Not Allowed" and "501 Not Implemented" responses to INFO requests as non-fatal. 2.9. Call Control Services To facilitate the implementation of value-added services, many of which require some degree of third party call control, units which support PSTN interworking will also need to support basic call control services. All nodes which accept or generate the "Require:" header values defined in this document MUST understand the extensions defined in "SIP Call Control Services" ( ref [8] ). 3. "Require:" and "Proxy-Require:" Headers The method for indicating protocol extensions is that described in sections 6.28 and 6.30 of "SIP: Session Initiation Protocol" ( ref [1] ). Note that the headers defined in this document will be used instead of, not in addition to, the "Require:" and "Proxy-Require:" headers defined in the referenced documents. 3.1. Values Roach [Page 5] Internet Draft June 1999 The header value defined for the purpose of denoting the need for the above services is "org.ietf.sip.pstn-interwork". When using the extensions described in this document, the client MUST include the extension name in both a "Require:" and a "Proxy-Require:" header for all INVITE requests. 3.2. Negotiation If a server requires the extensions described in this document but receives no appropriate "Require:" header from the client, it SHOULD respond with a "403 Forbidden" response which contains a "Warning:" header. The value of the warning code will be reserved from the IANA at a later date. Clients understanding the warning code SHOULD then automatically re-issue the INVITE request with appropriate headers. If a server supports but does not require the extensions defined in this document and receives an INVITE which does not contain an appropriate "Require:" header, it SHOULD include the above mentioned "Warning:" header in all responses, including 100 and 200 class responses. A client which supports but does not require the extensions defined in this document will respond to any 100 or 200 class messages containing the above mentioned "Warning:" header by re-issuing the INVITE request with an appropriate set of "Require:" and "Proxy-Require:" headers. The client MAY cache the fact that a particular URI supports PSTN interworking extensions. If, upon re-issuing the INVITE, the client receives a 420 response (e.g. from a proxy), it SHOULD re-issue the original INVITE request. The client MAY cache the fact that the path to a particular URI does not support PSTN interworking extensions. If such information is not cached, the client MUST take other precautions to ensure that it does not become locked in a loop (e.g. INVITE, 403, INVITE, 200, INVITE, 403...). 4. References [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, IETF; March 1999. [2] Christian Huitema, "The application/ISUP media type", Internet Draft , IETF; Feb. 1999. Work in progress. [3] Christian Huitema, "The multipart/sip-id media type", Internet Draft , IETF; Feb. 1999. Work in progress. Roach [Page 6] Internet Draft June 1999 [4] H. Schulzrinne/S Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", Internet Draft , IETF; June 1999. Work in progress. [5] Adam Roach, "Provisional SIP Responses with Media", Internet Draft , IETF; June 1999. Work in progress. [6] Adam Roach, "ISUP Parameters Expected in SIP Messages", Internet Draft , IETF; June 1999. Work in progress. [7] J. Rosenberg/H. Schulzrinne, "Reliability of Provisional Responses in SIP", Internet Draft , IETF; May 1999. Work in progress. [8] H. Schulzrinne/J. Rosenberg, "SIP Call Control Services", Internet Draft , IETF; June/July 1999. Work in progress (not yet released). [9] Steven R. Donovan, "The SIP INFO Method", Internet Draft , IETF; Feb. 1999. Work in progress. 5. Security Considerations This memo adds no security considerations beyond those applicable to the referenced documents. 6. Author's Address Adam Roach Ericsson Inc. Mailstop L-04 851 International Pkwy. Richardson, TX 75081 USA Phone: 972-583-7594 Fax: 972-669-0154 E-Mail: adam.roach@ericsson.com Roach [Page 7]