WebRTC offer - answer交换sdp流程分析

转载学习:
两端开启音视频通讯时,一方做为offer主动发出邀请,另一方做为answer被动等待offer的邀请做出反应。
代码中的流程:

Offer:

  1. offerForConstraints,得到sdp后回调 <第1.1步>。
  • 1.1. didCreateSessionDescription
  • 1.1.1.,如果有错直接返回错误给上层,没错继续 <第1.1.2步>。
  • 1.1.2. setLocalDescription设置sdp,回调 <第1.1.2.1步>。
  • 1.1.2.1. didSetSessionDescriptionWithError 如果有错直接返回错误给上层。

1.2. 根据sdp的RTCSdpType生产msg,调用sendSignalingMessage通过信令服务器发送给远程answer。
1.3. setMaxBitrateForPeerConnectionVideoSender设置视频发送最大码率。
Answer:

  1. 收到Offer的sdp后调用setRemoteDescription,然后回调 <第1.1步>。
  • 1.1. didSetSessionDescriptionWithError

  • 1.1.1. 如果有错直接返回错误给上层,没错继续 <第1.1.2步>。

  • 1.1.2. answerForConstraints回调 <第1.1.2.1步>,传入answerForConstraints得到的sdp。

  • 1.1.2.1 didCreateSessionDescription

  • 1.1.2.1.1 如果有错直接返回错误给上层,没错继续<第1.1.2.1.2步>。

  • 1.1.2.1.2. setLocalDescription设置从answerForConstraints得到的sdp,回调 <第1.1.2.1.2.1步>。

  • 1.1.2.1.2.1 didSetSessionDescriptionWithError 如果有错直接返回错误给上层。没错因为已经设置了localDescription所以不做其他处理。

 **1.1.2.2** 根据sdp的RTCSdpType生产msg,调用sendSignalingMessage通过信令服务器发送给远程offer。
 - **1.1.2.3** setMaxBitrateForPeerConnectionVideoSender设置视频发送最大码率。

1
2
Offer:

  1. 收到Offer的sdp后调用setRemoteDescription,然后回调 <第1.1步>。
  • 1.1. didSetSessionDescriptionWithError 如果有错直接返回错误给上层。

总结
从以上可以看出代码有多晕,主要层层回调还把didSetSessionDescriptionWithError重用在多处的原因,然后恶心的oc代码又臭又长,每个方法名都长到吓死人,看的人眼花缭乱。
写着上面的1.1,1.2之类的我自己都恶心了。

总结一下流程:
offer先调用offerForConstraints得到自己的offerSdp,setLocalDescription(offerSdp),把offerSdp发给远程answer,同时设置自己发送视频的最大码率。

answer收到offerSdp后,setRemoteDescription(offerSdp)。answerForConstraints得到自己的answerSdp,setLocalDescription(answerSdp),把answerSdp发送给offer,同时设置自己发送视频的最大码率。

offer收到answerSdp后,setRemoteDescription(answerSdp)。

以上很多调用的WebRTC API都产生回调,回调可能返回错误,此时都要处理错误,一般就是把错误传递给上层,然后关闭整个会话。

猜你喜欢

转载自blog.csdn.net/hmwz0001/article/details/130657387