SIP 协议讲解SIP 工作架构原理简介RTP/RTCPSIP/SDPUDP/TCP IP图 1 协议结构图 SIP 协议是一种会话建立和控制的信令协议，SIP 协议本身不能实现多媒体的业务，SIP 协议和 SDP 协议，媒体流 RTP/RTCP 协议配合完成完整的多媒体会话业务。SIP Session 建立流程1. INVITE bob@ieee.org 2. INVITE bob@ieee.org 3. bob 4. play.com 6. ACK 7. INVITE bob@play.com 8. INVITE bob@play.comSIP Redirect & Location Servers (Ieee.org) 3 SIP Proxy 2 5 6 7 (sjsu.edu) 11 10 12 9 8 (play.com) 4 SIP Proxy9. Ringing ok 10. Ringing ok 11. ACK 12. ACK5. Bob moved. Temporarily contact bob@play.com1RTP Media SIP Client SIP Client (User Agent Server)图 2 会话建立流程图
SIP协议介绍
SIP 基本概念
Session: : 会话是媒体流数据和他们发送者和接收者的集合的概念由SDP中的SESSION ID定义
Dialog: 对等SIP实体间的SIP信令连接关系，由from tag, to tag,call id唯一标识
User Agent Client (UAC):：创建新的SIP请求的逻辑实体
User Agent Server (UAS)：接收SIP请求并回应响应的逻辑实体
PROXY ：在UAC和UAS之间路由SIP消息的网络实体
SIP消息
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 ;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 <sip:bob@biloxi.com>
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 <sip:alice@atlanta.com>;tag=1928301774
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: <sip:alice@>
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 通过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
ii. 2xx response 携带SDP 消息体发出offer，ACK 携带SDP 消息体answer
__
SIP协议结构
F.2.1.1 编解码
对SIP文本消息进行解析。
F.2.1.2 传输层
SIP使用UDP,TCP,或者SCTP，TLS为承载传输SIP消息，SIP传输层的工作是管理和使用以上承载。
F.2.1.3 事务层
事务是SIP的基本元素。一个事务是由客户机事务发送给服务器事务的请求（使用传输层），以及对应该请求的从服务器事务发送回客户机的所有响应组成。事务层处理应用层重传，匹配响应到请求，以及应用层超时。任何用户代理客户机（UAC）完成的任务使用一组事务产生。用户代理包含一个事务层，有状态的代理也有。无状态的代理不包含事务层。事务层具有客户机组成部分（称为客户机事务）和服务器组成部分（称为服务器事务），每个代表有限的状态机，它被构造来处理特定的请求
设计事物层的目的是在非可靠传输（UDP）上能够保证SIP消息的可靠传输和过滤重发消息。所以在使用如TCP，SCTP等可靠传输协议是，可以不去掉事物层
SIP事物层分为：
? 客户端INVITE事物：
ACK Timer B firesor Transport ErrInform TUNOTE:transitions labeled
with the event over
the action to take
当TU 发出INVITE 时，TU 必须启动一个新的client transaction,则就进入了“calling”状态。Client transaction 必须将request 放到传输层以传输。如果传输层是不可靠传输，则client transaction 必须启动timer A，值为T1；如果传输层是可靠传输，则一定不能启动timer A。但是不管怎样，都必须启动timer B，值为64×T1。如果timer A 到时间了，就必须重发request,而且timer A 的值设为2×T1，当timer A又到时间了，就必须再次重发request,然后值设为前一次的两倍。这个过程不断重复，只要状态还处于“calling”状态中。如果timer B 到时间了，但是状态还处于“calling”状态中，client transaction 必须通知TU 时间已经到了，client transaction 绝对不能产生ACK 这个request。如果在“calling”状态中收到了一个
provisional response，则状态从“calling”转到了“proceeding”。在这个状态中，则不能再重发request。而且，provisional response 必须给TU，而且在“proceeding”状态中，任何其他的provisional response 也必须传给TU。无论是在“calling”状态还是在“proceeding”状态，只要收到300－699 的response，都会使状态进入“completed”。Client transaction 将收到的响应传给TU。Client transaction必须产生ACK，即使传输层是可靠的。ACK 必须给送到传输层传输request 的相同地址，相同端口。这时client transaction 一进入“completed”状态就要启动timer D.对于不可靠传输层，值至少是32 秒；对于可靠传输层，值是0。在“completed”状态中，每收到一个final response，都会导致ACK 的重传。但是新收到response 不能被传给TU.如果timer D 到时间了，则状态进入“terminated”状态。无论是在“calling”状态还是在“proceeding”状态，只要收到2XX 响应，就会进入到“terminated”状态。响应必须传给TU。对于这个响应的处理依赖于TU 是proxy core,还是UAC core.后者会为这个响应产生ACK,而前者只会将这个响应前传。当进入到“terminated”状态时，这个client transaction 就会被毁掉。这也是上述处理的原因。
? 客户端非INVITE事物
当request 到达时，TU 必须启动一个新的client transaction,则就进入了“trying”状态。从client transaction 设置timer F，值是64×T1。如果传输层是不可靠的，设置timerE，值是T1。如果timer E 到时间了，但是还依旧处于“trying”状态中，则重新设置timerE，值是MIN(2*T1,T2),这样反复进行。如果在“trying”状态中,timer F 时间到了，则client transaction 通知TU，而且进入到状态“terminated”中。如果在“trying”状态中，收到了provisional response，这个response 必须传给TU,clienttransaction 进入到状态“proceeding”。如果在“trying”状态中，收到了final response（200－699）, 这个response 必须传给TU,client transaction 进入到状态“completed”。注意，在“proceeding”状态，request 必须依旧重发，而且timer E 被设置成T2。如果timer F 时间到了，则client transaction 通知TU，而且进入到状态“terminated”中。如果收到final response（200－699），则状态进入到“completed”。在“completed”状态，对于不可靠传输层，设置timer K,值为T4；对于可靠传输层，值为0。这个状态只是为附加的reponse 的重传而设置缓冲。如果timer K 时间到了，则就进入到状态“terminated”。
? 服务器端用户INVITE事物
in 200msfrom TUTransport Err.
Inform TU
当request 到达时，TU 必须启动一个新的server transaction,则就进入了“proceeding”状态。除非server transaction 知道TU 会在200ms 内产生provisional response 或者final response，否则server transaction 产生100 response.这个response 主要是为了阻止request 的重发，以避免网络阻塞。只要server transaction 在“proceeding”状态，则TU 会传送任意多的response到server transaction.当收到重传的request,则server transaction 就将它所收到的最近的provisional response 放到传输层去重发。如果处于“proceeding”状态，TU 将2XXresponse 传给server transaction，注意这里2XX的重传并不是有server transaction 来控制，它必须由TU 控制。这是server transaction 进入到状态“terminated”。在“proceeding”状态，TU 产生300－699response，则状态进入“completed”。对于不可靠传输层，必须设置timer G，值为T1,如果是可靠传输层，就不必设置。当进入“completed”状态，同时也要设置timer H, 值为64*T1。Timer G 到时间，则response要重传，同时设置新值。如果收到一个request 的重传，则也必须重传response.在“completed”状态中时，如果收到ACK，则状态就进入到“comfirmed”。在这里，timer G 被忽视，所有response 的重传都被中止。如果timer H 的时间到了，还一直没有收到ACK，则状态进入到“terminated”，必须通知TU transaction failure。当进入“comfirm”状态，同时也要设置timer I,值为T4。如果时间到了，就进入到状态“terminated”。
? 服务器端非INVITE
200-699 form TUsend response
一旦收到非INVITE,ACK request,状态首先进入到“trying”，如果TU 传送一个provisional response,则server transaction 进入到“proceeding”状态。任何从TU 接收到的provisional response 都必须送到传输层去传输。如果收到重传的request,则最近的response 进行重传。如果TU 产生final response（200－699），则状态进入到“completed”。而且response 要送到传输层重传。当server transaction 进入到“completed”状态，必须设置timer J，对于可靠传输层，值为64×T1，对于不可靠传输层，值为0。只要收到一个request 的重传，都必须重传finalresponse.其它response 都忽视。当timer J 到时间了，则进入到“terminated”状态。
F.2.1.4 事务用户层
事物用户是事物层上的SIP业务处理层，事物用户层负责处理SIP中的具体消息内容，执行相关的业务逻辑。
每个SIP实体，除了无状态代理，都是事务用户。当一个TU希望发送请求，它生成一个客户机事务实例并且向它传递请求和IP地址，端口，和用来发送请求的传输机制。一个TU生成客户机事务也能够删除它。当客户机取消一个事务时，它请求服务器停止进一步的处理，将状态恢复到事务初始化之前，并且生成特定的错误响应到该事务。这由CANCEL请求完成，它构成自己的事务，但涉及要取消的事务。
事物用户包括注册机，会话控制等。
SIP网络结构
一般SIP网络结构
在一般的SIP网络结构中包含了以下网络实体
? SIP终端: 使用SIP网络服务的SIP用户
? 注册机（Registrar）：负责SIP用户的注册，SIP只有注册后才能使用SIP网络提供的服务
? 定位服务器(Location)：提供用户的位置信息，指引会话路由到被叫用户，用户的位置信息从用户的注册机获得，往往和注册机是同一个实体
? 重定向服务器: 提供呼叫重定向服务
? SIP代理服务器: 在网络中路有SIP消息的网络实体
? SIP 网关：SIP网络和其他网络的互通节点设备（如何PSTN，CS， H323等的互通）
IMS网络结构
IMS网络是基于SIP的移动下一代多媒体会话网络,IMS网络的最终目的是实现3G全IP演进。和一般的SIP网络比较来看，IMS网络提供了非常好的业务和控制分离的理念和网络结构，会话的控制由CSCF实现，用户的业务特性，位置等信息存储在HSS中，用户的业务逻辑由AS实现。各会话网元间接口使用SIP协议实现 为了提供多种不同的接入，ETSI TISPAN正在进行研究改进IMS网络，IMS网络将是未来全IP，多接入的电信下一代网络解决方案。
SIP路由
传统电信网络的路由：信令点码，GT，号码分析。 SIP网络的路由： DNS，路由器 F.2.1.5 SIP路由信息及方法
? 请求消息的路由
request-uri：request-uri是判断消息是否到达目的地的主要信息，例如在注册请求消息中request-uri是负责用户注册的注册机或域名
route： route 字段是消息必须要经过的中间网元URL。 ? 响应的路由
via: 指示响应消息回应的地址，UAC必须添加via，中间的PROXY网元如果希望回应消息经过本网元，可以添加via.
? 后续消息的路由
在会话（INVITE）流程中，中间网元如果希望后续的请求消息也经过本网元，可以在请求消息中添加本网元的record-route， record-route在回应消息中带回UAC, UAC的后续请求消息中将record-route信息放在route中，控制请求的路由。
SIP业务流程
注册
SIP注册流程
用户打开SIP终端时(如PC,IP PHONE),将向代理服务器/登记服务器发起注册过程, 注册过程需要周期刷新,注册服务器将把SIP终端所注册的信息传送到位置服务器存放。
用户向SIP Registrar发起一个注册请求REGISTER，其中包含用户的连接地址（contact）。SIP Registrar回应401（Unauthorized）要求用户向其鉴定身份。用户根据响应消息的指示将相应的信任证书包含的REGISTER请求中重新注册，SIP Registrar在通过鉴权认证后，回应200（OK）消息，其中包含用户当前注册的连接地址。
表1
假定图3中User Agent 和Registrar实体的信息如表1所示。各消息内容如下：
（1） REGISTER：User Agent → Registrar
REGISTER sip: SIP/2.0
Via: SIP/2.0/TLS :5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: LittleGuy <sip:UserB@biloxi.com>;tag=a73kszlfl
To: LittleGuy <sip:UserB@biloxi.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.com
CSeq: 1 REGISTER
Contact: <sip:UserB@>
Content-Length: 0
（2） 401 Unauthorized：Registrar → User Agent
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS :5061;branch=z9hG4bKnashds7 ;received=192.0.2.201
From: LittleGuy <sip:UserB@biloxi.com>;tag=a73kszlfl To: LittleGuy <sip:UserB@biloxi.com>;tag=1410948204 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.com
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="atlanta.com", qop="auth", nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
opaque="", stale=FALSE, algorithm=MD5
Content-Length: 0
（3） REGISTER：User Agent → Registrar
REGISTER sip: SIP/2.0
Via: SIP/2.0/TLS :5061;branch=z9hG4bKnashds7 Max-Forwards: 70
From: LittleGuy <sip:UserB@biloxi.com>;tag=ja743ks76zlflH To: LittleGuy <sip:UserB@biloxi.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.com
CSeq: 2 REGISTER
Contact: <sip:UserB@>
Authorization: Digest username="UserB", realm="atlanta.com" nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", uri="sip:",
response="dfe56131d1958046689d83306477ecc"
Content-Length: 0
（4） 200 OK：Registrar → User Agent
SIP/2.0 200 OK
Via: SIP/2.0/TLS :5061;branch=z9hG4bKnashds7
;received=192.0.2.201
From: LittleGuy <sip:UserB@biloxi.com>;tag=ja743ks76zlflH
To: LittleGuy <sip:UserB@biloxi.com>;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.com
CSeq: 2 REGISTER
Contact: <sip:UserB@>;expires=3600
Content-Length: 0
会话发起，媒体协商
1. （1）：主叫用户发INVITE请求到代理服务器；
2. （2）：代理服务器收到INVITE请求，发现没有包含鉴权证书，向主叫响应407
（Proxy Authentication Required），要求客户机向代理鉴定自身身份。
3. （3）、（4）：客户机收到407（Proxy Authentication Required）响应，以ACK请求
证实，并重新发送INVITE请求，其中包含鉴权证书。
4. （5）、（6）：代理服务器将INVITE请求发给被叫代理服务器，其中可能要执行DNS
查询；并向主叫用户返回100（Trying）响应，指示已收到INVITE请求并在处理；
5. （7）、（8）：被叫代理服务器收到INVITE请求，响应100（Trying）消息；查询定
位服务器得到被叫IP地址，然后向被叫发INVITE请求；
6. （9）、（10）、（11）：被叫终端收到INVITE请求，提示用户并振铃，180（Ringing）
响应通过代理服务器传给主叫，主叫用户可能听到回铃音或显示一信息；
7. （12）、（13）、（14）：被叫应答时200（OK）响应通过代理服务器传给主叫代理服
务器；
8. （15）、（16）、（17）：主叫终端收到200（OK）响应，回应ACK请求予以证实。
该响应通过代理服务器传给被叫。
9. （18）、（19）、（20）：被叫想终止会话，通过自己的用户代理向对方发送BYE请求；
（21）、（22）、（23）：主叫回应200（OK）响应。
其他话题
互通（PSTN, 3G CS, H323）
SIP扩展（3GPP扩展， TAG扩展， ETC）
SIP参数信息 /assignments/sip-parameters