 |
中标分类
行业分类
ICS分类
最新标准
|
登录注册 |
| 您的位置: 标准明细 |
GA/T 1364-2017 Police digital trunking communication system - Technical specifications for interconnection 1 Scope This standard specifies the interconnection interface protocol architecture, pSIP syntax, DNS extension provisions, RTP extension provisions and protocol process of police digital trunking (PDT) communication system. This standard is applicable to the design, manufacturing and engineering acceptance of police digital trunking (PDT) communication system. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. GA/T 1056-2013 Police digital trunking communication system - General technical specifications GA/T 1058-2013 Police digital trunking communication system - Technical specifications for call control layer of air interface GA/T 1059-2013 Police digital trunking communication system - Security technical specifications YD/T 1522.1-2006 Technical requirements for session initiation protocol - Part 1: Basic session initiation protocol YD/T 1936-2009 Technical Requirements for session description protocol RFC 1035 Domain names - Implementation and specification RFC 3550 RTP: A transport protocol for real-time applications RFC 3551 RTP profile for audio and video conferences with minimal control NMEA 0183 Protocol 3 Terms, definitions and abbreviations 3.1 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1.1 user agent logical functional entity supporting the SIP protocol, which acts as a UAC where a request is generated and as a UAS where a request is received and a response is generated 3.1.2 user agent client functional entity that sends a session request with client transaction status machine in the process of SIP session establishment 3.1.3 user agent server functional entity that receives, rejects or forwards the corresponding session request, and sends this response with the server transaction status machine in the process of SIP session establishment 3.1.4 transaction client and server event that shall range from the first request sent by the client to the server to the last (non-1xx) termination response sent by the server to the client 3.1.5 transaction user protocol layer on top of the SIP transaction layer 3.1.6 session point-to-point SIP connection between two UAs that lasts for a period of time and records the relevant content on the two UAs already connected 3.2 Abbreviations For the purposes of this document, the following abbreviations apply. BNF Backus-Naur Form DNS Domain Name Service ENUM Telephone Number Mapping GH_MSC Group Home Mobile Switching Center H_MSC Home Mobile Switching Center HSS Home Subscriber Sever IP Internet Protocol MFID Manufacturer's Specific FID MS Mobile Station MSC Mobile Switching Center O_MSC Original Mobile Switching Center P_MSC Participant Mobile Switching Center pSDP PDT Session Description Protocol pSIP PDT Session Initiation Protocol PDT Police Digital Trunking RTP Real-time Transport Protocol SDP Session Description Protocol SIP Session Initiation Protocol UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol URI Universal Resource Identifier V_MSC Visit Mobile Switching Center XML Extensible Markup Language 4 Overview 4.1 Interconnection function The interconnection between PDT systems is based on all-IP softswitch technology and shall meet the following requirements: ——The user mobility management between PDT systems includes functions of roaming registration/de-registration, cross-system authentication, stunning/reviving roaming users, killing roaming users and user group management; ——Call control functions between PDT systems include individual call, group call, PTT authorization, multi-site handover and speaker identification; ——Data services between PDT systems include cross-system short messages, status information and satellite positioning information; ——Support dynamic group number assignment (DGNA) function; ——The maximum transmission delay of the link between PDT systems is less than 100 ms, the transmission jitter is less than 25 ms, and the packet loss rate is less than 10-3, the bandwidth of each session is not less than 32 kbps; ——The cross-system group calling establishment time is not more than 500 ms. 4.2 Interconnection architecture The PDT communication system shall have the national networking capability, as well as the multi-level network management capability of ministries, provinces and cities. Therefore, the flat IP network is divided into virtual multi-level interconnection management system, as shown in GA/T 1056-2013. The interconnection between any two PDT systems in the flat IP network adopts a completely peer-to-peer system interconnection architecture, as shown in Figure 1. Keys: pSIP control signaling; RTP voice service. Figure 1 Completely peer-to-peer system interconnection architecture A pSIP protocol shall be used for interconnection control signaling between PDT systems, a RTP protocol for voice transmission between PDT systems, and a DNS protocol between PDT systems and domain name servers (DNS). A DNS is a database with distributed architecture, which completes number and domain name address parsing and mapping to IP addresses. The PDT system supports users to roam across the country. The home system shall decide whether the mobile station can roam to the remote system according to the user's roaming authority, and the system of visited area can decide the calling authority of roaming users according to the local roaming authority control policy. If ordinary roaming users roam in the visited area to access the network, the system of visited area only opens the lower call authority by default. If the system resources of visited area are busy, the local user may preempt the roaming user's call service channel. The system of visited area may also pre-configure the policy to reserve the calling authority of the home system for roaming users from some remote systems as appropriate, and the roaming users may enjoy the equivalent or higher calling authority as the local users. The roaming authority is configured by the local municipal network management system according to the work demands, and it is required to enable the roaming authority only for users who need to roam; if users without roaming authority need to roam across systems, they shall contact the home network management to activate roaming authority. The roaming authority control policy of the system of visited area is configured by the local network manager or the senior network manager. 4.3 Interconnection protocol The interconnection protocol between PDT systems is divided into control plane and user plane, and the hierarchical structure of the interconnection protocol is shown in Figure 2. Figure 2 Hierarchical structure of interconnection protocol The interconnection control plane interface between PDT systems uses the pSIP protocol for mobile management, call control and network maintenance, etc. The pSIP protocol also includes the pSDP protocol for media stream control, MAP protocol for user data definition and NMEA protocol for satellite positioning information. The basic syntax rules of pSIP shall meet the requirements of YD/T 1522.1-2006 and YD/T 1936-2009. The interconnection user plane interface between PDT systems uses the RTP protocol and it shall meet the following requirements: ——The format of the RTP header shall conform to RFC 3550, and the format of the media information carried by the RTP shall conform to RFC 3551; ——The RTP extension header can carry information such as LC, PI and EMS of wireless air interface voice; ——The PDT system shall be capable of transmitting air interface voice information with channel coding transparently. If the MSC needs to obtain the IP address of the H_MSC to which the MS belongs or the IP address of the GH_MSC to which the group user belongs, the relevant data may be obtained from the DNS server through the DNS query protocol. The layers of the pSIP protocol stack have the following meanings: ——Application layer: providing various application services between PDT systems; ——Session layer: completing various session service processes between PDT systems, such as call control and roaming registration; ——Transaction layer: divided into client transaction and server transaction. The client transaction is responsible for accepting the request from the upper entity and reliably sending the request to the server transaction; receiving responses and transmitting them to upper entities, while filtering duplicate responses and some illegal responses. The server transaction is responsible for receiving requests from the transport layer and sending them to upper entities, while filtering repeatedly received requests; receiving responses from upper entities and reliably sending responses to client transactions; ——pSIP signaling compression layer: completing the syntax parsing, signaling encoding and decoding, and signaling compression functions of pSIP protocol; ——Transport layer: UDP protocol is used for completing end-to-end data transport; ——Network layer: IP protocol is used for completing the routing from source address to destination address. 5 PDT session initiation protocol (pSIP) 5.1 pSIP protocol architecture The pSIP protocol stack is divided into application layer, session layer, transaction layer, compression layer, transport layer and network layer. The transport layer uses UDP protocol, and the port number is 5060 by default. Foreword i 1 Scope 2 Normative references 3 Terms, definitions and abbreviations 4 Overview 5 PDT session initiation protocol (pSIP) 6 Domain name service (DNS) extension provisions 7 Real-time Transport Protocol (RTP) extension provisions 8 Interconnection protocol processes Annex A (Normative) Description of domain name Annex B (Informative) Example of ENUM transformation relationship Annex C (Informative) Example of DNS lookup Annex D (Informative) Description of message sequence diagram ICS 33.060.01 A 90 GA 中华人民共和国公共安全行业标准 GA/T 1364—2017 警用数字集群(PDT)通信系统 互联技术规范 Police digital trunking communication system— Technical specifications for interconnection 2017-02-08发布 2017-02-08实施 中华人民共和国公安部 发布 前言 本标准是警用数字集群(PDT)通信系统技术规范系列标准之一。该系列标准文件已发布如下技术规范： ——GA/T 1056—2013《警用数字集群(PDT)通信系统 总体技术规范》； ——GA/T 1057—2013《警用数字集群(PDT)通信系统 空中接口物理层及数据链路层技术规范》； ——GA/T 1058—2013《警用数字集群(PDT)通信系统 空中接口呼叫控制层技术规范》； ——GA/T 1059—2013《警用数字集群(PDT)通信系统 安全技术规范》； ——GA/T 1255—2016《警用数字集群(PDT)通信系统 射频设备技术要求和测试方法》； ——GA/T 1365—2017《警用数字集群(PDT)通信系统 网管技术规范》； ——GA/T 1366—2017《警用数字集群(PDT)通信系统 移动台技术规范》； ——GA/T 1367—2017《警用数字集群(PDT)通信系统 功能测试方法》； ——GA/T 1368—2017《警用数字集群(PDT)通信系统 工程技术规范》。 本标准按照GB/T 1.1—2009给出的规则起草。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。 本标准由公安部科技信息化局提出。 本标准由公安部通信标准化技术委员会归口。 警用数字集群(PDT)通信系统 互联技术规范 1 范围 本标准规定了警用数字集群(PDT)通信系统互联接口协议架构、pSIP语法、DNS扩展规定、RTP扩展规定和协议流程。 本标准适用于警用数字集群(PDT)通信系统的设计、制造和工程验收。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。 GA/T 1056—2013 警用数字集群(PDT)通信系统 总体技术规范 GA/T 1058—2013 警用数字集群(PDT)通信系统 空中接口呼叫控制层技术规范 GA/T 1059—2013 警用数字集群(PDT)通信系统 安全技术规范 YD/T 1522.1—2006 会话初始协议(SIP)技术要求 第1部分：基本的会话初始协议 YD/T 1936—2009 会话描述协议(SDP)技术要求 RFC 1035 DNS-实现及标准 RFC 3550 实时应用程序传输协议 RFC 3551 最小控制的音频和视频会议RTP简介 NMEA 0183 协议 3 术语、定义和缩略语 3.1 术语和定义 下列术语和定义适用于本文件。 3.1.1 用户代理 user agent 支持SIP协议的逻辑功能实体，当产生请求时作为UAC，当接收请求并产生响应时作为UAS。 3.1.2 用户代理客户端 user agent client 在SIP会话建立过程中发送会话请求的功能实体，并且由客户端事务状态机发送这个请求。 3.1.3 用户代理服务器 user agent server 在SIP会话建立过程中接收、拒绝或者转发对应的会话请求的功能实体，并且由服务器端事务状态机发送这个响应。 3.1.4 事务 transaction 客户端和服务端的事件，应从第一个由客户端发送到服务端的请求，到最后一个(非1xx)服务端向客户端发出的终结应答。 3.1.5 事务用户 transaction user SIP事务层之上的协议层。 3.1.6 会话 session 在两个UA之间持续一段时间的点对点的SIP连接，并记录了两者已经连接上的相关内容。 3.2 缩略语 下列缩略语适用于本文件。 BNF Backus-Naur Form 巴科斯范式 DNS Domain Name Service 域名服务 ENUM Telephone Number Mapping 电话号码映射 GH_MSC Group Home Mobile Switching Center 组归属移动交换中心 H_MSC Home Mobile Switching Center 归属移动交换中心 HSS Home Subscriber Sever 归属用户服务器 IP Internet Protocol 互联网协议 MFID Manufacturer's Specific FID 厂家的功能识别码 MS Mobile Station 移动台 MSC Mobile Switching Center 移动交换中心 O_MSC Original Mobile Switching Center 源端移动交换中心 P_MSC Participant Mobile Switching Center 成员移动交换中心 pSDP PDT Session Description Protocol PDT会话描述协议 pSIP PDT Session Initiation Protocol PDT会话初始协议 PDT Police Digital Trunking 警用数字集群 RTP Real-time Transport Protocol 实时传输协议 SDP Session Description Protocol 会话描述协议 SIP Session Initiation Protocol 会话初始协议 UA User Agent 用户代理 UAC User Agent Client 用户代理客户 UAS User Agent Server 用户代理服务器 UDP User Datagram Protocol 用户数据报协议 URI Universal Resource Identifier 通用资源标识 V_MSC Visit Mobile Switching Center 拜访移动交换中心 XML Extensible Markup Language 可扩展标记语言 4 概述 4.1 互联功能 PDT系统间互联基于全IP软交换技术，应满足以下要求： ——PDT系统间的用户移动性管理包括漫游登记/去登记、跨系统鉴权、遥晕/复活漫游用户、遥毙漫游用户和用户组管理功能； ——PDT系统间的呼叫控制功能包括单呼、组呼、PTT授权、越区切换、讲话方身份识别等； ——PDT系统间的数据业务包括跨系统短消息、状态信息和卫星定位信息； ——支持跨系统动态重组功能； ——PDT系统间链路最大传输时延小于100ms，传输抖动小于25ms，丢包率小于10－3，每话路带宽不小于32kbps； ——跨系统组呼呼叫建立时间不大于500ms。 4.2 互联架构 警用数字集群通信系统应具备全国联网能力，以及部、省和地市多级网络管理能力，因此将扁平状的IP网分为虚拟的多级互联管理系统，具体见GA/T 1056—2013，在扁平化的IP网络内任何2个PDT系统之间的互联都采用完全对等的系统互联架构，见图1。 交换中心3 交换中心1 交换中心2 说明： pSIP控制信令； RTP语音业务。 图1 完全对等的系统互联架构 PDT系统间互联控制信令应使用pSIP协议，PDT系统间语音传输应使用RTP协议，PDT系统与域名服务器(DNS)间应使用DNS协议。DNS是一个分布式体系结构的数据库，完成号码和域名地址解析以及到IP地址的映射。 PDT系统支持用户全国漫游，归属地系统应根据用户的漫游权限决定移动台是否能够漫游到异地系统，拜访地系统可根据本地的漫游权限控制策略，决定漫游用户的呼叫权限。普通漫游用户在拜访地漫游入网时，拜访地系统默认仅开放较低的呼叫权限，当拜访地系统资源繁忙时，本地用户可抢占漫游用户的通话业务信道。拜访地系统也可预先配置策略酌情对来自某些异地系统的漫游用户保留其归属系统的呼叫权限，与本地用户享有同等或者更高级的呼叫权限。 漫游权限由归属地市级网管系统根据工作需要进行配置，要求仅给需要漫游的用户开启漫游权限；无漫游权限的用户如需要跨系统漫游，应与归属地网管联系开通漫游权限。拜访地系统的漫游权限控制策略由本地网管或者更高一级的网管进行配置。 4.3 互联协议 PDT系统间互联协议分为控制面和用户面，互联协议分层结构见图2。 应用层 会话层 事务层 pSIP压缩层 传输层 语音 网络层 控制面 用户面 图2 互联协议分层结构 PDT系统间互联控制面接口使用pSIP协议，用于移动管理、呼叫控制和网络维护等，pSIP协议还包括媒体流控制的pSDP协议、用户数据定义的MAP协议和卫星定位信息的NMEA协议。pSIP基本语法规则应符合YD/T 1522.1—2006和YD/T 1936—2009。 PDT系统间互联用户面接口使用RTP协议，满足以下要求： ——RTP头的格式应符合RFC 3550，RTP携带的媒体信息格式应符合RFC 3551； ——RTP扩展头可携带无线空口语音的LC、PI和EMS等信息； ——PDT系统应具备透传带信道编码的空口语音信息能力。 当MSC需要获取MS归属的H_MSC的IP地址或者组用户归属的GH_MSC的IP地址时，可通过DNS查询协议向DNS服务器获取相关数据。 pSIP协议栈各层含义如下： ——应用层：提供PDT系统间的各种应用业务； ——会话层：完成PDT系统间各种会话业务流程，例如呼叫控制，漫游登记等； ——事务层：分为客户端事务和服务器端事务。客户端事务负责从上层实体接受请求，并将请求可靠地发送到服务器端事务；负责接收响应并将响应传送给上层实体，同时过滤重复的响应和一些非法的响应。服务器端事务负责从传输层接收请求并发送给上层实体，同时过滤重复接收的请求；负责从上层实体接收响应，并将响应可靠地发送给客户端事务； ——pSIP信令压缩层：完成pSIP协议的语法解析、信令编解码和信令压缩功能； ——传输层：采用UDP协议，完成端到端数据传输； ——网络层：采用IP协议，完成源地址到目的地址的路由选择。 5 PDT会话初始协议(pSIP) 5.1 pSIP协议体系结构 pSIP协议栈分为应用层、会话层、事务层、压缩层、传输层和网络层。其中传输层采用UDP协议，端口号默认为5060。 pSIP协议基于客户端/服务器模式，包括用户代理UA和用户服务器US。UA又分为用户代理客户端UAC和用户代理服务器UAS。在PDT系统内UAC可以是主叫用户所在的接入网关、MSC或应用服务器等。UAS可以是被叫用户所在的MSC、接入网关或应用服务器等。US可以是提供域名解析功能、归属地解析功能或重定向服务的服务器。 pSIP协议是基于标准SIP协议改进和优化后的PDT系统间互联协议，支持组呼业务和多种集群调度业务，在传输链路质量保证情况下，跨系统组呼建立时间小于500ms。 5.2 pSIP事务层 事务层处理的事务可分为客户端事务和服务器端事务。pSIP事务层协议流程兼容标准SIP事务层，应符合YD/T 1522.1—2006。 5.3 定时器 pSIP协议栈定时器时长见表1。 表1 定时器时长 定时器 值 说明 T1 500ms(默认) 预估的重发时间 T2 4s(默认) 给非INVITE请求和INVITE应答的最大重传时间间隔 T4 5s(默认) 最大网络传送信息时间 Timer_A 最初为T1 INVITE请求重传间隔，仅UDP协议使用 Timer_B 64×T1 INVITE请求超时时间 Timer_D 大于32s(默认) 应答重发的等待时间 Timer_E 最初为T1 非INVITE请求重传间隔 Timer_F 64×T1 非INVITE请求事务超时时间 Timer_G 最初为T1 INVITE应答重传间隔 Timer_H 64×T1 等待ACK的时间 Timer_I T4 ACK重传的等待时间 Timer_J 64×T1 非INVITE请求重传的等待时间 Timer_K T4 应答重传的等待时间 5.4 pSIP的扩展BNF规定 5.4.1 特殊符号规定 [parm]表示parm可选。 (parm)表示parm优先。 {parm}表示parm可任意多次。 *n{parm}表示parm最多出现n次。 n*{parm}表示parm至少出现n次。 1*n{parm}表示parm至少出现1～n次。 n{parm}表示parm连续出现n次。 pSIP约定所有出现的字母大小写敏感。 5.4.2 保留字规定 DQUOTE＝％x22(双引号) 5.4.3 SIP-URI SIP-URI用于指示一个通信资源，包含了与该通信资源建立及维持会话所需要的信息。 注1：userinfo在PDT系统中不使用。 domainlabel的定义见附录A。 注2：maddr用于指定用户所要联系的服务器地址。 5.5 pSIP消息 5.5.1 pSIP消息基本格式 pSIP消息(pSIP-message)是从客户端到服务器端的请求，或者是从服务器端到客户端的应答，基本消息格式如下： Request-Line、Status-Line及每一个消息头域都应使用回车换行字符(CRLF)来表示行终结。无论pSIP消息是否携带消息体，pSIP消息中的CRLF都应存在。 5.5.2 pSIP Request 格式 5.5.2.1 pSIP Request通用格式 pSIP Request通用格式如下： pSIP请求消息至少包含6个头域：Via，From，To，Call-ID，CSeq，Max-Forwards。具体头域的定义见5.5.3。 5.5.2.2 pSIP Method格式 pSIP Method格式如下： 5.5.2.3 Request-URI格式 Request-URI格式如下： 注1：表示个人用户类型。 注2：表示组用户类型。 注3：表示越区切换的个人用户类型。 注4：表示越区切换的组用户类型。 注5：表示PSTN有线用户类型。 注6：表示被叫号码或越区切换号。 5.5.2.4 SIP-Version格式 SIP-Version格式如下： 注1：MFID为0表示pSIP协议，其他表示各厂家私有的扩展pSIP协议。 注2："SIP/0/1.0"表示pSIP协议1.0版本，"SIP/2.0"表示标准SIP协议。 注3：若无"SIP-Version"，默认为"SIP/0/1.0"。 5.5.3 pSIP message-header格式 5.5.3.1 pSIP message-header通用格式 pSIP message-header通用格式如下： pSIP message-header使用场合见表2。 表2 pSIPmessage-header使用场合 头域 使用场合 代理A B C I O R T H E P F Q M U N 注1：“使用场合”列表示可以使用该头域的请求和响应的类型： ——c表示从请求复制到响应； ——R表示该字段只能用于请求； ——r表示该字段只能用于响应； ——2**，4**表示该头域可以用于的响应代码； ——rc表示从请求复制到响应，但需修改内容； ——A表示该字段能用于请求和响应。 注2：“代理”列表示代理服务器可以在该头域上进行的操作： ——a表示如果没有该头域，代理服务器可以增加或连接该头域； ——m表示可以修改头域的原有值； ——d表示可以删除一个头域的值； ——r表示代理服务器可以读该头域，因此该头域一定不能加密。 注3：“A”列到“N”列指出了一个头域在某个方法中的存在情况： ——M表示必选； ——O表示可选； ——C表示条件选项； ——M*表示应该发送该头域，但UAC或UAS可以接收没有该头域的消息； ——*表示消息体不为空时，该头域应存在； ——表示不可以使用该字段。 5.5.3.2 Accept格式 Accept头域指明消息请求方(UAC)或者消息响应方(UAS)所支持的消息体类型。其格式如下： m-type和m-subtype的定义应符合5.5.3.7，"*"代表所有媒体类型，"*/*"表示对支持的媒体类型不做限制。如果没有Accept头域，UAS应当认为Accept头域缺省值是application/sdp。空的Accept头域意味着不接受任何格式。 5.5.3.3 Authorization格式 Authorization用于携带移动台的电子序列号、单向鉴权时的响应值、移动台反向鉴权时的响应值或者双向鉴权时的鉴权令牌、鉴权向量、MS身份认证码或同步随机数。其格式如下： 注1：表示移动台向系统报告电子序列号。 注2：移动台向系统进行鉴权响应。 注3：移动台向系统进行反向鉴权响应。 注4：遥晕、复活和遥毙时的令牌，令牌类型与Event头域的事件类型一致。 MutualAuthInfoValu表示双向鉴权时的一组鉴权向量，鉴权向量参数顺序为Rand、SEQL、TSAuthCode、TSConfCode、MSAuthCode、StunToken、ReviveToken、KillToken、DCK。具体含义应符合GA/T 1059—2013。 注5：双向鉴权时的MS身份认证码。 注6：双向鉴权时的同步随机数。 5.5.3.4 Call-ID 格式 Call-ID是在一系列消息中，区分一组消息的唯一标志。在一次对话中，每个UA的所有请求和应答的Call-ID应一致。具体格式如下： 5.5.3.5 Contact格式 Contact头域指定一个SIP-URI，同一对话中的后续请求可以用它来联系到当前的UA。在INVITE的请求消息中应有Contact头域，并且该头域只能含有一个SIP-URI。具体格式如下： Contact头域中的SIP-URI表示UA的联系地址。若c-p-expires参数值不填写则表示无生命周期限制；若该参数值为0表示去登记。 若REGISTER请求的Contact头域携带action参数且取值"va"，表示拜访地鉴权；若取值十进制整数1～10，表示归属地鉴权响应消息体中携带的鉴权向量的组数；若REGISTER请求的Contact头域不携带action参数，则表示归属地鉴权。 5.5.3.6 Content-Length 格式 Content-Length头域用十进制整数指示消息体的字节数。如果pSIP消息中Content-Type头域存在，则应携带此头域。具体格式如下： 5.5.3.7 Content-Type 格式 Content-Type头域指示了消息体的媒体类型。如果消息体不为空，则Content-Type头域应存在。具体格式如下： 注1：charset表示消息体的编码方式。 注2：属于application媒体类型。默认的编码方式为“ASCII”。 注3：文本消息，属于text媒体类型。默认的编码方式为“UTF-8”。 注4：卫星定位数据内容，属于application媒体类型，BNMEA表示二进制NMEA格式，SNMEA表示文本NMEA格式，默认的编码方式为“ASCII”。 注5：状态数据，属于application媒体类型，内容为十进制整数，默认的编码方式为“ASCII”。 注6：二进制格式，属于application媒体类型。 注7：承载MAP协议，使用XML语言，属于application媒体类型，默认的编码方式为“UTF-8”。 5.5.3.8 Call-Info格式 Call-Info头域用于在请求消息头中携带本次请求的特征参数。具体格式如下： 注：表示会话属性为广播模式。无该字段默认非广播模式。仅INVITEm方法内有效。 5.5.3.9 Call-Attribute 格式 Call-Attribute头域与Call-Info头域用途一致，用于在请求消息头中携带本次请求的特征参数。具体格式如下： 注：表示会话属性为广播模式。无该字段默认非广播模式。仅INVITEm方法内有效。 5.5.3.10 CSeq格式 CSeq头域包含一个序列号和一个请求方法，请求方法应与对应的请求消息类型一致。该头域用于把某对话中的事务进行排序且提供了一种唯一标识某事务的方法，能够区分某请求是新的请求还是重发的请求。具体格式如下： 请求消息可以省略Method，但响应消息不能省略。通常情况下，对于每一个新的请求(ACK和CANCEL除外)，CSeq头域的数字部分都会递增，当达到最大值999后，再从0开始递增。 5.5.3.11 Event格式 Event头域用来标识事件类型，具体格式如下： 注1：表示呈现业务。 注2：表示遥晕业务。 注3：表示遥毙业务。 注4：表示复活业务。 注5：表示监听业务。 注6：表示获取会话ID。 注7：表示获取卫星定位数据。 注8：表示获取基站业务信道号。 注9：表示获取越区切换号。 注10：表示心跳维持业务(仅适用于OPTIONS方法)。 注11：delete-subscriber表示删除移动台的数据，update-group表示更新组成员数据，regroup-subscriberadd表示添加动态重组组成员数据，regroup-subscriber-del表示删除动态重组组成员数据，attachment_group表示组附着。 注12：表示序列号同步。 注13：表示系统主动鉴权。 5.5.3.12 Expires格式 Expires消息头给出消息有效期的相对时间，计时从收到请求消息的那一刻开始。该头域取值0s～225s，其含义因请求方法不同而不同。具体格式如下： 5.5.3.13 From格式 From头域用于指示请求发起方的逻辑标识，具体格式如下： 注1：表示该域名的设备携带保密设备，在REGISTERm请求中有效。 注2：表示from指向的用户当前会话识别号，用于越区切换，在PREPAREm请求中有效。 5.5.3.14 Handover-Number 格式 Handover-Number头域用于携带越区切换过程中的漫游切换号，具体格式如下： 注：在PREPARE和RESTORE方法中使用。 5.5.3.15 Max-Forwards 格式 Max-Forwards头域用来限制一个pSIP请求消息允许经过的实体的最大数目。每个实体在向前转发请求消息时，会将Max-Forwards头域值递减1。如果一个实体收到一个Max-Forwards头域值为0的请求消息，则丢弃该请求消息，并向UAC回送483(跳转次数太多)响应。所有的pSIP请求消息都应有Max-Forwards头域，这个头域的缺省值为70，具体格式如下： 5.5.3.16 Min-Expires 格式 Min-Expires头域用来指示服务器更新消息的最短时间间隔，取值为1s～214s，以及gps上报的距离间隔，取值1m～9999m，具体格式如下： 注：若distance-meters参数不填写，默认按照时间更新消息。 5.5.3.17 P-Access-Network-Info格式 P-Access-Network Info头域用来指示接入网的信息，具体格式如下： 注：若access-type不填写则默认为pdt-access。BSIDParm表示基站识别号或LAI。CChannelParm 表示控制信道号。TChannelParm表示业务信道号。SlotNo表示信道的时隙号，若填写则取值为1或2；若不填写则表示使用全部2个时隙。Align表示信道的时基模式，0表示对齐模式，1表示偏移模式，若不填写则表示对齐模式。 5.5.3.18 P-Asserted-Temporary-Identity格式 分配给越区移动台的临时组ID，例如会话恢复申请或组呼并入等。具体格式如下： 5.5.3.19 Priority格式 Priority头域用于UAC设置发送的请求消息的紧急程度。若alphanum为“u”表示紧急，若alpha-num为数字则表示优先级的大小，数值越大，表示相对优先级越高，取值范围为0～3。请求中若无该头域则优先级数值默认为0。具体格式如下： 5.5.3.20 Route格式 Route头域用来指示一个请求应经过的代理服务器列表，具体格式如下： 5.5.3.21 Service- Route格式 Service-Route用来指示响应方下一次发送请求的目的地址，具体格式如下： 5.5.3.22 Subscription-State格式 Subscription-State头域用来指示订阅响应消息中的用户当前订阅状态，具体格式如下： 注1：表示用户订阅的相关业务已被接受并进行了激活。 注2：表示用户订阅的相关业务暂时处于挂起状态。 注3：表示用户订阅的相关业务已终止。 5.5.3.23 To格式 To头域用来指示请求的接收方信息，具体格式如下： 注1：“-”表示To头域的URI和Request-URI相同。“＋”表示To头域的URI和from头域的URI相同。 注2：表示在组漫游切换发送INVITE时的被叫真实组ID。 注3：表示组呼越区切换时会话恢复用户的域名。 注4：在PTT抢话失败响应消息中，表示当前讲话者信息；在INVITE请求消息中，表示组呼并入的并入方ID。 5.5.3.24 User-Agent格式 User-Agent头域用来承载各厂家的自定义信息，具体格式如下： 注：privtate-info为厂家自定义信息。 5.5.3.25 Via格式 Via头域用来指示请求当前经历的路径，以及响应应当经过的路径，具体格式如下： 注：无transportName表示默认为UDP。 5.5.3.26 WWW-Authenticate格式 WWW-Authenticate头域用于鉴权挑战和索取电子序列号。在系统对移动台鉴权时，携带挑战随机数；在移动台反向鉴权时，携带系统的鉴权挑战随机数；在双向鉴权时，携带鉴权向量和同步令牌。具体格式如下： 注1：若ESN取值为“t”，则表示系统向移动台索取电子序列号；若ESN取值为“c”，则表示电子序列号作为鉴权参数使用；其余则表示系统提供给拜访地的移动台电子序列号。 注2：系统对移动台鉴权时挑战的随机数。 注3：移动台反向鉴权时挑战的随机数系统的响应值。 SyncInfoValue表示双向鉴权时的序列号同步令牌，令牌参数顺序为SEQ和SyncToken。具体含义符合GA/T 1059—2013。 5.5.4 pSIP响应消息格式 pSIP响应消息格式如下： 注：无SIP-Version默认为SIP/0/1.0。 pSIP响应消息至少包含5个头域：Via、From、To、Call-ID和CSeq。 Status-Code的含义见YD/T 1522.1—2006。 5.5.5 pSIP消息体通用格式 pSIP消息体通用格式如下： 5.6 pSDP协议 5.6.1 pSDP语法 pSDP通用格式如下： 5.6.2 pSDP 格式 一个pSDP会话描述由多条 pSDP中每项的先后顺序应符合announcement中的约定。 INVITE请求和200响应消息仅携带origin-field和media-descriptions。UPDATE请求和200响应消息仅携带session-attrs。 5.6.3 proto-version 格式 proto-version用来表示pSDP的版本信息，具体格式如下： “PO”表示pSDP的初始版本号，若不填写proto-version，则默认为“PO”。 5.6.4 origin-field格式 origin-field用来表示会话发起方的信息，具体格式如下： IPv4address表示IPv4类型地址。 5.6.5 session-attrs格式 session-attrs用来表示会话级属性，具体格式如下： sattrP用来描述本会话的属性，语法应符合5.6.6.4。 注：priority 表示会话的优先级，取值为整数0～3，数值越大，优先级越高。若session-attrs省略，则表示会话优先级为1。 5.6.6 media-descriptions格式 5.6.6.1 media-descriptions通用格式 media-descriptions为pSDP的媒体描述域，具体格式如下： 5.6.6.2 media-fields格式 media-fields用来描述对会话中的媒体相关信息，具体格式如下： 注1：port表示接收和发送媒体的端口号，使用RTP/AVP传输时端口号应为偶数。 注2：proto表示媒体传输的协议类型。若不填写proto，则默认“RTP/AVP”。 fmt表示媒体编码类型，具体取值见表10。 5.6.6.3 bandwidth-fields格式 bandwidth-fields用来描述会话中的媒体带宽，为可选项，具体格式如下： 注：bwtype表示媒体带宽类型，当bwtype为“MB”时，表示模式带宽。 bandwidth表示媒体带宽大小，当bwtype为“MB”时，bandwith定义应符合表3。
|
联系我们
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
微信联系客服
|
| 关于我们 | 联系我们 | 收费付款 |
| 服务热线：400-001-5431 | 电话：010-8572 5110 | 传真：010-8581 9515 | Email: bz@bzfyw.com | |
版权所有： 北京悦尔信息技术有限公司 2008-2020 京ICP备17065875号-1
51La
|
| 本页关键词： |
| GA/T 1364-2017, GA 1364-2017, GAT 1364-2017, GA/T1364-2017, GA/T 1364, GA/T1364, GA1364-2017, GA 1364, GA1364, GAT1364-2017, GAT 1364, GAT1364 |