MT Call 界面滑动多次才成功接听分析
场景：
双卡（联通+电信）在位，外线来电，测试机前三次滑动接听无法接通，第四次滑动才接通。第二次出现此现象时，滑动接听一次，接听按钮返回中间，等待了一段时间才跳转至通话界面 。
问题：
为什么前三次接听不了，直到第四次才成功？
为什么滑动接听一次，按钮等待一段时间才跳转到通话界面？
分析：
从AP（应用处理器，运行Android系统）和BP（基带处理器，运行AMSS操作系统）来看，通信模块的架构描述为：
左侧Telephony和Qcril属于AP侧模块，右侧CM模块、NAS层的MM、CNM、MN模块，层三的RRC和RR都属于BP侧模块。
QMI是AP与BP之间的基于共享内存的跨处理器通信处理模块，双工模式，C/S结构设计。
UE被叫信令流程：
1. 核心网侧的NAS实体给UE发Paging 信令，告诉UE有人找你
2. UE回复Paing Response 给核心网侧的NAS实体
3. 核心网下发CC/Setup和UE回复CC/Call Confirmed给网络，为建立连接预留资源
4. UE侧振铃，回送CC/Alerting给网络
5. UE摘机的话，回送一条CC/Connect信令给网络，网络确认此连接，下发一条CC/Connect Acknowledge 给UE
6. UE挂机发送CC/Dissconnect
7. 网络下发CC/Release拆除连接，释放资源。UE确认拆除，回送CC/Release Complete
UE被叫，协议栈模块MMCNM 、MNCM之间的交互
1. 来电以及接听(CM_MT_CALL_IND、CM_MT_CALL_RES)
2. 对方挂断电话(CM_MT_DISC_IND)
3. 己方挂断电话（CM_MO_END_X_CALL_REQ)
流程相关LOG检查
1. UI滑动一次，就是发一个RIL_REQUEST_ANSWER请求给Qcril，qcril将此请求通过QMI message发给modem侧的CM模块
2. QMI message(Request/Response) received in QCSI Framework对比qcril 和qmi的时间戳，看到13min50s的这次请求很快完成，没有延迟。且从Indication看出，call state马上变为会话（CALL_STATE_CONVERSATION）状态。到这里，说明qcril、qmi都没有问题，下面要check CM以及NAS层相关的模块
3. CM 层log，看何时发生何种call event，voice call的event 在cm.h 的cm_call_event_e
枚举体中定义
4. NAS 层的CC 信令
以上CM事件以及CC信令分析，可以确认是网络响应CC/Connect 信令延迟导致的滑动接听后延迟的问题。前三次滑动接听不了，第四次才成功，本质上是一样的，分析过程略。我们只看看CM事件和CC信令是否有延迟的情况。如下截图：
结论就是，
1. UI界面滑动接听电话，在UE modem发送CC/Connect信令给网络，且网络要对这条信令进行确认，即回复CC/Connect Acknowledge
2. 如果网络侧CC/Connect Acknowledge确认信令延迟发送到UE的时间较长(>1s)，直观地反映在UI界面就是滑不动，给人的感觉就是滑动接听不成功。
原创文章，未经作者允许，拒绝商业用途的转载、复制、编辑！！
