中国移动CMIMS计费关键话单格式规范

QB-中国移动通信企业标准QB-中国移动CM-IMS计费关键话单格式规范China Mobile CM-IMSCDR Technical Specification 版本号：0.9.1-实施-发布中国移动通信有限公司 发布目录1.范围12.规范性引用文件13.术语、定义和缩略语24.IMS计费架构35.ASN.1编码45.1.ASN.1编码概述45.2.ASN.1编码格式45.2.1.标识符的编码规则45.2.2.长度的编码规则65.2.3.内容的编码规则65.2.4.结束符的编码规则86.话单文件结构87.话单内容说明107.1.概述107.2.计费原则117.2.1话单适用范围117.2.2用户标识117.2.3补充业务计费127.2.4漫游计费127.2.5话单查重127.3.AS 话单格式137.4.S-CSCF话单格式197.5.P-CSCF话单格式257.6.MGCF/VIG话单格式308.话单ASN.1定义359.自定义AVP469.1.Call-Description AVP469.2.Service-Identity AVP469.2.1.MMTel业务编号469.2.2.Centrex业务编号489.2.3.彩铃业务编号499.2.4.话务台业务编号499.2.5.点击拨号&点击会议业务编号509.3.Online-Charging-Flag AVP509.4.Group-Number AVP509.5.Short-Number AVP519.6.Subscriber-Identity AVP519.7.Calling-Party-Subgroup-Number AVP519.8.Called-Party-Subgroup-Number AVP5110.编制历史51前言本标准依据ITU-T和3GPP制定的相关标准，结合有关国内标准和中国移动其它企业标准，基于中国移动CM-IMS总体技术要求和实际需求而拟定，充分考虑了网络的平滑演进能力，为中国移动CM-IMS商用初期的网络建设和运行维护提供技术依据。本标准主要包括以下几方面内容：计费架构、ASN.1编码、关键话单格式等。本标准由中国移动通信集团公司业务支撑系统部提出，集团公司技术部归口。本标准由标准归口部门负责解释。本标准起草单位：中国移动通信研究院。本标准主要起草人：陈艾、刘昶、袁向阳、安宁、赵婷。II1. 范围本标准规定了IMS网元计费关键话单的格式，为中国移动引入IMS提供技术依据，供中国移动内部和厂商共同使用；适用于CM-IMS商用初期计费的网络建设和运行维护。2. 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。表2-1序号标准编号标准名称发布单位1QB-xx-xxx-xxxx中国移动CM-IMS计费总体技术要求中国移动通信有限公司2QB-xx-xxx-xxxx中国移动CM-IMS统一Centrex业务总体技术要求中国移动通信有限公司3QB-xx-xxx-xxxx中国移动CM-IMS统一Centrex业务规范中国移动通信有限公司4QB-xx-xxx-xxxx中国移动CM-IMS测试规范_统一Centrex业务分册中国移动通信有限公司5QB-xx-xxx-xxxx中国移动CM-IMS个人多媒体彩铃业务总体技术要求中国移动通信有限公司6QB-xx-xxx-xxxx中国移动CM-IMS个人多媒体彩铃业务规范中国移动通信有限公司7QB-xx-xxx-xxxx中国移动CM-IMS测试规范_个人多媒体彩铃业务分册中国移动通信有限公司8QB-xx-xxx-xxxx中国移动CM-IMS多媒体电话及补充业务总体技术要求中国移动通信有限公司9QB-xx-xxx-xxxx中国移动CM-IMS多媒体电话及补充业务规范中国移动通信有限公司10QB-xx-xxx-xxxx中国移动CM-IMS测试规范_多媒体电话及补充业务分册中国移动通信有限公司11TS 23.228 v7.0.0IP Multimedia subsystem (IMS)3GPP12TS 24.229 V7.0.0IP Multimedia Call Control Protocol based on SIP and SDP3GPP13TS 32.240 V7.0.0Charging management;Charging architecture and principles3GPP14TS 32.260 V7.0.0Charging management;IP Multimedia Subsystem (IMS) charging3GPP15 TS 32.299 V7.0.0Charging management;Diameter charging applications3GPP16 TS 29.213 V7.0.0Policy and charging control signalling flows and Quality of Service (QoS) parameter mapping3GPP17 TS 29.214 V7.0.0Policy and charging control over Rx reference point3GPP18 RFC 4005Diameter Network Access Server ApplicationIETF19 RFC 4006Diameter Credit-Control ApplicationIETF3. 术语、定义和缩略语下列术语、定义和缩略语适用于本标准：表3-1词语英文中文ACAACcounting Answer计费回答ACRACcounting Request计费请求ASApplication Server应用服务器AVPAttribute Value Pair属性值对ASN.1Abstract Syntax Notation One抽象语法标记BGCFBreakout Gateway Control Function边界网关控制功能CCFCharging Collection Function计费采集功能CDFCharging Data Function计费数据功能CDRCharging Data Record计费数据记录CGCharging Gateway计费网关CGFCharging Gateway Function计费网关功能CTFCharging Trigger Function计费触发功能GCIDGPRS Charging IdentifierGPRS计费标识符GGSNGateway GPRS Support NodeGPRS网关支持节点ICIDIMS Charging IdentifierIMS计费标识I-CSCFInterrogating-CSCF查询会话控制功能IMPIIP Multimedia Private Identity私有用户标识IMPUIP Multimedia Public Identity公有用户标识IMSIP Multimedia Core Network SubsystemIP多媒体子系统IMS-GWFIMS Gateway FunctionIMS 网关功能IOIInteroperator Identifier跨运营商标识MGCFMedia Gateway Control Function媒体网关控制功能MRFCMultimedia Resource Function Controller媒体资源控制功能OCSOnline Charging System在线计费系统PCEFPolicy and Charging Enforcement Function策略和计费执行功能P-CSCFProxy-CSCF代理会话控制功能PCRFPolicy Control and Charging Rules Fuction策略控制和计费规则功能SBCSession Border Controller边界控制功能S-CSCFServing-CSCF服务会话控制功能SDPSession Description Protocol会话描述协议SGSNServing GPRS Support NodeGPRS服务支持节点SIPSession Initiation Protocol会话初始协议WLANWireless Local Area Networks无线局域网络4. IMS计费架构Billing DomainONLINECHARGINGOFFLINECHARGINGWLANBGCFMGCFMRFCSIP ASPCRFAFCDFCS-NESGSNCGFP-CSCFI-CSCFS-CSCFService-NEGGSNPCEF图1 IMS公共计费架构IMS作为在UMTS网络中叠加在分组域以及其它IP网络之上的子系统，主要提供会话控制层面的计费。IMS网络能够支持离线计费和在线计费两种方式的计费架构。CM-IMS商用初期主要针对IMS离线计费，本标准对参与CM-IMS离线计费的各网元（经过计费网关处理）产生的话单格式进行规范。5. ASN.1编码5.1. ASN.1编码概述ASN.1是“Abstract Syntax Notation One”的缩写。ASN.1可以被看作一种高层协议描述语言，由于它可以用来清晰地描述复杂的数据结构，因而被广泛的作为应用层协议语法的标准。ASN.1给协议设计者提供了一些简单的数据类型，如整型(Integer)、布尔型(Boolean)以及字节串(Octet string)等，以这些简单类型为基础，协议的设计者就可以构造出更复杂的数据类型。通过唯一的“标识符（Tag）”可以很容易的标注出由一系列简单类型组成的复杂数据类型。例如：一张话单可以由一系列数据域的集合组成，每个数据域是一个编码单元或者是多个编码单元的复合。一个编码单元最多包括四部分：l 标识符（identifier octets，或者称为Tag）。l 长度（length octets）。l 内容（contents octets）。l 结束符（end-of-contents octets）：不是必须的，在不定长编码方式下才使用。5.2. ASN.1编码格式本节介绍ASN.1各单元的编码规则及话单文件结构。5.2.1. 标识符的编码规则标识符表示该编码对应的协议数据类型，它的编码分两种情况：1. 标识符值在0-30之间时标识符值在0-30之间时，用一个字节表示，其中各位含义如下：位8和位7代表数据的类型标记（Universal-00, Application-01, Context-specific-10, Private-11）。位6代表该数据单元是原子式还是结构类型（Primitive-0, Construct-1）。位5到位1代表具体分配的TAG值(Number of Tag)。 8 7 6 5 4 3 2 1 +-+-+-+ 1 CLASS P/C TAG NUMBER +-+ Bits 8-7: 数据的类型标记: +-+ Bit: 8 7 +- Universal 0 0 Application 0 1 Context-specific 1 0 Private 1 1 +-+ Bit 6 :原子式 (0) 或 结构类型 (1) Bits 5-1: 5个比特的二进制数2. 标识符值大于等于31时标识符值大于等于31时，用一个前字节和若干后续字节表示。l 前字节的位8、7、6与第一种情况一样，位5到位1为11111。l 后续字节遵守以下规则： 除最后一个字节外，其他字节的第8位为1。 从第一个字节到最后一个字节的第7位到第1位加起来表示tags值。 第一个字节的第7位到第1位不能全为0。如下图所示。 8 7 6 5 4 3 2 1 +-+-+-+-+-+-+- 1 CLASS P/C 1 1 1 1 1 +-+ Bits 8-7: 数据的类型标记 Bit 6 : 原子式 (0) 或 结构类型 (1) Bits 5-1: 全部设置为1后续字节编码如下： 8 7 6 5 4 3 2 1 +-+- first 2 1 NUMBER of TAG (msb) subsequent +- . . . . +- last 0 NUMBER of TAG (lsb) subsequent +-+ Bits 8 : 最后一个字节时，设置为0，其他均设置为1 Bits 7-1: 所有字节的比特71都加起来，就是实际的Tag值5.2.2. 长度的编码规则长度表示内容字段的净长度，不包括内容以外的其他字段的长度。长度有三种表示形式：短编码方式，长编码方式和不定长编码方式。其中，不定长编码方式不应用于ASN.1话单文件中，因此不做更进一步的描述。1.短编码方式当长度127时，用多个字节表示，即为长编码方式： 8 7 6 5 4 3 2 1 +-+- 1 1 0 n 127 +-+ +- 2 L L L L L L L L +-+ . +- n+1 L L L L L L L L +-+ LLLLLLLL表示实际长度的值l 第1个字节的位8固定填写为1，BIT1BIT7表示长度所占的字节数。第2到n+1字节代表长度的值5.2.3. 内容的编码规则内容包含零个、一个或更多的字节，它们的值依赖于所表示的数据类型。如下图所示： 8 7 6 5 4 3 2 1 +- most significant byte octet 1 +- octet 2 +- . . . . +- least significant byte octet n +-+下面对不同的数据类型分别进行介绍。l BOOLEAN该类型只能以原子式进行编码。FALSE编码为：Tag Length Value+- 01H 01H 0000, 0000 +-TRUE的编码（任何不是全0都可以）为：Tag Length Value+- 01H 01H 1111, 1011 +-l NULL该类型只能以原子式进行编码，且只有一个值，这样其Value中就无需填写，即Value处就不会占用空间。Tag Length Value+- 05H 00H +-l INTEGER该类型只能以原子式进行编码。整型分正数和负数两种情况，由于负数不应用于ASN.1话单文件，不加以详述。对于正数，如果最高比特位为0，则直接编码；如果为1，则在最高比特位之前增加一个全0的八位数组（采用的是补码的方式存储）。如下示例250的编码：Tag Length Value+- 02H 02H 0000,0000 1111,1010+-l ENUMERATED该类型编码与INTEGER类型编码方式相同。l BIT STRING该类型可以采用原子式或者结构式，下面以比特串1011011101011B为例，分别介绍以这两种方式进行编码。PrimitiveTag Length Value+- 03H 03H 03H 10110111 01011xxx+-注意在比特串1011011101011B之前增加了一个八位数组，取值为07，表征这个值最后补位的个数，主要是解决比特串可能不是8的倍数。Constructed采用结构式发送时，主要是有部分编码还不能确定时采用，比特串1011011101011B的编码如下：Tag Length Value+- 03H 80H T L V 03H 02H 00H 10110111 03H 02H 03H 01011xxx 00H 00H+-注意：此处整个比特串的Length采用不定长编码。l OCTET STRING该类型编码原则和BIT STRING编码原理一样，但由于该类型直接以八位组为单位，就不存在补位的情况。l SET该类型采用constructed格式编码，其每个成员都是采用TLV格式编码。l SEQUENCE该类型与SET类型编码方式基本一样，只是其成员顺序要与定义保持一致，而SET类型无需如此。l SET OF该类型编码与SET相同。l SEQUENCE OF该类型编码与SEQUENCE相同。其他的不常见的类型，在此不一一介绍。5.2.4. 结束符的编码规则在定长编码结构中不存在，只有在不定长编码结构中存在，此处不加以详述。6. 话单文件结构CCF使用ASN.1（BER）编码规范对处理的每一个CDR记录进行编码，将这些CDR记录存储在一定大小的话单文件中，CCF将这些编码后的话单传送给计费中心。CDR文件结构如下图所示：前面的Header是3gpp文件头，如下结构： BitsOctets876543211.4File length5.8Header length9High Release IdentifierHigh Version Identifier10Low Release IdentifierLow Version Identifier11.14File opening timestamp15.18Timestamp when last CDR was appended to file19.22Number of CDRs in file23.26File sequence number27File Closure Trigger Reason28.47IP Address of Node that generated file48Lost CDR indicator49.50Length of CDR routeing filter每一个CDR记录都是一个ASN.1的编码结构， CDR结构如下： CDR Header Record Data其中CDR Header结构如下：BitsOctets876543211.2CDR length3Release IdentifierVersion Identifier4Data Record FormatTS number7. 话单内容说明7.1. 概述每种类型的话单将会在以下相应的章节中进行详细的说明，包括话单字段，字段的配置属性，字段的来源以及字段的具体描述。每个字段有以下3种方式存在：l M表示某字段总在当前话单中出现，而且必须出现。l O表示某字段在当前话单中可以出现，也可以不出现，依据运营商的计费需求。l C表示某字段在某些确定的条件下才会出现，而且必须出现。这些条件在字段的定义中做了说明。对于可选字段，操作员可以使用OMC（Operation and Maintenance Center）管理功能，或者提供的一些工具来选择是否将本字段包含在话单中。部分字段由子字段构成，存在层次关系，为了清楚地描述这部分字段的层次关系，本章中字段采用NUM上标标注的方式表示字段的层次关系，NUM表示第几层。l 1表示本字段包含子字段，且本字段为第一层。l 2表示本字段是子字段，且本字段为第二层。l 3表示本字段是子字段，且本字段为第三层。l 4表示本字段是子字段，且本字段为第四层。7.2. 计费原则7.2.1话单适用范围 本计费关键话单格式规范定义了CM-IMS核心网元AS、S-CSCF、P-CSCF、MGCF/VIG的基于Diameter消息的话单格式。其中AS包括多媒体电话业务平台（MMTel AS）和统一Centrex业务平台（统一Centrex AS）。目前部署的AS都是由中国移动自建的，属于可信任平台，业务计费都以AS的话单作为计费话单。P-CSCF的话单用于与他域（省）漫游用户计费结算。MGCF/VIG的话单用于与他网的结算。如果MGCF是通过现网软交换关口局或软交换汇接局设备升级改造支持MGCF功能，那么改造升级的关口局或汇接局需要支持MGCF的话单功能。S-CSCF 的话单在商用初期计费方案中暂没被使用，但考虑到S-CSCF在CM-IMS网络中的重要性和今后网络发展的需求，本规范对S-CSCF的话单进行了要求。7.2.2用户标识 在开户时会给IMS域用户分配一个IMPI，每个IMPI可对应多个IMPU，包含1个E.164的TEL URI和1个或多个SIP URI。在CM-IMS网元产生的话单中，通过IMPU来标识不同的用户。在一次会话的过程中，SIP消息中的主叫信息保存在SIP信令PAI消息头中，可以是SIP URI，也可以是TEL URI，记录在计费消息List-Of-Calling-Party-Address字段；但是当前会话的计费方只有一个，记录在计费消息Charged-Party字段，BOSS针对该字段所包含的IMPU进行扣费。BOSS呈现给客户的账单根据客户要求，可以包括该客户拥有的所有IMPU的账单。 话单中主叫方和被叫方用户标识的表示格式为：TEL URI: +861012345678SIP URI: +861012345678主叫方用户标识来自SIP信令PAI消息头，被叫方用户标识来自SIP信令的Invite消息的Request URI中。主、被叫方用户标识应为“+国家码+区号+本地号”形式的IMPU。7.2.3补充业务计费 用户一次服务过程中所使用的补充业务会记录在Service-Identity字段中，BOSS系统可以根据不同补充业务的计费策略进行相应的扣费。 可以根据Record-Type字段来判断用户为统一Centrex用户或者MMTel用户。当用户为Centrex用户时，根据Call-Description字段判断呼叫属性进行相应资费优惠。7.2.4漫游计费对于用户漫游的判断通过Access-Network-Information字段携带用户接入网信息来判定。主叫侧SBC会在其下发的第一个Invite请求、被叫侧SBC会在其返回的第一个响应的SIP消息中填写P-Access-Network-Info头，在该消息头中记录拜访地SBC的地址（例如：sbc(1.n).归属地市区号.归属省名），传给主叫/被叫侧P-CSCF。P-CSCF在其话单的Access-Network-Information字段中填入相同的信息。SIP消息的P-Access-Network-Info头返回到主叫/被叫侧AS，AS将该值填入其话单Access-Network-Information字段中。用户拜访省BOSS系统根据P-CSCF话单中Access-Network-Information字段中描述的接入网信息，可以判定是否有他省用户漫游到本省。用户归属省BOSS系统根据AS话单中Access-Network-Information字段中描述的接入网信息，可以判定本省用户是否漫游到他省。7.2.5话单查重 IMS网元会为SIP会话产生计费标识，即ICID，该标识在一次端到端的会话中是唯一的，即IMS-Charging-Identifier字段。Service-Delivery-Start-Time-Stamp字段标识服务开始时间，Service-Delivery-End-Time-Stamp字段标识服务结束时间。可由主叫地址（List-of-Calling-Party-Address）或者被叫地址（Called-Party-Address） 联合三元组进行话单查重。针对ACREvent消息所生成的CDR文件，可由主叫地址（List-of-Calling-Party-Address）或者被叫地址（Called-Party-Address） 联合二元组进行话单查重。7.3. AS 话单格式下表对AS产生的CDR话单内容进行说明。字段名可配属性字段来源具体描述Record-TypeM由CCF填写话单类型的说明。用来指示该计费信息由哪类网元产生的。MMTel AS的话单中该值为69，表明这是一个MMTel AS的话单。Centrex AS的话单中该值为254，表明这是一个Centrex AS的话单。RetransmissionC来自Diameter消息头的Retransmission字段。说明该话单是否包含网元重传的ACR，有话单重传时该字段必选。话单中出现该字段表示该话单包含网元重传的ACR；不出现该字段则表示不包含网元重传的ACR。SIP-MethodO来自Event AVP的SIP-Method AVP。产生计费话单的原因说明，仅用于会话无关场景。Role-of-NodeM来自Role-of-Node AVP。用来指示AS网元在本次会话中扮演的角色。例如：该AS为主叫用户服务，则为ORIGINATING_ROLE：0；该AS为被叫用户服务，则为TERMINATING_ROLE：1。Node-AddressM来自Origin-Host AVP。用来指示提供本次计费消息的网元标识。AS的话单中，该值可以是AS的IP地址，也可以是AS的全称域名（FQDN）Session-IDO来自User-Session-ID AVP。用来指示该网元收到建立此会话初始请求的Call-ID，即主叫和被叫侧AS所收到SIP请求的Call-ID。List-of-Calling-Party-AddressM来自Calling-Party-Address AVP。服务请求方或者会话发起方的地址 (Public User ID or Public Service ID)，即主叫地址。Calling-Party-Adderss取自P-Asserted-Identify header，既可以包括SIP URL，也可以包括Tel URL，如果P-Asserted-Identify有多个，那么可能包括多个该AVP。Called-Party-AddressM来自Called-Party-Address AVP。在SIP会话中，本字段标识会话接收方的地址，即被叫地址；在SIP注册和订阅过程中，本字段标识被注册和订阅方的地址。本字段既可以包含SIP URL也可以包含TEL URL。对于群外呼叫，AS话单中的被叫号码需要去掉出群字冠。Service-Request-Time-StampM来自ACRStart或者ACREvent中Time-Stamps的子SIP-Request-TimeStamp AVP。显示服务请求的时间，即网元收到SIP请求消息的时间。用来表示服务触发的时间。Service-Delivery-Start-Time-StampM来自ACRStart或者ACREvent中的Time-Stamps的子SIP-Response-TimeStamp AVP。显示服务响应的时间，即网元收到SIP请求消息的响应的时间。用来表示服务开始的时间。Service-Delivery-End-Time-StampC来自ACRStop中的Time-Stamps的子SIP-Request-TimeStamp AVP。显示服务结束的时间，即网元收到SIP会话释放消息的时间。有ACRStop的情况下必选。用来表示服务结束的时间。Record-Opening-TimeM由CCF填写CCF创建话单的时间。即CCF收到ACRstart/ACRevent消息创建话单文件的时间。在收到ACREvent消息创建话单的情况下，该值与Record-Closure-Time相同。Record-Closure-TimeM由CCF填写CCF关闭话单的时间。即CCF收到ACRStop消息关闭话单文件的时间。在收到ACREvent消息创建话单的情况下，该值与Record-Opening-Time相同。Inter-Operator Identifiers1M来自Inter-Operator-Identifier AVP。用来显示呼叫发起方和呼叫目的方的归属网络标识。在SIP信令中，这些信息被记录在P-Charging-Vector消息头。Originating-IOI 2M来自Inter-Operator-Identifier AVP的子Originating-IOI AVP。本字段的含义为呼叫发起方的网络标识。在SIP信令中，该信息记录在P-Charging-Vector头的Orig-IOI头。Terminating-IOI 2M来自Inter-Operator-Identifier AVP的子Terminating-IOI AVP。本字段的含义为呼叫目的方的网络标识。在SIP信令中，该信息记录在P-Charging-Vector头的Term-IOI头。Local-Record-Sequence-NumberM由CCF填写。CCF为该计费网元（AS）相关的每个CDR分配一个唯一的数字，从1开始连续分配，保证在同一个CCF内的唯一性。即同一个CCF为它自身生成的CDR分配的Local-Record-Sequence-Number是唯一的。用来判断是否有CDR文件的丢失。Record-Sequence-NumberC由CCF填写。生成部分话单的情况下该字段必选。由于超时等原因导致生成部分话单的情况下，CCF需要针对同一个计费话单生成多个部分话单，则CCF为该会话中的每个部分话单分配Record-Sequence-Number，从1开始，依次1、2、3，并在话单中填充该字段。用来判断一次会话是否有部分话单丢失。Cause-For-Record-ClosingM由CCF填写。话单关闭的原因。用来描述本次会话结束的原因，例如收到ACREVENT或者ACRSTOP正常结束话单，或者超时未收到ACRInterim自动释放等。Incomplete-CDR-IndicationO由CCF填写。本字段是用来说明本CDR内容是否完整。如果本CDR缺少了部分ACR，则本字段的设置如下：aCRStartLost：缺少Start类型的计费消息，则本字段为TRUE，否则为FALSE。aCRInterimLost：含有Interim类型的计费消息，本字段为NO；缺少Interim类型的计费消息，本字段为YES；不知道是否缺少Interim类型的计费消息，本字段为UNKNOWN。aCRStopLost：缺少Stop类型的计费消息，本字值为TRUE，否则为FALSE。IMS-Charging-IdentifierM来自IMS-Charging-Identifier AVP。计费标识。IMS网元为SIP会话产生的计费标识，简称为ICID，该标识在一次端到端的会话中是唯一的。用来进行不同网元话单的关联。List-Of-SDP-Media-Components 1M来自SDP-Session-Description AVP、SDP-Type AVPTime-Stamps AVP、SDP-Media-Component AVP、Media-Initiator-Flag AVP用来描述本次会话中所用到的媒体类型，包括会话建立时协商的媒体类型和会话过程中重协商的媒体类型。因为在一次会话中可能会有多次媒体的切换和重协商，所以在一次会话中该字段可能出现多次。是一个Group类型的字段，包含以下字段：SDP-Session-Description SDP-TypeSIP-Request-Time-StampSIP-Response-Time-Stamp SDP-Media-Components Media-Initiator-Flag SDP-Session-Description 2O来自SDP-Session-Description AVP。用来描述一个会话中SDP的数据信息，即SDP数据中attribute-line(i=，c=,b=,k=,a=,etc.)的内容。SDP-Type2M来自SDP-Type AVP用来描述一个会话中的SDP数据是SDP请求还是SDP应答。SIP-Request-Time-Stamp 2M来自ACRstart或者ACRInterim的Time-Stamps 的子SIP- Request -Timestamp AVP。用来表示媒体切换的请求时间。即SIP 请求（通常是reInvite）的请求时间。SIP-Response-Time-Stamp 2M来自ACRstartACRInterim的Time-Stamps 的子SIP-Response-Timestamp AVP。用来表示媒体切换的完成时间。即SIP请求的应答(通常是200OK)时间。SDP-Media-Components 2M来自SDP-Media-Component AVP。用来描述当前会话的媒体信息。是个group 类型的字段，由关联一个媒体信息的几个子字段组成。因为在一个会话中可能会同时有多种媒体，所以会有多个该字段。本字段结构如下：SDP-Media-NameSDP-Media-DescriptionsAccess Correlation IDSDP-Media-Name 3M来自SDP-Media-Name AVP。描述本次会话SDP的媒体名，即SDP数据中“m=”内容SDP-Media-Descriptions 3M来自SDP-Media-Description AVP。描述SDP-Media-Name对应的媒体属性，即SDP数据中 attribute-line(i=, c=, b=, k=, a=, etc.)的内容。Access-Correlation-ID3O来自GPRS-Charging-Id AVP。描述承载层GPRS计费标识（GCID）或者其它类型接入网计费标识。适用于PCC架构。Media-Initiator-Flag 2O来自Media-Initiator-Flag AVP。用来标识被叫用户发起了会话修改。GGSN-AddressO来自GGSN-Address AVP。本字段的含义是提供媒体承载支持的GGSN的地址类型和IP地址。IP地址的前两个字节的值：如果是1，则代表IPv4型地址。如果是2，则代表IPV6型地址。Service-Reason-Return-CodeM来自Cause-Code AVP。业务请求成功或者失败的原因码，即SIP消息中请求的成功或者失败响应状态码。List-Of-Message-Bodies 1O来自Message-Body AVP。SIP消息体中所携带的端到端的用户数据信息。由于SIP信令交互的过程中可能携带多个消息，所以这组字段会出现多次。该字段是一个group类型，结构如下：Content-TypeContent-Disposition Content-Length OriginatorContent-Type 2O来自Content-Type AVP。描述SIP消息体的MIME媒体类型，如application/zip, image/gif, audio/mpeg等。Content-Disposition 2O来自Content-Disposition AVP。描述SIP消息的内容处理方式。例如，如果内容处理头域值为“render”则表明，该消息应该显示否则提供给用户。取值有：session, render, inline, icon, alert, attachment, 等。Content-Length 2O来自Content-Length AVP。描述SIP消息所包含的消息体的大小，单位是Byte。Originator 2O来自Originator AVP。描述这段消息体的发起方。Access-Network-InformationM来自Access-Network-Information AVP。接入网信息，用来判定用户是否漫游。由用户接入侧SBC把SBC的地址信息和接入地的区号带入SBC所处理的请求或者响应SIP消息的P-Access-Network-Info字段中，并填入Access-Network-Information AVP。描述了接入网的详细信息，作为用户是否漫游的判断依据。如果用户接入地信息与用户归属地信息不一致，可以判定用户已经漫游到其他省市。Requ