One document matched: draft-even-xcon-pnc-02.txt
Differences from draft-even-xcon-pnc-01.txt
XCON R. Even
Internet-Draft Polycom
Intended status: Best Current March 1, 2007
Practice
Expires: September 2, 2007
People and Content video streams
draft-even-xcon-pnc-02.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 September 2, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Even Expires September 2, 2007 [Page 1]
Internet-Draft PNC March 2007
Abstract
This document describes the procedures for using more than one video
channel in SIP based systems enabling the other endpoints to
understand the semantics 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.
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
3.2.1. Floor management policy . . . . . . . . . . . . . . . 6
3.2.2. Floor management for audio and video presentation . . 6
4. Offer answer flow . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Live role using the content alt attribute . . . . . . . . 8
4.2. Presentation role with floor control . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Even Expires September 2, 2007 [Page 2]
Internet-Draft PNC March 2007
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 has a
role as described using the content attribute described in
draft-ietf-mmusic-sdp-media-content-
01[I-D.draft-ietf-mmusic-sdp-media-content]. Floor control is 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 September 2, 2007 [Page 3]
Internet-Draft PNC March 2007
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 September 2, 2007 [Page 4]
Internet-Draft PNC March 2007
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 assigns application semantics to the
additional video stream explaining how the streams should be
presented to and processed by endpoints and MCUs. Under H.239, video
streams are given either 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 similar policies used on
the main video stream. The "Live" role is signaled using the "alt"
content attribute from draft-ietf-mmusic-sdp-media-content-
01[I-D.draft-ietf-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 their application policies that
define media distribution policies. The recommended policy is for
the MCUs to distribute a device's "Live" video stream to all
participants who are also receiving the other video stream from the
device.
Floor control may be used on the "main" and "alt" stream as a group.
3.2. Presentation role procedures
The H.239 "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
Even Expires September 2, 2007 [Page 5]
Internet-Draft PNC March 2007
transmission. Generally, the Presentation channel when 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 attribute from draft-ietf-mmusic-sdp-media-content-
01[I-D.draft-ietf-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. An endpoint that receives
the presentation SHALL not transmit video if it does not own the
floor. 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.
3.2.1. Floor management policy
The floor control sever according to H.239 makes automatic decisions,
there is no floor chair. There is one floor used in this
application. In a multipoint conference, H.239 does not mandate a
specific policy. A RECOMMENDED policy for multipoint conference is
for the floor control server to grant the floor if it is not
assigned. If the floor is assigned the floor control server will
send a FloorRequestStatus with state revoke to the current floor
owner and wait for FloorRelease message from the current owner before
granting the floor to the requesting participant.
In a point to point call, one of the parties is also the floor
control server. The other party may request the floor and the
request will be granted if the party with the floor control server
will not need it.
3.2.2. Floor management for audio and video presentation
The floor control server application can manage the video
presentation and the main audio as a group controlled by one floor.
In this case the MCU will treat the video stream as described in 3.2
and the audio stream will always be in the mix even if it is
currently not one of the highest speaker.
The floor control server will indicate the streams controlled by the
floor in the floor id attribute by listing both labels in the
m-stream parameter as in the following example.
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
Even Expires September 2, 2007 [Page 6]
Internet-Draft PNC March 2007
t=0 0
c=IN IP4 192.0.2.1
m=audio 30000 RTP/AVP 0
a=content:main
a=label:11
m=video 30002 RTP/AVP 31
a=content:main
a=label:12
m=audio 30004 RTP/AVP 0
a=content:alt
a=label:13
m=application 20000 TCP/BFCP *
a=setup:passive
a=connection:new
a=floorid:1 m-stream:11 12
a=floor-control: s-only
a=confid:4321
a=userid:1234
Even Expires September 2, 2007 [Page 7]
Internet-Draft PNC March 2007
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 is a view of
all the room using a second camera.
v=0
o=Alice 292742730 29277831 IN IP4 192.0.2.3
s=Two video streams from the room
c=IN IP4 192.0.2.3
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].
m=application 9 TCP/BFCP *
Even Expires September 2, 2007 [Page 8]
Internet-Draft PNC March 2007
a=setup:active
a=connection:new
a=fingerprint:SHA-1 \
3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21
a=floor-control: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=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=nonce:5736
a=floor-control:s-only
a=confid:4321
a=userid:1234
Even Expires September 2, 2007 [Page 9]
Internet-Draft PNC March 2007
a=floorid:1 m-stream:12
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 September 2, 2007 [Page 10]
Internet-Draft PNC March 2007
5. IANA Considerations
None
Even Expires September 2, 2007 [Page 11]
Internet-Draft PNC March 2007
6. Security Considerations
Will be added
Even Expires September 2, 2007 [Page 12]
Internet-Draft PNC March 2007
7. References
7.1. Normative References
[I-D.draft-ietf-mmusic-sdp-media-content]
Camarillo, G. and J. Hautakorpi, "The SDP (Session
Description Protocol) Content Attribute",
draft-ietf-mmusic-sdp-media-content-01.txt (work in
progress), February 2006.
[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 September 2, 2007 [Page 13]
Internet-Draft PNC March 2007
Author's Address
Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva 49130
Israel
Email: roni.even@polycom.co.il
Even Expires September 2, 2007 [Page 14]
Internet-Draft PNC March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Even Expires September 2, 2007 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 05:31:57 |