1、SIP协议介绍
Internet的许多应用都需要建立和管理一个会话，会话在这里的含义是在参与者之间的数据的交换。由于考虑到参与者的实际情况，这些应用的实现往往是很复杂的：参与者可能是在代理间移动，他们可能可以有多个名字，他们中间的通讯可能是基于不同的媒介（比如文本，多媒体，视频，音频等）－有时候是多种媒介一起交互。人们创造了无数种通讯协议应用于实时的多媒体会话数据比如声音，影像，或者文本。本SIP（会话初始协议）和这些协议一样，同样允许使用Internet端点（用户代理）来寻找参与者并且允许建立一个可共享的会话描述。为了能够定位精确的会话参与者，并且也为了其他的目的，SIP允许创建基础的network hosts（叫做代理服务器），并且允许终端用户注册上去，发出会话邀请，或者发出其他请求。SIP是一个轻型的，多用途的工具，可以用来创建，修改和终止会话，它独立运作于通讯协议之下，并且不依赖建立的会话类型。
2、SIP协议功能概况
SIP是一个应用层的控制协议，可以用来建立、修改、和终止多媒体会话（或者会议）例如Internet 电话。SIP也可以邀请参与者参加已经存在的会话，比如多方会议。媒体可以在一个已经存在的会话中方便的增加（或者删除）。SIP显示的支持名字映射和重定向服务，这个用于支持个人移动业务－用户可以使用一个唯一的外部标志而不用关系他们的实际网络地点。SIP在建立和维持终止多媒体会话协议上，支持5个方面：
1. 用户定位： 检查终端用户的位置，用于通讯。
2. 用户有效性：检查用户参与会话的意愿程度。
3. 用户能力：检查媒体和媒体的参数。
4. 建立会话：”ringing”,建立会话参数在呼叫方和被叫方。
5. 会话管理：包括发送和终止会话，修改会话参数，激活服务等等。
SIP不是一个垂直集成的通讯系统。SIP可能叫做是一个部件更合适，它可以用作其他IETF协议的一个部分，用来构造完整的多媒体架构。比如，这些架构将会包含实时数据传输协议（RTP）（RFC 1889）用来传输实时的数据并且提供QoS反馈，实时流协议（RSTP）(RFC 2326)用于控制流媒体的的传输，媒体网关控制协议（MEGACO）(RFC 3015)用来控制到公共电话交换网（PSTN）的网关，还有会话描述协议（SDP）（RFC 2327）用于描述多媒体会话。因此，SIP应该和其他的协议一起工作，才能提供完整的对终端用户的服务。虽然基本的SIP协议的功能组件并不依赖于这些协议。
SIP本身并不提供服务。但是，SIP提供了一个基础，可以用来实现不同的服务。比如，SIP可以定位用户和传输一个封装好的对象到对方的当前位置。并且如果我们利用这点来通过SDP传输会话的描述，立刻，对方的用户代理可以得到这个会话的参数。如果我们用这个像传输会话描述（SESSION DESCRIPTION SD）一样呼叫方的照片，一个”呼叫ID”服务很容易就建立了。这个简单的例子说明了，SIP作为一个基础，可以在其上提供很多不同的服务。
SIP并不提供会议控制服务（比如议席控制或者投票系统），并且并没有建议会议应该则那样管理。可以通过在SIP上建立其他的会议控制协议来发起一个会议。由于SIP可以管理参与会议的各方的会话，所以会议可以跨异构的网络，SIP 并不能，也不打算提供任何形式的网络资源预留管理。
安全对于提供的服务来说特别重要。要达到理想的安全程度，SIP提供了一套安全服务，包括防止拒绝服务，认证服务（用户到用户，代理到用户），完整性保证，加密和隐私服务。
SIP可以基于IPV4也可以基于IPV6
3、术语
在这个文档中，关键词”必须”,”不允许”,”要求”,”可以”,”不可以”,”应该”,”不应该”,”建议”,”不建议”,”可能”,”可选” 是根据BCP14,RFC 2119[2]的规范描述SIP实现需要的不同层次
4、实施概览
这节通过简单的示例介绍了SIP的基本实现。本节是通过自然的而非正则的示例来介绍的。
第一个例子说明了SIP的基本功能：定位一个断点，发出通讯请求，通过协商会话参数建立会话，拆卸刚才建立的会话。
图一表示一个典型的Alice和Bob两个用户间的SIP消息交易交换例子.（每一个消息采用字母”F”和一个用来指向正文的一个数字做标记）在这个例子里，Alice在她的PC上使用一个SIP的应用程序（比如说一个软的电话），呼叫Bob在Internet上的一个SIP电话。这个例子也掩饰了两个SIP代理之间，怎样为Alice和Bob建立会话连接。This typical arrangement is often referred to as the "SIP trapezoid" as shown by the geometric shape of the dotted lines in Figure 1.
Alice 通过Bob的SIP标志 “呼叫” Bob，这个SIP标志是统一分配的资源（Uniform Resource Identifier URI）称作SIP URI。SIP URI在19.1节中定义。它很像一个email地址，典型的SIP URI包括一个用户名和一个主机名。在这个范例中，SIP URI是sip:bob@biloxi.com,biloxi.com是Bob的SIP服务提供商。Alice有一个SIP URI: sip:alice@atlanta.com。 Alice可以输入Bob的URI，也可以直接在地址本的一个超级链接上点击一下Bob的URI。SIP也提供保密URI，称作SIPS URI。例如：sips: bob@biloxi.com。 一个基于SIPS URI的通话保证这个通话是安全的，并且对呼叫者和被叫的所有的SIP消息是加密传输的（叫做TLS）。在TLS中，请求是通过加密方式传输给被叫方，但是这个加密机制是基于被叫方宿主服务器的实现的。
SIP是基于一个类似HTTP协议的请求应答的通讯模式。每一个通讯都包含对某个功能的请求，并且起码需要一个应答。在这个应答中，Alice的软电话发送一个含有Bbo的SIP URI地址的INVITE通讯请求。INVITE是一个SIP请求的例子，表示请求方（Alice）希望服务方（Bob）应答。INVTE请求包含一系列的包头域（Header fields）。包头中包含很多属性并且包含了传输消息的附加信息。在INVITE中有如下的字段：呼叫的唯一标志，目的地址，Alice的地址，Alice和Bob建立会话的类型。INVITE请求（图1中的F1）可能看起来像这样的：
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice’s SDP not shown)
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . Bob’s
softphone SIP Phone
| | | |
| INVITE F1 | | |
|---------------> | INVITE F2 | |
| 100 Trying F3 |---------------> | INVITE F4 |
|<--------------- | 100 Trying F5 |---------------> |
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<--------------- |
| 180 Ringing F8 |<--------------- | 200 OK F9 |
|<--------------- | 200 OK F10 |<--------------- |
| 200 OK F11 |<--------------- | |
|<--------------- | | |
| ACK F12 |
| -------------------------------------------------> |
| Media Session |
|<================================================> |
| BYE F13 |
| <------------------------------------------------- |
| 200 OK F14 |
| -------------------------------------------------> |
| |
图一：SIP矩形表达的SIP会话建立例子。
在文本消息的第一行，包含了请求的类型（INVITE）。在这行之后的是这个请求的头域。这个例子中包含了最少需要的头域集合。简单介绍一下：
VIA域包含了Alice接收发送请求的服务器地址（pc33.atlanta.com）。同样这个包含了一个分支参数来标志Alice和这个服务器的会话事务。
TO域包含了显示姓名（Bob）和一个SIP或者SIPS URI（sip：bob@biloxi.com）请求将首先传输到这个URI中。显示姓名（Display names）在RFC 2822中描述。
From域也同样包含一个显示姓名（Alice）和一个SIP或者SIPS URI（sip:alice@atlanta.com）这个URI用来标志请求的原始发起者。
这个域也包含了一个TAG参数，这个TAG参数是一个随机字串（1928301774），是软电话（softphone）在URI上增加的一个随机串。用来做标志用途的。
Call_ID包含一个全局的唯一标志，用来唯一标志这个呼叫，通过随机字串和softphone的自己名字或者IP地址混和产生的。通过TO TAG, FROM TAG和CALL-ID完整定义了Alice和Bob之间的端到端的SIP关系，并且表示这个是一个对话性质的关系。
CSEQ或者Command Sequence包含了一个整数和一个请求名字。这个Cseq数字是顺序递增的。每当对话中发起一个新的请求都会引起这个数字的顺序递增。
Contact域包含一个SIP或者SIPS URI用来表示访问Alice的直接方式，通常由用户名和一个主机的全名（Fully Qualified Domain Name FQDN）组成。当FQDN作为首选的时候，许多终端用户由于不会由名字登记（而导致不能访问Alice的主机），所以IP地址是可选的。
VIA域告诉大家本请求发送到哪里并且应答到哪里，Contract域告诉大家将来的请求将发送到哪里（奇怪…不是Alice发起的么，将来的请求应该是Bob才对啊）。
Max-Forwards:最大转发数量限制了通讯中转发的数量。它是由一个整数组成，每转发一次，整数减一。
Content-type包含了消息正文的描述（消息正文在本范例中没有列出）
Content-length:包含消息正文的长度（字节数）
完整的SIP包头域的定义在20节。会话的细节，比如媒体的类型，codec，或者采样速率，没有通过SIP来描述。这个可以通过SIP的消息正文来描述，可以通过其他定义的协议在正文中进行描述。有一种是会话描述协议（Session Description Protocol SDP）（RFC2327[1]）。这个SDP消息（没有在例子中列出）通过SIP的消息中传送，就像通过附件发送EMAIL一样，或者说通过HTTP传输的网页一样。
由于softphone并不知道bob或者bob的sip服务器biloxi.com在哪里，所以softphone发送INVITE请求到Alice的sip服务器,atlanta.com。这个atlanta.com SIP服务器应该已经在Alice的softphone中配置了，或者可以通过DHCP获得。atlanta.com SIP服务器是一台代理服务器。代理服务器接收SIP请求并且根据请求转发。在这个例子中，代理服务器接收到INVITE请求，并且回送一个100（Trying）应答给Alice的softphone。100（Trying）应答表示INVITE请求已经收到，并且代理服务器正在转发INVITE请求。SIP的应答是通过一个三位数的数字表示的。SIP应答同样包含TO、FROM、Call-ID，CSEQ和在VIA中的分支参数，这个参数使得Alice的softphone可以把请求和应答关联起来。atlanta.com代理服务器收到INVITE请求之后，就去找biloxi.com可能通过DNS服务来找提供这个biloxi.com的SIP服务器。这在[4]中有描述。最后，转发INVITE请求到biloxi.com或者能到达biloxi.com的代理服务器。在转发请求之前，atlanta.com代理服务器会在via头上增加一个一段包含自己地址的值（INVITE已经包含了Alice的的地址VIA域）。biloxi.com代理服务器收到这个INVITE请求并且返回一个100（Trying）应答给atlanta.com代理服务器标志这它已经收到这个请求并且正在处理这个请求。这个代理服务器通过查询数据库，通常叫做地址服务，这个服务中包含了bob的当前ip地址。（我们在下一节可以看到这个数据库是怎么回事）biloxi.com代理服务增加另一段包含自己地址的VIA头域并且发送它到bob的sip 电话。
Bob的SIP电话接收到INVITE请求并且提醒bob有一个从Alice的呼入，这样bob可以决定是否响应这个呼入。这个意思就是：bob的电话响了。bob的sip电话发送一个180（Ringing）回应，这个回应将通过两个代理服务器原路返回给Alice。每一个代理服务器通过via头域决定该把这个应答发送给哪里，并且在发送之前把自己的地址从头上拿走。虽然DNS和定位服务在路由最初的INVITE请求，180（ringing）响应可以简单返回给发起者而不需要查找发起者在哪里，并且不需要在代理服务器保留状态，同时，每一个转发INVITE的代理也可以得到INVITE的每一个应答，这样的特性也非常有用。
当Alice的softphone收到180（Ringing）应答的时候，它提示Alice,可能是通过一个回铃音，或者屏幕上的一个消息提示。
在这个例子中，Bob决定响应这个呼叫。当他拿起电话，他的SIP电话发送200（OK）回应给发送者，表示这个电话已经接起来了。这个200（OK）包含了一个消息体，这个消息体包含SDP媒体描述，这个媒体描述包含Bob希望和Alice建立何种媒体连接。同样，SDP消息也是两段交换：Alice发送一个给Bob，Bob发送一个回给Alice。这个两段的交换提供基本的兼容性协商，并且基于简单的SDP提出/应答交换模型。如果Bob不想响应这个呼叫或者正在响应别的呼叫，一个错误的响应会代替正常的200（OK）回送出去，这样，就不会有连接建立。SIP完整的返回代码在21节有介绍。Bob发出的200（OK）（图一的F9消息）可能长得像这样的：
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob’s SDP not shown)
应答的第一行包含了应答代码（200）和原因（ok）。剩下的行包含了包头域。VIA,TO,FROM,CALL-ID,Cseq包头域是从INVITE请求包中直接拷贝过来的。（有三个VIA域值－一个是Alice SIP电话增加的，一个是atlanta.com代理加的，一个是biloxi.com代理加的）。Bob的SIP电话增加了一个TAG参数。这个TAG参数会被参与对话的各方所使用，并且在以后的对话中被使用。Contract域包含了一个能直接联系到Bob的URI。Content-type和Content-Length域包含了消息体（没有在例子中体现），这个消息体里边是Bob的SDP媒体信息。
除了DNS和位置服务之外，代理服务器可以自主决定路由，也就是说自己决定应该向哪里转发请求。比如，如果Bob的SIP电话返回一个486（电话正忙）信号，biloxi.com这个代理服务器可以转发这个INVITE请求到Bob的语音邮箱服务器。一个代理服务器可以同时向N个地方发送INVITE请求。这种并发寻找就是传说中的分流（forking）。
在这个例子中，200（OK）应答通过两个代理并且发送到Alice的softphone上，Alice的softphone收到这个应答，停止振铃，并且标志电话Bob已经接听。最后，Alice的电话发送一个确认消息，ACK，到Bob的SIP电话来确认接收到了这个最后的200（OK）应答。在这个例子中，ACK信号是直接由Alice的softphone发送到Bob的SIP phone上，跨过了两个代理服务器。这是因为两个端点（Alice和Bob）通过INVITE/200(OK)的请求应答包中的Contact包头域都知道互相之间的地址了，这个地址是最开始发起INVITE请求的时候所不知道的。所以，不需要两个代理服务器再查找对方的地址了，所以代理服务器不参与接下来的通话流了。这就完成了一个完整的使用INVITE/200/ACK 三方握手来建立SIP会话的过程。会话建立过程中的细节描述再13节由描述。
现在，Alice和Bob的媒体会话开始了，他们通过发送刚才建立会话所交换的SDP包中约定的互相明白的媒体包来进行会话。一般情况下，端到端的媒体包和SIP信号控制包通过不同的通讯路径来发送。
在会话中，Alice或者Bob都可以改变他们自己的媒体会话属性。这个可以通过发送一个包含新媒体属性描述的re-INVITE请求来完成。这个re-INVITE是捆绑在一个现有的会话的，这样参与会话的对方可以明白这是要改变现有的会话属性而不是新建立一个会话。对方收到这个re-INVITE请求后，会发送一个200（OK）应答表示接受这个改变。请求方通过一个ACK来表示接受了对方的这个200(OK)应答。如果对方不同意这个媒体属性变化，他会发送一个错误的应答比如488（暂时不能进行），这个也会收到发起者的一个ACK响应。不管怎样，就是是re-INVITE的失败也不会影响到现有的会话－原有的会话还可以用上次的媒体会话属性继续。可以在14节找到会话属性更改的细节说明。
在通话结束的时候，Bob首先断开（挂机hangs up），并且发送一个BYE的消息。这个BYE的消息将直接送到Alice的softphone，同样是跳过代理的。Alice通过发送200（OK）应答来确认收到了这个BYE消息，这个消息终止了会话并且应答了BYE的请求。ACK在这里不需要发送－一个ACK信号只在响应一个INVITE的响应的时候被发送。我们稍晚一点会讨论这个INVITE的特别处理，但是基于SIP的可靠性的机制，一个通话的时间可以认为包含电话振铃和挂机的时间（but relate to the reliability mechanisms in SIP, the length of time it can take for a ringing phone to be answered, and forking.）基于这样的原因，SIP请求的处理通常根据是否INVITE请求进行分类，INVITE类和非INVITE类请求分开处理。结束会话的细节可以在15节查到。
24.2节描述了图1中使用的全部消息详细解释。在某些情况下，所有会话中的包都继续通过代理转发会很有用。比如，如果biloxi.com代理服务器希望在INVITE之后继续保持SIP消息流，他会在INVITE中增加一个头域（Record-Route）包含一个URI指向这个代理服务器的hostname或者IP地址。这个消息会被Bob的SIP电话和Alice的softphone所接到（因为Record-Route头域将在200(OK)应答中被送回），并且在会话中一直保存。那么biloxi.com代理服务器就可以继续接收和转发ACK,BYE,给BYE的200（OK）应答。每一个代理都可以单独决定是否接收INVITE以后的后续消息，并且这些后续消息都可以被发送到那些决定接收后续消息的代理服务器。这种情况通常发生在提供mid-call业务的代理服务器上。
登记服务是另一个常用的SIP操作。登记服务是biloxi.com代理服务器知道Bob当前地址的一个方法。在初始化的时候，或者每隔一段时间，Bob的SIP 电话发送REGISTER消息给biloxi.com的一个注册服务器。REGISTER消息包含了Bob当前登陆服务器的SIP或者SIPS的URI（sip:bob@biloxi.com）（转换成为Contact域中的SIP或者SIPS URI）。登记服务器登记这个映射，这个叫做绑定（binding），写到一个数据库里边，叫做定位服务（location service），这个数据库可以被biloxi.com的代理服务器使用。通常登记服务器和代理服务器是做在一起的。一个很重要的概念就是SIP服务器的差别在逻辑上，并非在物理上的差别。
Bob并没有限定非得在一个单个设备上发起注册。比如，他家里的SIP电话和公司的SIP电话都可以注册。这些消息在定位服务（location service）中保存，并且允许代理服务器通过不同的手段查找Bob。同样的，不同的用户也可以在同一个设备上同时注册。
定位服务（location service）是一个逻辑概念。他是让代理服务通过输入一个URI来查询到底应该向哪里转发请求。可以简单通过用户注册来建立这个定位服务所需要的资料，也可以通过其他方法。可以通过其他任意的地址映射方式来实现定位服务。
最后在SIP中需要注意的是，注册服务只是用来提供路由收到的SIP请求的，它并不做请求的身份认证的判定。在SIP中授权和认证可以通过建立在基于请求/应答的模式上的上下文相关的请求来实现，也可以使用更底层的方式来实现（具体在26节有描述）。
完整的注册SIP消息描述例子在24.1节。
其他SIP的操作，比如检查SIP服务器的负载，或者使用客户端使用可选项（OPTIONS），或者用CANCEL取消一个未决的请求，在后续的章节中会介绍。
5、协议的结构
SIP是一个分层的协议，意思是说SIP协议由一组相当无关的处理层次组成，这些层次之间只有松散的关系。协议分成不同层次来描述是为了能够更清晰的表达，在同一个小节里有功能的公共要素的交叉描述。本协议并没有规定一个具体的实现。当我们说一个要素”包含”某一个层，我们的意思是这个要素复核这个层定义的规则。
不是SIP每一个要素都一定包含每一个层。此外，SIP定义的要素是逻辑上的要素，不是物理要素。一个物理的实现可以实现不同的逻辑要素，或许甚至是基于串行事务处理原理。SIP最底层的是它的语法和编码层。编码方式是采用扩展的Backus-Naur Form grammar(BNF范式)。完整的BNF描述在25节；第7节有简要的SIP消息结构描述。
第二层是传输层。它定义了一个客户端如何发送请求和接收应答，以及一个服务器如何接收请求和发送应答。所有的SIP要素都包含一个通讯层。第18节有通讯层的描述。
第三层是事务层。事务是SIP的基本组成部分。一个事务是客户发送的一个请求事务（通过通讯层）发送到一个服务器事务，连同服务器事务的所有的该请求的应答发送回客户端事务。事务层处理应用服务层的重发，匹配请求的应答，以及应用服务层的超时。任何一个用户代理客户端（user agent client UAC）完成的事情都是由一组事务构成的。有关事务的讨论在第17节有描述。用户代理包含一个事务层，来实现有状态的代理服务器。无状态的代理服务器并不包含事务层。事务层包含一个客户元素（可以认为是一个客户事务）和一个服务器元素（可以认为是一个服务器事务），他们都可以用一个有限状态机来处理特定的请求。
在事务层之上是事务用户（TU）。每一个SIP实体，除了无状态代理，都是一个事务用户。当一个TU发出一个请求，它首先创建一个客户事务实例（client transaction instance）并且和请求一起发送，这包括了目标IP地址、端口号、以及发送请求的设备。TU可以创建客户事务，也可以取消客户事务。当客户取消一个事务，它请求服务器终止正在处理的事务，并且回滚状态到该事务开始前的状态，并且产生指定的该事务的错误报告。这是由CANCEL请求完成的，这个请求有自己的事务，并且包含一个被取消的事务（第9节）。
SIP要素，包含，用户代理客户端和服务器，无状态和有状态代理服务器和注册服务器，包含一个可以互相区别的核心（Cores）。Cores，除了无状态代理服务器，都是事务用户。UAC(用户代理客户端)和UAS(用户代理服务端)的cores的行为依赖于实现，对所有的实现来说，有几个公共的原则（第8节）。对UAC来说，这些规则约束请求的建立；对UAS来说，这些规则约束请求的处理和应答。由于注册服务在SIP中是一个重要的角色，所以UAS处理REGISTER请求有一个特别的名字：登记员（registrar，登记服务器）。第10节描述了UAC和UAS的对REGISTER实现的core（核心）行为。第11节描述了OPTIONS的UAC和UAS的core实现，这个OPTIONS用来检测UA的处理能力的（UA-user agent）。
在对话中，有其他的相关会被发送。一个对话是一个持续一定时间的两个用户之间的端到端的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 Reason-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”
7.3.2 头域分类。
有一些头域是仅仅在请求（或者应答）中有效的。这些头域叫做请求头域或者应答头域。如果消息中的头域与这个消息的类型不匹配（比如在应答消息中出现的请求头域），这个头域必须被忽略。20节定义了每一个头域的分类。
7.3.3 缩写格式
SIP提供了一个用缩写格式来表达通用头域名字的机制。这个有助于避免消息过大而导致通讯层无法传输（比如在UDP传输的时候超过了最大传输单元(MTU)）。这个缩写格式在20节定义。
缩写格式的消息头域名字可以在不改变消息语义的情况下替代较大的消息头域名字。在单个消息中，头域名字既可以用长的格式，也可以用缩写格式。在实现中，必须同时支持对长名字和缩写名字的处理。
7.4包体
请求信息，包括这个规范以后的扩展的新请求，都可以包含一个消息正文体。对消息正文体的解释依赖域请求的方法（请求类型）。对于应答消息来说，请求方法和应答状态（response status code）决定了消息正文体的格式。所有的应答消息都可以有一个消息正文体（body）。
7.4.1 消息正文类型(MessageBodyType)
消息中的internet媒体类别必须在Content-Type头域中指明。如果消息正文（body）通过某种形式的编码（encoding），比如压缩等等，都必须在Content-Encoding 头域中指明，否则Content-Encoding域必须忽略。如果可行，消息体的字符集作为Content-type头域的值的一部分表达。
在RFC2046[11]中定义的多部分”multipart” MIME类型可以在消息体中应用。在由多部分组成的消息体发送的时候，如果接受方的实现中，包头域的Accept域中，不包含多部分的标记，那么发送方必须发送一个非多部分的session description。
SIP消息可以包含二进制的包体或者部分包体。如果发送方没有其他显示的字符集参数指出，媒体的文本”text”子类型会是缺省的字符集”UTF-8”。
7.4.2 消息体长度
在Content-Length头域中存放了包体的字节长度。第20.14节讲述了本域的详细解释。
HTTP/1.1的“chunked”传输编码方式并不适用于SIP。（备注：chuncked编码传输方式是通过把消息正文体分为一系列的块来传输的，每一块有它自己的大小标记）
7.5 分帧的SIP消息（Framing SIP Messages）
不同于HTTP的是，SIP实现可以使用UDP或者其他非可靠传输协议。每一帧包括一个请求或者应答。第18节讲述了非可靠传输的应用。
在处理以面向流的通讯为基础的SIP消息的时候，必须忽略在开始行之前的CRLF[H4.1]。
Content-Length头域用来确定每一个SIP消息在通讯流中的结束位置的。在基于面向流通讯基础上的SIP消息一定要使用这个头域。
8 一般用户代理行为
一个用户代理代表了一个终端系统。它包含一个用户代理客户端（UAC）,用来产生请求的，它包含一个用户代理服务端（UAS），用来响应请求的。UAC可以由一些外部的东西来发出请求和处理应答（比如用户按了一个按钮，或者按下了一个电话键产生了一个音频信号等等）。UAS是一个能够接收请求，并且产生应答的东西，它可以根据用户输入，外部输入，程序执行结果或者其他什么机制来产生应答。
当一个UAC发送一个请求，这些请求可能通过一些PROXY（代理服务器）传递到UAS上。当UAS产生一个应答，那么这个应答就会同样的被传送到UAC。UAC和UAS的处理由两个特点。第一，基于请求或者应答是否在一个对话里，第二，基于请求的方法（method）。会话的彻底描述在第12节；哪里描述了点对点的用户代理之间的关系，并且通过一些SIP方法建立了会话，比如INVITE方法等。
在本节，我们将讨论在处理对话外的请求时，UAC和UAS的方法无关的规则。这些当然也包括用于建立会话的请求。在26节讲述了对在对话外的请求和应答的安全处理。特别时，UAS和UAC之间的互相认证的机制。通过用S/MIME加密的消息体可以提供有限的隐私保证。
8.1 UAC特性
本节讲述UAC在会话外的特性。
8.1.1 产生一个请求
一个合法的SIP请求必须至少包含如下头域：TO,FROM,Cseq,Call-ID,Max-Forwards, Via;这些字段在所有SIP请求中必须包含。这6个字段是SIP消息的基本组成部分，他们提供了用于路由用的核心信息，包含了消息的地址，响应的路由，消息传递次数，详细的顺序，事务的唯一标志。
这些头域字段是必须包含在请求行之后的，请求行包含了请求的方法，Request-URI,SIP的版本号码。
有两个在对话外的发送请求的示例（通过INVITE请求建立连接，第13节），（通过OPTIONS请求查询负载，第11节）。
8.1.1.1 Request-URI
最开始的Request-URI头域应该是TO头域的的值。但是在REGISTER方法中，有一个值得注意的不同；REGISTER方法的Request-URI头域在第10节中指出。出于隐私的原因而把这些字段的值设置成为同一个值并不太合适（尤其是如果初始的UA期望Request-URI会在传输中改变的话）。
在一些特定的情况下，预先设置的路由表（route-set）会影响消息中的Request-URI。一个预置路由表是由一串server的URI组成，这些服务器是UAC往外发送会话外请求所需要经过的。通常，他们是由用户或者服务提供商手工在UA上设置的，或者通过一些非SIP的方法自动设置。当一个提供商希望配置一个出口proxy给一个UA，我们强烈建议通过一个预置一个单个URI路由表的方式来实现，这个单个路由就是出口proxy。
当要使用预置路由表(route set)，必须提供Request-URI和Route头域（在12.2.1.1节中有详细描述）（甚至在没有对话存在的时候也必须提供），并且把Request-URI当作远端目标URI。
8.1.1.2 TO
To头域是第一个并且也是最先指定请求的”逻辑”接收地，或者是这个请求的用户或者资源的address-of-record。这个域内的地址可以是也可以不是请求的最终接收者。TO头域可以用SIP或者SIPS URI,也可以用其他方式的URI(比如电话URL (RFC2806[9]))。所有的SIP实现必须支持SIP URI的实现。任何支持TLS的实现必须支持SIPS URI的实现。
To头域允许有一个显示用的姓名。
UAC可以通过无数的方法来知道在一个给定请求的时候该如何填写TO头域。通常用户会建议采用人工界面中输入的To头域，可能手工输入这个URI或者从地址本中选择（就好像outlook邮件中的to一样）。用户通常不会输入完整的URI,可能只是一个简单的字串（比如”bob”）。这就要求UA能够判断用户输入的这个到底是那个URI。一般使用用户输入的字串加上”@”标志和主机的名字组合成为SIP URI(比如sip:bob@example.com)。如果希望通讯在保密机制下进行，那么就用用户输入的字串组成SIPS URI的部分，用户输入的将加上”@”和主机的名字作为整个SIPS URI。这个主机的名字通常是请求方的主机名字，这个主机允许处理外发请求。这个很像”缩位拨号”的机制，这个机制要求请求者自身的主机能够解释这个缩位拨号一样。
如果UA不希望指定主机，那么就需要将用户输入的电话号码解释成为一个电话的URL。相当于，每一个请求经过的主机都会有机会来处理这个请求。比如，一个用户在机场可能登陆机场的代理服务器，并且通过机场的代理服务器发出一个请求。如果他输入”411”(美国本地电话本查询服务号码)，这个就需要机场的外发的代理服务器进行解释和处理，而不是解释成有主机的用户。在这里，tel:411是一个正确的解释。
在会话外的请求中，不能包含To tag字段，在to头域中的tag是用来在对话中做标志的。既然对话还没有建立，那么tag就不能存在。
20.39节有进一步的描述。
下边这个例子是一个To头域的例子：
To: Carol <sip:carol@chicago.com>
8.1.1.3 From
From头域包含了请求发起者的逻辑标志，可能是用户的address-of-record。就像To头域一样，From头域也包含一个URI并且可以包含一个显示的姓名。SIP可以用这个头域来实现对请求的检查和选择一个规则进行对请求的处理（比如，自动的呼叫拒绝，凡是x人发过来的东西，一律无视）。同样的，因为From头域包含的是逻辑名字，所以From URI也可以不包含IP地址或者UA对应的主机名字FQDN。
From头域可以包含一个显示姓名。在客户身份隐藏的情况下，一个UAC应该使用显示名字”Anonymous”，连通一个语法正确，但是没有意义的URI(比如：sip:thisis@anonymous.invalid)。通常，用户或者用户的本地主机的管理人员会事先规定请求头域中的From头域的值。如果给定的UA是多个用户共同使用的，那么必须有一个URI对应身份的profile，这样才能够切用户的profile。收到请求的服务方可以根据这个用于分辩身份的URI来区分同一个UA上的不同的用户，并且根据他们的From头域来判定他们的身份。（22节有更多的验证说明）。
From域必须包含一个由UAC产生的新的”tag”参数。19.3节有tag的详细描述。20.20节有更深入的资料。
例子：
From: “Bob” <sips:bob@biloxi.com> ; tag=a48s
From: sip:+12125551212@phone2net.com;tag=887s
From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
8.1.1.4 Call-ID
Call-ID是一个在一系列消息中，区分一组消息的唯一标志。在对话中的任一UA的所有请求和所有应答的Call-ID必须一致。在UA的每次注册中，都应该是一样的。在会话外的时候，UAC发起一个新的请求，这个Call-ID头域必须由UAC产生一个全局（在时间和空间上都是）唯一的Call-ID, 除非是请求头的方法（method）指明了别的产生方式。所有的SIP UA都必须保证自己产生的Call-ID不会和其他UA产生的Call-ID重复。注意，如果是请求的重新尝试，则重新尝试的请求不被当作一个新的请求，所以不需要新的Call-ID（重新尝试的请求例如：认证冲突等等）。（见8.1.3.5）
我们强烈建议用密码乱序随机串（RFC 1750[12]）来产生Call-ID。实现中，可以用类似”localid@host”这样的格式产生。Call-ID是大小写敏感的，并且通过简单字节/字节的来进行比较。
采用密码乱序随机串可以降低会话被窃听的机会，并且降低Call-ID重复的冲突。不规定或者要求使用用户界面来选择输入Call-ID头域的值。参见20.8节。
例子：
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
8.1.1.5 Cseq
Cseq 头域是用来区分和做位事务的顺序使用的。他由一个方法（method）和一系列的顺序号码组成。方法（method）必须和请求的方法一致。对于对话外的非REGISTER请求来说，顺序号码可以是任意的。这个顺序号码必须可以由32位的无符号整数表达，必须小于2^31。只要遵循了上述指导方针，客户端可以用任意的方法来产生这个Cseq头域。12.2.1.1节讲述了在对话中如何创建Cseq
例子：
Cseq: 4711 INVITE
8.1.1.6 Max-Forwards
Max-Forwards头域用来限制请求到他的目的地中间的跳转。它包含一个每隔一个跳转就自动减一的数字。如果Max-Forwards在到达目的之前就减到0，他会报告一个483(太多的路由)错误回应。
一个UAC必须为每一个请求填写一个Max-Forwards头域，这个字段的缺省值应该是70。这个数字是保证了请求在没有环路的SIP网络中都能够送达，也保证了在有环路的时候，尽量少消耗proxy的资源。如果这个数字要变小，则必须保证UA知道整个网络的拓扑结构。
8.1.1.7 Via
Via头域是标志了用于事务传输的传输设备，并且也标志了应答送回的地址。只有当需要通过选择传输设备到达下一个节点(hop)的时候，才需要在头域中包含Via域。当UAC创建一个请求，它必须在头域中添加一个Via域。protocol 名字和protocol版本必须分别是SIP和2.0。Via头域必须包含一个分支(branch)参数。这个参数用于区分请求创建的事务。这个参数客户端和服务器都会使用。除了CANCEL和给非2xx应答的ACK以外，branch参数对UA发出的所有的请求来说，在时间和空间上必须唯一。在下边的讲解中，CANCEL请求的branch参数必须和他所取消的请求的branch参数一致。在17.1.1.3节中讲述了给非2xxx（non－2xx）应答的ACK必须和其对应的的INVITE请求有相同的branch ID。
利用branch ID参数的唯一性来作为事务的ID（transaction ID）,并非RFC 2543的一部分。根据本标准产生的branch ID必须用”z9h64bK”开头。这7个字母是一个乱数cookie（定义成为7位的是为了保证旧版本的RFC2543实现不会产生这样的值），这样服务器收到请求之后，可以很方便的知道这个branch ID是否由本规范所产生的（就是说，全局唯一的）。在这样的要求下，精确的branch ID的格式必须事先有实现的定义。
Via头域中，maddr,ttl,和sent-by字段会在transport层处理请求的时候设置（18节）。Via在proxy的处理在16.6节8段和16.7节3段描述。
8.1.1.8 Contact
Contact头域提供了访问后续请求的特定UA实例的联系方法：SIP或者SIPS URI。在任何会建立一个对话的请求中，Contact头域必须提供和包含一个SIP或者SIPS URI。在这个规范中定义的方法中，只有INVITE请求会建立一个会话。对这些请求来说，Contact的作用域是全局性的。这就是说，Contact头域中包含的URI是UA能够接收请求的，这个URI必须是有效的，甚至在对话外的请求中的Contact头域中的URI也必须是有效的。
如果Request-URI或者头上的Route头域包含了SIPS URI,Contact头域也必须是一个SIPS URI。在20.10节有更进一步的说明。
8.1.1.9 Supported 和 Require
如果UAC支持服务端响应请求的SIP扩展，UAC应该在请求的时候包含一个Supported头域说明options tags（19.2节）描述那些SIP扩展。option tags中出现的扩展说明必须是遵循RFCs的标准扩展说明。这样可以防止服务端支持非标准的客户端扩展实现。在Support头域中的对于SIP扩展定义中，严格遵守不支持试验性质的或者说明性质的RFCs扩展，这个也是由于这些扩展是描述提供商定义的扩展说明。如果UAC要求UAS能够支持扩展，以便UAS能够处理UAC的特定请求，那么它必须在请求头中增加一个Require头域来说明处理本特定请求需要什么样的一个扩展option tags。如果UAC需要请求经过的所有proxy都支持它发出的某个请求的扩展部分，它必须增加一个Proxy-Require头域来说明需要Proxy支持何种option tag扩展。
如同在Supported头域指出的，Require和Proxy-Require头域中的option字段必须限定于RFCs的标准扩展。
8.1.1.10 附加信息部分
在一个新请求创建以后，以上的头域都被正确初始化了以后，就可以位这个请求增加它所需要的附加头域了。SIP请求允许包含一个MIME-encoded消息正文。无论请求包含哪种消息正文，都必须引入头域来指出这个正文的类型，以及这个正文的一些其他说明。关于这些头域的详细说明，请参见20.11节到20.15节。
8.1.2 发送一个请求
于是，我们就开始查找请求发送的目标。除非有其他的特定说明，目标必须是通过DNS来查找的（参见[4]说明）。如果路由表(route set)中的第一个元素表明这是一个严格路由（strict router,在12.2.1.1节中讲述），那么这些过程必须在请求的Request-URI中说明。否则，这些过程在请求中被应用于第一个Route头域中（如果存在），或者在请求的Request-URI中（如果Route头域不存在）。这样一些过程产生了一系列的地址，端口，和用于传输的传输器。无论那个URI用在这个[4]中描述的过程的输入，如果Request-URI指明了SIPS，那么UAC必须按照[4]中描述的说明来认为输入的URI是SIPS的URI。
本地策略可以指定一套额外的目的地用于发送。如果Request-URI包含一个SIPS URI,任何额外的目的地都必须用TLS来表达。除此之外，如果请求没有包含Route头域，那么就没有对额外的目的地有什么其他的限制了。这个就提供了一个简单的外发（outbound）proxy的事前路由的选择。但是，用这样的方法配置一个外发proxy是不推荐的；应该由单个UPI规定的预先设定的路由集来指定外发proxy。如果请求包含了Route头域，请求应该发送到Route头域最上边的一个位置，但是请求也可能被发给由本文档约定的Route或者Request-URI所指定的服务器(同RFC2543定义的相反)。特别的，一个配置了外发proxy的UAC应该首先尝试把请求发送给由第一个Route头域值指定的位置，而不是采用把所有消息都发给外发proxy的策略。这就保证了外发的proxy通过不增加Record-Route头域而不参与后续请求的路径。这个也允许让不能分析第一个Route URI的终端，把请求交给外发proxy来发送。UAC应该遵循[4]中定义的过程来实现有状态的元素，尝试每一个地址直到连接到一个服务器。每一个尝试都是一个事务，因此，每一个都有一个不同的Via头域值和一个新的branch参数值。
此外，在Via头域中的transport的值被设置成为要到目标服务器所必须的transport。
8.1.3 处理应答
应答首先是被transport层处理，并且被transport层发送给上一层transaction层处理。transaction层处理完成之后将应答发送给更上一层TU处理。在TU层进行的对应答的主要处理是方法相关的。但是也有集中通用的处理原则：
8.1.3.1: transaction 层的错误
在某些情况下，从transaction层返回的应答不一定是一个SIP消息，而是一个transaction层的错误。当从transaction层收到一个timeout错误的时候，必须将这个timeout错误当作是收到了一个状态码是408（请求timeout）的应答。如果transport层报告了一个严重错误（通常取决于UDP传输中的严重的ICMP错误，或者是TCP连接中的错误），必须把这个错误当作是状态码503（服务未提供）的错误。
8.1.3.2 未知的应答
UAC必须把自己不认识的所有最终应答当作是x00的那类应答，当然UAC也必须能够处理所有的类别应答的x00的应答。比如，如果UAC收到了不认识的应答代码431，他可以很安全的假设在他发出的请求中有什么地方弄错了，并且可以很简单的把这个应答错误当作是接收到了一个应答代码是400（非法请求）的错误应答。并且，UAC必须能够处理所有的不认识的非终结应答响应当作是183(session progress)。一个UAC必须能够处理100和183应答。
8.1.3.3 Vias
如果在应答中，有不只一个Via头域值存在，那么UAC应该丢弃这个消息。包含超过一个Via头域值的消息是因为被错误的路由或者消息被破坏。
8.1.3.4 处理3xx应答
由于接收到一个重定向的应答（比如，状态码是301的应答），客户端应该用在Contact头域中的URI(s)来组织一个或者多个基于重定向以后的新请求，这个处理过程同proxy处理一个3xx类别的应答很类似，相关资料在16.5节和16.6节中有描述。客户发起请求的时候只有一个目标URI，就是原始请求中的Request-URI。如果客户端想在这个请求基础上重构一个基于3xx类别应答的新请求，那么就需要把这个需要尝试的URIs放到目标集合中去。基于本规范的规定，一个客户端可以选择放置那个Contact URIs到目标集合中（target set）。同proxy会递归一样，客户端处理3xx应答的时候必须不能重复添加任何URI到target set。如果原始请求的Request-URI头域中包含了一个SIPS URI，那么客户端可以选择改乘一个非SIPS URI，但是需要知会客户转发到一个非安全的URI去。任何新的请求都可能导致接收到这些请求的3xx应答，并且在Contact中包含原始的URI。可以通过对两个位置的配置来形成互相重定向。只要保证在target set中任何URI都只出现1次就能避免无穷的重定向循环。当target set增长了，客户端可
小虎 2006-05-25 00:04
以对这个URIs，用任意顺序来产生新的请求。常见机制是通过在Contact头域的值中设置”q”参数来指定这个顺序。对这些URIs的请求可以是并行产生的也可以是串行产生的。有一个实现是按照q参数值递减的方法顺序处理URIs，并且对相同q参数值的URIs进行并行处理。还有一种就是直接按照顺序的方法处理URIs，对于q参数值不同的按照递减的顺序处理，对于q参数值相同的按照随机顺序处理。
如果发送给连接表上的地址失败了，（在下一段我们有定义），那么就选择列表中的下一个地址进行发送，直到列表全部遍历一遍。如果列表遍历完了还没有，那么请求就失败了。
通过响应码（大于399）我们可以知道请求的失败；对于网络错误来说，客户transaction会给transaciton user报告transport层的通讯错误错误。注意有一部分响应码（8.1.3.5）表示请求可以被重试；这个时候，请求可以重发而不是简单的当作一个错误。如果某个contact地址发送失败，那么client应该尝试下一个contact地址。这个会导致创建一个新的客户事务来处理这个新的请求。
为了在处理3xx应答中创建一个基于一个contact地址的请求，UAC必须首先从target set中拷贝除了”method-param”和”header”URI参数之外的整个URI到Request-URI（见参数的定义见19.1.1）。通过使用”header”参数来创建新请求的头域值，按照19.1.5节的指引，根据重定向的请求来重写头域的值。
注意在某些情况下，在contact地址中进行通讯所需要的头域，可能代替添加到现有的在原始转发的请求的请求头域中。作为通用的规则，如果头域可以接受用逗号分割的值列表，那么新的头域值可以添加到原始转发的请求的任何值后边。如果请求头域不接收多值列表，那么原始转发请求中的头域值可以由contact地址中进行通讯所需要的头域的值所替换。比如，如果contract地址返回了如下的值：
sip:user@host?Subject=foo&Call-Info=Http://www.foo.com
那么在原始转发请求中的任何Subject头域都被重写，但是HTTP URL仅仅添加到现存的Call-info 头域值中。
我们推荐UAC重用与原始转发请求相同的To,From,和Call-ID域值，但是也允许UAC为新的请求改变Call-ID头域。
最后，当一个新的请求构造好以后，这个请求将通过一个新的客户transaction发送，应此在最开始的Via头域中必须有一个新的branch ID （8.1.1.7节说明）
在其他的方面，转发的请求应该重用原始请求的头域和消息体。
在某些情况下，Contact头域的值可能在UAC中暂时或者永久保存，这个依赖于接收到的请求码和过期的时间；参见21.3.2和21.3.3节。
8.1.3.5 处理4xx应答
某个4xx应答码要求特定的UA处理，和请求的方法无关。
当接收到401（未授权）或者407（Proxy认证需要）应答的时候，UAC应该遵循在22.2和22.3中规定的认证步骤，重新发送带认证信息的请求。
当收到413（请求过大）应答的时候（21.4.11节），这说明请求包含了一个UAS所不能接收长度的消息体。如果可能，UAC应该尝试重新retry这个请求，或者去掉包体或者换一个小一点的长度。
如果收到了一个415（不支持的媒体类型）应答（21.4.13节），那么请求中包含的媒体类别是UAS所不支持的。UAC应该重发这个请求，并且这次发出的请求只包含应答中的Accept头域所指明的媒体类别，并且采用Accept-Encoding头域中指明的encoding方法，还有Accept-Language指明的语言。
如果收到了一个416（不支持的URI Scheme）应答（21.4.14节），Request-URI使用的URI Scheme（方案）是服务端所不支持的。客户端应该重新尝试这个请求，并且换用SIP URI。
如果收到了一个420（非法扩展）应答（21.4.15节），请求的Require或者Proxy-Require头域包含的option-tag中包含了UAS或者proxy不支持的特性。UAC应该尝试去掉应答中的Unsupported头域中列出的扩展以后然后再尝试。
在上述所有的情况中，所有需要重试的请求，都需要经过适当修正成为一个新的请求。这个新请求采用一个新的transaction并且应该有和上次请求相同的Call-ID,TO,From头域，Cseq应该有一个新的顺序号码（比原有顺序号码更大）。
其他的4xx应答，包括尚未制定的，是否允许请求重试，依赖于具体的方法和应用。
8.2 UAS特性
UAS在处理对话外的请求的时候，有一组规则需要遵守，这组规则与方法无关。12节指明了一个方法来判定一个请求是否在一个对话里。
注意，请求的处理是原子级别的。如果请求被处理，那么这个请求的相关状态一定是一起更新的。如果它被拒绝了，那么这个请求的所有相关状态一定是没有改变的。
UASs应当遵循本节所规定的顺序来处理请求。（就是说，首先是身份认证，然后是方法判定，然后是头域，然后按照本文规定处理剩余部分）
8.2.1 方法判定
当请求被认证（或者身份认证被忽略），UAS必须首先判定这个请求的方法。如果UAS发现自己不能处理这个请求的方法的时候，它必须给出一个405（方法不支持）的应答。产生应答的步骤在8.2.6节规定，并且UAS必须在给出的405（方法不支持）应答中增加一个Allow头域。这个Allow头域必须列明哪些方法UAS支持。Allow头域的说明在20.5节。
如果请求中的方法是服务器所支持的，那么处理将继续。
8.2.2 包头判断
如果UAS不认识请求中的包头域（就是说，包头域不在本规范中定义或者不在任何扩展中定义），那么服务器必须忽略掉这个包头域并且继续处理本请求。UAS必须忽略任何处理本请求所不需要的长得畸形的包头域。
8.2.2.1 TO 和Request-URI
To头域包含了由From域描述的发送者发出的请求的原始接受者。原始接受者可能是也可能不是正在处理这个请求的UAS,取决于呼叫转移或者其他的proxy操作。当TO域值和自身不相符的情况下，UAS可以自行决定是否接收这个请求。但是，我们依旧是建议UAS处理这个请求，甚至TO这个头域是以他们不认识的URI方案表达的（比如一个tel:URI），或者To头域并非指向这个自身处理的UAS。当然，另外一方面来说，如果UAS决定拒绝这个请求，它应该产生一个403（禁止访问）的状态码，并且交给服务器的transaction层来发送。
但是，Request-URI确定UAS来处理这个请求。如果Request-URI使用了一个UAS所不支持的方案（比如tel:URI），那么UAS应当拒绝这个请求，并且给出拒绝代码416（不支持的URI方案）。如果Request-URI并没有指明本UAS来处理这个请求，那么UAS应当给出一个404（未找到）的应答。比如，一个UA使用REGISTER方法来绑定它的address-of-record到一个特定的联系地址，将会收到Request-URI等于那个特定联系地址的请求。
其他潜在的Request-URI资源包括建立和刷新对话的UA发出的请求和应答的Contact头域。
8.2.2.2 合并的请求
如果请求的To头域中没有tag标志，UAS的处理核心必须检查基于正在进行的transactions上的请求。如果接收到的请求和正在处理的transaction的请求中的头域From tag,Call-ID,CSeq精确匹配了，但是请求并不匹配那个事务（基于事务匹配机制17.2.3节），UAS核心应该产生一个482（检测到循环）应答并且给服务器的transaction层发送。
这是由于相同的请求通过不同的路径到达UAS，很多情况下是由于分支的原因。UAS处理了第一个请求并且给其他所有这个请求以482（检测到循环）应答。
8.2.2.3 Require
如果请求的各项要素通过了UAS的判定，那么如果存在Require头域，接下来就是检查Require头域。Require头域是UAC用来通知UAS应该用什么样的SIP扩展来处理本请求的。Require的格式在20.32节中有介绍。如果UAS不支持请求的Require头域中的option-tag列表，那就必须产生一个420应答（错误的扩展）。并且UAS必须添上Unsupported头域，里边填上刚才接收到的请求的Require头域中，哪些options是自己所不支持的。
需要注意的是，Require和Proxy-Require禁止出现在SIP CANCEL请求中，或者回应给非2xx应答的ACK请求中。就算出现了在处理的时候也必须被忽略。并且回应给2xx应答的ACK请求必须只能包含在初始请求（在这个ACK请求之前的请求）中包含的Require和Proxy-Require所规定options，这样才能保证服务端能够正确处理。
例子：
UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: 100rel
UAS->UAC: SIP/2.0 420 Bad Extension
Unsupported: 100rel
这个特性（Unsupported）是为了保证客户－服务端都能够无阻碍的交互，除非是options对方不支持（就像上边的例子说明的一样）。对于相互匹配的客户－服务端（相互匹配的意思就是客户端Require的正好是服务端支持的），那么这些请求、应答将会处理的非常迅速，减少了一个请求的往返协商的浪费。另外，这个也避免了客户端不知道服务端到底不支持那些特性扩展。
某些特性扩展只对终端（endsystem）有效例如呼叫处理域等等。
8.2.3 内容处理
当UAS支持客户端请求中要求的扩展支持后，UAS要检查消息头域描述的消息体部分。如果UAS并不支持消息体部分的类型（Content-Type指明），语言（Content-Language指明），编码（Content-Encoding指明），并且这个消息体部分并非可选的消息体（Content-Disposition头域指明）,UAS必须回应一个415错误应答（不支持的媒体类型）应答。并且如果不支持请求中包含的消息体的正文类型，那么在应答中必须包含UAS所支持的消息体的类型列表（在Accept头域中指明）。如果不支持请求包含的消息体的encoding方式，那么应答中必须包含Accept-Encoding头域列明服务端支持的encoding方式。如果请求中的语言部分不支持，那么就必须在应答中包含Accept-Language头域列明支持的语言。在这些检查之外，消息体正文的处理依赖于方法和类型（method and type）。关于处理内容相关的头域的进一步的资料在7.4、20.11到20.15节。
8.2.4 应用扩展
如果UAS希望应用一部分SIP扩展，那么不可以在产生应答的时候做SIP扩展，除非这个扩展是在请求中的Supported头域中指明了的。如果这个扩展并没有在本请求的Supported头域中指明，那么服务端必须基于基准SIP给出应答，或者给出已知客户端支持的扩展应答。在极少数情况下，如果服务端不用扩展就无法处理请求，那么服务端应该发送421（需要扩展支持）应答。这个应答说明如果没有适当的扩展就无法给出正确的应答。在应答中需要的扩展必须在应答中的Require头域中指出。我们并不推荐这个方法，因为它会降低协同工作的能力。
除了421应答之外的其他应答中，如果需要应用扩展，那么这些扩展需要在421的应答中的Require头域中列明。当然，服务端不允许使用没有在请求中的Supported头域中列明的扩展。因此，应答中的Require头域只会包含标准的RFCs的扩展option tags。
8.2.5 处理请求
当所有的检查都通过了以后，UAS根据方法决定如何处理请求。第10节讲述了REGISTER请求的处理，11节讲述了OPTIONS请求的处理，13节讲述了INVITE的处理，15节讲述了BYE的处理。
8.2.6 产生应答
UAS产生应答，需要遵守接下来的几个小节中讲述的步骤产生一个应答。
在本节没有描述的应答代码的其他的行为，也可能会跟据应答代码的不同而要求。当创建应答的步骤完成之后，UAS将应答交给收到这个请求的服务端的transaction去处理。
8.2.6.1 发送一个临时应答
很多情况下，在与方法无关的应答规范中，在非INVITE请求的情况下，我们都要求UAS不应该发送临时应答给请求者。在这种情况下，UAS应该尽快发送一个终结应答给非INVITE请求。
当需要产生一个100（Trying）应答的时候，所有对应请求中包头的Timestamp域必须也拷贝到这个应答包头（就是说如果请求中有Timestamp，应答中也必须有timestamp）。而且如果应答有延时，那么UAS应该在这个Timestamp上增加延时的值。这个数值必须包含了接收请求和发送应答的时间，用秒来计数。
8.2.6.2 包头和Tags
应答中的From头域必须和请求中的From头域相等。应答中的Call-ID头域必须和请求中的Call-ID头域相等。应答中的Cseq头域必须和请求中的Cseq头域相等。应答中的Via头域必须和请求中的Via头域相等，而且顺序也必须相等。如果请求中包含了To tag，那么应答中的To头域必须和请求中的To头域相等。如果请求中的To头域并不包含Tag,那么应答中的To头域的URI必须和请求中的TO头域的URI相等；此外，UAS还必须增加一个Tag到To头域上（100（trying）应答是一个例外，在100中可能已经存在了一个tag）。这就提供了一个UAS正在应答的标志，也许就是对话ID的一部分。对同一个请求来说，它的应答必须有相同的tag标志，包括终结应答和临时应答（同样100（trying）除外）。生成tag的步骤在19.3节。
8.2.7 无状态UAS行为
无状态UAS就是说UAS本身不保持事务的状态。但是它在发送对应请求的应答之后并不保存请求的状态。如果无状态UAS接收到了一个重新发送的请求，它会重新产生一个应答并且重新发送应答，就像它接收到的是一个第一个请求一样（就像是新请求而不是重发的请求一样）。只有当相同请求的处理会导致相同的应答的时候，这个UAS才会是无状态的。例如：这条规则排除了无状态的登记服务。无状态的UAS并不包含一个transaction层；他们直接从通讯层接收请求和发送应答。
无状态的UAS通常用于处理不需要身份认证的请求，而且这些请求的应答是可以预期的。如果当不需要身份认证的请求被作为有状态的UAS来处理，那么大量的不需要身份认证的请求会造成服务器大量的事务状态，可能会导致UAS的处理非常慢，甚至中断处理，这样就导致了DoS（denial of service）状态。在26.1.5节中有进一步的描述。
无状态的UAS有下列重要的特性：
o 无状态的UAS不许发送临时应答（1xx）
o 无状态的UAS必须忽略ACK请求
o 无状态的UAS必须忽略CANCEL请求
o To头域必须依据无状态的规则来产生－就是说对于相同的请求，产生相同的tag标记。19.3节有讲tag标记。
对于其他情况而言，无状态的UAS遵循有状态的UAS的规则。对于一个新请求来说，同一个UAS可以是有状态的，也可以是无状态的。
8.3 重定向服务器
在某些架构下，可以透过重定向机制，来降低proxy服务器上的路由请求的压力，从而提高消息转发的效率。重定向允许服务器在一个请求的应答中，推送路由信息到客户端，这样就可以做到把自己从后续的消息流中脱离出来，但是同时又能提供准确的请求定位服务。当请求的发起者接收到转发的应答之后，他会重新产生一个基于接收到的URI（s）的请求。从network的中央转发到最边缘，转发机制可以适用于跨度很大的网络。
转发服务器在逻辑上是通过一个服务器的transaction层建立的，他作为transaction user可以访问某些类型的位置服务（参见第10节有关注册服务器和位置服务的说明）。这个位置服务可以很方便的用数据库里边的一个URI对应多个地址URI（可能在这个地址找到对应的客户）来实现。
一个重定向服务器并不发出任何指向它自己的请求。接收到任何一个非CANCEL的请求之后，服务器要么拒绝这个请求，要么从位置服务器上找到这个请求应该去的其他位置然后返回一个3xx的终结应答。对于合法的CANCEL请求，它应该返回一个2xx的应答。这个应答将会结束掉SIP事务。重定向服务器在整个SIP事务中位置事务的状态。在重定向服务器之间检测循环死锁应该是客户端的责任。
当重定向服务器给请求方返回一个3xx应答的时候，它会在Contact头域填写一组（一个或者多个）其他位置信息。如果需要指明这个Contact数据的生存周期，可以在Contact头域添加一个”expires”参数。Contact头域包含指向新位置的URI或者可以试试看的用户名，或者就是简单的附加通讯参数等等。301（永久去除）或者302（临时去除）应答同样可以指定和原始请求一样的目的位置和用户名，但是会附加像不同的服务器或者多点传送地址、或者SIP由UDP到TCP传输等等这样的通讯参数。
重定向服务器必须不能重定向一个请求到它自己的Request-URI列表中的地址；但是倘若那个URI并没有指向自己，重定向服务器可以路由这个请求到目的URI，或者可以返回一个404拒绝。
如果一个客户端正在使用外出的proxy，并且这个proxy实际上是重定向请求，那么就可能出现无限重定向循环。
注意，Contact头域的值可能指向一个与原始呼叫者无关的资源。比如，一个SIP对PSTN（本地电话网）网关的呼叫可能被转递给一个特别的说明，比如”你所呼叫的电话号码已经改为….”。Contact应答头域可以包含任何合适的能处理这个呼叫对方的URI，并不限于SIP URI。比如，它可以是电话，传真，或者IRC（如果有支持和定义的话）或者一个mailto：（RFC 2368[32]） URL。在26.4.4节讲述了对SIPS URI到非SIPS URI的实现和限制。
在Contact头域中的”expires”参数指明了这个URI的生存周期。这个参数的值是以秒作为单位的。如果这个参数没有提供，那么这个”expires”的缺省是有Expires头域所指定的。这个参数中如果设置了非法的值，那么都应改更改成为缺省的3600。这提供了对RFC2543的向后兼容，RFC2543允许在这个头域中填写绝对时间。在本协议中，如果这个expires填写了绝对时间，那么就会当作是非法的值，就会被当作是3600。
重定向服务器必须忽略自己所不能理解的特性（包括不认识的头域，不认识的Require中的option tag，甚至是不认识的方法名），并且带着问题处理这个请求的重定向。
9 取消一个请求(Cancel)
前边几节讲述了对所有方法的处理请求和处理应答的UA的通用处理过程。在本节中，我们讨论一个通用的方法，CANCEL。CANCEL请求，就像名字所说的，是用来取消客户端发起的上一个请求的。特别是，它请求UAS去终止上一个请求并且对上一个请求产生一个错误的应答。CANCEL对UAS已经给出终结应答的请求无效。所以，CANCEL请求的最大用处是取消需要服务器长时间处理的请求。也就是说，CANCEL最常用来处理取消INVITE请求，因为INVITE通常需要花费很长时间来产生一个终结应答。在这种使用中，UAS接收到对一个INVITE请求的CANCEL请求，当这个INVITE还没有得到终结应答的时候，UAS会”停止振铃”，并且给INVITE请求一个错误的应答（487）。
CANCEL可以由proxy或者UAC发起。15节讲述了在何种情况下，UAC会CANCEL
一个INVITE请求，在16.10节讲述了proxy对CANCEL的使用。
一个有状态的proxy需要对CANCEL进行响应，而不是简单的转发从下行流中接收到的一个应答。基于这个原因，CANCEL是一个”点对点”（hop-by-hop）的请求，也就是说，CANCEL需要每一个有状态的proxy节点进行处理和应答。
9.1 客户行为(Client Behavior)
CANCEL请求不应该取消除了INVITE之外的请求。因为除了INVITE之外的请求的响应都是立即响应的，所以，发送CANCEL来取消一个非INVITE请求总是形成一种赛跑的局面（就是说，cancel先到还是被取消的请求先到）。
下列步骤用于创建一个CANCEL请求。在CANCEL请求中的Request-URI , Call-ID , To , Cseq的数字部分，From这些头域都必须和被取消的请求头域一样，包含这些头域的tags. 客户端创建的CANCEL必须只有一个Via头域值，这个头域值和被取消的请求的最上一个Via头域值相同。这些头域的值和请求的值相同可以让CANCEL请求和被取消的请求相匹配（9.2节描述了如何匹配）。在Cseq请求头域的method部分必须是一个CANCEL方法。这个让这个CANCEL请求被当作自己的事务而被正确的鉴别和处理（参见17节）。
如果被取消的请求包含一个Route头域，CANCEL请求也必须包含这个Route头域的值。这个是让无状态的proxy能够正确路由CANCEL请求。
CANCEL头域必须不能包含任何Require或者Proxy-Require头域。
一旦CANCEL请求被创建了，客户端应当检查是否收到了这个CANCEL请求取消的原始请求的任何应答（临时的或者终结的应答）。如果没有任何临时应答收到，这个CANCEL请求一定不能发送，直到客户端等到了第一个临时应答。如果原始请求已经收到一个终结应答，这个CANCEL也不应当发送，因为CANCEL请求对已经产生了终结应答的请求没有任何作用。当客户端决定发送一个CANCEL,它会为这个CANCEL创建一个客户transaction，并且通过目的地址、端口、传输层来发送CANCEL请求。这个CANCEL中的目标地址、端口和传输层必须和原始请求一样。
如果允许在接收应答之前发送CANCEL请求，那么服务端必须支持在接收原始请求之前接收到CANCEL请求。
注意，原始请求的事务和CANCEL请求的事务都是互相独立的。也就是说，UAC判定一个请求的取消不能依赖原始请求的一个487（请求终止）应答，遵循RFC2543协议，UAS不会产生这样一个应答。如果原始请求经过了64*T1（T1在17.1.1.1节定义）秒还没有应答，客户端应当认为原始请求已经取消，并且应当销毁对应原始请求的客户端事务。
9.2 服务端行为(Server Behavior)
CANCEL请求要求服务端的TU取消相关的事务（transaction）。TU根据接收到的CANCEL请求，并且假定请求的方法不是CANCEL或者ACK，并且用17.2.3节描述的事务匹配方法来匹配事务，这样TU就可以决定那个事务需要被取消了，被匹配的事务就是需要被取消的事务。
服务端对CANCEL请求的处理依赖于服务器的类型。一个无状态的proxy会转发这个请求，一个有状态的proxy可能会响应这个请求，并且自己再产生一些CANCEL请求，UAS会响应这个CANCEL请求。16.10节讲述了proxy怎样处理CANCEL请求。
当UAS收到CANCEL请求，首先按照8.2节的UAS通用处理方法进行处理。不过，既然CANCEL请求是基于”点对点”（hop－by－hop）的，也是不能再提交的，他们不能由服务器为了获得Authorization头域中正确的认证而反复尝试。注意，因此CANCEL请求也不能包含Require头域。
如果根据上边的步骤，UAS不能找到与CANCEL请求相匹配的事务，它应该给CANCEL一个481应答（调用的Leg/Transaction不存在 会话/事务不存在）。如果对应原始请求的事务存在，那么UAS在接收到CANCEL请求的处理就依赖于是否已经给这个原始请求发出了终结应答。如果已经发出了，不会对CANCEL请求对应的原始请求做任何处理，不会更改任何会话状态，不会对原始请求的应答做任何处理。如果UAS没有发出对原始请求的终结应答，它会依赖于CANCEL所取消的原始请求方法。如果原始请求方法是INVITE，UAS应当立刻响应INVITE一个487（请求终止）。本协议中，对CANCEL取消的其他本协议中定义的方法没有约定。
不管原先请求的方法是什么，只要CANCEL匹配一个事务，UAS就响应CANCEL请求一个200（OK）应答。这个应答根据8.2.6节约定构造。注意，给CANCEL应答的To tag和给原始请求的应答的To tag应该是一样的。对CANCEL的应答会通过服务端transaction来传送。
10 注册(Registrations)
10.1 概览
SIP提供了一个搜索机制，如果一个用户希望建立和其他用户的会话，SIP必须查找能够找到对方用户正在使用的当前主机(hosts)。这个搜索机制经常被SIP网络基本元素使用，比如proxy服务器，重定向服务器等等。他们在接收、以及响应一个请求的时候，会基于这个用户的位置信息来判定这个消息应该发送到哪里。要实现这个，SIP网络部件考虑了一个抽象的服务：位置服务；位置服务是通过对特定地区提供地址绑定来实现的。这些地址绑定转换输入的SIP或者SIPS URI，比如sip:bob@biloxi.com，转换到一个或者一组更加”接近”目标用户的URI，比如sip:bob@engineering.biloxi.com。基本上，一个proxy会从把输入的URI转换到用户实际位置的位置服务中得到最终用户的位置。
注册服务为特定地区的位置服务创建绑定关系，这个绑定关系是用来建立包含一个或者多个联系地址的address-of-record URI。因而，当那个地区的proxy接收到一个请求，这个请求的Request-URI和address-of-record的记录匹配，那么这个proxy会转发请求到这个address-of-record中登记的联系地址中去。通常，只有当对那个address-of-record的请求会被路由到这个区域的时候，登记这个address-of-record 到这个这个区域的位置服务才是有意义的。在大多数情况下，这个就要求登记服务所覆盖的区域和URI中的address-of-record所覆盖的区域相同。有很多种方法来建立位置服务。一个方法是administratively(管理)。在上述的例子种，Bob我们通过查询公司数据库知道他是一个工程部职员。不过，SIP提供了一个让UA能够创建精确绑定的机制。这个机制就是登记服务。
登记服务需要向一个特殊的UAS服务器（注册服务器registrar）发出REGISTER请求。注册服务器(registrar)为一个区域的位置服务作为前端接入，根据REGISTER请求的内容读写位置对照表。这个位置服务通常为处理这个区域的proxy服务器提供位置服务。
总的登记服务处理流程在图2中说明。需要注意的是，登记服务器(registrar)和proxy服务器都是逻辑上的角色，可以在网络中用一个设备来部属；在例子图中是为了能够清楚的表示所以分开描述。还需要注意的是如果他们（登记服务器和proxy）本身是分开的，那么UA可以通过proxy服务器发送注册请求。
SIP本身对实现位置服务器（location service）没有特别的要求。唯一的要求是某些区域的注册服务器（registrar）必须能够对位置服务的数据进行读写，并且这个区域的proxy或者重定向服务器必须能够兼容读取相同的数据。注册服务器（registrar）可能和某一个区域的proxy服务器部署在一起。
10.2 构造一个REGISTER请求
REGISTER请求用来增加、删除、查询绑定资料。一个REGISTER请求可以增加一个address-of-record和一个或者多个联系地址之间的绑定。在合适的第三方认证的情况下，可以做address-of-record的登记。客户端同样可以删除前边绑定的内容也可以查询address-of-record的当前绑定地址。除了特别说明以外，REGISTER请求的构造以及客户端如何发送REGISTER请求和通常的8.1节描述的和17.1节描述的UAC发出请求是一致的。
一个REGISTER请求并不建立一个对话。当基于事先给定路由集（8.1节）的情况下，一个UAC可以在REGISTER请求中包含一个Route头域。在REGISTER请求和应答包中，Record-Route头域并没有任何意义，如果这个头域存在，必须被忽略。另外，UAC一定不能基于REGISTER请求的应答包中的任何Record-Route头域来创建新的路由集合。
下面这些头域，除了Contact,必须在REGISTER头域中包含。Contact头域可选。
Request-URI: 这个头域指明了登记服务所指明的位置服务所在的区域（比如sip:chicago.com）。”userinfo”和”@”元素在SIP URI中不能出现。
To： 这个头域包含了被查询、增加、修改的address-of-record。to头域和Request-URI头域通常是不同的，因为这个由用户名组成。这个address-of-record必须是一个SIP URI或者SIPS URI.
From: 这个头域包含了提交这个注册信息的用户的address-of-record资料。这个值和To头域的值相同，除非这个请求是第三方发起的注册请求。
Call-ID: UAC发出的给某个注册服务器（registrar）的所有注册请求都应该有相同的Call-ID头域值。如果相同的客户端用了不同的Call-ID值，注册服务器(registrar)就不能检测是否一个REGISTER请求由于延时的关系导致了故障。
Cseq: Cseq值保证了REGISTER请求的正确顺序。一个UA为每一个具备相同的Call-ID的REGISTER请求顺序递增这个Cseq字段。
Contact: REGISTER请求可以有一个Contact头域。这个头域可以有0个或者多个包含绑定地址信息的值。
UA在没有收到上一个注册请求的应答或者上一个REGISTER请求超时之前，禁止发送新的注册请求（就是说，包含一个新的Contact头域值，而不是重发）。
bob
+----+
| UA |
| |
+----+
|
|3)INVITE
| carol@chicago.com
chicago.com +--------+ V
+---------+ 2)Store |Location|4)Query +-----+
|Registrar|=======> | Service|<======= |Proxy|sip.chicago.com
+---------+ +--------+=======> +-----+
A 5)Resp |
| |
| |
1)REGISTER| |
| |
+----+ |
| UA | <-------------------------------+
cube2214a| | 6)INVITE
+----+ carol@cube2214a.chicago.com
carol
图2：REGISTER例子
下边的Contact头域参数在REGISTER请求中有特别的意义：
action: 在RFC2543中的“action”参数已经废弃了，UAC不能使用”action”参数。
expires： “expires”参数表明UA的绑定的有效时间。以秒为单位的整数。如果本参数没有制定，那么这个参数的值就是Expires头域的值。实现中，可以把超过2**32-1的值（4294967295秒或者136年）认为是2**32-1。非法的值应当视同3600。
10.2.1 增加绑定
REGISTER请求是向注册服务器（registrar）发送一个包含对某一个address-of-record的地址的SIP请求应当发送的实际联系地址。address-of-record包含在REGISTER请求的To头域中。
请求中的Contact头域通常包含了SIP或者SIPS的URI，这些URI表明了特定的SIP端点（比如sip:carol@cube2214a.chicago.com）,他们也可以使用其他的URI表示方法。一个SIP UA可以选择注册一个电话号码（比如使用tel URL, RFC 2806[9]）或者一个email地址（比如用mailto URL, RFC2368[32]）来作为address-of-record的联系地址Contact域。
例如，Carol,有一个address-of-record”sip:carol@chicago.com”，将会在区域chicago.com的注册服务器上注册。她的注册服务信息将会被chicago.com区域的proxy服务器使用，用来路由和转发到Carol的address-of-record请求到她的SIP终端。
当客户端在注册服务器（registrar）上建立好了绑定以后，它可以根据需要发送后续的注册请求，包含新的绑定信息或者修改以前的绑定信息。给REGISTER请求的2xx应答中，在Contact头域中是在这个注册服务器（registrar）上登记的完整的这个address-of-record的绑定列表。
如果REGISTER请求中的To头域中的address-of-record是一个SIPS URI,那么任何在REGISTER请求中的Contact头域都应当是SIPS URI。客户端只有在有其他手段保证非SIPS URI的安全性的情况下，才能在SIPS 的address-of-record的地址上注册非SIPS URI。这个也可以适用域使用非SIP协议的URI，或者用非TLS来加密的SIP设备。
注册并不需要更新所有的绑定。一般情况下，UA只更新它现在的联系地址。
10.2.1.1 设置Contact地址的过期参数
当一个客户端发出一个REGISTER请求，它可能包含一个过期参数用来表示这个注册的地址的有效期。（就像在10.3节讲述的那样，注册服务器（registrar）根据自己的策略选取实际的时间间隔来计算有效期）。
客户端设置有效期的方法有两种：一个是通过设置Expires头域，一个是通过设置”expires”contact头域的参数来设置。 后一种允许针对同一个REGISTER请求中的多个绑定联系地址中的每一个联系地址单独设定有效期，然后所有没有带”expires”参数的Contact头域的值都使用Expires的设置。
如果REGISTER中没有两种有效期都没有设置，这就表明这个有效期由服务器来决定。
10.2.1.2 Contact Adress的参数选择
如果在一个REGISTER请求中包含多个Contact，着说明UA想要把这些Contact头域的内容都和To头域中制定的address-of-record地址绑定起来。这个列表可以用”q”参数来区分Contact头域的优先级。”q”参数用来标志特定Contact头域值和其他绑定的address-of-record的联系地址之间的优先级。16.6节讲述了一个proxy服务器如何使用优先级。
10.2.2 删除绑定
注册信息是一个纯粹软件的状态，并且如果不刷新会过期。如果需要，也可以被删除。一个客户端可以设置注册服务器(registar)的有效期（10.2.1）。一个UA可以通过发出有效期为”0”的REGISTER请求，使某一个联系地址立刻失效。UAS都需要实现这个机制使得在联系地址过期前能够被删除。
REGISTER规范中的Contact头域如果设置成为”*”则表示需要操作所有的注册项。但是也只能在具有一个Expires头域并且这个头域为’0’的情况下能够使用。（这就是说，只能够在要删除所有的注册项的时候使用”*”）。
用”*”来删除所有的注册项有一个好处，就是使得UA不需要知道每一个注册项的精确值。
10.2.3 访问绑定
无论请求是否包含了Contact头域，给任何REGISTER请求的成功应答都包含了一个完整的绑定列表。如果REGISTER请求头域中不包含Contact头域，那么注册服务器的绑定列表将不会改变。
10.2.4 刷新绑定
每一个UA都对先前它建立的绑定信息由刷新的义务。禁止对其他UA建立的绑定信息进行刷新。在注册服务器（registrar）给出的200（OK）应答中，包含了的Contact头域中列明了所有的当前绑定信息。UA需要挨个比较这些联系地址，看看是否这个地址是可以建立联系的，这个比较是通过19.1.4节中的比较规则来进行的。如果是，它通过更新expires参数来更新过期时间（或者Expires头域）。于是在这些绑定信息过期前，UA为每个绑定发出REGISTER请求来刷新绑定。也可以通过一个REGISTER请求来刷新数个绑定请求。
UA在一个刷新周期中，应该使用相同的Call-ID来进行注册调用。刷新的注册信息应该是和原来登记的信息一致。
10.2.5 设置内部时钟
如果REGISTER请求的应答中包含一个Date头域，客户端可以用这个头域来校正当前内部的时钟。
10.2.6 寻找注册服务器
UA有3种方法来决定向哪里发出注册请求：通过配置，使用address-of-record,广播方式。一个UA可以用非本文档规定的方式，配置一个注册服务器的地址。如果UA没有配置任何注册服务器的地址，UA应该用请求的Request-URI部分种的address-of-record的服务器部分（host part），用普通的SIP服务器定位机制[4]。比如，用户”sip:carol@chicago.com”地址的注册服务应该是”sip:chicago.com”。
最后，UA可以通过监听广播的形式来获得注册服务器地址。监听广播的注册服务器是通过监听著名的”全部SIP 服务器”广播地址”sip.mcast.net”(224.0.1.74)。没有Ipv6的广播地址。SIP 的UA可以监听这个地址，并且用这个来知道其他本地用户的地址（见附件[33]）；不过他们并不对请求做响应。通过监听广播的登记服务可能在某些环境下不能用，比如，基于同一个本地网络的多个商业应用的情况。
10.2.7 传送一个请求
当REGISTER请求被构造好以后，并且也有了登记服务起地址，UAC遵循8.1.2节的说明来提交transaction层来发送REGISTER请求。如果transaction层返回一个由于REGISTER请求没有应答的超时错误，UAC不应该立刻重新尝试对同一个注册服务器的注册请求。
立刻重新尝试很有可能导致再次超时。等待一个合理的时间在尝试可以降低网络的负载，在这里并没有一个约定的等待时间间隔。
10.2.8 错误响应
如果UA接收到一个423（间隔太简略）应答，它可能需要更改REGISTER请求中的所有有效期，使得这些有效期必须大于等于423应答头中的Min-Expires头域中的有效期，并且重新尝试发送这个REGISTER请求。
10.3 处理REGISTER请求
一个注册服务器(registrar)就是一个UAS，这个UAS用来响应REGISTER的请求，并且维持一个绑定表，这个绑定表用来提供给它所管理的区域中的proxy服务器和重定向服务器的。一个注册服务器根据8.2和17.2中的规定来处理请求，但是它仅仅处理REGISTER请求。一个注册服务器禁止产生6xx应答。一个注册服务器可以适当的转发REGISTER请求。通常用于一个注册服务器（registar）监听一个多点广播，并且通过302应答（临时转移）转发这个多点广播的REGISTER请求到它正确的处理位置。
注册服务器必须忽略在REGISTER请求中的Record-Route头域，并且也不能在REGISTER请求的应答中包含任何Record-Route头域。注册服务器可能收到一个有proxy转发过来的REGISTER请求，这个请求中由于proxy处理这个请求当作未知请求所以添加了Record-Route头域。
一个注册服务器必须知道（例如，通过配置）它所管理的区域。注册服务器一定需要按照接收到的REGISTER请求顺序进行处理。
REGISTER请求必须当作原子请求来处理，意味着给定的REGISTER请求要么就完整处理，要么就完全拒绝。每一个REGISTER信息的处理都和其他的注册和绑定信息的处理无关。
当接收到一个REGISTER请求，注册服务器（registrar）按照如下步骤处理：
1、 注册服务器（registrar）检查Request-URI来决定是否它属于本注册服务器所管理的区域的Request-URI。如果不是，并且如果这个服务器同时也作为一个proxy服务器，那么这个服务器应当转发这个请求到指定的区域。这个转发是根据16节所规定的proxy通用信息处理规则来进行的。
2、 为了保证注册服务器能够支持所需要的扩展，注册服务器必须遵循8.2.2节描述的情况来处理Require头域。
3、 一个注册服务器应当对UAC进行身份认证。SIP UA的身份认证机制在22节描述。注册这个动作需要遵循SIP的通用的身份认证框架。如果没有任何认证机制，注册服务器可以使用From地址来作为原始请求的信任依据。
4、 注册服务器应当检查认证的用户是否通过认证来更改这个address-of-record的登记权限。比如，一个登记服务起(registrar)可以通过访问一个认证数据库，这个认证数据库映射了用户名和一个address-of-record列表，这些列表是用户可以更改绑定信息的列表。如果认证用户并没有权利修改绑定信息，注册服务器应当返回一个403（禁止访问）并且跳过后续步骤。在支持第三方认证和注册的架构下，一个实体可以被授权来更新多个address-of-record的注册信息。
5、 注册服务器(registrar)从REGISTER请求的To头域中解出address-of-record。如果这个address-of-record并非在这个Request-URI指明的区域中合法，那么注册服务器必须发出一个404(没有找到)的应答，并且跳过后续步骤。接着URI必须转换成为标准的格式。所有的URI参数都必须删去（包括用户参数user-param）,并且任何非法(escaped)字符必须转换成为合法字符(unescaped)格式。最后形成一个可以用于绑定的列表。
6、 注册服务器(registrar)检查是否请求包含了一个Contact头域。如果没有包含，它跳过到最后一步。如果Contact头域包含了，注册服务器检查是否有一个Contact头域值是”*”，并且包含了一个Expires头域。如果请求有其他的Contact头域或者任何有效期的值是非0的，这个请求就是非法请求，并且服务器必须送回一个400（非法请求）的应答，跳过后续步骤。如果没有，那么注册服务器检查是否Call-ID复核每一个绑定的值。如果不符合，它必须删除绑定。如果复核，它必须仅仅删除保存的绑定表中CSeq值小于请求中的Cseq值的记录。否则，更新必须终止，请求失败。
7、 现在注册服务器(registrar)可以依次处理Contact头域中的联系地址了。对于每一个地址，它根据下边的规则进行有效期检查。
－ 如果含有”expires”参数，这个参数值就是最终的有效期。
－ 如果没有这个参数，并且请求有一个Expires头域，那么这个值就是有效期。
－ 如果没有Expire头域也没有参数，那么本地的缺省配置应当作为有效期。
注册服务器可以选择一个小于请求中的有效期值作为最后的有效期。当且仅当请求的有效期大于0 并且小于1个小时并且小于一个注册服务器配置的最小有效期的时候，注册服务器可以响应一个423（有效期过小）的错误来拒绝。这个应答必须包括了一个Min-Expires头域来表明本注册服务器所接收的最小有效期，然后跳过所有后续步骤。
允许注册服务器设置注册服务器自己的有效期防止了过分频繁的刷新注册信息，并且也降低了维持和管理注册信息的工作量。在服务的创建的时候，注册信息中的有效期会经常用到。一个例子是follow-me(跟随我)服务，在这个服务中，一个用户可能在一个终端上只停留一小会儿。因此，注册服务器应当接收简略的注册；一个请求只有当它的有效期过短的时候（短到可能降低注册服务器性能的时候）才应当被拒绝。
对于每一个地址，注册服务器在当前绑定列表中用URI比较规则进行搜索。如果绑定不存在，它会暂时性的添加进去。如果绑定存在，注册服务器检查Call-ID值。如果Call-ID值在这个已经存在的绑定中和本次请求的Call-ID值不一样，那么如果绑定的有效期为0就删除这个绑定，否则就刷新这个绑定。如果Call-ID值一样，那么注册服务器比较Cseq值，如果请求中的这个值比现存的绑定值中的Cseq高，那么必须更新或者删除这个绑定（如果有效期为0 就删除，否则就刷新）。如果这个Cseq值比现存的Cseq值小，那么必须终止更新并且请求失败。
这个规则确保了从同一个UA过来的请求顺序处理，对于非顺序的请求跳过处理。
每一个绑定记录都包含了当时请求的Call-ID和Cseq的值。
只有当且仅当所有的绑定更新和绑定添加都完成的时候，绑定才可以做COMMIT处理（就是说，这次修改对proxy和重定向服务器可见）。如果任何更新或者添加失败了（比如，由于后台的数据库commit失败），必须给出一个500（服务器错误）的应答，并且中间进行的临时更新都必须删除。
8、 注册服务器（registrar）返回一个200（OK）应答。这个应答必须包含Contact头域，并且这个头域的值中列举了所有当前绑定的注册信息。每一个Contact值都必须包含一个”expires”参数，用来标志还有多久这个绑定信息就过期了。应答也必须包含一个Date头域。
