RTCWeb及WebRTC研究报告

('RTCWeb/WebRTC研究报告IETFRTCWeb草案研究报告目录术语和缩略语..............................................................................................................................-4-前言..............................................................................................................................................-4-1RTCWEB与WEBRTC综述............................................................................................-4-1.1RTCWEB与WEBRTC简介........................................................................................-4-1.2RTCWEB基本结构.....................................................................................................-4-1.2.1浏览器模型.........................................................................................................-4-1.2.2RTCWeb梯形模型.............................................................................................-4-1.3WEBRTC基本结构.....................................................................................................-4-2RTCWEB与WEBRTC规范............................................................................................-4-2.1RTCWEB规范............................................................................................................-4-2.1.1数据传输.............................................................................................................-4-2.1.2数据成帧.............................................................................................................-4-2.1.3数据格式.............................................................................................................-4-2.1.4连接管理.............................................................................................................-4-2.1.5展现和控制.........................................................................................................-4-2.1.6本地系统支持.....................................................................................................-4-2.2WEBRTC规范............................................................................................................-4-2.3关于RTP.....................................................................................................................-4-2.3.1网络拓扑结构.....................................................................................................-4-3.1.1RTP会话的信号要求.........................................................................................-4-3.1.2WebRTC使用的RTP：核心协议.....................................................................-4-3.1.3RTP的优化.........................................................................................................-4-3.1.4RTP的扩展.........................................................................................................-4-4各总司对RTCWEB及WEBRTC规范的提案...............................................................-4-4.1ALVESTRAND提案.......................................................................................................-4-4.2CBRAN提案.................................................................................................................-4-4.3IBC提案......................................................................................................................-4-4.4JENNINGS提案.............................................................................................................-4-4.5JESUP提案...................................................................................................................-4-4.6JOHNSTON提案............................................................................................................-4-4.7KAPLAN提案...............................................................................................................-4-4.8LENNOX提案...............................................................................................................-4-4.9NANDAKUMAR提案....................................................................................................-4-4.10PARTHA提案...............................................................................................................-4-4.11ROSENBERG提案.........................................................................................................-4-4.12JOHOSTON提案............................................................................................................-4-4.13WENGER提案..............................................................................................................-4-4.14针对同一问题不同公司提案的比较..........................................................................-4-4.15公司提案小结.............................................................................................................-4-5RTCWEB与WEBRTC规范的异同点分析....................................................................-4-5.1相同点.........................................................................................................................-4-5.2不同点.........................................................................................................................-4-6总结.....................................................................................................................................-4-第1页IETFRTCWeb草案研究报告主要参考文献..............................................................................................................................-4-第2页IETFRTCWeb草案研究报告术语和缩略语缩写全称解释参考RTCWebReal-TimeCommunicationinWEB-browsers基于网页浏览器的实时通信http://tools.ietf.org/wg/rtcweb/APIApplicationProgrammingInterface应用程序编程接口-aspecificationofasetofcallsandevents,usuallytiedtoaprogramminglanguageoranabstractformalspecificationsuchasWebIDL,withitsdefinedsemantics.[draft-ietf-rtcweb-overview-02]ICEInternetCommunicationsEngine一种面向对象的中间件平台，为构建面向对象的客户—服务器应用提供了工具、API和库支持。Ice应用适合在异种环境中使用：客户和服务器可以用不同的编程语言编写，可以运行在不同的操作系统和机器架构上，并且可以使用多种网络技术进行通信。无论部署环境如何，这些应用的源码都是可移植的。http://baike.baidu.com/view/64590.htm#3&[RFC5245]ICEAgentInternetCommunicationsEngineAgentAnimplementationoftheICEprotocol.[draft-ietf-rtcweb-overview-02]SDPSessionDescriptionProtocol会话描述协议—为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述。会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。SDP即用于将这种信息传输到接收端。SDP是一种会话描述格式，它使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME扩展协议的电子邮件以及超文本传输协议（HTTP）。http://baike.baidu.com/view/875414.htmSDPAgentSessionDescriptionProtocolAgentTheprotocolimplementationinvolvedintheSDPoffer/answerexchange,asdefinedin[RFC3264]section3.[draft-ietf-rtcweb-overview-02]第3页IETFRTCWeb草案研究报告SIPSessionInitiationProtocol会话初始协议－SIP是一个应用层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以好似Internet多媒体会议、IP电话或多媒体分发。会话的参与者可以通过组播（multicast）、网状单播（unicast）或两者的混合体进行通信。使用SIP，服务提供商可以随意选择标准组件。不论媒体内容和参与方数量，用户都可以查找和联系对方。SIP对会话进行协商，以便所有参与方都能够就会话功能达成一致以及进行修改.它甚至可以添加、删除或转移用户。http://baike.baidu.com/view/51013.htmlRTPReal-TimeTransportProtocol实时传输协议RTP详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（PushtoTalk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在用户数据报协议上的。http://baike.baidu.com/view/610472.htmSRTPSecureReal-timeTransportProtocol安全实时传输协议是在实时传输协议(RTP)基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。http://baike.baidu.com/view/985843.htmNATNetworkAddressTranslation网络地址转换－属接入广域网（WAN）技术，是一种将私有网络地址转化为合法IP地址的转换技术，它被广泛应用于各类型Internet接入方式和各种类型的网络中。http://baike.baidu.comXMPPTheExtensibleMessagingandPresenceProtocol可扩展通讯和表示协议－前称Jabber）是一种以XML为基础的开放式实时通信协定，是经由互联网工程工作小组（IETF）通过的互联网标准。XMPP因为被GoogleTalk和网易泡泡应用而被广大网民所接触。http://zh.wikipedia.org/zh-cn/XMPP第4页IETFRTCWeb草案研究报告Jingle－Jingle是XMPP的扩展协议。通过Jingle可以实现点对点（P2P）的多媒体交互会话控制，如：语音交互（VOIP），视频交互。Jingle由Google和XMPP基金会设计。http://en.wikipedia.org/wiki/Jingle_(protocol)STUNSimpleTraversalofUDPoverNATsNAT的UDP简单穿越――是一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间建立UDP通信。该协议由RFC3489定义。http://baike.baidu.com/view/884586.htm第5页IETFRTCWeb草案研究报告前言我们上网用浏览器浏览服务器的页面的过程，实际上是浏览器先通过TCP/IP协议与主机通信并下传文件、再断开TCP/IP连接并显示收到的文件的过程，简单地说，浏览器浏览网页是一种无连接的方式，它不能与服务器实时动态地交换数据并即时更新客户端的浏览信息。这样，在类似网上实时交谈、聊天、寻呼的时候，我们就只有采取定时刷新去取服务器信息更新客户端页面的方法来实现。这样做并不是真正实时的，而只是定时的，总会有一定的时间间隔；同时当连接用户增多时，大量的刷新请求将会造成服务器资源的巨大消耗，以致反应缓慢甚至系统崩溃。另外，在多媒体数据的处理上，如今的浏览器多采用插件或者WEB应用程序，且没有统一的规范和标准。实际上只要浏览器具有必要的接口，它是可以提供几乎任何一种服务的。随着网络带宽以及各种设备和技术的提升，实时的互动的网页通信也将逐渐成为可能。基于浏览器的实时通信允许我们在浏览器上完成视频会议、实时音频通信等功能。这里我们就研究由IETFRTCWeb工作组提出的一系列基于浏览器的网页实时通信的规范草案。虽然该草案尚在完善中，但初步已提出的RTCWeb的工作原理，主要技术和所需要的接口等信息。目前，针对RTCWeb很多公司已经提出相关提案，解决网页实时通信不同方面的问题，我们也将对此进行研究。第6页IETFRTCWeb草案研究报告1RTCWEB与WEBRTC综述1.1RTCWeb与WebRTC简介RTCWeb是TheRealTimeCommunicationontheWeb(RTC-Web)的缩写，为实现用户间不需要插件实时视频音频通信定义标准的协议，接口和API的尝试。WebRTC是一项在浏览器内部进行实时视频和音频通信的技术，是谷歌2010年以6820万美元收购收购GlobalIPSolutions公司而获得一项技术。这是一个可让网友之间通过音频和视频实时交流的开放工程，只要是支持Real-TimeCommunications(RTC)的浏览器都可实现实时音频和视频聊天.WebRTC实现了基于网页的视频会议，标准是WHATWG协议，目的是通过浏览器提供简单的javascript就可以达到实时通讯（Real-TimeCommunications(RTC)）能力。WebRTC提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。第7页IETFRTCWeb草案研究报告1.2RTCWeb基本结构1.2.1浏览器模型1.2.1.1浏览器模型图图11BrowserModel1.2.1.2模型说明Themodelofreal-timesupportforbrowser-basedapplicationsdoesnotenvisagethatthebrowserwillcontainallthefunctionsthatneedtobeperformedinordertohaveafunctionsuchasatelephoneoravideoconferencingunit;thevisionisthatthebrowserwillhavethefunctionsthatareneededforaWebapplication,workinginconjunctionwithitsbackendservers,toimplementthesefunctions.Thismeansthattwovitalinterfacesneedspecification:1)Theprotocolsthatbrowserstalktoeachother,withoutanyinterveningservers,2)andtheAPIsthatareofferedforaJavascriptapplicationtotakeadvantageofthebrowser\'sfunctionality.第8页IETFRTCWeb草案研究报告1.2.2RTCWeb梯形模型1.2.2.1RTCWeb梯形模型图图12BrowserRTCTrapezoid1.2.2.2模型说明Onthisdrawing,thecriticalparttonoteisthatthemediapath("lowpath")goesdirectlybetweenthebrowsers,soithastobeConformant（符合）tothespecificationsoftheRTCWEBprotocolsuite;thesignallingpath("highpath")goesviaserversthatcanmodify,translateormassagethesignalsasneeded.这个模型中的各个部分分别需要一些功能组，在第二部分中我们分析在RTCWeb中所需要的基本功能和相关的技术。第9页IETFRTCWeb草案研究报告1.3WebRTC基本结构图13WebRTC体系结构图1.视频WebRTC的视频部分，包含采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。2.音频WebRTC的音频部分，包含设备、编解码(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控(RTP/RTCP)等功能。第10页IETFRTCWeb草案研究报告2RTCWEB与WEBRTC规范2.1RTCWEB规范在IETF提出的RTCWEB规范中，对应模型的不同层次提出了一些基本的功能需求，下面我们就来看看这些功能组。2.1.1数据传输——建立安全的链接，拥塞控制，带宽分配等Datatransport:TCP,UDPandthemeanstosecurelysetupconnectionsbetweenentities,aswellasthefunctionsfordecidingwhentosenddata:Congestionmanagement,bandwidthestimationandsoon.Datatransportreferstothesendingandreceivingofdataoverthenetworkinterfaces,thechoiceofnetwork-layeraddressesateachendofthecommunication,andtheinteractionwithanyintermediateentitiesthathandlethedata,butdonotmodifyit(suchasTURNrelays).Itincludesnecessaryfunctionsforcongestioncontrol:Whennottosenddata.ICEisrequiredforallmediapathsthatuseUDP;inadditiontotheabilitytopassNATboxes,ICEfulfilstheneedforguaranteeingthatthemediapathisgoingtoanUDPportthatiswillingtoreceivethedata.2.1.2数据成帧——规定数据包的格式Dataframing:RTPandotherdataformatsthatserveascontainers,andtheirfunctionsfordataconfidentialityandintegrity.TheformatformediatransportisRTP[RFC3550].ImplementationofSRTP[RFC3711]isrequiredforallimplementations.RTP的使用：见文档2.3部分2.1.3数据格式——系统中数据的编译码器说明，格式说明，功能性说明Dataformats:Codecspecifications,formatspecificationsandfunctionalityspecificationsforthedatapassedbetweensystems.Audioandvideocodecs,aswellasformatsfordataanddocumentsharing,belonginthiscategory.Inordertomakeuseofdataformats,awaytodescribethem,asessiondescription,isneeded.Theintentofthisspecificationistoalloweachcommunicationseventtousethedataformatsthatarebestsuitedforthatparticularinstance,whereaformatissupportedbybothsidesoftheconnection.However,aminimumstandardisgreatlyhelpfulinordertoensurethatcommunicationcanbeachieved.Thisdocumentspecifiesaminimumbaselinethatwillbesupportedbyallimplementationsofthisspecification,andleavesfurthercodecstobeincludedatthewilloftheimplementor.第11页IETFRTCWeb草案研究报告2.1.4连接管理——会话的连接建立，分析数据格式，改变会话过程中的数据格式Connectionmanagement:Settingupconnections,agreeingondataformats,changingdataformatsduringthedurationofacall;SIPandJingle/XMPPbelonginthiscategory.连接管理部分包括多方面的规范和原则，不同公司也提出了一些相关的提案，我们将在第三部分中讨论。2.1.5展现和控制——包括地面控制，屏幕布局，声控，图像切换及其他等功能Presentationandcontrol:Whatneedstohappeninordertoensurethatinteractionsbehaveinanon-surprisingmanner.Thiscanincludefloorcontrol,screenlayout,voiceactivatedimageswitchingandothersuchfunctions-wherepartofthesystemrequirethecooperationbetweenparties.Cisco/Tandberg\'sTIPwasoneattemptatspecifyingthisfunctionality.Themostimportantpartofcontrolistheuser\'scontroloverthebrowser\'sinteractionwithinput/outputdevicesandcommunicationschannels.Itisimportantthattheuserhavesomewayoffiguringoutwherehisaudio,videoortextingisbeingsent,forwhatpurportedreason,andwhatguaranteesaremadebythepartiesthatformpartofthiscontrolchannel.Thisislargelyalocalfunctionbetweenthebrowser,theunderlyingoperatingsystemandtheuserinterface;thisisbeingworkedonaspartoftheW3CAPIeffort.2.1.6本地系统支持Localsystemsupportfunctions:Thesearethingsthatneednotbespecifieduniformly一律地,becauseeachparticipantmaychoosetodotheseinawayoftheparticipant\'schoosing,withoutaffectingthebitsonthewireinawaythatothershavetobecognizantof.Examplesinthiscategory类别includeechocancellation(someformsofit),localauthenticationandauthorizationmechanisms,OSaccesscontrolandtheabilitytodolocalrecordingofconversations.对于本地系统，有一些功能的质量强烈地影响了用户体验，但确切的算法并不需要协调。整个系统的定义可能需要指定整个系统对于那些有用的设备需要哪些特点，但并不需要要求这些设备按照一个固定的方式执行。2.2WEBRTC规范WEBRTC主要是对APIs进行了规范，规范中定义了音视频的步骤：\uf0b7Representingamultimediastream(video,audio,orboth)fromlocaldevices(videocameras,microphones,Webcams)orfromprerecordedfilesprovidedbytheuser.\uf0b7Recordingsuchstreamslocally.\uf0b7ConnectingtoremotepeersusingNAT-traversaltechnologiessuchasICE,STUN,andTURN.\uf0b7Sendingthelocally-producedstreamstoremotepeersandreceivingstreamsfromremotepeers.\uf0b7Displayingsuchstreams(boththelocally-producedonesandtheremotely-obtainedones)locallyusingthevideooraudioelements.\uf0b7Sendingarbitrarydatatoremotepeers.WEBRTC具体对StreamAPI,p2pconnectionAPI,及垃圾回收进行了规范。具体参照：http://dev.w3.org/2011/webrtc/editor/webrtc.html第12页IETFRTCWeb草案研究报告WEBRTC开发团队对W3C标准仍在开发中，所以规范随时会有大范围的改动。2.3关于RTP由于对实现RTC，IETF和W3C是合作的，在IETF的规范文档中也就WEBRTC项目使用RTP协议进行了一个建议和规范：网络实时通信（WebRTC）框架，旨在通过使用音频，视频，合作，游戏等提供直接的互动丰富的浏览器之间的通信。接下来主要介绍实时传输协议（RTP）是如何在webRTC这个框架中使用的。参考[draft-ietf-rtcweb-rtp-usage-01]2.3.1网络拓扑结构1PointtoPoint+---++---+A<------->B+---++---+图3-1PointtoPoint一个用户对应一个程序会很常见2Multi-unicast+---++---+A<---->B+---++---+^^\\/\\/vv+---+C+---+图3-2Multi-unicast用于小型会议：每一个人都发送个人单播的RTP/UDP流向其他参与者，很占带宽eg：如果有5个与会者，一个消息就要复制4份）这种拓扑结构很有可能作为一个单独的RTP会话。3RTPMixerwithOnlyUnicastPaths+---++------------++---+A<----><---->B+---++---+Mixer+---++---+C<----><---->D第13页IETFRTCWeb草案研究报告+---++------------++---+图3-3RTPMixerwithOnlyUnicastPathsAnRTPmixer(Figure3)isacentralisedpointthatselectsormixescontentinaconferencetooptimisetheRTPsessionsothateachend-pointonlyneedsconnecttooneentity,themixer.Themixeralsoreducesthebit-rateneedsasthemediasentfromthemixertotheend-pointcanbeoptimisedindifferentways.Theseoptimizationsincludemethodslikeonlychoosingmediafromthecurrentlymostactivespeakerormixingtogetheraudiosothatonlyoneaudiostreamisrequiredinsteadof3inthedepictedscenario.Thedownsideofthemixeristhatsomeoneisrequiredtoprovidetheactualmixer.4RTPTranslator(Relay)withOnlyUnicastPaths+---++------------++---+A<----><---->B+---++---+Translator+---++---+C<----><---->D+---++------------++---+图3-4RTPTranslator(Relay)withOnlyUnicastPaths5TranslatortowardsLegacyend-point+------------++---++---+A<---->Translator<---->B+---++---++------------+图3-5TranslatortowardsLegacyend-point3.1.1RTP会话的信号要求1SignallingforRTPsessions2(Lackof)SignallingforPayloadFormatChanges3.1.2WebRTC使用的RTP：核心协议1RTP和RTCP：实时传输协议：REQUIRED两部分组成：数据传输协议和RTP控制协议（RTCP）2RTP/SAVPF：安全方面的协议：REQUIRED3.1.3RTP的优化1RTP和RTCP的复用：RPT数据包和控制包在一个端口的复用是REQUIRED的。2缩减RTCP的尺寸：REQUIRED3对称的RTP/RTCP协议：发包和接收包的IP地址和端口数量是相同的：REQUIRED第14页IETFRTCWeb草案研究报告3.1.4RTP的扩展1会议扩展：OPTIONAL2头扩展：REQUIRED3快速同步扩展：RECOMMENDED第15页IETFRTCWeb草案研究报告4各总司对RTCWEB及WEBRTC规范的提案4.1Alvestrand提案提案文件：[draft-alvestrand-rtcweb-congestion-01]涉及问题：RTCWebDatatransport－拥塞控制主要内容：两种拥塞控制算法－接收端控制与发送端控制内容概要：Therearetwocongestioncontrolalgorithmsthattogetherareseentogivereasonableperformanceandreasonable(notperfect)bandwidthsharingwithotherconferencesandwithTCP-usingapplicationsthatsharethesamelinks.Thetwocongestioncontrolalgorithmsaresendersidecontrolalgorithmandreceiversidecontrolalgorithm.Thereceive-sidealgorithmcanbefurtherdecomposedintothreeparts:anarrival-timefilter,anover-usedetector,andaremoterate-control.Anadditionalcongestioncontrollerresidesatthesendingside.Itbasesitsdecisionsontheround-triptime,packetlossandavailablebandwidthestimatestransmittedfromthereceivingside.Together,sendersidecontrolandreceiversidecontrolimplementthecongestioncontrolalgorithm.4.2Cbran提案提案文件：[draft-cbran-rtcweb-media-00]&[draft-cbran-rtcweb-data-00]涉及问题：RTCWebDataframing－实时的多媒体数据和非多媒体数据的传输协议和要求主要内容：Thesetwodocumentsoutlinethatthereal-timemediaandnon-mediadatatransportprotocolsandrequirementsforRTC-Webclientapplications.提出方法：对于多媒体数据采用的是：拓展的RTP/RTCP对于非多媒体数据采用的提议：每个应用程序数据报发送一个字节的头，以帮助解复用的问题。合并后的数据报和头通过UDP或DTLS发送给接收方。接收器发送一个确认它收到的每一个数据包。通过接收方向发送方发送ack的方法，用TFRC-SP[RFC4828]计算出可使用的最大带宽，从而限制发送方发送数据所使用的带宽。――――提案文件：[draft-cbran-rtcweb-codec-01]涉及问题：WebRTC－编译码器需求主要内容：ThisdocumentoutlinesthecodecandmediaprocessingrequirementsforWebRTCclientapplicationandendpointdevices.内容概要：Audiocodecrequirements；Videocodecrequirement；WebRTCclientrequirements.――――提案文件：[draft-cbran-rtcweb-nat-02]涉及问题：WebRTC－NAT第16页IETFRTCWeb草案研究报告主要内容：Thisdocumentoutlinesthenetworkaddresstranslation(NAT)traversalrequirementsandforWebRTCclientapplications.内容概要：ConnectionManagementRequirements：NATTraversalRequirements；DataTransmissionRequirements；IPv4toIPv6TransitionRequirements；LegacyPhoneSystemInteroperabilityRequirements.ConnectionManagementMechanism：ICEasaConsentMechanism；NativeICESupport；STUNConfiguration.――――提案文件：[draft-cbran-rtcweb-negotiation-00]涉及问题：RTCWebConnectionmanagement－协商与信令主要内容：ThisdocumentoutlinesthenegotiationandsignalingprotocolsforRTC-Webclientapplicationimplementation.内容概要：NegotiationRequirements：ThewebbrowserMUSTimplementICEsuchthatadherestotheRTC-WebNATdraft[I-D.cbran-jennings-rtc-web-nat].SignalingProtocolRequirements：asmallsubsetofSIPwillbeREQUIREDforallRTC-WEBclientapplicationimplementations.InadditiontothesubsetofSIPspecification[RFC3261],RTC-WEBclientapplicationimplementationswillbeREQUIREDtosupportDNSresolutionsasspecifiedin[RFC3263]andtheoffer/answermodelwithSDPasspecifiedin[RFC3264].――――提案文件：[draft-cbran-rtcweb-protocols-00]涉及问题：RTCWeb－communicationprotocols主要内容：ThisdocumentoutlinesthatthecommunicationprotocolsforrealizingRTCWebfunctionalitywithinapplicationssuchaswebbrowsers.Thisdocumentalsoproposesasetofapplicationprogramminginterface(API)requirementsforcontrollingtheprotocolstack.内容概要：这是一个综合性的文档，包括了之前的五个文档的主要内容和一些新内容。从ProtocolRequirements，APIRequirements，LegacyVoIPInteroperability几个方面介绍了RTCWEB协议。4.3IBC提案提案文件：[draft-ibc-rtcweb-sip-websocket-00]涉及问题：RTCWeb－WebSocketTransportforSIP主要内容：ThisdocumentspecifiesaWebSocketsubprotocolforanewtransportinSIP(SessionInitiationProtocol).内容概要：TheWebSocketprotocolenablestwo-wayrealtimecommunicationbetweenclients(typicallyweb-basedapplications)andservers.ThemaingoalofthisspecificationistointegratetheSIPprotocolwithinwebapplications.使用WebSocket可以让客户端与服务器端通过socket端口来传递数据，这样做的好处是可以实现数据推送技术——服务器端不再是被动堤等待客户端发出的请求，只要客户端有一个被打开的socket与服务器端建立了一次连接之后，服务器端就可以在需要的时候，主动地将数据推送到客户端，不再需要轮询客户端的请求，直到客户端显示关闭这个连接。第17页IETFRTCWeb草案研究报告4.4Jennings提案提案文件：[draft-jennings-rtcweb-signaling-01]涉及问题：RTCWebConnectionmanagement－ROAP(RTCWebOffer/AnswerProtocol)主要内容：ThisspecificationdefinesaprotocolthatallowsanRTCWebbrowsertoexchangeinformationtocontrolthesetupofmediatoanotherbrowserordevice.内容概要：该提案定义了用于建立RTCWeb浏览器之间媒体协商、媒体会话建立的ROAP协议。该协议要求发送方和接收方先后发送OFFER(发送方发出请求)、ANSWER(接收方确认收到OFFER)、OK(发送方确认收到ANSWER)。除此之外还有SHUTDOWN、ERROR等。这些信息都将通过可靠的传输协议被携带发送，因此ROAP也是可靠的。在这个过程中有两种状态：sessionstateandrequeststate，应答者必须携带与发送者相同的状态。――――提案文件：[draft-jennings-rtcweb-signaling-gateway-00]涉及问题：RTCWebConnectionmanagement－GatewaybetweenROAPandSIP主要内容：ThisdocumentproposesbehaviorofaRTCWebsignalinggatewayformappingmessagerepresentationsbetweenRTCWebOffer/AnswerProtocol(ROAP)schemeandnativeSIPmessagingscheme.内容概要：该提案介绍了RTCWeb信令网关，通过该网关，RTCWeb浏览器可以与使用SIP协议的通信终端建立会话、在会话中插入多媒体信息、结束会话。同时，提案规定了该网关如何处理SIP请求、SIP响应和Web消息。（还有一些limitations）4.5Jesup提案提案文件：[draft-jesup-rtcweb-data-01]涉及问题：RTCWebDatagramConnection主要内容：ThisdocumentprovidesRequirementandusecasesforbothunreliableandreliablepeertopeerdatagrambasechannel,provideanoverviewoftheproandconsofthedifferentproposedsolutions,andfinallyanalyzeinmoredetailtheSCTPbasedsolution.内容概要：该文档提出了therequirementsforP2Pdataconnectionsbetweentwobrowsers.之后，列出了在可靠传输和不可靠传输两种情况下的一些use-case。提案重点从正反两面分析了几种数据传输提议，包括：DatagramsoverDTLSoverDCCPoverUDP；DatagramsoverSCTPoverDTLSoverUDP；AnewprotocolontopofUDP；TCPoverDTLSoverUDP；ARTPcompatibleprotocol。重点介绍了SCTP/DTLS/UDP，这个协议栈可以在几乎所有操作系统上得到实现，认为SCTP能提供强大的功能。之后，又对SCTP/DTLS/UDP和DTLS/SCTP/UDP做了比较。4.6Johnston提案提案文件：[draft-johnston-rtcweb-media-privacy-00]涉及内容：RTCWEB媒体隐私与安全主要内容：针对RTCWEB媒体安全以及隐私问题，描述了RTCWEB需要的安全需求，提出一个自己主张的ZRTP密钥管理协议。第18页IETFRTCWeb草案研究报告内容概要：Zrtp是一个完全独立的密钥管理协议,它最初被设计作为rtp的扩展，但是现在作为独立的协议运行于相同的端口和ip地址的rtp流。现在，zrtp同sip，jingle一起使用，唯一的需求是他们用媒体rtp。这种灵活性是其他密钥管理协议不能媲美的。它实现了自己的发现机制，它利用DiffieHellman密钥交换来为srtp产生密钥。Zrtp避免了使用公共密钥基础设施的需要，而是利用从SSH和密钥连续性借鉴的技术。曾经在许多场景媒体不能实现端到端加密，比如，当一个用户相信一个服务器时，对于这些情况，zrtp开发了一些机制用来处理这些情况，这些都没有违反基本的安全协议，或者允许任意的MITM实体在信道内。对于RTCWeb应用，也许有web服务应用提供媒体服务，但是需要信道权限的情况，zrtp能够支持这些情况，允许用户明确地对其进行授权，同时不影响zrtp的其他优点。ZRTP符合RTCWEB的媒体安全要求，符合RTCWEB的努力方向。4.7Kaplan提案提案文件：[draft-kaplan-rtcweb-api-reqs-01]涉及问题：APIRequirementsforWebRTC-enabledBrowsers主要内容：该提案讨论了几项建议方法的优点和缺点，关于什么类型的API和WebRTC浏览器的结构模型应该展现和使用。该提案还提出了一个API初始需求列表。内容概要：提案讨论了在浏览器中定义WebRTC协议（包括sessionsignaling和SDPoffer/answer）的优缺点。结论是，它们不利于应用的webrtc化，总体上说是反对这个web应用模型的，认为应该依托强大的JS库，将逻辑控制留給web开发人员。因此，这个文件还定义了对于API的一些他们认为更适合浏览器的初始需求列表。――――提案文件：[draft-kaplan-rtcweb-sip-interworking-requirements-01]涉及问题：RequirementsforInterworkingWebRTCwithCurrentSIPDeployments主要内容：ThisdocumentlistssomeWebRTC-to-SIPuse-cases,theWebRTCrequirementstosupportsuch,andthecomplexityinvolvedininterworkingiftherequirementscannotbemet.内容概要：Thegoalofthisdocumentistosummarizetheuse-casesforcommunicatingwithdeployedSIPdevicesanddomains,andcapturetherequirementsnecessarytodosowithoutusinganInterworkingFunction,ortominimizeitscost/complexity.TheimpactsordifficultieswithvariousInterworkingFunctionneedsarealsodiscussed,inordertotrytominimizethecostandcomplexityofusingthem.4.8Lennox提案提案文件：[draft-lennox-rtcweb-rtp-media-type-mux-00]涉及问题：通过单一RTPsession传输媒体流的机制和推荐做法。主要内容：该提案描述了如何利用单一RTPsession来实现多媒体流的传输内容概要：1.利用单一RTPsession来实现多媒体流的传输的步骤：(1)Eachstream(ofeverymediatype)isadistinctsource(distinctstreamofconsecutivepacketstobesenttoadecoder)andisgivenadistinctsynchronizationsourceID(SSRC),andhasitsowndistincttimestampandsequencenumberspace.第19页IETFRTCWeb草案研究报告(2)Everymediatype(fullmediatypeandsubtype,e.g.video/h264oraudio/pcmu)hasadistinctpayloadtypevalue.Thesamepayloadtypevaluemappingsapplyacrossallsourcesinthesession.(3)RTPSSRCs,initialsequencenumbers,andinitialtimestampsarechosenatrandom,independentlyforeachsource(ofeachmediatype).(4)RTCPbandwidthisfivepercentofthetotalRTPsessionbandwidth.(5)RTPsessionbandwidthandRTCPbandwidtharedividedamongallthesourcesinthesession.(6)RTCPsenderreport(SR)orreceiverreport(RR)packets,andsourcedescription(SDES)packets,aresentperiodicallyforeverysourceinthesession.2.向后兼容性：对于RTCWEB，预计要全程使用ICE.4.9Nandakumar提案提案文件：[draft-nandakumar-rtcweb-turn-uri-00]涉及问题：TURN协议URI计划主要内容：ThisdocumentisthespecificationofthesyntaxandsemanticsoftheUniformResourceIdentifier(URI)schemefortheTraversalUsingRelaysaroundNAT(TURN)protocol.内容概要：URI计划定义包括URI语法定义和URI语义定义1.URI语法：\'turn\'URI的非规范定义：turn:@:turns:@:\'turn\'URI的规范定义：第20页IETFRTCWeb草案研究报告2.URI语义定义：Turn协议支持通过UDP,TCP和TLS-over-TCP发送消息，表示TURN服务器，用来识别长期验证的。————提案文件：[draft-nandakumar-rtcweb-stun-uri-00]涉及问题：STUN协议URI计划主要内容：ThisdocumentisthespecificationofthesyntaxandsemanticsoftheUniformResourceIdentifier(URI)schemefortheSessionTraversalUtilitiesforNAT(STUN)protocol.内容概要：1.URI语法：\'STUN/STUNS\'URI的非规范定义：\'STUN/STUNS\'URI的规范定义：第21页IETFRTCWeb草案研究报告2.URI语义：STUN协议支持通过UDP,TCP和TLS-over-TCP发送消息，表示STUN服务器，用来识别长期验证的,但是是供选的也许不会被使用的。4.10Partha提案提案文件：[draft-partha-rtcweb-signaling-00]涉及内容：浏览器间的实时通信标准化主要内容：用标准的接口可以让兼容的浏览器间可以建立交互通信，而RTCWEB指定JavascriptAPI用来开发web应用。用JavascriptAPI开发类似SIP,Jingle,Websocket的信令协议是可实现的。第22页IETFRTCWeb草案研究报告该公司提出的标准主要集中在标准化RTCWEB的浏览器和RTCWEB服务器间的通信。没有标准的RTCWEB信令协议时面临的问题：(1)WithoutRTCWebstandardsignalingprotocol,eachwebsitedeveloperhastounderstandthecomplicationofsignalingprotocolformakingthereal-timecommunication.(2)DownloadingthecompleteRTCWebsignalingprotocolJavascriptisinefficientasitimpactperformanceandsetupdelayofreal-timecommunication.ThecachingofJavascriptshallavoiddownloadingthesignalingprotocolineachtimeRTCWebserverisaccessed.ButtheJavascriptcacheispossibletoberemovedoftenwhichleadstotheimpact.(3)Also,browserhastodownloadeachwebsitesignalingprotocolIndepentely(4)PluginisefficientasstandardsignalingprotocolbutdefeatthepurposeofRTCWebcharter标准的RTCWEB通讯协议的优势：(1)RTCWebdeveloperhasnoneedtoknowtheintricaciesofsignalingprotocolfordevelopingRTCWebapplication.TheeffortinvolvedinmakingvoiceorvideochatbyeachwebdevelopershallbeovercomebyprovidingstandardsignalinginRTCWebclient(2)GatewayforRTCWebserverandlegacysignalingprotocoliseasyincasestandardRTCwebsignalingprotocolisused.(3)MoreefficientincaseofbrowserhavingnativeRTCWebsignalingprotocolinbrowser4.11Rosenberg提案提案文件：[draft-rosenberg-rtcweb-rtpmux-00]涉及内容：提出视频音频多路复用通过一个RTP会议传输主要内容：为了实现多路复用，RTP头中的SSRC值被分成下面几个子域TheMagicCookieistwobytes,withavalueof0xf7b3.ItismeanttofacilitateDPIapplicationswhichcanuseitsvalueto-withhighconfidence-determinethatthisRTPpacketusestheencodingformatdefinedhere.Thetypeisa3bitvalue,correspondingtothetop-levelMIMEtypeofthemedia(mappingtableTBD).IttooismeanttofacilitateDPIapplicationswhichwanttoseparatevoiceandvideo.ThestreamIDisa12bitfieldwhichrepresentstheuniqueIDforthisstream.Itissignaledbetweenparticipantsoutofband.Thefinalbit,\'x\'issettozeroandisreservedforfutureusage.视频音频多路复用通过一个RTP会议传输的优点可以掩盖掉它的缺点，最主要的益处是它对NAT能力的影响，这在现代网络中已经变的非常重要，而且，对于RTCWEB向后兼容的第一无二的特性减少了对于交互性的担心。第23页IETFRTCWeb草案研究报告4.12Johoston提案提案文件：[draft-sipdoc-rtcweb-open-wire-protocol-00]涉及内容：RTCweb明线协议主要内容：RTCWeb没有在点与点之间定义用来实现媒体会话的协议，取而代之的是在web浏览器定义了协议。规范的目的是说出RTCweb的各个组件，以及澄清那个组件是留给web开发者的，那些是要用户要被RTCWeb规范授权使用的提案总共选取了四个假想的场景，每个场景都应用自己的明线协议，让所有这些场景应用一个协议和消息形式很难，每个场景的需要也不同，自定义的部分也不同。在web上，每个网络站点决定了如何实现想提供给用户的特征和权限。为消息格式授权不符合web的特点，授权模式会让rtcweb整合现存的已经实现了自己独特特征和功能的网络站点带来困难Rtcweb将消除实时通信服务的隔阂，它要充当web的角色，这其中包括提供给开发者自己想要的选择来创新，为用户提供新的服务。这是web成功的关键。提案目的：为了使使用协议达到统一，而不需要授权，授权的形式不符合web灵活性的特点。研究阶段：只是遐想阶段，因为规范中描述的还都是遐想的场景。4.13Wenger提案提案文件：[draft-wenger-rtcweb-layered-codec-00]涉及内容：Wenger提倡对RTCweb标准进行强制的可扩展编码的支持，如果由于各种原因不能实现，那么没有强制编解码器会比强制用一个劣质的不可扩展的编解码更好。主要内容：Wenger用视频编解码作为例子来呈现可扩张的编解码比不可扩展的更适合RTCWeb.Wenger分别从浏览器到浏览器应用，电话应用，视频会议应用，嵌入式语音会议应用等几个方面，展示了可扩展性编解码器的优点。(1)暂时的可扩展性能够提高错误恢复能力；(2)空间可扩展性提高了视频分辨率；(3)编码专家当碰到频宽问题时更愿意脱离像素；(4)空间的可扩展性也加快了视频反应速度。4.14针对同一问题不同公司提案的比较Data相关提案：[draft-cbran-rtcweb-data-00]vs.[draft-jesup-rtcweb-data-01]提案比较：Cbran提案通过添加1字节的报头的方法来解决复用问题，用TFRC-SP算法来计算最大带宽，以限制应用程序的发包率，从而进行拥塞控制。思路和方法都相对简单。Jesup提案则分析了各种不同的报文，认为DatagramsoverSCTPoverDTLSoverUDP是一种值得提倡的解决方案。认为SCTP可以提供一些很好的功能，包括：多数据流，有序和无序交付，可靠性和部分可靠性和动态地址重新配置Signaling相关提案：[draft-jennings-rtcweb-signaling-01]vs.[draft-partha-rtcweb-signaling-00]第24页IETFRTCWeb草案研究报告提案比较：Jennings公司提出一个ROAP协议，该协议用于建立RTCWeb浏览器之间媒体协商、媒体会话建立，Jennings公司证明ROAP的可靠性。Partha公司则是为了实现RTCWEB浏览器和RTCWEB服务器间通讯协议的标准化而提出了一个通讯协议。该公司的提案针对在没有标准通讯协议的劣势和有了的优势阐明了实现协议标准化的重要性。两个公司针对通讯问题提出了两个提案，分别针对不同的方面进行了阐述，都为实现RTCWEB的标准化而进行了努力。4.15公司提案小结通过以上对各个公司提案的简单介绍，我们可以看到，不同的公司针对同一或不同的问题从相同的或者不同的侧面提出了一些想法和规范。也许，我们不能说各个公司提出的方案一定趋于对自己有利的形式，或者哪家的规范更为合理，但这种百家争鸣的现象还是值得称赞的。由此我们也能看出RTCWeb和WebRTC巨大的应用前景，相信在相关领域能有所建树的企业，一定能在以后的互联网行业中占据鳌头。第25页IETFRTCWeb草案研究报告5RTCWEB与WEBRTC规范的异同点分析5.1相同点RTCWEB和WEBRTC都是为了实现实时的多媒体通信，所以说它们的相同点有目共睹：1.RTCWEB与WEBRTC都对数据传输，数据成帧，图像处理和显示等方面进行了定义和规范；2.两种规范都对实时通信过程中的协议进行了规范；最主要看看它们之间的差异。5.2不同点1.APIRTCWEB列举了许多中应用情形和每种应用所需的浏览器支持和API支持，包括：Browser-to-browseruse-cases:SimpleVideoCommunicationServiceSimpleVideoCommunicationService,NAT/FWthatblocksUDPSimpleVideoCommunicationService,globalserviceprovider:SimpleVideoCommunicationService,enterpriseaspectsSimpleVideoCommunicationService,accesschangeSimpleVideoCommunicationService,QoSSimpleVideoCommunicationServicewithsharingSimplevideocommunicationservicewithinter-operatorcallingHockeyGameViewerMultipartyvideocommunicationMultipartyon-linegamewithvoicecommunicationDistributedMusicBandBrowser-GW/Serverusecases:TelephonyterminalFedexCallVideoconferencingsystemwithcentralserverWEBRTC则较为笼统的定义了一些接口规范，如StreamAPI,p2pconnection,garbagecollection.2.侧重点：RTCWEB更注重为了实现实时多媒体通信所需的几个重要步骤的规范，而WEBRTC更注重的是这些规范所需要的细节技术。比如：编解码器，是需要可扩展的还是非可扩展的；视频音频传输是否要同一个RTP会议端口等这样的问题。第26页IETFRTCWeb草案研究报告6总结可以看到IETFRTCWEB工作组和W3CWEBRTC工作组合作给我们提供了一系列的基于浏览器的网页实时通信的相关规范。两个规范的主要目的是提出一种精简的有效的方案，用来实现浏览器的实时通信，实现无插件、无网页应用程序的，基于浏览器的实时多媒体数据和非多媒体数据的传输，如视频会议等。其中RTCWEB提出了RTCWEB的梯形模型，指出要在浏览器与浏览器之间建立多媒体通路，在服务器之间建立信令通路。规范了RTCWeb中的各个功能结构，已经各个功能所需的关键技术。综合应用WebSocket、SIP、SDP、RTP等协议和方法将传统的通信协议应用到Web中，建立适当的网关，同时规范了API接口，提出API需求，编译码器codec需求，使得浏览器的实时通信得以实现。而WEBRTC规范了实现实时多媒体通信的APIs定义和规范。包括音视频的采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。通过对RTCWEB及WEBRTC的研究分析，我们可以看到：两个规范的优势就是不仅针对实现实时多媒体通信过程的技术实现进行了周密的规范，对于各大浏览器厂家支持不同导致没有统一的规范也是一个带头作用。这样只要提供适当的接口和协议支持，浏览器本身就可以完成几乎任何一种功能的。浏览器的发展也将日趋向实时的、交互的和更加开放的平台发展。第27页IETFRTCWeb草案研究报告主要参考文献http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-overview-02.draft-ibc-rtcweb-sip-websocket-00draft-cbran-rtcweb-negotiation-00draft-ietf-rtcweb-use-cases-and-requirements-06draft-ietf-rtcweb-rtp-usage-01draft-kaplan-rtcweb-api-reqs-01draft-cbran-rtcweb-data-00draft-cbran-rtcweb-media-00draft-cbran-rtcweb-codec-01draft-jennings-rtcweb-signaling-01draft-jennings-rtcweb-signaling-gateway-00draft-jesup-rtcweb-data-01draft-johnston-rtcweb-media-privacy-00draft-kaplan-rtcweb-sip-interworking-requirements-01draft-kaufman-rtcweb-security-ui-00draft-kaufman-rtcweb-traversal-00draft-lennox-rtcweb-rtp-media-type-mux-00draft-nandakumar-rtcweb-stun-uri-00draft-nandakumar-rtcweb-turn-uri-00draft-partha-rtcweb-signaling-00draft-rosenberg-rtcweb-rtpmux-00draft-sipdoc-rtcweb-open-wire-protocol-00draft-wenger-rtcweb-layered-codec-00博客：http://blog.csdn.net/cymlife/article/details/6579861WebRTC主页：http://www.webrtc.org/referenceGIPS详细介绍：http://www.cnblogs.com/huaping-audio/archive第28页',)