案例现象描述：主叫UE发出SIP INVITE收到100 trying后，相隔一段时间后收到了网络侧下发的SERVICE_UNAVAILABLE（503），如图5-81所示。

协议规定SERVICE_UNAVAILABLE（503）表示服务器由于负荷过载或者维护问题暂时无法处理发送请求。服务器可能会在Retry-After头域里指示客户端何时再进行重发尝试请求。如果Retry-After没有给出，那么客户端必须表现的如同收到Server Interna1 Error（500）响应一样。而对于Server Interna1 Error（500）响应，一般指的是服务器处于不可预计的条件下，从而无法满足请求。客户端可以将该特定错误状况进行展示，例如该次的错误状态为“Media Bearer Lost”，一般收到500响应，可以基本断定是S-CSCF出现的问题，其中P-CSCF只是将之转发。

图5-81 UE发出SIP INVITE后网络侧下发SERVICE UNAVAILABLE

回溯一下信令流程，发现当主叫UE收到了100 trying后，迟迟等不到后续的183-180ringing，以及最后的SIP 200 OK，当大约10 s超时后，由RRC层先进行了链路释放，如图5-82所示。

图5-82 RRC层链路释放

RRC ConnectionRe1ease消息如图5-83所示。

图5-83 RRC Connection Re1ease消息

之后收到503后，其实已经处于RRC-IDLE状态，因此通过网络侧寻呼后又变成了连接态，其实是从主叫状态经历了RRC-IDLE，之后又变成了“被叫”。随后，网络侧下发QCI1的专用承载去激活NAS ESM信令，UE反馈Accept，同时将专用承载状态置为Inac-tive，如图5-84所示。

图5-84 UE反馈Accep，同时将专用承载状态置为Inactive

这里仅仅是专用承载去激活，默认承载QCI9，QCI5还依然保留，EUTRAN侧并没有立即发起RRC释放。后续可能由于目前UE的私有设置，UE变成了一个CSFB终端，后续的信令流程就是标准的CSFB主叫流程了，如图5-85所示。

(www.daowen.com)

图5-85 UE发起了CSFB的标志性流程Extended service request

在UE发起的CSFB流程中，RRC Connection Re1ease消息中携带了2G频点，如图5-86所示。

图5-86 RRC Connection Re1ease消息中携带了2G频点

结合整个流程的分析，推测出现问题是由于UE收到100 trying后没有收到后续SIP响应，因此当10 s超时后，EUTRAN下发了RRC Connection Re1ease，这里释放掉了SRB也同时释放掉了DRB，同时EUTRAN上报核心网由于该UE不活跃（User Inactivity）触发导致MME也将EPS承载释放（这里一般由eNodeB发起，通过UE Context Re1ease Request信令发起，通知MME将该UE的所有在S1接口建立起来的E-RAB释放掉），这样通知IMS域媒体承载释放，也就造成了后续503的下发。问题的关键是需要明确在10 s之内为什么没有收到183-180ringing响应，这里有一种可能是被叫处于CSFB状态（或者CS域），导致协商时间过长，超过了10 s。

有一个值得注意的现象，当网络侧异常释放了RRC连接，即下发了RRC Connection Re1ease，根据协议36.331描述，UE会清空自己所有建立的RB，但是不一定会释放掉EPS Bear，因此当再收到RRC重配消息后，通过重配消息中EPS Bear ID与DRB ID的耦合，可以分别确认默认承载QCI9、QCI5以及话音的专用承载QCI1的映射情况，如图5-87所示。

RRC重配置消息下EPS Bear ID，如图5-88所示。

RRC重配置消息中EPS Bear消息，可以分别确认默认承载QCI9、QCI5以及话音的专用承载QCI1的映射情况，但是在此案例中只有QCI1承载，如图5-89所示。

图5-87 RRC重配置消息

图5-88 RRC重配置消息中EPS Bear ID

图5-89 RRC重配置消息中EPS Bear ID及QCI承载信息