sip RFC3261中文版 （一）

1、SIP协议介绍

Internet的许多应用都需要建立和管理一个会话，会话在这里的含义是在参与者之间的数据的交换。由于考虑到参与者的实际情况，这些应用的实现往往是很复杂的：参与者可能是在代理间移动，他们可能可以有多个名字，他们中间的通讯可能是基于不同的媒介（比如文本，多媒体，视频，音频等）－有时候是多种媒介一起交互。人们创造了无数种通讯协议应用于实时的多媒体会话数据比如声音，影像，或者文本。本SIP（会话初始协议）和这些协议一样，同样允许使用Internet端点（用户代理）来寻找参与者并且允许建立一个可共享的会话描述。为了能够定位精确的会话参与者，并且也为了其他的目的，SIP允许创建基础的network hosts（叫做代理服务器），并且允许终端用户注册上去，发出会话邀请，或者发出其他请求。SIP是一个轻形的，多用途的工具，可以用来创建，修改和终止会话，它独立运作于通讯协议之下，并且不依赖建立的会话类型。

2、SIP协议功能概况

SIP是一个应用层的控制协议，可以用来建立、修改、和终止多媒体会话（或者会议）例如Internet 电话。SIP也可以邀请参与者参加已经存在的会话，比如多方会议。媒体可以在一个已经存在的会话中方便的增加（或者删除）。SIP显示的支持名字映射和重定向服务，这个用于支持个人移动业务－用户可以使用一个唯一的外部标志而不用关系他们的实际网络地点。SIP在建立和维持终止多媒体会话协议上，支持5个方面：

用户定位： 检查终端用户的位置，用于通讯。

用户有效性：检查用户参与会话的意愿程度。

用户能力：检查媒体和媒体的参数。

建立会话：”ringing”,建立会话参数在呼叫方和被叫方。

会话管理：包括发送和终止会话，修改会话参数，激活服务等等。

              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 Descripotion 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（o’k）应答。在这个例子中，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节找到会话属性更改的细节说明。