Sip stack之Sip Message学习笔记

一．Sip Message

1.Sip Message Struct

Generic-message = start-line

*message-header

CRLF

[message-body]

Start-line = Request-Line/Status-Line

起始行、每一个包头行，空行、都必须由回车换行组成（CRLF）。即使消息中文没有，也必须有一个空行跟随。

1.1. Request-Line

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

Request-Line 由CRLF 结束。除了用作行结束标志以外，不允许CR 或者LF 出现在其他地方。在其他域中，不允许出现线形的空白

Method 这个规范规定了6 中方法：REGISTER 用于登记联系信息，INVITE，ACK,CANCEL 用于建立会话，

BYE 用于结束会话，OPTIONS 用于查询服务器负载。

Request-URI Request-URI 是一个SIP 或者SIPS URI。Request-URI 禁止包含空白字符或者控制字符，并且禁止用”<>”括上。

SIP-Version用SIP/2.0 替代HTTP/1.1中关于版本的规定，版本依赖，升级版本号。一个应用，发出的SIP 消息一定包含了SIP-Version “SIP/2.0”。

这个SIP 版本串是大小写不敏感的，但是在实现中必须发送大写。

1.2. Responses（Response with Status-Line）

Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF (除了最后用作结束标志以外，CR/LF 不允许出现在其他地方)

1xx：临时应答－请求已经接收，正在处理这个请求。

2xx：成功处理－请求已经成功接收，并且正确处理了这个请求。

3xx：重定向－还需要附加的操作才能完成这个请求，本请求转发到其他的服务器上处理。

4xx：客户端错误－－请求包含错误的格式或者不能在这个服务器上完成。

5xx：服务器错误－服务器不能正确的处理这个显然合法的请求。

6xx：全局错误－请求不能被任何服务器处理。

1.3. Header Fields

header = "header-name" HCOLON header-value *(COMMA header-value)

SIP 头域遵循[H4.2]关于消息头的语法的定义，并且遵循多行的扩展头域的规则(通过在这些行前面加一些SP 或 HT 实现)。

必须在允许合并在具有同一个域名的多个头域，到一个用逗号分割的单个头域中。Contact头域除了当域值是”*”之外，都允许用逗号分割的列表(相同域名的域之间的顺序非常重要，必须注意有些头域是跟顺序有关的（Route）)。

头域中的不同域名的相关顺序并没有什么意义()。

*强烈建议与路由相关的域（VIA,ROUTE,Record-Route,Proxy-Require,Max-Forwards,Proxy-Authorization等等）放在消息头的最前边，这样可以提高处理的速度

这个规则有几个例外，就是WWW-Authenticate,Authorization,Proxy-Authenticate,和Proxy-Authorization 头域。

域值格式是由分号分开的参数名和参数值的组合：

field-name: field-value *(;parameter-name=parameter-value)

虽然在域值里边可以有任意数量的parameter-name/parameter-value 对，但是不能允许有相同的parameter-name 存在（唯一性）。除了特别指出的头域之外，头域中的域名、域值、parameter name parameter-value 都是大小写不敏感的。标记词始终是大小写不敏感的。除非有特别的指定，引号串的字符串是大小写敏感的。

Contact: ;expires=3600 和CONTACT: ; ExPiReS=3600 相同。

下边的两个头域不相同：Warning: 370 devnull “Choose a bigger pipe”和Warning: 370 devnull “CHOOSE A BIGGER PIPE”不同

1.4. Bodies

Content-Type 头域指明消息中的internet 媒体类别; Content-Encoding 头域中指明消息正文采用某种形式的编码（encoding），比如压缩等。如果可行，消息体的字符集作为Content-type头域的值的一部分表达,如果发送方没有其他显示的字符集参数指出，媒体的文本”text”子类型会是缺省”UTF-8"

2.相关概念

呼叫（Call）、会议（Conference）、发起者、主叫（Initiator，Caller）、被邀请者、被叫（Invitee，Callee）、邀请（Invitation）、

同构请求/响应（Isomorphic request or response）、并行查询（Parallel search）、

Loop：环路(必须避免)。

呼叫支路（Call leg/Dialog）:(一个呼叫支路由Call-ID、T o以及From 之中的addr-spec和tag共同标识)

一个对话是持续一段时间的两个UA之前的端到端的关系.(由Call identifier, local tag(本地tag), remote tag(对方tag)标志)

对于UAC来说，本地标签就是创建对话的初始请求的From头中的tag，远端标签就是创建对话的响应的From头中的tag。UAS则相反。

*当UA 在对话外发出一个请求时，它只包含From tag，对话根据应答创建完成，这个应答在To头域提供对话的另一Tag。

（SIP请求的分支意味着一个单个请求可以创建多个对话，这也是需要两个对话方的标志的原因）

Tag的生成规则：1)当UA 产生一个TAG并添加到请求或应答时，它必须是唯一的。

会话（Session）:根据SDP 描述"一个多煤体会话是一个由多媒体发送方和接受方组成的集合,并且包括发送方和接受方之间的数据"

SIP事务（SIP Transaction）:（事务是由一个呼叫支路（Call leg）中的Cseq 顺序号来标识的。一个ACK请求与对应的INVITE请求拥有相同的CSeq，构成自己的事务）

事务用户Transaction User(TU): 在Transaction 层之上的协议层. TU 包括了UAC core, UAS core, proxy core.

用户代理/终端系统UA:包含UAC和UAS.

UAC 用来产生请求, 可以由一些外部的东西来发出请求和处理应答（比如按下一个按钮）;

UAS 接收并处理应答请求。

UAC和UAS处理依赖两个特点：a)基于请求或应答是否在一个对话内b）基于请求的方法

3.消息的基本组成

3.1 Request 消息的基本组成

一个SIP Request请求必须至少包含如下头域：TO，FROM，Cseq，Call-ID，Max_Forwards，Via（这些消息包含了消息的地址，响应的路由，消息传递次数，详细的顺序和事务的唯一标识）

Call_ID的生成规则：a) Call_ID 是在一系列消息中，区分一组消息的唯一标志b) 在对话中的任一个UA的所有请求和所有应答的Call-ID必须一致c）在UA的每次注册中，都应该是一样的d）在对话外的时候，UAC发起一个新的请求，这个Call_ID必须由UAC产生一个全局唯一的Call_ID（所有的UA 都必须保证自己产生的Call_ID不会和其它UA产生的Call_ID重复）。e) 请求的重新尝试不被当做一个新的请求，不需要新的Call_ID。

CSeq的生成规则：a）用来区分和作为事务的顺序使用b）由方法和顺序号组成，方法必须和请求的方法一致c）对于对话外的非REGISTER请求，顺序号码可以是任意的。

格式：CSeq：1 BYTE

Via 中的Branch：a）用于区分请求创建的事务（客户端和服务器端都会使用）b）除了CANCEL和给非2XX应答的ACK外，branch参数对UA发出的所有请求来说，在时间和空间上必须唯一（CANCEL 请求的branch必须和它所取消的请求的branch一致；给非2XX应答的ACK必须和其对应的INVITE请求有相同的BRANCH ID）c)可以利用branch id的唯一性作为事务的ID ??

？？谁何时产生此Branch ID

二．SIP 协议的结构、处理流程

1. 采用分层结构，各层之前松散偶合。

第一层语法和编码层(组成消息);

第二层传输层(消息的发送与接收);

第三层事务层: 一个SIP 事务由一个请求和这个请求的所有应答组成.(当终结应答不是一个2XX应答时,事务还包括一个ACK,如果一个应答是2XX,那么ACK 并不认为是事务的一部分) a)事务存在于UA 及有状态的proxy 服务器中. b)事务层处理应用服务层的重发, 匹配请求的应答, 以及应用服务层的超时.

第四层事务用户层: 每一个SIP 实体(除了无状态Proxy), 都有一个事务用户.

当TU 发送一个请求, 他首先创建一个客户事务实例并且和请求一起发送.

TU 可以创建客户事务也可以取消客户事务, 当取消一个事务时, 它请求服务器取消正在处理的事务,并回滚状态到事务开始前的状态, 并产生指定的错误报告.

2. SIP 协议基本网络模型

事务用户层(Transaction User)

事务层(Transaction)

传输层(Transport)

语法和编码层(Syntax & Encoding)

三．SIP 过程分解（1.步骤描述2.画出流程来3.标出每一步的具体细节）

UAC/USC 的处理依赖于请求或应答是否是对话内/对话外请求和方法。一下讨论对话外的方法无关的规则。

1. UAC产生/发送/接收回复

UAC 产生一个请求、发送一个请求、接收处理应答

1.1. 产生一个请求

一个SIP Request请求必须至少包含如下头域：TO，FROM，Cseq，Call-ID，Max_Forwards，Via。

Request-URI：最开始的Request-URI 应该是T o头域的值

当Register 方法涉及隐私时有些差异

预设路由表的情况(12.2.1.1)

To：是第一个最先指定请求的接受地或者是（AOR)。

To field 的填写。

A request outside of a dialog MUST NOT contain a To tag; the tag in the To field of a request identifies the peer of the dialog. Since no dialog

is established, no tag is present.

From: 请求发起者的逻辑名称。通常用户或用户的本地主机的管理人员会事先规定Form 头域的值。

Form field 的用处。

The From field MUST contain a new "tag" parameter, chosen by the UAC. (See 19.3 Tags)

Call-ID：acts as a unique identifier to group together a series of messages.

It MUST be the same for all requests and responses sent by either UA in a dialog.

It SHOULD be the same in each registration from a UA.

In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time。

Call-IDs are case-sensitive

Note that when requests are retried after certain failure responses that solicit an amendment to a request , these retried requests are not considered new requests, and therefore do not need new Call-ID header fields;

CSeq：serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request。

For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary.

这个顺序号码必须可以由32位的无符号整数表达，必须小于2^31.

Max-Forwards：用来限制请求到他的目的地的中间的跳转，每隔一个跳转就自动减一，到达0时，会报告一个483错误回应。

Via：indicates the transport used for the transaction and identifies the location where the response is to be sent. A Via header field value is added only after the transport that will be used to reach the next hop has been selected.

当UAC 创建一个请求时，它必须在头域中添加一个Via头域。The via header contains a branch parameter？？

Contact：用来告诉对方回信息给谁。

MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog.

1.2. Sending the request

如何确定发送的目标地址？使用DNS来查找或本地策略指定.

1.3. Processing Responses

应答首先被transport处理，并且被transport发送给transaction处理，transaction处理完成之后将应答发送给TU处理。

处理Transaction 层错误

处理未知的应答

处理Vias:

处理3XX:

处理4XX:

2.UAS接收请求/处理/回复请求

UAS 接收请求，处理流程（首先身份认证，然后方法判定，然后头域，然后处理剩余部分）

2.1. Method Inspection：

2.2. Header Inspection：

2.3. To and Request-URI：To头域包含了由From 头域描述的发送者发出的请求的原始接受者。当To头域和自身不相符合的情况下，UAS 可以自行决定是否接收这个

请求。但是由Request-URI 确定是否由UAS 来处理这个请求。

2.4. Merged Requests：If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. （检测到环路）

2.5. Require 检查:

2.6. Content Processing:

2.7. Applying Extensions:

2.8. Processing the Request: 请参考REGISTER,OPTIONS,INVITE,BYTE

2.9. Generating the Response:

遵循以下步骤产生一个应答。创建完成之后，UAS将应答交给收到这个请求的服务端transaction去处理。

2.9.1. Sending a Provisional Response

2.9.2. Headers and Tags

2.10. Stateless UAS Behavior

Stateless UASs do not use a transaction layer; they receive requests directly from the transport layer and send responses directly to the transport layer.

2.11. Redirect Servers

A redirect server is logically constituted of a server transaction layer and a transaction user that has access to a location service of some kind (see Section 10 for more on registrars and location services).

接收到非Cancel 请求与Cancel 请求的处理。It is the responsibility of clients to detect forwarding loops between redirect servers.

3. Dialog and How to construct a dialog(by request and response) and then how subsequent requests and responses are sent within a dialog.

A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a remote tag.

A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number , a remote sequence number, a local URI, a remote URI, remote target, a boolean flag called "secure", and a route set, which is an ordered list of URIs.(对话的"early" 状态与"confirmed"状态)

3.1 Creation of a Dialog

Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog.

3.1.1 UAS Behavior

当UAS响应一个应答，并且这个应答会建立一个对话时：

1）copy all Record-Route header field values from the request into the response

2) add a Contact header field to the response.

3) If the request arrived over TLS, and the Request-URI contained a SIPS URI, the "secure" flag is set to TRUE

4) The remote URI MUST be set to the URI in the From field, and the local URI MUST be set to the URI in the To field

3.1.2 UAC Behavior

1)MUST provide a SIP or SIPS URI with global scope in the Contact header field of the request.

2)If the request was sent over TLS, and the Request-URI contained a SIPS URI, the "secure" flag is set to TRUE.

3)The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI

parameters.

......

3.2 Requests within a Dialog

建立对话之后，可以在对话中创建新的transaction。

对话中的请求可以包含Record-Rout 和 Contact头域，尽管他们可能修改Remote target URI, 但这些请求不会导致对话的路由被修改。

3.2.1 UAC Behavior

3.2.1.1 Generating the Request

对话中的请求由许多对话的状态组成。

3.2.1.2 Processing the Responses

3.2.2 UAS Behavior

UAS 收到请求并处理请求时相关状态要么一起改变，要么一起不变。

3.3 Termination of a Dialog

1)对话外的请求产生一个非2XX应答，会终结“early dialog”

2)BYE 方法终结一个对话

4.Invite, Register，Options，ACK，Byte，Cancel 方法

四．SIP 概念封装成类

1）把所有的对象（概念）list 出来2)把消息在对象之间的流动及处理过程整理出来3）把对象之间的关系整理出来

1. 类<---->概念

SipMessage(Header field(Request Line、StatusLine、Form、To、SDP......))

UAC/UAS/Proxy core

Dialog/Session(A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response. Therefore, when multiple 2xx responses are received from different remote UAs (because the INVITE forked), each 2xx establishes a different dialog. All these dialogs are part of the same call.)

Transaction

Transport

Timer

2.类的实现

五．建立测试环境六．其它

1.Dialog 的判断TU(UAC/UAS/Proxy core) Client/Server Transaction

Transport

SipMessage

2.Transaction 的判断

3.CSeq 的参数算法

使用32位长整数（即使每秒产生一笔，也要136年才会重复），非0的初始值可以考虑采用时间来作为初始序列号（31位有符号或32位无符号）。

4.Target Refresh requests ??

12.1.1.1

5.Via 头域的Branch 参数

6.