第一篇：SIP中的SDP offer-answer交换初探

1.引言

SDP的offer/answer模型本身独立 与于使用它的高层协议。SIP是使用offer/answer模型的应用之一。RFC 3264 [3] 定义了offer/answer模型，但没有规定使用那个SIP消息来携带一个offer或answer。这些被定义在SIP基本部分（RFC3261）及其扩展RFCs中。

理论上，任何SIP消息的正文中都可以包含会话描述部分。但是，一个SIP中的会话描述并不一定是一个offer 或一个answer,只有符合在SIP标准RFCs中所描述的规则的会话描述才会被解释为一个offer或一个answer。目前，这些关于如何处理 offer/answer模型的规则被定义为若干个RFCs中

offer/answer模型定义会话的更新。在SIP中，对话（dialog）用于将offer/answer交换及其要更新的会话联系起来。换句话 说，只有在某个SIP对话中进行的offer/answer交换，才能更新该对话所管理的会话。

2、六种Offer/Answer交换模式

在SIP消息中承载offer/answer的规则定义在RFC 3261[1], RFC 3262 [2] 以及RFC 3311 [4]中。在这些RFCs中定义了六种在SIP消息中交换offer/answer的模式。

模式1和模式2是在RFC3261中定义 的，用于不支持可靠临时响应消息（1xx-rel）的SIP实体之间的会话建立。

模式1：UAC在INVITE请求中携带一个 offer, UAS在200 INVITE响应中返回answer。这是最常用的一种模式。

模式2：UAC在INVITE请求中没有携带 offer。UAS在200 INVITE响应中携带一个offer，UAC通过ACK返回answer。这种模式通常用于3PCC中。

模式

3、模式

4、模式5都是在RFC3262中 定义的，可用在支持100rel（可靠临时响应）扩展的SIP实体之间。其中模式

3、模式4可用于会话建立。模式5只能用于会话参数更新。它们利用 1xx-rel响应消息来携带offer或answer来建立会话。

模式3：UAC在INVITE请求中携带一个offer, UAS在1xx-rel响应中返回answer。这样，在呼叫完成之前（UAC没有收到200 INVITE消息）会话已建立。此后，会话参数还可以被更新，具体见模式5及模式6。模 式4： UAC在INVITE请求中没有携带offer。UAS在1xx-rel可靠响应中携带一个offer，UAC通过PRACK返回answer。同样地，在呼叫完成之前（UAC没有收到200 INVITE消息）会话已建立。此后，会话参数还可以被更新，具体见模式6。

模式5：当UAC与UAS采用模式3建立会话 后，呼叫并未完成（见模式3）。之后，可以使用模式5对已建立的会话参数进行更新：UAC在PRACK请求中携带一个新的offer, UAS在200 PRACK响应中返回answer。这样，会话参数便被更新。

模式6在RFC3311中定义，主要用于在早期 对话中更新已建立的会话参数，会话可能是通过模式3，也可能是通过模式4建立的。

模式6还可以对会话进行多次更新。例如，之前已通过模 式5更新过的会话还可以使用模式6更新；甚至通过模式6更新过的会话还可以再次使用模式6更新。模 式6：UAC（或UAS）发送UPDATE请求其中携带一个新的offer, AS（或UAC）在200 UPDATE中返回一个offer。这样，会话参数便被更新。注意，UAS或UAC在发送UPDATE进行会话更新之前，必须保证之前的会话更新过程已经 完成。也就是说，发出的offer已经收到answer，或者收到的offer已经产生了answer。

3.总 结

INVITE方法提供了会话建立过程。

在 没有100rel选项时，会话建立过程非常简单，只能使用200INVITE响应消息传送会话描述，这些会话描述可能是answer(模式1),也可能是 offer（模式2）。无论使用何种模式，会话都只能呼叫完成后才能建立，在呼叫完成之前和呼叫完成之后只能有一个会话 – 用于最终通话的常规会话，因而，不能建立所谓的“早期媒体会话”。

在引入100rel选项后，会话建立过程变得复杂，通过可靠的临时消 息消息也可以传送会话描述，这些会话描述可能是answer(模式3),也可能是offer（模式4）。模式3和模式4都能够在呼叫完成前建立会话。并且 在呼叫完成之前，这些会话还可以被更新。这样就能够建立与常规会话不同的“早期媒体会话”，完成回铃音的产生等功能。

PRACK方法可 用于更新已建立的会话的参数（模式5）

UPDATE方法可用于多次更新已建立的会话的参数（模式6），发起更新的可以是UAC也可以是 UAS。SIP中的早期媒体early media与回铃音

1、早期媒体

无论是在PSTN还是在VoIP网络中，一个呼叫的最终目的让两个用户进行交谈（conversation）。这里我们将由用户之间的交谈所产生的 媒体称为常规媒体（“regular media”）。

早期媒体（“early media”）是与常规媒体相比而言的。

通常，主叫用户发起呼叫后用户交谈并不会立即开始（甚至可能最终没有开始），等待时间一般是几秒到几十秒，这完全取决于被叫用户的何时应答。在被叫 应答之前，主叫用户与网络之间也可以有媒体流产生，与常规媒体相区别，这种媒体被称为早期媒体。

最典型的早期媒体就是回铃音。其他形式的早期媒体还有排队提示等等。早期媒体通常都是单向的（网络>主叫），在SIP中也可能会有双向的早期媒体。

2、早期媒体的传送

要传送媒体首先要建立一个媒体会话（Session）。建立媒体会话实际上就是通过SDP offer/answer交换进行就会话的媒体参数进行协商的一个过程。在SIP中，媒体会话的建立过程通常首先伴随着一个SIP对话（Dialog）的 建立过程，一般情况下，媒体会话和SIP对话是同时建立的（通过SIP 200或ACK消息携带SDP answer）。这种情况下，媒体会话直到被叫用户摘机以后才能建立起来，只能用户传送用户媒体，显然无法传送早期媒体。

要传送早期媒体，必须在SIP对话尚未完全建立之时，即所谓的SIP早期对话状态，完成媒体会话的建立。

怎样在早期对话状态建立媒体会话呢？SIP中支持两种做法。

这两种做法的关键不同在于：是否将传送早期媒体的会话与传送之后的通话媒体的会话明确地划分清楚，区别开来。具体到协议上看，两种做法都利用了 200之前的 SIP消息，比如1xx-rel、PRACK、Update等等，来传送SDP offer/answer，但是这些SDP offer/answer在SIP消息中的标明类型和处理指示是不同的。做法1没有明确区分出用于早期媒体的会话，实际上始终只有一个会话。具体到协议上看，用于建立（或修改）这个会话的SDP offer/answer 在SIP消息中的处理指示都是“Session”。做法2专门建立一个用于传送早期媒体的会话，并称之为早期会话（“early-session”）。具体到协议上看，用于建立（或修改）早期会话的 SDP offer/answer SIP 消息中的处理指示是“early-session”。并且，在一个SIP消息中可以同时携带处理指示分别为“Session”和“early-session”的两个SDP消息，各自独立地用于早期会话的协商和正常会话的协商。

在做法1中，用同一个会话（在不同的时间段里）来传送早期媒体和通话媒体。在被叫摘机之前，这个会话可用于传送早期媒体，在被叫摘机之后，这个会话 又用于传送通话媒体。倘若早期媒体和通话媒体的参数不同的话，需要重新进行媒体传输参数的协商，这需要一定的时间，可能会带来媒体删剪（media clipping）的问题。在做法2中，同时会存在两个会话，分别用于传送早期媒体和通话媒体，在被叫摘机之后，终端可以迅速从早期会话切换到正常会话，不会带来媒体删剪的问题。

根据它们的适用场景的不同，这两种做法分别被称为网关模式和应用服务器模式。

3、回铃音的产生

一个呼叫被发起之后，当被叫终端振铃时，主叫也会听到某种声音，提示正在等待被叫应答，这就是所谓回铃音。回铃音通常是某种标准的音频信号，也可能 是被叫用户指定的某种特殊的声音文件，例如音乐等等。在PSTN中，回铃音通常是被叫的本地交换机产生，然后通过已建立的单向话路传送给主叫话机，由主叫 话机播放给主叫。

在SIP网络中，被叫侧可以早期媒体的形式向主叫提供回铃音（如果被叫侧不提供回铃音，则主叫SIP终端会在本地产生回铃音）。究竟使用前面所述的 两种做法的那一种来传送早期媒体，下面分别讨论。3.1．网关模式

网关模式适用于被叫（即UAS）为一个SIP网关的情形。具体的可能的情况通常如下图所示：一个用户在SIP终端上呼叫一个PSTN用户，这个呼叫 通过了一个SIP网关。就SIP呼叫而言，网关是被叫。

在这里，回铃音是由PSTN网产生的。但是在SIP域，SIP网关需要以早期媒体的形式将从PSTN网络收到的回铃音媒体传送给主叫SIP终端。

这种情况下，从SIP域来看，回铃音媒体流和之后的被叫媒体流的产生是同源的，都在SIP网关上。当被叫用户摘机时，回铃音媒体流自然地变成了用户 媒体流，因此可以使用网关模式，而不会带来媒体删剪的问题。信令流程如下图：

其中消息简单说明如下：

1)INVITE请求中含有SDP offer，其处置类型为“Session”。网关收到INVITE后向PSTN发送IAM消息，然后在PCM话路上收到回铃音，同时在信令上收到ACM消息。

2)183响应中含有SDP answer，其处置类型为“Session”。

此时，UAC与网关之间媒体会话建立，同时将回铃音在这个会话上传送给UAC。3)UAC发送PRACK 4)网关返回针对PRACK的200响应。

5)被叫用户应答，网关收到ANM后向SIP UAC返回200 INVITE响应。同时到SIP UAC上的会话上的回铃音自动变成了从PSTN上收到的用户话音。主被叫用户开始双向通话 6)SIP UAC发送ACK。3.2．应用服务器模式

应用服务器模式适用于被叫（即UAS）是一个应用服务器的情形。具体的可能的情况通常如上图所示：一个SIP用户希望由运营商网络（而非终端）来产 生回铃音。运营商通常使用网络上的一个MRF资源提供回铃音，并且需要一个应用服务器其来控制回铃音的产生。

这种情况下，回铃音媒体流与之后的被叫媒体流分别在MRF与被叫SIP终端上产生，显然是不同的源。如果使用网关模式的话，将回铃音媒体切换为被叫 媒体流必须在会话上进行媒体更改，媒体更改不能立即完成，这将会带来媒体删剪的问题。

使用应用服务器模式，则是同时建立了两个会话，将回铃音媒体切换为被叫媒体流可以通过将当前会话从早期会话切换到正常会话上即可，能够立即完成。信令流程如下图：

简单说明如下： 1)INVITE请求中携带一个SDP作为常规会话的offer 其Supported头域中包含一个选项标签“early-session”，表示主叫终端支持早期会话。

2)INVITE请求中携带之前收到的offer 3)183响应中携带一个SDP作为常规会话的answer。4)183中含有两个SDP：

a)一个是之前从被叫那里收到的，作为常规会话的answer； 此时常规会话被建立，但并没有媒体被传送。b)另一个作为要建立的早期会话的的offer.5)PRACK中携带一个SDP，作为早期会话的answer 此时早期会话被建立，且有被早期媒体（回铃音）传送。6)AS向被叫发送PRACK 7)被叫向AS返回200 PRACK 8)AS向主叫返回200 PRACK 9)被叫摘机，向AS发送200响应

10)AS向主叫发送200响应

此时常规会话上将会有媒体传送，主叫UA播放常规会话上的媒体。

4、关于目前多媒体彩铃的实现的简单说明

目前中国网通及中国移动的多媒体体彩铃业务的实现都主要采用了网关模式的实现方案（详细流程参见相关技术规范），原因是很多SIP终端都不支持 “early-session”选项标签，无法使用应用服务器模式。

实际上，采用网关模式实现彩铃会导致媒体删剪等一些问题，最终应该会逐步过渡到理想的方案 – 应用服务器模式。

SIP Using SDP with Offer/Answer Model http://blog.sina.com.cn/s/blog_4b839a1b010092tl.html 根据RFC3261-13.2.1所述，SIP使用的Offer/Answer模型是建立在对话环境下的。RFC中还特意对Offer/Answer交互 有限制： 1.初始Offer必须在INVITE消息或者第一个可靠的非失败型响应中。注：当时RFC3261中可靠效应只有2**，接下来将讲到1**（除100外）也可为可靠性效应。

2.如果初始Offer在INVITE消息中，Answer必须出现在一个可靠的非失败型响应中。可能在1**中就带有Answer（但该Answer必须与 之后的2**中的一致），UAC将忽略同一事务之后出现的回应中的Answer。

3.如果初始Offer出现在第一个可靠的非失败型响应中，Answer必须出现在对该响应的确认消息中（ACK）。

4.如果已经发送或接受对于第一个Offer的Answer，UAC可以继续发送新的Offer；相反的，如果没有确认对前一个Offer的Answer，不 能发送新的Offer。

5.如果已经发送或接受对于初始Offer的Answer，UAS禁止在之后同一个事务的响应消息中带上新的Offer。

根据RFC3262-5所述，对于Offer/Anwer模型引入了新的扩展。

1.如果INVITE消息带有Offer，UAS必须在一个可靠的非失败型的响应中提供Answer。这将在呼叫完成之前建立好会话。同样，Answer可以 出现在1**中，因为RFC3262提供了PRACK方法来保证1**消息为可靠消息。

2.如果UAC接收到1**中的Offer，必须在PRACK方法中带有Answer。但是如果UAC收到1**中的Answer，则可能在PRACK带上新 的Offer。如果UAS接收到PRACK中的Offer，则必须在2**中带上Answer。

3.如果Offer/Answer交互成功的话，在INVITE事务没有完成之前也能建立好会话。

4.如果在1**中带有Offer的话，UAS在没有收到对1**的确认之前不能发送2**。

根据RFC3264所述，Offer建立媒体选择项（高层如SIP提供），而Answer端可以接受或拒绝，取决于高层。UA可以通过新的 Offer/Answer交互来进行会话更新，但旧的Offer/Answer交互未结束之前不可发起新的Offer。

1.发起初始Offer：虽然SDP(RFC4566)允许在一个SDP消息中支持多个会话，但具有Offer/Answer模型的SDP消息只能包含一个对 话描述。2.Offer可以包含0个或更多的媒体流（每个媒体流使用一个“m=”行和相关的属性来描述的）。0个媒体流代表只是连接，之后可以通过新的Offer来更 新会话。

3.构建单点传播媒体Offer：1）媒体流方向，包含recvonly、sendrecv（默认）、sendonly及inactive。但需要注意的是在 RTP协议中，RTCP不会受该方向影响，即任何设置情况下均处于工作状态。

4.对于recvonly和sendrecv方向的媒体流来说，Offer中的端口号码和地址指示了提供方接受媒体流的地方。对于sendonly方向的媒体 流来说，Offer中的端口号码和地址间接指示了提供方接受RTCP的地方（除非特殊说明，RTCP的端口比对应RTP端口高一位）。如果端口是0，则只 提供、拒绝或终止媒体流。

5.对于sendonly和sendrecv流来说，Answer可能对于同一编码指示不同的负载类型编号（Payload Type Number），在这种情况下，Offer必须采取Answer中的编号值。

6.对于RTP流，媒体描述需要使用“a=rtpmap”来映射RTP媒体负载类型编号，如果没有对应的“a=rtpmap”行，则使用当前默认的配置（RFC 1890）。7.“m=”行中所列的编码必须采取优先顺序排列。

8.对于Offer中的每个“m=”行，Answer中必须有对应的“m=”行。Answer中的“t=”行必须与Offer行的一致。

9.拒绝某个Offer的流，该流的端口值必须设置为0.10.Offer如果是sendonly，则Answer必须为recvonly或者inactive；Offer如果是recvonly，则Answer必须 为sendonly或者inactive；Offer如果是sendrecv，则Answer必须为sendrecv、recvonly、sendonly或者inactive；Offer如果是inactive，则Answer必须为inactive。

11.即使Offer是senonly型，Answer的地址和端口也必须存在，因为需要传送RTCP。

12.如果是RTP，Offer使用特定负载编号来与某编码相对应，Answer应该保持这种对应关系。13.Answer中的“m=”行编码应具有优先顺序，以便Offer能采用最高优先级的选项。但即便如此，建议Answer采取与Offer相同的优先顺序。14.ptime指示接受的打包间隔，但并不要求双方的ptime值一致。但发送媒体流时应该按照ptime指示的打包间隔来发送。

15.如果是RTP流，Answer应该采用Offer提供的负载编码编号。16.当Offer收到Answer后，必须采用Answer中的媒体类型中的一个，最后应该采用排列的第一个。

第二篇：SIP

SIP请求方法：

INVITE:

ACK:发起会话请求 证实已收到对于INVITE请求的最终响应。与INVITE消息配套使用。

REGISTER:将自己的地址信息注册至服务器上

OPTIONS: 查询服务器(对方代理)的能力

CANCEL:

BYE:

UPDATE:

INFO:

REFER:

PRACK:

COMET: 取消尚未完成的请求。对于已完成的无影响 结束会话 允许客户更新一个会话的参数而不影响当前的会话状态 用于传递会话中产生的与会话相关的控制信息 呼叫转移，用于指示接收方通过使用在请求中提供的联系地址信息联系第三方 与ACK相同，但用于临时响应 用来检验能够用于会话的资源，使用户代理根据资源可用性决定是否接受呼

取消订阅请求 REINVITE: 用于改变会话参数 SUBSCRIBE: 用于发起订阅请求，向远端断点预定其状态变化的通知 UNSUBSCRIBE:

NOTIFY: 用于通告当前资源状态，发送消息通知预订者它所预定的状态的变化

MESSAGE: 用于通过在消息体中承载即时消息内容实现即时通信

SIP响应码：

1xx: Provisional,2xx: Success,3xx: Redirection

4xx: Client Error

5xx: Server Error

6xx: Global Error 临时响应---表明请求已经接收,正在继续进行处理。成功响应---请求已经成功收到,理解并接受。重定向响应---还需要附加的操作才能完成这个请求，本请求转发到其他的服务器 上处理 客户端错误---请求包含错误的格式或者不能在这个服务器上完成 服务器错误---服务器不能正确的处理这个显然合法的请求 全局错误---请求不能被任何服务器处理。

SIP消息头域：

1.通用头域：

用于请求消息或响应消息.域名只有在协议版本改变时才可有效的扩展

Call-ID: a84b4c76e66710@pc33.atlanta.com

Call-ID =(“Call-ID” | “i”)”:”local-id”@”host

Local-id = 1*uric

全局唯一标识。代表了一种在两个或多个用户之间共享的SIP信令的关系。

标识一个特定邀请和与这个邀请相关的所有后续事务

一般使用经过加密的随机标识(可通过随机字串和主机名或IP地址混和产生)

From: Alice;tag=1928301774

From =（“From” | “f”）“：”（name-addr | addr-spec）*（“；”addr-params）

addr-params=tag-param

tag-param=“tag=”UUID

UUID=1*（hex | “-”）

“tag”可出现在From头域中，当共享同一个SIP地址的用户的两个实例使用同一个Call-ID发出邀请时，必须使用“tag”。全局唯一的经过加密的至少32比特的随机数。“tag”参数作为一种通用机制，用于区分由一个SIP-URL标识的用户的多个实例。

出于安全性考虑，禁止包含“transport-param”，“maddr-param”，“ttl-param”，“headers”。接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前，应将这些元素删除。

To: BobTo =（“To” | “t”）“：”（name-addr | addr-spec）*（“；”addr-params）如果请求包含了不止一个Via头域，则必须增加“tag”参数。

出于安全性考虑，同From。

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds

Via指示请求迄今为止所走的路径。

Branch参数: 使用magic cookie”z9hG4bK”打头.其它部分是对“To, From, Call-ID头域和Request-URI”按一定的算法加密后得到。这7个字母是一个乱数cookie（定义成为7位的是为了保证旧版本的RFC2543实现不会产生这样的值）.Contact:sip:192.168.2.89:5090

Contact=(“Contact” | “m”)”:”

(“*” |(1#((name-addr | addr-spec)[*(“;”contact-params)][comment])))

name-addr=[display-name]”<”addr-spec”>”

addr-spec=SIP-URL | URI

display-name=*token | quoted-string

contact-param=“q”“=”qvalue|“action””=””proxy”|”expires”“=”delta-seconds| <”>SIP-date<”>| extension-attribute

extension-attribute = extension-name [“=”extension-value]

q：表明所给的位置的相对重要性，“qvalue”从0到1，值高参考性大。

action：只用于使用REGISTER登记时。表明是否客户希望服务器代理或者重定向用户想要的未来的请求。

expires：表明URI的活动时间。注意与Expire头域的联系：如果Contact 中存在expires参数，则使用其表示的时间；若不存在，则使用Expire头域所表示的时间。

CSeq: 314159 INVITECseq =“Cseq” “：” 1*DIGITMethod 为一个32位的无符号整数，它的初始值是任意的，但必须小于等于2**31。

每发出一个新的SIP请求，CSeq++1,遵循严格单调增加的守则.派生的请求须有同样的Cseq值 用户代理服务器必须记住同一个Call-ID的INVITE请求的最高序列数.低于此序列数的任何INVITE请求，服务器作出响应后放弃。

“Method”值使得客户将对于INVITE请求的响应和对于一个CANCEL请求的响应（一般是200响应）区分开来

Encryption:Encryption= “Encryption” “:””pgp”pgp-eparams

pgp-eparams=1#(pgp-version | pgp-encoding)

pgp-encoding=”encoding””=””ascii” | token

表明内容经过了加密处理，此加密为端到端的加密。加密部分默认为二进制。Expires = “Expires” “:”(SIP-date | delta-seconds)Expires头域给出了消息内容活动的日期和时间 此域的值可以是一个SIP-date，或者是一个以秒为单位的数字形式。此头域只用于INVITE、REGISTER方式。在REGISTER请求中，它指示登记的有效期限。在INVITE请求中，主叫方可以限制邀请的有效性 Record-Route: sip:p1.example.com;lr Expires:

Record-Route = “Record-Route” “:” 1#name-addr

Record-Route请求和响应头域可以被任何服务器加到请求中并坚持以后的同一个Call leg的请求使用同样的路径。它包含了一个唯一可达的Request-URI来指示代理服务器。每一个代理服务器将它的Request-URI加到序列的开始。

严格路由: Strick Routing.要求接收到的消息的request-URI必须是自己的URI，然后将第一个Route头域“弹”出来，并把其中的URI作为新的request-RUI，然后把该消息路由给该URI。松散路由：lr: Louse Routing1，Proxy首先会检查消息的request-URI是不是自己属于自己所负责的域。如果是，它就会通过定位服务将该地址“翻译”成具体的联系地址并以此替换掉原来的request-URI；否则，它不会动request-URI。2，Proxy检查第一个Route头域中的URI是不是自己的，如果是，则移除之。3，前面两项都是准备工作，下面该进行真正的路由了。如果还有Route头域，则Proxy会把消息路由给该头域中的URI，否则就路由给request-URI。Timestamp:

Timestamp = “Timestamp” “:” *(DIGIT)[ “.” *(DIGIT)][delay] Delay =(DIGIT)[ “.” *(DIGIT)] Timestamp通用头域指示客户何时向服务器发送请求。

此头域的值只对客户有用。客户使用timestamp头域来计算到达服务器的round-trip时间，以便调整重传的timeout时间。

Date: Tue, 15 Nov 1994 08:12:31 GMTDate = “Date” “:” HTTP-dateHTTP-date只能是rfc1123-date。

rfc1123-date = wkday “,” SP date1 SP time SP “GMT”

date1 = 2DIGIT SP month SP 4DIGIT;day month year(e.g., 02 Jun 1982)

wkday = “Mon” | “Tue” | “Wed” | “Thu” | “Fri” | “Sat” | “Sun”

month = “Jan” | “Feb” | “Mar” | “Apr” | “May” | “Jun” | “Jul” | “Aug” | “Sep” | “Oct” | “Nov” | “Dec”

(GMT)：Greenwich Mean Time

当请求或者响应被第一次发送时，Date头域指示发送日期和时间.重传将使用与相应的初始同样的Date头域。

Accept:

用于INVITE、OPTIONS和REGISTER请求方式中，指示在响应中能够接收的媒体的类型（缺省值为application/sdp）

Accept-Encoding:与Accept头域相似，但它限制在响应中可接受的content-codings

客户用此头域向服务器指示它接收原因短语、通话描述符或者消息体中所承载的状态响应时所使用的语言。Proxy可以用此域来帮助选择呼叫的目的地。

2.实体头域

描述消息体内容的长度、格式和编码类型等属性.可用于请求消息或响应消息

Content-Encoding:

Content-Encoding=(“Content-Encoding” | “e”)”:” 1#content-coding

指示适用于实体消息体的其他的内容编码，指示为了获得Content-Type头域所给出的media-type，必须使用的编码方案。主要用于压缩消息体，而不丢失它底层的媒体类型的标识。如服务器不能识别Content-Encoding, 则发送415响应，在Accept-Encoding头域中列出可以接受的编码.Accept-Language:

Content-Length:142Content-Length =(“Content-Length” | “l”)”:” 1*DIGIT 指示消息体的长度。形式上以八个比特为一个字节。Content-Length的值应为非负数，0表示没有消息体。

服务器如果收到一个不包含Content-Length域的UDP请求，那么它便认为此请求压缩了包的剩余部分,直接关闭TCP连接

服务器如果收到一个包含有Content-Length域的UDP请求。但它的值比消息体的实际长度大，客户则应产生一个400类的响应。

Content-Type: application/sdpContent-Type=（“Content-Type”| “c”）“：”media-type 指示发送给接收者的消息体的媒体类型

3.请求头域：

只用于请求消息.用来传递有关请求或客户机本身的一些附加信息，对请求进行补充说明 Subject:

Subject=（“subject” | “s”）“：”*TEXT-UTF8

提供了一个摘要，或指示了呼叫的实际情况，使得不必分析通话描述便可过滤呼叫。User-Agent:CERN-LineMode/2.15 libwww.teniu.ccment)

包含了关于发送初始请求的客户用户代理的消息

用于统计目的，跟踪违反协议的情况、用户代理的自动认可的情况，以便在编制响应时避免特定用户代理的限制。用户代理应在请求中包含此头域。

Organization:Organization =“Organization” “：”*TEXT-UTF8

表明发送请求或者响应的实体所属的组织。它可以由位于某组织边界的代理来加入。客户软件可以使用此头域来过滤呼叫。

Contact:可出现在INVITE、ACK和REGISTER请求中，1XX、2XX、3XX和485响应中。提供了一个URL，用户可以通过此URL来进行进一步的通信 INVITE和ACK请求：Contact域表明请求从哪个位置发起； Authorization = “Authotization”“：”“pgp”*（“；”pgp-response）

pgp-response =realm | pgp-version | pgp-signature | signed-by | nonce

pgp-signature = “signature”“=”quoted-string

signed-by = “signed-by”“=”<”>URI <”>

pgp-signature：由ASCII码包裹的PGP标识，出现在“BEGIN PGP MESSAGE”和“END PGP MESSAGE”之间，没有版本标识。如果重新侵入并不担心的话，服务器可以不产生nonce。不产生nonce避免了增加其他形式的请求，401响应和可能的ACK消息，也减少了round-trip时间的耽搁。realm：复制于相关的www.teniu.ccment] [“:” “duration””=”delta-seconds]

用在503（Service Unavailable）响应中，向提出申请的客户指示，此服务预计多长时间无效。用在404（Not Found）,600(Busy)和603（Decline）响应中，指示被叫方多长时间内再次有效。此域的值可以是SIP-date和以秒为单位的整数值。

Server:CERN/3.0 libwww.teniu.ccment)Product = token [“/” product-version] product：所使用的服务器；

comment：服务器中的重要部分。

包含了关于UAS用来处理请求的软件的信息.如果响应通过代理来前转，那么代理禁止修改此Server响应头域，它应该包含一个Via头域。

Warning:

Warning= “Warning”“：” 1#warning-value

Warning-value = warn-code SP warn-agent SP warn-text

Warn-code = 3DIGIT

Warn-agent =（host[“：”port]）| pseudonym

Warn-text= quoted-string

包含了关于响应状态的其他信息.一个响应中可以有多个Warning头域

Allow:Allow = “Allow”“：” 1#Method

列出了Request-URI指示的资源所支持的方式集.目的是通知接收者与资源相联系的有效方式。在405（Method Not Allowed）响应中必须有Allow头域；在OPTIONS响应中应该有Allow头域。

Unsupported:Unsupported = “Unsupported” “：”1#option-tag

列出了服务器不支持的特征。（只用于420响应）

第三篇：SIP协议描述

SIP协议描述

一、SIP协议的背景和功能

SIP(会话初始协议)的开发目的是用来帮助提供跨越因特网的高级电话业务。因特网电话（IP电话）正在向一种正式的商业电话模式演进，SIP就是用来确保这种演进实现而需要的NGN（下一代网络）系列协议中重要的一员。

SIP是IETF标准进程的一部分，它是在诸如SMTP（简单邮件传送协议）和HTTP（超文本传送协议）基础之上建立起来的。它用来建立，改变和终止基于IP网络的用户间的呼叫。为了提供电话业务它还需要结合不同的标准和协议：特别是需要确保传输（RTP），与当前电话网络的信令互连，能够确保语音质量（RSVP），能够提供目录（LDAP），能够鉴权用户（RADIUS）等等。

SIP被描述为用来生成，修改和终结一个或多个参与者之间的会话。这些会话包括因特网多媒体会议，因特网（或任何IP网络）电话呼叫和多媒体发布。会话中的成员能够通过多播或单播联系的网络来通信。SIP支持会话描述，它允许参与者在一组兼容媒体类型上达成一致。它同时通过代理和重定向请求到用户当前位置来支持用户移动性。SIP不与任何特定的会议控制协议捆绑。

本质上，SIP提供以下功能：

名字翻译和用户定位：无论被呼叫方在哪里都确保呼叫达到被叫方。执行任何描述信息到定位信息的映射。确保呼叫（会话）的本质细节被支持。

特征协商：它允许与呼叫有关的组（这可以是多方呼叫）在支持的特征上达成一致（注意：不是所有方都能够支持相同级别的特征）。例如视频可以或不可以被支持。总之，存在很多需要协商的范围。

呼叫参与者管理：呼叫中参与者能够引入其它用户加入呼叫或取消到其它用户的连接。此外，用户可以被转移或置为呼叫保持。

呼叫特征改变：用户应该能够改变呼叫过程中的呼叫特征。例如，一呼叫可以被设置为“voice-only”，但是在呼叫过程中，用户可以需要开启视频功能。也就是说一个加入呼叫的第三方为了加入该呼叫可以开启不同的特征。

二、SIP网络元素

SIP中有两个要素。SIP用户代理和SIP网络服务器。用户代理是呼叫的终端系统元素，而SIP服务器是处理与多个呼叫相关联信令的网络设备。

用户代理本身具有一客户机元素（用户代理客户机UAC）和一服务器元素（用户代理服务器UAS）。客户机元素初始呼叫而服务器元素应答呼叫。这允许点到点的呼叫通过客户机-服务器协议来完成。SIP服务器元素提供多种类型的服务器。有三种服务器形式存在于网络中--SIP有状态代理服务器，SIP无状态代理服务器和SIP重定向服务器。由于呼叫者未必知道被呼叫方的IP地址或主机名，SIP服务器的主要功能是提供名字解析和用户定位。可以获得的是email形式的地址或与被呼叫方关联的电话号码。使用该信息，呼叫者的用户代理能够确定特定服务器来解析地址信息--这可能涉及网络中很多服务器。

SIP代理服务器接收请求，决定将这些请求传送到何处，并且将它们传送到下一服务器（使用下一跳路由原理）。在网络中可以有多跳。

有状态和无状态代理服务器的区别是有状态代理服务器记住它接收的入请求，以及回送的响应和它转送的出请求。无状态代理服务器一旦转送请求后就忘记所有的信息。这允许有状态代理服务器生成请求以并行地尝试多个可能的用户位置并且送回最好的响应。无状态代理服务器可能是最快的，并且是SIP结构的骨干。有状态代理服务器可能是离用户代理最近的本地设备，它控制用户域并且是应用服务的主要平台。

重定向服务器接收请求，但不是将这些请求传递给下一服务器而是向呼叫者发送响应以指示被呼叫用户的地址。这使得呼叫者可以直接联系在下一服务器上被呼叫方的地址。

三、SIP协议的实现机制

SIP是一个分层结构的协议，这意味着它的行为根据一组平等独立的处理阶段来描述，每一阶段之间只是松耦合。协议分层描述是为了表达，从而允许功能的描述可在一个部分跨越几个元素。它不指定任何方式的实现。当我们说某元素包含某层，我们是指它顺从该层定义的规则集。

不是协议规定的每个元素都包含各层。而且，由SIP规定的元素是逻辑元素，不是物理元素。一个物理实现可以选择作为不同的逻辑元素，甚至可能在一个个事务的基础上。

SIP的最底层是语法和编码。它的编码使用增强Backus-Nayr形式语法（BNF）来规定。

第二层是传输层。它定义了网络上一个客户机如何发送请求和接收响应以及一个服务器如何接收请求和发送响应。所有的SIP元素包含传输层。

第三层是事务层。事务是SIP的基本元素。一个事务是由客户机事务发送给服务器事务的请求（使用传输层），以及对应该请求的从服务器事务发送回客户机的所有响应组成。事务层处理应用层重传，匹配响应到请求，以及应用层超时。任何用户代理客户机（UAC）完成的任务使用一组事务产生。用户代理包含一个事务层，有状态的代理也有。无状态的代理不包含事务层。事务层具有客户机组成部分（称为客户机事务）和服务器组成部分（称为服务器事务），每个代表有限的状态机，它被构造来处理特定的请求。

事务层之上的层称为事务用户（TU）。每个SIP实体，除了无状态代理，都是事务用户。当一个TU希望发送请求，它生成一个客户机事务实例并且向它传递请求和IP地址，端口，和用来发送请求的传输机制。一个TU生成客户机事务也能够删除它。当客户机取消一个事务时，它请求服务器停止进一步的处理，将状态恢复到事务初始化之前，并且生成特定的错误响应到该事务。这由CANCEL请求完成，它构成自己的事务，但涉及要取消的事务。

SIP通过EMAIL形式的地址来标明用户地址。每一用户通过一等级化的URL来标识，它通过诸如用户电话号码或主机名等元素来构造（例如：SIP:usercompany.com）。因为它与EMAIL地址的相似性，SIP URLs容易于用户的EMAIL地址关联。

SIP提供它自己的可靠性机制从而独立于分组层，并且只需不可靠的数据包服务即可。SIP可典型地用于UDP或TCP之上。

SIP提供必要的协议机制以保证终端系统和代理服务器提供以下业务：

● 用户定位

● 用户能力

● 用户可用性

● 呼叫建立

● 呼叫处理

● 呼叫前转，包括：（1）等效800类型的呼叫，（2）无应答呼叫前转，（3）遇忙呼叫前转，（4）无条件呼叫前转

● 呼叫号码传递，该号码可以是任何命名机制。

● 个人移动性，例如通过一个单一的、位置无关的地址来到达被呼叫方，即使被呼叫方改变了终端。

● 终端类型的协商和选择：呼叫者可以给出选择如何到达对方，例如通过因特网电话，移动电话或应答业务等。

● 终端能力协商

● 呼叫者和被呼叫者鉴权

● 不知情和指导式的呼叫转移

● 多播会议的邀请

当一用户希望呼叫另一用户，呼叫者用INVITE请求初始呼叫，请求包含足够的信息用以被呼叫方参与会话。如果客户机知道另一方的位置它能够直接将请求发送到另一方的IP地址。如果不知道，客户机将请求发送到本地配置的SIP网络服务器。如果服务器是代理服务器它将解析被呼叫用户的位置并且将请求发送给它们。有很多方法完成上步，例如搜索DNS或访问数据库。服务器也可以是重定向服务器，它可以返回被呼叫用户的位置到呼叫客户机用以它直接与用户联系。在定位用户的过程中，SIP网络服务器当然能够代理或重定向呼叫到其它的服务器，直到到达一个明确地知道被呼叫用户IP地址的服务器。

一旦发现用户地址，请求就发送给该用户，此时将产生几种选择。在最简单的情况，用户电话客户机接收请求——也就是，用户的电话振铃。如果用户接受呼叫，客户机用客户机软件的指定能力响应请求并且建立连接。如果用户拒绝呼叫，会话将被重定向到语音邮箱服务器或另一用户。“指定能力”参照用户想启用的功能。例如，客户机软件可以支持视频会议，但用户只想使用音频会议，那则只会启用音频功能。

SIP还具有另外两个有重要意义的特征。第一个是有状态SIP代理服务器具有分割入呼叫或复制入呼叫的能力，从而可以同时运行几个扩展分支。第一个应答的分支接受呼叫。该特征在用户工作在两位置之间（例如实验室和办公室）或者同时对经理和其秘书振铃时是非常便利的。

第二个特征是SIP独特的返回不同媒体类型的能力。举个用户联系公司的例子。当SIP服务器接收到客户机的连接请求，它能够通过WEB交互式语音响应页面来返回到顾客的客户机，该页面具有可获得的部门分支或提供在列表上的用户。点击适当的链接后将发送一请求到所点击选择的用户从而建立起呼叫。

四、SIP消息的组成

有两种类型的SIP消息：

● 请求：从客户机发到服务器

● 响应：从服务器发到客户机

SIP请求消息包含三个元素：请求行、头、消息体。

SIP响应消息包含三个元素：状态行、头、消息体。

请求行和头域根据业务、地址和协议特征定义了呼叫的本质，消息体独立于SIP协议并且可包含任何内容。

SIP定义了下述方法：

INVITE——邀请用户加入呼叫。

BYE——终止一呼叫上的两个用户之间的呼叫。

OPTIONS——请求关于服务器能力的信息。

ACK——确认客户机已经接收到对INVITE的最终响应。

REGISTER——提供地址解析的映射，让服务器知道其它用户的位置。

INFO——用于会话中信令。

五、结束语

SIP协议凭借其简单、易于扩展、便于实现等诸多优点越来越得到业界的青睐，它正逐步成为NGN（下一代网络）和3G多媒体子系统域中的重要协议，并且市场上出现越来越多的支持SIP的客户端软件和智能多媒体终端，以及用SIP协议实现的服务器和软交换设备。虽然SIP协议目前还不成熟，但可以预见SIP必定是将来网络多媒体通信中的明星。

第四篇：SIP优势总结

SIP优势总结

1、自动回呼功能。

启用该功能后，如果您呼叫的对象没有接听到电话，系统会记录下此次呼叫，一旦对方使用了VOIP电话，系统就会判定该对象已经回来并向双方的电话发起振铃，摘机后就可以建立通话。该功能解决了中国人不爱使用电话留言功能的问题。

2、语音点播功能。

说明如下：

1、将重要文件或通知录制成文件存放在VOIP系统中并挂接上特殊的号码，用户只要拨打该号码并输入密码验证，就可以收听录音；

2、如果企业有常用的培训录音，也可以放在系统中，用户拨打培训电话号码，就可以远程反复收听培训录音了；

3、对于紧急重要的通知，也可以通过系统制作录音，并通过群呼的方式向所有VOIP话机呼叫。

3、企业统一通信录应用。

公司内部网页可集成“企业统一通信录”，其中包含各部门员工通信录名片，甚至合作单位通信录名片，通讯录名片可以链接多个用户号码（如VOIP分机号码、普通固定电话号码、移动手机号码等）。

员工上班时以专有用户身份登录系统，除了可以查询公共通讯录外，还可以建立自己私人的通讯录。员工需要电话呼叫同事或客户时，只需要在“企业统一通信录”上找出呼叫对象，点击后，双方听到电话振铃后摘机便可开始对话。

该应用革新了企业的通信管理概念，避免了传统电话通信中找号码、拨电话的麻烦，解决了企业传统通信录在更新、管理过程中容易泄密的问题。

4、邮件自动呼叫应用

将企业的邮件系统集成自动呼叫功能，员工在阅读邮件的时候，只需点击邮件相关人员，系统就可在该员工和相关人员之间建立语音连接，甚至可同时连接多方电话，组成电话会议共同讨论邮件内容。

该应用的显著特点是提高业务处理效率。员工不必翻查通信录，直接点击相关联系人即可快速解决问题。

5、电话会议应用。

系统提供基于Web的电话会议系统，该系统以功能模块方式集成在软交换服务器中，不需要额外添加电话会议设备。

利用此套电话会议系统可方便的召开跨部门、跨地区会议，而无需占用会议室、无需长途旅行费用开支、无需向运营商支付通讯费用。

此外，针对黑龙江人寿目前应用的PLOYCOM和AVCON视频会议系统，VOIP通信系统也可以通过三种方式实现其价值：

第一种，由于PLOYCOM能够提供模拟接口，所以VOIP系统可通过语音网关的模拟接口与之对接，作为VOIP系统的任何一部分机都可以加入视频会议系统（只有语音）；

第二种，通过PLOYCOM和AVCON视频会议系统的媒体服务器所提供的标准H.323协议，与VOIP系统互联也可加入视频会议系统（只有语音）。

第三种，由于视频会议系统价格昂贵，在部署时只是有针对性的部署在重点地市。而相对来讲VOIP通信系统所提供的电话会议成本低、部署广，可以作为视频电话会议系统的一个有效补充。

6、网络安全。

1、号码认证体系。我们的系统提供了严格的号码认证体系，除了针对用户名、密码进行认证外，还可以针对对方的IP地址进行认证。

2、加密体系。我们的系统有一套非常完善的加密措施来保证通话安全。

3、跨网间通话质量保证。我们的系统有措施确保在不同网络运营商之间通话质量良好。

7、电话录音功能。

保险行业通常有一些业务是需要录音的，比如电话回访，目的是保证回访员的工作质量；此外对于一些催款部门，电话录音也可以作为催款参考凭据。我们的系统可以方便实现这种应用，软交换服务器录音后可保存当本地硬盘。服务器上安装数据库工具，可以实现对录音文件的查询管理。如果录音文件过大，还可以设置定期将录音文件传送到公司其它存储设备上。

8、“帮助单系统”自动呼叫应用。

给IT部门的“帮助单系统”集成自动呼叫功能，当IT部门员工收到“帮助请求单”后，可以直接点击帮助请求人，系统将自动呼叫并接通对方电话。

9、IT部门专用Call Center 该应用利用软交换服务器集成的多级可编程IVR功能，可以把企业IT应用系统的故障帮助请求分门别类，分别引导；企业员工只需要拨打IT部门公布的服务号码（VOIP号码），其呼叫请求即被引导、转接到合适的IT服务坐席或语音录音。通过“IT部门专用Call Center”应用，可以将各地市人寿分公司的IT部门员工都纳入到统一的服务体系，实现多中心联网服务，形成网络服务的优势。

该应用无需特别的设备投资，却可以充分利用各地区的IT人力资源，给企业创造更多的服务价值，体现IT部门高效、完美的服务形象。

此外，我们系统即将推出高智能终端，可以通过液晶触摸屏实现通讯录查找、自动呼叫、电话录音等功能。这些功能在H323系统中是不容易实现的。

第五篇：品质SIP定义

制作SIP的重点及注意事项

1.什么是SIP？

SIP是STANDARD INSPECTION PROCEDURE 是缩写，翻译成中文检验标准指导书，是为确保产品的性能，寿命、可靠性、安全性、经济性，尺寸和外观是否满足明确和隐含要求而制定的一个准则。

2.分类

检验标准一般分为内部检验标准和外部检验标准，外部检验标准又可分为客户检验标准和行业检验标准。

3.检验标准的定义

a． 保证产品质量的一致性。b． 为公司节约成本。c． 减少社会资源浪费。d． 方便客户寻找替代品。

e． 为检验员判断产品某一特性是否合格提供依据。

4.检验标准书包括的项目

4.1基本项目：

公司名称，文件名称，发行日期，发行版本，文件编号，产品名称，产品料号，检验工程站别名称，检验项目，检验标准，检验方法，检验环境和设施，检验频率，制定者，审核人。

5.重要项目说明

a． 产品名称，产品料号，文件编号一方面为了查找，另一方面区别与其他产品，相当于一种产品的代号。

b． 检验方法包括目视、量测、实验。其中量测和实验是借用二次元投影机，厚薄规推拉力计等仪器设备来完成检验。

c． 使用表单通常是检验者记录检验结果的表单，记录内容包括：产品名称、规格、批量、编号、使用仪器、设备、检验时间、检验人、检验结果数据、检验结果。

d． 检验频率是指对总样本数抽多少的一个比率或间隔多长时间抽取一定的样本数。

e． 严重度分危害，严重，轻微。危害指对人的生命安全造成一定影响；严重指完全或部分影响使用，轻微指不会影响使用，但存在一些瑕疵使客户的满意度降低。

f． 制定栏目填写制定此SIP的品质工程师自己的名字，审核和核准栏目为品质部门的主管填写。

g． 尺寸是客户对某一产品的长度，宽度，弧度等特性的要求，其检验标准栏填写客户要求这些特性和允许的公差。

6.如何制作一份完整的SIP? 6.1.如何识别产品的质量特性中的固有特性和不合格特性？ 产品的质量特性分为固有特性和不合格特性。固有特性指客户在外观，结构，性能，可靠度等方面可区分的要求，及制造过程中不可避免的特征，比如产品某些位置的凹凸，不连续，产品组合后的间隙等都属于质量特性中的固有特性。不合格特性是指制造过程中某些不可避免的特征超出规定要求和产品上增加了其他物质，包括脏污、杂色、刮伤、间隙过大等属于此类。

识别方法：前后制程对比，与样品对比，产品互相比较，与检验标准对比，组装后结构后功能是否正常，了解所有制程的控制特性及相关的品质特性，新产品开发阶段，或试产一种从未接触的新产品，在没有标准和样品提供的前提下，了解所有制程的检验特性及相关的品质特性至关重要。

6.2.了解客户要求

每种产品有其独自应具备的特性，并且不同的产品出于不同的使用环境和用途其具备的特性也不尽相同。比如一个水杯是用来装水，因而必须具备不漏水的特性；一部手机的显示屏是用于查阅，储存信息，消费者对屏幕的关注度特别高，因而手机的显示屏的外观要求特别高，不允许刮伤、污点之类的缺陷。只有认真去了解客户和消费者的使用环境，相应的品质标准也就可以制定出来，当然不同层次的消费群体对产品的要求也会有差异，一般老百姓关注的是所买的产品能否用，价格是否便宜，而那种生活品味相对有点高的消费群体不仅注重性能，还要在外观上看着舒服。但不论哪种消费群体，他们都会关注所买的产品是否能够使用，通过这么了解识别可制定通用的检查项目和应客户群体同所制定的特需检验项目。

6.3.检验标准的要求

a．尽量量化，对于边界清晰，有一定的面积的缺陷用尺寸数据描述。

b．必须含盖客户所有的明确或潜在的要求，获得要求常用的方式是客户提供的检验标准。c．某些特殊检验项目无法量化，通常用签限度样板的方式弥补，作为检验的标准。

d．同样的缺陷，在不同强度的光源，视距，角度下其看到的结果不一样，因而必须把这些检验方法标准化。

7.注意事项

a．了解公司制程和客户端制程，若有必要，通过一定的途径了解终端客户的使用环境。b．了解公司每个制程会出现的问题点及客户最关心的问题点。任何客户最关心的问题点通常是能否使用，因而对影响使用的关键项目必须重点管控。比如：产品的某些位置有毛边干涉了组装，这种毛边就是重点管控的项目。不同产品，不同位置的管控重点不一样，因而必须了解后续制程。

c．检验项目和标准的描述应该即专业又通俗易懂，对于用文字描述无法说清楚的地方可附加图片补充说明。比如有些产品分A，B，C几面管控，B,C面都是侧面，只是位置不同而已，此种情形用附图说明的方式比较好。

d.一个公司同一时期内的标准指导书格式和排版必须保持一致，字体风格和大小必须保持一致。

e.在制作SIP过程中切忌照搬COPY，这种方法很容易出现制作的内容与实际产品不符，若想节约时间，可先把有用的内容用不同的字体颜色标出来再进行COPY。便于识别哪些是有用于目前产品的标准，假如在一份SIP中修改成需要的SIP，先把不需要的内容删除，修改需要的部分用不同颜色做记号区分。

f．当相连项目的内容一样时可做合并，整个SIP的排版看起来会显得美观。g．在设定检验频率时首先单个产品的所需工时及检验员的工作量，频率过低的抽检起不到对产品品质状况的有效掌控。频率过高的抽检会超出检验员的负荷，达不到指导的目的。h．为确保每份SIP的格式一样，先确定每个项目内容所需要的空间，然后设定好页边距及内部格式，设定好的格式必须锁定保存，不要随意改动。当做第二份SIP时可直接COPY此份SIP的格式。

i．当做完一份SIP后，不要盲目打印，格式是否符合要求以打印预览中看到的效果为准。与样品对比是否能一眼看出差异，了解哪些面是用户经常看到的面，了解影响程度，了解送给客户产品的样品。

制定：