前面的章节笔者重点讨论了offer初始化流程的处理,包括基本的SDP协商模式的背景知识,针对发起方对offer消息中单播和多播环境处理。从本章节开始,我们继续介绍SDP协商中的接收方或者应答方的单播和多播媒体的应答处理(answer消息)。除了针对移动方生成answer的讨论以外,本章节还将继续介绍关于SDP的媒体管理,指示能力的讨论和一个交互模式的示例。
构建offer消息的answer消息
发起方提供了一个offer消息给应答方,同样,应答方answerer也会根据offer的消息回复一个answer信息。在answer的讨论中,笔者首先需要提醒读者需要注意几个媒体描述的设置("o=","m="行数和“t=”行),并且"m="中包含接受的媒体格式和不接受的媒体格式指示。通常来说,已提供的offer消息和它的answer是相互对应的,否则双方的交互没有办法完成。它们之间的绑定关系是通过"o="行来关联在一起。具体来讲,如果answer消息中的"o="行版本号和offer消息中的"o="行版本号不一致的话,那么,说明这answer消息是由不同的实体生成。另外,在offer中的每个"m="行必须对应相应的answer中的"m="行,answer中的"m="行必须包含和offer消息中完全一样的"m="行数。简单来说,offer中包含2行"m="行,answer必须也同样包含2行"m="行。当然,如果在offer消息中包含零行"m="行的话,answer中也是包含零行"m="行。一些情况下,这样规定的目的是为了保证媒体流格式按照一定的顺序来匹配。最后,会话时间是不能协商的,因此,在answer中的"t="行设置必须等于offer中的"t="设置。offer消息中提供的流可以因为各种原因被answer消息拒绝。进一步说明,如果offer的流媒体被拒绝的话,发起方和应答方双方一定不能生成针对此流媒体生成媒体流数据(或者RTCP报表数据)。对已拒绝的offer的媒体流,answer消息中相应的"m=0"行表示。任何的媒体格式列表要被忽略,至少保留一个媒体格式以支持指定的SDP。针对单播和多播流媒体来说,offer的流媒体的answer消息生成也有各自的流程。另外提醒读者,很多网关设备支持的默认媒体媒体格式的列表有自己的设置限制,有的网关可能至少支持一个媒体格式,最大支持4个媒体格式列表。有点的可能更多,如果列表支持的最大数百年满足协商的列表的话,可能出现编码匹配或者协商机制的不兼容性。下面,我们针对answer消息的单播媒体流和多播媒体流的构建进行讨论。
在生成应答的消息环境中,单播媒体流需要注意一些设置,特别是指向特征属性
注意,规范中的定义相对比较严格,为了保证能够完整准确的解释其官方的内容,笔者也只能遵从其用法。这里的流媒体是一个总称,媒体流是指具体的音视频,数据等具体媒体格式。现在,我们说明在answer消息中关于指向属性的设置。这里有很多“如果”,读者一定要注意。如果发送的或者提供的流媒体使用的是一个单播地址,此媒体其应答的地址或answered的地址必须包含一个单播地址。如果提供的流媒体标记为sendonly状态,在answer消息中其相应的流媒体必须标记为recvonly 或者 inactive状态。如果在offer消息中,媒体流列为recvonly状态,在answer消息中其媒体流必须标记为sendonly或者 inactive状态。如果提供的媒体流标记为sendrecv(或如果在媒体级或会话级没有指向属性,这种情况下,媒体流默认的标记为sendrecv状态),在answer消息中相应的媒体流可以标记为sendonly,recvonly,sendrecv,或inactive的状态。如果提供的媒体流标记为inactive状态,此媒体流在answer消息中必须标记为inactive状态。指向属性讨论完以后,笔者再结合指向属性介绍一些关于"m="行以及其他相关属性设置。对于在answer消息中标记为
在answer消息中的连接地址和端口表示一个应答方期望接收媒体的地址(RTP和RTCP的地址,RTCP端口是默认比RTP端口高一位数的端口,否则必须明确说明)。现在,笔者讨论一下关于RTP的媒体格式使用以及其他参数设置。如果在offer消息中,一个特定的编码格式支持了一种指定的payload类型码的话,此指定的payload类型码也应该使用在answer的payload类型中。虽然在answer中使用了同样类型的payload类型号,answer也必须包含rtpmap属性来定义payload类型的映射,使用此映射支持动态的payload类型,并且在answer消息中应该包含payload类型映射支持静态的payload类型。在answer消息中,"m="行中的媒体格式列表应该按照偏好顺序来排列,列表中的第一个媒体格式是实际推荐的媒体格式。在这种情况下,推荐的媒体格式表示对端offerer应该使用answer消息中推荐列表的最高排序的媒体格式。简单来说,answerer通知offerer使用answer中的最高优先级编码格式。虽然answerer应答方可以根据自己的推荐媒体格式在answer消息中列出一个媒体格式推荐顺序列表,但是,除非有特别的原因,一般的推荐方式是,应答方应根据出现在offer中的列表的格式顺序列出answer中的推荐列表。换句话说,如果出现在offer中的媒体流的语音编码格式顺序是8,22和48,answerer支持的语
商人拥有虚拟的象形图
音编码是8和48的话,根据一般的推荐方式,如果answerer没有任何理由修改这个顺序的话,在answer中的语音编码的顺序应该是8和48,而不是48和8的顺序。这样可以保持双向编码一致,降低了编码协商的多余处理步骤。answerer可以包括一个非零的ptime属性来支持任何媒体格式,这表示应答方期望使用此打包时长来接收媒体。对于一个媒体流来说,针对每个方向的媒体流打包时长可以不同,不一定是一样的。应答方也可以包括一个带宽属性支持任何媒体流,此带宽表示answerer应答方希望发起方发送媒体时使用的带宽。带宽属性可以为零,这表示无媒体发送,使用RTP的场景中,answerer同时也关闭了RTCP。针对一个某个由发起方的媒体流,如果answerer没有对此媒体流提供任何媒体格式的话,answerer必须设置端口为零来拒绝此媒体。但是,如果answerer对所有的媒体没有提供媒体格式的话,发起方提供的整个会话将会被answerer拒绝。
现在,我们继续讨论answerer发送answer后的处理流程。一旦answerer已经发送了answer消息,answerer必须准备好接收在answer消息中标识为
多播媒体流在answerer中关于answer和单播媒体流的处理有一定的差别,一些基础的设置是相同的。我们这里简要介绍多播媒体流在answerer方的构建处理规范。
https://tools.ietf.org/id/draft-ietf-mmusic-ice-sip-sdp-14.html