【嵌⼊式开发】SIP信令交互总结（1）房屋置换协议书
1 SIP视频流获取
这⾥的SIP视频流的获取是指解码器通过SIP协议向⽤户代理服务器（UAS）获取视频流的过程（这⾥的sip⽤的是28181协议）。UAC必须包含⽣成请求，发送请求和处理响应的功能，解码器制定的有效SIP请求，⾄少包括以下头字段：To、From、Cq、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、Cq、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
From：
From头字段表⽰请求发起者的逻辑⾝份，有可能是⽤户的记录地址。和 To 字段⼀样，它包含了 URI 和显⽰名称，显⽰名称是可选的。SIP 元素⽤它来确定应⽤于请求的处理规则（如，⾃动呼叫拒绝）。同样地，因为没有逻辑名字，不包含 IP 地址或者 UA 运⾏主机的正式域名的 From URI 很重要。 下⾯是 From 头字段的实例：
From: “Bob” ;tag=a48s
From: sip:+;tag=887s
From: Anonymous ;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: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@
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必须发现可到达⽬的⽤户的当前主机。注册必须发送 REGI
STER 请求给特定类型的 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指定了注册服务器指明的定位服务域。（如）。不能出现SIPS URI的urinfo和@组
件。
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 必须逐⼀增加Cq值。
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必须认为会话和对话结束了。
