VoLTE端到端业务详解 | 编解码协商流程

Posted 2022-08-22 COCOgsta

书籍来源：艾怀丽《VoLTE端到端业务详解》

一边学习一边整理书中的笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：VoLTE端到端业务详解 | 汇总_COCOgsta的博客-CSDN博客

---

由于VoLTE网络中不同网元、不同网络类型对编解码的支持不完全相同，且编解码之间存在兼容性等问题，因此在呼叫建立以及呼叫稳态过程中，VoLTE各网元间需要进行编解码协商。编解码协商的目的是尽量让整个呼叫路径上使用相同的编解码，以节省TC资源，提高语音质量。

在现网VoLTE业务解决方案实施过程中，推荐由VoLTE侧的SBC、MGCF/IM-MGW提供编解码协商和转换功能，组网如图8-11所示。

总体部署策略包括如下内容。

① 在VoLTE用户基本呼叫互通场景、VoLTE用户与CS/VoBB/RCS-e/NGN用户的基本呼叫互通场景中，由VoLTE侧的SBC提供编解码协商和转换功能。

② MGCF/IM-MGW作为VoLTE组网中IMS Core和CS的互通网元，配合VoLTE侧的SBC提供VoLTE用户和CS用户公共编解码的协商和转换功能。

③ eSRVCC场景下，由MGCF/SRVCC IWF配合VoLTE侧的SBC（作为ATCF/ATGW）提供编解码协商和转换功能。

8.3.1 VoLTE用户之间的编解码协商

在VoLTE用户之间互通场景中，SBC完成编解码AMR-WB（Adaptive Multi-Rate-Wideband）、AMR（Adaptive Multi-Rate）的相互转换，实现VoLTE用户之间的互通。

VoLTE用户之间互通的编解码协商流程如图8-12所示，以UE_A呼叫UE_B，主被叫的编解码以UE_A只支持AMR且UE_B优选AMR-WB为例。

备注：以下消息流程仅提供编解码转换点的处理说明，其他信息同基本呼叫。

P1：SBC_A接收UE_A的请求消息，将消息中的编解码格式（AMR）与SBC_A上该会话所在接入网配置支持的编解码格式（AMR-WB/AMR）进行比较。

① 如果完全一致或不存在交集，则直接将UE_A请求消息转发给被叫侧。

② 如果不完全一致，则将并集中UE_A没有携带的编解码格式（AMR-WB）顺序添加到请求消息的SDP中。SBC_A将修改后UE_A请求消息（AMR/AMR-WB）发送给被叫侧。

P2：SBC_B的处理同SBC_A（P1）。SBC_B将入局消息中的编解码格式（AMR/AMR-WB）与SBC_B上配置支持的编解码格式（AMR/AMR-WB）进行比较。

① 如果完全一致或不存在交集，则直接将主叫侧请求消息（AMR/AMR-WB）转发给UE_B。

② 如果不完全一致，则将并集中没有携带的编解码格式顺序添加到请求消息的SDP中。SBC_B将修改后主叫侧请求消息发送给UE_B。

P3：SBC_B接收UE_B应答消息，将消息中携带的编解码格式（AMR-WB）与入局消息中的编解码格式（AMR/AMR-WB）进行比较。

① 如果完全一致或存在交集，则将UE_B应答消息的编解码格式（AMR-WB）直接透传给主叫侧。

② 如果不存在交集，则SBC_B申请媒体格式转换资源实现主叫侧编解码格式与UE_B侧编解码格式之间的转换；SBC_B将UE_B应答消息中的编解码格式修改为UE_A支持的编解码格式并将该消息发送给UE_A。

P4：SBC_A处理同SBC_B（P3）。SBC_A接收UE_B应答消息，将消息中携带的编解码格式（AMR-WB）与UE_A消息中的编解码格式（AMR）进行比较。

① 如果完全一致或存在交集，则将UE_B应答消息的编解码格式直接透传给UE_A。

② 如果不存在交集，则SBC_A申请媒体格式转换资源实现UE_A侧编解码格式（AMR）与UE_B侧编解码格式（AMR-WB）之间的转换；SBC_A将UE_B应答消息中的编解码格式修改为UE_A支持的编解码格式（AMR）并将该消息发送给UE_A。

P5：SBC_A接收UE_A侧的编解码格式（AMR）的RTP（Real-time Transport Protocol）媒体码流并进行格式转换。

① SBC_A对接收的UE_A侧（AMR）媒体码流进行解码得到UE_A侧音频信号，并将该音频信号重新编码为UE_B侧编解码格式（AMR-WB）的RTP媒体码流。

② SBC_A将转换后得到的UE_B侧编解码格式（AMR-WB）的RTP媒体码流发送给UE_B。

P6：SBC_A接收UE_B侧的编解码格式（AMR-WB）的RTP媒体码流并进行格式转换。

① SBC_A对接收的UE_B侧（AMR-WB）媒体码流进行解码得到UE_B侧音频信号，并将该音频信号重新编码为UE_A侧编解码格式（AMR）的RTP媒体码流。

② SBC_A将转换后得到的UE_A侧编解码格式（AMR）的RTP媒体码流发送给UE_A。

8.3.2 VoLTE用户与CS域用户之间的编解码协商

在VoLTE用户和CS用户互通场景中，编解码转换资源部署在VoLTE侧的SBC上，由该SBC完成VoLTE侧编解码AMR-WB、AMR与CS侧窄带AMR编解码（FR AMR、HR AMR、UMTS AMR和UMTS AMR2）、宽带AMR编解码（UMTS AMR-WB、FR AMR-WB）的相互转换，实现VoLTE用户和CS用户的互通。

1.VoLTE用户呼叫CS用户

VoLTE用户呼叫CS用户的编解码协商流程如图8-13所示，以VoLTE用户UE_A呼叫CS 3G用户UE_B，主被叫的编解码以UE_A选择AMR-WB modeset=1,3,4,8和UE_B选择AMR-NB modeset=7为例。

备注：以下消息流程仅提供编解码转换点的处理说明，其他信息同基本呼叫。

P1：SBC_A接收UE_A的请求消息，将消息中的编解码格式（AMR-WB modeset=1,3,4,8）与SBC_A上该会话所在接入网配置支持的编解码格式（AMR-WB modeset=1,3,4,8/AMR-WB modeset=0,1,2/AMR-NB modeset=7）进行比较。

① 如果完全一致或不存在交集，则直接将UE_A请求消息转发给被叫侧。

② 如果不完全一致，则将并集中UE_A没有携带的编解码格式（AMR-WB modeset=0, 1,2/AMR-NB modeset=7）顺序添加到请求消息的SDP中。SBC_A将修改后UE_A请求消息（AMR-WB modeset=1,3,4,8/AMR-WB modeset=0,1,2/AMR-NB modeset=7）发送给被叫侧。

P2：MGCF/IM-MGW接收主叫侧请求消息，做如下处理。

（1）MGCF/IM-MGW对主叫侧请求消息携带的AMR、AMR-WB编解码做如下处理。

① 如果不携带modeset，则MGCF/IM-MGW认为IMS侧支持全速率的AMR/AMR-WB。MGCF/IM-MGW进行编解码协商后取本端配置的AMR/AMR-WB Configuration。

② 如果携带modeset，则MGCF/IM-MGW按照RFC 4867定义的协商方式。如果主叫侧请求消息携带的AMR/AMR-WB modeset不能匹配本端配置的AMR/AMR-WB Configuration，则丢弃该modeset；如果可以匹配，则继续使用该AMR/AMR-WB modeset。

③ 如果主叫侧请求消息携带的AMR/AMR-WB modeset与本端配置的AMR/AMR-WB Configuration无交集，则MGCF/IM-MGW向CS侧发送MGCF/IM-MGW支持的AMR/AMR-WB Configuration。

④ 如果MGCF与VMSC之间通过BICC协议互通，由于BICC有UP（User Plane）头，SIP无UP头，MGCF要在SIP（IMS侧）和BICC（CS侧）之间插入一个FPTC。

⑤ 如果MGCF与VMSC之间通过SIP互通，MGCF无须插入一个FPTC。

（2）MGCF/IM-MGW将协商后的编解码集（AMR-WB modeset=0,1,2/AMR-NB modeset=7）发送给CS侧的网元。

P3：VMSC/MGW接收主叫侧请求消息，将入局消息中的编解码格式（AMR-WB modeset= 0,1,2/AMR-NB modeset=7）与VMSC/MGW上配置支持的编解码格式进行比较。

① 如果完全一致或不存在交集，则直接将主叫侧请求消息（AMR-WB modeset=0,1,2/AMR-NB modeset=7）转发给UE_B。

② 如果不完全一致，则将并集中没有携带的编解码格式顺序添加到请求消息的SDP中。VMSC/MGW将修改后主叫侧请求消息发送给UE_B。

P4：VMSC/MGW接收UE_B应答消息，将消息中携带的编解码格式（AMR-NB modeset=7）与入局消息中的编解码格式（AMR-WB modeset=0,1,2/AMR-NB modeset=7）进行比较。

① 如果完全一致或存在交集，则将UE_B应答消息的编解码格式（AMR-NB modeset=7）直接透传给主叫侧。

② 如果不存在交集，则VMSC/MGW申请媒体格式转换资源实现主叫侧编解码格式与UE_B侧编解码格式之间的转换；VMSC/MGW将UE_B应答消息中的编解码格式修改为UE_A支持的编解码格式并将该消息发送给UE_A。

P5：MGCF/IM-MGW的处理同P4。

P6：SBC_A接收UE_B应答消息，将消息中携带的编解码格式（AMR-NB modeset=7）与UE_A消息中的编解码格式（AMR-WB modeset=1,3,4,8）进行比较。

① 如果完全一致或存在交集，则将UE_B应答消息的编解码格式直接透传给UE_A。

② 如果不存在交集，则SBC_A申请媒体格式转换资源实现UE_A侧编解码格式（AMR-WB modeset=1,3,4,8）与UE_B侧编解码格式（AMR-NB modeset=7）之间的转换；SBC_A将UE_B应答消息中的编解码格式修改为UE_A支持的编解码格式（AMR-WB modeset=1,3,4,8）并将该消息发送给UE_A。

P7：SBC_A接收UE_A侧的编解码格式（AMR-WB modeset=1,3,4,8）的RTP（Real-time Transport Protocol）媒体码流并进行格式转换。

① SBC_A对接收的UE_A侧（AMR-WB modeset=1,3,4,8）媒体码流进行解码得到UE_A侧音频信号，并将该音频信号重新编码为UE_B侧编解码格式（AMR-NB modeset=7）的RTP媒体码流。

② SBC_A将转换后得到的UE_B侧编解码格式（AMR-NB modeset=7）的RTP媒体码流发送给UE_B。

P8：MGCF/IM-MGW接收到UE_A侧的RTP媒体码流后，对RTP媒体码流做UP头转换后发送给UE_B。

P9：MGCF/IM-MGW接收到UE_B侧的RTP媒体码流后，对RTP媒体码流做UP头转换后发送给UE_A。

P10：SBC_A接收UE_B侧的编解码格式（AMR-NB modeset=7）的RTP媒体码流并进行格式转换。

① SBC_A对接收的UE_B侧（AMR-NB modeset=7）媒体码流进行解码得到UE_B侧的音频信号，并将该音频信号重新编码为UE_A侧编解码格式（AMR-WB modeset=1,3,4,8）的RTP媒体码流。

② SBC_A将转换后得到的UE_A侧编解码格式（AMR-WB modeset=1,3,4,8）的RTP媒体码流发送给UE_A。

2.CS用户呼叫VoLTE用户

CS用户呼叫VoLTE用户的编解码协商流程如图8-14所示，以CS 2G用户UE_B呼叫VoLTE用户UE_A，主被叫的编解码以UE_A选择GSM EFR，UE_B选择AMR-NB modeset=7为例。

备注：以下消息流程仅提供编解码转换点的处理说明，其他信息同基本呼叫。

P1：VMSC/MGW接收UE_B的请求消息，将消息中的编解码格式（GSM EFR）与VMSC/MGW上配置支持的编解码格式（GSM EFR/AMR-NB modeset=7）进行比较。

① 如果完全一致或不存在交集，则直接将UE_A请求消息转发给被叫侧。

② 如果不完全一致，则将并集中UE_A没有携带的编解码格式（AMR-NB modeset=7）顺序添加到请求消息的SDP中。VMSC/MGW将修改后的UE_B请求消息（GSM EFR/AMR-NB modeset=7）发送给被叫侧。

P2：MGCF/IM-MGW接收主叫侧请求消息，将入局消息中的编解码格式（GSM EFR/AMR-NB modeset=7）与MGCF/IM-MGW上配置支持的编解码格式进行比较。

① 如果完全一致或不存在交集，则直接将主叫侧请求消息（GSM EFR/AMR-NB modeset=7）转发给UE_B。

② 如果不完全一致，则将并集中没有携带的编解码格式顺序添加到请求消息的SDP中。VMSC/MGW将修改后的主叫侧请求消息发送给UE_B。

备注：如果MGCF与VMSC之间通过BICC协议互通，由于BICC有UP头，SIP无UP头，MGCF需在SIP（IMS侧）和BICC协议（CS侧）之间插入一个FPTC。

如果MGCF与VMSC之间通过SIP互通，MGCF无须插入一个FPTC。

P3：SBC_A接收主叫侧请求消息，将消息中的编解码格式（GSM EFR/AMR-NB modeset=7）与SBC_A上该会话所在接入网支持的编解码格式（AMR-NB modeset=7）进行比较。

① 如果完全一致或不存在交集，则直接将UE_A请求消息转发给被叫侧。

② 如果不完全一致，则将并集中主叫侧没有携带的编解码格式顺序添加到请求消息的SDP中。SBC_A将修改后的UE_A请求消息发送给UE_A。

P4：SBC_A接收UE_A应答消息，将消息中携带的编解码格式（AMR-NB modeset=7）与入局消息中的编解码格式（GSM EFR/AMR-NB modeset=7）进行比较。

① 如果完全一致或存在交集，则将UE_B应答消息的编解码格式（AMR-NB modeset=7）直接透传给主叫侧。

② 如果不存在交集，则SBC_A申请媒体格式转换资源实现主叫侧编解码格式与UE_A侧编解码格式之间的转换；SBC_A将UE_A应答消息中的编解码格式修改为主叫侧支持的编解码格式并将该消息发送给主叫侧。

P5：MGCF/IM-MGW的处理同VoLTE用户呼叫CS用户的P2。

P6：VMSC/MGW接收UE_A应答消息，将消息中携带的编解码格式（AMR-NB modeset=7）与UE_B消息中的编解码格式（GSM EFR）进行比较。

① 如果完全一致或存在交集，则将UE_A应答消息的编解码格式直接透传给UE_B。

② 如果不存在交集，则VMSC/MGW申请媒体格式转换资源实现UE_A侧编解码格式（AMR-NB modeset=7）与UE_B侧编解码格式（GSM EFR）之间的转换；VMSC/MGW将UE_A应答消息中的编解码格式修改为UE_B支持的编解码格式（GSM EFR）并将该消息发送给UE_A。

P7：VMSC/MGW接收UE_B侧的编解码格式（GSM EFR）的RTP媒体码流并进行格式转换。

① VMSC/MGW对接收的UE_B侧（GSM EFR）媒体码流进行解码得到UE_B侧音频信号，并将该音频信号重新编码为UE_A侧编解码格式（AMR-NB modeset=7）的RTP媒体码流。

② VMSC/MGW将转换后得到的UE_A侧编解码格式（AMR-NB modeset=7）的RTP媒体码流发送给UE_A。

P8：MGCF/IM-MGW接收到UE_B侧的RTP媒体码流后，对RTP媒体码流做UP头转换后发送给UE_A。

P9：MGCF/IM-MGW接收到UE_A侧的RTP媒体码流后，对RTP媒体码流做UP头转换后发送给UE_B。

P10：VMSC/MGW接收UE_A侧的编解码格式（AMR-NB modeset=7）的RTP媒体码流并进行格式转换。

① VMSC/MGW对接收的UE_A侧（AMR-NB modeset=7）媒体码流进行解码得到UE_A侧音频信号，并将该音频信号重新编码为UE_B侧编解码格式（GSM EFR）的RTP媒体码流。

② VMSC/MGW将转换后得到的UE_B侧编解码格式（GSM EFR）的RTP媒体码流发送给UE_B。

8.3.3 SRVCC场景的编解码协商

eSRVCC切换过程中，SRVCC IWF根据STN-SR向ATCF发送Invite消息，携带了SRVCC IWF与切换方UE_A进行编解码协商后得到的编解码集A。如果IMS侧的编解码集B与编解码集A有交集C，则ATCF进行编解码协商后使用编解码集C进行eSRVCC切换。如果编解码集B与编解码集A无交集，则SRVCC IWF与ATCF之间需要进行编解码转换。

在现网VoLTE业务解决方案中，一般由ATCF完成SRVCC IWF与ATCF之间的编解码协商和转换，并优先选择SRVCC IWF提供的首选编解码，避免SRVCC IWF侧再插入TC（Transcoder）进行编解码转换。

备注：SRVCC/eSRVCC切换过程中，仅激活（Active）状态会话和告警（Alerting）状态会话切换涉及编解码协商和转换。保持状态会话切换过程中，ATCF不做承载切换控制，直接回落至SRVCC流程，不涉及编解码协商和转换。

8.3.3.1 Active状态会话切换的编解码协商流程

UE_A和UE_B正在进行通话时，UE_A从E-UTRAN网络移动到UTRAN/GERAN网络，发生eSRVCC切换。切换过程中，SRVCC IWF与ATCF之间的编解码协商和转换流程如图8-15所示。编解码协商信令流程如图8-16所示。

流程1：MME向UE_A当前所在地区的SRVCC IWF发起eSRVCC切换请求PS to CS Request消息，携带切换支持的编解码列表，如图8-17所示。

流程2～3：SRVCC IWF进行编解码协商得到切换方UE_A支持的编解码，发送ADD Req消息给MGW建立UE_A侧的承载端点。

流程4～5：SRVCC IWF将UE_A的编解码和中继网关支持的编解码取交集，使用交集的首选编解码，发送ADD Req消息给MGW建立IMS侧的承载端点。

流程6：SRVCC IWF向MME返回PS to CS Response消息。MME收到消息后，指示UE_A向UTRAN/GERAN网络发起切换。

流程7：SRVCC IWF根据STN-SR向ATCF发送Invite消息，携带SRVCC IWF与UE_A进行编解码协商后得到编解码。

Invite消息示例如下。

P1：ATCF进行编解码协商，流程如图8-18所示。

备注：现网ATCF一般与SBC同是物理实体，即在SBC上新增的一个逻辑功能实体。

流程8：ATCF向SRVCC IWF返回200 OK，携带协商后的编解码信息。

200 OK消息示例如下。

P2：SRVCC IWF收到ATCF的200 OK后，直接使用消息中携带的编解码，不再进行后续的编解码协商。如果ATCF返回的编解码和SRVCC IWF在Invite消息中携带的首选编解码不一致，则SRVCC IWF需要更改编解码，插入TC，控制MGW完成媒体转换。

（可选）流程9～10：如果ATCF返回的编解码和SRVCC IWF在Invite消息中携带的首选编解码不一致，SRVCC IWF根据ATCF返回的编解码，发送MOD Req消息给MGW修改IMS侧的承载端点。

流程11：SRVCC IWF返回消息接收成功响应ACK。

流程12：ATCF向SCCAS发送Invite消息，请求eSRVCC切换。

8.3.3.2 Alerting状态会话切换的编解码协商流程

UE_A呼叫UE_B，UE_B处于振铃态。UE_A从E-UTRAN网络移动到UTRAN/GERAN网络，发生eSRVCC切换。切换过程中，SRVCC IWF与ATCF之间的编解码协商和转换流程如图8-15所示，编解码协商信令流程如图8-19所示。

流程1～7：消息处理流程与第8.3.3.1节中的第1～7步相同。

P1：ATCF进行编解码协商，其处理流程与第8.3.3.1节中（图8-16）基本相同，差别在于ATCF完成编解码协商和转换后，向SCCAS发起切换请求，编解码协商结果通过183消息返回给SRVCC IWF。

流程8：ATCF向SCCAS发起切换请求，携带协商后的编解码信息。

流程9～10：SCCAS返回183消息，携带协商后的编解码信息。

P2：SRVCC IWF收到183消息后，处理流程与第8.3.3.1节中的P2相同。

（可选）流程11～12：如果ATCF返回的编解码和SRVCC IWF在Invite消息中携带的首选编解码不一致，SRVCC IWF根据ATCF返回的编解码，发送MOD Req消息给MGW修改IMS侧的承载端点。