【通信行业标准(YD)】 会话初始协议(SIP)技术要求 第1部分:基本的会话初始协议

中华人民共和国通信行业标准
YD/T1522.1-2006
会话初始协议（SIP）技术要求
第1部分：基本的会话初始协议
Technical Requirments for Session Initiation ProtocolPart 1:Basic Session Jnitiation Protoco(IETF RFC 3261,2002,SIP:Session Initiation Protocol,NEQ)2006-12-11发布
2007-01-01实施
中华人民共和国信息产业部发布前言·
1范围·
2规范性引用文件
3术语、定义和缩略语
4SP 协议结构
5SP 消息·
用户代理（UA）的基本行为
请求的取消
能力查询·
对话（Dialog）。
会话发起过程
会话更改过程·
会话结束过程·
代理服务器的行为
SIP 事务层·
普通的消息组成·
头字段
应代码·
SIP 协议的鉴整权机制·
21安全/多用途因特网邮件扩展（S/MIME）（可选）22SIP协议的扩展 BNF语法·
附录A（资料性附录）安全：威胁模式和安全建议：附录 B（资料性附录）IANA 定义附录C（规范性附录）SIP协议中临时响应的可靠性附录D（规范性附录）SP的定位过程录
附录B（规范性附录）SDP的提供/应答（Offer/Answer）模式附录F（规范性附录）特定事件的通知·附录 G（规范性附录）SIP INFO方法附录H（规范性附录）即时消息
附录I（规范性附录）UPDATE消息附录J(规范性附录】REFER 方法YD/T 1522.1-2006
YD/T 1522.1-2006
《会话初始协议（SIP）技术要求》预计分为5个部分：第1部分：基本的会话初始协议：-第2部分：基于会话初始协议（SP）的呼叫控制的应用：一第3部分：ISDN用户部分（ISUP）和会话初始协议（SIP）的互通：一第4部分：软交换网络中基于呼叫控制的会话始协议（SIP）技术要求；一第5部分：支持移动应用部分。本部分为《会话初始协议（SP）技术要求》的第1部分。本部分对应于IETFRFC3261（2002）《SIP：会话初始协议》，与RFC3261（2002）的一致性程度为非等效。
本部分是会话初始协议（SIP）系列标推之一。该系列标准的预计结构为：1.《会话初始协议（SIP）技术要求》—一第1部分：基本的会话初始协议：第2部分：基于会话初始协议（SP）的呼叫控制的应用；一第3部分：ISDN用户部分（ISUP）和会话初始协议（SIP）的互通：第4部分：软交换网络中基于呼叫控制的会话初始协议（SIP）技术要求；第5部分：支持移动应用部分。
2.《会话初始协议（SIP）测试方法》第1部分：基本的会话初始协议：一第2部分：基于会话初始协议（SIP）的基本呼叫控制。3.《会话初始协议（SIP）服务器设备技术要求》。4.会话初始协议（SIP）服务器设备测试方法》《会话初始协议（SIP）技术要求第1部分：基本的会话初始协议》将与《会话初始协议（SIP）测试方法第1部分：基本的会话初始协议》配套使用。随着技术的发展，还将制定后续的相关标准。本部分的附录A、B、K是资料性附录，附录C、D、E、F，G、H、I、J是规范性附录。本部分由中国通信标准化协会提出并归口。本部分起草单位：信息产业部电信研究院华为技术有限公司
中兴通讯有限公司
北京西门子通信网络股份有限公司本部分主要起草人：蒋晓琳魏亮　李建芳段世慧林美玉张大坤等1
1范围
会话初始协议（SIP】技术要求
第1部分：基本的会话初始协议
YD/T 1522:1-2006
本部分规定了会话初始协议的技术要求，包括SP消息、用户代理基本行为、请求取消、查询能力、对话、会话发起过程、会话更改过程、代理服务器行为、SP事务层，传输、普通消息成分，头字段、、应代码、HTTP鉴权使用、S/MTME、SIP协议的扩展BNF、安全、IANA考虑等技术要求。本部分适用于支持SP协议的终端设备或网络。2规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款，凡是注日期的引用文性，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然面，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。RFC1750 (1994 )
RFC1847 (1995)
RFC2234 (1997 )
RFC2279 ( 2000)
RFC2327 (1998 )
RFC2369 (1998 )
RFC2543 (1999 )
RFC2612 (1999 )
RFC2616 (1999)
RFC2617 (1999)
RFC2630 (1999)
RFC2633 (1999 )
RFC2782 (2000)
RFC2806 (2000 )
RFC2809 (2000 )
RFC2822 (2001 )
RFC2976 (2000)
RFC3108 (2001)
RFC3261 (2002)
RFC3262 (2002 )
RFC3263 (2002 )
RFC3311 (2002)
安全随机建议
MIM多部分安全格式：签名和加密扩展的BNF语法：ABNF
SIP INFO 方法
会话描述协议
通用资源定位符（URI）通用语法SIP协议
CAST-256 加密算法
超文本传输协设一—HTTP/1,1
HTTP鉴权：基本鉴权和分类接入鉴权加密消息语法
SAMIME版本3消息规范
DNS指定服务位置（DNS SRV）
电话呼叫URL
通过RADIUS实现L2TP强制隧道
Internet消息格式
SIP INFO 消息www.bzxz.net
在ATM承载连接上使用SDP的规程SIP：会话初始协议
SIP协议临时应答的可靠性
会话初始协议：定位服务器
UPDATE方法
YD/T 1522.1-2006
RFC3428 (2002)
RFC3515 (2003 )
3术语、定义和缩略语
3.1术语和定义
即时消息
REFER方法
下列术语和定义适用于本部分，3.1.1UA [ User Agant ]
用户代理（UA）是一个逻辑功能实体，当产生请求时作为UAC，接收请求并产生响应时作为UAS。3.12 UAC ( User Agent Client 1用户代理客户端（UAC）是一个逻辑功能实体，它产生一个新的请求消息后使用客户事务状态机将该请求发送出去。当终端产生一个请求时，在该请求事务中，它作为UAC。当终端接收到一个请求时，它作为UAS处理该请求并产生响应。3.1.3UAS [ User Agent Server ]用户代理服务器（UAS）是一个逻辑功能实体，它对SIP请求消息进行处理并产生响应。该响应接受、拒绝或者重定向S请求消息。当终端对于接收到的请求消息作出响应时，在该请求事务中，它作为UAS。当终端产生请求时，在该请求事务中，它作为UAC。3.1.4B2BUA ( Back-to-Back User Agent )背靠背用户代理（B2BUA）是一个逻辑功骼实体，它作为UAS接收请求消息并处理该消息。同时，为了判决该请求消息如何应答，它也作为UAC来发送请求消息。和代理服务器不同的是，B2BUA需要维护一个它所创建的对话状态。
3.1.5重定向服务器
重定向服务器用响应消息将某一请求的路由信息返回给客户端，从而起到了帮助选路的功能。当请求的发起者收到重定向响应后，它将基于收到的URI发送新的请求。重定向服务器逻辑上由一个服务器端事务层和一个能够访间某种定位服务的事务用户组成。3.1.6注册服务器
注册服务器会为特定的区域创建绑定信息，即将一个地址记录URI与-一个或多个地址相关联。3.1.7代理服务部
为客户机做代理，进行SIP消息的转接和转发。消息机制与UAC和UAS相似。并对收到的请求消息进行翻译和处理后，传递给其他的服务器，同时对SIP请求及响应进行路由。3.1.8对话
对话是两个UA之间持续一段时间的点对点的SIP连接，它便UA之间的消息变得有序，同时给出请求消息的正确的路由。
3.1.9会话
会话是信参与方及它们之间的媒体流的集合。3.1.10内核（Core
内核指定了某个特定的SIP实体的功能集合。该SIP实体包括有状态代理、无状态代理，UA、注册服务器。除了无状态代理之外，所有的内核都是事务用户。2
3.2缩略语
下列缩略语适用于本部分。
SIMIME
4SIP协结构
Domain Narne Service
Denial of Service
Hyper Text Transport ProtocolInternet Control Message ProtocolInternet Protocol
Internet Assigned Numbers AuthorityInternet Engineering Task ForceMaximal Trarismission Unit
Public Switched Telephone NetworkReal-Time Transport Protocol -Real-Time Transpart Control ProtocolStrearn Control Transmission ProtocolSession Description ProtocolSession Initiation Protocot
Security of Systems and NetworksSecure / Muitipurpose Internet Mail ExtensionsTransimission Control ProtocolTransport Layer Security
User Agent
User Agent Client
User Agent Server
User Datagram Protocol
Universal Resource Identifier域名服务
YD/T 1522.1-2006
拒绝服务攻击
超文本传输协议
互联网控制协议
互联网协议
互联网号码分配委员会
互联网工程任务组
最大传输单元
公共交换电话网
实时传输协议
实时传输控制协议
流控传输协设
会话描述协议
会话初始协议
安全服务网络
安全多用途互联网邮件扩展
传输控制协议
传输层安全
用户代理
用户代理客户
用户代理服务器
用户数据报协议
通用资源标识
SIP是一个分层结构的协议，即它的行为根据一组平等独立的处理阶段来描述，每一阶段之间只是松耦合。协议分层描述是为了表达，从而允许功能的描述可在个部分跨越儿个实体。S亚协议不指定任何方式的实现。当我们说某实体包含革层，我们是指它顺从该层定义的规集。SIP协议框架的最底层是它的语法和缩码层。SIP协议的编码以BNF语法来定义。SIP协议框架的第二层是传输层。一个客户端事务通过传输层向服务器端事务发送一个请求，服务器端事务对该请求做出响应并发送给客户端，这样就构成了。一个事务。事务层负责处理应用展的重传，响应匹配和超时。UAC的任何任务都是通过一系列的事务而完成的，UA作为有状态的代理服务器的时候包括事务层；无状态的代理服务器不包括事务层。事务层包括客户端部分和服务器端部分，并都以有限状态机表示。
SIP协议框架的第三层为事务用户层（TU）。每个STP实体都是一个事务用户。当TU要发送-个请求消息时，它首先创建一个客户端事务实例并将请求消息和目的P地址、端口号发送给它。创建客户端事务的TU也可以将该事务取消。当一个客户端事务被取消时，它要求服务器端终止对该事务的处理并回3
YD/T 1522.1-2006
到初始状态，然后产生对该事务产生一个特定的错误鸣应。SIP实体，即用户代理客户端和服务器端、有状态及无状态的代理服务器和注册服务器，都包括一个内核相互区别，除了无状态的代理服务器，其他实体的内核都是事务用户。UAC和UAS的内核的行为都决定于方法（method），对于所有的方法都有一个总的规则。对于UAC，这些规则决定了请求消息的构成；对于UAS，这些规则决定了请求的处理和响应的产生。由于注珊在SIP协议中的重要地位，处理REGISTER消息的UAS在本协议中就称为注册服务器。SIP协议中，某些请求在对话中发送。本部分定义INVITE方法是惟一的可以创建对话的方法。SEP协议中最重要方法就是INVITE方法，它可以用来建立在双方间创建一个会话。5SIP消息
SIP 协议是采用 UTF-8 字符集来进行编码的文本协议。SP协议消息分请求和响应两类，其中请求消息由客户机发往服务器，响应消息由服务器发往客户机。除选用的字符集以及语法定义外，请求和响应消息均采用RFC2822定义的基本格式进行编码。请求和哦应消意格式由一个起始行、若干个头字段，以及一个可选的消息体组成。其中消息体为可选项，头字段与消息体之闻用空行进行分隔。请求和响应消息格式如下；SIP消息=起始行
*消息头部（1个或多个头部）
CRLF（回车换行符）
[消息体]
起始行=请求行状态行
如上消息格式定义，“*表示该消息头部可包含一个或多个，”表示该参数为可选项。本标推规定起始行，每一个消息头部以及空行都必须使用回车换行字符（CRLF）来表示行终结，即使消息中未包含消息体可选项空行也不能省略。除了以上字符集不同之外，SIP 消息和头字段语法定义与 HTTP 1.,1 的语法定义一致。HTTP/1.1 的语法定义见RFC2612。消息语法定义与HTTP类似，SIP协议并不是HTTP的扩展协议。在SIP应用中使用的所有方法名学、头段头学段名字、状态编码和选项标记都必须向IANA注册。具体的IANA定义参见附录B。
5.1请求 ( Request )
请求消息的起始行为请求行（Request-Line）。体求行的格式由方法名、请求URL和协议版本组成，各部分之间均用一个空格字符进行分陷。除此之外，请求行必须用回车换行（CRLF）字符表示行终结。Request-Line = Method[ I Request-URI SIP-Version CRL F1）方法（Method)：本部分正文共定义了 6 个方法，INVITE、ACK、CANCEL、OPTIONS、BYE和REGISTER。REGISTER消息用于发送注册请求信息：INVITE、ACK、CANCEL用于建立会话连接；BYE用于终结会话连接；OPTIONS用于查询服务器能力。本协议规定方法名必须使用大写宇母。除以上6类主要消息外，SP协议在其他文档中还规定有若下方法实现协议扩展。本部分在附录F，G，H.I，J中定义了其他几个重要的扩展方法，如NOTIFYISUBSCRIBE，INFO，REFER等，具体内容见相关附录。2）请求URI（Request-URI）：指示被邀请用户的当前地址。本协议规定Request-URL中不充许出现空格或其他控制字符且不能包含在“”符号之内心4
YD/T 1522.1-2006
除使用\sip\和\sips\URI之外，还可以使用telURI定义机制，有关\tel\的URI定义机制见RFC2806，SIP实体可将非SIPURI翻译成SIPURI、SIPSURI或其他URI定义，3）版本号（SIP-Versio）：用于定义协议的当前版本号。本协议的版本号为SIP/2.0。5.2期应【Response】
喇应消息的起始行为状态行（Status-Line），状态行由协议版本、状态码和与状态码相关的文本描述组成，各个部分之间用一个空格字符进行分隔。状态行的格式如下所示：Status-Line=SIP-Version [ jStatus-Code I ] Reason-Phrase CRLF除状态行的尾部可使用回车换行CRLF学符之外，状态行内不充许出现CRLF字符。1）Status-Code（状态码）：该参数为一个3位的十进制整数，用于指示请求消息的执行响应结果。2）Reason-Pirase（原因）：该参数用于对Status-Code参数进行简单的文本描述。客户机不必检查或显示Reason-Phrase参数。尽管本标准建议使用特定字符表示Reason-Phrase，具体实现过程中Reason-Phrase仍可使用其他的文本字符。
本协议共定义6类状态码，其中状态码的第1位数字用于指示响应类型，后2位数字表示具体响应。本协议规定状态码为“100-199”之间的响应用“1XX”进行标识，“200~299”之间的啦应用“2XX\进行标识，依此类推。
1）1XX：临时响应，表示请求消息正在被处理。2）2XX：成功响应，表示请求已被成功接收，完全理解并被接收。3）3XX：重定向响应，表示需采取进一步以完成该请求。4）4XX：客户机错误，表示请求消息中包含语法错误信息或服务器无法完成客户机请求。5）5XX：服务器错误，表示服务器无法完成合法请求。6）6XX：全局故障，表示任何服务器无法完成该请求。5.3头字段
SIP头字段的语法和语义定义与HTIP头字段定义基本相同。HTTP中定义多行扩展可使用障含的空格和折叠字符（folding），而本标准定义的多行扩履规则只能使用显式空格和折叠字符（folding），且空格和折叠字符（folding）作为消息的组成部分。同样，HTTP中也定义了将具有多个参数值的同一字段扩展为具有相同字段名称的多个字段行的规则。该规则同样适用于本协议，但具体应用时规则会有所不同。S协议定义的头字段语法规则如下：header\header-name\HCOLON header-value*(COMMAheader-value)如上所示，S卫P头字段允许一个头字段可以定义多个参数值，且多个参数值之间用“，”字符进行分。当属性值不为“*”时，Contact头字段允许属性值之间用“，”字符进行分隔。5.3.1头字段格式
SIP消息的头字段格式避循RFC2822所定义的通用头字段格式定义规则。头字段格式如下所示，头字段名和字段值之间用字符“：”进行分隔。field-name：field-value
消息头字段中允许出现多个空格字符。但是在具体实现过中，本标准建议字段头部右侧，即字段名和“：”字符之间应避免出现空格字符，而字段头部左侧，即字段值和“；”之间用一个空格字符进行分隔，如下所示：
YD/T 1522.1-2(06
fieid-name; field-value
头字段部分可以通过增加多个空白字符或者TAB字符而扩展成多行，本标准规定扩展行首位的多个空白宇符以及分行字符都应作为个空白字符对待。消息头字段内不同头学段名的顺序可任意排列，但是本标准建议与代理服务器处理相关的字段名（如Via、Route、Record-Route、Proxy-Require、Max-Forwards、Proxy-Authorization等）等，应尽可能排在消息头字段的前几位以加快代理服务器对消息的处理速度。相同头字段名的择列顺序也非常重要，本标准规定，当且仅当字段值为多个字段值列表且字段值列表遵循多个字段值之间用“”分割的规则，购一个消息内允许同时存在多个相同的字段名行。同理，多个相同字段名的字段行可以组成一个单一的字段行，其字段值为一个用“，”字符分隔的值列表。WWW-Authenticate、Authorization、Proxy-Authenticate 和 Proxy-Authorization 学段不遵循以上规则。由于以上字段值不允许出现列表值，因此当消息中出现多个以上字段行时，多个字段行不能组成一个字段行。具体实现过程中，消息接收实体应按照同样的规则处理字段名相同的多个字段行或一个包含字段列表的组合字段行。
本标准中，头字段值由头字段名进行标识。通常头字段名由UTF8字符集所包含的文本字符组戚。除此之外，头字段还允许包含空格、破折号、分摇符和引号字符。多数头字段名和头字段属性值之间用“：”进行分隔，且头字段中还可包含参数名和参数值，格式如下所示：field-name：field-value*（sparameter-name-parameter-value）本标准对头字段中所包含的参数名数目不作限制，但规定在一个头字段内，同一参数名能且仅能出现一次。
本协议规定，头字段名对大小写字符不敏感，即相同字段名不区分大小写字符。如未特别指出，头字段中所包含的宇段参数值，参数名和参数值也对大小写字符不敏感，除此之外，头字段名中所包含的破折号“一”字符对大小写字符不敏感，但是引号字符内的字符内容对大小写字符敏感。5.3.2头字段分类
SIP消息某些头字段仅当存在于请求或响应中的时候才有意义。只能存在于请求消息中的字段称为请求头字段，只能存在于应消息中的字段称为响应头字段。当消息头字段出现了不匹配的字段类型时，则消息接收实体应忽略该字段。5.3.3 压缩格式
本协议提供了一种压缩机制用于将头字段名相间的字段进行压缩传送，这种压缩机制可以避免消息传输过程中产生大量消息拆分。采用压缩并不会导致消息语义的改变。本协议规定同一头字段名可出现在压缩头部或非压缩头部中，在具体实现过程中，消息接收实体应能识别并正确处理这两种不同格式的消息。
5.4消息体
本协议规定SP请求消息可包含消息体部分，消息体部分的解释应与消息请求方法相-致。对于SIF响应消息，请求方法和响应状态码可以识别消息体的类型。本协议规定所有SP响应消息应包含一个消息体部分。
5.4.1．消息体类型
消息体的类型必须由“Content-Type”字段进行定义，且如果消息体采用了压缩编码方式，则相应地应在“content-Encoding”学段中定义其所采用的压缩编码算法。否则，如果消息体未采用了压缩编码方6
YD/T1522.1-2006
式，则\Content-Ecoding”字段的内容应被忽略。在其体应用过程中，消息接收实体应将消息体的内容作为“Content-Type”头字段值来对待。本协议规定消息体可以承载使用\multipart”MLME方式进行编码的信息单元。具体实现中，当请求发送方需要发送消息体部分包含MIME信息单元的请求消息时，且消息接收方在“Accept头字段指示其不能接受MIME消息体，则消息请求发送方应在消息中附加一个SDP部分作为非MIME消息体进行发送。SIP消息可以包含二进制编码的消息体。如果未明确指出，本标准中缺省的消息文本编码类型是UTF-8
5.4.2消息体长度
消息体的长度由\Content-Length\头字段进行定义，单位为学节。有关“Content-Length”头字段见本部分第 18 章。
本协议规定 SIP 消息体不能采用 HTTP1.1 中所定义的分块(chunked）传送编码机制。在分块传送编码机制中，每一块消息体的长度由相应的标识符进行标识5.5SIP消息顿
SIP协议可以使用UDP或者其他不可靠的报文协议进行承载传送，且每一个报文携带个请求或响应消息。
具体实现时，如果SIP消息采用面向流的方式进行传送，则SIP消息起始行前的任何CRLF字符应忽露。
“Content-Length”头字段值用于定义一个SIP消息在流中的结束位置。当SIP消息采用面向流的方式进行传送时，该头字段不能被省略。6 用户代理 ( UA 的基本行为
当UAC发出请求，请求消息会通过一些代理服务器被转发到UAS。而UAS产生一个响应后，响应消息会以同样的方式被转发到UAC。UAC和UAS的处理过程与两个因紊有关，即被处理的请求或响应消息是否属于某个对话（dialog）以及请求的方法。对话是一种UA之间的端到端对等关系，它由特定的SIP消息，如INVITE消息建立。关于对话定义见本标推第0章。
对话之外的请求或响应消息的安全性处理参见本部分附录A。另外，UAC和UAS之间存在着相互鉴权机制，消息体可以通过S/MIME进行如密。6.1UAC 基本行为
本节讨论对话之外的UAC行为。
6.1.1请求消息的产生
本标准规定，由UAC产生的一个有效的SIP请求消息必须至少包含下列头字段：To、From、CSeqCal1-ID、Max-Fcrwards和Via头字段，这些头字段在所有的SIP请求消息都是必选的。这6个头字段是构建S卫消息的基本单元，它们共同提供了大部分的关键的消息路由服务，包括消息的寻址、响应的路是由、消息传播距离限制、消息排序，以及事务交互的惟-一性标识等。另外，请求行（request line）也是必选的，它包含了请求方法、Request-URI、SP版本信息。在对话外发送的请求消息包括：用INVTTE消息建立起一个会话，用OPTIONS消息进行能力查询等，6.1.1.1Aequest-URl
YD/T 1522.1-2006
除REGISTER请求，本协议中所有的请求消息的初始Request-URI都应被设为To头字段中的URI值。另外，出于安全性考虑，UA有时可能不希望将这两个头字段设为同样的值，尤其是当发端UA知道Request-URI可能会在传输中改变。某些情况下，预设路由集的存在能影响到消息的Request-URI。预设路由集是一个有序的URI集合！宅标识了个服务器链，UAC向这个服务器链发出对话外请求消息。预设路由集通常由用户或服务供应商在UA上手工配置，或者通过某些其他的非SIP机制配置。本部分建议，在给某个UA配置一个外拨代理服务器时服务供应商所提供的预设路由集中只有一个URI，即外拨代理服务器的URI。当存在预设路由集时，必须遵循本标准12.2节中描述的过程来设置Request-URI和Route头字段，其 Request-URI 作为远端目标 URI。6.1.1.2 To 头字段
To头字段指定请求消息的逻辑接收者或者是用户或资源的注册地址，该地址同样是作为请求消息的目标地址。To头字段所指示的不一定为请求消息的最终接收者。它可能包含一个SIP或SIPSURI，或其他的URI方案。本标准规定，所有的具体实现过程都必须支持SIPURI方案，任何支持TLS的实现必须支持SIPS URI方案。To头字段中充许包含一个显示名称。UAC可通过多种方式来构造一个请求消息的To头字段。通常经过人机接口，由用户输人或者从地址簿中选取。用户通常不会输人一个完整的URI，而只是提供个由数字或字母组成的字符串，由UA判断并解释该字符串。如果这个字符串被用来构造一个SIPURI的用户部分，购用户名称在符号右所示的主域中被解析；如果这个字符串被用来构造一个SIPSURI的用户部分，则用户希望进行安全的通信，同时用户名将在@符号右侧所示的主域中被解析。SIPURI中@符号右侧通常是请求发起方的主域，它使本地主域能够处理外发请求。此外，如果用户输入的是一个电话号码，且UA不会指定由某个主域来解释该号码，这时可以使用telURL，从而使请求消息所经过的每一个主域都可以处理它。请求消感的To标签标识了一个对话中的对端，如果对话没有建立，标签就不应当出现。对话之外的请求消息中不可以包含To标签（tag）。关于To头字段见本标推18章。
6.1.1.3 Fram 头字段
From头字段是指示请求发起方的逻辑标识，它可能是用户的注册地址。From头字段包含一个·URI和一个可选的显示名称。SP实体用它来决定如何处理一个请求（如呼叫自动拒绝）。由于不是逻辑名称，因此FromURI不包含IP地址或UA所在主机的全称域名（FQDN）。From头字段中允许包含一个显示名称。如果个UAC需要隐裁自己的身份，它可以使用“Anonymous”作为显示名称和一个语法正确但没有任何意义的 URI。通常，某个UA产生的请求消息中的From头字毁值是由用户或用户本地主域的服务器预先设置的。如果UA被多个用户所共用，那么它可以有多个可切换的用配置文件，每一文件中含有某一用户的URI。请求消息的接收者要对发送者进行鉴权，以确认发送者身份与From头字段相一致。Fron头字段中必须包含一个新的由 UAC选定的“tag”参数。关于 From头学字段见本标 18章。6.1.1,4Call-ID头字段
Cal-ID头字段是用来将消息分组的一性标识。本协议规定，在一个对话中，UA发送的所有请求8
YD/T 1522.1-2006
消息和响应消息都必须有同样的Call-ID，在注册生存期内，一个UA每次注册所用的Call-ID也应是一样的。
当UAC产生一个新的对话外请求时，除非被某些方法指定，否则它必须为这个请求消息选择一个在空间上和时间上都是全局惟一的Call-D头字段。所有的SPUA都必须保证它所产生的 Call-ID不会与其他UA所产生的相同。当UA收到某些失败的响应后，请求会根据响应的内容修改并重发，这些重发的请求不作为新请求处理，因而也就不需要新的Call-ID头字段。本标准建议使用RFC175中的加密随机标识符生成方法来生成Call-ID。具体实现可采用localid@host的形式。Call-ⅡD对大小写敏感，需逐宁节的进行比较。加密随机标识符方法在一定程度上能防范黑客的会话攻击，并降低了无意中产生 Call-ID 冲突的可能性。Call-D 的选择不需要通过人机接口和预先设定值来实现。
关于 Call-ID头字段见本标准 18章。6.1.1.5Cseq头字段
CSe头字段用于标识事务并对事务进行排序。它由一个请求方法和一个序列号组成，请求方法必须与对应的请求消息类型一致。对话外的非 REGISTER 请求，序列号值可以是任意的。但它必须可被表示成一个32位的无符号整数，且<2\。只要符合以上规则，客户端可以用任何方式来选择Cseg头字段值。6.1.1.6Max-Fowords头字段
Max-Fowords头字段限定一个请求息在到送目的地之前允许经过的最大跳数。它包含一一个整数值，每经过一跳，这个值就被减一。如果在请求消息到送目的地之前该值变为0，那么请求将被拒纯并返回一个483（跳数过多）错误响应消息。UAC必须在它发起的每个请求中都插人Max-Fowords头字段，值为70。在任何不出现同路的SP网络中，选择该值为70足够大的保证一个请求消息不被丢弃，其在有回路的情况下，这个慎妞不会太大而过分浪费代理服务器的资源。UA只有知道网络的拓扑结构时，才可以谨慎地选择更小的跳数值。6.1.1.7Via头字段
Via头字段定义SP事务的下层（传输层）传输协议，并标识响应消息将要被发送的位置。只有当到达下一跳所用的传输协议被选定后，才能在请求消息中加人Va头字段值。本协议规定，当 UAC 生成请求消息时，它必须在其中插入一个Via头字段。Via 头字段的协议名称和协议版本必须分别为“sP”和2.0\。Via头字段中必须包含一个“branch”参数，该参数用来标识由当前请求所建立的事务。该参数既用在客户端也用在务器端。对于某个UA发出的所有请求，它们的banch参数值在空间和时间上必须全局惟一的。但有两种情祝例外：一是CANCEL求，以后会说明 CANCEL请求的branch参数与它所要取消的那个请求的 branch参数是一样的：另一个是对非 2xx 响应的 ACK 请求，这种情况下 ACK 请求与相关的 INVTIE 请求有着同样的branchID，它所要确认的就是该INVITE的响应。SIP实体在插入 branch D时，必须以\z9hG4bK\开头。这7个字符是“magic cookie”，这样SIP服务器在收到请求消息时，就能确定现在的 branchⅡD是全局惟一的。另外，branchD参数的准确格式由具体的实现定义。
Via头的 maddr、ttl 以及 sent-by部分在传输层对请求消息进行处理时进行设置，见本标准第16章。关于代理服务器对 Via 头字段的处理见本标 13 章。9
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。