1、1、SIP 协议介绍Internet 的许多应用都需要建立和管理一个会话，会话在这里的含义是在参与者之间的数据的交换。由于考虑到参与者的实际情况，这些应用的实现往往是很复杂的：参与者可能是在代理间移动，他们可能可以有多个名字，他们中间的通讯可能是基于不同的媒介（比如文本，多媒体，视频，音频等）有时候是多种媒介一起交互。人们创造了无数种通讯协议应用于实时的多媒体会话数据比如声音，影像，或者文本。本 SIP（会话初始协议）和这些协议一样，同样允许使用 Internet 端点（用户代理）来寻找参与者并且允许建立一个可共享的会话描述。为了能够定位精确的会话参与者，并且也为了其他的目的，SIP 允许创建
2、基础的 network hosts（叫做代理服务器） ，并且允许终端用户注册上去，发出会话邀请，或者发出其他请求。SIP 是一个轻形的，多用途的工具，可以用来创建，修改和终止会话，它独立运作于通讯协议之下，并且不依赖建立的会话类型。2、SIP 协议功能概况SIP 是一个应用层的控制协议，可以用来建立、修改、和终止多媒体会话（或者会议）例如 Internet 电话。SIP 也可以邀请参与者参加已经存在的会话，比如多方会议。媒体可以在一个已经存在的会话中方便的增加（或者删除） 。SIP 显示的支持名字映射和重定向服务，这个用于支持个人移动业务用户可以使用一个唯一的外部标志而不用关系他们的实际网络地
3、点。SIP 在建立和维持终止多媒体会话协议上，支持 5 个方面：1. 用户定位： 检查终端用户的位置，用于通讯。2. 用户有效性：检查用户参与会话的意愿程度。3. 用户能力：检查媒体和媒体的参数。4. 建立会话：”ringing”,建立会话参数在呼叫方和被叫方。5. 会话管理：包括发送和终止会话，修改会话参数，激活服务等等。SIP 不是一个垂直集成的通讯系统。SIP 可能叫做是一个部件更合适，它可以用作其他IETF 协议的一个部分，用来构造完整的多媒体架构。比如，这些架构将会包含实时数据传输协议（RTP） （RFC 1889）用来传输实时的数据并且提供 QoS 反馈，实时流协议（RSTP）(R
4、FC 2326)用于控制流媒体的的传输，媒体网关控制协议（ MEGACO）(RFC 3015)用来控制到公共电话交换网（PSTN ）的网关，还有会话描述协议（SDP） （RFC 2327）用于描述多媒体会话。因此，SIP 应该和其他的协议一起工作，才能提供完整的对终端用户的服务。虽然基本的 SIP 协议的功能组件并不依赖于这些协议。SIP 本身并不提供服务。但是，SIP 提供了一个基础，可以用来实现不同的服务。比如，SIP 可以定位用户和传输一个封装好的对象到对方的当前位置。并且如果我们利用这点来通过 SDP 传输会话的描述，立刻，对方的用户代理可以得到这个会话的参数。如果我们用这个像传输会话
5、描述（SESSION DESCRIPTION SD）一样呼叫方的照片，一个”呼叫ID”服务很容易就建立了。这个简单的例子说明了，SIP 作为一个基础，可以在其上提供很多不同的服务。SIP 并不提供会议控制服务（比如议席控制或者投票系统） ，并且并没有建议会议应该则那样管理。可以通过在 SIP 上建立其他的会议控制协议来发起一个会议。由于 SIP 可以管理参与会议的各方的会话，所以会议可以跨异构的网络，SIP 并不能，也不打算提供任何形式的网络资源预留管理。安全对于提供的服务来说特别重要。要达到理想的安全程度，SIP 提供了一套安全服务，包括防止拒绝服务，认证服务（用户到用户，代理到用户） ，完
6、整性保证，加密和隐私服务。SIP 可以基于 IPV4 也可以基于 IPV63、术语在这个文档中，关键词”必须”,”不允许”,”要求”,”可以”,”不可以”,”应该”,”不应该”,”建议”,”不建议”,”可能”,”可选” 是根据 BCP14,RFC 21192的规范描述SIP 实现需要的不同层次4、实施概览这节通过简单的示例介绍了 SIP 的基本实现。本节是通过自然的而非正则的示例来介绍的。第一个例子说明了 SIP 的基本功能：定位一个断点，发出通讯请求，通过协商会话参数建立会话，拆卸刚才建立的会话。图一表示一个典型的 Alice 和 Bob 两个用户间的 SIP 消息交易交换例子.（每一个消息
7、采用字母”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 标志
8、 “呼叫” Bob，这个 SIP 标志是统一分配的资源（Uniform Resource Identifier URI）称作 SIP URI。SIP URI 在 19.1 节中定义。它很像一个 email 地址，典型的 SIP URI 包括一个用户名和一个主机名。在这个范例中，SIP URI 是sip:, 是 Bob 的 SIP 服务提供商。 Alice 有一个 SIP URI: sip:。 Alice 可以输入 Bob 的 URI，也可以直接在地址本的一个超级链接上点击一下 Bob 的 URI。SIP 也提供保密 URI，称作 SIPS URI。例如：sips: 。 一个基于 SIPS UR
9、I 的通话保证这个通话是安全的，并且对呼叫者和被叫的所有的 SIP 消息是加密传输的（叫做 TLS） 。在 TLS 中，请求是通过加密方式传输给被叫方，但是这个加密机制是基于被叫方宿主服务器的实现的。SIP 是基于一个类似 HTTP 协议的请求应答的通讯模式。每一个通讯都包含对某个功能的请求，并且起码需要一个应答。在这个应答中，Alice 的软电话发送一个含有 Bbo 的 SIP URI 抵制的 INVITE 通讯请求。INVITE 是一个 SIP 请求的例子，表示请求方（ Alice）希望服务方（Bob）应答。INVTE 请求包含一系列的包头域（ Header fields） 。包头中包含很
10、多属性并且包含了传输消息的附加信息。在 INVITE 中有如下的字段：呼叫的唯一标志，目的抵制，Alice 的地址，Alice 和 Bob 建立会话的类型。INVITE 请求（图 1 中的 F1）可能看起来像这样的：INVITE sip: SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob From: Alice ;tag=1928301774Call-ID: CSeq: 314159 INVITEContact: Content-Type: application/sdpContent-Length:
11、 142(Alices SDP not shown) . . . . proxy proxy . .Alices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bobssoftphone SIP Phone| | | | INVITE F1 | | |- | INVITE F2 | | 100 Trying F3 |- | INVITE F4 | | | | Media Session | | BYE F13 | | |图一：SIP 矩形表达的 SIP 会话建立例子。在
12、文本消息的第一行，包含了请求的类型（INVITE） 。在这行之后的是这个请求的头域。这个例子中包含了最少需要的头域集合。简单介绍一下：VIA 域包含了 Alice 接收发送请求的服务器地址（） 。同样这个包含了一个分支参数来标志 Alice 和这个服务器的会话事务。TO 域包含了显示姓名（Bob）和一个 SIP 或者 SIPS URI（sip：）请求将首先传输到这个 URI 中。显示姓名（ Display names）在 RFC 2822 中描述。From 域也同样包含一个显示姓名（Alice ）和一个 SIP 或者 SIPS URI（sip:）这个 URI 用来标志请求的原始发起者。这个域也
13、包含了一个 TAG 参数，这个 TAG 参数是一个随机字串（ 1928301774） ，是软电话（softphone）在 URI 上增加的一个随机串。用来做标志用途的。Call_ID 包含一个全局的唯一标志，用来唯一标志这个呼叫，通过随机字串和 softphone 的自己名字或者 IP 抵制混和产生的。通过 TO TAG, FROM TAG 和 CALL-ID 完整定义了Alice 和 Bob 之间的端到端的 SIP 关系，并且表示这个是一个对话性质的关系。CSEQ 或者 Command Sequence 包含了一个整数和一个请求名字。这个 Cseq 数字是顺序递增的。每当对话中发起一个新的请
14、求都会引起这个数字的顺序递增。Contact 域包含一个 SIP 或者 SIPS URI 用来表示访问 Alice 的直接方式，通常由用户名和一个主机的全名（Fully Qualified Domain Name FQDN）组成。当 FQDN 作为首选的时候，许多终端用户由于不会由名字登记（而导致不能访问 Alice 的主机） ，所以 IP 地址是可选的。VIA 域告诉大家本请求发送到哪里并且应答到哪里，Contract 域告诉大家将来的请求将发送到哪里（奇怪不是 Alice 发起的么，将来的请求应该是 Bob 才对啊） 。Max-Forwards:最大转发数量限制了通讯中转发的数量。它是由一
15、个整数组成，每转发一次，整数减一。Contenttype 包含了消息正文的描述（消息正文在本范例中没有列出）Content-length:包含消息正文的长度（字节数）完整的 SIP 包头域的定义在 20 节。会话的细节，比如媒体的类型，codec ，或者采样速率，没有通过 SIP 来描述。这个可以通过 SIP 的消息正文来描述，可以通过其他定义的协议在正文中进行描述。有一种是会话描述协议（Session Descripotion Protocol SDP） （RFC23271） 。这个 SDP 消息（没有在例子中列出）通过 SIP 的消息中传送，就像通过附件发送 EMAIL一样，或者说通过 H
16、TTP 传输的网页一样。由于 softphone 并不知道 bob 或者 bob 的 sip 服务器 在哪里，所以 softphone 发送INVITE 请求到 Alice 的 sip 服务器 ,。这个 SIP 服务器应该已经在Alice 的 softphone 中配置了，或者可以通过 DHCP 获得。 SIP 服务器是一台代理服务器。代理服务器接收 SIP 请求并且根据请求转发。在这个例子中，代理服务器接收到 INVITE 请求，并且回送一个 100（Trying）应答给 Alice 的 softphone。100（Trying）应答表示 INVITE 请求已经收到，并且代理服务器正在
17、转发 INVITE 请求。SIP 的应答是通过一个三位数的数字表示的。SIP 应答同样包含 TO、FROM、Call-ID，CSEQ 和在 VIA 中的分支参数，这个参数使得 Alice 的 softphone 可以把请求和应答关联起来。 代理服务器收到 INVITE 请求之后，就去找 可能通过 DNS 服务来找提供这个 的 SIP 服务器。这在4中有描述。最后，转发 INVITE 请求到 或者能到达 的代理服务器。在转发请求之前， 代理服务器会在 via 头上增加一个一段包含自己抵制的值（INVITE 已经包含了 Alice 的的地址 VIA 域） 。 代理服务器收到这个 INVIT
18、E 请求并且返回一个 100（Trying）应答给 代理服务器标志这它已经收到这个请求并且正在处理这个请求。这个代理服务器通过查询数据库，通常叫做地址服务，这个服务中包含了 bob 的当前 ip 地址。 （我们在下一节可以看到这个数据库是怎么回事） 代理服务增加另一段包含自己地址的 VIA 头域并且发送它到bob 的 sip 电话。Bob 的 SIP 电话接收到 INVITE 请求并且提醒 bob 有一个从 Alice 的呼入，这样 bob 可以决定是否响应这个呼入。这个意思就是：bob 的电话响了。bob 的 sip 电话发送一个180（Ringing）回应，这个回应将通过两个代理服务器原
19、路返回给 Alice。每一个代理服务器通过 via 头域决定该把这个应答发送给哪里，并且在发送之前把自己的地址从头上拿走。虽然 DNS 和定位服务在路由最初的 INVITE 请求，180（ringing）响应可以简单返回给发起者而不需要查找发起者在哪里，并且不需要在代理服务器保留状态，同时，每一个转发INVITE 的代理也可以得到 INVITE 的每一个应答，这样的特性也非常有用。当 Alice 的 softphone 收到 180（Ringing）应答的时候，它提示 Alice,可能是通过一个回铃音，或者屏幕上的一个消息提示。在这个例子中，Bob 决定响应这个呼叫。当他拿起电话，他的 SIP
20、 电话发送 200（OK ）回应给发送者，表示这个电话已经接起来了。这个 200（OK ）包含了一个消息体，这个消息体包含 SDP 媒体描述，这个媒体描述包含 Bob 希望和 Alice 建立何种媒体连接。同样，SDP 消息也是两段交换：Alice 发送一个给 Bob，Bob 发送一个回给 Alice。这个两段的交换提供基本的兼容性协商，并且基于简单的 SDP 提出/应答交换模型。如果 Bob 不想响应这个呼叫或者正在响应别的呼叫，一个错误的响应会代替正常的 200（OK ）回送出去，这样，就不会有连接建立。SIP 完整的返回代码在 21 节有介绍。Bob 发出的 200（OK ） （图一的
21、F9 消息）可能长得像这样的：SIP/2.0 200 OKVia: SIP/2.0/UDP ;branch=z9hG4bKnashds8;received=192.0.2.3Via: SIP/2.0/UDP ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2Via: SIP/2.0/UDP ;branch=z9hG4bK776asdhds ;received=192.0.2.1To: Bob ;tag=a6c85cfFrom: Alice ;tag=1928301774Call-ID: CSeq: 314159 INVITEContact: Co
22、ntent-Type: application/sdpContent-Length: 131(Bobs SDP not shown)应答的第一行包含了应答代码（200）和原因（ok） 。剩下的行包含了包头域。VIA,TO,FROM,CALL-ID,Cseq 包头域是从 INVITE 请求包中直接拷贝过来的。 （有三个VIA 域值一个是 Alice SIP 电话增加的，一个是 代理加的，一个是 代理加的） 。Bob 的 SIP 电话增加了一个 TAG 参数。这个 TAG 参数会被参与对话的各方所使用，并且在以后的对话中被使用。Contract 域包含了一个能直接联系到 Bob 的URI。Con
23、tenttype 和 Content_Length 域包含了消息体（没有在例子中体现） ，这个消息体里边是 Bob 的 SDP 媒体信息。除了 DNS 和位置服务之外，代理服务器可以自主决定路由，也就是说自己决定应该向哪里转发请求。比如，如果 Bob 的 SIP 电话返回一个 486（电话正忙）信号， 这个代理服务器可以转发这个 INVITE 请求到 Bob 的语音邮箱服务器。一个代理服务器可以同时向 N 个地方发送 INVITE 请求。这种并发寻找就是传说中的分流（forking） 。在这个例子中，200（OK）应答通过两个代理并且发送到 Alice 的 softphone 上，Alice
24、 的softphone 收到这个应答，停止振铃，并且标志电话 Bob 已经接听。最后，Alice 的电话发送一个确认消息，ACK，到 Bob 的 SIP 电话来确认接收到了这个最后的 200（ok）应答。在这个例子中，ACK 信号是直接由 Alice 的 softphone 发送到 Bob 的 SIP phone 上，跨过了两个代理服务器。这是因为两个端点（Alice 和 Bob）通过 INVITE/200(OK)的请求应答包中的 Contact 包头域都知道互相之间的地址了，这个地址是最开始发起 INVITE 请求的时候所不知道的。所以，不需要两个代理服务器再查找对方的地址了，所以代理服务器
25、不参与接下来的通话流了。这就完成了一个完整的使用 INVITE/200/ACK 三方握手来建立 SIP 会话的过程。会话建立过程中的细节描述再 13 节由描述。现在，Alice 和 Bob 的媒体会话开始了，他们通过发送刚才建立会话所交换的 SDP 包中约定的互相明白的媒体包来进行会话。一般情况下，端到端的媒体包和 SIP 信号控制包通过不同的通讯路径来发送。在会话中，Alice 或者 Bob 都可以改变他们自己的媒体会话属性。这个可以通过发送一个包含新媒体属性描述的 re-INVITE 请求来完成。这个 re-INVITE 是捆绑在一个现有的会话的，这样参与会话的对方可以明白这是要改变现有的
26、会话属性而不是新建立一个会话。对方收到这个 re-INVITE 请求后，会发送一个 200（OK）应答表示接受这个改变。请求方通过一个 ACK 来表示接受了对方的这个 200(OK)应答。如果对方不同意这个媒体属性变化，他会发送一个错误的应答比如 488（暂时不能进行） ，这个也会收到发起者的一个 ACK 响应。不管怎样，就是是 re-INVITE 的失败也不会影响到现有的会话原有的会话还可以用上次的媒体会话属性继续。可以在 14 节找到会话属性更改的细节说明。在通话结束的时候，Bob 首先断开（挂机 hangs up） ，并且发送一个 BYE 的消息。这个BYE 的消息将直接送到 Alice
27、 的 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 ans
28、wered, and forking.）基于这样的原因，SIP 请求的处理通常根据是否 INVITE 请求进行分类，INVITE 类和非 INVITE 类请求分开处理。结束会话的细节可以在 15 节查到。24.2 节描述了图 1 中使用的全部消息详细解释。在某些情况下，所有会话中的包都继续通过代理转发会很有用。比如，如果 代理服务器希望在 INVITE 之后继续保持 SIP消息流，他会在 INVITE 中增加一个头域（Record-Route）包含一个 URI 指向这个代理服务器的 hostname 或者 IP 地址。这个消息会被 Bob 的 SIP 电话和 Alice 的 softphon
29、e 所接到（因为 Record-Route 头域将在 200(OK)应答中被送回） ，并且在会话中一直保存。那么 代理服务器就可以继续接收和转发 ACK,BYE,给 BYE 的 200（OK）应答。每一个代理都可以单独决定是否接收 INVITE 以后的后续消息，并且这些后续消息都可以被发送到那些决定接收后续消息的代理服务器。这种情况通常发生在提供 mid-call 业务的代理服务器上。登记服务是另一个常用的 SIP 操作。登记服务是 代理服务器知道 Bob 当前地址的一个方法。在初始化的时候，或者每隔一段时间，Bob 的 SIP 电话发送 REGISTER 消息给 的一个注册服务器。REG
30、ISTER 消息包含了 Bob 当前登陆服务器的 SIP 或者SIPS 的 URI（sip:） （转换成为 Contact 域中的 SIP 或者 SIPS URI） 。登记服务器登记这个映射，这个叫做绑定（binding） ，写到一个数据库里边，叫做定位服务（location service） ，这个数据库可以被 的代理服务器使用。通常登记服务器和代理服务器是做在一起的。一个很重要的概念就是 SIP 服务器的差别在逻辑上，并非在物理上的差别。Bob 并没有限定非得在一个单个设备上发起注册。比如，他家里的 SIP 电话和公司的 SIP电话都可以注册。这些消息在定位服务（location ser
31、vice）中保存，并且允许代理服务器通过不同的手段查找 Bob。同样的，不同的用户也可以在同一个设备上同时注册。定位服务（location service）是一个逻辑概念。他是让代理服务通过输入一个 URI 来查询到底应该向哪里转发请求。可以简单通过用户注册来建立这个定位服务所需要的资料，也可以通过其他方法。可以通过其他任意的地址映射方式来实现定位服务。最后在 SIP 中需要注意的是，注册服务只是用来提供路由收到的 SIP 请求的，它并不做请求的身份认证的判定。在 SIP 中授权和认证可以通过建立在基于请求/应答的模式上的上下文相关的请求来实现，也可以使用更底层的方式来实现（具体在 26 节有
32、描述） 。完整的注册 SIP 消息描述例子在 24.1 节。其他 SIP 的操作，比如检查 SIP 服务器的负载，或者使用客户端使用可选项（OPTIONS） ，或者用 CANCEL 取消一个未决的请求，在后续的章节中会介绍。5、协议的结构SIP 是一个分层的协议，意思是说 SIP 协议由一组相当无关的处理层次组成，这些层次之间只有松散的关系。协议分成不同层次来描述是为了能够更清晰的表达，在同一个小节里有功能的公共要素的交叉描述。本协议并没有规定一个具体的实现。当我们说一个要素”包含”某一个层，我们的意思是这个要素复核这个层定义的规则。不是 SIP 每一个要素都一定包含每一个层。此外，SIP 定
33、义的要素是逻辑上的要素，不是物理要素。一个物理的实现可以实现不同的逻辑要素，或许甚至是基于串行事务处理原理。SIP 最底层的是它的语法和编码层。编码方式是采用扩展的 Backus-Naur Form grammar(BNF 范式)。完整的 BNF 描述在 25 节；第 7 节有简要的 SIP 消息结构描述。第二层是传输层。它定义了一个客户端如何发送请求和接收应答，以及一个服务器如何接收请求和发送应答。所有的 SIP 要素都包含一个通讯层。第 18 节有通讯层的描述。第三层是事务层。事务是 SIP 的基本组成部分。一个事务是客户发送的一个请求事务（通过通讯层）发送到一个服务器事务，连同服务器事务
34、的所有的该请求的应答发送回客户端事务。事务层处理应用服务层的重发，匹配请求的应答，以及应用服务层的超时。任何一个用户代理客户端（user agent client UAC）完成的事情都是由一组事务构成的。有关事务的讨论在第 17 节有描述。用户代理包含一个事务层，来实现有状态的代理服务器。无状态的代理服务器并不包含事务层。事务层包含一个客户元素（可以认为是一个客户事务）和一个服务器元素（可以认为是一个服务器事务） ，他们都可以用一个有限状态机来处理特定的请求。在事务层之上是事务用户（TU） 。每一个 SIP 实体，除了无状态代理，都是一个事务用户。当一个 TU 发出一个请求，它首先创建一个客户
35、事务实例（client transaction instance）并且和请求一起发送，这包括了目标 IP 地址、端口号、以及发送请求的设备。TU 可以创建客户事务，也可以取消客户事务。当客户取消一个事务，它请求服务器终止正在处理的事务，并且回滚状态到该事务开始前的状态，并且产生指定的该事务的错误报告。这是由CANCEL 请求完成的，这个请求有自己的事务，并且包含一个被取消的事务（第 9 节） 。SIP 要素，包含，用户代理客户端和服务器，无状态和有状态代理服务器和注册服务器，包含一个可以互相区别的核心（Cores） 。Cores ，除了无状态代理服务器，都是事务用户。UAC(用户代理客户端)和
36、 UAS(用户代理服务端) 的 cores 的行为依赖于实现，对所有的实现来说，有几个公共的原则（第 8 节） 。对 UAC 来说，这些规则约束请求的建立；对 UAS来说，这些规则约束请求的处理和应答。由于注册服务在 SIP 中是一个重要的角色，所以UAS 处理 REGISTER 请求有一个特别的名字：登记员（registrar ，登记服务器） 。第 10 节描述了 UAC 和 UAS 的对 REGISTER 实现的 core（核心）行为。第 11 节描述了 OPTIONS的 UAC 和 UAS 的 core 实现，这个 OPTIONS 用来检测 UA 的处理能力的（UA-user agent
37、） 。小虎 2006-05-25 00:03在对话中，有其他的相关会被发送。一个对话是一个持续一定时间的两个用户之间的端到端的 SIP 关系。对话过程要求两个用户代理之间的信息是有序的而且请求被正确路由传输的。在这个规范中，只有 INVITE 请求可以用来建立会话。当一个 UAC 在一个对话中发出请求的时候，它不仅遵循第 8 节描述的一般 UAC 规则而且也遵循对话中的请求规则。第12 节讲述了对话并且讨论了对话的创建和维持，以及在对话中创建一个请求。SIP 中最重要的方法就是 INVITE 方法，它用来在不同的参与者中创建会话使用。一个会话由一组参与者，他们之间用于交流的媒体流组成。第 13
38、 节讲述了这些会话的创建初始化过程，以及创建一个或一组对话。第 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 它指向了一个具有定位服务的主机
39、，这个主机可以把 URI 映射成为用户真正物理位置的 URI。通常情况下，定位服务器是通过登记服务来建立的。一个 AOR 经常被认为是一个用户的”公共地址”Back-to-Back UserAgent:背对背的用户代理（ B2BUA）是一个逻辑实体，它就像用户代理服务器（UAS ）一样接收和处理请求。为了决定该如何应答一个请求，B2BUA 就像 UAC一样工作，并且发出请求。但是它不像代理服务器（proxy） ，它维持对话状态，并且参与已经建立的对话中的每一个请求。由于它是直接的 UAC 和 UAS 的串连，所以，不需要对他有额外的定义。Call：呼叫，一个呼叫是一个非正式的术语，它是指在端点
40、之间一个一些通讯行为，通常用于建立多媒体对话。Call Leg: 对话的别名；在本规范中没有使用。Call Stateful: 如果一个代理服务器（proxy）保存一个对话的状态（从最开始的 INVITE 到对话终结的 BYE） ，那么这个代理服务器就是请求有状态的。一个请求有状态（call stateful）的代理服务器也一定是事务有状态的，但是事务有状态的不一定是请求有状态的。Client：客户端。一个客户端是一个任意的网络元素，它发出 SIP 请求和接收 SIP 应答。客户端可能会也可能不会和人交互。用户代理客户端（UAC）和代理服务器都是客户端。Conference: 一个包含多个参与
41、方的多媒体会话（见后） 。Core：核心。核心定义了 SIP 实体的特定类别。比如定义了一个有状态和无状态的代理服务器，一个用户代理或者注册服务器（registrar） 。所有的核心，除了无状态代理服务器，都是事务用户。Dialog:对话，一个对话是持续一段时间的两个 UA 之间的端到端的 SIP 关系。一个对话由SIP 消息建立，就像用 2xx 响应 INVITE 请求。我们用 Call identifier，local tag（本地 tag） ，remote tag（对方 tag）来标志一个对话，一个对话在 RFC 2543 中被正式叫做 CALL LEG.Downstream: 它是事务
42、中的消息传递方向。它特指从 UAC 到 UAS 的请求流的方向， Final Response：终结响应。一个响应终端 SIP 事务的应答，和事务中间的临时响应相反。所有的 2xx，3xx，4xx，5xx，6xx 响应都是终结响应。Header：头。头域是在 SIP 消息头部用来描述这个 SIP 消息信息的部分。它由一堆头域字段组成。Header Field:头域字段。头域字段是在 SIP 消息头域的字段。一个头域字段可以由多个头域字段行组成。一个头域字段由一个头域名和（零个或多个）头域值组成。多个头域值用,分割。某些头域字段只能有单个值，比如结果域（result）就只能有一个值。Header
43、 Field Value:头域值。一个头域值是一个单个的值，一个头域字段可以有 0 个或者多个头域值。Home Domain：宿主机。一个提供 SIP 服务的主机。一般指的是在登记服务中指明的记录地址中的 URI 的主机。Informational Response:提示应答。和临时应答一样。Initiator, Calling Party, Caller: 用 INVITE 初始一个会话（和对话）的那方。一个 caller 从发出 INVITE 请求建立对话开始，到对话终止都一直是这个角色。Invitation: 一个 INVITE 请求。Invitee,Invited User,Calle
44、d Party, Callee:被叫方。收到 INVITE 请求并且建立会话的那方。一个被叫方从收到 INVITE 请求起，到终止 INVITE 建立的对话结束，都称作被叫方。Location Service: 定位服务。定位服务是用来给 SIP 转发或者代理服务器确定被叫方可能的位置使用的。它包含一张绑定了 address-of-record 的表，被叫方可能有 0 到多个记录。绑定的记录可以通过多种渠道添加和删除；本规范定义了 REGISTER 方法来更新绑定表。Loop：环路。当请求抵达一个代理服务器，代理服务器转发这个请求，当这个请求再次来到同一个代理服务器，就称之为环路。当第二次抵达
45、的时候，RequestURI 中包含了上次抵达的资料，并且由于并没有什么东西可以改变转发的策略，这样就导致这个请求还会再次被转发回来。环路请求是错误的，所以，处理程序需要检测和防止协议中出现的环路请求。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
46、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 会手工配置一个对外的
