sip协议字段讲解

sip协议字段讲解内容摘要：

会话的某些属性，例如：增加或删除媒体流，改变媒体发送或接受地址等。 当需要结束会话的时候，任何一端 UA 可以通过发送 BYE 请求，来结束会话。 对端同意结束，则发送 200 OK应答，结束会话成功。 图 最基本的两个 UA 之间的 SIP 呼叫 最基本、最简单的 SIP 呼叫是两个 UA 之间之间的点对点呼叫。 如上图所示。 下面就最基本的 SIP 呼叫，分别针对发起会话、调整会话和结束会话进行说明。 发起会话 图 建立会话的三次握手 如图 所示， INVITE、 200 OK、 ACK三条消息为会话发起过程中的三次握手。 三次握手过程的完成，唯一标识了会话的成功建立。 UAC 的 INVITE 消息的产生 RFC3261 规定，由 UAC产生的一个有效的 SIP 请求消息必须至少包含下列头字端： Via、MaxForwards、 To、 From、 CSeq 和 CallID 头字端，不仅是在 INVITE，它们在所有的 SIP请求消息中都是必选的。 这六个头字段是构建 SIP 消息的 基本单元，它们共同提 供了大部分的关键的消息路由服务，包括消息的寻址、响应的路由、消息传播距离限制、消息排序，以及事务交互的唯一性标识等。 另外，请求行 （ RequestLine）也是必选的。 各头字段的说明见上文。 具体地，请求行（ RequestLine）中的 RequestURI 设置为与 To 头字段一值（除 REGISTER 以外的 所有请求的初始 RequestURI 都应该与 To 头字段一值）；Via 头字段设置为响应消息将要被发送的地址，其 brance 参数值在时间和空间上也必 须唯一（即不同的 method 有不 同 brance 值，两种情况除外， CANCEL 与对应的 INVITE 的 brance值相同，对非 2xx 的最终响应的 ACK与对应的 INVITE 的 brance 值相同）； MaxForwards一般设置为 70； To 头字段包含了请求消息的逻辑接收者，可以是 SIP 或 SIPS URI，其 tag值标识了对话中的对端，在 INVITE 消息中不应该出现； From 头字段设置为消息发送者的地址，其 tag 值标识了消息的发起 者； Cseq 设置为不同于其他事务的整数序列和 INVITE方法； CallID 设置为全局时间上和空间上都唯一的 ID 号； Contact 头字段设置为 UAC（请求发送者）的地址。 另外， INVITE 消息中可以包含 SDP 消息，这时 ContentType 头字段的值应该是application/sdp。 SIP 协议中规定了 关于媒体协商的过程是通过在消息中携带 SDP 来完成的。 关于 SDP 协商的过程需要遵循如下规定： INVITE 消息中携带 SDP 请求，则 200 OK消息中返回 SDP 响应； 200 OK消息中携带 SDP 请求，则 ACK消息中返回 SDP 响应。 SDP 请求和响应这个协商过程，不能并行，只能当一次交互完成之后才能发起新的协商过程。 UAS 的行为 INVITE 消息根据 Via 头字段中的地方，发送消息。 当 UAS 收到消息后，可以按以下几种进行：正在处理，发送 1XX；重定向， UAS 希望将此请求重新发送到另一地址，发送 3XX；拒绝，发生了某种错误，发送 4XX 或 5XX 或 6XX；接受，发送 2XX。 UAS 构建响应消息时，按照如下方法：构建状态行（ StatusLine）；复制收到请求的 Via 头字段，做部分修改；复制 To 头字段，添加 tag 值（即 UAS 的标识）；完全复制 From 头字段， Cseq 头字段和 CallID 头字段； Contact 头字段修改为 UAS 的地址。 如果 INVITE 请求中携带了 SDP 请求，则在 200OK消息中携带 SDP 响应。 ACK的发送 对于最终响应（ 2XX， 3XX， 4XX， 5XX， 6XX）， UAC 将构建 ACK消息。 此时的 ACK消息的构建方法与 INVITE 大体一 致： RequestLine 中的 RequestURI 应设置为 200OK中的Contact 头字段的 URI； Via 头字段的 brance 值不同于 INVITE； MaxForwards、 To、 From、CallID 与 INVITE 相同（ To 中包含了 tab 标识）； Cseq 中的整数序列 与 INVITE 相同， method为 ACK。 一个例子（图 ） MESSAGE INVITE sip: SIP/ Via: SIP/:5060。 branch=z9hG4bKfw19b MaxForwards: 70 To: G. Marconi From: Nikola Tesla CallID: CSeq: 1 INVITE Subject: About That Power Outage... Contact: ContentType: application/sdp ContentLength: 158 v=0 o=Tesla 2890844526 2890844526 IN IP4 s=Phone Call c=IN IP4 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Ringing MESSAGE SIP/ 180 Ringing Via: SIP/:5060。 branch=z9hG4bKfw19b。 received= To: G. Marconi From: Nikola Tesla CallID: CSeq: 1 INVITE Contact: ContentLength: 0 OK MESSAGE SIP/ 200 OK Via: SIP/:5060。 branch=z9hG4bKfw19b。 received= To: G. Marconi From: Nikola Tesla CallID: CSeq: 1 INVITE Contact: ContentType: application/sdp ContentLength: 155 v=0 o=Marconi 2890844528 2890844528 IN IP4 s=Phone Call c=IN IP4 t=0 0 m=audio 60000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 MESSAGE ACK sip: SIP/ Via: SIP/:5060。 branch=z9hG4bK321g MaxForwards: 70 To: G. Marconi From: Nikola Tesla CallID: CSeq: 1 ACK ContentLength: 0 调整会话 图 调整会话 在会话建立后，呼叫方或被叫方可以发送一条新的 INVITE 消息，来调整、修改已经建立的会话的参数信息。 在一个现存对话中发出 INVITE 请求就 是 reINVITE。 其过程与发起会话的过程类似，如上图 所示。 reINVITE 请求的产生 reINVITE 过程所采用的 SDP 协商过程与建立会话的 INVITE 过程相同：会话中的任意一方可以通过在 reINVITE 消息中携带一个新的 SDP 请求来更新会话内容；或者， reINVITE 可以不携带 SDP，让其对方在 200OK 中携带 SDP。 reINVITE 消息中的 To、 From、 CallID、 Cseq 和 RequestURI 头字段的生成方法采用通用的请求消息的生成规则。 reINVITE 不会被分 岔（分岔成为多份 INVITE，发送到不同地址），因此只可能收到一个最终应答（不会分岔的原因是，会话已经建立，那么 reINVITE 消息中的 RequestURI 将是目标 UA 的地址，会准确无误地送到）。 reINVITE 过程不能重叠，如果已经有一个 reINVITE 事务正在执行，就不能发起新的reINVITE 事务。 对于 reINVITE 事务的 ACK和 2XX 响应的生成，与初始 INVITE 过程相同。 UAS 的处理 UAS 收到 reINVITE 消息后，必须检查其中的 SDP 是否更改，并对相应的会话参数做出调整。 如果新的媒体描述不可接受， UAS 可以返回 488（ Not Acceptable Here）拒绝响应。 这个响应应当包含一个 Warning 头域（用来提供给请求方，提供这个拒绝的原因）。 如果 UAS 返回了 2XX 响应，但是没有受到 ACK，它必须发送 BYE 来结束本次对话。 一个例子 在例子 的基础上，发起一个增加视频请求的 reINVITE，消息如下： 1． INVITE MESSAGE INVITE sip: SIP/ Via: SIP/:5060。 branch=z9hG4Bk412kg MaxForwards: 70 To: G. Marconi From: Nikola Tesla CallID: CSeq: 2 INVITE Subject: Request for video… Contact: ContentType: application/sdp ContentLength: 158 v=0 o=Tesla 2890844526 2890844526 IN IP4 s=Phone Call c=IN IP4 t=0 0 m= video 53000 RTP/AVP 32 a= rtpmap:32 MPV/90000 OK MESSAGE SIP/ 200 OK Via: SIP/:5060。 branch= z9hG4Bk412kg。 received= To: G. Marconi From: Nikola Tesla CallID: CSeq: 2 INVITE Contact: ContentType: application/sdp ContentLength: 155 v=0 o=Marconi 2890844528 2890844528 IN IP4 s=Phone Call c=IN IP4 t=0 0 m= video 61000 RTP/AVP 32 a= rtpmap:32 MPV/90000 MESSAGE ACK sip: SIP/ Via: SIP/:5060。 branch=z9hG4bK432km MaxForwards: 70 To: G. Marconi From: Nikola Tesla CallID: CSeq: 2 ACK ContentLength: 0 结束会话 图 结束会话 会话的中止可以通过对 INVITE 请求返回拒绝响应来完成，或者对已建立的会话发送 BYE请求等方式来完成。 对于非 2XX 的最终响应， UAC 收到此响应后，发送 ACK中止会话。 对于 BYE 请求，下面略作介绍。 UAC 行为 会话中的任意一方可以通过发送 BYE 请求来结束已经建立的会话。 BYE 请求的生成与通用的请求消息的生成规则相同。 BYE 请求对应一个新的事务。 UAC 发送 BYE 请求之后即认为本次会话已经结束了。 UAS 行为 UAS 收到 BYE 请求之 后，需要查询匹配的会话。 如果找不到则返回 481 响应。 如果找到对应的会话， UAS 必须结束该会话。 然后对 BYE 返回 2XX 响应。 对于正在处理的请求消息，UAS 返回 487 响应。 一个例子 1． BYE MESSAGE BYE sip: SIP/ Via: SIP/:5060。 branch=z9hG4bK392kf MaxForwards: 70 To: Nikola Tesla From: G. Marconi CallID: CSeq: 1 BYE ContentLength: 0 2． 200 OK SIP/ 200 OK Via: SIP/:5060。 branch=z9hG4bK392kf。 received= To: Nikola Tesla From: G. Marconi CallI。