蒐集的一些關於SIP視頻會議中實現雙流的信息。
來自Radvision的信息
Data Collaboration In Video Conferencing
Dual Video in SIP
On the other hand, SIP, or to be more precise IETF, defined all the necessary building blocks which when used together were suppose to provide the “dual video” functionality. In SIP it is possible to use severalSDP video media lines to signal support for multiple video streams. The “content” attribute defined in theRFC 4796 is semantically similar to the role parameter in H.239 and applying different content values to the different video media lines provides a simple way to distinguish between them.
IETF also defined in RFC 4582 the Binary Floor Control Protocol (BFCP), which allows control of a conference floor. A floor is a shared conference resource, which is available only to a single participant at a time. If the ability to present is considered such a resource, then it is possible to use BFCP to control the presentation token. In contrast to H.239, BFCP and video streams in SIP are completely unrelated, so a separated mechanism is needed to associate between them.
RFC 4574 defines a label attribute, which allows “stamping” the SDP media lines with labels. It is then possible to refer to these media lines from other places in SDP by using the labels. BFCP media line is using this mechanism to define which video stream is controlled by the BFCP floor control mechanisms.
So SIP got all the building blocks necessary to implement the “dual video” functionality. The problem, however, is that no document defined how all these separate pieces suppose to work together. As a result videoconferencing equipment manufacturers were open to create proprietary interpretation of the protocol semantics. There exist today several variants of standardized, non-interoperable implementations of “dual video” over SIP.
An additional problem is that SIP represents the requirement of backwards compatibility. The single video stream SIP endpoints need to work correctly against the “dual video” endpoints. Unfortunately, the specification of the behavior of the single video endpoint, when it receives the SDP with multiple video streams proved to be rather ambiguous and any straightforward implementations of the dual video endpoints inevitably causes inconsistent behavior of older equipment.
These and similar issues existing today in SIP prompted the creation of the IMTC SIP parity group. The goal of this group is to create specifications detailing the best current practices of the behavior of the SIP entities which would allow both interoperability and backwards compatibility. One of the subgroups of the SIP parity group is dedicated to multiple video streams applications. Several versions of the best practices document are already produced and discussed, and the chances are that the document will be finalized soon. With the completion of this work we should expect more interoperable dual video SIP based conferencing systems to appear on the market.
來自Polycom的信息
UC driving protocol convergence: the road to SIP visual communications is paved with challenges<font face=""">—and benefits—for end-users
Communications News,July, 2008 byStefan Karapetkov
DUAL-VIDEO STREAMS
In H.323 networks, the dual-video streams function is standardized by H.239. The first issue with supporting dual-video streams in SIP is describing the content/presentation stream. In a SIP environment, the session description protocol (SDP) is used to describe media stream parameters. SIP endpoints and conferencing servers have to supportRFC 4574, which defines the "label" attribute in the SDP, and theRFC 4796, which defines the content attribute. Next, the content stream has to be associated with a live stream. This can be done by supportingRFC 3388 grouping of media lines in the SDP.
The remaining issue is how to identify who is sending the content and who is receiving it. This is usually done by tokens (the party that has the token can send content), and token-management protocols ensure there is only one token in the session, and that anyone can request and receive the token. TheRFC 4582 binary flow control protocol (BFCP) defines the token-management mechanism, and can be used for dual-video stream implementation in SIP. Since everything has to be described in SDP, a way also is needed to describe the BFCP streams in SDP. This can be done by supporting the RFC 4583 SDP format for binary floor control protocol streams.
Video-channel control is embedded in H.245, a sub-protocol in the H.323 family. The protocol allows sending messages like "flow control" from the receiver of live and presentation streams back to the sender of these streams, and telling the sender to modify the bit rate, usually to reduce the bit rate when the receiver detects high packet loss. By sending a "fast update" message, the receiver asks the sender to resend a full or intravideo flame(s), usually when a video flame is lost in transmission.
There is still no standard solution for replicating the video channel control functionality in SIP. One method is to use the SIP INFO message because it allows easy mapping of the H.245 messages into SIP. Several vendors in the market have embraced this approach, mainly because interworking between H.245 and SIP INFO is simple to implement and only touches the H.323-SIP signaling.
Far-end camera control (FECC) is a popular feature in visual communications. If H.323 terminals A and B are on a call, the feature allows terminal A to control the camera of terminal B. The assumption is that terminal B has a pan, tilt and zoom camera, and has the FECC feature enabled.
In a group conferencing setting, the key FECC benefit is that users can adjust the image that they get from the remote site, focus on a particular person or a group of people, and then move to another part of the room. In personal video settings, the feature can be used to adjust the camera if the remote party is sitting too close or too far from the camera.
In H.323, FECC is implemented via two standards: H.281 defines the binary data that is transmitted between terminal A and B to control the camera, while H.224 defines the format of the frames that carry the binary data.
In SIP, RFC 4573 MIME type registration for RTP payload format for H.224 registers the H.224 media type, and defines the syntax and the semantics of the SDP parameters needed to support FECC protocol using H.224 in SIP. In effect, RFC 4573 creates a tunnel through the SiP-based network, and allows video endpoints to exchange H.224/H.281 information exactly as they do in H.323-based networks.
下面是一個業內人士的答覆
Overview
- Major topics outlined in best practice document
- BFCP via UDP recommended as default for best practice
|
Function |
H.239 |
Best Practices Profile |
TCP-based BFCP Channel Implementations |
|
Designating Channel Roles |
h239ExtendedVideoCapability roleLabel |
RFC 4796 content attribute |
RFC 4796 content attribute |
|
Token Control Messages |
H.239 Control & Indication messages |
BFCP |
BFCP |
|
Token Control Channel |
H.245 |
UDP-based BFCP |
TCP-based BFCP |
|
Offer/Answer Exchange |
H.245 |
Offer UDP-based BFCP as indicator of support of RBVS. Send re-INVITE for TCP-based BFCP if far-end doesn't support UDP-based BFCP (optional) |
Offer TCP-based BFCP as indicator of support of RBVS |
|
Token Control Channel Security |
None |
DTLS for UDP-based BFCP channel. |
TLS for the BFCP channel. However, there are no known implementations using TLS-based BFCP. |
Hopefully the formatting is okay. Please let me know if not.
The most important aspects are the use of BFCP via UDP, as defined in draft-sandbakken-dispatch-bfcp-udp:
https://datatracker.ietf.org/doc/draft-sandbakken-dispatch-bfcp-udp/
The use of the content attribute as defined in RFC 4796 is important as well.
UDP is used for BFCP instead of TCP because BFCP via TCP does not work well through firewalls.
Best regards,
Charles
