紧接上期《有中国特色的紧急呼叫》里提到过有中国特色的110、119、120、122、999会放到NV#69737 /nv/item_files/pbm/pbm_hardcoded_ecc_list，并且配置hardcoded_type = 0x01 ，意味着不插卡时call type是emergency type，插卡时call type是normal call(CC Setup)。所以当UE VoLTE注册成功后拨打110、119、120、122、999这些紧急号码走的是普通的VoLTE Call流程，然后会遇到P-CSCF响应的380 Alternative Service。具体详情，推荐阅读春天哥的以下文章，这里就不做过多阐述。
秉着Haykey哥一向遵守的理论结合实践的原则，咱们先过一遍相关的协议理论。
摘自3GPP TS23.167 IP Multimedia Subsystem (IMS) emergency sessions
这里提到了P-CSCF会配置并识别这些终端未检测出为紧急呼叫的号码，当检测到被叫为这些号码后，会拒绝掉本次回话并且指示终端该呼叫应为紧急呼叫，通常采用的SIP信令就是380 Alternative Service。UE收到后会选择一个合适的域继续发起紧急呼叫。
这个域协议上就3种选择，CS CN domain，PS CN domain和IMS CN domain。实际上目前PS CN domain = IMS CN domain。
那么，UE具体选择哪个domain域发起后续紧急呼叫的准则是什么呢？
摘自3GPP TS22.101 Service aspects;Service principles
通俗来讲，就是目前对于附着在多个domain上的UE（即注册在IMS域上又联合附着在CS域上），之前UE选择什么域上拨打普通电话，就应该用同样的域上拨打紧急电话，除非网络明确要求UE在哪个域上发起紧急呼叫。以下图为例，UE选择的是IMS domain优先，所以紧急呼叫也应该在IMS域上呼出。
你要是连这个voice domain pref都懵逼的话，再次强烈建议阅读春天哥的以下两篇强文来加深相关概念理解。
那什么叫做网络明确要求UE在哪个域上发起紧急呼叫呢，玄机就在380带的ims-3gpp XML上，一般国内运营商都在<reason>上注明Please retry by other network，意味着在CS域上发起CSFB紧急呼叫，
当然有的海外运营商网络会要求在IMS域上发起Emergency registration后，再发起Emergency Session，如下：
以Haykey哥目前遇到过的形形色色的380 Alternative Service，特总结如下：
最近，Haykey哥遇到了几个实际案例，可以归结为一类问题，就是当VoLTE UE发起Non detectable Emergency的普通VoLTE呼叫时，收到PCSCF响应的380状态字提示为emergency，但是并没有按照预期继续在CS或者IMS域上继续发起紧急呼叫。能够确定这就是UE问题么？参考以下协议后，发现UE行为正常，又是再给网络问题背书：）
摘自3GPP TS24.229 IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
这里提到了两个关键信息。第一，包含PAI头部（P-Asserted-Identity），且内容必须等于注册(SIP Register)时所带PATH头部的最后一项，即PCSCF的IP地址或者FQDN；第二，包含ims-3gpp XML，有verstion属性，<alternative-service>子元素<type>设置为emergency。只有当这两个条件都满足的时候，UE才会继续选择合适的domain进行紧急呼叫。
针对这两个条件，常出现由于运营商网络配置不当，造成的异常情景有
i. 不包含ims-3gpp XML
这种情景下的380如下图所示：
ii. 不包含PAI或者包含PAI，但是不等于注册(SIP Register)时所带PATH头部的最后一项
做全球海外市场的好处，就是Haykey哥有幸能接触到全部这两种异常情景：）
、
对于这两种异常情景，UE不会继续在CS或者IMS域上发起紧急呼叫。按理说是符合协议规定的。但紧急呼叫的重要性不言而喻，涉及到财产，甚至人身安全，Q平台做了个workaround来禁止掉UE检查380的合法性，开关通过NV#67257 /ims/qp_ims_voip_config[VoIPConfigDisableChecksFor380Res]控制，当VoIPConfigDisableChecksFor380Res = 1 时禁止掉UE检查380的合法性，即使网络配置380有问题，紧急呼叫仍然会正常进行。
Haykey哥经过实验发现此NV开关开启或者关闭时， IMS日志中会反应如下
IMS/High [ qipcallh.c 41724] alternate_service_event: is_s_h_enabled : 1 --> NV67257 VoIPConfigDisableChecksFor380Res
IMS/High [ qipcallh.c 41724] alternate_service_event: is_s_h_enabled : 0
最后按照惯例，让大家看看针对不同情景下的典型日志，以便日后遇到类似问题时可以关键字搜索。
情景1：Workaround未开启时，P-CSCF回复不包含ims-3gpp XML的380 Alternative Service
2017 Dec 20 13:19:42.208 [7E] 0x156E IMS SIP Message -- IMS_SIP_INVITE/ALTERNATIVE_SERVICE
Direction = NETWORK_TO_UE
Message ID = IMS_SIP_INVITE
Response Code = ALTERNATIVE_SERVICE (380)
SIP Call ID = 3810273819_383815628@2a02:1400:8a:14a5:e37d:5859:73d1:aed
Sip Message = SIP/2.0 380 Alternative Service
Via: SIP/2.0/TCP [2a02:1400:8a:14a5:e37d:5859:73d1:aed]:41198;branch=z9hG4bK1284131459
//1177未被UE识别为紧急号码
To: <sip:1177;phone- context=ims.mnc008.mcc240.3gppnetwork.org@ims.mnc008.mcc240.3gppnetwork.org;user=phone>;tag=h7g4Esbg_cz1yxnvh1sw6pf6nk86sdixb1cyognh9
From: <sip:+46731483382@ims.mnc008.mcc240.3gppnetwork.org>;tag=3810273823
Call-ID: 3810273819_383815628@2a02:1400:8a:14a5:e37d:5859:73d1:aed
CSeq: 589048347 INVITE
Content-Length: 0
MSG 13:19:42.206 IMS SIP/High [ qpSipUtils.cpp 3407] EVENT_SIP_RESPONSE_RECV: SIP/2.0 380 Alternative Service
MSG 13:19:42.206 IMS/Medium [ sipConnection.cpp 8686] SipConnection::qpSipValidateTransaction | Received a Response : 380
MSG 13:19:42.215 IMS IMS CORE/High [ qpSipSessionServic 2966] SS::notifyResponse | pSipClConn = 16eb7800 StatusCode = 380 | pTmpMethod = INVITE
MSG 13:19:42.215 IMS/High [qpSipSessionService.cpp 4169]EVENT_SIP_SESSION_FAILURE:Response Code: 380
MSG 13:19:42.215 IMS/Medium [ qimfif.cpp 8262] qimfif_handle_message_errors: Status Code: 380, OPRT Mode: 2, event: 4101
MSG 13:19:42.215 IMS/High [ qipcalldialog.c 6040] [qipcalldialog_process_incoming_msg] [event: 4101] [status_code: 380] [sdpBody_ptr: 0x0]
MSG 13:19:42.215 IMS/High [ qipcallh.c 16192] qipcallh_process_cs_fallback_for_video_invite: status code 380
MSG 13:19:42.215 IMS/High [qipcallSipMsgHandle.c 1885]qipcallh_process_alternate_service_event: Alternate Handling serv type 0: Call End reason : 4（CMIPAPP_END_CAUSE_PERMANENT_FAILURE）,special handling 0,
MSG 13:19:42.215 IMS/High [ qipcallh.c 8311] qipcallh_chg_state_to_null: end_reason = 4, end_request_type = 0
情景2：Workaround未开启时，包含PAI，但是不等于注册(SIP Register)时所带PATH头部的最后一项
2018 Jan 3 11:28:46.501 [9E] 0x156E IMS SIP Message -- IMS_SIP_INVITE/ALTERNATIVE_SERVICE
Direction = NETWORK_TO_UE
Message ID = IMS_SIP_INVITE
Response Code = ALTERNATIVE_SERVICE (380)
SIP Call ID = 718250844_2345788744@11.96.0.7
Sip Message = SIP/2.0 380 Alternative Service
Via: SIP/2.0/TCP 11.96.0.7:8901;branch=z9hG4bK519614051
//10111未被UE识别为紧急号码
To: <sip:10111;phone-context=ims.mnc010.mcc655.3gppnetwork.org@ims.mnc010.mcc655.3gppnetwork.org;user=phone>;tag=h7g4Esbg_df6pnfnvq2rty65bbw68spb9ljd1cgct
From: <sip:+27717555545@ims.mnc010.mcc655.3gppnetwork.org>;tag=718250859
Call-ID: 718250844_2345788744@11.96.0.7
CSeq: 718250844 INVITE
P-Asserted-Identity: <sip:10.100.78.132:7777;transport=tcp;lr>
Content-Type: application/3gpp-ims+xml
Content-Length: 207
<?xml version="1.0" encoding="UTF-8"?>
<ims-3gpp version="1">
<alternative-service>
<type>emergency</type>
<reason>Emergency Call over LTE is not supported</reason>
</alternative-service>
</ims-3gpp>
MSG 11:28:46.508 IMS/High [qpSipSessionService.cpp 4092]EVENT_SIP_SESSION_FAILURE:Response Code: 380
MSG 11:28:46.514 IMS/High [ qipcalldialog.c 5010] [qipcalldialog_process_incoming_msg] [event: 4104] [status_code: 380] [sdpBody_ptr: 0x0]
MSG 11:28:46.514 IMS/High [ qipcallh.c 41724]alternate_service_event: is_s_h_enabled : 0 --》VoIPConfigDisableChecksFor380Res = 0
//PAI检查失败
MSG 11:28:46.515 IMS/High [ qimfif.cpp 12798] AlternateHandling:validate_p_asserted_id failed
MSG 11:28:46.515 IMS/High [ qipcallh.c 41763] alternate_service_event: Some thing wrong with P-ASSERTED-ID, Sending PERMANENT failure to CM
MSG 11:28:46.514 IMS/High [ XmlDecoder.cpp 452] <XML Decoder>:Decoder Success
//PAI = 10.100.78.132 from 380 Status
MSG 11:28:46.514 IMS SIP/High [ sipConnection.cpp 13693] GetHostType |IPv4 = 10.100.78.132 10.100.78.132
//Path = JHSBG1-1-PCSCF.ims.mtn.co.za from 200 OK for SIP Register MSG 11:28:46.514 IMS SIP/High [ sipConnection.cpp 13703] GetHostType |UNKNOWN IP Type JHSBG1-1-PCSCF.ims.mtn.co.za JHSBG1-1-PCSCF.ims.mtn.co.za
MSG 11:28:46.515 IMS/Error [ qimfif.cpp 12951] qimfif_compare_ip_address_part_of_uri | FQDN MisMatch
MSG 11:28:46.515 IMS/High [ qipcallh.c 12236] qipcallh_chg_state_to_null: end_reason = 4, end_request_type = 0
MSG 11:28:46.516 IMS/High [ qipcallh.c 5093] qipcall_call_end_rpt_ind: Call Id=3, State=1,Cause=4
MSG 11:28:46.516 Call Manager/High [ cmipcall.c 2653] =CM= IP RXD: CALL_END, end_cause=4（CMIPAPP_END_CAUSE_PERMANENT_FAILURE）, client_end_cause=430（CMIPAPP_CLIENT_END_CAUSE_ALTERNATE_SERVICE ）, call_id=3
MSG 11:28:46.516 Call Manager/High [ cmipcall.c 579] =CM= VOIP client end cause 430, call_end 430
MSG 11:28:46.516 Call Manager/Medium [ cmipcall.c 5130] =CM=cmipcall_end, reas=430
情景3：Workaround开启时，包含PAI，但是不等于注册(SIP Register)时所带PATH头部的最后一项
018 Jan 3 11:36:40.515 [F6] 0x156E IMS SIP Message -- IMS_SIP_INVITE/ALTERNATIVE_SERVICE
Direction = NETWORK_TO_UE
Message ID = IMS_SIP_INVITE
Response Code = ALTERNATIVE_SERVICE (380)
SIP Call ID = 718725128_2345784552@11.96.0.6
Sip Message = SIP/2.0 380 Alternative Service
Via: SIP/2.0/TCP 11.96.0.6:8901;branch=z9hG4bK2957653073
To: <sip:10111;phone-context=ims.mnc010.mcc655.3gppnetwork.org@ims.mnc010.mcc655.3gppnetwork.org;user=phone>;tag=h7g4Esbg_rh5798m6skycosftmzo8duums1bptmx8
From: <sip:+27717555545@ims.mnc010.mcc655.3gppnetwork.org>;tag=718725140
Call-ID: 718725128_2345784552@11.96.0.6
CSeq: 718725128 INVITE
P-Asserted-Identity: <sip:10.100.78.132:7777;transport=tcp;lr>
Content-Type: application/3gpp-ims+xml
Content-Length: 207
<?xml version="1.0" encoding="UTF-8"?>
<ims-3gpp version="1">
<alternative-service>
<type>emergency</type>
<reason>Emergency Call over LTE is not supported</reason>
</alternative-service>
</ims-3gpp>
MSG 11:36:40.838 IMS/High [qpSipSessionService.cpp 4092]EVENT_SIP_SESSION_FAILURE:Response Code: 380
MSG 11:36:40.844 IMS/High [ qipcallh.c 41724] alternate_service_event: is_s_h_enabled : 1 --> NV67257 VoIPConfigDisableChecksFor380Res
MSG 11:36:40.845 IMS SIP/High [ sipConnection.cpp 13693] GetHostType | IPv4 = 10.100.78.132 10.100.78.132
MSG 11:36:40.845 IMS SIP/High [ sipConnection.cpp 13703] GetHostType | UNKNOWN IP Type JHSBG1-1-PCSCF.ims.mtn.co.za JHSBG1-1-PCSCF.ims.mtn.co.za
MSG 11:36:40.845 IMS/Error [ qimfif.cpp 12951] qimfif_compare_ip_address_part_of_uri | FQDN MisMatch
MSG 11:36:40.845 IMS/High [ qimfif.cpp 12798] AlternateHandling:validate_p_asserted_id failed
//尽管PAI检查失败，UE仍然处理fallback到CS发起紧急呼叫
MSG 11:36:40.845 IMS/High [ qipcallh.c 41671] Alternate Handling: Normal Voice call over CS
MSG 11:36:40.845 IMS/High [ qipcallh.c 41757] alternate_service_event: Alternate Handling:Call End reason : 609
MSG 11:36:40.845 IMS/High [ qipcallh.c 12236] qipcallh_chg_state_to_null: end_reason = 609非4, end_request_type = 0
MSG 11:36:40.845 IMS/High [ qipcallh.c 19896]qipcallh_process_cs_fallback_for_video_invite: status code 380
MSG 11:36:40.847 IMS/High [ qipcallh.c 4987] Sending ALTERNATE SERVICE EMERGENCY to CM for call id: 1
MSG 11:36:40.847 IMS/High [ qipcallh.c 4897] qipcall_alternate_service_rpt_ind: Call Id=1, State=1,Cause=609
MSG 11:36:40.847 Call Manager/High [ cmipcall.c 2653] =CM= IP RXD: CALL_END, end_cause=610（CMIPAPP_END_CAUSE_ALTERNATE_VOICE_CALL), client_end_cause=431（CMIPAPP_CLIENT_END_CAUSE_ALTERNATE_SERVICE ）, call_id=1
//发起CSFB紧急电话
MSG 11:36:40.847 Call Manager/High [ cmcall.c 9105] =CM=csfb_type=2
MSG 11:36:40.847 Call Manager/High [ cmcall.c 31757] =CM=cmcall_process_orig_mode mode_usage=3
（本文完）
