SIP基本概念

目录

sip 作用和定义
sip 拓扑图
sip 各个成员介绍 
sip 协议头
sip 协议流程图
实例分析:一次完整的通话过程SIP报文分析

正文

1 定义和作用

SIP是一个应用层的控制协议,可以用来建立,修改,和终止多媒体会话(或会议)例如Internet 电话.
SIP也可以邀请参与者参加已经存在的会话，比如多方会议。媒体可以在一个已经存在的会话中方便的增加（或者删除）。
SIP显示的支持名字映射和重定向服务，这个用于支持个人移动业务－用户可以使用一个唯一的外部标志而不用关系他们的实际网络地点。
SIP在建立和维持终止多媒体会话协议上，支持5个方面：
1） 用户定位： 检查终端用户的位置，用于通讯。
2） 用户有效性：检查用户参与会话的意愿程度。
3） 用户能力：检查媒体和媒体的参数。
4） 建立会话：”ringing”,建立会话参数在呼叫方和被叫方。
5） 会话管理：包括发送和终止会话，修改会话参数，激活服务等等。

基本概念（各个成员介绍）：

sip也是一个小系统

SIP元素（ SIP elements）：
用户代理客户端,用户代理服务器,无状态代理,有状态代理、注册服务器，包含区分这些元素的核心.

事务：是客户端事务（使用传输层）想服务器事务发送的请求，以及服务器事务向客户端事务发回的该请求的响应。事务是SIP的基础组件。

UAC(用户代理客户端)和UAS(用户代理服务端)的cores的行为依赖于实现，对所有的实现来说，有几个公共的原则（第8节）。
对UAC来说，这些规则约束请求的建立；对UAS来说，这些规则约束请求的处理和应答。
由于注册服务在SIP中是一个重要的角色，所以UAS处理REGISTER请求有一个特别的名字：登记员（registrar，登记服务器）.第10节描述了UAC和UAS的对REGISTER实现的core（核心）行为.
第11节描述了OPTIONS的UAC和UAS的core实现，这个OPTIONS用来检测UA的处理能力的（UA-user agent）。

一个对话是一个持续一定时间的两个用户之间的端到端的SIP关系。对话过程要求两个用户代理之间的信息是有序的而且请求被正确路由传输的.在这个规范中，只有INVITE请求可以用来建立会话.
当一个UAC在一个对话中发出请求的时候，它不仅遵循第8节描述的一般UAC规则而且也遵循对话中的请求规则。第12节讲述了对话并且讨论了对话的创建和维持，以及在对话中创建一个请求。

SIP 中的Dialog，call，session 和 transaction,

Call(呼叫) ：一个呼叫是由一个会议中被同一个发起者邀请加入的所有成员组成的。
一个 SIP 呼叫用全局唯一呼叫标识（CALL_ID）来识别。因此，如果一个用户被不同的人邀请参加同一个多点会议，每个邀请都有一个唯一的呼叫。

注: Dialog和Session都翻译成了会话,但两者显然不同.

下面的示意图清晰的显示了它们之间的关系

(RINGING 是 1xx 响应, OK是 2xx 响应)

caller呼叫callee的号码来建立一系列的对话(Dialogs),这些对话组成了一个呼叫(Call).
notes: 示意图good。 一次交换就是一次transaction。多个transaction组成一个dialog.

1.对话(dialog)和事务(transaction)处于信令层，而会话(session)处于媒体传输层。SIP使用SDP来通知传输层（RTP）来创建、增加、移除和修改会话。\ 
2.一般来说，在会议应用中SIP可以通过请求来让另一方加入已有会话中。在这种情况下，新的对话会被创建。\ 
3.对话是end-point对end-point的关系，即真实的通信双方，\ 
而transaction 是hop by hop的关系，即路由过程中交互的双方。

分层: 

SIP是一个分层协议，每层之间松耦合。SIP元素都是逻辑元素，而非物理元素。物理实现可以作为不同逻辑元素，甚至是基于事务的。

SIP中最重要的方法就是INVITE方法，它用来在不同的参与者中创建会话使用。
一个会话由一组参与者,他们之间用于交流的媒体流组成.
第13节讲述了这些会话的创建初始化过程,以及创建一个或一组对话。
第14节讲述了在对话中使用INVITE请求来改变会话的属性。
最后，第15节，讲述了如何终止会话。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

SIP协议头

SIP报头格式

下图显示了一个典型的SIP头的结构。

 

SIP协议格式介绍
概括-总体
SIP消息体结构与Http协议结构相似，均由三部分组成：

•请求行(request-line) or 状态行(status-line)

•消息头(header)

•正文(body)

  请求行

请求行格式：Method Request-URI SIP-Version CRLF

请求行举例：INVITE sip:bob@zte.com SIP/2.0 /r/n

Method:以下列出了几种消息Method方法

Request-URI：指示请求的用户或者服务的地址信息

SIP-Version：请求和响应消息都需要包含SIP版本

状态行
状态行格式： SIP-Version Status-Code Reason-Phrase CRLF

状态行举例：SIP/2.0 200 OK /r/n

Status-Code状态码：状态代码由3位数字组成，表示请求是否被理解或被满足。

状态代码的第一个数字定义了响应的类别，后面两位没有具体的分类。

消息头
MESSAGE sip:0210011140114@10.192.39.37:17017 SIP/2.0

Via: SIP/2.0/UDP 10.192.39.194:15069;rport;branch=z9hG4bK2000324456

From: <sip:0100012000002@10.192.39.194:15069>;tag=2253307030

To: sip:0210011140114@10.192.39.37:17017

Contact: <sip:0100012000002@10.192.39.194:15069>

Call-ID: 755416301

CSeq: 20 MESSAGE

Content-Type: Application/MANSCDP+xml

Max-Forwards: 70

User-Agent: eXosip/3.3.0

Content-Length:   161

SIP协议理解
结构
在SIP协议中主要包含以下几种逻辑上的角色：UA、Proxy Server、 Register/Location Server、Redirect Server。

UA：用户代理（User Agent）类似于http协议中浏览器的角色，是用户操作的终端界面，用户代理需要符合SIP协议的要求，但是结合其他的协议根据不同的应用场景，会有不同的实现逻辑。比如，SIP协议结合H.323VoIP协议可以实现软件电话功能。用户代理分为UAC（UA Client）和UAS（UA Server）两种逻辑实体，UAC发送SIP Request并接受Response，UAS接收SIP Request并返回Response，一个物理设备既可以是UAC同时也可以是UAS。

Proxy Server：代理服务器的作用主要是转发Request和Response给其他的Proxy Server或者UA，Proxy Server分为有状态代理服务器（Stateful Proxy）和无状态代理服务器（Stateless Proxy），前者会保留一次通信事务的状态，通过一个有限状态机来控制转发操作，而后者不保存状态，只是实现透明的转发操作。

Registration/Location Server：注册和定位服务器用于登记和定位UA，在线的UA会定时的向Registration服务器发送SIP消息来表明UA当前的位置（如IP地址、端口号等），Registration服务器会将该信息存入数据库（或者散列表）中，当其他UA向该UA发送request时就能获得该UA的位置。

Redirect Server：用于重定向，在逻辑上相当于一个特殊功能的UA。

                                                

 

重要概念

sip协议最重要的是要弄清楚sip协议的3个核心定义：dialog（对话）、session（会话）、transaction（事务）把这3部分梳理清楚就可以清楚的看到sip协议栈的基本架构了。

事务

概述：Transaction事务是指一个请求消息以及这个请求对应的所有响应消息的集合。

理解：                                    

       1. 对于INVITE事务来讲，除包含INVITE请求和对应的响应消息外，在非成功响应的情况下，还包括ACK请求。

       2.Via头中的branch参数能够唯一确定一个事务.branch值相同,代表同一个 transaction(事务)。

       3.事务是由事件（方法）来引起的，一个方法（Method）的建立和到来都将建立新的事务。（实际上当收到新消息时，就是根据branch来查找对应的事务）

       4.根据sip协议描述一个transaction由5个必要部分组成：from、to、Via头中的branch参数、call-id和cseq，这5个部分一起识别某一个transaction， 如果缺少任何一部分，该transaction就会设置失败。

对话

概述: Dialog对话是两个UA之间持续一段时间的点对点的SIP连接。

理解:

        1.它使UA之间的消息变得有序，同时给出请求消息的正确的路由。

        2.Call-ID、from-tag以及to-tag三个值的组合能够唯一标识一次对话。

        3.对话一般是由Invite and Subscribe  来创建的.即对话处于确定阶段时，对话已经建立起来。

注意事项：

        1.在一个对话中不同UA之间的 dialog ID 是不同的。

        2.在一个UA中的 local tag 与其对方的 remote tag 是一样的。tag 是透明的标记，这有助于生成独一无二的 dialog ID。

会话

概述:会话是一次通信过程中所有参与者之间的关联关系以及他们之间的媒体流的集合。

理解:

根据SDP 的描述：“一个多媒体会话是多媒体的发送者和接收者以及传输与发送者与接收者之间的多媒体流，一个多媒体会议是一个多媒体会话的例子”（在SDP定义下的会话是可以包含一个或者多个RTP会话）。一个被叫方可以被邀请多次，被不同的呼叫方呼叫至同一个会话，如果使用了SDP，一个会话被SDP开头处的一些相关的SDP用户名、会话id、网络类型、地址类型元素定义。

++++++++++++++++++++++++++++++++++++++++++++++++++

呼叫（call）： 呼叫是一个非正式的术语，用来表示一个多媒体会话，用Call-ID来标识；不论两方通话还是在多方通话中，在每个UA中是使用同一个Call-ID；

事务(transaction)： 请求（UAC）+最终响应（相邻的UAS），SIP基于事务。所谓相邻就是说transaction存在于相邻的SIP实体，而不是存在于两个UA之间。CSeq标识。
一个事务中包含一个请求消息、0个或多个临时响应消息、1个或多个最终响应消息（2xx\~6xx）。SIP是事务性的协议。
事务的区分通过Via字段栈顶的Branch的值来确定，这是由于对于请求消息每经过一个有事务状态的Proxy的时候，该Proxy需要为这个事务创建一个服务器端事务和一个客户端事务，并且将自己的URI添加到Via的栈顶，并生成一个Global ID做为Branch的值,以此值来表示一个与之相对应的事务.
SIP在事务层面定义了状态机和定时器来实现重传。

**下图是一个回复200 OK的成功的INVITE事务：
是不是INVITE事务区别在于** UAC需要为每个INVITE最终请求（2xx～6xx）生成ACK响应，而其他的请求消息（INFO,OPTION,etc）则不必如此。
因为INVITE的地位比较重要， 所以需要这样一个三次握手的机制来保证会话的双方都能够确保事务的完整性，这一点和TCP连接建立的三次握手比较像。
notes: invite 3次握手和tcp 3次握手一样.

注意在上图这两个UA中，每一个代理服务器都将自己的地址加入返回的ACK的Via头域中，而非成功的transaction则不会加入，见RFC 3261 (p.24)。
CSeq头域的值必须与INVITE相同，并且CSeq的方法必须是ACK。
中间响应消息 1xx 的使用则是为了节省网络开销设计的,
一旦 UC 收到任何一个中间响应消息,则 UC 必须停止消息重发定时器,不再重发这个请求消息,反之则直到收到最终响应消息或重发定时器超时.
一旦客户端UAC的事务在Calling状态收到任何中间响应消息1xx，事务则自动切换到Processing状态，停止请求消息的重发。并且需要将中间响应消息传送给TU事务用户。在呼叫业务中，TU以及上层应用可以根据中间响应消息在用户界面上提示用户。
一旦事务切换到Processing状态，任何其他中间响应消息也都要传送给TU。

而非INVITE事务则如下：

当UAC发出非INVITE请求时，它就会在事务管理子层上开启定时器F（TCP）或者是E（UDP），确保超时的时候进行重传。这适用于除了 ACK请求外的其他非INVITE请求。
每次超时重传时E的时间都被翻倍，直到最大的4秒。而F超时时，UAC就会认为是Timeout，这个事务将被删除。

对话(dialog/leg）： 代表着两个SIP UA之间持续一段时间的端到端的联系（如：一段通话）。
也就说仅仅存在于端到端的信令关系。
当一个UAS发出对于INVITE（或者REFER）的非失败最终响应<=>200OK（BYE），则Dialog建立，同时这也是session的开始。
UA和SIP代理服务器之间不会有对话。
在SIP中呼叫中包含一个或多个Dialog(这仅仅存在于多方通话中).Dialog终结于任意一端发出BYE.
Early Dialog可以通过UAC发出的CANCEL进行终结，更确切的说，所有早期对话在接收到非2XX最终响应时就被终结了。 
Call-ID-value、To、From进行标识。Forking时体现明显。

在这个Forking的例子中，这个用户注册了三个设备，在用户被呼叫时，INVITE的Contact头域就被转换为三个INVITE发往三个设备。后边的q指的是优先级，q越小，优先级越高。其中的SIP注册服务器相当于一个Forking代理，尽管这个实体接收到两个ACK，但是除了这些ACK外，它与主叫方的信令交互都是属于一个transaction的，而与被叫方则分别建立了Transaction。另外，被叫方收到的两个ACK由分别建立了Transaction。注意Device3返回了488这样的非成功响应，SIP注册服务器（Forking代理服务器）没有将该响应发回主叫方，这是SIP代理一个重要的特征，SIP代理还能自行发出Request:CANCEL消息。

UAS对话层接收到一个新的对话请求INVITE消息后，在建立会话的响应消息2xx中，将请求消息里面的所有Route-Record字段拷贝到2xx消息中，并且UAS的对话层必须添加一个Contact字段使得对话中后续的响应（INVITE在2xx响应的情况下也包括ACK消息）、请求消息可以直接和本UA联系。当UAC收到UAS的INVITE的2xx响应消息后，如果2xx中不包含任何Route-Record字段的，则UAC可以选择直接发送ACK到Contact中地址&端口。

会话(session)： 多方用户的媒体关系，在对话的控制下建立。

下图是Early dialog、Session、Dialog、Transaction等的在一个UA-UA的呼叫中的体现：

在这个例子中，通过INVITE事务而成功建立起来的dialog必须有一个ACK进行回应，这是第二个transaction的开始，尽管ACK并没有回复，但是由于新的 branch-value被填入，
所以这个ACK代表了一个新的Transaction的开始。
注意，此时** transaction number 
(CSeq)** 并没有根据INVITE而增加–也就是说若收到的最终响应不是2XX（是3XX–6XX），则该transaction中包含ACK，若最终响应是2XX，则**ACK属于一个新的transaction(此处存疑，国外有资料将其视为一个新的transaction，但是RFC3261中的意思却是ACK不属于INVITE 
Transaction，也不创建新的Transaction，但会重新计算Transaction参数–branchID)**。早期对话是UAS以一个1XX响应作为回应时建立的。这样做的好处是在UAC可能在早期对话中发出诸如UPDATE这样的SIP请求。

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

实例分析：

示例
注册-含鉴权

REGISTER sip:130909115229300920@10.64.49.44:7100 SIP/2.0   
Via: SIP/2.0/UDP 10.64.49.218:7100;rport;branch=z9hG4bK4162288924 
From: <sip:130909113319427420@10.64.49.218:7100>;tag=382068091
To: <sip:130909113319427420@10.64.49.218:7100>
Call-ID: 143225205      
CSeq: 1 REGISTER
Contact: <sip:130909113319427420@10.64.49.218:7100>
Max-Forwards: 70
User-Agent: Hikvision
Expires: 7200
Content-Length: 0

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.64.49.218:7100;rport=7100;branch=z9hG4bK4162288924
From: <sip:130909113319427420@10.64.49.218:7100>;tag=382068091
To: <sip:130909113319427420@10.64.49.218:7100>;tag=916944766
Call-ID: 143225205
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="hik", nonce="a8afe6fcbee6331d89d3eb0d3d19ce39", opaque="a853e4f25298413f9bf3a9aa6767857d", algorithm=MD5
User-Agent: Hikvision
Expires: 7200
Content-Length: 0

REGISTER sip:130909115229300920@10.64.49.44:7100 SIP/2.0
Via: SIP/2.0/UDP 10.64.49.218:7100;rport;branch=z9hG4bK3997518011
From: <sip:130909113319427420@10.64.49.218:7100>;tag=382068091
To: <sip:130909113319427420@10.64.49.218:7100>
Call-ID: 143225205
CSeq: 2 REGISTER
Contact: <sip:130909113319427420@10.64.49.218:7100>
Authorization: Digest username="admin", realm="hik", nonce="a8afe6fcbee6331d89d3eb0d3d19ce39", uri="sip:130909115229300920@10.64.49.44:7100", response="907ddb1bcc25174d7de4a96c947fb066", algorithm=MD5, opaque="a853e4f25298413f9bf3a9aa6767857d"
Max-Forwards: 70
User-Agent: Hikvision
Expires: 7200
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.64.49.218:7100;rport=7100;branch=z9hG4bK3997518011
From: <sip:130909113319427420@10.64.49.218:7100>;tag=382068091
To: <sip:130909113319427420@10.64.49.218:7100>;tag=705514612
Call-ID: 143225205
CSeq: 2 REGISTER
Contact: <sip:130909113319427420@10.64.49.218:7100>
User-Agent: Hikvision
Date: 2013-09-10T16:01:51
Content-Length: 0

预览-包含结束bye

INVITE sip:33010602001310019325@10.64.49.218:7100 SIP/2.0
Via: SIP/2.0/UDP 10.64.49.44:7100;rport;branch=z9hG4bK1839167633
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>
Call-ID: 2074790969
CSeq: 20 INVITE
Contact: <sip:130909115229300920@10.64.49.44:7100>
Content-Type: Application/SDP
Max-Forwards: 70
User-Agent: Hikvision
Subject: 33010602001310019325:0,130909115229300920:0
Content-Length: 216

v=0
o=33010602001310019325 0 0 IN IP4 10.64.49.44
s=Play
c=IN IP4 10.64.49.44
t=0 0
m=video 5494 RTP/AVP 96 97 98
a=rtpmap:96 PS/90000
a=rtpmap:97 MPEG4/90000
a=rtpmap:98 H264/90000
a=recvonly
y=0999999999

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.64.49.44:7100;rport=7100;branch=z9hG4bK1839167633
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>
Call-ID: 2074790969
CSeq: 20 INVITE
User-Agent: Hikvision
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.64.49.44:7100;rport=7100;branch=z9hG4bK1839167633
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>;tag=3330812776
Call-ID: 2074790969
CSeq: 20 INVITE
Contact: <sip:130909113319427420@10.64.49.218:7100>
Content-Type: Application/SDP
User-Agent: Hikvision
Content-Length: 162

v=0
o=33010602001310019325 0 0 IN IP4 10.64.49.44
s=Play
c=IN IP4 10.64.49.218
t=0 0
m=video 5514 RTP/AVP 96
a=rtpmap:96 PS/90000
a=sendonly
y=0060205514


ACK sip:130909113319427420@10.64.49.218:7100 SIP/2.0
Via: SIP/2.0/UDP 10.64.49.44:7100;rport;branch=z9hG4bK3589109049
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>;tag=3330812776
Call-ID: 2074790969
CSeq: 20 ACK
Contact: <sip:130909115229300920@10.64.49.44:7100>
Max-Forwards: 70
User-Agent: Hikvision
Content-Length: 0

BYE sip:130909113319427420@10.64.49.218:7100 SIP/2.0
Via: SIP/2.0/UDP 10.64.49.44:7100;rport;branch=z9hG4bK2928302365
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>;tag=3330812776
Call-ID: 2074790969
CSeq: 21 BYE
Contact: <sip:130909115229300920@10.64.49.44:7100>
Max-Forwards: 70
User-Agent: Hikvision
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.64.49.44:7100;rport=7100;branch=z9hG4bK2928302365
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>;tag=3330812776
Call-ID: 2074790969
CSeq: 21 BYE
User-Agent: Hikvision
Content-Length: 0