SIP协议详解(中文)-2
满昊然
在对话中，有其他的相关会被发送。一个对话是一个持续一定时间的两个用户之间的端到端的SIP关系。对话过程要求两个用户代理之间的信息是有序的而且请求被正确路由传输的。在这个规范中，只有INVITE请求可以用来建立会话。当一个UAC在一个对话中发出请求的时候，它不仅遵循第8节描述的一般UAC规则而且也遵循对话中的请求规则。第12节讲述了对话并且讨论了对话的创建和维持，以及在对话中创建一个请求。
SIP中最重要的方法就是INVITE方法，它用来在不同的参与者中创建会话使用。一个会话由一组参与者，他们之间用于交流的媒体流组成。第13节讲述了这些会话的创建初始化过程，以及创建一个或一组对话。第14节讲述了在对话中使用INVITE请求来改变会话的属性。最后，第15节，讲述了如何终止会话。
第8、10、11、12、13、14、15节讲述了完整的UA核心（第9节描述了取消，在UA核心和代理核心中使用）。第16节讲数了代理服务器，代理服务器用于在两个UA之间做消息路由使用。
6、协议的定义
以下讲述的名次对SIP有着额外的意义：
Address-of-Record: 记录地址。一个address-of-record(AOR)是一个SIP或者SIPS URI它指向了一个具有定位服务的主机，这个主机可以把URI映射成为用户真正物理位置的URI。通常情况下，定位服务器是通过登记服务来建立的。一个AOR经常被认为是一个用户的”公共地址”
Back-to-Back UserAgent:背对背的用户代理（B2BUA）是一个逻辑实体，它就像用户代理服务器（UAS）一样接收和处理请求。为了决定该如何应答一个请求，B2BUA就像UAC一样工作，并且发出请求。但是它不像代理服务器（proxy），它维持对话状态，并且参与已经建立的对话中的每一个请求。由于它是直接的UAC和UAS的串连，所以，不需要对他有额外的定义。
Call：呼叫，一个呼叫是一个非正式的术语，它是指在端点之间一个一些通讯行为，通常用于建立多媒体对话。
Call Leg: 对话的别名；在本规范中没有使用。
Call Stateful: 如果一个代理服务器（proxy）保存一个对话的状态（从最开始的INVITE到对话终结的BYE），那么这个代理服务器就是请求有状态的。一个请求有状态（call stateful）的代理服务器也一定是事务有状态的，但是事务有状态的不一定是请求有状态的。
Client：客户端。一个客户端是一个任意的网络元素，它发出SIP请求和接收SIP应答。客户端可能会也可能不会和人交互。用户代理客户端（UAC）和代理服务器都是客户端。
Conference: 一个包含多个参与方的多媒体会话（见后）。
Core：核心。核心定义了SIP实体的特定类别。比如定义了一个有状态和无状态的代理服务器，一个用户代理或者注册服务器（registrar）。所有的核心，除了无状态代理服务器，都是事务用户。
Dialog:对话，一个对话是持续一段时间的两个UA之间的端到端的SIP关系。一个对话由SIP消息建立，就像用2xx响应INVITE请求。我们用Call identifier，local tag（本地tag），remote tag（对方tag）来标志一个对话，一个对话在RFC 2543中被正式叫做CALL LEG.
Downstream: 它是事务中的消息传递方向。它特指从UAC到UAS的请求流的方向，
Final Response：终结响应。一个响应终端SIP事务的应答，和事务中间的临时响应相反。所有的2xx，3xx，4xx，5xx，6xx响应都是终结响应。
Header：头。头域是在SIP消息头部用来描述这个SIP消息信息的部分。它由一堆头域字段组成。
Header Field:头域字段。头域字段是在SIP消息头域的字段。一个头域字段可以由多个头域字段行组成。一个头域字段由一个头域名和（零个或多个）头域值组成。多个头域值用’,’分割。某些头域字段只能有单个值，比如结果域（result）就只能有一个值。
Header Field Value:头域值。一个头域值是一个单个的值，一个头域字段可以有0个或者多个头域值。
Home Domain：宿主机。一个提供SIP服务的主机。一般指的是在登记服务中指明的记录地址中的URI的主机。
Informational Response:提示应答。和临时应答一样。
Initiator, Calling Party, Caller: 用INVITE初始一个会话（和对话）的那方。一个caller从发出INVITE请求建立对话开始，到对话终止都一直是这个角色。
Invitation: 一个INVITE请求。
Invitee,Invited User,Called Party, Callee:被叫方。收到INVITE请求并且建立会话的那方。一个被叫方从收到INVITE请求起，到终止INVITE建立的对话结束，都称作被叫方。
Location Service: 定位服务。定位服务是用来给SIP转发或者代理服务器确定被叫方可能的位置使用的。它包含一张绑定了address-of-record的表，被叫方可能有0到多个记录。绑定的记录可以通过多种渠道添加和删除；本规范定义了REGISTER方法来更新绑定表。
Loop：环路。当请求抵达一个代理服务器，代理服务器转发这个请求，当这个请求再次来到同一个代理服务器，就称之为环路。当第二次抵达的时候，Request－URI中包含了上次抵达的资料，并且由于并没有什么东西可以改变转发的策略，这样就导致这个请求还会再次被转发回来。环路请求是错误的，所以，处理程序需要检测和防止协议中出现的环路请求。
Loose Routing:丢失路由。代理服务器在下述情况下会丢失路由。
A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.
Message:消息。SIP元素之间传送的协议数据就是消息。SIP消息既可以是请求也可以是应答。
Method:方法。方法是在服务器请求处理的主要功能。方法是请求消息自身携带的。典型的方法就是INVITE和BYE。
Outbound Proxy:对外代理服务器。一个代理服务器接收到客户的请求，即使它不是由Request_URI所决定的服务器。通常一个UA会手工配置一个对外的代理服务器，或者可以通过一个自动配置的协议自动配置一个。
Parallel Search: 并行搜索。并行搜索情况下，代理服务器会向多个用户可能存在的地方发起请求，并且等待应答。同串行搜索不同的地方是，并行搜索不会等待上一个请求应答回来之后再发起下一个搜索，而是一个接一个的发起搜索请求。
Provisional Response: 临时应答。服务器用来标志自己正在处理的应答，但是本应答并不结束一个SIP事务。1xx应答就是临时的，其他应答标志着事务的结束。
Proxy,Proxy Server:代理、代理服务器。一个中间的实体。它本身即作为客户端也作为服务端，为其他客户端提供请求的转发服务。一个代理服务器首先提供的是路由服务，也就是说保证请求被发到更加”靠近”目标用户的地方。代理服务器对某些强制政策有用（比如，确认一个用户是否允许建立一个呼叫等）。一个代理服务器翻译，并且，如果有需要的话，再转发前会重写请求消息。
Recursion：回路、递归。一个客户端，在响应请求的时候产生新的到Contract包头域的URI请求的时候，会在3xx响应中陷入递归。A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response.
Redirect Server:重定向服务器。一个重定向服务器是一个产生3xx应答的UAS服务器，指示客户端连接别的URI。
Registrar: 登记员。一个登记员（登记服务器）是一个接收REGISTER请求得服务器。他把请求得信息放到定位服务器中，这样可以让定位服务器很方便得查找位置信息。
Regular Transaction:常规事务。凡不包含INVITE,ACK,或者CANCEL方法得事务就是常规事务。
Request: 请求。 一个由客户端发到服务端得SIP信息，用于执行特定得功能。
Response：应答。一个由服务端发到客户端得SIP信息。用来标志从客户端发往服务端得请求处理得情况得。
Ringback: 回铃音。回铃音是一个信号音。是给呼叫方得一个信号表示被叫方正在振铃（Ringing）。
Route Set: 路由集。路由集合是一个顺序得SIP或者SIPS URI。这些URI描述了传递一个请求所必须经历得代理列表。一个路由集可以是自适应得，因为包头中包含了Record-Route(记录路由)，也可以是依赖配置得到得。
Server：服务器。一个server是一个网络元素接收请求并且处理请求并且发送回应给请求方。典型得服务器就是代理服务器（proxies），用户代理服务器（user agent servers），重定向服务器，登记服务器。
Sequential Search：顺序查找。在顺序查找中，代理服务器顺序尝试联系地址，在处理下一个之前必须等待上一个请求已经有一个结束应答。一个2xx或者6xx系列得最终应答总是结束一个顺序查找。
Session：会话。根据SDP得描述：”一个多媒体会话是一个由多媒体发送方和接受方组成得集合，并且包括在发送方和接受方之间得数据流。一个多媒体会议是一个典型得多媒体会话。”(RFC 2327[1])(一个session在SDP订一下可以是一个或者多个RTP sessino)。在定义中，一个被叫方可以被多次邀请，被不同得呼叫方邀请，到同一个会话。在SDP中，一个会话可以被SDP用户名，session id,网络类型，地址类型，地址元素得一个集合串所规定。
SIP 事务：一个SIP事务是在客户端和服务端得事件，包括了从第一个由客户端发送到服务端得请求，到最后一个（非1xx）服务端向客户端发出得终结应答。如果请求是一个INVITE请求，并且终结应答是一个非2xx得应答，那么事务还包括一个ACK给服务器做应答。给INVITE请求的2xx应答的ACK回应，是一个独立的事务。
Spiral：回溯。一个回溯是指一个SIP请求，路由给一个proxy，并且转发，但是又被路由回这个proxy，但是不同于回路（递归）的是，这次路由回来的请求包的包头中，包含了不同于原请求的请求包部分，使得本次proxy决定的路由转发与上次不同。通常，这是说，请求的Request-URI不同于上次的Request_URI。一个回溯不是一个错误，不同于回路（环路loop）。通常导致这样的现象是呼叫转发（call forwarding）。一个用户呼叫 joe@example.com 。example.com代理服务器转发请求到Joe的PC,并且Joe的pc呼叫转移到 bob@example.com 。这个请求被转发回example.com代理服务器。可是这个并不是一个环路（loop）。因为请求的目的地址变成了另一个用户，这就是回溯，是一个合法的情况。
Stateful Proxy:有状态的代理服务器。在逻辑上，有状态的代理服务器就是处理一个请求的过程中，维持的一个本规范所定义的客户端和服务端的事务状态机。也是一个事务又状态代理服务器(transaction stateful proxy)。具体的stateful proxy在第16节定义。一个（事务）有状态代理服务器和一个call stateful proxy不是一回事。
Stateless Proxy：无状态的代理服务器。在逻辑上，无状态代理服务器在处理请求中，并不维持客户和服务端的事务状态机。一个无状态的代理服务器直接转发每一个接收到的请求和每一个接收到的响应。
Strict Routing:严格路由。路由处理规则如果复核RFC2543协议（and many prior work in progress versions of this RFC） 就是一个严格路由。在这个规则下，如果在包头中包含Route域，那么代理服务器就会删除Request_URI域内容。本文档并不要求一定要有严格路由，本文档只要求松散路由就可以了。支持严格路由的代理服务器也叫严格路由器。
Target Refresh Request: 目标刷新请求。一个Target Refresh Request是一个在对话中发出的请求，用来更改对话目标的请求。
Transaction User(TU):事务用户。在transaction 层之上的协议层。TU包括了UAC 核心，UAS core,和proxy core。
Upstream:上行流。一个在事务中的消息流向方向。它是指由用户代理服务器（UAS）发出应答到用户代理客户端（UAC）的消息流向方向。
URL-encoded:一串根据RFC2396－2.4节编码的字符。
User Agent Client(UAC):用户代理客户端。用户代理客户端是一个逻辑的概念，他创建一个新请求，并且用客户事务状态机发送这个请求。UAC角色只在事务中存在。换句话说，UAC就是一小段代码初始化一个请求，并且在事务中遵循UAC的规则。如果它接下来收到一个请求，那么在那个事务中，它就是作为UAS来处理请求。
UAC Core:UAC核心。在transaction和transport层之上得UAC实现的功能集合。
User Agent Server(UAS): 用户代理服务器.UAS是一个逻辑的实体，对SIP请求做响应的。应答接受、拒绝、或者转发对应的请求。UAS角色在事务中存在。换句话说，是响应请求的一小段软件，在事务中作为UAS存在。如果他发出请求，那么他就在事务中作为UAC存在。
UAS Core：UAS核心。在transaction和transport层智商的UAS实现的功能集合。
User Agent（UA）。一个逻辑实体的概念，包含UAC和UAS。
UAC和UAS，就像代理服务器和转发服务器，是在事务by事务的原理（串行事务处理）上定义的。例如，当发出一个初始化INVITE请求的时候，UA作为UAC初始化一个呼叫动作，当从被叫方接收到一个BYE请求的时候，UA作为UAS响应。类似的，同样的代码可以对一个请求做为proxy服务器处理，对另一个请求作为重定向服务器。
proxy，location，registrar服务器都是逻辑实体，在它们的实现中，可能是作为单个应用实现的。
7、SIP消息：
SIP协议是一个基于文本的协议，使用UTF-8字符集（RFC2279[7]）。
一个SIP消息既可以是一个从客户端到服务器端的请求，也可以是一个从服务器端到客户端的一个应答。
即使在字符集上和语法细节上有所不同，请求（7.1）还是应答（7.2）消息都基于RFC2822格式的。（SIP允许包头域不是标准的RFC2822包头域）。这两种消息类型都由一个起始行，一个或者多个包头域，一个可选的消息中文组成。
一般消息＝ 起始行
*消息包头
CRLF
[消息正文]
起始行＝ 请求行/状态行
起始行、每一个包头行，空行、都必须由回车换行组成（CRLF）。即使消息中文没有，也必须有一个空行跟随。
除了在字符集上的区别以外，很多SIP的消息和包头域的格式都同HTTP/1.1一样。我们在这里就不重复它的语法和语义了，我们用[HX.Y]来标志HTTP/1.1规范（RFC2616[8]）的X.Y节的描述。
SIP并非一个HTTP的超集或者扩展。
7．1 请求
SIP请求是根据起始行中的Request-Line来区分的。一个Request_line包含方法名字，Request－URI，用单个空格（SP）间隔开的协议版本。
Request-Line由CRLF结束。除了用作行结束标志以外，不允许CR或者LF出现在其他地方。在其他域中，不允许出现线形的空白（liner whitespace LWS）
Request-Line = Method SP Request-URI SP SIP-VERSION CRLF
Method: 这个规范规定了6中方法：REGISTER用于登记联系信息，INVITE，ACK,CANCEL用于建立会话，BYE用于结束会话，OPTIONS用于查询服务器负载。SIP扩展、标准RFC追加可能包含扩展的方法。
Request-URI: Request-URI是一个SIP或者SIPS URI，他们在19.1节由描述。也可以是一个通用的URI(RFC 2396[5])。它标志了这个请求所用到的用户或者服务的地址。Request-URI禁止包含空白字符或者控制字符，并且禁止用”<>”括上。
SIP 元素可以支持除了SIP或者SIPS之外所规定的Request-URIs。比如”tel” URI模式（RFC 2806[9]）。SIP元素可以用他们自己的机制来转换non-SIP URIs到SIP URI，SIPS URI或者其他什么格式的URI。
SIP-Version：请求和应答消息都包含当前使用的SIP版本，这个遵循[H3.1](类似HTTP用SIP替代，用SIP/2.0替代HTTP/1.1)中关于版本的规定，版本依赖，升级版本号。一个应用，发出的SIP消息一定包含了SIP-Version “SIP/2.0”。这个SIP版本串是大小写不铭感的，但是在实现中必须发送大写。
不像HTTP/1.1,SIP把版本号当作一个文本串处理。在实现上，这个应该不会有区别。
7．2应答
SIP应答和SIP请求的区别在于在START-LINE中是否包含一个STATUS-LINE。一个status-line在由数字表达的status－code之前，是一个协议的版本串，每一个元素之间用一个单个SP（空格）分开。
除了最后用作结束标志以外，CR/LF不允许出现在其他地方。
status-line = SIP-VERSION SP STATUS-CODE SP Reasong-Phrase CRLF
Status-Code 是一个3位的数字result code，用来标志处理请求的一个结果。Reason-Phrase是一个简短的Status-Code的说明。Status-Code是为了能自动处理使用的，但是Reason-Phrase是用来给用户看得。一个客户端并不要求一定要显示或者解释这个Reason-Phrase。本文档建议输出这个reason-phrase,实现中可以选择其他文本，比如用请求包头中指定的合适语言来显示。
status－code的第一个数字表示了应答的类型。接下来两个数字并不作分类使用。基于这个原因，任何status code在100到199的可以统称位”1xx应答”，类似的，在200到299的可以统称位”2xx应答”，依此类推。SIP/2.0允许6类应答：
1xx：临时应答－请求已经接收，正在处理这个请求。
2xx：成功处理－请求已经成功接收，并且正确处理了这个请求。
3xx：重定向－还需要附加的操作才能完成这个请求，本请求转发到其他的服务器上处理。
4xx：客户端错误－－请求包含错误的格式或者不能在这个服务器上完成。
5xx：服务器错误－服务器不能正确的处理这个显然合法的请求。
6xx：全局错误－请求不能被任何服务器处理。
21节定义了详细的代码说明。
7.3 头域
SIP头域和HTTP头域在语法和语义上都比较类似。特别的，SIP头域遵循[H4.2]关于消息头的语法的定义，并且遵循多行的扩展头域的规则。(后者 is specified in HTTP with implicit whitespace and folding)。这个规范遵循RFC2234[10]，并且把清晰的空白和封装作为内在的语法规则。
[H4.2]也定义了具有相同域名的多个头域，他们的值是用逗号分开的列表，可以合并到一个头域中。这个也适用于SIP，但是细节上略有不同，因为语法不同。实际上，任何SIP的包头语法都是基于如下范式的：
header ＝ “ header-name” HCOLON header-value *(COMMA header-value)
这个允许合并在具有同一个域名的多个头域，到一个用逗号分割的单个头域中。Contact头域除了当域值是”*”之外，都允许用逗号分割的列表。
7.3.1 头域格式。
头域遵循在RFC2822的2.2节定义的通用头域格式。每一个头域都由一个域名加上冒号（”:”）和域值组成。
field-name:field-value
消息头的正则语法在25节中有介绍介绍。
在消息头中，允许在冒号的左右有任意个数的空白；但是，在实现中，建议避免域名和冒号中间有空格，并且建议在冒号和值之间使用单个空格（SP）。
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
所以，上面的都是合法的，也是相等的，但是最后一种是我们所推荐的。
头域可以扩展成为多行的，只要在每一个附加行前边用至少一个SP或者水平TAB(HT)打头就可以了。这种多行的头域在行结尾并且在下一行之前的空白SP（或者HT）将被认为是一个单个的SP字符。所以，下边的例子是相等的：
Subject: I know you’re there, pick up the phone and talk to me!
Subject: I know you’re there,
pick up the phone,
and talk to me!
头域中的不同域名的相关顺序并没有什么意义。虽然如此，我们还是强烈建议与路由相关的域（VIA,ROUTE,Record-Route,Proxy-Require,Max-Forwards,Proxy-Authorization等等）放在消息头的最前边，这样可以提高处理的速度。相同域名的域之间的顺序非常重要。只有当单个头域的域值是可以用逗号分割的列表的时候，才可以表达成为同一个域名的多个头域（这就是说，如果遵循7.3定义的语法）。也就是意味着必须可以将同一个域名的多个头域在不改变消息语义的前提下，改换表达成为一对”域名: 域值”；这个转换是通过顺序增加每一个域的域值，域值之间用逗号分割。这个规则有几个例外，就是WWW-Authenticate,Authorization,Proxy-Authenticate,和Proxy-Authorization头域。多个头域行可以在消息头中出现，但是由于他们的语法并不遵循7.3中定义的通用格式，所以，他们并不能合并成为单个头域行。
在实现上，必须能够既能够处理多个头域行的情况，也必须能够处理用逗号分割的合并的单个头域行的情况。
下边的几组头域是相等的：
Route: <sip:alice@atlanta.com>
Subject: Lunch
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Subject: Lunch
Subject: Lunch
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
<sip:carol@chicago.com>
下边各组是合法的，但是并不相等。
Route: <sip:alice@atlanta.com>
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:bob@biloxi.com>
Route: <sip:alice@atlanta.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,<sip:bob@biloxi.com>
每一个头域值的格式是依赖于它的头域名的。他可以是任意顺序的TEXT-UTF8字符，也可以是一个空格，标记，分隔符，引号括起来的字串的组合。很多头域都回附带一个通用的域值格式。这个域值格式是由分号分开的参数名和参数值的组合：
field-name: field-value *(;parameter-name=parameter-value)
虽然在域值里边可以有任意数量的parameter-name/parameter-value对，但是不能允许有相同的parameter-name存在（唯一性）。除了特别指出的头域之外，头域中的域名、域值、parameter name parameter-value都是大小写不敏感的。标记词始终是大小写不铭感的。除非有特别的指定，引号串的字符串是大小写敏感的。例如：
Contact: <sip:alice@atlanta.com>;expires=3600
和
CONTACT: <sip:alice@atlanta.com>; ExPiReS=3600
相同。
Content-Disposition: session;handling=optional
和
content-disposition: Session;HANDLING=OPTIONAL
相同。
下边的两个头域不相同：
Warning: 370 devnull “Choose a bigger pipe”
Warning: 370 devnull “CHOOSE A BIGGER PIPE”
SIP中最重要的方法就是INVITE方法，它用来在不同的参与者中创建会话使用。一个会话由一组参与者，他们之间用于交流的媒体流组成。第13节讲述了这些会话的创建初始化过程，以及创建一个或一组对话。第14节讲述了在对话中使用INVITE请求来改变会话的属性。最后，第15节，讲述了如何终止会话。
第8、10、11、12、13、14、15节讲述了完整的UA核心（第9节描述了取消，在UA核心和代理核心中使用）。第16节讲数了代理服务器，代理服务器用于在两个UA之间做消息路由使用。
6、协议的定义
以下讲述的名次对SIP有着额外的意义：
Address-of-Record: 记录地址。一个address-of-record(AOR)是一个SIP或者SIPS URI它指向了一个具有定位服务的主机，这个主机可以把URI映射成为用户真正物理位置的URI。通常情况下，定位服务器是通过登记服务来建立的。一个AOR经常被认为是一个用户的”公共地址”
Back-to-Back UserAgent:背对背的用户代理（B2BUA）是一个逻辑实体，它就像用户代理服务器（UAS）一样接收和处理请求。为了决定该如何应答一个请求，B2BUA就像UAC一样工作，并且发出请求。但是它不像代理服务器（proxy），它维持对话状态，并且参与已经建立的对话中的每一个请求。由于它是直接的UAC和UAS的串连，所以，不需要对他有额外的定义。
Call：呼叫，一个呼叫是一个非正式的术语，它是指在端点之间一个一些通讯行为，通常用于建立多媒体对话。
Call Leg: 对话的别名；在本规范中没有使用。
Call Stateful: 如果一个代理服务器（proxy）保存一个对话的状态（从最开始的INVITE到对话终结的BYE），那么这个代理服务器就是请求有状态的。一个请求有状态（call stateful）的代理服务器也一定是事务有状态的，但是事务有状态的不一定是请求有状态的。
Client：客户端。一个客户端是一个任意的网络元素，它发出SIP请求和接收SIP应答。客户端可能会也可能不会和人交互。用户代理客户端（UAC）和代理服务器都是客户端。
Conference: 一个包含多个参与方的多媒体会话（见后）。
Core：核心。核心定义了SIP实体的特定类别。比如定义了一个有状态和无状态的代理服务器，一个用户代理或者注册服务器（registrar）。所有的核心，除了无状态代理服务器，都是事务用户。
Dialog:对话，一个对话是持续一段时间的两个UA之间的端到端的SIP关系。一个对话由SIP消息建立，就像用2xx响应INVITE请求。我们用Call identifier，local tag（本地tag），remote tag（对方tag）来标志一个对话，一个对话在RFC 2543中被正式叫做CALL LEG.
Downstream: 它是事务中的消息传递方向。它特指从UAC到UAS的请求流的方向，
Final Response：终结响应。一个响应终端SIP事务的应答，和事务中间的临时响应相反。所有的2xx，3xx，4xx，5xx，6xx响应都是终结响应。
Header：头。头域是在SIP消息头部用来描述这个SIP消息信息的部分。它由一堆头域字段组成。
Header Field:头域字段。头域字段是在SIP消息头域的字段。一个头域字段可以由多个头域字段行组成。一个头域字段由一个头域名和（零个或多个）头域值组成。多个头域值用’,’分割。某些头域字段只能有单个值，比如结果域（result）就只能有一个值。
Header Field Value:头域值。一个头域值是一个单个的值，一个头域字段可以有0个或者多个头域值。
Home Domain：宿主机。一个提供SIP服务的主机。一般指的是在登记服务中指明的记录地址中的URI的主机。
Informational Response:提示应答。和临时应答一样。
Initiator, Calling Party, Caller: 用INVITE初始一个会话（和对话）的那方。一个caller从发出INVITE请求建立对话开始，到对话终止都一直是这个角色。
Invitation: 一个INVITE请求。
Invitee,Invited User,Called Party, Callee:被叫方。收到INVITE请求并且建立会话的那方。一个被叫方从收到INVITE请求起，到终止INVITE建立的对话结束，都称作被叫方。
Location Service: 定位服务。定位服务是用来给SIP转发或者代理服务器确定被叫方可能的位置使用的。它包含一张绑定了address-of-record的表，被叫方可能有0到多个记录。绑定的记录可以通过多种渠道添加和删除；本规范定义了REGISTER方法来更新绑定表。
Loop：环路。当请求抵达一个代理服务器，代理服务器转发这个请求，当这个请求再次来到同一个代理服务器，就称之为环路。当第二次抵达的时候，Request－URI中包含了上次抵达的资料，并且由于并没有什么东西可以改变转发的策略，这样就导致这个请求还会再次被转发回来。环路请求是错误的，所以，处理程序需要检测和防止协议中出现的环路请求。
Loose Routing:丢失路由。代理服务器在下述情况下会丢失路由。
A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.
Message:消息。SIP元素之间传送的协议数据就是消息。SIP消息既可以是请求也可以是应答。
Method:方法。方法是在服务器请求处理的主要功能。方法是请求消息自身携带的。典型的方法就是INVITE和BYE。
Outbound Proxy:对外代理服务器。一个代理服务器接收到客户的请求，即使它不是由Request_URI所决定的服务器。通常一个UA会手工配置一个对外的代理服务器，或者可以通过一个自动配置的协议自动配置一个。
Parallel Search: 并行搜索。并行搜索情况下，代理服务器会向多个用户可能存在的地方发起请求，并且等待应答。同串行搜索不同的地方是，并行搜索不会等待上一个请求应答回来之后再发起下一个搜索，而是一个接一个的发起搜索请求。
Provisional Response: 临时应答。服务器用来标志自己正在处理的应答，但是本应答并不结束一个SIP事务。1xx应答就是临时的，其他应答标志着事务的结束。
Proxy,Proxy Server:代理、代理服务器。一个中间的实体。它本身即作为客户端也作为服务端，为其他客户端提供请求的转发服务。一个代理服务器首先提供的是路由服务，也就是说保证请求被发到更加”靠近”目标用户的地方。代理服务器对某些强制政策有用（比如，确认一个用户是否允许建立一个呼叫等）。一个代理服务器翻译，并且，如果有需要的话，再转发前会重写请求消息。
Recursion：回路、递归。一个客户端，在响应请求的时候产生新的到Contract包头域的URI请求的时候，会在3xx响应中陷入递归。A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response.
Redirect Server:重定向服务器。一个重定向服务器是一个产生3xx应答的UAS服务器，指示客户端连接别的URI。
Registrar: 登记员。一个登记员（登记服务器）是一个接收REGISTER请求得服务器。他把请求得信息放到定位服务器中，这样可以让定位服务器很方便得查找位置信息。
Regular Transaction:常规事务。凡不包含INVITE,ACK,或者CANCEL方法得事务就是常规事务。
Request: 请求。 一个由客户端发到服务端得SIP信息，用于执行特定得功能。
Response：应答。一个由服务端发到客户端得SIP信息。用来标志从客户端发往服务端得请求处理得情况得。
Ringback: 回铃音。回铃音是一个信号音。是给呼叫方得一个信号表示被叫方正在振铃（Ringing）。
Route Set: 路由集。路由集合是一个顺序得SIP或者SIPS URI。这些URI描述了传递一个请求所必须经历得代理列表。一个路由集可以是自适应得，因为包头中包含了Record-Route(记录路由)，也可以是依赖配置得到得。
Server：服务器。一个server是一个网络元素接收请求并且处理请求并且发送回应给请求方。典型得服务器就是代理服务器（proxies），用户代理服务器（user agent servers），重定向服务器，登记服务器。
Sequential Search：顺序查找。在顺序查找中，代理服务器顺序尝试联系地址，在处理下一个之前必须等待上一个请求已经有一个结束应答。一个2xx或者6xx系列得最终应答总是结束一个顺序查找。
Session：会话。根据SDP得描述：”一个多媒体会话是一个由多媒体发送方和接受方组成得集合，并且包括在发送方和接受方之间得数据流。一个多媒体会议是一个典型得多媒体会话。”(RFC 2327[1])(一个session在SDP订一下可以是一个或者多个RTP sessino)。在定义中，一个被叫方可以被多次邀请，被不同得呼叫方邀请，到同一个会话。在SDP中，一个会话可以被SDP用户名，session id,网络类型，地址类型，地址元素得一个集合串所规定。
SIP 事务：一个SIP事务是在客户端和服务端得事件，包括了从第一个由客户端发送到服务端得请求，到最后一个（非1xx）服务端向客户端发出得终结应答。如果请求是一个INVITE请求，并且终结应答是一个非2xx得应答，那么事务还包括一个ACK给服务器做应答。给INVITE请求的2xx应答的ACK回应，是一个独立的事务。
Spiral：回溯。一个回溯是指一个SIP请求，路由给一个proxy，并且转发，但是又被路由回这个proxy，但是不同于回路（递归）的是，这次路由回来的请求包的包头中，包含了不同于原请求的请求包部分，使得本次proxy决定的路由转发与上次不同。通常，这是说，请求的Request-URI不同于上次的Request_URI。一个回溯不是一个错误，不同于回路（环路loop）。通常导致这样的现象是呼叫转发（call forwarding）。一个用户呼叫 joe@example.com 。example.com代理服务器转发请求到Joe的PC,并且Joe的pc呼叫转移到 bob@example.com 。这个请求被转发回example.com代理服务器。可是这个并不是一个环路（loop）。因为请求的目的地址变成了另一个用户，这就是回溯，是一个合法的情况。
Stateful Proxy:有状态的代理服务器。在逻辑上，有状态的代理服务器就是处理一个请求的过程中，维持的一个本规范所定义的客户端和服务端的事务状态机。也是一个事务又状态代理服务器(transaction stateful proxy)。具体的stateful proxy在第16节定义。一个（事务）有状态代理服务器和一个call stateful proxy不是一回事。
Stateless Proxy：无状态的代理服务器。在逻辑上，无状态代理服务器在处理请求中，并不维持客户和服务端的事务状态机。一个无状态的代理服务器直接转发每一个接收到的请求和每一个接收到的响应。
Strict Routing:严格路由。路由处理规则如果复核RFC2543协议（and many prior work in progress versions of this RFC） 就是一个严格路由。在这个规则下，如果在包头中包含Route域，那么代理服务器就会删除Request_URI域内容。本文档并不要求一定要有严格路由，本文档只要求松散路由就可以了。支持严格路由的代理服务器也叫严格路由器。
Target Refresh Request: 目标刷新请求。一个Target Refresh Request是一个在对话中发出的请求，用来更改对话目标的请求。
Transaction User(TU):事务用户。在transaction 层之上的协议层。TU包括了UAC 核心，UAS core,和proxy core。
Upstream:上行流。一个在事务中的消息流向方向。它是指由用户代理服务器（UAS）发出应答到用户代理客户端（UAC）的消息流向方向。
URL-encoded:一串根据RFC2396－2.4节编码的字符。
User Agent Client(UAC):用户代理客户端。用户代理客户端是一个逻辑的概念，他创建一个新请求，并且用客户事务状态机发送这个请求。UAC角色只在事务中存在。换句话说，UAC就是一小段代码初始化一个请求，并且在事务中遵循UAC的规则。如果它接下来收到一个请求，那么在那个事务中，它就是作为UAS来处理请求。
UAC Core:UAC核心。在transaction和transport层之上得UAC实现的功能集合。
User Agent Server(UAS): 用户代理服务器.UAS是一个逻辑的实体，对SIP请求做响应的。应答接受、拒绝、或者转发对应的请求。UAS角色在事务中存在。换句话说，是响应请求的一小段软件，在事务中作为UAS存在。如果他发出请求，那么他就在事务中作为UAC存在。
UAS Core：UAS核心。在transaction和transport层智商的UAS实现的功能集合。
User Agent（UA）。一个逻辑实体的概念，包含UAC和UAS。
UAC和UAS，就像代理服务器和转发服务器，是在事务by事务的原理（串行事务处理）上定义的。例如，当发出一个初始化INVITE请求的时候，UA作为UAC初始化一个呼叫动作，当从被叫方接收到一个BYE请求的时候，UA作为UAS响应。类似的，同样的代码可以对一个请求做为proxy服务器处理，对另一个请求作为重定向服务器。
proxy，location，registrar服务器都是逻辑实体，在它们的实现中，可能是作为单个应用实现的。
7、SIP消息：
SIP协议是一个基于文本的协议，使用UTF-8字符集（RFC2279[7]）。
一个SIP消息既可以是一个从客户端到服务器端的请求，也可以是一个从服务器端到客户端的一个应答。
即使在字符集上和语法细节上有所不同，请求（7.1）还是应答（7.2）消息都基于RFC2822格式的。（SIP允许包头域不是标准的RFC2822包头域）。这两种消息类型都由一个起始行，一个或者多个包头域，一个可选的消息中文组成。
一般消息＝ 起始行
*消息包头
CRLF
[消息正文]
起始行＝ 请求行/状态行
起始行、每一个包头行，空行、都必须由回车换行组成（CRLF）。即使消息中文没有，也必须有一个空行跟随。
除了在字符集上的区别以外，很多SIP的消息和包头域的格式都同HTTP/1.1一样。我们在这里就不重复它的语法和语义了，我们用[HX.Y]来标志HTTP/1.1规范（RFC2616[8]）的X.Y节的描述。
SIP并非一个HTTP的超集或者扩展。
7．1 请求
SIP请求是根据起始行中的Request-Line来区分的。一个Request_line包含方法名字，Request－URI，用单个空格（SP）间隔开的协议版本。
Request-Line由CRLF结束。除了用作行结束标志以外，不允许CR或者LF出现在其他地方。在其他域中，不允许出现线形的空白（liner whitespace LWS）
Request-Line = Method SP Request-URI SP SIP-VERSION CRLF
Method: 这个规范规定了6中方法：REGISTER用于登记联系信息，INVITE，ACK,CANCEL用于建立会话，BYE用于结束会话，OPTIONS用于查询服务器负载。SIP扩展、标准RFC追加可能包含扩展的方法。
Request-URI: Request-URI是一个SIP或者SIPS URI，他们在19.1节由描述。也可以是一个通用的URI(RFC 2396[5])。它标志了这个请求所用到的用户或者服务的地址。Request-URI禁止包含空白字符或者控制字符，并且禁止用”<>”括上。
SIP 元素可以支持除了SIP或者SIPS之外所规定的Request-URIs。比如”tel” URI模式（RFC 2806[9]）。SIP元素可以用他们自己的机制来转换non-SIP URIs到SIP URI，SIPS URI或者其他什么格式的URI。
SIP-Version：请求和应答消息都包含当前使用的SIP版本，这个遵循[H3.1](类似HTTP用SIP替代，用SIP/2.0替代HTTP/1.1)中关于版本的规定，版本依赖，升级版本号。一个应用，发出的SIP消息一定包含了SIP-Version “SIP/2.0”。这个SIP版本串是大小写不铭感的，但是在实现中必须发送大写。
不像HTTP/1.1,SIP把版本号当作一个文本串处理。在实现上，这个应该不会有区别。
7．2应答
SIP应答和SIP请求的区别在于在START-LINE中是否包含一个STATUS-LINE。一个status-line在由数字表达的status－code之前，是一个协议的版本串，每一个元素之间用一个单个SP（空格）分开。
除了最后用作结束标志以外，CR/LF不允许出现在其他地方。
status-line = SIP-VERSION SP STATUS-CODE SP Reasong-Phrase CRLF
Status-Code 是一个3位的数字result code，用来标志处理请求的一个结果。Reason-Phrase是一个简短的Status-Code的说明。Status-Code是为了能自动处理使用的，但是Reason-Phrase是用来给用户看得。一个客户端并不要求一定要显示或者解释这个Reason-Phrase。本文档建议输出这个reason-phrase,实现中可以选择其他文本，比如用请求包头中指定的合适语言来显示。
status－code的第一个数字表示了应答的类型。接下来两个数字并不作分类使用。基于这个原因，任何status code在100到199的可以统称位”1xx应答”，类似的，在200到299的可以统称位”2xx应答”，依此类推。SIP/2.0允许6类应答：
1xx：临时应答－请求已经接收，正在处理这个请求。
2xx：成功处理－请求已经成功接收，并且正确处理了这个请求。
3xx：重定向－还需要附加的操作才能完成这个请求，本请求转发到其他的服务器上处理。
4xx：客户端错误－－请求包含错误的格式或者不能在这个服务器上完成。
5xx：服务器错误－服务器不能正确的处理这个显然合法的请求。
6xx：全局错误－请求不能被任何服务器处理。
21节定义了详细的代码说明。
7.3 头域
SIP头域和HTTP头域在语法和语义上都比较类似。特别的，SIP头域遵循[H4.2]关于消息头的语法的定义，并且遵循多行的扩展头域的规则。(后者 is specified in HTTP with implicit whitespace and folding)。这个规范遵循RFC2234[10]，并且把清晰的空白和封装作为内在的语法规则。
[H4.2]也定义了具有相同域名的多个头域，他们的值是用逗号分开的列表，可以合并到一个头域中。这个也适用于SIP，但是细节上略有不同，因为语法不同。实际上，任何SIP的包头语法都是基于如下范式的：
header ＝ “ header-name” HCOLON header-value *(COMMA header-value)
这个允许合并在具有同一个域名的多个头域，到一个用逗号分割的单个头域中。Contact头域除了当域值是”*”之外，都允许用逗号分割的列表。
7.3.1 头域格式。
头域遵循在RFC2822的2.2节定义的通用头域格式。每一个头域都由一个域名加上冒号（”:”）和域值组成。
field-name:field-value
消息头的正则语法在25节中有介绍介绍。
在消息头中，允许在冒号的左右有任意个数的空白；但是，在实现中，建议避免域名和冒号中间有空格，并且建议在冒号和值之间使用单个空格（SP）。
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
所以，上面的都是合法的，也是相等的，但是最后一种是我们所推荐的。
头域可以扩展成为多行的，只要在每一个附加行前边用至少一个SP或者水平TAB(HT)打头就可以了。这种多行的头域在行结尾并且在下一行之前的空白SP（或者HT）将被认为是一个单个的SP字符。所以，下边的例子是相等的：
Subject: I know you’re there, pick up the phone and talk to me!
Subject: I know you’re there,
pick up the phone,
and talk to me!
头域中的不同域名的相关顺序并没有什么意义。虽然如此，我们还是强烈建议与路由相关的域（VIA,ROUTE,Record-Route,Proxy-Require,Max-Forwards,Proxy-Authorization等等）放在消息头的最前边，这样可以提高处理的速度。相同域名的域之间的顺序非常重要。只有当单个头域的域值是可以用逗号分割的列表的时候，才可以表达成为同一个域名的多个头域（这就是说，如果遵循7.3定义的语法）。也就是意味着必须可以将同一个域名的多个头域在不改变消息语义的前提下，改换表达成为一对”域名: 域值”；这个转换是通过顺序增加每一个域的域值，域值之间用逗号分割。这个规则有几个例外，就是WWW-Authenticate,Authorization,Proxy-Authenticate,和Proxy-Authorization头域。多个头域行可以在消息头中出现，但是由于他们的语法并不遵循7.3中定义的通用格式，所以，他们并不能合并成为单个头域行。
在实现上，必须能够既能够处理多个头域行的情况，也必须能够处理用逗号分割的合并的单个头域行的情况。
下边的几组头域是相等的：
Route: <sip:alice@atlanta.com>
Subject: Lunch
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Subject: Lunch
Subject: Lunch
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
<sip:carol@chicago.com>
下边各组是合法的，但是并不相等。
Route: <sip:alice@atlanta.com>
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:bob@biloxi.com>
Route: <sip:alice@atlanta.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,<sip:bob@biloxi.com>
每一个头域值的格式是依赖于它的头域名的。他可以是任意顺序的TEXT-UTF8字符，也可以是一个空格，标记，分隔符，引号括起来的字串的组合。很多头域都回附带一个通用的域值格式。这个域值格式是由分号分开的参数名和参数值的组合：
field-name: field-value *(;parameter-name=parameter-value)
虽然在域值里边可以有任意数量的parameter-name/parameter-value对，但是不能允许有相同的parameter-name存在（唯一性）。除了特别指出的头域之外，头域中的域名、域值、parameter name parameter-value都是大小写不敏感的。标记词始终是大小写不铭感的。除非有特别的指定，引号串的字符串是大小写敏感的。例如：
Contact: <sip:alice@atlanta.com>;expires=3600
和
CONTACT: <sip:alice@atlanta.com>; ExPiReS=3600
相同。
Content-Disposition: session;handling=optional
和
content-disposition: Session;HANDLING=OPTIONAL
相同。
下边的两个头域不相同：
Warning: 370 devnull “Choose a bigger pipe”
Warning: 370 devnull “CHOOSE A BIGGER PIPE”
类似资料：