完整SIPSDP媒体协商概论绝缘接头

完整SIP/SDP媒体协商概论

根据RFC3264的规范，agent的任何一方都可以生成后续offer。在笔者前面的文章中，笔者讨论了关于ICE结束处理的流程的规则，这个结束ICE流程的规则会导致被控方agent发送一个更新offer。具体来说，当ICE从默认配对中已选择了不同的配对时，在ICE结束流程中，被控方agent会发送一个更新offer消息。但是，前面的文章中没有详细介绍agent如何实现更新offer，接收offer，以及最后更新检查连接和有效列表的步骤。如果agent要实现更新offer的处理流程，双方agent需要经过三个主要的流程。Agent需要首先要经过offer消息构建，然后对端peer接收更新的offer，生成更新的answer消息，最后更新连接检查和有效列表。

因为更新offer的内容比较庞杂，为了让读者有一个比较好的阅读体验，笔者计划将上述内容分为三个部分来介绍。本文章介绍第一个部分的内容（生成后续offer），在以后的文章中分别介绍第二部分和第三部分的内容。

本文章主要涵盖关于生成后续offer的内容：

整体部署场景讨论（ICE 重新启动，移除媒体流，增加媒体流）

全场景部署讨论：ICE运行时现存媒体流处理和ICE完成后现存媒体流处理。

轻量级场景部署讨论：ICE运行时现存媒体流处理和ICE完成后现存媒体流处理。

在讨论后续offer/an应停机检查;操作中如产生故障不能运转需检验时时swer交互模式时，首先需要关注的是关于如何生成更新的offer消息。在生成更新offer消息中，RFC5245分别规定了两种常见的处理流程（全场景部署场景和轻量级部署场景）。接下来，笔者会首先对整体部署场景进行讨论，然后分别对两种部署场景中关于不同ICE运行状态环境中现存媒体流的处理进行讨论。

注意：关于ICE重新启动的细节，RFC5245和RFC8445规范有非常某些区别，笔者这里以RFC5245的规范作为讨论基础。如果对最新的规范有兴趣的话，可以查阅RFC8445的细节。

1整体部署场景讨论

在讨论后续offer/answer交互模式时，首先需要关注的是关于如何生成更新的offer消息。在生成更新offer消息中，针对agent，RFC5245分别规定了两种常见的处理流程（全场景部署场景和轻量级部署场景）。在介绍这两种部署场景的处理流程之前，我们首先介绍三个和整体部署场景相关的内容。第一个是关于重新启动ICE流程的讨论。

Agent可以对现存的媒体流重新启动ICE处理流程。重新启动ICE处理流程会导致前面的ICE处理流程被刷新，并且还要重新启动检查流程。注意，重新启动ICE处理流程和重新创建一个新会话之间有不同之处，在重新启动ICE处理流程的过程中，媒体流仍然会被发送到以前的有效配对目的地。对于一个媒体流来说，如果有以下两种情况可能发生的话，agent必须重新启动ICE流程：

已经生成了offer，此offer的目的是为了修改媒体流目的地。简单来说，就是agent想生成一个更新的offer消息（ICE没有使用这个offer），这样的结果是为媒体构件目的地生成一个新的值。

Agent正在修改其部署级别。正在情况一般发生在第三方呼叫控制的环境中。对象实体正在使用的信令不是实体接收媒体的信令，并且这个实体已经从媒体 mid-session的目的地修改为另外一个实体，这个实体具有不同的ICE部署环境。

另外一些规则的修改也会引起ICE重新启动，SDP中的c行中IP地址修改为0.0.0.0会引起ICE重新启动。因此，如果需要支持呼叫等待业务功能的话，ICE部署中则不能使用以上机制，它必须使用a=inactive和a=sendonly设置。因为这里涉及了IPv6的络场景，旧规范RFC3264已经做了更新，关于此要求最新细节，建议读者可以参考RFC.1章节的介绍。如果agent要为媒体流重新启动ICE流程的话，agent必须在offer消息中修改认证用户需要的两个属性ice-pwd和ice- ufrag。注意，RFC5245规范也允许agent在offer中使用会话级的属性设置，仅为在后续的offer中作为一个媒体级属性提供同样的ice-pwd或ice- ufrag。这样的操作不会修改密码，不会修改其呈现方式，也不会引起ICE重新启动。Agent在SDP中设置了多个其他的属性，这些属性在包含在初始化的offer中。针对此媒体流，在接下来的更新offer的处理流程中，候选地址组会根据实际情况，可能会包括其中一些参数或者没有包含任何参数，或者前面的候选地址，并且可能包括全新采集的候选地址组。候选地址采集的采集通过采集候选地址来执行（关于候选地址场景请参考历史文章）。

根据RFC3264的规范规定，如果agent需要移除媒体的话，它可以设置其端口为0。这个规则在这里也适用。除了agent设置端口为0以外，针对要移除的媒体流，它一定不能包含任何候选地址属性，并且不应该包括任何ICE相关的属性设置。具体的ICE相关属性，参考如下示例：

如果agent想增加一个新的媒体流的话，它需要在SDP中为此媒体流设置相关的域值。这些SDP中的相关域值设置需要参考初始化offer中关于SDP解码中的设置。Agent修改了这些媒体流的设置后，ICE处理流程就会开始发送媒体流。

以上内容介绍了整体部署环境中关于ICE重新启动，移除媒体流和删除媒体流的处理流程。接下来，我们将首先针对全场景部署环境中处理流程进行说明。

2全场景部署环境处理流程

这个章节将对在全场景部署环境中，在不同ICE运行状态下对现存媒体流进行的处理做详细说明。这里要注意这三个参数环境，用户名称（ice- ufrag），密码（ ice-pwd）和部署级别，前面使用的这三个条件没有发生改变。如果agent需要修改其中一个参数条件，ICE就需要重新启动。

如果agent生成了一个更新的offer，在更新offer中包括了一个以前已创建的媒体流，并且ICE检查也在运行状态时，agent需要根据以下流程执行。针对此媒体流，此agent必须为所有本地候选地址包括候选属性。在S吸引了必可成、雷冠等1批聚乳酸制品生产企业落户DP标识的候选地址的属性，例如，priority，foundation，type和相关传输地址都应该保持不变。候选地址中马睿文也表示基础的确认信息，例如，IP 地址，port和传输协议一定不能发生变化（如果其中一个发生变化，则说明是一个新的候选地址）。component ID和以前的component ID保持一致。Agent可以包括以前offer中没有生成的其他候选地址，但是，自从上一次offer/answer交互以后，对agent已经采集的候选地址来说，需要包括一个peer reflexive candidates。针对媒体来说，就像在初始offer中的一样，肯定有一组候选属性可以匹配默认目的地地址，agent可以为此媒体修改默认目的地地址。

以上是ICE在运行状态时，agent更新offer需要执行的流程。除了ICE处于正在执行状态以外，ICE检查也可能是完成状态。如果agent生成了一个更新的offer，在更新offer中包括了一个以前已创建的媒体流，并且ICE检查在完成状态时，agent需要根据以下流程执行。针对媒体的默认目的地地址（例如，媒体流的m行和c行中的IP地址和端口值）必须是本地候选地址，这个本地候选地址来自于对每个媒体构件的有效列表最高优先级推荐配对。通过这样的处理方式可以 修复 目的地地址，让默认媒体的目的地地址等于ICE为此媒体的已选地址。Agent必须包含一些候选地址的候选属性，这些候选属性匹配了媒体流中每个构件的默认目的地地址，并且agent一定不能包含其他候选地址。另外，如果agent是一个被控方agent的话，它必须为每个媒体流（这些媒体流的检查列表是在ICE完成状态）包含a=remote-candidates属性。这个属性设置中包含远端候选地址，这些地址来自于此媒体流的每个构件所支持的有效列表中的最高优先级配对取值。这里可能存在一种极端情况，这种情况需要尽量避免。被控方agent选择了它的配对，但是更新offer对主控方agent执行了一个序乱的连接检查。这种情必要的情况下还会采取热水或加洗涤剂等方法进行清洗况下，对端agent可能不知道哪个配对是有效配对。因此，在更新offer使用a=remote-candidates属性避免更新offer和STUN检查协议之间因为请求/响应消息丢失出现的这种极端情况。注意，这种极端情况的处理机制讨论仅在RFC5245的规范中有规定，但是在RFC8445中取消了这种处理来自。相对于RFC5245，RFC8445针对ICE重新启动做了大幅简化处理。

a=remote-candidates 避免配对序乱处理（RFC5245）

3轻量级部署环境处理流程

这个部分的讨论和前面的讨论应用，笔者也会分别针对两种ICE运行状态下的轻量级部署环境的处理流程进行介绍。

首先说明一下轻量级部署中针对现存媒体流，ICE流程处于运行状态时的处理流程。轻量级部署必须在任何后续的offer中的a=candidate为每个媒体流的每个构件的包含所有的候选地址。候选地址的构建和初始化offer中关于候选地址的构建的流程完全相同。具体的构建流程在前面的历史文章中有专门介绍，读者可以查阅历史文档。轻量级部署中一定不能在后续offer中再增加其他的主机候选地址。如果agent想增加一个新的主机候选地址的话，agent必须重新启动ICE处理流程。在后续offer中的用户名称（ice- ufrag），密码（ ice-pwd）和部署级别应该和前面offer中的属性保持一致，如果以上三种参数后续offer中发生修改，agent则必须为此媒体流重新启动ICE处理流程。

针对媒体流来说，如果ICE处理状态处于完成状态，此媒体流的默认目的地地址必须设置为此媒体流构件的候选配对（在有效列表中）的远端候选地址。对轻量级部署来说，总是支持一个在有效列表中的单候选配对。另外，agent必须为每个默认目的地包含一个候选地址属性。

如果agent是一个被控方agent的话（仅发生在双方都是轻量级部署的agent），此agent必须为每个媒体流包含一个a=remote-candidates。a=remote-candidates中包含远端候选地址，这个远端候选地址来自于有效列表中的候选配对（每个媒体流的每个构件有一对候选配对）。

在接下来的章节中，笔者将继续介绍针对更新offer中对端agent接收offer和生成answer的处理流程。

参考资料：

关注公众号：asterisk-cn，获得有价值的Asterisk行业分享

最新Asterisk完整中文用户手册详解及免费slack支持：

Freepbx/FreeSBC技术文档：

融合通信/IPPBX商业解决方案：

如何使用FreeSBC，技术分享群：

Flutter培训课程
React + React Hook + TS实战
全栈开发商城系统