SIP协议详解-优快云博客

7 SIP Message

SIP 协议是一个基于文本的协议，使用 UTF-8 字符集（RFC2279[7]）。
一个 SIP 消息既可以是一个从客户端到服务器端的请求，也可以是一个从服务器端到客户端的一个应答。

即使在字符集上和语法细节上有所不同，请求（ 7.1）还是应答（ 7.2）消息都基于RFC2822 格式的。（SIP 允许包头域不是标准的 RFC2822 包头域）。这两种消息类型都由一个start-line，一个或者多个header fields，an empty line indicating the end of the header fields
（一个指定头字段末尾的空行），一个optional message-body组成。

generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line / Status-Line

start-line、每一个message-header line，the empty line、都必须由回车换行组成（CRLF）。即使消息中文没有，也必须有一个空行跟随。

7.1 Requests

SIP 请求是根据start-line中的 Request-Line 来区分的。一个 Request_line 包含method name, Request－UR，protocol version，用单个空格（SP）间隔开。

Request-Line = Method SP Request-URI SP SIP-Version CRLF

Method：这个规范定义了6种方法:

Register：用于登记联系消息；
INVITE,ACK,CANCEL：用于建立会话；
BYE：用于结束会话；
OPTIONS：查询服务器的负载；

SIP extensions, documented in standards track RFCs, may define additional methods.

Request-URI:Request-URI 是一个 SIP 或者 SIPS URI，他们在 19.1 节由描述，也可以是一个通用的 URI(RFC 2396[5])。它表明了这个请求所用到的用户或者服务的地址。Request-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 Responses

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。

While this specification suggests specific wording for the reasonphrase, implementations MAY choose other text, for example, in the
language indicated in the Accept-Language header field of therequest.（虽然本文档建议输出这个 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 Header Fields

SIP Header Fields 和 HTTP Header Fields在语法和语义上都比较类似。特别的， SIP 头域遵循[H4.2]关于消息头的语法的定义，并且遵循多行的扩展头域的规则。 (后者 is specified in HTTP withimplicit whitespace and folding)。这个规范遵循 RFC2234[10]，并且把清晰的空白和封装作为内在的语法规则。

[H4.2]也定义了具有相同域名的多个头域，他们的值是用逗号分开的列表，可以合并到一个头域中。这个也适用于 SIP，但是细节上略有不同，因为语法不同。实际上，任何 SIP的包头语法都是基于如下范式的：

header ＝ “ header-name” HCOLON header-value *(COMMA header-value)

这个允许合并在具有同一个域名的多个头域，到一个用逗号分割的单个头域中。 Contact头域除了当域值是”*”之外，都允许用逗号分割的列表。