消息的格式

SIP消息类型和消息格式

sip消息类型和消息格式

SIP是⼀个基于⽂本的协议,使⽤的是UTF-8字符集.

SIP消息主要分为两⼤类:

⼀类是由客户端发往服务器的请求消息(Request);

⼀类是由服务器发往客户端的应答消息(Response).

⼀个基本的SIP消息包括起始⾏、⼀个或多个头字段、说明头字段结束的空⾏和⼀个可选的消息体。

消息=起始⾏（包括请求⾏/状态⾏；请求⾏规定了请求的类别，⽽状态⾏指出了每个请求的状态，⽐如是成功还是失败。如果是失败的话还

要给出失败的原因或类型。）

*头字段

CRLF

[消息体]（消息⾸部给出了关于请求或应答的更多信息⼀般包括消息的来源、规定的消息接收⽅，另外还包括⼀些其他⽅⾯的重要信

息。消息体通常描述将要建⽴会议的类型包括所交换媒体的描述，但不具体定义消息体的内容或结构，其结构或内容使⽤另外⼀个协议

来描述，就是会话描述协议SDP。）

请求消息

请求⾏=⽅法+空格+请求地址+SIP版本号+空⾏

通过⼀个请求⾏作为起始⾏，请求⾏包括了⽅法名、请求的URL、协议版本号、中间⽤空格分开。

六种请求⽅法：

INVITE发出呼叫会话请求

ACKINVITE请求被最终请求

BYE释放⼀个呼叫会话

CANCEL取消挂起的呼叫

REGISTER登记注册⽤户代理

OPTIONS查询服务器能⼒

应答消息

状态⾏=SIP版本+空格+状态码+空格+相关⽂本短语+空⾏

SIP应答消息状态码与功能

类型状态码状态说明

临时应答(1XX)100Trying正在处理中

180Ringing振铃

181callbeingforwarder呼叫正在前向

182queue排队

181*sessionprogress会话进⾏

会话成功(2XX)200OK会话成功

重定向(3XX)300multiple多重选择

301movedpermanently永久移动

302movedtemporaily临时移动

305useproxy⽤户代理

380alternativeservice替代服务

请求失败(4XX)400badrequest错误请求

请求失败(4XX)400badrequest错误请求

401unauthorized未授权

402paymentrequired付费要求

403forbidden禁⽌

404notfound未发现

405methodnoallowed⽅法不允许

406notacceptable不可接受

407proxyauthenticationrequired代理需要认证

408requesttimeout请求超时

410gone离开

413requestentitytoolarge请求实体太⼤

414request-urltoolong请求URL太长

415unsupportedmediatype不⽀持的媒体类型

416unsupportedurlscheme不⽀持的URL计划

420badextension不良扩展

421extensionrequired需要扩展

423intervaltoobrief间隔太短

480temporarilyunavailable临时失效

481call/transactiondoesnotexist呼叫/事务不存在

482loopdetected发现环路

483toomanyhops跳数太多

484addressincomplete地址不完整

485ambiguous不明朗

486busyhere这⾥忙

487requestterminated请求终⽌

488notacceptablehere这⾥请求不可接受

491requestpending未决请求

493undecipherable不可辨识

服务器失败(5XX)500serverinternalerror服务器内部错误

501notimplemented不可执⾏

502badgateway坏⽹关

503serviceunavailable服务⽆效

504servertime-out服务器超时

505versionnotsupported版本不⽀持

513messagetoolarge消息太⼤

全局性错误(6XX)600busyeverywhere全忙

603decline丢弃

604doesnotexistanywhere不存在

606notacceptable不可接受

SIP应答代码(这个是详细的应答码解释)

应答码是包含了，并且扩展了HTTP/1.1应答码。并不是所有的HTTP/1.1应答码都适当应⽤，只有在折⾥指出的是适当的。其他HTTP/1.1

应答码不应当使⽤。并且，SIP也定义了新的应答码系列，6xx。

1临时应答1xx

临时应答，也就是消息性质的应答，标志了对⽅服务器正在处理请求，并且还没有决定最后的应答。如果服务器处理请求需要花200ms以

上才能产⽣终结应答的时候，它应当发送⼀个1xx应答。

注意1xx应答并不是可靠传输的。他们不会导致客户端传送⼀个ACK应答。临时性质的（1xx）应答可以包含消息体，包含会话描述。

1.1100Trying

这个应答表⽰下⼀个节点的服务器已经接收到了这个请求并且还没有执⾏这个请求的特定动作（⽐如，正在打开数据库的时候）。这个应

答，就像其他临时应答⼀样，种植了UAC重新传送INVITE请求。100(Trying)应答和其他临时应答不同的是，在这⾥，它永远不会被有状态

proxy转发到上⾏流中。

1.2180Ringing

UA收到INVITE请求并且试图提⽰给⽤户。这个应答应当出世化⼀个本地回铃。

1.3818CallisBeingForwarded(呼叫被转发)

服务器可以⽤这个应答代码来表⽰呼叫正在转发到另⼀个⽬的地集合。

1.4182Queued

当呼叫的对⽅暂时不能接收呼叫的时候，并且服务器决定将呼叫排队等候，⽽不是拒绝呼叫的时候，那么就应当发出这个应答。当被叫⽅

⼀旦恢复接收呼叫，他会返回合适的终结应答。对于这个呼叫状态，可以有⼀个表⽰原因的短语，⽐如：”5callsqueued;expectedwaiting

timeis15minutes”。服务器可以给出好⼏个182（Queued）应答告诉呼叫⽅排队的情况（⽐如排队靠前了等等）。

1.5183会话进度

183（SessionProgress）应答⽤于提⽰建⽴对话的进度信息。Reason-Phrase（表达原因的句⼦）、头域或者消息体可以⽤于提⽰呼叫进

度的更消息的信息。

2成功信息2xx

2成功信息2xx

这个应答表⽰请求是成功的。

2.1200OK

请求已经处理成功。这个信息取决于不同⽅法的请求的应答。

3转发请求3XX

3xx系列的应答是⽤于提⽰⽤户的新位置信息的，或者为了满⾜呼叫⽽转发的额外服务地点。

3.1300MultipleChoices

请求的地址有多个选择，每个选择都有⾃⼰的地址，⽤户或者（UA）可以选择合适的通讯终端，并且转发这个请求到这个地址。

应答可以包含⼀个具有每⼀个地点的在Accept请求头域中允许的资源特性，这样⽤户或者UA可以选择⼀个最合适的地址来转发请求。没有

未这个应答的消息体定义MIME类型。

这些地址选择也应当在Contact头域中列出（20.10节）。不同于HTTP，SIP应答可以包含多个Contact头域或者⼀个Contact头域中具有⼀

个地址列表。UA可以使⽤Contact头域来⾃动转发或者要求⽤户确认转发。不过，本规范没有定义⾃动转发的标准。

如果被叫⽅可以在多个地址被找到，并且服务器不能或者不愿意转发请求的时候，可以使⽤这个应答来给呼叫⽅。

3.2301MovedPermently

当不能在Request-URI指定的地址找到⽤户的时候，请求的客户端应当使⽤Contact头域(20.10)所指出的新的地址重新尝试。请求者应当⽤

这个新的值来更新本地的⽬录，地址本，和⽤户地址cache，并且在后续请求中，发送到这个/这些列出的地址。

3.3302MovedTemporarily

请求⽅应当把请求重新发到这个Contact头域所指出的新地址(20.10)。新请求的Request-URI应当⽤这个应答的Contact头域所指出的值。

在应答中的Expires(20.19节)或者Contact头域的expires参数定义了这个ContactURI的⽣存周期。UA或者proxy在这个⽣存周期内cache这

个URI。如果没有严格的有效时见，那么这个地址仅仅本次有效，并且不能在以后的事务中保存。

如果cache的Contact头域的值失败了，那么被转发请求的Request-URI应当再次尝试⼀次。临时URI可以⽐超时时间更快的失效，并且可以

有⼀个新的临时URI。

3.4305UseProxy

请求的资源必须通过Contact头域中指出的proxy来访问。Contact头域指定了⼀个proxy的URI。接收到这个应答的对象应当通过这个proxy

重新发送这个单个请求。305（UseProxy）必须是UAS产⽣的。

3.5380AlternativeService

呼叫不成⼯，但是可以尝试另外的服务。另外的服务在应答的消息体中定义。消息体的格式在这⾥没有定义，可能在以后的规范中定义。

4请求失败4xx

4xx应答定义了特定服务器响应的请求失败的情况。客户端不应当在不更改请求的情况下重新尝试同⼀个请求。（例如，增加合适的认证信

息）。不过，同⼀个请求交给不同服务器也许就会成功。

4.1400BadRequest

请求中的语法错误。Reason-Phrase应当标志这个详细的语法错误，⽐如”MissingCall-IDheaderfield”。

4.2401Unauthorized

请求需要⽤户认证。这个应答是由UAS和注册服务器产⽣的，当407（ProxyAuthenticationRequired）是proxy服务器产⽣的。

4.3402PaymentRequired

保留/以后使⽤

4.4403Forbidden

服务端⽀持这个请求，但是拒绝执⾏请求。增加验证信息是没有必要的，并且请求应当不被重试。

4.5404NotFound

服务器返回最终信息：⽤户在Request-URI指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的情况下，也会

产⽣这个应答。

4.6405MethodNotAllowed

服务器⽀持Request-Line中的⽅法，但是对于这个Request-URI中的地址来说，是不允许应⽤这个⽅法的。

应答必须包括⼀个Allow头域，这个头域包含了指定地址允许的⽅法列表。

4.7NotAcceptable

请求中的资源只会导致产⽣⼀个在请求中的Accept头域外的，内容⽆法接收的错误。

4.8407ProxyAuthenticationRequired

这个返回码和401（Unauthorized）很类四，但是标志了客户端应当⾸先在proxy上通过认证。SIP对认证的访问请参见26节和22.3节。

这个返回码⽤于应⽤程序访问通讯⽹关（⽐如，电话⽹关），⽽很少⽤于被叫⽅要求认证。

4.9408RequestTimeout

在⼀段时间内，服务器不能产⽣⼀个终结应答，例如，如果它⽆法及时决定⽤户的位置。客户端可以在稍后不更改请求的内容然后重新尝

试请求。

4.10410Gone

请求的资源在本服务器上已经不存在了，并且不知道应当把请求转发到哪⾥。这个问题将会使永久性的。如果服务器不知道，或者不容易

检测，这个资源消失是临时性质的还是永久性质的，那么应当返回⼀个404（NotFound）。

4.11413请求实体过⼤。

服务器拒绝处理请求，因为这个请求的实体超过了服务器希望或者能够处理的⼤⼩。这个服务器应当关闭连接避免客户端重发这个请求。

如果这个情况是暂时的，那么服务端应当包含⼀个Retry-After头域来表明这是⼀个暂时的故障，并且客户端可以过⼀段时间再次尝试。

4.12414Request-URITooLong

服务器拒绝这个请求，因为Request-URI超过了服务器能够处理的长度。

4.13415UnsupportedMediaType

服务器由于请求的消息体的格式本服务器不⽀持，所以拒绝处理这个请求。这个服务器必须根据内容的故障类型，返回⼀个

Accept，Accpet-Encoding,或者Accept-Language头域列表。UAC根据8.1.3.5节定义的⽅法处理这个应答。

4.14416UnsupportedURIScheme

服务器由于不⽀持Request-URI中的URI⽅案⽽终⽌处理这个请求。客户端处理这个应答参照8.1.3.5。

4.15BadExtension

服务器不知道在请求中的Proxy-Require(20.29)或者Require(20.32)头域所指出的协议扩展。服务器必须在Unsupported头域中列出不⽀持

的扩展。UAC处理这个应答请参见8.1.3.5

4.16421ExtensionRequired

4.16421ExtensionRequired

UAS需要特定的扩展来处理这个请求，但是这个扩展并没有在请求的Supported头域中列出。具有这个应答码的应答必须包含⼀个Require

头域列出所需要的扩展。

UAS不应当使⽤这个应答除⾮它真的不能给客户端提供有效的服务。相反，如果在Support头域中没有列出需要的扩展，服务器应当根据基

准的SIP兼容的⽅法和客户端⽀持的扩展来进⾏处理。

4.17423IntervalTooBrief

服务器因为在请求中设置的资源刷新时间（或者有效时间）过短⽽拒绝请求。这个应答可以⽤于注册服务器来拒绝那些Contact头域有效期

过短的注册请求。这个应答的⽤法和相关的Min-Expires头域在10.2.8,10.3,20.23节中介绍和说明。

4.18480TemporarilyUnavailable

请求成功到达被叫⽅的终端系统，但是被叫⽅当前不可⽤（例如，没有登陆，或者登陆了但是状态是不能通讯，或者有”请勿打扰”的标

记）。应答应当在Retry-After中标志⼀个合适的重发时间。这个⽤户也有可能在其他地⽅是有效的（在本服务器中不知道）。Reason-

Phrase(原因短句)应当提⽰更详细的原因，为什么被叫⽅暂时不可⽤。这个值应当是可以被UA设置的。状态码486（BusyHere）可以⽤来

更精确的表⽰本请求失败的特定原因。

这个状态码也可以是转发服务或者proxy服务器返回的，因为他们发现Request-URI指定的⽤户存在，但是没有⼀个给这个⽤户的合适的当

前转发的地址。

4.19481Call/TransactionDoesNotExist

这个状态表⽰了UAS接收到请求，但是没有和现存的对话或者事务匹配。

4.20482LoopDetected

服务器检测到了⼀个循环(16.3/4)

4.21483TooManyHops

服务器接收到了⼀个请求包含的Max-Forwards(20.22)头域是0

4.22484AddressInComplete

服务器接收到了⼀个请求，它的Request-URI是不完整的。在原因短语中应当有附加的信息说明。这个状态码可以和拨号交叠。在和拨号交

叠中，客户端不知道拨号串的长度。它发送增加长度的字串，并且提⽰⽤户输⼊更多的字串，直到不在出现484（AddressIncomplete）应

答为⽌。

4.23485Ambiguous

Request-URI是不明确的。应答可以在Contact头域中包含⼀个可能的明确的地址列表。这个提⽰列表肯囊个在安全性和隐私性对⽤户或者

组织造成破坏。必须能够由配置决定是否以404（NotFound）代替这个应答，⼜或者禁⽌对不明确的地址使⽤可能的选择列表。

给带有Request-URI的请求的⼀个应答例⼦：

sip::

SIP/2.0485Ambiguous

Contact:CarolLee

Contact:PingLee

Contact:

部分email和语⾳邮箱系统提供了这个功能。这个状态码和3xx状态码不同：对于300来说，它是假定同⼀个⼈或者服务有不同的地址选择。

所以对3xx来说，⾃动选择系统或者连续查找就有效，但是对485（Ambiguous）应答来说，⼀定要⽤户的⼲预。

4.24486BusyHere

当成功联系到被叫⽅的终端系统，但是被叫⽅当前在这个终端系统上不能接听这个电话，那么应答应当回给呼叫⽅⼀个更合适的时间在

Retry-After头域重试。这个⽤户也许在其他地⽅有效，⽐如电话邮箱系统等等。如果我们知道没有其他终端系统能够接听这个呼叫，那么应

当返回⼀个状态码600（BusyEverywhere）。

4.25487RequestTerminated

请求被BYE或者CANCEL所终⽌。这个应答永远不会给CANCEL请求本⾝回复。

4.26488NotAcceptableHere

这个应答和606（NotAcceptable）有相同的含义，但是只是应⽤于Request-URI所指出的特定资源不能接受，在其他地⽅请求可能可以接

受。

包含了媒体兼容性描述的消息体可以出现在应答中，并且根据INVITE请求中的Accept头域进⾏规格化（如果没有Accept头域，那么就是

application/sdp）。这个应答就像给OPTIONS请求的200(OK)应答的消息体⼀样。

4.27491RequestPending

在同⼀个对话中，UAS接收到的请求有⼀个依赖的请求正在处理。14.2描述了这种情况应当怎样解决。

4.28493Undecipherable

UAS接收到了⼀个请求，包含了⼀个加密的MIME,并且不知道或者没有提供合适的解密密钥。这个应答可以包含单个包体，这个包体包含

了合适的公钥，这个公钥⽤于给这个UAS通讯中加密包体使⽤的。细节描述在23.2节。

5ServerFailure5xx

5xx应答是当服务器本⾝故障的时候给出的失败应答。

5.1500ServerInternalError

服务器遇到了未知的情况，并且不能继续处理请求。客户端可以显⽰特定的错误情况，并且可以在⼏秒种以后重新尝试这个请求。

如果这个情况是临时的，服务器应当在Retry-After头域标志客户端过多少秒钟之后重新尝试这个请求。

5.2501NotImplemented

服务器没有实现相关的请求功能。当UAS不认识请求的⽅法的时候，并且对每⼀个⽤户都⽆法⽀持这个⽅法的时候，应当返回这个应答。

（proxy不考虑请求的⽅法⽽转发请求）。

注意405（MethodNotAllowed）是因为服务器实现了这个请求⽅法，但是这个请求⽅法在特定请求中不被⽀持。5.3502BadGateway

如果服务器，作为gateway或者proxy存在，从下⾏服务器上接收到了⼀个⾮法的应答（这个应答对应的请求是本服务器为了完成请求⽽转

发给下⾏服务器的）。

5.4503ServiceUnavailable

由于临时的过载或者服务器管理导致的服务器暂时不可⽤。这个服务器可以在应答中增加⼀个Retry-After来让客户端重试这个请求。如果没

有Retry-After指出，客户端必须就像收到了⼀个500（ServerInternalError）应答⼀样处理。

客户端（proxy或者UAC）收到503（ServiceUnavailable）应当尝试转发这个请求到另外⼀个服务器处理。并且在Retry-After头域中指定

的时间内，不应当转发其他请求到这个服务器。

的时间内，不应当转发其他请求到这个服务器。

作为503(ServiceUnavaliable)的替代，服务器可以拒绝连接或者把请求扔掉。

5.5504ServerTime-out

服务器在⼀个外部服务器上没有收到⼀个及时的应答。这个外部服务器是本服务器⽤来访问处理这个请求所需要的。如果从上⾏服务器上

收到的请求中的Expires头域超时，那么应当返回⼀个408（RequestTimeOut）错误。

5.6505VersionNotSupported

服务器不⽀持对应的SIP版本。服务器是⽆法处理具有客户端提供的相同主版本号的请求，就会导致这样的错误信息。

5.7MessageToLarge

服务器⽆法处理请求，因为消息长度超过了处理的长度。

6GlobalFailures6xx

6xx应答意味这服务器给特定⽤户有⼀个最终的信息，并不只是在Request-URI的特定实例有最终信息。

6.1600BusyEverywhere

成功联系到被叫⽅的终端系统，但是被叫⽅处于忙的状态，并不打算接听电话。这个应答可以通过增加⼀个Retry-After头域更明确的告诉呼

叫⽅多久以后可以继续呼叫。如果被叫⽅不希望提⽰拒绝的原因，被叫⽅应当使⽤603（Decline）。只有当终端系统知道没有其他终端节

点（⽐如语⾳邮箱系统）能够访问到这个⽤户的时候才能使⽤这个应答。否则应当返回⼀个486（BusyHere）的应答。

6.2603Decline

当成功访问到被叫⽅的设备，但是⽤户明确的不想应答。这个应答可以通过增加⼀个Retry-After头域更明确的告诉呼叫⽅多久以后可以继续

呼叫。只有当终端知道没有其他任何终端设备能够响应这个呼叫的势能才能给出这个应答。

6.3604DoesNotExistsAnywhere

服务器验证了在请求中Request-URI的⽤户信息，哪⾥都不存在

6.4606NotAcceptable

当成功联系到⼀个UA,但是会话描述的⼀些部分⽐如请求的媒体，带宽，或者地址类型不被接收。

606（NotAcceptable）应答意味着⽤户希望通讯，但是不能充分⽀持会话描述。606（NotAcceptable）应答可以在Warning头域中包含⼀

个原因列表，⽤于解释为何会话描述不能被⽀持。警告原因代码在20.43节中列出。

在应答中，可以出现⼀个包含媒体兼容性描述的消息体，这个消息体的格式根据INVITE请求中的Accept头域指出的格式进⾏规格化（如果

没有Accept头域，那么就是application/sdp），就像给OPTIONS亲求的200(OK)应答中的消息⼀样。

我们希望这些媒体协商不要经常需要，并且当⼀个新⽤户被邀请加⼊已经存在的会话的时候，这个媒体协商可能不需要。这取决于邀请的

初始化者是否需要对606（NotAcceptable）进⾏处理。

这个应答只有当客户端知道没有其他终端能够处理这个请求的时候才能发出。