您当前的位置是:  首页 > 资讯 > 国内 >
 首页 > 资讯 > 国内 >

完整SIP/SDP媒体协商概论-后续offer处理-answer生成

2020-05-25 14:26:41   作者:james.zhu   来源:Asterisk开源派   评论:0  点击:


  在上一篇文章中,笔者介绍了后续offer中关于offer生成的讨论。今天,笔者将继续介绍peer接收offer和生成answer响应的细节,主要涵盖细节包括:
  整体部署场景讨论(检测ICE重新启动,移除媒体流,增加媒体流)
  全场景部署讨论:无remote-candidates属性状态下,ICE运行时现存媒体流处理和ICE完成后现存媒体流处理,带remote-candidates现存媒体流处理。
  轻量级场景部署讨论:ICE运行时现存媒体流处理和ICE完成后现存媒体流处理。
  读者注意,在这里讨论的offer/answer已经涉及到了后续offer的内容,也就是更新的offer,所以有时会和初始offer时的一些属性进行对比处理,读者一定不要迷惑。
  1整体部署场景讨论
  当agent在现存会话中收到后续offer时,无论前面的offer/answer交互验证是否成功,agent必须重新检查一次验证ICE支持能力(前面的文章中介绍过接收初始offer关于ICE能力支持验证流程)。虽然,前面offer/answer交互可能导致ICE不能使用,不过,这种处理结果可以作为后续offer/answer交互的结果使用。和上一篇文章中所讨论的应用,agent接收offer时,对于整体部署场景来说,仍然需要执行常规的三个步骤的处理:检测ICE重新启动,添加媒体流处理,移除媒体流处理。现在,我们分别加以介绍。
  用户属性发生了修改,agent需要重新检测并且重新启动ICE。具体来说,agent和前面收到的SDP中属性对比,如果agent在收到的更新offer消息中包含了一个已修改的属性(可能是a=ice-ufrag 或者a=ice-pwd),针对此媒体流,agent需要重新启动ICE。如果所有的媒体流需要重新启动的话,所有ICE也需要重新启动。如果一个媒体流的ICE重新启动的话,agent会在answer中执行两种修改处理:
  Agent必须修改answer中的a=ice-ufrag和a=ice-pwd。
  Agent可能在answer消息中修改其部署层级。
  针对媒体流,agent会修改SDP中其他属性设置,属性设置和和初始answer中的处理流程相同。针对此媒体流,在接下来的处理流程中,候选地址组会根据实际情况,可能会包括部分参数,无参数,或者包括前面的候选地址参数,并且可能包括全新采集的候选地址组。
  如果agent收到一个offer,offer中包含了一个新的媒体流,针对此媒体流,就像agent在初始offer包含的媒体流一样,agent必须在answer中设置相关的域值。在answer设置以后就会导致ICE重新启动。
  如果agent收到一个offer,offer中包含了一个媒体流,其端口设置为0的话,agent一定不能为此媒体流在answer中包含任何候选地址属性,并且不应该包含任何和ICE定义的相关属性,例如foundation和component-id等。
  2全场景部署环境处理流程
  这个章节将对在全场景部署环境中,在不同ICE运行状态下对现存媒体流进行的处理做详细说明。这里要注意这三个参数环境,用户名称(ice- ufrag),密码( ice-pwd)和部署级别。除了agent已经从offer消息中检测到ICE重新启动之外,用户名称(ice- ufrag),密码( ice-pwd)和部署级别必须维持不变。如果agent想修改其中一个属性值的话,agent通过生成一个新的offer来重新启动ICE。agent不能在answer消息重新启动ICE处理流程。其他的流程取决于此媒体流的ICE运行状态。笔者将结合不同remote-candidates属性出现的以下三种状态进行讨论。
  如果针对一个媒体流的ICE的状态处于运行状态,并且此媒体流的offer已锁定了remote-candidates属性,构建answer消息的规则和笔者上一篇关于offer生成的流程相同。
  如果针对一个媒体流的ICE状态处于完成状态,并且此媒体流的offer已锁定了remote-candidates属性,构建answer消息的规则和笔者上一篇关于offer生成的流程相同,另外,应答方answerer一定不能在answer消息中包括a=remote-candidates属性。
  以上两种状态都是锁定了remote-candidates属性的。如果remote-candidates是一种可变状态,出现了竞争条件的话,现存媒体流的处理就需要做另外处理。当agent对端peer对一个媒体流已包含了ICE处理流程的话,主控方agent将会收到一个带a=remote-candidates属性的offer消息。出现在offer中的这个属性用来处理介于offer接收和响应接收之间的竞争条件,通知answerer接收方ICE将会选择一个候选地址。关于竞争状态的流程,读者可以查阅RFC5246-appendix-B.6。接下来关于针对offer携带a=remote-candidates的处理流程完全取决于竞争条件中协商胜方的处理流程。
  Agent为媒体流的每个构件生成一个候选配对,它需要远端候选地址和本地候选地址,具体处理流程为:
  设置远端候选地址等于offerer提供方中的默认目的地地址。例如,针对RTP的m行和c行内容,和RTCP的a=rtcp。
  设置本地候选地址等于传输地址,此传输地址是支持在offer中a=remote-candidates同一构件。
  生成候选配对完成以后,agent看到候选配对会出现在有效列表中。如果有一个配对没有出现在有效列表中的话,说明检查流程失去了竞争条件。这样的配对称之为 "losing pair"(丢失的配对)。接下来,agent会在检查列表中通过远端候选地址查找,查找所有远端候选地址等于丢失配对中的远端候选地址的配对,执行以下流程:
  如果这些配对中无配对在In-Progress处理状态,并且至少一个配对是失败状态,这可能是因为网络问题导致,例如可能发生了网络隔离问题,严重的网络丢包。这样可能就没有出现remote-candidates,agent应该为此媒体流生成一个answer,然后为此媒体流重新启动ICE流程。
  如果这些配对中至少有一对配对在In-Progress处理状态,agent应该等待它们的检查流程完成,并且当每个检查完成后,重新执行这部分流程,直到再没有丢失配对需要处理。
  一旦完成了没有再需要处理的丢失的配对以后,agent就可以生成一个answer消息。它必须为此媒体设置默认目的地地址,默认目的地地址为remote-candidates(来自于offer)中的候选地址。它必须为此每个候选地址在answer中包括一个候选地址属性,这里的每个候选地址是在offer中remote-candidates属性中。
  3轻量级部署环境处理流程
  如果在收到的offer中包含remote-candidates属性,agent为媒体流的每个构件生成一个候选配对,它需要远端候选地址和本地候选地址,具体处理流程为:
  设置远端候选地址等于offerer提供方中的默认目的地地址。例如,针对RTP的m行和c行内容,和RTCP的a=rtcp。
  设置本地候选地址等于传输地址,此传输地址是支持在offer中a=remote-candidates同一构件。
  针对此媒体流,agent然后把这些候选地址迁移到有效列表中。ICE处理流程状态设置为完成状态。
  除了以上设置以外,agent控制角色也是一个问题需要讨论。如果agent认为它自己是主控方agent,而且在offer消息中包含了remote-candidates属性,双方agent都认为自己是主控方agent。这种情况下,双方agent将可能都已经同时对对方发送了更新offer消息。这种极端情况需要负责传输offer/answer交互的信令协议来解决。最后,其中一方agent总是以竞争环境中的胜方出现。在信令协议传输offer/answer交互的流程中,对端peer发送offer之前,胜方agent会首先收到一个offer消息。胜方agent会充当主控方agent的角色,因此,这里所讨论的应答方answerer必须修改其角色为主控方角色。接下来,如果agent基于一个流程(根据RFC5245-8.2.2)发送更新offer的话,这个agent就是一个主控方agent。
  除了以上控制角色修改以外,构建answer的执行流程中关于有效列表中的修改和ICE状态修改和构建offer流程的相同。读者可以查阅上一篇文章做进一步了解。
  本章节介绍了在更新的offer中关于接收offer消息和生成answer消息的处理过程。接下来的章节笔者将介绍在后续offer/answer交互中check更新和有效列表更新的细节。
【免责声明】本文仅代表作者本人观点,与CTI论坛无关。CTI论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

相关阅读:

专题

CTI论坛会员企业