One document matched: draft-even-xcon-pnc-00.txt
XCON R. Even
Internet-Draft Polycom
Expires: March 5, 2006 September 2005
People and Content video streams
draft-even-xcon-pnc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the procedures for using more than one video
channel in SIP based systems enabling the other endpoints to
understand the content of each channel. The document describe how to
label individual channels with a "role". The "role" indicates the
requirements for processing the channel and the role of the channel
content in the SIP call. The procedure address multipoint and point
to point scenarios.
Even Expires March 5, 2006 [Page 1]
Internet-Draft PNC September 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Dual Stream framework . . . . . . . . . . . . . . . . . . . . 5
3.1. Live role procedures . . . . . . . . . . . . . . . . . . . 5
3.2. Presentation role procedures . . . . . . . . . . . . . . . 5
4. Offer answer flow . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Live role using the content alt attribute . . . . . . . . 7
4.2. Presentation role with floor control . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Even Expires March 5, 2006 [Page 2]
Internet-Draft PNC September 2005
1. Introduction
The document describes the procedures for using more than one video
channel during the conference. The first video channel is used to
transmit video from the main camera. The second video channel may
have a role described using the content attribute described in
draft-ietf-mmusic-sdp-media-content-00[I-D.hautakorpi-mmusic-sdp-
media-content]. Floor control may be used based on BFCP[I-D.ietf-
xcon-bfcp]
The procedures described in the document can be used for multipoint
or point to point scenarios and are interoperable with the procedures
described in ITU H.239[ITU.H239] recommendation.
Even Expires March 5, 2006 [Page 3]
Internet-Draft PNC September 2005
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 RFC2119 [RFC2119] and
indicate requirement levels for compliant RTP implementations.
Even Expires March 5, 2006 [Page 4]
Internet-Draft PNC September 2005
3. Dual Stream framework
H.239[ITU.H239] is the ITU standard for implementing "People +
Content" functionality in H.323 and H.320 systems. H.239 specifies
mechanisms for adding additional media channels to conferences, and
how to control presentation video during a multipoint conference
involving H.320/H.323 based signaling systems. H.239 includes the
concept of roles, a notion that spells out the purpose of the
additional video stream and how the streams should be presented to
and processed by endpoints and MCUs. Under H.239, video streams are
given a role of 'Live', meaning that the video stream is processed as
a normal, bidirectional stream, or 'Presentation', meaning that the
stream is defined as a presentation to be distributed to all
endpoints. H.239 also makes it possible for users to hand-off the
role of presenter between endpoints during the meeting using a floor
control mechanism.
3.1. Live role procedures
The "Live" role indicates that the second video channel shall be
distributed, managed, and presented using the traditional means. The
"Live" role is signalled using the alt content attribute from
draft-ietf-mmusic-sdp-media-content-00[I-D.hautakorpi-mmusic-sdp-
media-content]. The "Live" role is appropriate for live video of
meeting participants. The "Live" video channel supplements the main
video channel - it should carry a stream which is less important to
display at end-user systems than the Presentation channel, main
channel or channels without role labels.
"Live" video is two-way transmission; multiple devices may transmit
"Live" video simultaneously.
MCUs that support roles and process "Live" video streams distribute
all live video in accordance with manufacturer-defined conference
policies. MCUs should distribute a device's "Live" video stream to
all participants who are also receiving the other video stream from
the device.
3.2. Presentation role procedures
The "Presentation" role is used to indicate that the video channel
contains a presentation which is intended to be seen by all
conference participants. Transmission on the Presentation channel
shall be managed by a floor control mechanism using BFCP[I-D.ietf-
xcon-bfcp], in order to provide the one-way transmission. Generally,
the Presentation channel when it is in use should carry the stream
which is most important to display at end-user systems. The
"presentation" channel is described using the slides content
Even Expires March 5, 2006 [Page 5]
Internet-Draft PNC September 2005
attribute from draft-ietf-mmusic-sdp-media-content-00[I-D.hautakorpi-
mmusic-sdp-media-content]
For the "Presentation" role, MCUs shall distribute the presentation
video to all devices in the conference which support the
"Presentation" role and its associated video mode. It is optional to
send the presentation video to the sender. The MCU shall also manage
the presentation token in a multipoint call (grants the token). The
MCU shall be the floor control server for the "Presentation" channel
token.
Even Expires March 5, 2006 [Page 6]
Internet-Draft PNC September 2005
4. Offer answer flow
4.1. Live role using the content alt attribute
The following is an example of an offer of two video streams. The
first is the main camera from the room and the second in a view of
all the room using a second camera.
v=0
o=Alice 292742730 29277831 IN IP4 131.163.72.4
s=Two video streams from the room
c=IN IP4 131.164.74.2
t=0 0
m=video 52886 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:main
label:10
m=video 53334 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:alt
a=label:11
4.2. Presentation role with floor control
In this scenario there are two video streams. The first is the main
conference video, the second is a presentation. The right to send
the presentation is controlled by a floor token. One of the users or
the MCU may initiate the floor control channel. In the case of
multipoint the MCU shall be the floor control server.
The following is an example of an offer sent by a client to a MCU
based on ietf-mmusic-sdp-bfcp[I-D.ietf-mmusic-sdp-bfcp]. The
'crypto' attribute is used to generate a shared secret between the
client and the floor control server.
Even Expires March 5, 2006 [Page 7]
Internet-Draft PNC September 2005
m=application 9 TCP/BFCP *
a=setup:active
a=connection:new
a=crypto:1 HMAC-SHA1 inline:c2hhcmVkLXNlY3JldA==
a=floorctrl:c-only
m=audio 25000 RTP/AVP 0
a=label:10
m=video 35000 RTP/AVP 31
a=content:main
a=label:11
m=video 35100 RTP/AVP 31
a=content:slides
a=label:12
The following is the answer returned by the MCU. The MCU assign a
floor only to the presentation channel.
m=application 20000 TCP/BFCP *
a=setup:passive
a=connection:new
a=crypto:1 HMAC-SHA1 inline:c2hhcmVkLXNlY3JldA==
a=nonce:5736
a=floorctrl:s-only
a=confid:4321
a=userid:1234
a=floorid:1 m-stream:12
Even Expires March 5, 2006 [Page 8]
Internet-Draft PNC September 2005
m=audio 20000 RTP/AVP 0
a=label:10
m=video 30000 RTP/AVP 31
a=content:main
a=label:11
m=video 35100 RTP/AVP 31
a=content:slides
a=label:12
The endpoint will initiate the floor control connection to the MCU.
When the endpoint wants to start sending presentation it will send a
floor request as described in
draft-ietf-xcon-bfcp[I-D.ietf-xcon-bfcp]. When the endpoint receives
a floor request status granted, the endpoint can start sending the
presentation. The endpoint shall release the floor when done.
Even Expires March 5, 2006 [Page 9]
Internet-Draft PNC September 2005
5. IANA Considerations
None
Even Expires March 5, 2006 [Page 10]
Internet-Draft PNC September 2005
6. Security Considerations
Will be added
Even Expires March 5, 2006 [Page 11]
Internet-Draft PNC September 2005
7. References
7.1. Normative References
[I-D.hautakorpi-mmusic-sdp-media-content]
Camarillo, G. and J. Hautakorpi, "The SDP (Session
Description Protocol) Content Attribute",
draft-hautakorpi-mmusic-sdp-media-content-01.txt (work in
progress), July 2005.
[I-D.ietf-mmusic-sdp-bfcp]
Camarillo, G., "Session Description Protocol (SDP) Format
for Binary Floor Control Protocol (BFCP) Streams",
draft-ietf-mmusic-sdp-bfcp-02 (work in progress),
July 2005.
[I-D.ietf-xcon-bfcp]
Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-05 (work in progress), July 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[ITU.H239]
International Telecommunications Union, "Role management
and additional media channels", ITU-T Recommendation
H.239, July 2003.
Even Expires March 5, 2006 [Page 12]
Internet-Draft PNC September 2005
Author's Address
Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva 49130
Israel
Email: roni.even@polycom.co.il
Even Expires March 5, 2006 [Page 13]
Internet-Draft PNC September 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Even Expires March 5, 2006 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 05:33:10 |