SIP视频会议中的双流实现
2014-03-24 16:59
399 查看
搜集的一些关于SIP视频会议中实现双流的信息。
来自Radvision的信息
Data Collaboration In Video Conferencing
Guest post bySasha RuditskyCategories:Collaboration,VideoConferencing | September 15, 2009
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 weresuppose to provide the “dual video” functionality. In SIP it is possible to use severalSDPvideo media lines to signal support for multiple video streams.
The “content” attribute defined in theRFC 4796is 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-usersCommunications 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. |
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
相关文章推荐
- SIP视频会议中的双流实现
- 我想了解下 java视频会议远程文档共享 实现的机制 谁能帮我解释下
- 我想了解下 java视频会议远程文档共享 实现的机制 谁能帮我解释下
- IP 视频会议中的组播实现
- 我想了解下 java视频会议远程文档共享 实现的机制 谁能帮我解释下
- 视频监控、视频会议中常用的视频布局实现方法
- 视频会议交互怎么实现
- DirectX技术实现视频会议中的音频通信
- 手机视频会议的实现
- Red5流服务器搭建(实现在线直播,流媒体视频播放和在线视频会议)
- 基于Webrtc的多人视频会议的简单实现
- 视频教程+源代码:FLEX+FMS实现远程共享、电子白板、远程交流会议
- 基于SIP的集中式视频会议模型介绍
- 基于SIP的视频会议系统研究
- Red5流服务器搭建(实现在线直播,流媒体视频播放和在线视频会议)
- 视频会议系统的设计和实现
- Red5流服务器搭建(实现在线直播,流媒体视频播放和在线视频会议)
- JAVA webRtc的实现视频会议系统
- Red5流服务器搭建(实现在线直播,流媒体视频播放和在线视频会议)
- 腾创网络视频会议:实现在线商业社交