被WebRTC自带oc版本的例子恶心到了，不做笔记还真不行。
两端开启音视频通讯时，一方做为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设置视频发送最大码率。
-
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都产生回调，回调可能返回错误，此时都要处理错误，一般就是把错误传递给上层，然后关闭整个会话。
