CLUE R. Hansen Internet-Draft A. Krishna Intended status: Standards Track A. Romanow Expires: January 11, 2013 Cisco Systems July 10, 2012 Call Flow for CLUE draft-romanow-clue-call-flow-00 Abstract This draft shows the CLUE call flow demonstrating the use of CLUE in SIP. It also provides information about the message and syntax for CLUE transport establishment and other extensions in SDP. In CLUE participants act as both providers and consumers. The draft includes a detailed example of a typical use case which includes both static and switched captures. 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 January 11, 2013. 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 Hansen, et al. Expires January 11, 2013 [Page 1] Internet-Draft Call Flow for CLUE July 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Transport for carrying CLUE signaling protcol . . . . . . . . 5 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. UDP/DTLS/SCTP . . . . . . . . . . . . . . . . . . . . . . 6 5. Initial Call Establishment . . . . . . . . . . . . . . . . . . 7 5.1. First offer-answer exchange . . . . . . . . . . . . . . . 7 5.2. RTP-header extension and SDP support for CLUE calls . . . 8 5.2.1. RTP extension header for associating RTP stream with CLUE capture . . . . . . . . . . . . . . . . . . 9 5.2.2. RTP extension header for audio rendering tag . . . . . 11 5.3. CLUE channel establishment using SDP . . . . . . . . . . . 12 5.4. Bandwidth considerations for CLUE . . . . . . . . . . . . 14 5.4.1. Allocate as you go . . . . . . . . . . . . . . . . . . 14 5.4.2. Pre-allocation of bandwidth . . . . . . . . . . . . . 17 6. CLUE message exchange following call setup . . . . . . . . . . 17 7. Sending and receiving media . . . . . . . . . . . . . . . . . 20 7.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Backward compatibility with non-CLUE endpoints . . . . . . 22 9. Mid-call provider advertisement and re-configuration . . . . . 22 10. Example call flow . . . . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 14.1. Normative References . . . . . . . . . . . . . . . . . . . 28 14.2. Informative References . . . . . . . . . . . . . . . . . . 28 Appendix A. Example call flow messages . . . . . . . . . . . . . 29 A.1. INVITE from Alice . . . . . . . . . . . . . . . . . . . . 30 A.2. 200 OK from Bob . . . . . . . . . . . . . . . . . . . . . 31 A.3. CLUE advertisement A (from Alice) . . . . . . . . . . . . 31 A.4. CLUE advertisement B (from Bob) . . . . . . . . . . . . . 33 A.5. CLUE response A (from Alice) . . . . . . . . . . . . . . . 39 A.6. CLUE response B (from Bob) . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Hansen, et al. Expires January 11, 2013 [Page 2] Internet-Draft Call Flow for CLUE July 2012 1. Background The purpose of this draft is to examine the call flow for implementing the CLUE framework using SIP and other IETF protocols. Although much of the CLUE framework [ref] is reasonably well agreed upon in the CLUE WG, in order to develop a feasible call flow, we had to make assumptions about many aspects of CLUE that have not yet been decided: what the transport will be, what the message format will be, etc. While these assumptions are not definitive final answers, we have tried to make sensible decisions based on existing drafts and common sense. Perhaps by examining in more detail how the call flow could be handled some light will be shed light on some of the proposals. The following assumptions related to UDP are being made: [these are also stated in draft-romanow-clue-sdp-usage] o For each CLUE media type and content type (audio, video-main, or video-slides) [draft-romanow-clue-data model], there will be at most one corresponding SDP media stream ("m=" line). Note: video- main and video-slides are both using SDP "video" media type. o Multiple media captures of the same CLUE media and content type, or different encodings of a given media capture will all use the same SDP media stream (i. e., via RTP multiplexing with a different SSRC for each). o It is acceptable to use more than one offer/answer exchange to setup the whole Telepresence session. o The Telepresence session is established by setting up sets of unidirectional streams (not bidirectional streams). Today telepresence endpoints actively negotiate audio and video SDP media streams using the SDP offer/answer model during call establishment and during mid-call features, such as hold resume. The CLUE framework adds additional parameters to a telepresence session. Each party in the CLUE conference is usually both a provider and a consumer, whether the conference is point-to-point or multipoint. The CLUE 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 parameter values via a new CLUE signaling protocol which will be negotiated via SIP. The CLUE messages consist of provider advertisements and Hansen, et al. Expires January 11, 2013 [Page 3] Internet-Draft Call Flow for CLUE July 2012 consumer requests. 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. Solution Overview A number of aspects of CLUE remain to be fully defined, including major issues such as the transport mechanism and message structure. In order to provide illustrative examples, this draft makes a number of assumptions and guesses about the final format of CLUE. Where possible an attempt has been made to use existing drafts (such as for the multiplexing methodology), or similar developments in other working groups (such as the use of SCTP over UDP as a transport from RTCWeb). As such, this draft should not be taken as an attempt to specify such aspects, but merely to illustrate how they would be used to convey the necessary data: were other decisions to be made on aspects such as transport, the mechanisms would be different, but the data needing to be conveyed would remain the same. We have assumed about the call flow that: 1. SIP is used to establish the telepresence conference, similarly to using SIP for non-CLUE video conferencing. 2. The media parameters for the call are established using SDP. 3. A new and separate CLUE signaling protocol is used for carrying CLUE messages. (draft-romanow-clue-SDP-usage looked at carrying CLUE messages in SDP and concluded it was infeasible.) 4. Usage of the CLUE protocol is established through SDP 5. The transport for the CLUE protocol is SCTP over UDP, following the RTCWeb specification. 6. The transport for CLUE protocol, SCTP/DTLS/UDP is setup in SDP, as illustrated in the following diagram and discussed below. Hansen, et al. Expires January 11, 2013 [Page 4] Internet-Draft Call Flow for CLUE July 2012 Alice (3-screen Bob (switching 3-camera) MCU) | | | INVITE | +--------------------->| | 200 OK | <----------------------+ | ACK | |----------------------> | | | single-stream media | | <..................> | | | +----SCTP over UDP established----+ | ----Advertisment A---> | | <---Advertisment B---- | | ------ Request A-----> | | <----- Request B-----> | +---------------------------------+ | | | multi-stream media | | <..................> | + + Call setup overview The following section discusses the transport for carrying CLUE signaling protocol, following the direction that RTCWeb has taken. Then the telepresence call establishment using SDP is considered, including RTP header extension, initial offer answer exchange, and bandwidth considerations. The following section describes CLUE message exchange following the call setup, including provider advertisements and consumer requests. Then mid-call changes in provider advertisements and consumer requests are considered. Section 10 describes a case study which includes both static and dynamic switched captures. Interoperability is then considered, followed by security. 4. Transport for carrying CLUE signaling protcol This section discusses a feasible choice for the transport of CLUE signaling protocol. First the requirements are considered followed by a discussion of RTCWeb's choice of SCTP over DTLS over UDP. Hansen, et al. Expires January 11, 2013 [Page 5] Internet-Draft Call Flow for CLUE July 2012 4.1. Requirements TBD Refer to draft wenger-clue-transport and mailing list discussion. 4.2. UDP/DTLS/SCTP There have been several discussion in the CLUE WG suggesting that the transport requirements for CLUE and RTCWeb are sufficiently similar so that CLUE should consider following what RTCWeb has decided. This section briefly reviews RTCWeb's transport specification relevant for CLUE. RTCWeb WG has reached a general consensus on using SCTP [RFC4960] encapsulated on DTLS [RFC6347] encapsulated on UDP for handling non- media data types in the context of RTCWeb. The approach is described in RTCWeb Datagram Connection, draft-ietf-rtcweb-data-channel. The transport protocol stack is illustrated in the diagram below, Protocol layers. +-----------+ |CLUE/RTCWeb| +-----------+ | SCTP | +-----------+ | DTLS | +-----------+ | ICE/UDP | +-----------+ Protocol layers The services offered by this stack are described in draft-ietf-rtcweb-data-channel: The encapsulation of SCTP over DTLS over ICE/UDP provides a NAT traversal solution together with confidentiality, source authenticated, integrity protected transfers. This data transport service operates in parallel to the media transports, and all of them can eventually share a single transport-layer port number. SCTP provides multiple streams natively with reliable, unreliable and partially-reliable delivery modes. DTLS Encapsulation of SCTP Packets for RTCWEB, draft-tuexen-tsvwg-sctp-dtls-encaps describes the encapsulation of SCTP by DTLS. Hansen, et al. Expires January 11, 2013 [Page 6] Internet-Draft Call Flow for CLUE July 2012 The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This memo document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. SCTP over DTLS is used by the RTCWeb protocol suite for transporting non-media data between browsers. In addition a third RTCWeb related draft, Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) draft-ietf-mmusic-sctp-sdp describes in detail how SDP can handle setting up SCTP and DTLS. SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers for SDP. We have followed this syntax here. 5. Initial Call Establishment This section is not intended to prescribe the flows and messages precisely as they are shown, but rather illustrates the principles. 5.1. First offer-answer exchange The flow illustrated below shows Alice calling Bob offering SDP parameters that are typical of an offer. The new extensions related to CLUE are highlighted below. Hansen, et al. Expires January 11, 2013 [Page 7] Internet-Draft Call Flow for CLUE July 2012 Alice Bob | | |(1) INVITE | | SDP-Offer { | | session-attributes | | <<< rtp-header extensions for CLUE >>> *new* | | m=audio .... | | m=video .... | | m=video .... | | m=application...UDP/BFCP * | | <<< m=application 6736 UDP/SCTP/CLUE * >>> *new* | | } | |---------------------------------------------------------------->| | | |(2) 200OK | | SDP-Answer { | | session attributes | | <<< rtp-header extensions for CLUE >>> *new* | | m=audio .... | | m=video .... | | m=video .... | | m=application...UDP/BFCP * | | <<< m=application 4534 UDP/SCTP/CLUE * >>> *new* | |<----------------------------------------------------------------| | | | | First SDP offer answer exchange TODO : Discuss any changes to SIP header Three issues relate to SDP support during initial call setup: 1. Extension of the RTP header for telepresence calls. As part of CLUE usage, two such potential requirements are consideration. Refer to sec 5.2. 2. Establishment of CLUE signaling channel using separate application m-lines. Sec 5.3 3. Bandwidth considerations during initial setup. Sec.5.4 5.2. RTP-header extension and SDP support for CLUE calls Currently 2 proposals are under consideration for mechanisms that require using RTP extension headers [RFC5285]. Although neither proposal has been accepted, we are showing how each would be handled if they are added to the CLUE framework [draft-ietf-clue-framework]. Hansen, et al. Expires January 11, 2013 [Page 8] Internet-Draft Call Flow for CLUE July 2012 The first mechanism that requires an RTP header extension is for associating RTP streams with CLUE captures as described in draft-lennox-clue-rtp-usage. The second mechanism is using an audio rendering tag to associate audio captures with video captures as described in draft-romanow-clue-audio-rendering-tag. Both use session-level SDP parameters as recommended by RFC5285. 5.2.1. RTP extension header for associating RTP stream with CLUE capture Telepresence calls multiplex encoded streams from multiple similar media sources on a single RTP session for the same media-type/and content-type. For example, Alice has a 3 camera system but in SDP she negotiates a single RTP session for main video. How does she indicate these separate RTP streams with the CLUE capture ids to enable Bob, the receiver, to know the proper placement of the audio and video streams? How do the RTP streams get routed to the appropriate output devices? This is considered in detail in draft-lennox-clue-rtp-usage. The proposal is to extend the RTP header to embed the capture-id in each RTP packet. That requires negotiating a unique "id" out of band (in SDP) so that multiple such extensions could co-exist. This is achieved by using the extmap extension in SDP as specified in RFC5285. The extmap id-1 below depicts the identifier being used to signal the capture-id information in RTP extension header. Hansen, et al. Expires January 11, 2013 [Page 9] Internet-Draft Call Flow for CLUE July 2012 Alice (3-screen Bob (3-screen 3-camera) 3-camera) o o o o o o +--+ +--+ +--+ +--+ +--+ +--+ |1 | |2 | |3 | | 1| |2 | |3 | +--+ +--+ +--+ +--+ +--+ +--+ + + | INV - SDP extmap:1 - CLUE demux +------------------------>| | 200 OK - SDP extmap:1 - CLUE demux |<------------------------+ | . . . . . . . . . . . | | | | -----------------------\ |/ Main Video - RTP Session |\_______________________/| | ------------- capture-id | | ----------- extmap tag | v v | | +------+-+-+ | | | data |3|1|-->| | +------+-+-+ | | +-------+-+-+ | | | data |1|1|--> | RTP Packets | +-------+-+-+ | | +-------+-+-+ | | | data |2|1|--> | | +-------+-+-+ | SDP example using extmap id-1 The extmap is a SDP session level attribute, as shown v=0 o=3ss 40471 40471 IN IP4 10.47.197.103 c=IN IP4 10.47.197.103 t=0 0 a=extmap:1 urn:ietf:params:clue:mux SDP showing extmap-1 An example of the RTP extension for a video packet is illustrated below: Hansen, et al. Expires January 11, 2013 [Page 10] Internet-Draft Call Flow for CLUE July 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xDE | length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=1 | len=3 | capture id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | capture id | 0 (pad) | 0 (pad) | 0 (pad) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RTP packet showing extension header for capure-id 5.2.2. RTP extension header for audio rendering tag As explained in draft-romanow-clue-audio-rendering-tag, to support directional audio the receiver needs to know where to render audio in relationship to video captures. In some circumstances the spatial information is not available in the provider advertisement, so the association cannot be made in that way. The proposal for these cases is that the consumer optionally tells the provider an audio tag value corresponding to each of its chosen video captures, which enables received audio to be associated with the correct video stream, even when the set of audible participants changes. In the example provided below, the packet shows dual header extensions - one for associating RTP stream with capture as above, and one for associating audio capture with video capture. The SDP session level attribute extmap id-3 below depicts the identifier being used to signal the audio tag field in the RTP extension header. a=extmap:3 urn:ietf:params:clue:audiotag An example of the RTP header extension for an audio packet is illustrated below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xDE | length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=1 | len=3 | capture id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | capture id | ID=3 | len=0 | tag | 0 (pad) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hansen, et al. Expires January 11, 2013 [Page 11] Internet-Draft Call Flow for CLUE July 2012 RTP packet showing extension header for capture-d and audio tag The default value of these extmap attributes is to be agreed upon in case these lines were dropped by intermediaries or not sent by Alice in the first place. 5.3. CLUE channel establishment using SDP Most importantly, the initial offer/answer negotiates the port and transport information for establishing a CLUE signaling channel. The new application m-line details the information for that. As explained in Sec.4, the CLUE signaling protocol will ride on top of SCTP transport. The following illustrates an unsecure CLUE channel. Alice Bob | INV m=application 6736 UDP/SCTP/CLUE * +--------------------->| | | | | | 200 OK m=application 4536 UDP/SCTP/CLUE * <----------------------+ | | | | |CLUE Signaling Channel| +------------------------------------+ | ............ | | | +------------------------------------+ | | | | CLUE transport channel establishment Hansen, et al. Expires January 11, 2013 [Page 12] Internet-Draft Call Flow for CLUE July 2012 SDP Offer: INVITE bob@biloxi.net SIP/2.0 ... Content-Length: 1000 v=0 .... m=audio... ... m=video... ... m=application 6736 UDP/SCTP/CLUE * SDP Answer: SIP/2.0 200 OK ... Content-Length: 1000 v=0 .... m=audio... m=video... .... m=application 4534 UDP/SCTP/CLUE * The same encrypted with DTLS shall look something as follows. This illustrates including fingerprint hash attribute in the session level of SDP in order for the other side to authenticate the identity while exchanging the certificate during the connection setup. SDP Offer: a=fingerprint: SHA-1 64:02:2A:20:92:CD:DB:80:9F:68:0D:EF:AC:99:95:34:89:C6:7D:34 ... m=application 6736 UDP/DTLS/SCTP/CLUE * a=setup:actpass a=connection:new SDP Answer: a=fingerprint: SHA-1 4B:AC:B7:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:BA ... m=application 4534 UDP/DTLS/SCTP/CLUE * a=setup:passive a=connection:new Hansen, et al. Expires January 11, 2013 [Page 13] Internet-Draft Call Flow for CLUE July 2012 Secure CLUE channel establishment In an unencrypted call the 'setup' parameter in SDP is used to negotiate which participant will listen for an incoming SCTP connection, while the other participant initiates the connection. In an encrypted call using DTLS the 'setup' parameter negotiates which participant will establish the DTLS connection (the same participant then establishes SCTP over the DTLS channel once DTLS has been established). 5.4. Bandwidth considerations for CLUE We discuss two models of bandwidth allocation for CLUE telepresence calls. In the first mechanism bandwidth is allocated as needed through successive re-INVITEs. This has the advantage of being bandwidth efficient but may require multiple re-INVITEs. In the second approach the maximum allowable bandwidth is allocated initially. This saves on re-INVITEs but may allocate bandwidth not needed. 5.4.1. Allocate as you go The bandwidth initially offered by Alice is set to some default value (say for a single-screen system). The bandwidth requirement is bound to change as the call progresses on learning the remote end capabilities and the selections made thereafter. Any increase in the usage of bandwidth based on the selected captures will result in that telepresence endpoint sending out a new re-INVITE requesting the intermediaries to allocate extra bandwidth from their pool. Hansen, et al. Expires January 11, 2013 [Page 14] Internet-Draft Call Flow for CLUE July 2012 Alice (3-screen Bob (3-screen 3-camera) 3-camera) o o o o o o +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ | | | INV (video TIAS bw = 4mb) - Default single stream bw +--------------------->| | 200 OK (video TIAS bw = 4mb) - Default single stream bw <----------------------+ |----------------------> ACK | CLUE Signaling | +---------------------------------+ | --------------> Exchanges each others | <-------------- Provider capabilities +---------------------------------+ | | | .................. | | Alice Chooses to view 3 | Video captures of Bob; | New bw req = 3*4mb = 12mb | | | Bandwidth re-INVITE | | | | INV (video TIAS bw = 12mb) +--------------------->| | 200 OK (video TIAS bw = 4mb) |<---------------------+ |----------------------> ACK | | | .................. | | | + + Allocate bandwidth as needed The advantage of this approach is the usage efficiency, as during the initial call setup the remote endpoint's capabilities are still unknown. Also, even after learning the remote end's capabilities through CLUE, there is no guarantee that Alice shall decide to view all or a subset of the captures there after. So the reserved network bandwidth is the amount that is currently being used. The drawback is the potential need for one or more re-INVITEs for re- negotiating new bandwidth numbers from either side if they choose to Hansen, et al. Expires January 11, 2013 [Page 15] Internet-Draft Call Flow for CLUE July 2012 view additonal captures or choose captures in additional encoding formats. Also due to the asynchronous nature of the consumer requests, the flow is susceptible to glare re-INVITEs. The glare would be more pronounced in the case after the first CLUE provider advertisement exchange. This may be due to these systems being pre-programmed to re-configure themselves immediately after learning each other's capabilities. The following figure illustrates the glare condition. Alice (3-screen Bob (3-screen 3-camera) 3-camera) o o o o o o +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ | | | Call Setup (Initial offer/ans) | . . . . . . . . | | | | CLUE - Provider advertisement exchanges | . . . . . . . . | | | | | Alice chooses Bob chooses to view 3 captures to view 3 captures | | | INV (video bw = 12mb)| +----------------------> xxxx | INV (video bw = 12mb)| xx |<---------------------+ x | 491 Request Pending | x Glare |<---------------------+ x | 491 Request Pending | xx +--------------------->| xxxx | . . . . . . . . . | | | | INV (video TIAS bw = 12mb) +--------------------->| | 200 OK (video TIAS bw = 12mb) |<---------------------+ | | Glare condition in allocate bw as you go Hansen, et al. Expires January 11, 2013 [Page 16] Internet-Draft Call Flow for CLUE July 2012 5.4.2. Pre-allocation of bandwidth An alternate method to avoid the need for multiple re-INVITEs to increase bandwidth is to offer maximum bandwidth size that this device is capable of handling in the initial offer/answer. However this approach risks unnecessary call failures in the case the network bandwidth is provisioned and policed. Alice (3-screen Bob (3-screen 3-camera) 3-camera) o o o o o o +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ | | | Call Setup (Initial offer/ans negotiated 12 mb | to begin with) | . . . . . . . . | | | | CLUE - Provider advertisement exchanges | . . . . . . . . | | | | Since each telepresence systems are operating at | max bandwidth usage, no re-INVITE is required Pre-allocation of maximum bandwidth Implementations must be able to cope with the remote endpoints operating in either mode. 6. CLUE message exchange following call setup This section describes the call flow for CLUE messages. Following the SIP and SDP call setup, CLUE messages are exchanged. There are only 2 types of CLUE messages: provider advertisements and consumer requests. Each participant in a CLUE telepresence conference, whether an endpoint or an MCU, is most likely to act as both provider and consumer, as discussed above. Thus each will send provider advertisements and receive consumer requests for those advertisements; and each will also receive provider advertisements and send consumer requests. Hansen, et al. Expires January 11, 2013 [Page 17] Internet-Draft Call Flow for CLUE July 2012 The provider advertisements will consist of the following data elements: o captures o capture scenes o encoding groups o encodings o simultaneous transmission set The consumer requestsconfigurations will consist of the following data elements: o captures o encodings In considering the sequencing of messages, either participant could be first to send a provider advertisement. The next message, sent by the other participant, could be either a provider advertisement or a consumer request in response to the provider advertisement. This is illustrated in the 2 examples below. The first example shows Bob's provider advertisement sent before he responds to Alice's provider advertisement. The second example shows Bob sending a consumer request in response to Alice's provider advertisement before sending his own provider advertisement. The important thing to keep in mind is that these messages are sent asynchronously and can be sent not only at the beginning of a call, but any time throughout the call when a parameter value has changed. The diagram below shows an example of CLUE messages with provider advertisements back to back. Hansen, et al. Expires January 11, 2013 [Page 18] Internet-Draft Call Flow for CLUE July 2012 Alice Bob | SIP call setup | | <------------------->| | | | CLUE Signaling | +---------------------------------+ | Provider Advertisement | | --------------------> | | Provider Advertisement | | <-------------------- | | Consumer Request | | <-------------------- | | Consumer Request | | --------------------> | +---------------------------------+ | | | .................. | Back-to-back provider advertisements Figure XX shows an example of CLUE messages with provider advertisement directly followed by consumer request. Alice Bob | SIP call setup | | <------------------->| | | | CLUE Signaling | +---------------------------------+ | Provider Advertisement | | --------------------> | | Consumer Request | | <-------------------- | | Provider Advertisement | | <-------------------- | | Consumer Request | | --------------------> | +---------------------------------+ | | | .................. | Provider advertisement followed by consumer request Hansen, et al. Expires January 11, 2013 [Page 19] Internet-Draft Call Flow for CLUE July 2012 Appendix A shows example provider advertisement and consumer request messages related to Section 10. Keep in mind these are not proposals, just examples using data elements taken from the current versions of the draft-romanow-clue-data-model and draft-ietf-clue-framework. 7. Sending and receiving media 7.1. RTP CLUE allows multiple media streams to be multiplexed onto a single RTP session, to reduce the complexity of negotiating independent ports for an asymmetric and variable number of media streams, and aid NAT and SBC traversal. Demultiplexing these media streams is achieved via the urn:ietf:params:clue:demux RTP header extension negotiated in the SIP messages. The provider MUST include this header extension in all media packets sent due to a successfully processed CLUE consumer request. The value of the header extension for a given stream MUST match the value of the 'multiplex-id' element for the associated stream in the consumer request. An example of the RTP header extension section of an RTP packet containing an RTP header extension is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xDE | length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=1 | len=3 | capture id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | capture id | 0 (pad) | 0 (pad) | 0 (pad) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RTP packet showing extension header for capture-id See draft-lennox-clue-rtp-usage for the specifics of the multiplexing process. A receiving device which has sent at least one CLUE consumer request MUST examine RTP packet headers for the presence of this header extension. If it is not present then the packet should be treated as part of a single-stream media stream. If the extension header is present then the value of the capture id allows the various multiplexed streams to be differentiated. Packets with a capture id that does not correspond to one of the ids sent in the most recent Hansen, et al. Expires January 11, 2013 [Page 20] Internet-Draft Call Flow for CLUE July 2012 valid CLUE consumer request MUST be discarded. 7.2. RTCP As described in the preceding session, multiple media streams are multiplexed onto a single RTP session. This RTP session SHOULD be matched by a single set of RTCP messages, sent in a conventional fashion. A device SHOULD send RTCP receiver reports, sender reports, SDES and other packets as it would in the single-stream case. However, when multiple media streams are present each RTCP packet SHOULD contain multiple chunks; each chunk can be used to identify a specific SSRC and include the information relevant to that media stream. This allows standard statistics, packet loss indications and other RTCP metrics to be used. CNAME, as part of the RTCP SDES message, can be used to indicate synchronization between multiple multiplexed media streams when they are generated by encoders sharing a common clock, in the same way it can be used to synchronize streams received on different ports. 8. Interoperability CLUE support in a remote device is identified by the presence of a valid SDP media stream advertising the ability to negotiate the SCTP- based CLUE protocol - absence of this requirement indicates that either the remote device does not support CLUE, or that a middle box in the signaling path has suppressed the ability to do so. A device that receives an SDP offer or answer without a valid media stream advertising the CLUE protocol MUST fall back to a single-stream call until such time as new SDP messages are able to negotiate a CLUE protocol media stream between the devices - see Section 10.1. for details on interoperability with non-CLUE devices. If both sides successfully support CLUE then the call flow proceeds as shown in this draft. Note that as per [RFC3264], both devices MUST be prepared to receive media for any media streams they have advertised as recvonly or sendrecv. The devices SHOULD also begin sending single-stream media once the initial SDP negotiation is complete, while the SCTP channel is being set up and before any CLUE messages are sent or received. This minimizes the time in which a basic single-stream call is established to match that of a conventional non-CLUE system, and ensures a baseline level of interoperability. Once CLUE messages have been received and processed the call will then be 'upgraded' to multistream. Hansen, et al. Expires January 11, 2013 [Page 21] Internet-Draft Call Flow for CLUE July 2012 8.1. Backward compatibility with non-CLUE endpoints One of the requirements of CLUE is that it allows backwards compatibility with devices that are not CLUE-aware, ensuring that a call between a CLUEful device and a conventional non-CLUEful SIP will result in a conventional, single-stream call. The SIP messages sent by a CLUEful endpoint are highly compatible with conventional SIP devices, as all CLUE-specific changes are in the form of additions that will be ignored by a non-CLUE recipient. Audio and video remain specified on separate receive ports in the SDP, which not only allows non-CLUE devices to establish calls as normal, but allows separate QoS settings to be applied to the different media types if desired. A CLUEful SDP will contain one or more RTP header extmap extensions [RFC5285], which will be ignored by non-CLUE devices that do not support negotiation of RTP header extensions, or which do support such negotiation but do not recognise the CLUE-specific extensions. An offer from a CLUE device will contain an m-line specifying the CLUE transport, which the recipient will not understand and will reject (though as per the SDP offer- answer [RFC3264] the m-line itself will remain in the response and further SDPs). A CLUE device that receives an offer or a response either lacking a CLUE protocol m-line or with a rejected CLUE protocol m-line MUST fall back to a standard single-stream call. 9. Mid-call provider advertisement and re-configuration A provider may send a new advertiesment at any time, and a consumer may send a new request at any time (once it has received an initial advertisement). There is not a one-to-one mapping between advertisements and requests - a consumer may send multiple requests to a single advertisement. Advertisements contain a sequence number, while consumer requests contain both a sequence number and a reference to the sequence number of the advertisement to which they correspond - the provider can use these to detect and discard requests relating to a previous, now invalid advertisement. Consumer re-configuration can occur anytime during the course of a call. Possible triggers include but are not restricted to: o New provider advertisement to indicate a changes in captures or encodings. o Change in device configuration (such as availability of new screen) or user selection at the consumer end. The bandwidth requirement and need for re-INVITE is based on the increase or decrease in usage. Implementations can choose Hansen, et al. Expires January 11, 2013 [Page 22] Internet-Draft Call Flow for CLUE July 2012 appropriate bandwidth as discussed previously. It is just that they have to ensure necessary bandwidth is in place before choosing any new captures. The following is a mid-call CLUE provider advertisement from Bob advertising capture-scene with 3 captures as opposed to 2 previously (could be triggered by turning on the 3rd camera. In order to keep the call-flow simple we assume both Alice and Bob allocate a large bandwidth (20Mb). The consumer request is within that bandwidth boundary. Hansen, et al. Expires January 11, 2013 [Page 23] Internet-Draft Call Flow for CLUE July 2012 Alice (3-screen Bob (3-screen 3-camera) 2-camera) o o o o o o +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ | | | Call Setup (Initial offer/ans negotiated max bw | of 20Mb from either side to begin with) +-----------------------------------------------------------+ | | CLUE Provider Advertisement Exchange | | | | | | |adv{[capt-id 1,enc max-bw=8M][capt-id 2,enc max-bw=8M]} | |<---------------------+ |First | | | |CLUE | |adv{[capt-id 1,enc max-bw=6M][capt-id 2,enc max-bw=4M]|Provider | +--------------------->| |Exchange | | [capt-id 3,enc max-bw=10M]} | +-----------------------------------------------------------+ | | +-----------------------------------------------------------+ | | CLUE Consumer Configuration Message | | | | |Initial | |conf{[capt-id 1,enc max-bw=8M][capt-id 2,enc max-bw=8M]}Config | +--------------------->| | | |conf{[capt-id 1,enc max-bw=6M][capt-id 2,enc max-bw=4M]Note: | |<---------------------+ |Alice | | [capt-id 3,enc max-bw=10M]} |has 2 +-----------------------------------------------------------+captures | | to choose | . . . . . . . . . . .| | . . . . . . . . . . .| | | | Bob turns On 3rd camera | o o o | +--+ +--+ +--+ | | | | | | | | +--+ +--+ +--+ |adv{[capt-id 1,enc max-bw=8M][capt-id 2,enc max-bw=8M]}Mid-call |<---------------------+ Provider | | adv by Bob | conf{[capt-id 1,enc max-bw=8M][capt-id 2,enc max-bw=4M] +--------------------->| | [capt-id 3,enc max-bw=8M]} Re-Config | | msg from | | Alice req 3 captures Hansen, et al. Expires January 11, 2013 [Page 24] Internet-Draft Call Flow for CLUE July 2012 Provider advertisement followed by consumer request 10. Example call flow To help illustrate how all the aspects of a multistream call using CLUE tie together, a complete set of SIP and CLUE message is provided for a sample call between two participants. Alice in this example is a three-screen endpoint, with three cameras. She is able to send all three camera streams individually, or can send a single switched video stream (based on the current active speaker, or most recent speaker if no one in her room is speaking). Her system also has three microphones, but only advertises a single, composed audio stream made up of the streams of three microphones mixed together. Bob, in contrast, is an MCU that switches media between different participants in a conference. Bob advertises up to three video streams and three audio streams, with alternate offerings for one- and two-screen systems. Alice (3-screen Bob (switching 3-camera) MCU) | | | INVITE | +--------------------->| | 200 OK | <----------------------+ | ACK | |----------------------> | | | single-stream media | | <..................> | | | +----SCTP over UDP established----+ | ----Advertisement A---> | | <---Advertisement B---- | | ------ Request A-----> | | <----- Request B-----> | +---------------------------------+ | | | multi-stream media | | <..................> | + + Example call flow The flow begins with Alice sending an INVITE to Bob (Appendix A.1.) Hansen, et al. Expires January 11, 2013 [Page 25] Internet-Draft Call Flow for CLUE July 2012 The SDP includes an audio stream, offering AAC and G.711(u), and a video stream offering H264. Alice is limited to receiving 6M of bandwidth. Alice also includes a media line for CLUE over SCTP over UDP (for simplicity in this example the stream is unencrypted). The attributes for the stream show that this is a new connection, and that Alice is willing to be either active or passive with respect to establishment of the media session. Finally, Alice includes an SDP 'extmap' parameter, advertising that she understands the multiplex id RTP header extension, and that Bob should use an ID of 1 to identify such extensions; this parameter is included at the session level, as it applies to both audio and video media streams. Bob responds with a 200 OK (Appendix A.2. - any prior 1xx messages have been elided for brevity). The SDP also includes an audio stream supporting AAC and G.711(u) and a video stream offering H264. Bob is able to receive up to 10M of media. Bob includes a media line for CLUE over SCTP over UDP that matches Alice's; the 'connection:new' attribute corresponds to hers, and Bob chooses to be passive in establishment of the stream. Bob also includes an SDP 'extmap' parameter, in this case specifying that Alice should send multiplexed media with an RTP extension header with an ID of 3. Alice sends an ACK, not included in the appendix. Having completed the initial SIP call setup, Alice and Bob begin sending H264 video and AAC audio in a conventional single-stream fashion. Further, Alice initiates a STCP connection to Bob on port 3782, encapsulated in UDP, as was negotiated in the SDP exchange. With the CLUE transport established both sides are free to begin sending CLUE messages. The call flow shows Alice sending an advertisement before Bob, but in practise there is no correlation between the sending of these messages; Bob may send his message first, or both may be sent simultaneously. Both sides of the CLUe message exchange are independant of one another. Alice's CLUE advertisement includes four video captures (Appendix A.3.) The first three are static captures that correspond to the three cameras of the system, while the final one is a switched capture to show the current active speaker. The static captures give the physical coordinates of the area of capture, in millimetres, while the switched capture does not include an area of capture. There is a single, mixed audio capture, again with no area of capture. The entries for the capture scene allow the recipient to understand which captures provide 'equivalent' views. In this case it illustrates that to get a 'complete' view of the scene the recipient should subscribe to either captures 1, 2 and 3, or to capture 4. Finally, the information in the encoding groups shows Hansen, et al. Expires January 11, 2013 [Page 26] Internet-Draft Call Flow for CLUE July 2012 that while Alice can supply any given video stream at up to 4M, she can only supply a total of 6M of video. In contrast, as a switching MCU Bob has no static captures (Appendix A.4.) Instead, Bob wants to be able to supply one-, two- and three- screen switched capture views. He does this by advertising six video captures with non-physical area of capture coordinates; these coordinates are used to illustrate the fraction of the overall scene a capture represents (and how to render the captures to ensure their adjacency is correct and no multi-screen systems are rendered back- to-front). A similar approach is taken for audio. This is reinforced in the entries, which illustrate the captures to which a recipient should subscribe to receive a 'correct' view of the conference. The encoding information supplied by Bob shows that he is able to supply up to three video streams, with the only encoding maximum that of the 10M advertised in his SDP for the stream total. Having received Bob's CLUE advertisement, Alice then sends her consumer request (Appendix A.5.) As she is a three-screen system she requests video captures 4, 5 and 6, which correspond to the switched captures for a three-screen system. She includes a 'max-bandwidth' element, limiting each stream to 2M. Having two speakers she subscribes to audio captures 8 and 9, which correspond to the two- channel audio advertised by Bob. Having received Alice's CLUE advertisement, Bob sends his initial consumer request (Appendix A.6.) Bob's request is straightforward, requesting the three static camera streams and the mixed audio stream, and adds no additional encoder limitations beyond those already imposed by his SDP. Both Bob and Alice now send multistream audio and video, the RTP packets including the multiplex extension header with capture ids specified in the consumer requests. Note again that, though the example illustrates Alice and Bob sending their CLUE messages in order, this is not a requirement; Alice might send her advertisement, receive Bob's request and begin sending multistream media before ever receiving Bob's advertisement. At any time Alice or Bob may send further CLUE advertisement or request messages, which invalidate previous messages. They may also send SIP messages to update or alter media parameters. 11. Security Considerations This document provides an overview of the call-flow of a CLUE multiscreen telepresence call, and hence is not an appropriate place to definitively identify and deal with security considerations. Hansen, et al. Expires January 11, 2013 [Page 27] Internet-Draft Call Flow for CLUE July 2012 However, it should be clear from the above that CLUE does pose a number of security challenges: for example, the transport conveying CLUE messages must be encryptable in a fashion that limits the potential for man-in-the-middle attacks, while the multiplexing of RTP streams must not interfere with the ability to secure these streams against interception or spoofing. These security considerations will be addresses as part of the specification of these aspects of CLUE, but it is believed that well-understood methods (such as DTLS for the CLUE protocol and SRTP for the media) can be used to secure these channels. 12. Acknowledgements 13. IANA Considerations This draft includes examples of a number of features which, if agreed on by consensus, would have IANA considerations as part of their specification. The examples used here are purely for illustrative purposes, and do not represent the final format of these features; as such this draft has no IANA considerations. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 14.2. Informative References [I-D.ietf-clue-framework] Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino, Hansen, et al. Expires January 11, 2013 [Page 28] Internet-Draft Call Flow for CLUE July 2012 "Framework for Telepresence Multi-Streams", draft-ietf-clue-framework-06 (work in progress), July 2012. [I-D.lennox-clue-rtp-usage] Lennox, J., Witty, P., and A. Romanow, "Real-Time Transport Protocol (RTP) Usage for Telepresence Sessions", draft-lennox-clue-rtp-usage-04 (work in progress), June 2012. [I-D.romanow-clue-audio-rendering-tag] Romanow, A., Hansen, R., Pepperell, A., and B. Baldino, "The need for audio rendering tag mechanism in the CLUE Framework", draft-romanow-clue-audio-rendering-tag-00 (work in progress), May 2012. [I-D.romanow-clue-data-model] Romanow, A. and A. Pepperell, "Data model for the CLUE Framework", draft-romanow-clue-data-model-01 (work in progress), June 2012. [I-D.romanow-clue-sdp-usage] Romanow, A., Andreasen, F., and A. Krishna, "Investigation of Session Description Protocol (SDP) Usage for ControLling mUltiple streams for tElepresence (CLUE)", draft-romanow-clue-sdp-usage-01 (work in progress), March 2012. [I-D.wenger-clue-transport] Wenger, S., Eubanks, M., Even, R., and G. Camarillo, "Transport Options for Clue", draft-wenger-clue-transport-02 (work in progress), March 2012. Appendix A. Example call flow messages Hansen, et al. Expires January 11, 2013 [Page 29] Internet-Draft Call Flow for CLUE July 2012 A.1. INVITE from Alice INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TCP 10.47.197.7:5060;branch=z9hG4bK7251784nf Call-ID: 3ebf09e73b83408f@10.47.197.7 CSeq: 1 INVITE Contact: From: "Alice" ;tag=6d1e0bf6d948f0b8 To: Max-Forwards: 70 Content-Type: application/sdp Content-Length: 525 v=0 o=alice 1 3 IN IP4 10.47.197.7 s=- c=IN IP4 10.47.197.7 b=AS:6000 t=0 0 a=extmap:1 urn:ietf:params:clue:demux m=audio 1000 RTP/AVP 101 0 b=TIAS:64000 a=rtpmap:101 MP4A-LATM/90000 a=fmtp:101 profile-level-id=25;object=23;bitrate=64000 a=rtpmap:0 PCMU/8000 a=sendrecv m=video 1002 RTP/AVP 98 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42e016;max-mbps=35000;max-fs=3600 a=sendrecv m=application 1004 UDP/SCTP/CLUE * a=setup:actpass a=connection:new Hansen, et al. Expires January 11, 2013 [Page 30] Internet-Draft Call Flow for CLUE July 2012 A.2. 200 OK from Bob SIP/2.0 200 OK Via: SIP/2.0/TCP 10.47.197.7:5060;branch=z9hG4bK7251784nf Call-ID: 3ebf09e73b83408f@10.47.197.7 CSeq: 1 INVITE From: "Alice" ;tag=6d1e0bf6d948f0b8 To: ;tag=b91d0ea4 Contact: ;isfocus Content-Type: application/sdp Content-Length: 474 v=0 o=bob 45727 45727 IN IP4 10.47.196.161 s=- c=IN IP4 10.47.196.161 b=AS:10000 t=0 0 a=extmap:3 urn:ietf:params:clue:demux m=audio 3778 RTP/AVP 101 0 a=rtpmap:101 MP4A-LATM/90000 a=fmtp:101 profile-level-id=25;object=23;bitrate=64000 a=sendrecv m=video 3780 RTP/AVP 98 99 34 31 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42e016;max-mbps=244800;max-fs=8160 a=sendrecv m=application 3782 UDP/SCTP/CLUE * a=setup:passive a=connection:new A.3. CLUE advertisement A (from Alice) millimeters video main 1 Hansen, et al. Expires January 11, 2013 [Page 31] Internet-Draft Call Flow for CLUE July 2012 video main 1 video main 1 video main 1 true Hansen, et al. Expires January 11, 2013 [Page 32] Internet-Draft Call Flow for CLUE July 2012 audio main 2 true 6000000 4000000 4000000 4000000 64000 A.4. CLUE advertisement B (from Bob) No Scale Hansen, et al. Expires January 11, 2013 [Page 33] Internet-Draft Call Flow for CLUE July 2012 video main 1 true video main 1 true video main 1 true Hansen, et al. Expires January 11, 2013 [Page 34] Internet-Draft Call Flow for CLUE July 2012 video main 1 true video main 1 true video main 1 true audio main 2 true Hansen, et al. Expires January 11, 2013 [Page 35] Internet-Draft Call Flow for CLUE July 2012 audio main 2 true audio main 2 true audio main 2 true Hansen, et al. Expires January 11, 2013 [Page 36] Internet-Draft Call Flow for CLUE July 2012 audio main 2 true audio main 2 true Hansen, et al. Expires January 11, 2013 [Page 37] Internet-Draft Call Flow for CLUE July 2012 Hansen, et al. Expires January 11, 2013 [Page 38] Internet-Draft Call Flow for CLUE July 2012 A.5. CLUE response A (from Alice) 11 1 2000000 22 2 2000000 44 3 2000000 111 1 222 2 Hansen, et al. Expires January 11, 2013 [Page 39] Internet-Draft Call Flow for CLUE July 2012 A.6. CLUE response B (from Bob) 1 1 2 2 3 3 1 4 Authors' Addresses Robert Hansen Cisco Systems Langley, UK Email: rohanse2@cisco.com Arun Krishna Cisco Systems San Jose, CA USA Email: arukrish@cisco.com Hansen, et al. Expires January 11, 2013 [Page 40] Internet-Draft Call Flow for CLUE July 2012 Allyn Romanow Cisco Systems San Jose, CA 95134 USA Email: allyn@cisco.com Hansen, et al. Expires January 11, 2013 [Page 41]