Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6230


Media Control Channel Framework

Part 3 of 3, p. 36 to 49
Prev RFC Part


prevText      Top      Up      ToC       Page 36 
12.  Security Considerations

   The Channel Framework provides confidentiality and integrity for the
   messages it transfers.  It also provides assurances that the
   connected host is the host that it meant to connect to and that the
   connection has not been hijacked, as discussed in the remainder of
   this section.

   In design, the Channel Framework complies with the security-related
   requirements documented in "Media Server Control Protocol
   Requirements" [RFC5167] -- more specifically, REQ-MCP-11, REQ-MCP-12,
   REQ-MCP-13, and REQ-MCP-14.  Specific security measures employed by
   the Channel Framework are summarized in the following sub-sections.

12.1.  Session Establishment

   Channel Framework sessions are established as media sessions
   described by SDP within the context of a SIP INVITE dialog.  In order
   to ensure secure rendezvous between Control Framework clients and
   servers, the Media Channel Control Framework should make full use of
   mechanisms provided by SIP.  The use of the 'cfw-id' SDP attribute
   results in important session information being carried across the SIP
   network.  For this reason, SIP clients using this specification MUST
   use appropriate security mechanisms, such as TLS [RFC5246] and SMIME
   [RFC5751], when deployed in open networks.

12.2.  Transport-Level Protection

   When using only TCP connections, the Channel Framework security is
   weak.  Although the Channel Framework requires the ability to protect
   this exchange, there is no guarantee that the protection will be used
   all the time.  If such protection is not used, anyone can see data

   Sensitive data, such as private and financial data, is carried over
   the Control Framework channel.  Clients and servers must be properly
   authenticated/authorized and the Control Channel must permit the use
   of confidentiality, replay protection, and integrity protection for
   the data.  To ensure Control Channel protection, Control Framework
   clients and servers MUST support TLS and SHOULD use it by default

Top      Up      ToC       Page 37 
   unless alternative Control Channel protection is used or a protected
   environment is guaranteed by the administrator of the network.
   Alternative Control Channel protection MAY be used if desired (e.g.,
   IPsec [RFC5246]).

   TLS is used to authenticate devices and to provide integrity, replay
   protection, and confidentiality for the header fields being
   transported on the Control Channel.  Channel Framework elements MUST
   implement TLS and MUST also implement the TLS ClientExtendedHello
   extended hello information for server name indication as described in
   [RFC5246].  A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA
   [RFC3261] MUST be supported.  Other cipher-suites MAY also be

   When a TLS client establishes a connection with a server, it is
   presented with the server's X.509 certificate.  Authentication
   proceeds as described in Section 7.3 ("Client Behavior") of RFC 5922

   A TLS server conformant to this specification MUST ask for a client
   certificate; if the client possesses a certificate, it will be
   presented to the server for mutual authentication, and authentication
   proceeds as described in Section 7.4 ("Server Behavior") of RFC 5922

12.3.  Control Channel Policy Management

   This specification permits the establishment of a dedicated Control
   Channel using SIP.  It is also permitted for entities to create
   multiple channels for the purpose of failover and redundancy.  As a
   general solution, the ability for multiple entities to create
   connections and have access to resources could be the cause of
   potential conflict in shared environments.  It should be noted that
   this document does not carry any specific mechanism to overcome such
   conflicts but will provide a summary of how to do so.

   It can be determined that access to resources and use of Control
   Channels relate to policy.  It can be considered implementation and
   deployment detail that dictates the level of policy that is adopted.
   The authorization and associated policy of a Control Channel can be
   linked to the authentication mechanisms described in this section.
   For example, strictly authenticating a Control Channel using TLS
   authentication allows entities to protect resources and ensure the
   required level of granularity.  Such policy can be applied at the
   package level or even as low as a structure like a conference
   instance (Control Channel X is not permitted to issue commands for
   Control Package y OR Control Channel A is not permitted to issue
   commands for conference instance B).  Systems should ensure that, if

Top      Up      ToC       Page 38 
   required, an appropriate policy framework is adopted to satisfy the
   requirements for implemented packages.  The most robust form of
   policy can be achieved using a strong authentication mechanism such
   as mutual TLS authentication on the Control Channel.  This
   specification provides a Control Channel response code (403) to
   indicate to the issuer of a command that it is not permitted.  The
   403 response MUST be issued to Control Framework requests that are
   not permitted under the implemented policy.  If a 403 response is
   received, a Control Framework client MAY choose to re-submit the
   request with differing requirements or to abandon the request.  The
   403 response does not provide any additional information on the
   policy failure due to the generic nature of this specification.
   Individual Control Packages can supply additional information if
   required.  The mechanism for providing such additional information is
   not mandated in this specification.  It should be noted that
   additional policy requirements to those covered in this section might
   be defined and applied in individual packages that specify a finer
   granularity for access to resources, etc.

13.  IANA Considerations

   IANA has created a new registry for SIP Control Framework parameters.
   The "Media Control Channel Framework Parameters" registry is a
   container for sub-registries.  This section further introduces sub-
   registries for control packages, method names, status codes, header
   field names, and port and transport protocol.

   Additionally, Section 13.6 registers a new MIME type for use with

   For all registries and sub-registries created by this document, the
   policy applied when creating a new registration is also applied when
   changing an existing registration.

13.1.  Control Packages Registration Information

   This specification establishes the Control Packages sub-registry
   under Media Control Channel Framework Packages.  New parameters in
   this sub-registry must be published in an RFC (either in the IETF
   stream or Independent Submission stream), using the IANA policy
   [RFC5226] "RFC Required".

   As this document specifies no package or template-package names, the
   initial IANA registration for Control Packages will be empty.  The
   remainder of the text in this section gives an example of the type of
   information to be maintained by the IANA.

Top      Up      ToC       Page 39 
   The table below lists the Control Packages defined in the "Media
   Control Channel Framework".

    Package Name      Reference
    ------------      ---------
    example1          [RFCXXXX]

13.1.1.  Control Package Registration Template

      Package Name:

          (Package names must conform to the syntax described in
          Section 8.1.)

      Published Specification(s):

          (Control Packages require an RFC.)

      Person & email address to contact for further information:

13.2.  Control Framework Method Names

   This specification establishes the Method Names sub-registry under
   Media Control Channel Framework Parameters and initiates its
   population as follows.  New parameters in this sub-registry must be
   published in an RFC (either in the IETF stream or Independent
   Submission stream).

    CONTROL - [RFC6230]
    REPORT  - [RFC6230]
    SYNC    - [RFC6230]
    K-ALIVE - [RFC6230]

   The following information MUST be provided in an RFC in order to
   register a new Control Framework method:

   o  The method name.

   o  The RFC number in which the method is registered.

13.3.  Control Framework Status Codes

   This specification establishes the Status Code sub-registry under
   Media Control Channel Framework Parameters.  New parameters in this
   sub-registry must be published in an RFC (either in the IETF stream
   or Independent Submission stream).  Its initial population is defined
   in Section 9.  It takes the following format:

Top      Up      ToC       Page 40 
    Code Description Reference

   The following information MUST be provided in an RFC in order to
   register a new Control Framework status code:

   o  The status code number.

   o  The RFC number in which the method is registered.

   o  A brief description of the status code.

13.4.  Control Framework Header Fields

   This specification establishes the Header Field sub-registry under
   Media Control Channel Framework Parameters.  New parameters in this
   sub-registry must be published in an RFC (either in the IETF stream
   or Independent Submission stream).  Its initial population is defined
   as follows:

      Control-Package - [RFC6230]
      Status - [RFC6230]
      Seq - [RFC6230]
      Timeout - [RFC6230]
      Dialog-ID - [RFC6230]
      Packages - [RFC6230]
      Supported - [RFC6230]
      Keep-Alive - [RFC6230]
      Content-Type - [RFC6230]
      Content-Length - [RFC6230]

   The following information MUST be provided in an RFC in order to
   register a new Channel Framework header field:

   o  The header field name.

   o  The RFC number in which the method is registered.

13.5.  Control Framework Port

   The Control Framework uses TCP port 7563, from the "registered" port
   range.  Usage of this value is described in Section 4.1.

13.6.  Media Type Registrations

   This section describes the media types and names associated with
   payload formats used by the Control Framework.  The registration uses
   the templates defined in [RFC4288].  It follows [RFC4855].

Top      Up      ToC       Page 41 
13.6.1.  Registration of MIME Media Type application/cfw

    Type name: application

    Subtype name: cfw

    Required parameters: None

    Optional parameters: None

    Encoding considerations: Binary and see Section 4 of RFC 6230

    Security considerations: See Section 12 of RFC 6230

    Interoperability considerations:
       Endpoints compliant to this specification must
       use this MIME type.  Receivers who cannot support
       this specification will reject using appropriate
       protocol mechanism.

    Published specification: RFC 6230

    Applications that use this media type:
       Applications compliant with Media Control Channels.

     Additional Information:
       Magic number(s): (none)
       File extension(s): (none)
       Macintosh file type code(s): (none)

    Person & email address to contact for further information:
       Chris Boulton <>

    Intended usage: COMMON

    Restrictions on usage:
       Should be used only in conjunction with this specification,
       RFC 6230.

    Author: Chris Boulton

    Change controller:
       IETF MEDIACTRL working group, delegated from the IESG.

Top      Up      ToC       Page 42 
13.6.2.  Registration of MIME Media Type application/

    Type name:  application

    Subtype name:  framework-attributes+xml

    Required parameters:  (none)

    Optional parameters: Same as charset parameter of application/xml as
       specified in RFC 3023 [RFC3023].

    Encoding considerations:  Same as encoding considerations of
       application/xml as specified in RFC 3023 [RFC3023].

    Security considerations:  No known security considerations outside
       of those provided by core Media Control Channel Framework.

    Interoperability considerations:  This content type provides common
       constructs for related Media Control Channel packages.

    Published specification:  RFC 6230

    Applications that use this media type:  Implementations of
       appropriate Media Control Channel packages.

    Additional information:
       Magic number(s): (none)
       File extension(s): (none)
       Macintosh file type code(s): (none)

    Person & email address to contact for further information:
       Chris Boulton <>

    Intended usage:  LIMITED USE

    Author/Change controller:  The IETF

    Other information:  None.

13.7.  'cfw-id' SDP Attribute

   Contact name:          Chris Boulton <>

   Attribute name:        "cfw-id".

   Type of attribute      Media level.

Top      Up      ToC       Page 43 
   Subject to charset:    Not.

   Purpose of attribute:  The 'cfw-id' attribute indicates an
      identifier that can be used to correlate the Control Channel with
      the SIP INVITE dialog used to negotiate it, when the attribute
      value is used within the Control Channel.

   Allowed attribute values:  A token.

13.8.  URN Sub-Namespace for

   IANA has registered a new XML namespace,
   "urn:ietf:params:xml:ns:control:framework-attributes", per the
   guidelines in RFC 3688 [RFC3688].

  URI: urn:ietf:params:xml:ns:control:framework-attributes

  Registrant Contact: IETF MEDIACTRL working group <>,
     Chris Boulton <>.


     <?xml version="1.0"?>
     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
      <html xmlns="" xml:lang="en">
        <title>Media Control Channel attributes</title>
        <h1>Namespace for Media Control Channel attributes</h1>
          <p>See <a href="">
             RFC 6230</a>.</p>

13.9.  XML Schema Registration

   This section registers an XML schema as per the guidelines in RFC
   3688 [RFC3688].

  URI:  urn:ietf:params:xml:ns:control:framework-attributes

Top      Up      ToC       Page 44 
  Registrant Contact: IETF MEDIACTRL working group <>,
     Chris Boulton <>.

  Schema:  The XML for this schema can be found in Appendix A.1 of this

14.  Contributors

   Asher Shiratzky from Radvision provided valuable support and
   contributions to the early versions of this document.

15.  Acknowledgments

   The authors would like to thank Ian Evans of Avaya, Michael
   Bardzinski and John Dally of NS-Technologies, Adnan Saleem of
   Radisys, and Dave Morgan for useful review and input to this work.
   Eric Burger contributed to the early phases of this work.

   Expert review was also provided by Spencer Dawkins, Krishna Prasad
   Kalluri, Lorenzo Miniero, and Roni Even.  Hadriel Kaplan provided
   expert guidance on the dialog association mechanism.  Lorenzo Miniero
   has constantly provided excellent feedback based on his work.

   Ben Campbell carried out the RAI expert review on this document and
   provided a great deal of invaluable input.  Brian Weis carried out a
   thorough security review.  Jonathan Lennox carried out a thorough SDP
   review that provided some excellent modifications.  Text from Eric
   Burger was used in the introduction in the explanation for using SIP.

16.  References

16.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  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.

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, June 2002.

Top      Up      ToC       Page 45 
   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, October 2002.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4574]  Levin, O. and G. Camarillo, "The Session Description
              Protocol (SDP) Label Attribute", RFC 4574, August 2006.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, February 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

Top      Up      ToC       Page 46 
   [RFC5922]  Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
              Certificates in the Session Initiation Protocol (SIP)",
              RFC 5922, June 2010.

16.2.  Informative References

              Burger, E., "Media Server Control Language and Protocol
              Thoughts", Work in Progress, June 2006.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, April 2004.

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [RFC5125]  Taylor, T., "Reclassification of RFC 3525 to Historic",
              RFC 5125, February 2008.

   [RFC5167]  Dolly, M. and R. Even, "Media Server Control Protocol
              Requirements", RFC 5167, March 2008.

   [RFC5626]  Jennings, C., Mahy, R., and F. Audet, "Managing Client-
              Initiated Connections in the Session Initiation Protocol
              (SIP)", RFC 5626, October 2009.

Top      Up      ToC       Page 47 
Appendix A.  Common Package Components

   During the creation of the Control Framework, it has become clear
   that there are a number of components that are common across multiple
   packages.  It has become apparent that it would be useful to collect
   such reusable components in a central location.  In the short term,
   this appendix provides the placeholder for the utilities, and it is
   the intention that this section will eventually form the basis of an
   initial 'Utilities Document' that can be used by Control Packages.

A.1.  Common Dialog/Multiparty Reference Schema

   The following schema provides some common attributes for allowing
   Control Packages to apply specific commands to a particular SIP media
   dialog (also referred to as "Connection") or conference.  If used
   within a Control Package, the Connection and multiparty attributes
   will be imported and used appropriately to specifically identify
   either a SIP dialog or a conference instance.  If used within a
   package, the value contained in the 'connectionid' attribute MUST be
   constructed by concatenating the 'Local' and 'Remote' SIP dialog
   identifier tags as defined in [RFC3261].  They MUST then be separated
   using the ':' character.  So the format would be:

               'Local Dialog tag' + ':' + 'Remote Dialog tag'

   As an example, for an entity that has a SIP Local dialog identifier
   of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the
   'connectionid' attribute for a Control Framework command would be:


   It should be noted that Control Framework requests initiated in
   conjunction with a SIP dialog will produce a different 'connectionid'
   value depending on the directionality of the request; for example,
   Local and Remote tags are locally identifiable.

   As with the Connection attribute previously defined, it is useful to
   have the ability to apply specific Control Framework commands to a
   number of related dialogs, such as a multiparty call.  This typically
   consists of a number of media dialogs that are logically bound by a
   single identifier.  The following schema allows for Control Framework
   commands to explicitly reference such a grouping through a
   'conferenceid' XML container.  If used by a Control Package, any
   control XML referenced by the attribute applies to all related media
   dialogs.  Unlike the dialog attribute, the 'conferenceid' attribute
   does not need to be constructed based on the overlying SIP dialog.
   The 'conferenceid' attribute value is system specific and should be
   selected with relevant context and uniqueness.

Top      Up      ToC       Page 48 
   It should be noted that the values contained in both the
   'connectionid' and 'conferenceid' identifiers MUST be compared in a
   case-sensitive manner.

   The full schema follows:

 <?xml version="1.0" encoding="UTF-8"?>

   elementFormDefault="qualified" attributeFormDefault="unqualified">

        <xsd:attributeGroup name="framework-attributes">
              SIP Connection and Conf Identifiers

          <xsd:attribute name="connectionid" type="xsd:string"/>

          <xsd:attribute name="conferenceid" type="xsd:string"/>


Top      Up      ToC       Page 49 
Authors' Addresses

   Chris Boulton


   Tim Melanchuk


   Scott McGlashan
   Gustav III:s boulevard 36
   SE-16985 Stockholm, Sweden