CLUE A. Romanow Internet-Draft F. Andreasen Intended status: Standards Track A. Krishna Expires: September 13, 2012 Cisco Systems March 12, 2012 Investigation of Session Description Protocol (SDP) Usage for ControLling mUltiple streams for tElepresence (CLUE) draft-romanow-clue-sdp-usage-01 Abstract This draft investigates how SDP offer/answer can be used to communicate CLUE encoding and encoding group parameters. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 13, 2012. Copyright Notice Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Romanow, et al. Expires September 13, 2012 [Page 1] Internet-Draft SDP Usage for CLUE March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Assumptions and Design Principles . . . . . . . . . . . . . . 4 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Encoding group . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Solution overview . . . . . . . . . . . . . . . . . . . . . . 8 8. Provider advertisement in the initial offer/answer . . . . . . 9 8.1. Bidirectional SDP messages . . . . . . . . . . . . . . . . 13 8.2. Unidirectional SDP messages . . . . . . . . . . . . . . . 13 9. Multiple offer/answer exchanges . . . . . . . . . . . . . . . 15 10. Representation of Encoding and Encoding group in SDP . . . . . 19 11. Concerns about conveying CLUE parameters via SDP . . . . . . . 21 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 15.1. Normative References . . . . . . . . . . . . . . . . . . . 22 15.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Romanow, et al. Expires September 13, 2012 [Page 2] Internet-Draft SDP Usage for CLUE March 2012 1. Introduction This draft investigates how SDP could be used to carry CLUE, ControLling mUltiple streams for tElepresence, encoding and encoding group provider advertisements. CLUE specifies how multiple streams can be communicated in a telepresence conference in a standardized manner allowing interoperability. A familiarity is assumed with the CLUE framework document and the concepts defined therein [CLUEFRWK]. The media provider describes to the media consumer both media captures and encodings that it is capable of sending, and the consumer "configures" the provider to send the captures using the potential streams it wants to receive. In order for an interactive telepresence session to be established between A and B, each party needs to configure its role as both a media provider and a media consumer. Encoding parameters are maxBandwidth, maxMbps, maxFps, maxWidth, maxHeight. Encoding group parameters are maxGroupBandwidth and maxGroupVideoMbps. There are 2 reasons we investigated using SDP for CLUE provider advertisements of encoding and encoding groups. It was suggested that: 1. By carrying the encoding and encoding group parameters in SDP, the call-control agents, proxies, and other intermediaries can monitor and potentially modify these values thereby allowing administrators to easily configure and enforce either static limitations or more dynamic call-shaping approaches. 2. SDP is the usual protocol for communicating the encoding and encoding group related parameters in SIP-based systems Media captures, capture sets, and simultaneous transmission information are all communicated in a new CLUE protocol, whereas encoding and encoding group parameters are communicated in SDP. 2. Terminology 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] and indicate requirement levels for compliant implementations. 3. Background The following abstractions defined in the CLUE framework document Romanow, et al. Expires September 13, 2012 [Page 3] Internet-Draft SDP Usage for CLUE March 2012 need to be understood in considering this investigation. o Media capture - fundamental representation of the content, audio and video so far defined. Each media capture is associated with one or more encoding groups. o Capture set - A capture set is most usefully thought of as being a set of table rows, with each row consisting of a set of media captures. Media captures within a row can always be used simultaneously, whereas media captures in different sets may or may not be used simultaneously.. By including multiple media captures in a row within a capture set, the provider is signaling that those captures together form a representation of that capture set's scene. o Simultaneous transmission set - there are often physical constraints that determine whether captures can be sent at the same time or not. For example, a camera may be able to create a video capture which is close up and another which is zoomed out. These 2 views cannot be done simultaneously. The simultaneous transmission set expresses the physical constraints on simultaneity. o Encoding - Represents a way to encode a media capture in terms of its associated media characteristics, specifically maxBandwidth, maxFps, maxMbps, maxHeight and maxWidth. Each encoding is uniquely identified within an encoding group. [Practically it's desirable to have a unique ID among all encodings in the conference] o Encoding group - An encoding group includes set(s) of encodings, plus parameters that apply to the group as a whole, specifically maxGroupBandwidth and maxGroupMpbs. Each encoding group has a unique identifier in the SDP. 4. Assumptions and Design Principles o For each CLUE type ("purpose") of media capture (audio, video- main, or video-presentation), there will be at most one corresponding SDP media stream ("m=" line). Note: video-main and video-presentation are both using "video" media type. o Multiple media captures of the same CLUE type ("purpose"), or different encodings of a given media capture will all use the same SDP media stream (e.g. via RTP multiplexing with a different SSRC for each). o It is acceptable to use more than one offer/answer exchanges to setup the whole Telepresence session. o The Telepresence session is established by setting up sets of unidirectional streams (not bidirectional streams). Romanow, et al. Expires September 13, 2012 [Page 4] Internet-Draft SDP Usage for CLUE March 2012 5. Encoding The CLUE framework calls an RTP stream that the provider is capable of sending, an Encoding (note that an RTP session may contain multiple RTP streams, with each stream having a unique SSRC). The parameters of an encoding are: encodingID, maxBandwidth, maxMbps, maxWidth, maxHeight, maxFrameRate, as described below in the following Figures: Figure 1 shows video encoding parameters and Figure 2. shows audio encoding parameters. +-----------------+-------------------------------------------------+ | Name | Description +-----------------+-------------------------------------------------+ | encodingID | A unique identifier for the individual encoding | | maxBandwidth | Maximum number of bits per second | | maxMbps | Maximum number of macroblocks per second: | | | ((width + 15) / 16) * ((height + 15) / 16) | | | * framesPerSecond | | maxWidth |Video resolution's max supported width in pixels| | maxHeight |Video resolution's max supported height in pixels| | maxFrameRate | Maximum supported frame rate | +--------------------+----------------------------------------------+ Figure 1: Video encoding parameters +--------------+----------------------------------------+ | Name | Description | +--------------+----------------------------------------+ | encodingID | A unique id for the encoding | +--------------+----------------------------------------+ | maxBandwidth | Max # of bits per second | +--------------+----------------------------------------+ Figure 2: Audio encoding parameters 6. Encoding group In addition to encodings, the Framework defines an Encoding Group as a set of individual encodings plus parameters that apply to the whole set, as shown in Figure 3, Encoding group. The two parameters for the group of encodings are maxGroupBandwidth and maxGroupVideoMbps. Max group bandwidth refers to both audio and video, and is the Romanow, et al. Expires September 13, 2012 [Page 5] Internet-Draft SDP Usage for CLUE March 2012 maximum value of the sum of all of the configured bitrates. The max group video macroblocks per second refers only to video and is the maximum value for the sum of all the macroblocks per second in the encoding group. +------------------+-------------------------------------------------+ | Name | Description | +------------------+-------------------------------------------------+ | maxGroupBandwidth| Max # bits per sec for all encodings combined | | maxGroupVideoMbps| Max # macroblks/sec all video encodings combined| | videoEncodings[] | Set of available encodings (list of encodingIDs)| | audioEncodings[] | Set of available encodings (list of encodingIDs)| +------------------+-------------------------------------------------+ Figure 3: Encoding group parameters Additional characteristics of encoding groups include: 1. A media provider advertises one or more encoding groups. 2. Each encoding group includes one or more individual encodings. 3. Each individual encoding can represent a different way of encoding media. For example one individual encoding may be 1080p60 video, another could be 720p30, with a third being CIF. 4. While a typical 3 codec/display system might have one encoding group per "codec box", there are many possibilities for the number of encoding groups a provider may be able to offer and for the encoding values in each encoding group. The consumer uses the media capture attribute EncGroupID to know which set of encodings to consider using for that capture and what the constraints are. 5. In a provider advertisement, the sum of the maxBandwidths of the encodings advertised in an encoding group may total more than the maxGroupBandwidth, as these are potential encodings. Similarly for maxGroupVideoMbps. The group restriction however must be respected by the provider in terms of actual set of encodings used at any given point in time. 6. In a consumer request, the sum of the maxBandwidths of the encodings selected in an encoding group may total more than the maxGroupBandwidth. However the provider will send values under the max of the individual encodings and which sum to a total below or equal to that of the group max. The following diagram Figure 4, Association of captures and encodings, depicts the association between the encodings (expressed in SDP) and the media captures, expressed in elsewhere (in a CLUE protocol perhaps). In this diagram the consumer can match Capture 1 Romanow, et al. Expires September 13, 2012 [Page 6] Internet-Draft SDP Usage for CLUE March 2012 with any of the encodings in Encoding group 1. The consumer can match capture 2 with any of the encodings in encoding group 2, and match capture 3 wiht any of the encodings in encoding group 1. +--------------------+ | Capture Set 1 | | | Encodings for capture 1 | +----------------+--------------- Encoding 1 } | | capture 1 | |------------- Encoding 2 } Encoding group 1 | | video | |------------- Encoding 3 } | | ... | | | | encgrpID 1 | | | +----------------+ | | | | +----------------+ | Encodings for capture 2 | | capture 2 | | | | audio | |---------------Encoding 4 } | | .... | |---------------Encoding 5 } Encoding group 2 | | | | | | encgrpID 2 | | | +----------------+ | | | Encodings for capture 3 | +----------------+--------------- Encoding 1 } | | capture 3 | |------------- Encoding 2 } Encoding group 1 | | video | |------------- Encoding 3 } | | ... | | | | encgrpID 1 | | | +----------------+ | | | +--------------------+ Figure 4: Association of captures and encodings In this example showing a capture set containing 2 captures, the first captureID 1 is video and is mapped to encoding group 1, encgrpID 1. The consumer can map capture 1 to any or all of the potential RTP streams within encoding group 1. The use case for mapping a single video capture to more than one encoding at a given point in time is simulcast. The information contained in the encoding group parameters helps the consumer choose how to do this mapping by communicating the resource limitations. Romanow, et al. Expires September 13, 2012 [Page 7] Internet-Draft SDP Usage for CLUE March 2012 7. Solution overview Today telepresence endpoints actively negotiate audio and video SDP media streams using the SDP offer/answer model during call establishment and during midcall features, such as hold resume. However, in the CLUE framework, each party in the conference is usually both a provider and a consumer whether point-to-point or multipoint. The parameter values for one provider may well not be the same values for the other provider. Thus each party needs to advertise its provider encoding parameter values to the other side. This is not the typical communication model for SDP offer/answer, which is more often a bidirectional agreement on parameter values. As specified in the CLUE framework, parties in a telepresence conference do not negotiate a single value between them; therefore offer/answer [RFC3264] is not used for the full negotiation of all encoding related values. Rather, we propose, sending CLUE provider advertisements for encodings and encoding group in SDP offer/answer, if it valuable for intermediaries to know these values. Then the consumer uses another protocol, such as a new CLUE protocol, to select which captures it wants at a given point in time and how it wants them encoded, subject to the encoding and encoding group parameters specified in the SDP. Provider advertisements not related to encoding, that is, capture attributes such as spatial relations would also be communicated in the CLUE protocol, rather than in SDP, as they are not provided as part of the SDP media descriptions for the streams. In this approach, the CLUE protocol carries the information related to media captures, as well as implements the control functions described in the CLUE framework including configuring the actual encodings used. For example, if A and B are parties (either endpoints or MCUs) in a telepresence conference, A is a provider for B, and B is a provider for A. We propose that A and B send to each other provider advertisements for encoding and encoding groups through SDP; and A and B send to each other provider advertisements for Captures and consumer requests through a CLUE protocol. The sending of advertisements of capture information and encoding information and the responding consumer request happens not only at call setup but also throughout the conference whenever there is a change in what the provider is capable of sending, or a change in which captures and streams the consumer wants to receive. We will now explore two approaches for sending provider encoding advertisements in SDP. In the first approach, the provider encoding advertisements are accomplished in the initial offer/answer. A sends its provider encoding advertisements in the offer and B sends its Romanow, et al. Expires September 13, 2012 [Page 8] Internet-Draft SDP Usage for CLUE March 2012 provider encoding advertisements in the answer. There are two message options here: bidirectional or unidirectional. In the second approach, a series of offer/answer messages are sent from each participant. Both approaches have pluses and minuses. How each approach handles the situation where the parties advertise different types (SDP media capabilities) is of interest. For example one party may offer video-presentation and the other may not offer it. 8. Provider advertisement in the initial offer/answer One possibility for exchange of CLUE parameters between 2 endpoints or MCUs is in the initial SDP offer/answer exchange. One party sends provider encoding advertisements as the SDP offer and the other party answers with its provider encoding advertisements, as shown in Figure 5, Initial offer/answer exchange. A then sends its capture information to B through the CLUE protocol (and vice versa). Romanow, et al. Expires September 13, 2012 [Page 9] Internet-Draft SDP Usage for CLUE March 2012 Provider A +--------------------+ | SDP offer 1 | | | | Offered media | | (actively negotd | | as today) | | | Encoding Group 1 | +-------------+ | | | Encoding 1 | | | | Encoding 2 | | | | ... | | | +-------------+ | Offer | |--------> | Encoding Group 2 | | +-------------+ | | | Encoding 3 | | | | Encoding 4 | | | | ... | | | +-------------+ | | ....... | | | +--------------------+ Provider B +--------------------+ | SDP answer 1 | | | | Accepted media | | (actively negotd) | Answer | | <--------| | | Encoding-Group 1 | | +-------------+ | | | Encoding 1 | | | | Encoding 2 | | | | ... | | | +-------------+ | | | | Encoding-Group 2 | | +-------------+ | | | Encoding 3 | | | | Encoding 4 | | | | ... | | | +-------------+ | | ....... | +--------------------+ Romanow, et al. Expires September 13, 2012 [Page 10] Internet-Draft SDP Usage for CLUE March 2012 Figure 5: Initial offer answer exchange There are two possibilities: birdirectional or unidirectional SDP messages. Figure 6, Call message sequence illustrates an end-end call with the message sequence where provider advertisements are in initial offer/ answer. Alice Bob | | ________|__________________________________|_______________________ | |(1) INVITE | | | | Offer (Offered media, | | | | CLUE extensions - | | | | enc-grp 1 | | | | enc 1 | | | | enc 2 | | | | enc 3 | SIP | | | enc-grp 2 | CALL SETUP | | | enc 4 | | | | enc 5 | Alice sends Provider | | | TRANSPORT TBD/CLUE connection | advertisement for | | | params ) | encodings & encoding | | | | groups in SDP | | | | | | |--------------------------------->| | | |(2) 200OK | | | | Answer (Accepted media, | Bob in | | | CLUE extensions | Provider's role | | | enc-grp 1 | sends his | | | enc 1 | advertisement for | | | enc-grp 2 | encodings & encoding | | | enc 2 | groups | | | TRANSPORT TBD/CLUE negotd | | | | connection ) | | | |<---------------------------------| | |________|__________________________________|_______________________| | | | | ________|__________________________________|_______________________ | | (3) CLUE PROTOCOL | | | |--------------------------------->| | | | CLUE Provider MESSAGEs | Alice and Bob in | | | Describe media captures | Provider's role | | | Includes association of MC | | Romanow, et al. Expires September 13, 2012 [Page 11] Internet-Draft SDP Usage for CLUE March 2012 | | to Encoding Group | | | |<---------------------------------| | | | | | |________|__________________________________|_______________________| | | | | . . . . . . . . . . . . . . . . | ________|__________________________________|_______________________| | | (4) CLUE PROTOCOL | | | | | | | | Bob configures the MCs it wants| Bob in consumer role | | | Onto the encodings it wants | sends CLUE consumer | | | Within the encoding group | CONFIGURE message | | | Constraints. | | | |<---------------------------------| | | | | | |________|__________________________________|_______________________| | | ________|__________________________________|_______________________ | | (5) SIP Re-INVITE | | | | Re-negotiate TIAS bw etc | SIP | | | based on consumer choices | Media Re-negotiation| |________|__________________________________|_______________________| | | | . . . . . . . . . . . . . . . . ________|__________________________________|_______________________ | | (6) CLUE PROTOCOL | | | | | | | | Choose the MCs to be sent, | CLUE MESSAGE | | | Request media in various | | | | encoding formats | | | |--------------------------------->| Alice in | | | | Consumer role | |________|__________________________________|_______________________| | | ________|__________________________________|_______________________ | | (7) SIP Re-INVITE | | | | Re-negotiate TIAS bw etc | SIP | | | based on consumer choices| Media Re-negotiation| |________|__________________________________|_______________________| | | . . . . . . . . . . . . . . . . Figure 6: Call message sequence for CLUE advertisements in initial offer/answer Romanow, et al. Expires September 13, 2012 [Page 12] Internet-Draft SDP Usage for CLUE March 2012 8.1. Bidirectional SDP messages The challenge with a bidirectional approach is that the answerer must not respond with a type that was not in the offer. Suppose A offers two SDP media streams video-main and audio. B however wants to offer 3 SDP media streams: video-main, audio, and video-presentation. B cannot add a new stream type in the answer. One way around this is for the offerer to always offer all 3 CLUE media types ("purpose") whether it will send them or not, i.e., be a provider. This allows both sides to negotiate use of each "purpose" as a provider and/or a consumer. The SDP direction attributes ("sendrecv", "sendonly", "recvonly", and "inactive") are used to indicate the real intent for a stream; a provider sends whereas a consumer receives, and hence a "sendrecv" stream covers both provider and consumer role. Streams can of course be rejected as per normal offer/answer procedures (e.gg., if neither side wants to use a particular stream such as video-presentation. An adjustment to reflect the real situation can also bemade in a subsequent offer/ answer exchange. Using the example above, A will only send video main and audio, however, following the specification, A offers all 3 audio, video main, video presentation. B is going to send presentation, B accepts all 3 audio, video-main and video-presentation and hence generates an answer with them. The CLUE protocol negotiations take place. Then there is an updated offer in which A does not offer video presentation, thus making the SDP media streams accurate. 8.2. Unidirectional SDP messages 1) Offer (INVITE) from Alice to Bob (Alice provider=sendonly, Alice consumer=recvonly) ================================================== m=audio 10000 RTP/AVP 96 ;Alice provider audio a=sendonly a=rtpmap:96 PCMU ... m=video 10002 RTP/AVP 96 97;Alice provider video-main a=sendonly a=rtpmap:96 H264 a=rtpmap:97 H265 ... m=video 10004 RTP/AVP 96 ;Alice provider video-presentation a=sendonly a=rtpmap:96 H264 ... Romanow, et al. Expires September 13, 2012 [Page 13] Internet-Draft SDP Usage for CLUE March 2012 m=audio 20000 RTP/AVP 96 ;Alice consumer audio a=recvonly a=rtpmap:96 PCMU ... m=video 20002 RTP/AVP 96 97 ;Alice consumer video-main a=recvonly a=rtpmap:96 H264 a=rtpmap:97 H265 ... m=video 20004 RTP/AVP 96 ;Alice consumer video-presentation a=recvonly a=rtpmap:96 H264 ... 2) Answer from Bob to Alice (Bob provider=sendonly, Bob consumer=recvonly) ============================================== m=audio 30000 RTP/AVP 96 ;Bob consumer audio a=recvonly a=rtpmap:96 PCMU ... m=video 30002 RTP/AVP 96 97 ;Bob consumer video-main a=recvonly a=rtpmap:96 H264 a=rtpmap:97 H265 ... m=video 30004 RTP/AVP 96 ;Bob consumer video-presentation a=recvonly a=rtpmap:96 H264 ... m=audio 40000 RTP/AVP 96 ;Bob provider audio a=sendonly a=rtpmap:96 PCMU ... m=video 40002 RTP/AVP 96 97;Bob provider video-main a=sendonly a=rtpmap:96 H264 a=rtpmap:97 H265 ... m=video 0 RTP/AVP 96 ;Bob does not want to be a provider for video-presentation, so rejected this stream (port=0) a=inactive a=rtpmap:96 H264 ... Romanow, et al. Expires September 13, 2012 [Page 14] Internet-Draft SDP Usage for CLUE March 2012 9. Multiple offer/answer exchanges An alternate approach to using the intial offer answer for the provider encoding advertisements is to do multiple offer/answer messages in which both sides make provider advertisements. The initial offer/answer establishes that the parties are CLUE capable and subsequent offer/answer messages exchange provider encoding advertisements. The disadvantage of this approach is that it requires a number of offer/answer messages. In this method, the call is initially established with configurable default media values. The call flow is shown in detail in Figure 7 Romanow, et al. Expires September 13, 2012 [Page 15] Internet-Draft SDP Usage for CLUE March 2012 Alice Bob | | ________|__________________________________|_______________________ | |(1) INVITE | | | | Offer {m=audio..., | | | | m=video (main) .... | | | | m=application CLUE | SIP | | | trans params from | CALL SETUP | | | Alice end | | | | } | | | |--------------------------------->| Negotiate default | | |(2) 200OK | media parameters | | | Answer {m=audio..., | | | | m=video (main) .... | | | | m=application CLUE | | | | trans params from | | | | Bob end | | | | } | | | |<---------------------------------| | | | | | | |<================================>| | | | Both Alice & Bob understand | | | | they are talking to CLUE | | | | endpoint | | |________|__________________________________|_______________________| | | | | ____________________________________________ / CLUE CONNECTION ESTABLISHMENT \ \____________________________________________/ | | ________|__________________________________|_______________________ | | Provider Capabilities Ind(Alice)| | | | | | | | | | | |(3)re-INVITE | | | | Offer {m=audio ... | | | | CLUE extensions | | | | enc-grp 1 | | | | enc 1 | | | | enc 2 | | | | enc 3 | ALICE in | | | m=video (main)... | Provider's role | | | CLUE extensions | | | | enc-grp 2 | | | | enc 4 | | | | enc-grp 3 | (keeps previously | | | enc 5 | negotd media | Romanow, et al. Expires September 13, 2012 [Page 16] Internet-Draft SDP Usage for CLUE March 2012 | | m=application CLUE | | | | conn params | params) | | | } | | | |--------------------------------->| Adds Alice's | | |(4) 200OK | provider | | | Answer {m=audio... | encoding | | | m=video (main) ... | capabilities | | | m=application CLUE | for each m-line | | | conn params | | | | } | | | |<---------------------------------| | |________|__________________________________|_______________________| | | | | ________|__________________________________|_______________________ | | Provider Capabilities Ind (Bob) | | | | | | | | | | | |(5)re-INVITE | | | | Offer {m=audio ... | BOB in | | | CLUE extensions | provider role | | | enc-grp 1 | | | | enc 1 | (keeps previously | | | enc 2 | negotd media | | | m=video (main)... | params) | | | CLUE extensions | | | | enc-grp 2 | Is capable of | | | enc 3 | doing presentation| | | m=application CLUE | | | | conn params | Adds new pres | | | m=video (pres)... | m-line | | | CLUE extensions | | | | enc-grp 3 | | | | enc 4 | | | | } | | | |<---------------------------------| | | |(6) 200OK | Adds Bob's | | | Answer {m=audio... | provider | | | m=video (main) ... | encoding capabil | | | m=application CLUE | for each m-line | | | conn params | | | | m=video (pres) ... | | | |--------------------------------->| | |________|__________________________________|_______________________| | | ________|__________________________________|_______________________ | | (7) CLUE PROTOCOL | | | |--------------------------------->| | Romanow, et al. Expires September 13, 2012 [Page 17] Internet-Draft SDP Usage for CLUE March 2012 | | CLUE Provider MESSAGEs | Alice & Bob in | | | Describe media captures | Provider's role | | | Includes association of MC to | | | Encoding Group | | | |<---------------------------------| | | | | | |________|__________________________________|_______________________| | | ________|__________________________________|_______________________ | | (8) CLUE PROTOCOL | | | | | | | | Bob configures the MCs it wants | | | | Onto the streams it wants within | Bob in consumer role | | | the encoding group constraints. | sends CLUE consumer | | | | CONFIGURE message | | | | | | |<---------------------------------| | | | | | |________|__________________________________|_______________________| | | ________|__________________________________|_______________________ | | (9) SIP Re-INVITE | | | | Re-negotiate TIAS bw etc | SIP | | | based on view options | Media Re-negotiation| |________|__________________________________|_______________________| | | | | ________|__________________________________|_______________________ | | (10) CLUE PROTOCOL | | | | | | | | Choose the MC to view, | CLUE MESSAGE | | | Request the video in various | | | | encoding formats | | | |--------------------------------->| Alice in | | | | Consumer role | |________|__________________________________|_______________________| | | ________|__________________________________|_______________________ | | (11) SIP Re-INVITE | | | | Re-negotiate TIAS bw etc | SIP | | | based on view options | Media Re-negotiation| |________|__________________________________|_______________________| | | . . . . . . . . . . . . . . . . Figure 7: Call message sequence for CLUE advertisements multiple Romanow, et al. Expires September 13, 2012 [Page 18] Internet-Draft SDP Usage for CLUE March 2012 offer/answers The offerer establishes a CLUE application with transport connection. The answerer acknowledges, thus indidcating its willingness to participate in CLUE signaling. No encoding advertisements are exchanged at this point. The CLUE connection is established Alice, in the provider's role, indicates ecnoding and encoding group advertisement parameters using re-INVITE (new offer/answer). In this example, Alice does not indicate support for video-presentation. Bob acks back and does not provide any of his provider encoding advertisements at this point Bob now signals his provider encoding advertisements using a fresh re-INVITE (third offer/answer). Bob is capable of video- presentation. It adds a video-presentation m=line and indicates its provider encoding advertisements. Alice may decide to not actively do presentiaton at this time, and may stop the media (port 0) in 200OK. But Alice is aware of the CLUE advertisement for the video- presentation to be used in the future. Alice and Bob use CLUE messages exchange provide capture advertisements, including bindings to encoding groups. Bob in consumer role uses the consumer configure CLUE message to select which captures and encodings he wants. Bob sends a re-INVITE (4th offer/answer) to negotiatie TIAS bandwidth based on the consumer requests. This enables call control and intermediaries to manage bandwidth resources. Alice in consumer role uses the consumer configure CLUE message to slect which captures and encodings she wants. Alice sends a re=INVITE to negotiate new TIAS bandwidth based on the consumer requests, updating previous parameter values. This process continues as options change at either end. 10. Representation of Encoding and Encoding group in SDP We want a mechanism that will allow the provider to advertise encodings and encoding groups. We can define three new SDP attributes: clue, enc, encgrp. Romanow, et al. Expires September 13, 2012 [Page 19] Internet-Draft SDP Usage for CLUE March 2012 Encgrp is the encoding group. It consists of an encoding group ID, a list of encodings, and a list of encoding group parameters, maxGroupBandwidth, maxGroupVideoMbps. a=encgrp: Enc is the encoding. It consists of an encoding id and a list of clue parameters and their values for the encoding. a=enc: Clue consists of CLUE encoding parameters: max-fps, max-mbps, max- bitrate, imageattr. The parameter list can be extended in the future. a=clue: where clue attributes in our context would be "imageattr[x= ,y= ]" [draft-ietf-mmusic-image-attributes],"max-mbps", "max-br", max-fps Example of 2 video encodings: a=clue:1 imageattr[w=1920, y=1088] a=clue:2 max-fps=60 a=clue:3 max-mbps=244800 a=clue:4 max-br=4000 a=clue:5 imageattr[x=960, y=554] a=clue:6 max-fps=30 a=clue:7 max-mbps=61200 a=enc:1 clue=1,2,3,4 Encoding 1 and its clue attributes a=enc:2 clue=5,6,7,4 Encoding 2 and its clue attributes Example of 2 video encoding groups a=encgrp: 1 enc=1,2,3 grpparm=3,4,5 a=encgrp:2 enc=4,5,6,7 grpparm=2,4,5 Figure 8: Example 2 video encodings Romanow, et al. Expires September 13, 2012 [Page 20] Internet-Draft SDP Usage for CLUE March 2012 11. Concerns about conveying CLUE parameters via SDP There are some potential concerns in using SDP for CLUE provider capability announcements. Passing information to two separate protocols and processing it from them complicates the protocol and implementation. Secondly, if the two SIP peers do not communicate directly (e.g. due to SIP Record-Route), then reINVITEs/UPDATEs may be delay-prone compared to an independent and direct end-to-end protocol; this is relatively unimportant so long as any parameters expected to change repeatedly, or that must be sent when a stream switches (i.e., near real-time) are kept out of the SDP. The encoding and encoding group will potentially be large and significantly expand the SDP size. A compact representation is suggested in the above to try and alleviate this. Further work and testing will be required to see if it is a problem in practice, and whether it is inherent to CLUE to begin with. The presence of the CLUE protocol negotiation provides a way to ameliorate this problem for systems operating in a mixed CLUE/ non-CLUE environment that don't wish to send the information to non- CLUE endpoints: the initial offer contains the CLUE protocol m-line, but not the CLUE media descriptions. The answerer sees that the caller is CLUE-capable and includes the media description in their answer, and the offerer can then reINVITE once negotiation is complete with a media description. The value to the intermediaries of the encoding parameters needs to be considered carefully. The intermediaries will have the TIAS value which is updated after CLUE protocol activity. What about the encoding parameters? It is unclear they are of much use to intermediaries by themselves - they are the potential maximum values of potential RTP streams. How are intermediaries expected to use these? It seems the encoding group parameter values, especially the maxGroupBandwidth could be of interest to intermediaries augmenting the TIAS information. An alternative to including provider advertisements in SDP might be to include an attribute in SDP for the sum of all the Encoding group maxGroupBandwidths, which seems more valuable than all the individual encoding group maxGroupBandwidths. Another factor to consider is that suppose an intermediary changes the maxGroupBandwidth value - that change would be seen by the Consumer, not by the provider, and it is the provider who is the one who needs to see a change in encoding group available resources. This could require actual negotiation of these parameters, instead of the currently declarative unidirectional use specified in the draft Romanow, et al. Expires September 13, 2012 [Page 21] Internet-Draft SDP Usage for CLUE March 2012 currently. Note on real time requirements: The provider advertisements and Consumer selection should be as quick as possible, but do not have hard real time requirements. They can be accomplished within the time scale of signaling. There is however one scenario that has timing requirements more stringent than signaling typically provides. Consider a switch=true audio capture, the information on the spatial location of the audio capture needs to happen in real time. The speaker changes frequently and the location of the speaker must be known quickly (in near real- time) in order to assign the incoming stream to a decoder. Editor's Note: add reference to draft-clue-hansen 12. Security Considerations TBD 13. Acknowledgements Thanks to Rob Hansen for discussions on the advantages and disadvantages of using SDP. 14. IANA Considerations TBD 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 15.2. Informative References [I-D.ietf-clue-framework] Romanow, A., Pepperell, A., Baldino, B., and M. Duckworth, "Framework for Telepresence Multi-Streams", draft-ietf-clue-framework-03 (work in progress), February 2012. Romanow, et al. Expires September 13, 2012 [Page 22] Internet-Draft SDP Usage for CLUE March 2012 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. Authors' Addresses Allyn Romanow Cisco Systems San Jose, CA 95134 USA Email: allyn@cisco.com Flemming Andreasen Cisco Systems Iselin, NJ USA Email: fandreas@cisco.com Arun Krishna Cisco Systems San Jose, CA USA Email: arukrish@cisco.com Romanow, et al. Expires September 13, 2012 [Page 23]