【嵌入式开发】SIP信令交互总结（1）

1 SIP视频流获取

这里的SIP视频流的获取是指解码器通过SIP协议向用户代理服务器（UAS）获取视频流的过程（这里的sip用的是28181协议）。UAC必须包含生成请求，发送请求和处理响应的功能，解码器制定的有效SIP请求，至少包括以下头字段：To、From、Cseq、Call-ID、Max-Forwards 和 Via，我们的主要任务是实现解码器的这些功能。
过程首先解码器上线向服务器注册，并且向cu客户端进行通知，然后通过客户端操作解码器的运行（解码停止解码等），实际上所有信令都是通过服务器进行交互的，即解码器解码命令由cu发向服务器然后服务器通知解码器解码，然后解码器向服务器邀请视频，然后解码，最后结束。

1.1 SIP概要

SIP(Session Initiation Protocol)是一个应用层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以是Internet多媒体会议、IP电话或多媒体分发。会话的参与者可以通过组播（multicast）、网状单播（unicast）或两者的混合体进行通信。SIP在建立和维持终止多媒体会话协议上，支持5个方面：
1. 用户定位： 检查终端用户的位置，用于通讯。
2. 用户有效性：检查用户参与会话的意愿程度。
3. 用户能力：检查媒体和媒体的参数。
4. 建立会话：”ringing”,建立会话参数在呼叫方和被叫方。
5. 会话管理：包括发送和终止会话，修改会话参数，激活服务等等。

1.2 生成请求

UAC制定的有效SIP请求，必须，至少包括以下头字段：To、From、Cseq、Call-ID、Max-Forwards 和 Via。在所有的 SIP 请求中，这些头字段都是必需的。这六个头字段是SIP消息基本的构件块，它们共同提供大部分关键性消息路由服务，包括消息的寻址、响应的路由、限制消息的传播、消息的排序和事务的唯一标识符。UAC 制定的有效SIP请求除了包含这些头字段外，还有必需的请求行。这个请求行包含了方法、Request-URI 和 SIP 版本。 具体参考RFC3261文档。

Request-URI：

消息初始 Request-URI 应该设置成To字段的URI值。但应注意，REGISTER方法例外。保密性原因或者便于将这些字段设置成相同的值（特别是在传输过程中，原始 UA 期望改变 Request-URI），可能不符合需要。

To：

头字段首先指明了想要的请求的“逻辑”接收者或者用户的记录地址或者作为请求目标的资源。这不一定是请求的最终接收者。To字段可能包含 SIP 或者SIPS URI，在适当的时候，它也可以使用其它URI模式。所有 SIP 执行必须支持 SIPS URI 模式。任何支持 TLS 的执行必须支持 SIPS URI 模式。To 头字段考虑到了显示名称。 UAC可以知道怎样以多种方法为特定的请求填充 To 头字段。通常，用户建议To头字段通过用户界面填充——可能是手动输入 URI 或者从地址本中选择。To 头字段的更多信息见第 20.39 节。下面是 To 头字段的实例： To: Carol sip:[e-mail]

From：

From头字段表示请求发起者的逻辑身份，有可能是用户的记录地址。和 To 字段一样，它包含了 URI 和显示名称，显示名称是可选的。SIP 元素用它来确定应用于请求的处理规则（如，自动呼叫拒绝）。同样地，因为没有逻辑名字，不包含 IP 地址或者 UA 运行主机的正式域名的 From URI 很重要。 下面是 From 头字段的实例：
From: “Bob” sips:[e-mail] ;tag=a48s
From: sip:[e-mail];tag=887s
From: Anonymous sip:[e-mail];tag=hyh8

Call-ID：

Call-ID头字段作为集合一系列消息的唯一标识符。在对话中，每个 UA 发送的所有请求和响应中，Call-ID必须是一样的。UA的每个注册中，它应该是一样的。 在UAC创建的对话外的新请求中，如果不是特定方法行为覆盖的，UAC 选择的Call-ID头字段必须是在时间和空间上全球唯一的标识符。所有的 SIP UA必须有一种方法来保证其他UA不会产生它们产生的Call-ID 头字段。注意，当在特定的失效响应后，重发请求以修正请求时（如，认证挑战），重的请求将不作为新的请求，因此不需要新的 Call-ID 头字段。下面是 Call-ID 头字段的实例：
Call-ID: [e-mail]

CSeq：

CSeq头字段是用作识别和指示事务的。它由序列号和方法组成。此方法必须和请求相匹配。对于对话外的非 REGISTER 请求，此序列号是任意的。此序列号的值必须是值小于2^31的3位的无符号整数。只要遵循上述原则，客户端就可以随意地使用一种机制来选择 CSeq 头字段值。
实例：
CSeq: 4711 INVITE
 Max-Forwards：Max-Forwards头字段是用作限制请求传输到其目的地跳跃的点数。它是一个整数，在每个跳跃点上减一。如果请求在到达其目的地之前。Max- Forwards值到 0，将返回 483(太多跳跃点)错误响应，拒绝其请求。 UAC 必须在每个请求中插入 Max-Forwards 头字段，并赋初始值为 70。此数字足够长，可保证在没有环路时，请求不会在 SIP 网络中丢失；当存在环路时，此数字不会消耗代理太多的资源。
 Via：Via头字段表示事务中使用的传输，并标识了响应发送的位置。仅在选择了要到达的下一个跳跃点后(这可能包括[4]中过程的使用)，才在传输中加上 Via 头字段的值。 当 UAC 创建请求时，它必须在请求中插入 Via。在头字段中的协议名和协议版本必须分别是 SIP 和2.0。Via 头字段值必须包含分支参数（branch parameter）。此参数用来识别请求创建的事务。此参数同时用于客户端和服务器。 对于 UA 发送的所有请求，其分支参数的值必须在时间和空间上是唯一的。此规则的异常是CANCEL和非 2xx 响应的 ACK。 分支 ID 必须是以“z9hG4bk”字符开头。这七个字符用作magic cookie（7认为是足以确保旧 RFC 2543 执行不会选择这个值），以便于接收请求的服务器可以确定以本规范描述的格式（即，全球唯一）构造分支 ID。
 Contact：Contact头字段提供了SIP或者SIPS URI，可用于为随后请求联系 UA 的具体实例。必须正确地表示 Contact 头字段，并包含任何请求中的 SIP 或者 SIPS URI，这将导致建立对话。在本规范中定义的方法，仅仅包含INVITE请求。对于这些请求，Contact 的范围是全局的。即 Contact 头字段值包括 UA 要接收请求的 URI，即使是在任何对话外的随后请求中使用，此URI都必须是有效的。 如果 Request-URI 或 top Route头字段值包含 SIPS URI，Contact 头字段也必须包含SIPS URI。
 Supported and Require：如果 UAC 支持 SIP 扩展，服务器可将此扩展用于响应，UAC应该在请求中引用 Supported 头字段，列出这些扩展的可选标签。
 Additional Message Components：在创建了新请求，并合理地构造上面所介绍的头字段后，可以添加任何其他的可选头字段，作为具体方法的头字段。 SIP 请求可能包含 MIME 编码的消息体。不管请求包含的消息体是什么类型，必须阐明特定的头字段来说明主题内容的特征。
1.3 注册、注销
1.3.1 注册流程
如果用户要发起和另一个用户的会话，SIP必须发现可到达目的用户的当前主机。注册必须发送 REGISTER 请求给特定类型的 UAS——即是注册服务器。注册采用RFC3261规定的基于数字摘要的挑战应答式安全技术进行注册，具体流程如下：

基本注册流程
根据上图，注册流程如下：
1. SIP代理向SIP服务器发起REGISTER请求，请求字段中不包含Authorization字段。
2. SIP服务器向SIP代理发送响应401，并在响应的消息头WWW_Authenticate字段给出适合SIP代理的认证体制和参数。
3. SIP代理重新想SIP服务器发送REGISTER请求，在请求的Authorization字段给出认证信息。
4. SIP服务器对请求进行验证，如果SIP代理身份合法，就向SIP代理返回200 OK，否则发送拒绝应答。
1.3.2 注销
注销流程和注册相似，只是在REGISTER请求中将Expires头域值设为0，Contact头域如果设置成为“*”，Call-Id头域值设为和注册时候的值一样，并且在Authorization字段给出和注册时候一样的认证信息，发送请求，服务器返回200 OK后即完成注销。
1.3.3 REGISTER请求构造
REGISTER请求添加、删除和查询绑定，不建立对话。REGISTER 请求可以在记录地址和一个或多个联系地址之间添加新绑定。合适地通过认证的第三方可以完成代表特定记录地址的注册。在 REGISTER 请求和响应中的Record-Route头字段没有意义，如果存在，必须忽略。下列头字段除了Contact 外，必须包含在 REGISTER请求中：
 Request-URI：Request-URI指定了注册服务器指明的定位服务域。（如sip:chicago.com）。不能出现SIPS URI的userinfo和@组件。
 To：To头字段包括记录地址，可以创建、查询和修改其注册。To头字段和 Request-URI字段主要的不同是，前者包含用户名。此记录地址必须是SIP或者SIPS URI。
 From：From 头字段包含负责注册的人的记录地址。除非是第三方注册，此值和To头字段的值是一样的。
 Call-ID：UAC 所有的注册应该使用与发送到注册服务器的注册相同的Call-ID头字段值。 如果相同的客户端使用不同的Call-ID值，那么注册服务器不能检测延时的REGISTER请求是否没有排序到达。
 CSeq：CSeq 值保证 REGISTER 请求适当的排序。对于每个使用相同的Call-ID的REGISTER 请求，UA 必须逐一增加Cseq值。
 Contact：REGISTER 请求可能包括有一个或多个地址绑定值的Contact头字段。
 Expires：Expires 参数表示了UA绑定的有效时间，以秒为单位。如果不提供此参数，那么将使用expires头字段的值代替。不规范的值应该视为等于3600。
1.4 邀请视频
注册成功后，解码器（decode）可以向服务器（S）邀请视频，这时候客户端需要构造发送INVITE消息。客户端成功邀请视频，基本流程：

需要经过下面四步：
1. decode服务器（S）发起INVITE请求。
2. S向decode发送响应100 Trying。
3. S向decode发送带有SDP的响应200 OK，SDP内容是视频传输相关参数。
4. decode向S发送带有SDP的ACK消息，SDP内容根据S向decode的200 OK响应的SDP填写。
INVITE和ACK构参考4.3小节。需要注意的是从INVITE到 ACK整个过程属于一个会话，所以Call-ID值应该一样。服务器返回200 OK的时候，会给to域打上标签，回复ACK的时候，To，From和Call-ID应该和回复消息一样。另外，向指定设备邀请视频的时候应该提供设备ID和通道号，比如，设备ID为131054000100015051，而通道号为01。
客户端回复ACK消息的时候，SDP内容依据服务器回复的200 OK填写，客户端需要提供本机IP和用于接收流的端口号。ACK消息被服务器接收后，服务器开始向该ip主机的该端口发送流。否则服务器继续发送200 OK。
1.5 结束会话
结束会话需要构造BYE消息，BYE消息的构造参考4.3小节，需要注意的是BYE消息的From、To和Call-ID要与需要结束的会话一样。BYE请求一旦发送给服务器，UAC 必须认为会话结束了（并因此停止发送和侦听媒体）。如果BYE响应是 481（呼叫/事务不存在）或者 408（请求超时），或者请求根本没有接收到BYE 的响应（即是 INVITE 客户端事务返回超时），那么，UAC必须认为会话和对话结束了。