[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 5009

Network Working Group                                    Richard Ejzak
INTERNET-DRAFT                                     Lucent Technologies
                                                     February 15, 2005


      Private Header (P-Header) Extension to the Session Initiation
             Protocol (SIP) for Authorization of Early Media
                  <draft-ejzak-sipping-p-em-auth-00.txt>


Status of this memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This document is a submission of the IETF AVT WG.  Comments should
   be directed to the AVT WG mailing list, avt@ietf.org.

Abstract

   This document describes a private Session Initiation Protocol (SIP)
   header (P-header) to be used by the European Telecommunications
   Standards Institute (ETSI) Telecommunications and Internet converged
   Services and Protocols for Advanced Networks (TISPAN) for the
   purpose of authorizing early media flows in Third Generation
   Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This
   header is useful in any SIP network that is interconnected with
   other SIP networks and needs to control the flow of media in the
   early dialog state.





Ejzak                                                         [Page 1]

INTERNET-DRAFT          P-Early-Media-Auth Header    February 15, 2005



Table of Contents

1. Introduction....................................................2
2. Applicability Statement.........................................3
3. Conventions and Acronyms........................................3
4. Background on early media authorization.........................4
  4.1. Backward early media ......................................4
  4.2. Forward early media .......................................5
5. Applicability of RFC 3959 and RFC 3960..........................6
6. Overview of Operation...........................................6
7. The P-Early-Media header........................................7
  7.1. Procedures at the User Agent Server........................8
  7.2. Procedures at the proxy....................................8
  7.3. Procedures at the User Agent Client........................8
8. Formal syntax...................................................8
9. Security Considerations.........................................9
10. Acknowledgements...............................................9
11. References.....................................................9
  11.1. Normative References......................................9
  11.2. Informative References...................................10
12. Authors' Addresses............................................10
13. IPR Notice....................................................10
14. Copyright Notice..............................................11


1. Introduction

   This document defines the use of the P-Early-Media header for use
   within SIP [1] provisional responses in certain SIP networks to
   authorize the cut-through of backward and/or forward early media.
   The P-Early-Media header is intended for use in a SIP network, such
   as a 3GPP IMS, that prohibits the exchange of early media between
   end users, that includes several Public Switched Telephone Network
   (PSTN) gateways with which an end user may exchange certain early
   media, that is interconnected with other SIP networks that have
   unknown, untrusted or different policies regarding early media, and
   that has the capability to "gate" (enable/disable) the flow of early
   media to/from user equipment.

   Within an isolated SIP network it is possible to gate early media
   associated with all endpoints within the network to enforce a
   desired early media policy among network endpoints.  However, when a
   SIP network is interconnected with other SIP networks, only the
   boundary node connected to the external network can determine which
   early media policy to apply to a session established between
   endpoints on different sides of the boundary.  The P-Early-Media
   header provides a means for this boundary node to communicate this
   early media policy decision to other nodes within the network.





Ejzak                                                         [Page 2]

INTERNET-DRAFT          P-Early-Media-Auth Header    February 15, 2005


2. Applicability Statement

   The use of this extension is only applicable inside a 'Trust Domain'
   as defined in RFC 3325 [9].  Nodes in such a Trust Domain are
   explicitly trusted by its users and end-systems to authorize early
   media requests only when allowed by early media policy within the
   Trust Domain.

   This document does NOT offer a general early media authorization
   model suitable for inter-domain use or use in the Internet at large.
   Furthermore, since the early media requests are not
   cryptographically certified, they are subject to forgery, replay,
   and falsification in any architecture that does not meet the
   requirements of the Trust Domain.

   An early media request also lacks an indication of who specifically
   is making or modifying the request, and so it must be assumed that
   the Trust Domain is making the request.  Therefore, the information
   is only meaningful when securely received from a node known to be a
   member of the Trust Domain.

   Despite these limitations, there are sufficiently useful specialized
   deployments that meet the assumptions described above, and can
   accept the limitations that result, to warrant publication of this
   mechanism.  An example deployment would be a closed network that
   emulates a traditional circuit switched telephone network.



3. Conventions and Acronyms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [1].

   The following acronyms are used in this document:

      3GPP   - the Third Generation Partnership Project
      ABNF   - Augmented Backus-Naur Form
      DTMF   - Dual Tone Multi-Frequency
      ETSI   - European Telecommunications Standards Institute
      IMS    - Internet Protocol Multimedia Subsystem
      MIME   - Multipurpose Internet Mail Extensions
      PSTN   - Public Switched Telephone Network
      SDP    - Session Description Protocol
      SIP    - Session Initiation Protocol
      TISPAN - Telecommunications and Internet converged Services and
               Protocols for Advanced Networks
      UA     - User Agent
      UAC    - User Agent Client
      UAS    - User Agent Server



Ejzak                                                         [Page 3]

INTERNET-DRAFT          P-Early-Media-Auth Header    February 15, 2005




4. Background on early media authorization

   PSTN networks typically provide call progress information as
   backward early media from the terminating switch towards the calling
   party.  In a SIP network, backward early media flows from the User
   Agent Server (UAS) towards the User Agent Client (UAC).  PSTN
   networks also use forward early media from the calling party towards
   the terminating switch under some circumstances for applications
   such as digit collection for secondary dialing. In a SIP network,
   forward early media flows from the UAC towards the UAS.

   PSTN networks typically allow backward and/or forward early media
   since they are used for the purpose of progressing the call to the
   answer state and do not involve the exchange of data between
   endpoints. On the other hand, a SIP network may have a policy to
   prohibit backward early media from SIP user equipment and to
   prohibit forward media towards SIP user equipment, either of which
   may contain user data. A SIP network containing both PSTN gateways
   and SIP end devices can maintain such an early media policy by
   gating off any early media with a SIP end device acting as UAS,
   gating on early media with a SIP end device acting as UAC, and
   appropriately gating early media at each PSTN gateway.
   Unfortunately, a SIP network interconnected with another SIP network
   may have no means of assuring that the interconnected network is
   implementing a compatible early media policy.

   Without this extension, a SIP network interconnected with other SIP
   networks provides no mechanism for an originating SIP endpoint
   within the network, be it a PSTN gateway or SIP user equipment, from
   identifying if the terminating SIP endpoint, which may be located
   outside the network, is a SIP endpoint (such as a PSTN gateway) that
   is authorized to either send backward early media or to receive
   forward early media.


4.1. Backward early media

   Backward early media in the PSTN typically comprises call progress
   information such as ringing, or announcements regarding special
   handling such as forwarding.  It may also include requests for
   further information, such as a credit card number to be entered as
   forward early media in the form of Dual Tone Multi-Frequency (DTMF)
   tones or speech. Backward early media of this type provides
   information to the calling party strictly for the purpose of
   progressing the call and involves no exchange of data between end
   users.  The usual PSTN charging policy assumes that no data is
   exchanged between users until the call has been answered.





Ejzak                                                         [Page 4]

INTERNET-DRAFT          P-Early-Media-Auth Header    February 15, 2005


   A terminating SIP User Agent (UA) outside of the SIP network, on the
   other hand, may provide any user data in a backward early media
   stream.  Thus if the network implements the usual early media
   policy, the network equipment gating the backward early media flow
   for the originating UA must distinguish between authorized early
   media from a terminating SIP endpoint such as a PSTN gateway, and
   unauthorized early media from another SIP device outside of the
   network.  Given the assumption of a transitive trust relationship
   between SIP servers in the network, this can be accomplished by
   including some information in a backward SIP message that identifies
   the presence of authorized backward early media.  Since it is
   necessary to verify that this indication comes from a trusted
   source, it is necessary for each server on the path back to the
   originating UA be able to verify the trust relationship with the
   previous server and to remove such an indication when it cannot do
   so.  A server on the boundary to an untrusted SIP network can assure
   that no indication of authorized backward early media passes from an
   external UAS to a UAC within the network.  Thus the use of a private
   header that can be modified by SIP proxies is to be preferred over
   the use of a Multipurpose Internet Mail Extensions (MIME) attachment
   that cannot be modified in this way.


4.2. Forward early media

   Forward early media is less common than backward early media in the
   PSTN.  It is typically used to collect secondary dialed digits, to
   collect credit card numbers, or to collect other DTMF or speech
   responses for the purpose of further directing the call.  Forward
   early media in the PSTN is always directed toward a network server
   for the purpose of progressing a call and involves no exchange of
   data between end users.  The usual PSTN charging policy assumes that
   no data is exchanged between users until the call has been answered.

   A terminating SIP UA outside of the SIP network, on the other hand,
   may receive any user data in a forward early media stream, thus if
   the network implements the usual early media policy, the network
   equipment gating the forward early media flow for the originating UA
   must distinguish between a terminating endpoint such as a PSTN
   gateway that is authorized to receive forward early media, and
   another SIP device outside of the network that is not authorized to
   receive forward early media containing user data.  Given the
   assumption of a transitive trust relationship between SIP servers in
   the network, this can be accomplished by including some information
   in a backward SIP message that identifies that the terminating side
   is authorized to receive forward early media.  Since it is necessary
   to verify that this indication comes from a trusted source, it is
   necessary for each server on the path back to the originating UA be
   able to verify the trust relationship with the previous server and
   to remove such an indication when it cannot do so.  A server on the
   boundary to an untrusted SIP network can assure that no indication



Ejzak                                                         [Page 5]

INTERNET-DRAFT          P-Early-Media-Auth Header    February 15, 2005


   of forward early media authorization passes from an external UAS to
   a UAC within the network.  Thus the use of a private header that can
   be modified by SIP proxies is to be preferred over the use of a MIME
   attachment that cannot be modified in this way.


5. Applicability of RFC 3959 and RFC 3960

   The private header extension defined in this document is applicable
   to the gateway model defined in RFC 3960 [7], since the PSTN gateway
   is the primary requestor of early media in an IMS.  For the same
   reason, neither the application server model of RFC 3960, nor the
   early session disposition type defined in RFC 3959 [6] is
   applicable.

   The gateway model of RFC 3960 [7] allows for individual networks to
   create local policy with respect to the handling of early media, but
   does not address the case where a network is interconnected with
   other networks with unknown, untrusted or different early media
   policies.  Without the kind of information in the P-Early-Media
   header, it is not possible for the network to determine whether cut-
   through of early media could lead to the transfer of data between
   end-users during session establishment.

   Thus the private header extension in this document is a natural
   extension of the gateway model of RFC 3960 [7] that is applicable
   within a transitive trust domain.


6. Overview of Operation

   We define a new P-Early-Media header field for the purpose of
   requesting and authorizing requests for backward and/or forward
   early media.  A UAS requesting backward and/or forward early media
   will include the P-Early-Media header in a 18X provisional response
   to an incoming INVITE request, including a direction parameter that
   identifies whether the early media request is for backward media,
   forward media, both or neither.  The UAS may change its request for
   early media by including a modified P-Early-Media header in a
   subsequent 18X provisional response to the INVITE request.

   The UAS may be a PSTN gateway providing in-band call progress
   information in the backward direction, or a network server
   requesting the input of a digit string as DTMF in the forward
   direction.

   As members of the Trust Domain, each proxy in the network forwarding
   the 18X response has the responsibility for assuring that the early
   media request comes from an authorized source.  If a P-Early-Media
   header arrives from either an untrusted source, a source not allowed
   to send backward early media, or a source not allowed to receive



Ejzak                                                         [Page 6]

INTERNET-DRAFT          P-Early-Media-Auth Header    February 15, 2005


   forward early media, then the proxy may remove the P-Early-Media
   header or alter the direction parameter of the P-Early-Media header
   before forwarding the 18X response, based on local policy.  A proxy
   will typically authorize an early media request from a PSTN gateway,
   and disallow an early media request from user equipment or from an
   untrusted network.

   If the proxy also performs gating of early media, then it uses the
   direction parameter of the P-Early-Media header to gate on/off
   backward and/or forward early media flow between the UAs.

   If the UAC is a PSTN gateway, then the UAC uses the direction
   parameter of the P-Early-Media header in the 18X provisional
   response to perform early media gating or cut-through and to decide
   whether or not to render backward early media in preference to
   generating ringback based on the receipt of a 180 Ringing response.

   If the UAC is associated with user equipment, then the network will
   have assigned a proxy the task of performing early media gating, so
   that the direction parameter of the P-Early-Media header received at
   such a UAC does not police the early media flow, but does provide
   additional information that the UAC may use to render media.



7. The P-Early-Media header

   The P-Early-Media header MAY be included in any 18X provisional
   response to the INVITE request for the purpose of requesting the
   authorization of early media.  The P-Early-Media header includes a
   single parameter "direction" that has one of the following values:
   "sendrecv", "sendonly", "recvonly", or "inactive", following the
   convention used for Session Description Protocol (SDP) [10] stream
   directionality.  The value sendrecv indicates a request for
   authorization of early media both from the UAS towards the UAC and
   from the UAC towards the UAS (both backward and forward early
   media).  The value sendonly indicates a request for authorization of
   early media from the UAS towards the UAC (backward early media), and
   not in the other direction.  The value recvonly indicates a request
   for authorization of early media from the UAC towards the UAS
   (forward early media), and not in the other direction.  The value
   inactive indicates either a request that no early media be
   authorized or a request for revocation of authorization of
   previously authorized early media.  In networks using the P-Early-
   Media header, the default behavior in the absence of the header is
   either to request that no early media be authorized (in the absence
   of any previous early media authorization request) or to leave
   unchanged any previous early media authorization within the session.






Ejzak                                                         [Page 7]

INTERNET-DRAFT          P-Early-Media-Auth Header    February 15, 2005


   The P-Early-Media header is optional in any 18X provisional response
   to the INVITE request, and may be freely altered or deleted by any
   proxy.

7.1. Procedures at the User Agent Server

   A User Agent Server that is requesting authorization to send or
   receive early media MAY insert a P-Early-Media header with
   appropriate direction value in any 18X provisional response to the
   INVITE request.  A User Agent Server MAY request changes in early
   media authorization by inserting a P-Early-Media header with
   appropriate direction value in any subsequent 18X provisional
   response to the INVITE request.


7.2. Procedures at the proxy

   To authorize or deny early media authorization requests, a proxy MAY
   modify or remove a P-Early-Media header in any 18X provisional
   response to an INVITE request, depending on the trust relationship
   with the server sending or forwarding the 18X response.  In
   addition, if the proxy controls the gating of early media in both
   directions for the User Agent Client, it SHALL use the contents of
   the P-Early-Media header to gate the early media according to the
   definition of the direction parameter defined in clause 7.


7.3. Procedures at the User Agent Client

   A User Agent Client receiving a P-Early-Media header in a 18X
   provisional response to an INVITE request MAY use the direction
   parameter of the header to gate or cut-through early media, and to
   decide whether to render early media from the UAS to the UAC in
   preference to any locally generated ringback triggered by a 180
   Ringing response.  If a proxy is providing the early media gating
   function for the User Agent Client, then the gateway model of RFC
   3960 [7] for rendering of early media is applicable.

   The User Agent Client associated with a PSTN gateway in an IMS does
   not have a proxy configured to perform early media gating, so it
   needs to perform early media gating on its own.  A User Agent Client
   without a proxy in the network performing early media gating that
   receives a P-Early-Media header in a 18x provisional response to an
   INVITE request SHOULD perform gating or cut-through of early media
   according to the direction parameter of the header.  Such a User
   Agent Client MAY also use the direction parameter to decide whether
   to render early media from the UAS to the UAC in preference to any
   locally generated ringback triggered by a 180 Ringing response.


8. Formal syntax



Ejzak                                                         [Page 8]

INTERNET-DRAFT          P-Early-Media-Auth Header    February 15, 2005



   This syntax of the P-Early-Media header is described below in ABNF
   according to RFC 4234 [8], as an extention to the ABNF for SIP in
   RFC 3261 [1].

      P-Early-Media = "P-Early-Media" HCOLON em-direction
      em-direction  = "sendrecv" / "sendonly" / "recvonly" / "inactive"


9. Security Considerations

   There are no confidentiality concerns associated with the P-Early-
   Media header.  It is desirable to maintain the integrity of the
   direction parameter in the header across each hop between servers to
   avoid the potential for unauthorized use of early media.  It is
   assumed that the P-Early-Media header is used within the context of
   the 3GPP IMS trust domain or a similar trust domain, consisting of a
   collection of SIP servers maintaining pairwise security
   associations.  In an IMS it is only necessary to police the use of
   the P-Early-Media header at the boundary to user equipment served by
   the network and at the boundary to peer networks.  It is assumed
   that boundary servers in the IMS will have local policy for the
   treatment of the P-Early-Media header as it is sent to or received
   from any possible server external to the network.  Since boundary
   servers are free to modify or remove any P-Early-Media header in SIP
   messages forwarded across the boundary, the integrity of the P-
   Early-Media header can be verified to the extent that the
   connections to external servers are secured.  The authenticity of
   the P-Early-Media header can only be assured to the extent that the
   external servers are trusted to police the authenticity of the
   header.


10. Acknowledgements

   The author would like to thank Miguel Garcia-Martin, Jan Holm,
   Sebastien Garcin, Akira Kurokawa, Erick Sasaki, James Calme, and
   Greg Tevonian for their significant contributions made throughout
   the writing and reviewing of this document.


11. References

11.1. Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.
   [2]  3GPP “TS 23.228: IP Multimedia Subsystem (IMS); Stage 2
        (Release 7)”, 3GPP 23.228, September 2005,
        ftp://ftp.3gpp.org/Specs/archive/23-series/23.228/.



Ejzak                                                         [Page 9]

INTERNET-DRAFT          P-Early-Media-Auth Header    February 15, 2005


   [3]  3GPP “TS 24.229: IP Multimedia Call Control Protocol based on
        SIP and SDP; Stage 3 (Release 7)”, 3GPP 24.229, September 2005,
        ftp://ftp.3gpp.org/Specs/archive/24-series/24.229/.
   [4]  3GPP “TS 32.200: Telecommunication Management; Charging
        management; Charging principles (Release 7)”, 3GPP 32.200,
        September 2005, ftp://ftp.3gpp.org/Specs/archive/32-
        series/32.200/.
   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.
   [6]  Camarillo, G., “The Early Session Disposition Type for the
        Session Initiation Protocol (SIP)”, RFC 3959, December 2004.
   [7]  Camarillo, G., “Early Media and Ringing Tone Generation in the
        Session Initiation Protocol (SIP)”, RFC 3960, December 2004.
   [8]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.
   [9]  Jennings, C., Peterson, J. and Watson, M., ”Private Extensions
        to the Session Initiation Protocol (SIP) for Asserted Identity
        within Trusted Networks”, RFC 3325, November 2002.
   [10] Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.
11.2. Informative References

   [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.
   [12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", STD 64,
        RFC 3550, July 2003.
   [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
        Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

   ETSI documents can be downloaded from the ETSI web server,
   http://www.etsi.org/".  Any 3GPP document can be downloaded from the
   3GPP webserver, "http://www.3gpp.org/", see specifications.


12. Authors' Addresses

   Richard Ejzak
   Lucent Technologies
   1960 Lucent Lane
   Naperville, IL 60566, USA

   Phone:   +1 630 979 7036
   EMail: ejzak@lucent.com


13. IPR Notice

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described



Ejzak                                                        [Page 10]

INTERNET-DRAFT          P-Early-Media-Auth Header    February 15, 2005


   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


14. Copyright Notice

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   This Internet-Draft expires in August 2006.


RFC Editor Considerations

   - The RFC editor is requested to replace all occurances of XXXX
     with the RFC number this document receives.











Ejzak                                                        [Page 11]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/