鲁达 问题：需要确定为何在IMS 上失败以及fall back to GSM retry，为何仍然报错？
QCAT 分析
QCAT 过滤0X1544（QMI_MCS_QCSI_PKT）qmi 消息，再找关键字：
voice_sups|query_|voice_get_|SS_sups_failure|failure_cause, 在问题时间点附近找到以下报错：failure_cause = QMI_FAILURE_CAUSE_ILLEGAL_SS_OPERATION
QXDM 分析
SS failed问题CM LOG关键点打印
>>CM supscmd 4, CM_SUPS_CMD_INTERROGATE 定义在cm.h 枚举enum cm_sups_cmd_e{…}
后面CM_ INTERROGATE_SS_CONF是对CM_ INTERROGATE_SS_REQ的确认，这样一对REQ/CONF 表示一个完整的请求-处理-响应过程。
SS 在IMS 失败原因分析
从截图log分析，因为IMS失败，IMS 模块要求去CS 上重试，最后由CM触发了ESR。
ESR (extend service request)OTA log:
在ESR前面，发现CM有如下打印：
fallback reason: 1 去代码里查发现cm.h里面定义：CM_IPSUPS_FAILURE_CAUSE_PDP_FAILURE,
至此触发ESR过程fallback to gsm的原因找到，应该是PDP_FAILURE导致tcp socket error，
需要进一步分析PDP异常的原因。
Check DS Fail
Error 26 D DSS_ERROR_CONNECT_OPERATION_FAILED = 26
Error 49 D DSS_ERROR_SHUTDOWN_OPERATION_FAILED = 49
SS 在GSM 失败原因分析
此例子中，触发了ESR, CSFB 到GSM上去，但是在CS上仍然失败，所以过滤UMTS OTA log，看是否与网络有交互，如下：
看到两条SS相关的信令：SS/Register, SS/Release Complete。
SS/Release Complete信令内容如下：
可以看到SS/Release Complete 信令携带了return_error_comp错误字段，且error_code[0]=16指明错误代码，因此下一步可以让方案商协助分析或者自己查看3GPP NAS协议，确定是否是协议中定义场景。
SS 属于NAS 层业务，以上错误字段的定义请见协议24.080-f00-《Mobile radio interface layer 3-Supplementary services specification;Formats and coding》。
进一步，在以上SS/Release Complete OTA log 时间点附近过滤出以下trace log：
Wireshark分析"查询呼叫转移"状态的pcap包
LTE网络下，查询"呼叫转移"查询状态，UE使用HTTP GET方法与IMS侧AS（application sever）交互。方便协议分析，可以使用QCAT 工具将.isf文件转换成.pcap文件，然后使用Wireshark工具打开。尝试通过tcpdump工具在手机上去抓取，但是没有抓到相关包，疑问中！！
QCAT 时序图
通过QCAT的"View"-"Call Follow Analysis"工具可以看到模块之间的时序图，通过它能直观地看到所有与Call 相关的modem 模块的交互过程，可以帮助确定问题所在模块（层）。
以下为一个呼叫转移增值业务查询的时序截图：
a) CM模块下发CM_INTERROGATE_SS_REQ 给MN，
b) MN的CNM发送MMCNM_EST_REQ要求MM做连接建立动作
c) MM发送MS_MM_请求给RR
d) RR又发MPH_START_GSM_MODE_REQ给GL1（物理层）
…
一层层反馈，给client以XXX_CNF 确认消息
e) CM模块最终收到CM_INTERROGATE_SS_CNF 确认，流程完成。
CM_INTERROGATE_SS_REQ 触发：
CM_INTERROGATE_SS_CNF 确认：
结论：无论是IMS域还是CS域，从OTA信令以及错误码基本可以判断为核心网侧的问题。如果想深入继续深入分析，可以通过tcpdump 再抓取TCP/IP 完整数据包使用wireshark工具解析。