200 OK消息后MSC发送BYE消息

【问题现象】

eSRVCC切换时eMSC发INVITE到ATCF, ATCF回200 OK，eMSC再回ACK同时发送BYE拆线，切换失败。

【原因定位】

1) 之前SRVCC切换测试已经成功，排除eMSC本端数据配置问题.

2) 了解到ATCF侧也没有修改参数.

3) 逐个比对eSRVCC切换测试成功和不成功时eMSC和ATCF的交互信令和其中参数。 发现eMSC向ATCF发向invite消息之后，ATCF回的200 OK消息中precondition消息参数存在不一致，而且随后eMSC发送bye消息拆线。

切换成功时的ATCF回的200OK：

SIP/2.0 200 OK

Call-ID: 6p5z85o0zp60szs56ht653h5mhtm6o28@10.18.5.64 Via: SIP/2.0/UDP

10.184.87.110:5066;received=10.184.87.110;branch=z9hG4bKmz9hst9h4mh896h9h0ot9tsz6;X-D ispMsg=1406

To: “+8613412345”

<sip:+8613412345@10.189.18.7;transport=udp;user=phone>;tag=545c2d1b-545c8eb0bde7de7

–gm-po-lucentPCSF-000355 From:

“+8618452600024″<sip:+8618452600024@10.184.87.110;transport=udp;user=phone>;tag=33 ottu35-CC-1015-TRC-259895-OFC-9

CSeq: 1 INVITE

Require: timer

Contact: <sip:pcsf-v6vo.imsgroup0-001.js.chinamobile.com:5060> Content-Type: application/sdp

Session-Expires: 1800;refresher=uac Supported: timer

Content-Length: 432

Server: Alcatel-Lucent-HPSS/3.0.3

v=0

o=LucentPCSF 1888449251 1888449251 IN IP4 imsgroup0-001.js.chinamobile.com s=-

c=IN IP4 10.189.25.4

t=0 0

m=audio 32434 RTP/AVP 102 116

a=rtpmap:102 AMR/8000 a=fmtp:102 mode-set=7; max-red=0 a=rtpmap:116 telephone-event/8000 a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv a=sendrecv

a=ptime:20 a=maxptime:20 a=silenceSupp:off – – – –

切换不成功时的ATCF回的200OK：

SIP/2.0 200 OK

Call-ID: tjvtepw7w78vneimn6vscmeiv8jmw7uj@10.18.5.64 Via: SIP/2.0/UDP

10.184.87.110:5068;received=10.184.87.110;branch=z9hG4bKvptsmwvncnweieuj6cp8p6wj7;X-D ispMsg=1404

To: “+8613412345”

<sip:+8613412345@10.189.18.7;transport=udp;user=phone>;tag=545c2d1b-546021bb2072eb b2-mw-pt-lucentPCSF-000913

From: “+8618452600024″<sip:+8618452600024@10.184.87.110;transport=udp;user=phone>;tag=vct 7eu8m-CC-1005-TRC-257332-OFC-9

CSeq: 1 INVITE

Require: timer

Contact: <sip:pcsf-v6vo.imsgroup0-001.js.chinamobile.com:5060> Content-Type: application/sdp

Session-Expires: 1800;refresher=uac

Supported: timer Content-Length: 445

Server: Alcatel-Lucent-HPSS/3.0.3

v=0

o=LucentPCSF 108201857 108201857 IN IP4 imsgroup0-001.js.chinamobile.com s=-

i=A VOIP Session c=IN IP4 10.189.25.4

t=0 0

m=audio 33322 RTP/AVP 102 116 b=AS:38

b=RS:375 b=RR:1125

a=rtpmap:102 AMR/8000 a=fmtp:102 mode-set=7; max-red=0 a=rtpmap:116 telephone-event/8000 a=curr:qos local sendrecv a=curr:qos remote none

a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=sendrecv

a=ptime:20 a=maxptime:20

协议关于precondition参数的说明如下：

RFC 3312 – section 5.2 Generating an answer
Desired Strength: We define an absolute ordering for the strength-tags: “none”, “optional” and “mandatory”. “Mandatory” is the tag with the highest grade and “none” thetag with the lowest grade. An answerer MAY upgrade the desired strength in any entry of the transaction status table, but it MUST NOT downgrade it. Therefore, it is OK to upgrade a row from “none” to “optional”, from “none” to “mandatory”, or from “optional” to “mandatory”, but not the other way around.
从协议的规定看，precondition参数，应答侧消息中该参数的不能低于发送侧的参数级别。

“Mandatory” 级别最高， “none”级别最低；而且只能升级或不变，不能降级。

4) 查看200 OK 消息对应的eMSC发送给ATCF的INVITE消息：

a=des:qos mandatory local sendrecv

a=des:qos optional remote sendrecv
可以看到，invite 要求本端（EMSC侧）为mandatory 。但是切换失败时，ATCF回的200OK消息中，远端（eMSC侧）为optional，不符合协议。

eMSC发送给ATCF的INVITE和ATCF回的200OK消息中precondition 参数协商失败，导 致eMSC异常拆线。
根据ATCF反馈是透传终端参数所致，更换终端后问题解决。

【解决方案】

ATCF反馈是透传终端参数所致，更换终端后问题解决。

本文整理自网络，文章版权归原作者所有，如有侵权，请联系我们进行删除。小编微信（gprshome201101）

长按下方二维码图片 > 识别图中二维码 > 关注“51学通信公众号”

51学通信接头方式如下：