SIP消息介绍

200 OK响应
200（OK）回应给发送者，表示这个电话已经接起来了。VIA,TO,FROM,CALL-ID,Cseq包头域是从 INVITE请求包中直接拷贝过来的，它包含了一个消息体，这个消息体包含 SDP 媒体描述，表示被 叫端希望与主叫端建立何种媒体连接。

SIP中的SDP
SIP消息可以携带SDP消息体。SDP(会话描述协议)是用来描述与媒体流相关的参数以及与会话相关的信息，其 中包括对会话的描述以及媒体类型、数据发送到的端口、传输协议(例如RTP)以及媒体格式(例如RTP载荷格式)的描述。
SIP消息介绍
李文俊 2015.12.04
SIP协议功能概况
1，SIP 是一个应用层的控制协议，可以用来建立、修改、和终止多媒体会话（或者会议），例如 Internet 电话。也可以邀请参与者参加已经存在的会话，比如多方会议。
2， SIP不是一个垂直集成的通讯系统，可能叫做是一个部件更合适，它可以用作其他IETF协议的一个部分，与其他的 协议一起工作，才能提供完整的对终端用户的服务，虽然基本的SIP协议的功能组件并不依赖于这些协议。
PS: 如果UAC在INVITE消息中含有support头域：100rel，而UAS也支持该扩展并且在183响应中有require:100rel,说明在后面的会话当中，对所 有100以外的响应消息，都需要prack回应。 如果UAC不支持100rel，但UAS要求支持100 rel (require:100rel),UACv发送CANCEL，切断会话。
模式2：UAC在INVITE请求中没有携带 offer。UAS在200 INVITE响应中携带一个offer，UAC通过ACK返回answer，这种模式通常 用于3PCC（即第三方电话呼叫控制，指的是由第三方控制者在另外两者之间建立一个会话，由控制者负责会话双方的媒体协商， 实现点击拨号、通话过程中放音等功能）中。
对几种模式小结 在没有100rel选项时，会话建立过程非常简单，只能使用“200 ”响应消息传送会话描述，这些会话描述可能是answer(模式1),也 可能是offer（模式2）。无论使用何种模式，会话都只能呼叫完成后才能建立，在呼叫完成之前和呼叫完成之后只能有一个会话 – 用于最终通话的常规会话，因而，不能建立所谓的“早期媒体会话”。 在引入100rel选项后，会话建立过程变得复杂，通过可靠的临时消息也可以传送会话描述，这些会话描述可能是answer(模式3), 也可能是offer（模式4）。模式3和模式4都能够在呼叫完成前建立会话。并且在呼叫完成之前，这些会话还可以被更新。这样就能 够建立与常规会话不同的“早期媒体会话”，完成回铃音的产生等功能。 PRACK方法可用于更新已建立的会话的参数（模式5） UPDATE方法可用于多次更新已建立的会话的参数（模式6），发起更新的可以是UAC也可以是UAS。
三，RTCP媒体流 每发完一批RTP包的时候，就发一个RTCP包，告诉接收方我刚才发了多少RTP包，多少个字节 RTCP：RTP 控制协议，提供数据分发质量反馈信息
• •
• • •
Version ― 识别 RTP 版本。RTP 数据包中的该值与 RTCP 数据包中的一样。当前规范定义的版本值为 2。 P ― 间隙（Padding）。设置时， RTCP 数据包包含一些其它 padding 八位位组，它们不属于控制信息。Padding 的最后八位是用于计算 应该忽略多少间隙八位位组。一些加密算法中需要计算固定块大小时也可能需要使用 Padding 字段。在一个复合 RTCP 数据包中，只有最 后的个别数据包中才需要使用 padding ，这是因为复合数据包是作为一个整体来加密的。 RC ― 接收方报告计数。包含在该数据包中的接收方报告块的数量，有效值为 0。 Packet type ― 包括常量 200 ，识别这是一个 RTCP SR 数据包。 Length ― RTCP 数据包的大小（32 位字减去 1），包含头和任意间隙 （偏移量的引入使得 0 成为有效值，并避免了扫描复合 RTCP 数据 包过程中的无限循环现象，而采用 32 位字计数方法则避免了对 4 的倍数的有效性校验）。
模式4： UAC在INVITE请求中没有携带offer。UAS在1xx-rel可靠响应中携带一个offer，UAC通过PRACK返回answer。同样地，在呼叫完成之前 （UAC没有收到200 INVITE消息）会话已建立。此后，会话参数还可以被更新，具体见模式6。
模式5：当UAC与UAS采用模式3建立会话后，呼叫并未完成,可以使用模式5对已建立的会话参数进行更新： UAC在PRACK请求中携带一个新的offer, UAS在200 PRACK响应中返回answer。这样，会话参数便被更新。 什么是PRACK?
1，100 （Trying）应答表示 INVITE 请求已经收到，并且代理服务器正在转发 INVITE 请求。 2，在每次转发请求之前，proxy都会在via头域增加一段包含自己地址的值（INVITE消息中已经包含了主叫端A的的址）；当被叫响应时 ，每个proxy通过 via 头域决定该把这个应答发送给哪里，并且在发送之前把自己的地址从头上拿走。 3，每个转发 INVITE的proxy也可以得到 INVITE 的每一个应答。 4，ACK信号是直接由A发送到B上，跨过了两个代理服务器。这是因为两终端通过INVITE/200(OK)的请求应答包中的Contact域都知道互 相之间的地址了，这个地址是最开始发起INVITE请求的时候所不知道的。不需要两个代理服务器再查找对方的地址了， 代理服务器不参 与接下来的通话流了。这就完成了一个完整的使用INVITE/200/ACK 三方握手来建立SIP会话的过程。
SDP及RTP的工作过程
一，SIP协议告知对方UDP端口号，协商媒体类型 1，主叫方发给被叫方的INVITE请求
2，被叫方回给主叫方的183消息
二，RTP媒体流 3，主叫方发给被叫方的一个RTP包，UDP端口号是SDP协商好的，包的序列号是28590
4，主叫方发给被叫方的下一个RTP包，UDP端口号是SDP协商好的，包的序列号是28591
4，SIP 是基于一个类似 HTTP 协议的请求应答的通讯模式。 每一个通讯都包含对某个功能的请求，并且起码需要一 个应答。 5，SIP 也提供保密 URI，称作 SIPS URI，例如：sips: bob@。 一个基于 SIPS URI 的通话保证这个通话是 安全的，并且对呼叫者和被叫的所有的 SIP 消息是加密传输的（叫做 TLS）。在 TLS 中，请求是通过加密方式传输给被 叫方，但是这个加密机制是基于被叫方宿主服务器的实现的。
模式3、模式4、模式5都是在RFC3262中定义的，可用在支持100rel的SIP实体之间。其中模式3、模 式4可用于会话建立。模式5只能用于会话参数更新。它们利用1xx-rel响应消息来携带offer或answer来建立会话。
模式3：UAC在INVITE请求中携带一个offer, UAS在1xx-rel响应中返回answer。这样，在呼叫完成之前（UAC没有收到200 INVITE消息）会话已 建立。此后，会话参数还可以被更新，具体见模式5及模式6。
3，SIP/2.0 允许 6 类应答： 1xx：临时应答－请求已经接收，正在处理这个请求。 2xx：成功处理－请求已经成功接收，并且正确处理了这个请求。 3xx：重定向－还需要附加的操作才能完成这个请求，本请求转发到其他的服务器上处理。 4xx：客户端错误－－请求包含错误的格式或者不能在这个服务器上完成。 5xx：服务器错误－服务器不能正确的处理这个显然合法的请求。 6xx：全局错误－请求不能被任何服务器处理。
问题：SIP电话被叫端 无法挂机 外网SIP1和SIP2话机互打，通过映射的网关做端口映射的转发的，并在0.235机器上抓的包
Thank you !
Call_ID 包含一个全局的唯一标志， 用来唯一标志这个呼叫，表示这个是一个对话性质的关系。 CSEQ 或者 Command Sequence :包含了一个整数和一个请求名字。 这个 Cseq 数字是顺序递增的。每当对话中发起一个新的请求都会 引起这个数字的顺序递增。 Contact 域包含一个 SIP 或者 SIPS URI 用来表示访问 主叫端 的直接方式 Content－type 包含了消息正文的描述（消息正文在本范例中没有列出） 。 Content-length：包含消息正文的长度（字节数）
建立媒体会话实际上就是通过SDP offer/answer交换进行就会话的媒体参数进行协商的一个过程，但在SIP中 没有规定使用哪个SIP消息来携带一个SDP（offer或answer）。理论上，任何SIP消息的正文中都可以包含会话 描述部分。 SDP 消息也是两段交换：A 发送一个给 B，B 发送一个回给 A。这个两段的交换提供基本的兼容性协商，并且 基于简单的SDP 请求/应答交换模型。 六种在SIP消息中交换offer/answer的模式。 其中模式1和模式2是在RFC3261中定义的，用于不支持100rel（中间状态响应）的SIP实体之间的会 话建立。 模式1：UAC在INVITE请求中携带一个 offer, UAS在200 INVITE响应中返回answer。
UAC: user agent client,用户代理客户端 UAS: 用户代理服务端 ，下面可以把它当成另一个客户端
INVITE消息包头域
两个用户间的 SIP 消息交易交换例子（SIP软终端A:12345呼叫SIP软终端B:11）。 INVITE 是一个 SIP 请求的例子，表示请求方希望服务方应答。INVTE 请求包含一系列的包头域（Header fields）。 包头域中包含很多属性并且包含了传输消息的附加信息。下图为做被叫的SIP软终端侧抓的包，如图：
模式6在RFC3311中定义，主要用于在早期对话中更新已建立的会话参数，会话可能是通过模式3，也可能 是通过模式4建立的。模式6还可以对会话进行多次更新。例如,之前已通过模式5更新过的会话还可以使用模式6更新； 甚至通过模式6更新过的会话还可以再次使用模式6更新。 模式6：UAC（或UAS）发送UPDATE请求其中携带一个新的offer, UAS（或UAC）在200 UPDATE中返回一个answer。这样，会 话参数便被更新。注意，UAS或UAC在发送UPDATE进行会话更新之前，必须保证之前的会话更新过程已经完成。也就是说，发出 的offer已经收到answer，或者收到的offer已经产生了answer。