sdp recv/send/sendrecv

https://www.cnblogs.com/idignew/p/7249056.html

 

3 实体行为、操作过程
3.1 初始协商的Offer请求

实体A <-> 实体B，实体首先发起Offer请求，内容如2节所示，对于作何一个媒体流/媒体通道，这时实体A必须：

a.       如果媒体流方向标为recvonly/sendrecv，即a=recvonly或a=sendrecv，则A必须（MUST）准备好在这个IP和端口上接收实体B发来的媒体流；

b.       如果媒体流方向标为sendonly/inactive，即a=sendonly或a=inactive，则A不需要进行准备。

3.2 Answer响应

实体B收到A的请求offer后，根据自身支持的媒体类型和编码策略，回复响应。

a. 如果实体B回复的响应中的媒体流数量和顺序必须（MUST）和请求offer一致，以便实体A进行甄别和决策。即m行的数量和顺序必须一致，B不能（MUST NOT）擅自增加或删除媒体流。如果B不支持某个媒体流，可以在对应的端口置0，但不能不带这个m行描述。

b. 对于某种媒体，实体B必须（MUST）从请求offer中选出A支持且自己也支持的该媒体的编码标识集，并且可以（MAY）附带自己支持的其它类型编码。

c. 对于响应消息中各个媒体的方向：

如果请求某媒体流的方向为sendonly，那么响应中对应媒体的方向必须为recvonly；

如果请求某媒体流的方向为recvonly，那么响应中对应媒体的方向必须为sendonly；

如果请求某媒体流的方向为sendrecv，那么响应中对应媒体的方向可以为sendrecv/sendonly/recvonly/inactive中的一种；

如果请求某媒体流的方向为inactive，那么响应中对应媒体的方向必须为inactive；

d.       响应answer里提供IP和端口，指示Offerer本端期望用于接收媒体流的IP和端口，一旦响应发出之后，Offerer必须（MUST）准备好在这个IP和端口上接收实体A发来的媒体流。

e.       如果请求offer中带了ptime（媒体流打包间隔）的a行或带宽的a行，则响应answer也应该（SHOULD）相应的携带。

f.        实体B Offerer应该（SHOULD）使用实体A比较期望的编码生成媒体流发送。一般来说对于m行，如m=video 0 RTP/AVP 31 34，排充越靠前的编码表示该实体越希望以这个编码作为载体，这里示例31(H261)，34（H263）中H261为A更期望使用的编码类型。同理，当实体A收到响应answer后也是这样理解的。