SIP协议深入介绍
网络事业部软交换开发部王笑蓉1．SIP简介
SIP（Session Initiation Protocol）是应用层控制协议，可以创建，修改，以及终止一个多媒体会话。它具有以下几个主要功能：
User
location：确定通信中的终端位置
availability：确定被叫方是否愿意进行通信
User
capabilities：确定用于通信的媒体类型及参数
User
setup：建立会话各方的会话参数
Session
management：终止会话，修改会话参数
Session
SIP协议需要和其他IETF协议一起来构成一个完整的多媒体通信构架。这些协议有：
RTP(Real Time Transport)：传输实时数据，提供QoS反馈信息
Streaming
protocol)：控制流媒体的传送
Time
RTSP(Real
MEGACO(Media Gateway Control Protocol)：控制媒体网关
SDP（Session Description Protocol）：描述多媒体会话
1．1SIP协议结构
SIP协议的行为模型可以用几个分层的相对独立处理阶段来描述：
1．语法及编码层
2．传输层
定义了客户端如何通过网络发送请求及接收响应，以及服务器端如何接收请求并发送响应。所有SIP逻辑实体都包含此层。
3．事务层
事务层处理应用层请求或响应消息的重发，响应与请求的匹配以及应用层的超时。一个SIP事务由一个请求和对该请求的所有响应构成，这些响应分临时响应
（provisional response）和最终响应(final response)。对于INVITE事务，对应于非
2xx响应的ACK确认消息也属于该事物，而对应于2xx响应的ACK确认消息则不
属于该INVITE事物。
UA以及stateful proxy均包含事务层，而stateless proxy 不包含事务层
一个事物根据逻辑功能分为客户事务(client transaction)和服务器事务（server transaction）。客户事务和服务器事务是存在于UA及有状态代理服务器(stateful
proxy server)的逻辑功能，stateless proxy不存在客户机及服务器事务，即不包含事
务层
客户机事务从事物用户TU（UA或stateful proxy）接收请求，并把此请求可靠传输到服务器事务。客户机事务还负责从传输层接收来自服务器的响应，滤除响应
的重发及不允许的响应（如对ACK请求的响应）。此外，对于INVITE请求，还负
责对除2xx外的final response（3xx-6xx）产生ACK确认。
服务器事务负责从传输层接收来自客户机的请求消息，并传递给TU，服务器事务滤除请求的重发。服务器事务还负责从TU接收响应，并传递给传输层发出。
此外，对于INVITE事务，还负责吸收对除2xx外的final response（3xx-6xx）产生
ACK确认。
2xx响应及与之对应的ACK确认采用特殊的端到端处理方式。2xx响应的重发由UAS负责，与2xx响应对应的ACK确认仅由UAC产生。这种端到端的处理
方式使得呼叫方能知道所有接受此呼叫的用户。因此，2xx响应的重发及对应2xx
的确认ACK分别由UAS core和UAC core而不由事务层处理。UAC及UAS间的
Proxy仅转发2xx响应及其对应的ACK确认。
客户事务收到传输层来的2xx响应后传递给TU，TU如何处理取决于TU是Proxy core还是UAC Core，UAC Core对INVITE事务产生ACK(non-INVITE事务
则无需ACK确认)，而Proxy仅Forward响应。
4．事务用户层
所有SIP逻辑元素，如UAC，UAS，stateful proxy，stateless proxy，registrar 均包含一个core以示区别。除stateless proxy 外的所有SIP逻辑实体core均是事务用户（TU）。
1．2SIP消息
SIP消息分为从客户机到服务器的请求消息以及从服务器到客户机的响应消息。
两种类型的消息结构相似，虽然语义不尽相同。两种消息都有一个起始行（start line）; 一个或多个头字段（ head fields）;一个空行（empty line）表示头部的结束；还包括一个可选择的消息体（message-body）。
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line / Status-Line
请求消息Request中请求行：
Request-Line = Method SP Request-URI SP SIP-Version CRLF
请求方法（Method）有六种：
REGISTER用来登记；INVITE,ACK,CANCEL用来建立对话；BYE用来结束对话；
OPTIONS用来咨询服务器的能力。
Request-URI:是SIP或SIPS URI，也支持“tel”URI，代表request所请求的用户或服务器。它的初始值可以被设成与to field中URI一致；一个比较特殊的情况是register，它是被设成所要登记地址的location service 的域。在呼叫寻址的过程中可以改写,在寻址过程中有详细介绍。
SIP-Version：表示request和response所使用的SIP版本。
响应消息Response中状态行：
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
状态码（Status-Code）有：
1xx: Provisional -- request received, continuing to process the request;
2xx: Success -- the action was successfully received, understood, and accepted;
3xx: Redirection -- further action needs to be taken in order to complete the request;
4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
5xx: Server Error -- the server failed to fulfill an apparently valid request;
6xx: Global Failure -- the request cannot be fulfilled at any server.
消息头字段（head fields）：
header = "header-name" HCOLON header-value *(COMMA header-value)
（字段值，参数名，参数值大小写无关）
(请求消息必须包括Via，To，From，CSeq，Call-ID，Max-Forwards六个字段)
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8 ; received=192.0.2.1 Via head field Via头字段保存所经过SIP网元的主机名或网络地址（可能还有端口号），消息中的所有Via头字段对请求消息而言，从下至上依次表示到当前所在
SIP网元为止，请求消息所经过的路径；对响应消息而言，从上至下依次表
示从当前网元开始，响应所应遵循的路径。
UAC在发出请求时，他在其请求中插入Via字段，该字段包含UAC的主机名或网络地址，在消息的传递过程中经过的每个SIP网元均在其转发的
请求中插入Via字段。同时当SIP网元收到上一跳SIP网元的请求消息时，
在上一跳SIP网元所插入的Via字段中加入received参数，代表所收到来
自上一跳SIP网元数据包的实际源地址（对于上一跳SIP网元具有多主机
地址即multi-homed host时，可能会混淆所用的网络接口）。见RFC3261
P180。
在SIP网元（UAC或Proxy）发出或转发请求消息时，在其插入的Via 字段中必须包含branch参数，该参数用于标识此请求消息所创建的事务。
UA所发送的所有request的branch 参数必须在时间和空间上都唯一；这
里也有一个例外，CANCEL以及非2XX response的ACK。对于CANCEL
来讲，与它所cancel的request的branch参数一致；此外，当INVITE请
求其final response是non-2xx响应时，对应该response的ACK与此
INVITE请求的branch参数一致。因而，CANCEL以及非2XX response
的ACK与其所cancel的request或对应的INVITE属于同一个事务。见RFC
3261 P39 P122
branch参数可以用做loop detection，这时参数必须被分成两部分：第一部分符合一般的原则（对于RFC3261，z9hG4bK），第二部分被用来
实现loop detection以用来区分loop和spiral。loop和spiral均指Proxy
收到一个请求后转发，然后此转发的请求又重新到达该Proxy，区别是loop
中请求的Request-URI以及其他影响Proxy处理的头字段均不变，而Spiral
请求中这些部分必需有某个发生改变，spiral发生的典型情况是
Request-URI发生改变。Proxy在插入Via字段前，其branch参数的loop
detection部分依据以下元素编码：To Tag，From Tag，Call-ID字段，
Request-URI，Topmost Via字段，Cseq的序号部分（即与request method
无关），以及proxy-require字段，proxy authorization字段。注意：request
method不能用于计算branch参数，比如CANCEL以及非2XX response
的ACK与其所cancel的request或对应的INVITE属于同一个事务，即其
branch参数相同。见RFC3261 P22 P25 P39 P95 P105
此外Via字段还包含SIP协议版本以及消息传输所用的传输协议。
Max-Forwards: 70
Max-Forwards head field 表示request到达UAS的跳数的限制。是一个整数，经过每一跳时减去一。如果Max-Forwards已经是零，可是request还没有到达目的地，
则就会产生一个483(too many hops)响应。
To: Bob
To head field 预置request所希望的的”logical” recipient（REGISTER事务除外），它可能是，也可能不是request 的最终recipient。To head field 在REGISTER事
务中表示要在Location Server中登记谁的地址，即地址绑定中的
address-of-record（vs. contact address）。
To head field可以有一个tag参数，to tag代表dialog的对等参与者（peer）。在UAC发出一个初始Dialog的请求（如INVITE）时，即发出
out-of-dialog请求时，由于dialog还没有建立，不含to tag参数。当UAS
收到INVITE请求时，在其发出的2xx或101-199响应中设置to tag参数，
与UAC设置的From Tag参数以及Call-ID（呼叫唯一标识）一起作为一个
Dialog ID（对话唯一标识，包含To tag，From Tag，Call-ID）的一个部分。
RFC3261规定只有INVITE请求与2xx或101-199响应可以建立Dialog（由
101-199响应创建的Dialog称为early dialog）。见RFC3261 P70
见RFC3261 P36，P159，P178
From: Alice
From head field 是request发起者的logical 标识（REGISTER事务除外）。from head field 在REGISTER事务中表示谁负责这次登记，如果由发起者负责该字段也就
是地址绑定中的address-of-record（vs. contact address）。From head field
与To head field类似，包含一个URI以及可选的display name，但From
head field不能是UA的主机IP地址或主机名，因为From字段只能是逻辑
名（From字段用于SIP元素决定对该请求采用何种处理规则，例如对From
字段代表的用户进行自动拒绝）。
From字段必须包含tag参数，在UAC发出一个out-of-dialog请求（对话建立请求）时，必须设置一个唯一的tag参数，作为Dialog ID的一个部
分。
见RFC3261 P37，P159，P172
Call-ID: a84b4c76e66710
Call-ID head field是一个邀请(Invitation)或来自同一个UAC用户的所有登记请求(Registeration，包括更新登记，取消登记)以及由此产生的一组响应的唯一标
识。一个邀请可以建立多个Dialog（当被叫用户有多个联系方式时），这成
为Forking，因而Call-ID只是一次呼叫邀请的唯一标识，Call-ID与UAC在
发出请求中设置的From Tag字段以及UAS在其相映中设置的To Tag字段三
者一起作为一个Dialog-ID。
在一个Dialog中，所有的requests和responses的Call-ID必须一致
同一UA的每一个register 的Call-ID必须一致。
见RFC3261 P37，P159，P166
CSeq: 314159 INVITE
CSeq head field用于在同一个Dialog中标识及排序事务（transaction）以及区分新的请求与请求的重发。
（请求的重发-retransmission与re-REQUEST不同，前者消息完全相同，
后者则与原请求不同。例如re-INVITE能用于改变媒体会话的参数；在原
请求产生4xx响应时，按照响应内容再re-REQUEST，见RFC3261 P45）。
CSeq包括顺序号和方法（method），方法必须和它所对应的request 相匹配。对于out-of-dialog的非register request，取值任意。
对于dialog内的每一个新的request（如BYE,re-INVITE,OPTION），Cseq的序号加1。但是对于CANCEL,ACK除外。对于ACK而言，Cseq
的序号必须与其所对应的request相同。对于CANCEL而言，Cseq的序
号也必须与其cancel掉的request相同。
注意：在同一个对话中的UAC和UAS分别维护自己的CSeq序号，他们发出请求的CSeq序号是不相关的。见RFC3261 P218
见RFC3261 P38，P159，P170，P218
Contact:
contact head field对于非Register事务，Contact header field 主要提供了UAC或UAS的直接联系SIP URI，UAC在发出的对话建立（out-of-dialog）INVITE请求
的Contact字段中提供自己的直接联系SIP URI，在UAS收到该请求后在
其发出响应的Contact字段中提供自己的直接联系SIP URI，这样在建立
对话后，UA间可以通过对方的直接联系SIP URI绕过Proxy直接发送请
求。
对于Register事务，表示地址绑定中的contact address（vs.
address-of-record）
Content-Type: application/sdp
Content-type header field 主要表示发给接收器的消息体的媒体类型。如果消息体不是空的，则Content-type header field一定要存在。如果Content-type header
field存在，而消息体是空的，表明该类型的媒体流长度是0。
Content-Length: 142
Content-length header field表示消息体的长度。是八位组的十进制数。
(Alice's SDP not shown)
消息体 SIP Message Body：
编码方式主要是由头部确定，现在为一般为SDP。
//SIP Request line/Status line ＋ Headers ＋ CRLF
v=0//版本号为0
o=UserA 2890844526 2890844526 IN IP4 https://www.doczj.com/doc/fa7398692.html,
//建立者用户名＋会话ID＋版本＋网络类型＋地址类型＋地址
s=Session SDP //会话名
c=IN IP4 100.101.102.103 //连接信息：网络类型＋地址类型＋地址
t=0 0 //会话活动时间起始时间＋终止时间
m=audio 49172 RTP/A VP 0
//媒体描述：媒体＋端口＋传送＋格式列表
音频＋端口49172 ＋传输协议RTP ＋格式A VT，有效负荷0（u率PCM编码）a=rtpmap:0 PCMU/8000
//0或多个会话属性：属性＋有效负荷＋编码名称＋抽样频率。
// rtpmap ＋0型＋ PCMU ＋ 8KHz
…… //其他SDP描述
SIP通过offer/answer模型来进行UA间的SDP会话描述交互：
a) UA发出会话描述，称为offer，它包含会话描述的提议，代表期望建立的通讯方式
（aduio,video,games），通讯方式的参数（如codex types）以及用于接收answer方媒体的地址。
b) 另一方UA接到offer，并用另一个会话描述予以响应，代表此UA接受的通讯方式，参
数以及用于接收offer方媒体的地址。
c) UA双方会话描述的offer/answer交互在一个建立的对话内进行，当一个INVITE请求
建立多个对话时，每个对话的UA间都要有offer/answer交互。
d) 会话描述SDP只能由INVITE，response，ACK的消息体携带，SDP的offer/answer
交互有以下几种方式：
i. INVITE携带SDP消息体发出offer，2xx response携带SDP消息体answer
response携带SDP消息体发出offer，ACK携带SDP消息体answer ii. 2xx
2．呼叫过程概述
alice’s https://www.doczj.com/doc/fa7398692.html, https://www.doczj.com/doc/fa7398692.html, bob’s
softphone proxy proxy SIP phone
上图中，Alice通过其PC上的SIP应用程序呼叫Bob，Bob使用一个在Internet上的SIP Phone。Alice通过Bob的SIP标识，即SIP URI sip:bob@https://www.doczj.com/doc/fa7398692.html,来呼叫Bob，其中https://www.doczj.com/doc/fa7398692.html, 是Bob的SIP服务提供者（SIP service provider）所在的域。同样Alice也有一个SIP URI sip:alice@https://www.doczj.com/doc/fa7398692.html,。
1)Alice’s softphone并不知道Bob以及https://www.doczj.com/doc/fa7398692.html,域中SIP代理服务器的具体位置，因而
Alice发送INVITE请求到Alice所在的https://www.doczj.com/doc/fa7398692.html,域中SIP代理服务器，该代理服务器的地址一般配置在Alice的softphone中，或者可以通过DHCP查找。
Alice作为UAC在发出请求时，他在其请求中插入Via字段，该字段包含UAC的主机名或网络地址。Via字段的branch参数用于标识此请求消息所创建的事务。
此时，Alice作为UAC发出的是一个out-of-dialog请求（对话建立请求），必须在From 字段中设置tag参数，作为Dialog ID的一个部分。
Alice作为UAC在Contact字段中提供自己的直接联系SIP URI。
F1 INVITE Alice -> https://www.doczj.com/doc/fa7398692.html, proxy
INVITE sip:bob@https://www.doczj.com/doc/fa7398692.html, SIP/2.0
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob
From: Alice
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
2)https://www.doczj.com/doc/fa7398692.html,代理服务器收到INVITE请求后发送100（Trying）响应给Alice，该响应包
含与INVITE同样的To，From，Call-ID，CSeq以及Via字段的branch参数，通过这些字段建立响应与请求间的对应关系。
F2 100 Trying https://www.doczj.com/doc/fa7398692.html, proxy -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob
From: Alice
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
3)Alice在https://www.doczj.com/doc/fa7398692.html,域中的SIP代理服务器不负责域https://www.doczj.com/doc/fa7398692.html,，因而通过某种特殊形式
的DNS定位https://www.doczj.com/doc/fa7398692.html,域中的SIP代理服务器，从而获得其IP地址，并向其转发INVITE 请求。
在https://www.doczj.com/doc/fa7398692.html,代理服务器收到上一跳Alice UAC的请求消息时，在Alice UAC所插入的Via字段中加入received参数，代表所收到来自上一跳SIP网元数据包的实际源地址。
在https://www.doczj.com/doc/fa7398692.html,代理服务器向https://www.doczj.com/doc/fa7398692.html,代理服务器转发INVITE请求前，在INVITE 请求的Via字段中加上自己的地址（INVITE请求的Via字段已包含Alice的地址），同时Max-Forwards由于经过了一跳而减一。
F3 INVITE https://www.doczj.com/doc/fa7398692.html, proxy -> https://www.doczj.com/doc/fa7398692.html, proxy
INVITE sip:bob@https://www.doczj.com/doc/fa7398692.html, SIP/2.0
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 69
To: Bob
From: Alice
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
4)在https://www.doczj.com/doc/fa7398692.html,代理服务器收到https://www.doczj.com/doc/fa7398692.html,代理服务器转发的INVITE请求后，向其返回
100（Trying）响应以通知收到并正在处理该请求。
F4 100 Trying https://www.doczj.com/doc/fa7398692.html, proxy -> https://www.doczj.com/doc/fa7398692.html, proxy
SIP/2.0 100 Trying
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob
From: Alice
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
5)https://www.doczj.com/doc/fa7398692.html,域中的SIP代理服务器通过查询其Location Service数据库获得Bob的当前实
际地址，并改写Request-URI。（Bob通过Registrar服务器在Location Service中建立了其SIP URI与实际地址的映射）。
https://www.doczj.com/doc/fa7398692.html,代理服务器在转发其收到的INVITE请求至Bob的SIP Phone前，在Via 字段中加入其地址。
F5 INVITE https://www.doczj.com/doc/fa7398692.html, proxy -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 68
To: Bob
From: Alice
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
6)Bob的SIP Phone收到转发来的INVITE请求后返回180（Ringing）响应消息，该响应
将沿着INVITE请求的传递路径返回Alice的softphone，途中的每个代理通过消息中的Via字段决定转发的目的地，并把包含自己的地址的Via字段从消息中删除。
Bob作为UAS发出的180（Ringing）响应消息拷贝其收到的INVITE请求的Via，To，From，Call-ID，CSeq，Record-Route等头字段，并在To头字段中加入Tag参数（含有Tag参数的To，From字段与Call-ID一起作为该对话Dialog的唯一标识）。此外，响应消息的Contact头字段放入Bob SIP Phone的直接联系URI地址。
F6 180 Ringing Bob -> https://www.doczj.com/doc/fa7398692.html, proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob
From: Alice
Call-ID: a84b4c76e66710
Contact:
CSeq: 314159 INVITE
Content-Length: 0
F7 180 Ringing https://www.doczj.com/doc/fa7398692.html, proxy -> https://www.doczj.com/doc/fa7398692.html, proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob
From: Alice
Call-ID: a84b4c76e66710
Contact:
CSeq: 314159 INVITE
Content-Length: 0
F8 180 Ringing https://www.doczj.com/doc/fa7398692.html, proxy -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob
From: Alice
Call-ID: a84b4c76e66710
Contact:
CSeq: 314159 INVITE
Content-Length: 0
7)当Bob拿起话筒时，其SIP Phone将发出200（OK）响应消息，该响应与INVITE请求
类似，均包含一个SDP媒体描述的消息体，代表Bob想建立的会话的媒体描述。上述过程提供了会话各方的媒体协商机制。
如果Bob不想应答或占线时将发出错响应而不是200（OK），这将不会建立会话。
除DNS及Location Service等功能外，代理服务器也可以具有“柔性路由决策”功能，例如当Bob返回486（Busy Here）响应时，https://www.doczj.com/doc/fa7398692.html, 代理服务器可以把INVITE 请求代理到Bob的其他联系方式，如语音邮件。SIP 代理服务器也可以发送请求消息到一组Bob登记的地址。
与180响应类似，200（OK）响应将沿着INVITE请求的传递路径返回Alice的softphone，途中的每个代理通过消息中的Via字段决定转发的目的地，并把包含自己的地址的Via字段从消息中删除。
F9 200 OK Bob -> https://www.doczj.com/doc/fa7398692.html, proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8 ;received=192.0.2.1
To: Bob
From: Alice
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
F10 200 OK https://www.doczj.com/doc/fa7398692.html, proxy -> https://www.doczj.com/doc/fa7398692.html, proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob
From: Alice
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
F11 200 OK https://www.doczj.com/doc/fa7398692.html, proxy -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob
From: Alice
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
8)Alice收到Bob’s SIP Phone发出的200（OK）后将发出ACK确认请求消息，因为Alice
发出的INVITE请求和Bob发出的180(Ringing)响应中的Contact字段中给出了这两个UA间的直接联系地址，因而ACK消息可以绕过代理直接发送到Bob，这样就完成了建立SIP会话的INVITE/200/ACK三次握手。
该ACK请求属于前面已建立的对话（相同对话标示：Call-ID，From| Tag，To|Tag），但与BYE或re-INVITE不同，ACK和CANCEL请求与其对应的INVITE请求的CSeq 序号相同。
F12 ACK Alice -> Bob
ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKnashds9
Max-Forwards: 70
To: Bob
From: Alice
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
9)INVITE/200/ACK三次握手后，Alice与Bob间的媒体会话建立。会话双方按照在SDP
媒体协商中所确定的格式发送媒体包，一般来说端到端的媒体包路由与SIP信令消息路由不同。
Alice或Bob均可以改变媒体会话的参数，这通过re-INVITE请求实现，在其SDP 消息体中包含新的媒体描述，该re-INVITE对应前面已存在的一个对话（通过对话标示：Call-ID，From| Tag，To|Tag），这样对方知道是修改一个已存在的会话而不是建立一个新会话。对方发出200(OK)响应来接受绘画改变，而发起方以ACK确认，如对方不同意改变，则发出488(Not Acceptable Here)，发起方同样以ACK确认。re-INVITE的失败不会导致原会话的失败。
因为re-INVITE与原INVITE属于同一个Dialog对话，其Cseq头字段的序号为原序号加一。
10)Bob挂机，发出BYE请求消息，消息绕过代理直接发往Alice。此外，Alice作为UAC，
Bob作为UAS分别维护其私有的CSeq编号空间，因而其所发出请求的CSeq序号是不相关的，假如BYE请求由Alice发出，则其CSeq序号为314159+1=314160。
因为由INVITE的被叫方Bob发出BYE请求，其To 和From字段互换。
F13 BYE Bob -> Alice
BYE sip:alice@https://www.doczj.com/doc/fa7398692.html, SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob
To: Alice
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0
11)Alice收到BYE消息后发出200（OK）响应以确认收到了BYE请求，从而终止整个会
话以及BYE事务。Bob收到200（OK）响应后无需发ACK确认，基于INVITE请求的可靠性考虑，ACK只用来确认INVITE请求产生的响应。
F14 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob
To: Alice
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0
3．登记过程概述
Proxy及 Redirect服务器负责接收发往其负责域中UAs的请求消息，并通过查询该 SIP
域Location Service中的address-of-record vs. contact addresses地址绑定（一个address-of-record可绑定多个contact addresses），找到与消息Request-URI相匹配的address-of-record后，Proxy或Redirect服务器把消息Forward到此address-of-record对应的contact addresses（此时消息的Request-URI改写为这些contact addresses）。
登记服务器（Registrar）是一种特殊的UAS，它负责为所在域中的location server创建地址绑定。在很多情况下，某域中的登记服务器和代理服务器作为不同逻辑实体存在于同一个网络设备，如果他们处在不同的网络设备，注册用户也可通过代理服务器访问登记服务器。
Service必须保证域中的登记服务器能够对其进行读写操作，而域中的代理服务 Location
器，重定向服务器能进行读操作。
REGISTER请求消息不创建Dialog，REGISTER请求消息头字段必须包含以下部分（除Contact外）
Request-URI：表示location server所在的域，如sip:https://www.doczj.com/doc/fa7398692.html,。SIP URI中的“userinfo”“@”不能出现在Request-URI中。
To：表示要登记的address-of-record，即代表要创建，查询，修改谁的contact addresses 地址绑定，其形式为SIP URI。
From：表示负责此登记者的address-of-record，除由第三方登记的情况外，From字段与To字段相同。
Call-ID：由同一UAC向同一registrar的所有登记刷新请求推荐具有相同Call-ID。
CSeq：具有相同Call-ID的登记请求CSeq序号依次加一。
Contact：
对于新建或添加登记请求消息，代表要新建，添加与To字段的address-of-record 绑定的contact address，返回的2xx响应的contact字段包含所有登记的contact addresses)。
对于登记查询请求消息，不包含该字段，但返回2xx响应的contact字段（一个或多个）代表从location service中查询到的地址绑定中与To字段的address-of-record相对应的contact addresses。
对于删除登记请求消息（expires参数为0），代表要删除与To字段的address-of-record绑定的contact address。contact字段为 * 代表要删除与To字段的address-of-record绑定的所有contact addresses(此时Expires头字段必需为0)。
Contact字段的expires参数代表地址绑定的有效期限，当其为0时代表删除绑定，expires参数也可用Expires头字段代替。
下面是登记过程的实例：
https://www.doczj.com/doc/fa7398692.html, bob’s
Registrar softphone
F1 REGISTER Bob -> Registrar
REGISTER sip:https://www.doczj.com/doc/fa7398692.html, SIP/2.0
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,:5060;branch=z9hG4bKnashds7 Max-Forwards: 70
To: Bob
From: Bob
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact:
Expires: 7200
Content-Length: 0
F2 200 OK Registrar -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4这是传输层加的
To: Bob
From: Bob
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact:
Expires: 7200
Content-Length: 0
4．对话内（Within Dialog）消息的发送及路由处理
4．1UAC与UAS对话的建立及状态
见RFC3261 P69-72
对话（Dialog）代表UA间端到端的SIP联系，对于某个UA而言，一个对话具有唯标识dialog-ID，它由Call-ID，Local Tag，Remote Tag。
RFC3261规定Dialog的建立过程是UAC发出out-of-dialog INVITE请求，然后UAS 返回2xx或101-199响应（由101-199响应创建的Dialog称为early dialog）。
当out-of-dialog INVITE消息路由中的某个SIP代理服务器希望对话建立后的所有请求消息(with in dialog)均通过通过此Proxy时，则在其转发的INVITE消息中加入Record-Route 字段，填入能解析为其主机名或IP地址的URI。
UAS返回的2xx或101-199响应拷贝了请求消息的Record-Route头字段，加上To Tag 参数，并在Contact字段中设置自己的直接联系SIP URI。建立对话后，UAS构造UAS端的对话状态（state of dialog），UAS在整个对话中均保存及维护此状态，对话状态包含以下元素：
a)secure flag：当请求消息通过TLS到达时，secure flag为TRUE。
b)route set：设为收到的INVITE请求的Record-Router头字段中的URIs，保持原
有顺序。
c)remote target：INVITE请求的Contact字段。
d)remote sequence number：INVITE请求的CSeq字段序号。
在同一个对话中的UAC和UAS分别维护自己的CSeq序号，他们发出请求的CSeq
序号是不相关的。
e)local sequence number：此时为空
f)Dialog-ID：
i.Call-ID：INVITE请求的Call-ID字段
ii.Local Tag：响应的To Tag
iii.Remote Tag：INVITE请求的From Tag
g)Remote URI：INVITE请求的From字段
h)Local URI：INVITE请求的To字段
UAC收到UAS建立对话的2xx或101-199响应后， UAC构造UAC端的对话状态（state of dialog），UAS在整个对话中均保存及维护此状态，对话状态包含以下元素：
i)secure flag：当请求消息通过TLS到达时，secure flag为TRUE。
j)route set：设为收到响应消息的Record-Router头字段的URIs，但顺序反向。
k)remote target：响应消息的Contact字段。
l)local sequence number：请求消息的CSeq字段序号。
在同一个对话中的UAC和UAS分别维护自己的CSeq序号，他们发出请求的CSeq
序号是不相关的。
m)remote sequence number：此时为空
n)Dialog-ID：
i.Call-ID：请求的Call-ID字段
ii.Local Tag：请求的From Tag
iii.Remote Tag：响应消息的To Tag
o)Remote URI：请求的To字段
p)Local URI：请求的From字段
4．2对话建立后，UAC的within dialog请求消息处理
见RFC3261 P72-74
对话建立后，作为对话一方的UA维护各自的对话状态，一般是在作为UAC发出对话内(with in dialog)请求（CANCEL，ACK除外）后local sequence number加一，作为UAS 收到请求后remote sequence number设置为该请求的CSeq字段序号。
当对话中的UA作为UAC发出请求消息时，请求消息中的头字段根据该UA的对话状态按照对应关系进行设置：
对于非CANCEL，ACK请求，CSeq序号设为local sequence number加一，对于CANCEL，ACK请求，CSeq序号设为与local sequence number相同。
UAC用其对话状态中的remote target和route set来构造请求消息中的Request-URI 和Router头字段，规则如下：
a)当route set为空时，UAC必须把消息的Request-URI中设置为remote target。（如
图1中的BYE请求）
b)当route set为非空，且route set的第一个URI包含restrict router “lr” 参数，则
在必须把消息的Request-URI设置为remote target，并依据route set在消息中加
上Route头字段（如下例（1）U1和例（2）U2发出的BYE请求）。
c)当route set为非空，且route set的第一个URI不包含restrict route “lr” 参数，则
必须把消息的Request-URI中设置为此route set URI（截去不容许的lr等参数），
并依据route set在消息中加上Route头字段（除去第一个route set URI），此外把
remote target加在Route头字段最后。
UAC发送消息时要遵循以下原则：
a)如果route set中的第一项是strict router，消息的下一跳目的地置于request中的
request-URI。
b)如果route set中的第一项是loose router, 消息的下一跳目的地是request中的route
head field 中的第一项。
c)如果不存在route head field,则消息的下一跳目的地是request中的request-URI。
4．3Stateful Proxy的请求消息处理
SIP代理服务器的主要功能是为发往UAS的请求消息和发往UAC的响应消息进行路由，Proxy在转发消息前可以对消息进行修改。Stateful Proxy在收到新的请求后创建新的服务器事务（Service Transaction），Stateful Proxy其Proxy Core属于TU，这里介绍的代理服务器行为是指Proxy Core的行为。
a.route information preprocessing
i.代理服务器必须先检查request消息中的request-URI，如果request-URI中的一
个值是代理服务器先前放到Record-route head field中去的，则代理服务器将
Route head field 中的最后一项（一般是UAC的remote target）放到request-URI
中去，然后将这个值从route head field中去掉。理服务器再去处理这个修改过
的request.
ii.如果route head field 中的第一个值是这个代理服务器，就将它从route head field中去掉。
b.postprocessing routing information
如果request消息中有route head field，则代理服务器检查它的第一个值，如果第一
个值不含有1r这个参数（表明是loose router）,代理服务器必须做如下操作：首先，代理服务器将request-URI（一般是UAC的remote target）放到route head field中，作为它的最后一项；
其次，代理服务器将route head field的第一项放到request-URI中去，并将它从route head field中去掉。
c.determine next-hop address,port,and transport
i.如果代理服务器将request送到一个strict-routing element,则下一跳目的地是
request-URI，否则下一跳是request中的route head field 中的第一项，ii.如果不存在route head field，则消息的下一跳是request中的request-URI（对于within dialog request，request-URI为UAC的remote traget）。.
代理服务器还必须处理收到的reponse.其中值得注意的一点是，代理服务器将response 中的via head field中的第一项（即该代理服务器加上的Via字段）去掉。如果没有via head field，则表明这个代理服务器是response的最终地，不再将它再往前送。
4．4实例：
（1）U1 P1 P2 U2
P1,P2都是loose router.
其中U1向其outbound proxy P1发出：
INVITE sip:callee@https://www.doczj.com/doc/fa7398692.html, SIP/2.0
Contact: sip:caller@https://www.doczj.com/doc/fa7398692.html,
P1发现它并不负责https://www.doczj.com/doc/fa7398692.html,,它就查询DNS，并将它发送到查到的P2，在转发的消息中加上record-route 头字段，填入能解析为P1主机名或IP地址的URI。
INVITE sip:callee@https://www.doczj.com/doc/fa7398692.html, SIP/2.0
Contact: sip:caller@https://www.doczj.com/doc/fa7398692.html,
Record-Route:
P2得到了这个request,它是负责https://www.doczj.com/doc/fa7398692.html,域，所以它就去查询该域的location service，用查到的U2登记的contact address改写request-URI。此外，加了record-route 头字段，由于没有route head field，所以它解析新的request-URI，并把它发送到那儿。
INVITE sip:callee@https://www.doczj.com/doc/fa7398692.html, SIP/2.0
Contact: sip:caller@https://www.doczj.com/doc/fa7398692.html,
Record-Route:
Record-Route:
在 https://www.doczj.com/doc/fa7398692.html,域中的被叫方收到了request, 并且产生一个response 200 OK: SIP/2.0 200 OK
Contact: sip:callee@https://www.doczj.com/doc/fa7398692.html,
Record-Route:
Record-Route:
此时，在 https://www.doczj.com/doc/fa7398692.html,中的被叫方UAS为建立的对话设置UAS端对话状态（dialog state），其中remote target URI 为：
sip:caller@https://www.doczj.com/doc/fa7398692.html,
route set是:
(
这个response通过P2,P1,最后U1收到，U1设置UAC端对话状态，其中remote target URI ：
sip:callee@https://www.doczj.com/doc/fa7398692.html, and its
route set:
(
由于所有的route head field 中的值都有lr parameter, 所以U1产生 BYE request，其Request URI 设为U1端对话状态的remote target:
一、SIP协议介绍： 会话发起协议SIP（Session Initiation Protocol）是一个应用层控制信令协议，用于建立、更改和终止多媒体会话或呼叫。SIP作为一个基础，可以在其上提供很多不同的服务。目前已经定义的媒体类型有音频、视频、应用、数据、控制。 二、SIP呼叫流程： 注册流程： （1）用户首次试呼时，终端代理A 向代理服务器发送REGISTER 注册请求； （2）代理服务器通过后端认证/计费中心获知用户信息不在数据库中，便向终端代理回送401Unauthorized 质询信息，其中包含安全认证所需的令牌； （3）终端代理提示用户输入其标识和密码后，根据安全认证令牌将其加密后，再次用REGISTER 消息报告给代理服务器； （4）代理服务器将REGISTER 消息中的用户信息解密，通过认证/计费中心验证其合法后，将该用户信息登记到数据库中，并向终端代理A 返回成功响应消息200 OK。 呼叫流程：
（1）用户摘机发起一路呼叫，终端代理A 向该区域的代理服务器发起Invite 请求；（2）代理服务器通过认证/计费中心确认用户认证已通过后，检查请求消息中的Via 头域中是否已包含其地址。若已包含，说明发生环回，返回指示错误的应答；如果没有问题，代理服务器在请求消息的Via 头域插入自身地址，并向Invite 消息的To 域所指示的被叫终端代理B 转送Invite 请求； （3）代理服务器向终端代理A 送呼叫处理中的应答消息，100 Trying； （4）终端代理B 向代理服务器送呼叫处理中的应答消息，100 Trying; （5）终端代理B 指示被叫用户振铃，用户振铃后，向代理服务器发送180 Ringing 振铃信息； （6）代理服务器向终端代理A 转发被叫用户振铃信息； （7）被叫用户摘机，终端代理B 向代理服务器返回表示连接成功的应答（200 OK）；（8）代理服务器向终端代理A 转发该成功指示（200 OK）； （9）终端代理A 收到消息后，向代理服务器发ACK 消息进行确认； （10）代理服务器将ACK 确认消息转发给终端代理B； （11）主被叫用户之间建立通信连接，开始通话； 结束流程：
SIP协议学习总结 1、SIP协议定义 SIP（Session Initiation Protocol，即初始会话协议）是IETF提出的基于文本编码的IP电话/多媒体会议协议。用于建立、修改并终止多媒体会话。SIP 协议可用于发起会话，也可以用于邀请成员加入已经用其它方式建立的会话。多媒体会话可以是点到点的话音通信或视频通信，也可以是多点参与的话音或视频会议等。SIP协议透明地支持名字映射和重定向服务，便于实现ISDN，智能网以及个人移动业务。SIP协议可以用多点控制单元（MCU）或全互连的方式代替组播发起多方呼叫。与PSTN相连的IP电话网关也可以用SIP协议来建立普通电话用户之间的呼叫。 SIP协议在IETF多媒体数据及控制体系协议栈结构的位置 H.323SIP RTSP RSVP RTCP H.263 etc. RTP TCP UDP IP PPP Sonet AAL3/4AAL5 ATM Ethernet PPP V.34 SIP协议支持多媒体通信的五个方面： ◆用户定位：确定用于通信的终端系统； ◆用户能力：确定通信媒体和媒体的使用参数； ◆用户有效性：确定被叫加入通信的意愿； ◆会话建立：建立主叫和被叫的呼叫参数； ◆会话管理：包括呼叫转移和呼叫终止； SIP协议的结构 SIP是一个分层的协议，也就是说SIP协议由一组相当无关的处理层次组成，这些层次之间只有松散的关系。 SIP最底层的是它的语法和编码层。编码方式是采用扩展的Backus-Naur Form grammar (BNF范式)。 第二层是传输层。它定义了一个客户端发送请求和接收应答的方式，以及一 个服务器接收请求和发送应答的方式。所有的SIP要素都包含一个通讯层。 第三层是事务层。事务是SIP的基本组成部分。一个事务是UAC向UAS发送的一个请求以及UAS向UAC发送的一系列应答。事务层处理应用服务层的重发，匹配请求的应答，以及应用服务层的超时。任何一个用户代理客户端完成的事情都是
Osip2是一个开放源代码的sip协议栈，是开源代码中不多使用C语言写的协议栈之一，它具有短小简洁的特点，专注于sip底层解析使得它的效率比较高。 eXosip是Osip2的一个扩展协议集，它部分封装了Osip2协议栈，使得它更容易被使用。 一、介绍 Osip2是一个开放源代码的sip协议栈，是开源代码中不多使用C语言写的协议栈之一，它具有短小简洁的特点，专注于sip底层解析使得它的效率比较高。但缺点也专门明显，首先确实是可用性差，没有专门好的api封装，使得上层应用在调用协议栈时专门破裂；其次，只做到了transaction层次的协议过程解析，
缺少call、session、dialog等过程的解析，这也增加了使用的难度；再次，缺少线程并发处理的机制，使得它的处理能力有限。 eXosip是Osip2的一个扩展协议集，它部分封装了Osip2协议栈，使得它更容易被使用。eXosip增加了call、dialog、registration、subscription等过程的解析，使得有用性更强。然而eXosip局限于UA的实现，使得它用于registrar、sip server等应用时极其不容易。另外，它并没有增加线程并发处理的机制。而且只实现了音频支持，缺少对视频和其它数据格式的支持。 综合来讲，Osip2加上eXosip协议栈仍然是个实现Sip协议不错的选择。因此需要依照不同的需求来增加更多的内容。 二、Osip2协议栈的组成 Osip2协议栈大致能够分为三部分：sip协议的语法分析、sip 协议的过程分析和协议栈框架。 1、Sip协议的语法分析：
要紧是osipparser2部分，目前支持RFC3261和RFC3265定义的sip协议消息，包括INVITE、ACK、OPTIONS、CANCEL、BYE、SUBSCRIBE、NOTIFY、MESSAGE、REFER和INFO。不支持RFC3262定义的PRACK。 遵循RFC3264关于SDP的offer/answer模式。带有SDP的语法分析。 支持MD5加解密算法。支持Authorization、www_authenticate 和proxy_authenticate。 2、Sip协议的过程分析： 要紧是osip2部分，基于RFC3261、RFC3264和RFC3265的sip 协议描述过程，围绕transaction这一层来实现sip的解析。 Transaction是指一个发送方和接收方的交互过程，由请求和应答组成。请求分为Invite类型和Non-Invite类型。应答分为响应型的应答和确认型的应答。响应型的应答是指那个应答仅代表
第一章SIP协议主要消息 1.1 SIP消息分类 SIP协议是以层协议的形式组成的，就是说它的行为是以一套相对独立的处理阶段来描述的，每个阶段之间的关系不是很密切。 SIP协议将Server和User Agent之间的通讯的消息分为两类：请求消息和响应消息。 请求消息：客户端为了激活特定操作而发给服务器的SIP消息，包括INVITE、ACK、BYE、CANCEL、OPTION和UPDATE消息。 SIP请求的6种方法： 1、邀请（INVITE）——邀请用户加入呼叫 2、确认（ACK）——确认客户机已经接收到对INVITE的最终响应 3、可选项（OPTIONS）——请求关于服务器能力的信息 4、再见（BYE）——终止呼叫上的两个用户之间的呼叫 5、取消（CANCEL） 6、注册（REGISTER）——提供地址解析的映射，让服务器知道其它用户的位置 响应消息：服务器向客户反馈对应请求的处理结果的SIP消息，包括1xx、2xx、3xx、4xx、5xx、6xx响应 1.2 SIP消息结构 请求消息和响应消息都包括SIP消息头字段和SIP消息体字段； SIP消息头主要用来指明本消息是有由谁发起和由谁接受，经过多少跳转等基本信息； SIP消息体主要用来描述本次会话具体实现方式； 1.3 消息格式 1.3.1 请求消息格式 SIP请求消息的格式，由SIP消息头和一组参数行组成，如图1-1所示。通过换行符区分命令行和每一条参数行。
图1-1 SIP 请求消息结构 注意：参数行的顺序不是固定的。对应的参数解释见错误！未找到引用源。。 消息体定义： Call-ID ：头字段是用来将消息分组的唯一性标识 From ：头字段是指示请求发起方的逻辑标识，它可能是用户的注册地址。From 头字段包含一个URI 和一个可选的显示名称 CSeq ：头字段用于标识事务并对事务进行排序。它由一个请求方法和一个序列号组成，请求方法必须与对应的请求消息类型一致 Max-Fowords ：头字段限定一个请求消息在到达目的地之前允许经过的最大跳数。它包含一个整数值，每经过一跳，这个值就被减一。如果在请求消息到达目的地之前该值变为零，那么请求将被拒绝并返回一个483（跳数过多）错误响应消息。 Via ：头字段定义SIP 事务的下层（传输层）传输协议，并标识响应消息将要被发送的位置。只有当到达下一跳所用的传输协议被选定后，才能在请求消息中加入Via 头字段值。 expires ：参数指出了该值中包含的URI 地址的有效期。这个参数的值是以秒为单位计算的。如果没有提供该参数，那么URI 地址的有效期由Expires 头字段值来确定。 消息头
1.SIP 1.1.1.SIP格式 每条SIP消息由以下三部分组成： （1）起始行（Start Line）：每个SIP消息由起始行开始。起始行传达消息类型（在请求中是方法类型，在响应中是响应代码）与协议版本。起始行可以是一请求行（请求）或状态行（响应）。 （2）SIP头：用来传递消息属性和修改消息意义。它们在语法和语义上与HTTP头域相同（实际上有些头就是借自HTTP），并且总是保持格式：<名字>:<值>。 （3）消息体：用于描述被初始的会话（例如，在多媒体会话中包括音频和视频编码类型，采样率等）。消息体能够显示在请求与响应中。SIP清晰区别了在SIP起始行和头中传递的信令信息与在SIP 范围之外的会话描述信息。可能的体类型就包括本文将要描述的SDP会话描述协议。
1.1. 2.消息头 Header field where proxy ACK BYE CAN INV OPT REG Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alter-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * Cseq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o o Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c - o o o o o Retry-After 404, 413,
SIP协议与视频通信 关键字：SIP视频通信H.323 摘要：文章简要概述现有视频通信技术，包括H.320与H.323应用。然后介绍IETF可以用于视频通信的协议：SIP。在SIP介绍中首先描述SIP协议的历史，然后描述SIP的组成部件。明确部件后举例说明了一个SIP呼叫建立的流程。在第四部分通过与H.323协议族比较来说明SIP用于视频通信的优劣。最后指出SIP协议用于视频通信的前景。 引言 沟通是人类生存的基本需求，通信已成为现代生活中必不可少的内容。在任何时间，任何地点与人和人通信是电信发展的目标。通信技术发展到今天，电话网几乎覆盖全球。语音通信(电话)似乎已基本达到上述目标。但是随着技术的发展，人们已不满足仅仅语音通信。大规模视频通信已成为下一阶段信息产业发展方向。虽然电视会议已出现二十多年，当前不但统一的标准而且有成熟的产品；但是由于种种原因一直没有得到象电话那样的普遍应用。视频通信似乎一直是一座未被足量开采的金矿。随着传输技术的发展，带宽资源已不是瓶颈；随着一场SARS的肆虐，视频通信又成为热点。随着SIP协议的出现，视频通信在技术上又有了新的发展动力。 视频通信协议概述 基于H.320的视频应用 传统会议电视利用以电话网2M或者1.544M直联数字线路连接终端会议电视设备进行实时音频、视频和数据信息的传送。通过使用多点控制器，可以在一块控制板具备所有主会场的操作切换功能。最初会议电视厂家以各自专用的压缩和通信算法进行生产，各个会议电视厂家产品无法互联互通。 随着ITU-T推出H.320协议，上述问题得到很大程度的解决。H.320是同步电路交换网(如ISDN)上现频传输的标准。电路交换网适用于实时应用，如长时间和具有确定延迟的音频和视频信号传递。电路的建立依赖于带外信令、集中的路由控制和昂贵的交换设备。使用H.320协议，电话网上中商用会议电视的理想电路是384 kbps。使用384kbps的电路可以以合理的成本提供高质量的音频和视频信号。采用2M或者1.544M的中继直连当然很容易满足上述带宽要求，但是作等于建立专网，价格将令用户难以承受。 由于电话网络中继价格不断下降以及大量既成事实的基于H.320的电视会议应用，虽然H.320通信成本相对于现有的其它方式稍显昂贵，但其市场仍将在未来数年里继续成长——尽管其成长是缓慢的。 基于H.323协议的视频应用 H.323是国际电信联盟制定的局域网上的多媒体通信系列标准。该协议专门为不提供服务质量(QOS)保证的局域网技术制定，例如运行于以太网、快速以太网和令牌环网(Token Ring)上的TCP／IP和IPX。尽管H.323协议特别为局域网制定，只要带宽时延满足要求同样可以应用在更大范围例如城域网和广域网。1997年5月，国际电信联盟第15研究小组重新定义
2017年第2期信息通信2017 (总第170 期）INFORM ATION & COMMUNICATIONS (Sum. No 170) SIP协议介绍及应用前景分析 杜鑫 (中国人民解放军9155〇部队3分队） 摘要:S IP是一种源于互联网的IP语音会话控制协议，具有灵活、易于实现、便于扩展等特点。文章介绍了 S IP协议的发 展历史、网络组成，通过与传统的电信网络协议对比分析了 S IP协议的特点，结合S IP协议特点及现状对其应用前景进 行了分析。 关键词：SIP ;融合通信;VO LTE;互联网 中图分类号:TN913.23 文献标识码:A文章编号：1673-1131(2017)02-0105-02 1S IP协议的发展历史 SIP(Session Initiation Protocal)会话初始化协议的概念在 1996年出现，主要运用在Internet的不同文本类型当中，用于 电子邮件以及文字聊天等各项环节中。1999年由IE T F最初 建立，应用于Internet的相关网络环境结构当中，实现实时性 通讯。二H世纪初，由IE T F当中的S IP工作团队发出 RFC3261建议后才得到了逐渐推广。 S IP协议最初应用于Internet网络中，实现多媒体的会话 建立控制，后来作为IMS(IP M ultim edia Subsystem IP多媒体 子系统）的主要信令应用于电信领域的VOBB(V oiceover Broad Band宽带语音)，近年来随着LT E的推广，SIP成为LTE 的语音最终解决方案V O LTE的主要信令协议，其应用范围从 特定环境逐步扩展至主流多媒体通信环境。 2 S IP网络组成 2.1 S IP协议在IM S中的应用 S IP协议是IM S中的基本协议,应用于M w、U t、ISC、M i、M g、M j、M k、M r等众多接口，整个IM S网络的会话控制功能 都是由S IP协议完成，具体使用情况如图1所示： P-CSCF ATS IM-SSF SIPl 4 M RFC UGC 19 图1S IP协议在IM S网络中应用示意图 2.2 S IP网络架构 S IP使用CS(Client/server客户端/服务器)架构如图2所 示，交互形式为请求、响应的方式。User Agent C lie n t即客户 端，发起S IP请求;User Agent Server即服务器端，进行S IP请 求处理，并进行响应，Request Proxy Server起到消息路由转发的功能。 3.2认证测试标准 系统B模型采用的简表是07B0,根据K N X协议必须满 足如表1所列的功能需求。认证测试将会针对这些基本功能 来设计测试例进行测试。 按照测试规范[6]要求，先通过E TS配置软件配置好K N X 设备后，采用E IT T软件编写好测试例，运行测试序列，所有测 试例均通过，说明该协议栈符合K N X协议规范要求。在软件 开发过程中，可以通过该方式进行各个功能点的验证，从而保 证软件的可靠性，缩短最终的认证周期。 表1系统B的基本功能表 协议栈主要功能 数据链路层数据帧的封装和解析、应答、数据过滤 网络层正确设置路由计数器 传输层支持四种传输模式；支持style3的状态机 配置和管理直接内存访问；用户内存的直接内存访问；验证模式；接口对象处理；下载状态机；运行状态机；重启；授权；设备描述业务；编程模式；K N X序列号；地址表?，关 联表；组对象表；应用相关参数 4结语 本文介绍的系统B模型的K N X设备是基于LPC处理器、L in u x系统来设计和实现的，并采用了 NCN5120芯片作为 K N X总线收发模块。该设备通过了第三方认证测试实验室的 认证测试，符合K N X协议规范。系统B模型K N X具有更丰 富的资源，可应用于复杂的智能家居和楼宇控制系统中，具有 广阔的市场价值和应用前景。 参考文献： [1]夏长凤.基于K N X总线智能家居控制系统的设计[J].电 器自动化，2016, 38⑴. [2]任志勇.基于K N X智能家居的应用[J].重庆电子工程职 业学院学报,2010, 19(4). [3]Jason Richards,Development o f Complex K N X Devices. W EINZIERL ENGINNERING GmbH,2010. [4]Konnex Association.Konnex Standard,Vol3,System Specifications,2013. [5]Konnex Association.Konnex Standard,Vol6,Profiles,2013. [6]Konnex Association.Konnex Standard,Vol8,System Test Specifications,2013. 作者简介:朱莉(1979-)，女，四川省资中县人，电子工程师，硕 士学位，主要研宄方向为智能家居、大数据、LTE。 105
协议分析 协议扩展分析 STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ????STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?
SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK 与传统 Telephony 业务互通的场景 ?Encapsulation –'Transparent' Transit of ISUP Messages –SIP 与ISUP 协议不可能一一映射 –如果为了保证SP1－SP2之间业务的无缝互通，只有SP1发出的ISUP 消息能够透传到SP2–将ISUP 消息封装在SIP 消息体里–Content-Type: application/ISUP
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?可STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK SIP GW INVITE SIP Proxy PSTN PSTN IAM SIP GW Transaction STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???准?STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK SIP GW INVITE SIP Proxy PSTN PSTN IAM SIP GW STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?规则CANCEL ???
sip协议解析与实现(c和c++使用osip)11 第八章查询能力 SIP的OPTIONS方法允许一个UA查询另外一个UA或者一个代理服务器的能力。这能让客户端探测关于它们所支持的方法、内容类型、扩展和编码等信息，而不用"呼叫(ringing)"另外一端。例如，在客户端插入了一个Require头域到INVITE 中，并列出了不确定目标UAS是否支持的能力之前，它可以先使用OPTIONS方法查询目标UAS是否要查询的选项被目标UAS在应答的Supported头域中返回。所有UA必须支持OPTIONS方法。 OPTIONS方法的目标使用Request-URI来标识，因为它可以表示不同的UA或者SIP服务器。如果OPTIONS被定位到一个代理服务器，Request-URI不由客户端设置，这类似于REGISTER请求设置Request-URI的方法。 如果服务器接收到一个Max-Forwards头域的值为0的的OPTIONS请求，它要对这个请求进行应答而不用管Request-URI. 这个行为与HTTP/1.1一致。这个行为可以被用于"追踪路由线路(traceroute)"功能，从而使用发送一系列递增的 Max-Forwards值的OPTIONS请求的方法检查消息路由过程中个别服务器的能力。
作为一般UA的行为，如果OPTIONS长时间没有应答，事务层能够返回一个超时错误。这将指出，目标是不可到达的并且查询的能力是不可以使用的。 OPTIONS请求可能由建立一个对话的一端发送，用于查询对端在后面的对话中可能会被使用到的能力。 第一节构造OPTIONS请求 OPTIONS请求使用像RFC3261第8.1.1讨论的标准的构造SIP请求的规则来构造。 OPTIONS可能会有一个Contact头域。 应该包含一个Accept头域用来指出UAC希望接收到的应答中的消息体类型。典型的，这可能被设置成用来描述UA的媒体能力的类型，比如，SDP(application/adp)。OPTIONS请求的应答被认为是有限定范围的，它被限定在原始请求的Request-URI内。只有当OPTIONS被作为建立对话的一部分发送，它保证会话中后继的请求也由应答OPTIONS的服务器所接收时，对OPTIONS请求的应答才是可用的。 OPTIONS请求的例子： OPTIONS sip:carol@https://www.doczj.com/doc/fa7398692.html, SIP/2.0 Via: SIP/2.0/UDP https://www.doczj.com/doc/fa7398692.html,;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70
14 SIP协议关于本章
本章将对SIP协议做一简要介绍，包括涉及的基本概念、消息结构以及简要的消息流程。 14.1 概述 SIP（Session Initiation Protocol）是一个应用层控制协议，用于创建、更改和终止会话。这里的会话类型包括多媒体会议、Internet电话等类似的应用。SIP是实现VOIP（Voice over IP）的关键协议之一。 SIP支持别名映射、重定向服务、ISDN和智能网业务。它支持个人移动（personal mobility），即终端用户能够在任何地方、任何时间请求和获得已订购的任何电信业务。总的来说，SIP能够支持下列五种多媒体通信的信令功能。 l用户定位：确定参加通信的终端用户的位置； l用户通信能力协商：确定通信的媒体类型和参数； l用户意愿交互：确定被叫是否乐意参加某个通信； l建立呼叫：包括向被叫“振铃”，确定主叫和被叫的呼叫参数； l呼叫处理和控制：包括呼叫重定向、呼叫转移、终止呼叫等等。 SIP可以通过MCU（Multipoint Control Unit）、单播联网方式、或组播方式创建多方会话，支持PSTN和IP电话之间的网关功能。 SIP协议对低层协议作了最少的假设，低层协议可以为SIP协议提供可靠或非可靠传输，可以为分组或字节流业务。SIP可以使用UDP协议或TCP协议作为传输层协议，首选UDP协议。 14.1.1 相关概念 呼叫 一个呼叫是由一个会议中被同一个发起者邀请加入的所有成员组成的。一个SIP 呼叫由Call-ID进行标识。 因此，如果一个用户是被不同的人邀请参加同一个多点会议，那么每个邀请都构成一个呼叫。点到点IP电话会话是一种最简单的会话，它映射为单一的SIP呼叫。 呼叫分支 一个呼叫分支（Call leg）由Call-ID、To、From三个参数共同决定。在同一个Call-ID中，从A到B的请求与从B到A的请求都属于同一个呼叫分支，呼叫分支也可以理解成一次呼叫中消息经过的路径。 事务 事务是发生在客户端和服务器之间的，包括从客户端发给服务器的第一个请求消息直到服务器端发给客户端的最终响应消息，这期间的所有的消息。 事务是由一个呼叫分支中的CSeq顺序号来标识的。但也有例外，比如一个ACK 请求与对应的INVITE请求具有相同的CSeq，但它们却构成了各自的事务。 一个正常的呼叫一般包含三个事务。其中，呼叫启动包含两个操作请求：邀请（INVITE）和证实（ACK），前者需要回送响应，后者只是证实已收到最终响应，不需要回送响应。呼叫终结包含一个操作请求：再见（BYE）。 定位服务 SIP重定位服务器或代理服务器用来获得被叫位置的一种服务，可由定位服务器提供，但SIP协议不规定SIP服务器如何请求定位服务。 代理服务器 代理服务器（Proxy Server）是用于将SIP请求路由到目的地的中间路径。它既是客户端也是服务器。用户请求可以直接被代理服务器处理或被转发给别的代理服务器。代理服务器在转发之前要对消息进行解析，必要时还会改写请求。 重定向服务器
SIP协议测试总结 一：响应码定义 1、响应（Response） 1）1XX：临时响应，表示请求消息正在被处理。 2）2XX：成功响应，表示请求已被成功接收，完全理解并被接受。 3）3XX：重定向响应，表示需采取进一步以完成该请求。 4）4XX：客户机错误，表示请求消息中包含语法错误信息或服务器无法完成客户机请求。 5）5XX：服务器错误，表示服务器无法完成合法请求。 6）6XX：全局故障，表示任何服务器无法完成该请求。 100：临时响应，正在尝试 180：振铃，UA收到INVITE请求之后用该响应通知用户，该响应也可以再发起一个本地回铃 181：呼叫正在转发 182：排队 183：会话进行 200：OK 300网络协议不兼容:会话描述中的一个或多个网络协议不可用。 301网络地址格式不兼容:会话描述中的一个或多个地址格式不可用。 302传送协议不兼容:会话描述中的一个或多个传送协议不可用。 303带宽单位不兼容:会话描述中的一个或多个带宽度量单位不被理解。 304媒体类型不可用:对话描述中的一个或多个媒体类型不可用。 305媒体格式不兼容:对话描述中的一个或多个媒体格式不可用。 306媒体特征不被理解:对话描述中的一个或多个媒体特征不被支持。
307对话描述参数不被理解:除上述几种参数之外的参数不被理解。 330组播不可用:用户站点不支持组播。 331单播不可用:用户站点不支持单播通信(通常是由于防火墙的存在)。 370带宽不足:对话描述中定义的或者媒体定义的带宽超出可用带宽。 399混合告警:该告警表示用户存在的任意一种错误，收到该告警的系统不可以采取任何自动的动作 401：未授权 403：禁止 404：未找到 405：不允许的请求方法 406：不接受 407：代理服务器需要鉴权 408：请求超时 413：请求消息过大 415：不支持的媒体类型 414：Request-URI过长 415：不支持媒体类型 416：不支持的URI方案 420：错误的扩展 421：需要扩展支持 423：间隔太短 480：临时不可用 481：呼叫/事务不存在 482：检测到路由循环
《软交换系统实验》实验报告四 实验室名称：现代通信网络实验室实验日期： 2011 年 6月 5日 学院（系）专业、班级姓名成绩 实验项目SIP协议的认识及呼叫追踪分析实验指导教师 教师评语 教师签名： 年月日 一、实验过程原始记录(数据、图表等) 1．设备配置实验记录 设备名称设备IP地址短号设置长号设置 EIA2016设备192.168.0.3 101 EIT200 SIP电话192.168.1.101 802 2．呼叫跟踪实验记录 3．1）主叫信息 群号： 1 短号： 101 长号：用户标识码: （2）被叫信息 群号：1 短号： 102 长号：用户标识码: （3）呼叫消息原始记录（包括：主叫方和被叫方与EIX交互的信令消息） ①主叫方与EIX交互的呼叫信令消息跟踪结果： [151-12:02:09:970] MSG :--->> to 192.168.0.3/58525 crypt:TRUE Phone Call proto:P2PV2 len:739 INVITE sip:25130016@192.168.0.3 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.3:2080;branch=z9hG4bK7155de6d801d63c038d6335428dfb99e ;rport From:
SIP协议深入介绍 网络事业部软交换开发部王笑蓉1．SIP简介 SIP（Session Initiation Protocol）是应用层控制协议，可以创建，修改，以及终止一个多媒体会话。它具有以下几个主要功能： User location：确定通信中的终端位置 availability：确定被叫方是否愿意进行通信 User capabilities：确定用于通信的媒体类型及参数 User setup：建立会话各方的会话参数 Session management：终止会话，修改会话参数 Session SIP协议需要和其他IETF协议一起来构成一个完整的多媒体通信构架。这些协议有： RTP(Real Time Transport)：传输实时数据，提供QoS反馈信息 Streaming protocol)：控制流媒体的传送 Time RTSP(Real MEGACO(Media Gateway Control Protocol)：控制媒体网关 SDP（Session Description Protocol）：描述多媒体会话 1．1SIP协议结构 SIP协议的行为模型可以用几个分层的相对独立处理阶段来描述： 1．语法及编码层 2．传输层 定义了客户端如何通过网络发送请求及接收响应，以及服务器端如何接收请求并发送响应。所有SIP逻辑实体都包含此层。 3．事务层 事务层处理应用层请求或响应消息的重发，响应与请求的匹配以及应用层的超时。一个SIP事务由一个请求和对该请求的所有响应构成，这些响应分临时响应 （provisional response）和最终响应(final response)。对于INVITE事务，对应于非 2xx响应的ACK确认消息也属于该事物，而对应于2xx响应的ACK确认消息则不 属于该INVITE事物。 UA以及stateful proxy均包含事务层，而stateless proxy 不包含事务层 一个事物根据逻辑功能分为客户事务(client transaction)和服务器事务（server transaction）。客户事务和服务器事务是存在于UA及有状态代理服务器(stateful