draft-roach-mmusic-sip-pstn-require-header-00.txt

Internet Engineering Task Force                               Adam Roach
Internet Draft                                             Ericsson Inc.
Category: Standards Track                                      June 1999
                                                    Expires January 2000
                     <draft-roach-mmusic-sip-pstn-require-header-00.txt>


            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."

     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 <draft-ietf-sigtran-mime-isup-00.txt>, IETF;
         Feb. 1999. Work in progress.

     [3] Christian Huitema, "The multipart/sip-id media type",
         Internet Draft <draft-ietf-mmusic-sip-multipart-00.txt>,
         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-avt-tones-01.txt>, IETF; June 1999. Work in progress.

     [5] Adam Roach, "Provisional SIP Responses with Media", Internet
         Draft <draft-roach-mmusic-sip-provisional-media-00.txt>,
         IETF; June 1999. Work in progress.

     [6] Adam Roach, "ISUP Parameters Expected in SIP Messages",
         Internet Draft <draft-roach-sip-isup-parameters-00.txt>,
         IETF; June 1999. Work in progress.

     [7] J. Rosenberg/H. Schulzrinne, "Reliability of Provisional
         Responses in SIP", Internet Draft
         <draft-ietf-mmusic-sip-100rel-01.txt>, IETF; May 1999. Work
         in progress.

     [8] H. Schulzrinne/J. Rosenberg, "SIP Call Control Services",
         Internet Draft <draft-ietf-mmusic-sip-cc-01.txt>, IETF;
         June/July 1999. Work in progress (not yet released).

     [9] Steven R. Donovan, "The SIP INFO Method", Internet Draft
         <draft-ietf-mmusic-sip-info-method-00.txt>, 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]