在步入正题前，请先回答下面4个问题。如果都答对了，恭喜您，您对于这方面知识已经门清了，可以忽略本文了：）
为什么需要Feature Tag?（Why We need FT?）
From IETF RFC-3840 “Indicating User Agent Capabilities inthe Session Initiation Protocol (SIP)”,
原因就是SIP终端形态和能力多种多样，如PC上SIP应用，如支持视频电话的手机，如仅支持语音的手机，因此SIP网络实体有必要了解每个SIP终端的能力和功能。例如网络应用想要发一个MESSAGE给一台SIP终端，但在发送前，需要得
知这台终端是否有能力接收MESSAGE。因此在终端注册时需要上报其能力。
继续摘自IETF RFC-3840，里面回答了开篇的第一个问题（the answer to the first question）。这种表示能力和特性的信息会被Contact头部承载，并且包含在REGISTER请求与响应，OPTIONS响应和任何能创建SIP对话的消息里，如INVITE。
再回答比较容易的第二个问题（the answer to the second question）
From IETF RFC-6809 "Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)"
这里明确指出了RFC3840是有关表达User Agent(UE)能力的，而RFC6809提出的新的SIP头部<Feature-Caps>是传达其他SIP实体能力的，如P-CSCF和S-CSCF。
因此在UE端日志里，能看到Feature-Caps头时，必然是在Network to UE方向。
例如，
Direction = NETWORK_TO_UE
Feature-Caps:*;+g.3gpp.srvcc;+g.3gpp.srvcc-alerting;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
在继续揭晓第三个问题的答案前，让我们通读下协议，先分别了解SIP REGISTER和SIP INVITE下Contact头部构成是如何规定的。
( Before annoucing the answer to my third question, Let's go through all related specifications to know what it says about how to form the Contact Header seperately in SIP REGISTER and SIP INVITE )
1) Contact header in SIP REGISTER
From 3GPP TS 24.229, K.2.1.2.2 Initial registration
TS 24.229规定了UE在Contact里应该包含代表自己IP地址或者域名的SIP URI，Instance ID和所有支持的ICSI。这里Instance ID和ICSI又是什么鬼？
From 3GPP TS 23.003,
Instance-ID就是Contact头部的参数之一，用来唯一标识User Agent的。如果UA存在IMEI号( 请在手机拨号盘里拨打*#06# ），需要采用urn:gsma:imei:<imeival>的形式构建Instance-ID.
TS 24.229里进一步阐述Instance ID只是用来标识设备，非用户相关信息。所以更为准确地说，卡中的IMPU + 标识设备的Instance ID才能真正唯一标识UA实例.当然它还提到了3GPP2世界里替代IMEI的MEID等。
但在SIP Invite里并没有提及需要包含Instance ID，所以此处为定制项，根据运营商具体需求决定是否包含，Q方案需要配置overideConfig文件里的
[SIPConfig:FeatureFlags]
IsSipInstanceNeeded = 1
From 3GPP 23.228, IP Multimedia Subsystem (IMS);Stage 2
标识User subscription的有了，标识Device的有了，其实剩下的您也能够猜出来了，最后就是标识服务/service的ICSI了，类似于TCP/IP世界里的端口概念，一看到80就是HTTP，21就是FTP应用等。这样终端可以把SIP消息分发到正确的应用服务，网络结点也可以选择正确的应用服务器来服务UE。
搞懂了ICSI和Instance-ID后继续查阅
From 3GPP TS 24.229, 5.1.1.2 Initial Registration
看见红线标注的了么？总算提到了UE应该包含media feature tag了，但具体是什么，只字未提，只是说RFC 3840里定义的、UE支持的FT就要包含。查阅RFC 3840的第10章节Media Feature Tag Definitions后，其实就audio和video这两个FT有些帮助。
3GPP里关于IMS知识写的很粗的时候，就要看看GSMA的IR标准了。
From GSMA.IR.92 IMS Profile for Voice and SMS Version 10.0
From GSMA.IR.94 IMS Profile for Conversational Video Service Version 11.0
GSMA.IR.92联合IR.94的补充对于SIP REGISTER里contact头部应该包含哪些参数真是细致到无微不至。大体就是下面这种组合
Contact:
<sip:4111e26f-8b78-46da-a09d-552e3b12e79d@[fc01:abab:cdcd:efe1:a7d0:726c:640f:2de]:5060>;
+sip.instance="<urn:gsma:imei:00440245-884755-0>";
+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";
+g.3gpp.smsip;
audio;
+g.3gpp.accesstype="cellular2"
video; //If UE is VT capble
其中，+g.3gpp.accesstype的意思如下：
This feature-tag when used in a SIP REGISTER request indicates access network technology used by the device and the particular registration flow that the device is using to register over. [3GPP TS 24.292]
eg, +g.3gpp.accesstype="cellular2" for VoLTE
+g.3gpp.accesstype="wlan1" for VoWifi
2) Contact header in SIP INVITE
From 3GPP TS 24.237,IP Multimedia Subsystem (IMS) Service Continuity; Stage 3
24.237里只提到了它所关心的跟SRVCC/bSRVCC/aSRVCC/mid-call SRVCC有关的media feature tag，即
1. g.3gpp.mid-call
This feature-tag when used in a SIP request or a SIP response indicates that the function sending the SIP message supports the MSC server assisted mid-call feature. [3GPP TS 24.237]
2. g.3gpp.srvcc-alerting
This media feature-tag when used in a Contact header field of a SIP request or a SIP response indicates that the functional entity sending the SIP message supports SRVCC access transfer for calls in alerting phase, i.e. for calls within early dialog. [3GPP TS 24.237]
3. g.3gpp.cs2ps-srvcc-alerting
This media feature-tag when used in a Contact header field of a SIP request or a SIP response indicates that the functional entity sending the SIP message supports CS to PS SRVCC access transfer for calls in alerting phase. [3GPP TS 24.237 11.10.0]
4. g.3gpp.cs2ps-srvcc
This media feature tag when included in Contact header field indicates support of the CS to PS single radio voice call continuity as specified in 3GPP TS 24.237. [3GPP TS 24.237 11.10.0]
5. g.3gpp.ps2cs-srvcc-orig-pre-alerting
This media feature tag when used in a Contact header field ofa SIP request or a SIP response indicates that the functional entity sending the SIP message supports the PS to CS SRVCC for originating calls in pre-alerting phase. [3GPP TS 24.237 12.8.0]
所以还要看GSMA的IR标准。
From GSMA.IR.92 IMS Profile for Voice and SMS Version 10.0
From GSMA.IR.94 IMS Profile for Conversational Video Service Version 11.0
UE一定要在SIP INVITE request和相应response(如180 ringing、183 session progress、200 OK）的Contact头部包含audio FT. 对于video FTs有些意思，V11版本直接说了即使不是在拨打或者接听VT电话（video media not in SDP offer），只要手机支持VT功能就要包含video FT。
还记得haykey哥以前写过的《SS系列之呼叫转移（CDIV )业务 --- 实践篇》里的这页胶片么？NV#69673 ims_operation_mode么？只有NV#69673 = 2时手机才遵守GSMA IR.92/.94标准，即上面阐述的FT添加逻辑。但是你也可以看到美帝岛国的大运营商们都有自己的一套，到时还需要查看他们的VoLTE白皮书而定。
haykey哥在国庆期间加班解决一个TA问题（我司的叫法，Type Approval的缩写，类似于国内的CTA, 欧洲GCF,北美PTCRB）。顾名思义如果有fail项直接block产品入库发布，所以都是必解问题。就是标题的TS36.523-1 TC11.2.2项失败，失败点为我司产品在发起紧急电话的SIP Invite上没有携带video feature tag。先暂不提这个问题的debug心路历程。先带大家看看查阅相关协议时发现的下面这些有用的表格。
From 3GPP TS 34.229,
Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); User Equipment (UE) conformance specification;
Part 1: Protocol conformance specification
A.2.1 INVITE for MO Call Setup
里面列举了在SIP Invite的Contact头要包含哪些参数的前提条件。如feature-param = video的前提就是A10条件，即UE支持VT功能。我就不一一列举了，大家保存好这两张表，到时查阅即可。
同理还有适用于SIP Register的两张表：
至此，第三个问题的答案也揭晓了，对于每个feature tag就是要看那些对应的A几条件是否满足。实际上我认为这就是废话，因为理论和实践永远是有GAP的。
针对Q平台的话，你就要看对应service是否enable了，并且相应的feature tag是否在相关NV里填写了。Haykey哥总结了基于最新AT平台上常见FT的NV项，请收下
最后，总算可以看看标题里的那个案例了。
TC11.2.2(TS36.523-1) Failed at Step 7-21 , A.2.1 condition A10, A11: Missing feature-param in Contact header
由于IMS协议栈代码并不开放给客户，无法得知845的ISMFeatureTag.cpp为何无厘头地自动添加Video Feature Tag。haykey哥只能把这段日志贴给原厂寻求帮助。在等待回复的同时，我又翻阅了TC11.2.2引发的诸多协议，发现了端倪。
这唯一的区别就是A11的有无. Rel 13要求UE支持VT并且拨打VT电话时才能在SIP INVITE的contact头加Video FT. Rel 14则是只要UE支持VT即可添加Video FT, 吻合GSMA.IR.94 V11的描述
( Video feature tag must be present only if A10 is met for Rel14.
Video feature tag must be present when both A10 and A11 are met for Rel 13.)
那是不是基于835平台的DUT支持TS 34.229-1 Rel 13版本，晚一年发布的845平台已经更新到支持TS 34.229-1 Rel 14呢？经过和原厂支持的double confirm, So it is.
( For DUT, the AT2.0 platform supports at most TS 34.229-1 version 13
For REF, the AT4.0 platform already updated to support TS 34.229-1 version 14. )
最后让第三方TA实验室更换TTCN脚本到Rel 13，继续测试后TC11.2.2通过。
（本文完）