WebRTC源码分析-呼叫建立过程之一(综述)
前言基于WebRTC源码下example/peerconnect_client,example/peerconnect_server工程打算写一个典型的呼叫建立过程的源码分析系列文章,本文是一个序章。example/peerconnect_client与,example/peerconnect_server实现了一个Demo性质的P2P音视频会话程序,其中有3个主要的类:MainWnd类进行界面.
前言
基于WebRTC源码下example/peerconnect_client,example/peerconnect_server工程打算写一个典型的呼叫建立过程的源码分析系列文章,本文是一个序章。example/peerconnect_client与,example/peerconnect_server实现了一个Demo性质的P2P音视频会话程序,其中有3个主要的类:MainWnd类进行界面显示,视频渲染;PeerConnectionClient类负责与信令服务器peerconnect_server进行Http信令交互;Conductor类是核心业务类,持有MainWnd与PeerConnectionClient对象,整个WebRTC的使用都浓缩在这个类中。
对这两个工程的叙述就说到此,整体的架构实现不再多讲。刚入坑WebRTC的同学可以以此为学习的入口点,查看源码或者参考以下几篇博客来分析。
本文省略工程中信令交互部分(信令交互只在UML时序图中体现),直接从PeerConnectionFactory对象的创建开描述建立一个典型p2p WebRTC呼叫建立过程。
呼叫建立过程时序
如下所示为P2P建立过程详细的UML时序图,为了便于识别以不同的颜色来表示不同的对象,对象之间的消息传递也以不同颜色区分。
- 天蓝色背景表示两个需要建立P2P通信的两个端点,端上运行着peerconnect_client程序。其中呼叫端成为Caller,被呼叫端为Callee。在端上执行的步骤均以黑色字体展现。
- 粉色背景表示的是信令服务器,运行着peerconnect_server程序。端与服务器的信令交互过程也以粉色字体展示。
- 橘红背景表示的是STUN服务器,运行着STUN服务器程序。工程中以谷歌提供的STUN服务器作为STUN测试服务器,地址为"stun:stun.l.google.com:19302"。端与STUN服务器的交互也以橘红色的字体展示。
- 以绿色字体展示端与端之间的音视频传输。
在WebRTC的源码api/peer_connection_interface.h中,有很长一段注释,分别从呼叫方和被呼方的视角说明了整个流程。此处直接粘贴过来,不做翻译了,因为很容易理解。
- 以下是呼叫方的视角
// The following steps are needed to setup a typical call using WebRTC:
//
// 1. Create a PeerConnectionFactoryInterface. Check constructors for more
// information about input parameters.
//
// 2. Create a PeerConnection object. Provide a configuration struct which
// points to STUN and/or TURN servers used to generate ICE candidates, and
// provide an object that implements the PeerConnectionObserver interface,
// which is used to receive callbacks from the PeerConnection.
//
// 3. Create local MediaStreamTracks using the PeerConnectionFactory and add
// them to PeerConnection by calling AddTrack (or legacy method, AddStream).
//
// 4. Create an offer, call SetLocalDescription with it, serialize it, and send
// it to the remote peer
//
// 5. Once an ICE candidate has been gathered, the PeerConnection will call the
// observer function OnIceCandidate. The candidates must also be serialized and
// sent to the remote peer.
//
// 6. Once an answer is received from the remote peer, call
// SetRemoteDescription with the remote answer.
//
// 7. Once a remote candidate is received from the remote peer, provide it to
// the PeerConnection by calling AddIceCandidate.
- 以下是被呼方的视角
// The receiver of a call (assuming the application is "call"-based) can decide
// to accept or reject the call; this decision will be taken by the application,
// not the PeerConnection.
//
// If the application decides to accept the call, it should:
//
// 1. Create PeerConnectionFactoryInterface if it doesn't exist.
//
// 2. Create a new PeerConnection.
//
// 3. Provide the remote offer to the new PeerConnection object by calling
// SetRemoteDescription.
//
// 4. Generate an answer to the remote offer by calling CreateAnswer and send it
// back to the remote peer.
//
// 5. Provide the local answer to the new PeerConnection by calling
// SetLocalDescription with the answer.
//
// 6. Provide the remote ICE candidates by calling AddIceCandidate.
//
// 7. Once a candidate has been gathered, the PeerConnection will call the
// observer function OnIceCandidate. Send these candidates to the remote peer.
源码分析
后续将写打算写一系列的文章来将整个过程的每个步骤,每个细节捋清楚。先从第一篇文章开始吧~~
更多推荐
所有评论(0)