RFC 7082

Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP)

📅 published December 2013, from ietf

Part 1 of 2 💌

Bestie, this is RFC 7082 🎀

RFC 7082: Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP) ✨

This one's from the IETF 🌸. The authors are R. Shekh-Yusef (Avaya) and M. Barnes (Polycom). It's Informational, not a standards-track spec, and it was published in December 2013. The ISSN is 2070-1721. The title block lists no RFCs that it obsoletes or updates 💅.

Abstract ✨

Okay so the CCMP document, which is RFC 6503, lets a client find a conference control server that supports CCMP 🦋. The gap is that nothing lets a client already in a conference check whether the conference focus supports CCMP 😭. If a CCMP-enabled client could tell, it could join a conference over SIP, also register for the Centralized Conferencing (XCON) conference event package, and use CCMP operations on that conference. Iconic 👑.

This doc gives two mechanisms to fill that gap, depending on what the User Agent (UA) needs. The first uses the Call-Info header field. The second adds a new value for the "purpose" header field parameter in the <service-uris> element of the SIP conferencing event package 💜.

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published just for information 🧚.

It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 🌈.

For the current status, errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7082 🔥.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 🫶.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, at http://trustee.ietf.org/license-info, as they stand on the publication date. Please read them carefully, because they spell out your rights and restrictions for this document 💅. Code Components pulled out of this document need to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License ⚠️.

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. Solutions .......................................................3
      2.1. Call-Info ..................................................3
      2.2. Service URI Purpose ........................................4
   3. Overall Process .................................................5
   4. Security Considerations .........................................5
   5. IANA Considerations .............................................6
      5.1. Call-Info Purpose Registration .............................6
      5.2. URI Purpose Registration ...................................6
   6. Acknowledgments .................................................6
   7. Normative References ............................................7
   Appendix A. Other Approaches Considered ............................9
      A.1. Feature Tag ................................................9
      A.2. Conference URI Purpose .....................................9

1. Introduction 🎀

Okay, background first 🍓. RFC 5239 [RFC5239] sets up a framework for Centralized Conferencing (XCON). It lets participants swap media in a centralized unicast conference. The framework also lays out a set of conferencing protocols for building advanced conferencing apps 💖.

CCMP [RFC6503] lets authenticated and authorized users create, manipulate, and delete conference objects. You can add and remove participants, change their roles, and add and remove media streams and their associated end points. Main character energy 👑.

CCMP lets an XCON-aware client find out whether a conference control server supports CCMP. But a SIP client in a conference can't yet find out whether the conference focus [RFC4353] supports CCMP 🙈. Knowing that would let an XCON-aware SIP client that joins a SIP-based conference [RFC4579] also register for the XCON conference event package [RFC6502] and use CCMP operations on the conference. Iykyk 🦋.

This doc describes two options, depending on what the User Agent (UA) needs ✨. The first option uses the Call-Info [RFC3261] header. It fits application servers that need to find out whether a UA supports CCMP. The second option adds a new value for the "purpose" header field parameter in the <service-uris> element of the SIP conferencing event package [RFC4575]. It fits a UA that would normally subscribe to the conference event package 🧚.

Appendix A briefly covers other options we looked at. We didn't pick them, because the options in this doc handle the problem better 💅.

1.1. Terminology 📖

Here are the key words, verbatim, as they appear in the original. They're to be interpreted as described in RFC 2119 [RFC2119]:

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 RFC 2119 [RFC2119].

2. Solutions 🛠️

This section defines two mechanisms that a SIP UA can use to find out whether the conference a client has joined supports CCMP. The joining follows the SIP signaling procedures defined in [RFC4579] 🌸. Specifically, the mechanisms let the client know that the URI for the conference focus, as defined in [RFC4579], is an XCON-URI as defined in [RFC6501] 💜.

2.1. Call-Info 🌈

This approach uses the Call-Info header in various requests and responses 📞.

The Call-Info header has two parts: a URI and a "purpose" header field parameter. The URI gives the XCON-URI of the conference focus. A new value for the "purpose" header field parameter says that the conference focus supports CCMP ✨.

The XCON-URI alone is supposed to be enough to show that the conference focus supports CCMP 🤓. But the "purpose" header field parameter with the value 'ccmp' is an easier way for a UA that doesn't use the conference event package to find out CCMP support without parsing the URI 🎀.

You can put the Call-Info header, with the XCON-URI and the "purpose" header field parameter set to 'ccmp', on any INVITE request or response, and on a response to an OPTIONS request 🫶.

This approach suits a UA, like an application server acting as a Back-to-Back User Agent (B2BUA), that wants to find out whether a conference focus supports CCMP but doesn't use the XCON conference event package [RFC6502]. That app can send an OPTIONS request and learn CCMP support from the response 🦋.

It also suits a conference focus that sends an INVITE request to a SIP UA to add a participant. The focus can say it supports CCMP right in that INVITE request 👑.

The upside here is that you can learn a conference focus supports CCMP without subscribing to the XCON event package [RFC6502] 🙌. The downside is that sometimes you need an extra request, an additional OPTIONS request, to find out 😭.

2.2. Service URI Purpose 💜

This approach defines an extra URI 'purpose' of 'ccmp', tied to a <service-uris> element in the SIP conferencing event package. The XCON-URI for the conference goes in the 'uri' element, like this:

      <service-uris>
        <entry>
          <uri>XCON:conf1@example.com</uri>
          <purpose>ccmp</purpose>
        </entry>
      </service-uris>

The upside is that it reuses an existing way to extend the <purpose> field of the <service-uris> element in the conferencing event package [RFC4353] 🍓. The downside is that the client has to subscribe to the conference event package 🥺.

This approach suits a SIP UA that would normally subscribe to the conference event package. If a conference supports CCMP, an XCON-aware SIP UA can use CCMP operations, and it can subscribe to the XCON event package [RFC6502] to get more info about the conference 💅✨.

3. Overall Process 🧩

CCMP capability is discovered using the two methods from Section 2 🔍. Which one gets tried first depends on whether an implementation subscribes to the conference event package by default 🌷.

A UA implementation that subscribes to the conference event package can look at the conference description and see whether a URI with <purpose>ccmp</purpose> is specified (Section 2.2) 📋. An implementation that doesn't subscribe can send an OPTIONS query when it connects to the conference server 📞. UAs MUST NOT attempt both methods with the same server. 🚫

Conference servers MUST reflect the same information using both discovery channels. 🔁 A server MUST indicate CCMP support through the conference event package if and only if it indicates support through the Call-Info header in OPTIONS responses. This means UAs never have to try both methods 💖.

Part 2 of 2 is next, bestie 🦋 (Security Considerations, IANA, and the references are still coming 🫶).

6. Acknowledgments 🎀

okay bestie, the authors gave a big shoutout to Alan Johnston, Robert Sparks, Cullen Jennings, Glenn Parsons, Ben Campbell, Barry Leiba, Spencer Dawkins, Sean Turner, Pete Resnick, and Adrian Farrel for their careful review and feedback 🫶✨

special thanks to Adam Roach for his thorough review, comments, and suggestions 💜 and extra special thanks to Richard Barnes for his review and for the text he provided for Section 3 of this document 🦋 that's literally so sweet, no cap

7. Normative References 📚

these are the docs the spec leans on, so you need them to fully understand it 🧚

[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. 🌸

[RFC3840]

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

[RFC4353]

Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. 🧚

[RFC4575]

Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. 💖

[RFC4579]

Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006. 👑

[RFC5239]

Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008. 🌈

[RFC5367]

Camarillo, G., Roach, A., and O. Levin, "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", RFC 5367, October 2008. ✨

[RFC6501]

Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012. 🦋

[RFC6502]

Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, March 2012. 🫶

[RFC6503]

Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, March 2012. 🎀

[RFC6910]

Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev, "Completion of Calls for the Session Initiation Protocol (SIP)", RFC 6910, April 2013. 🌸

[RFC6993]

Saint-Andre, P., "Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)", RFC 6993, July 2013. 💜

Appendix A. Other Approaches Considered 🔥

okay so the next two options were considered as possible solutions but got cut 💀 because the options in this document better address the problem we're trying to solve 💅

A.1. Feature Tag 🧚

this approach defines a feature parameter 'ccmp' to indicate that a SIP dialog belongs to a conference that supports CCMP 🎀 the use of feature parameters in Contact header fields to describe the characteristics and capabilities of a UA is described in the User Agent Capabilities document [RFC3840] 💖

the conference focus behavior for the 'ccmp' feature is the same as the behavior for the 'isfocus' feature parameter 🌈 in session establishment, a conference focus MUST include the 'ccmp' feature parameter in the Contact header field unless the conference focus wishes to hide the fact that it is a conference focus 🫣

the advantages are one-step discovery of the conference focus and its support for the 'ccmp' feature 🦋 it can also be used in response to an OPTIONS request, and it lets any network element that doesn't need the conference event package discover the 'ccmp' capability ✨ the disadvantage is that it needs defining a new feature parameter 😭

A.2. Conference URI Purpose 👑

this approach defines an extra URI 'purpose' of 'ccmp' tied to a 'conf-uris' element in the SIP conferencing event package 💜

ccmp: indicates that the conference focus represented by this URI supports 'ccmp', which in turn lets a client use CCMP to manipulate the conference 🌸 this URI MUST be an XCON-URI as defined in the XCON data model specification [RFC6501] 🔥

  <conf-uris>
    <entry>
      <uri>XCON:conf1@example.com</uri>
      <display-text>whatever</display-text>
      <purpose>ccmp</purpose>
    </entry>
  </conf-uris>

the advantage of the SIP conference event package options is that they reuse an existing mechanism for extending the <purpose> field of the <service-uris> or <conf-uris> elements 🌈 the disadvantage is the requirement that the client register for the conference event package 🥺

Authors' Addresses 💌

Rifaat Shekh-Yusef
Avaya
250 Sidney Street
Belleville, Ontario
Canada

Phone: +1-613-967-5267
EMail: rifaat.ietf@gmail.com


Mary Barnes
Polycom
TX
US

EMail: mary.ietf.barnes@gmail.com
📦 where this page comes from