2.6.2.1背景
SIP是目前通信界最为活跃的通信协议之一。
IETF每年都在Internet上召开一次会议，由于其成员遍及全世界，因此他们基于Internet原有物理线路和硬件开发了一种"虚拟网络”，以连接与会人员。这个虚拟网络被称作“多目主干”(MulticastBackbone),或Mbone。Mbone依靠多目方式传送信息(“多目”是指把实时数据流同时提交到多个计算机主机的方法)。
在SIP(SessionInitiationProtocal)没有提出之前，IP领域主要采用SAP和SDP进行会议业务。SDP侧重于对多媒体会话属性的描述；SAP则是用于处理组播和单播会话分组协议。当召开会议时，SAP模块会在一个组播地址和端口上周期地宣布当前会议，使用SAP时，参加会议的一方需要周期性地检查组播地址和端口，发现是否有想要参加的会议。因此，通过SAP不能主动通知以及邀请用户参加会议。这一瓶颈阻止了SAP的大规模使用。
由于SAP在会议业务上的局限性,因此IETF想提出一种新的方式能够邀请用户参加Mbonesession。
1999年，IETF提出RFC2543,定义了SIP的基本框架要求，随着实际应用范围的扩大,人们在实践过程中对RFC2543进行不断地修改或扩充，最终形成RFC3261。
2.6.2.2通用介绍
SIP是一个基于文本的应用层控制协议，用于建立、修改和终止双方或多方多媒体会话,在实现土独立于底层传输协议，因此底层可采用TCP/UDP/SCTP中的任何一种。
通过与RTP/RTCP、SDP、RTSP等协议及DNS配合，SIP在能力上可支持语音、视频、数据、状态呈现、即时通信、游戏等业务。
除此之外，SIP消息体部分可允许同时存在多种不同会话描述协议，此种方式称为MIME(Multipurpose Internet MAIl Extensions)。
对每个SIP消息而言，可分成两部分：SIP头消息、SIP消息体(可选)。简单来看，消息头是描述了一些功能特性，例如，选路字节或表征呼叫标识的字节；消息体则主要描述一些会话属性，例如，本次呼叫是一个语音还是视频呼叫、呼叫采用的编解码方式、连接地址(IP+端口号)等信息。消息头是SIP新定义的参数，而消息体则可引用目前网络中任何成熟的协议，例如SDP或ISUP等。
我们在谈SIP时，一般称其为SIP簇，主要在于SIP是一个系列协议，总的来讲可分为基本框架协议和扩展协议。
1）基本框架协议就是RFC3261,最初提出的RFC2543目前已被删除。框架协议是SIP协议的灵魂，它规定了SIP的基本行为原则，但不涉及SIP在各种环境下如何各种应用。
2）展协议，除RFC3261外，其他针对SIP提出的协议都可以称为SIP的扩展协议，它是为了明确SIP在各种环境下如何应用而提出的。所有扩展协议在提出时,都必须以RFC3261为基础，不得违背RFC3261的基本精神。
2.6.2.3 网络模型实体介绍
SIP网络中共分为以下几个功能实体：
1.用户代理UA（UserAgent）
UserAgent（简称UA）是“用户代理”的意思，对接收到的行为进行代理，然后发送到SIP网络中。
根据Clien—Server的行为准则，UA可分为UserAgentClient（简称UAC）、UserAgentServer（简称UAS）。 UAC是发起请求的实体，UAS则是对发起请求晰响应的实体。
在应用上，UA可包括：SIP终端、窄带软交换呼叫中心等、基于SIP的IAD设备等。
2.BacktoBackUserAgent（B2BUA）
B2BUA（BacktoBackUserAgent）是一种背靠背UserAgent,是UA的一种扩展应用。原理实现上，首先终止一个呼叫，然后重新发起一个呼叫，因此对于B2BUA而言，需要具备将两个呼叫绑定在一起的功能，维护整个会话状态。
3.代理服务器Proxy
代理服务器是RFC3261描述的核心网络设备，主要完成消息转发。Proxy处理消息的主要特点是“转发”，只要消息格式符合RFC3261的语法规则，Proxy不会判别该消息是否认识,都会根据选路规则，将该消息发送到目的地或发送到网络中下一跳地址。
同时，Proxy也不会对接收到消息的消息体进行修改（例如增加、删除等）。这点与UA的行为存在很大区别：UA接收到消息时，会判别该消息自己是否能够解释（SIP在不断地发展，不断地有新消息出现），如果不能够解释，可能会拒绝该消息。这也是为什么RFC3261一直将Proxy作为网络路由实体的原因。（RFC3261认为通过Proxy构建的网络架构，将来只须对终端进行升级，而网络设备则不需要做任何改动）。
4.注册服务器Registrar
在2.5.6.4节我们讲过SIP终端需要通过注册行为告知网络自己所处的位置。SIP网络将接受注册行为的网络设备称为注册服务器。
5.重定向服务器RedirectServer
接收到请求消息后，通过3**响应消息对请求消息进行响应，实现该种行为的服务器在SIP中称为重定向服务器。RedimctServer只是对请求消息进行响应，不产生请求消息，因此也是一种特殊UAS。
在理解上，可参照DNS的实现机制。
作为网络层面的应用，RedirectServer可作为网络层面的路由载荷分担或路由查询。
另外，终端也可通过重定向功能告知网络希望启动呼叫转移的业务，网络根据用户的业务属性决定是否进行后续寻址。
以上五种分类指的都是逻辑功能实体，实际产品中同一个物理设备可能集成了多个逻辑功能，只不过在不同的应用环境下启动不同逻辑功能。
2.6.2.4消息类型介绍
SIP网络所有实体都采用Client/Server的操作模式，因此SIP消息可分为请求、响应两大类。
另外，区别于二机制信令，SIP消息采用文本方式。
RFC3261中主要规定了六个请求消息。响应消息则分为六大类，每个响应消息为三位数字，第一位表示类别，与后两位配合表示不同的响应消息。
对一个呼叫，实际最终结果只有两种：呼叫成功建立、呼叫不成功。对应到实际操作中,如果被叫用户摘机，则呼叫成功建立；如果出现被叫用户忙、被叫久叫不应、主叫用户在被叫用户摘机前挂机等情况，此时呼叫失败（或不成功）。实际上，呼叫过程中还存在一些中间状态，例如被叫用户处于振铃状态，当收到该类消息时，我们并不能够判断此时呼叫是成功还是失败，该类消息只是表征“呼叫进展"状态。
表2-3 SlP 请求消息
表2-4 sip相应消息
总结一下，在SIP中，将能够判别呼叫状态的消息称为最终响应消息，否则为临时响应消息。（实际上按照RFC3261的定义，我们在此的描述并不严谨）。
1.各个消息头的作用解释
Request-URI：呼叫请求发送的地址。UA生成初始请求消息时，该域中的信息一般与To中的地址相同。经过网络服务器后，由于实际路由问题，该值可能发生变化。另外一个比较特殊的是REGISTER消息，在REGISTER消息中，Request-uri中将会填充注册服务器的地址（表示消息发往注册服务器），而此时To域中的地址将会填充客户端实际的地址。
From：发起请求方的地址。一般采用userinfo@hostport形式。该域同时带有一个tag参数，是随机产生的整数。
To：接受方地址。同From域相同，也采用userinfo@hostport的地址形式。当该域存在于最终响应消息中时，将会带有tag参数。
Call-id：用于识别呼叫的参数，在同一个Dialog中，该参数不发生变化。该参数与From中的tag参数、To域中的tag参数相结合用以保证呼叫的惟一性。
Cseq：表征Transaction的参数，由于同一个呼叫中会存在多个Transaction,因此通过该参数来保证同一个 UserAgent发送的不同请求消息间的顺序。
Contact：告知对端自己的地址。当对端发送下一个请求消息时，可直接向该地址发送。不需要关心前一个请求的路由信息（除非有特定原则，例如，hoxy可以通过record-route域来保证下一个请求消息必须经过本Proxy,即使Contact域中填写了对端客户端的地址）。
Via：该参数表征呼叫经过的路径。UA生成SIP消息时，会在该域中填写自己的地址；Proxy在转发请求消息时，将会增加一个填有自己地址的Via域，表示呼叫经过本Proxy。Via域的存在可以保证响应消息按照原有路径返回到主叫方。
Record-route：由于contact域的存在，使得两个用户后续的请求消息可能不经过Proxy,为了运营需要，Proxy在初始INVITE消息中增加了record-route域，这样可以保证后续请求（例如BYE消息）经过Proxy。通过Record-route与contact域的结合，既可避免后续请求旁路网络服务器的行为，又可减少后续请求路径上的环节。
Content-type：表征消息体格式的参数，例如，呼叫采用SDP进行会话描述，还是采用其他类型的会话描述协议。
2.消息示例
（1）INVITE消息
INVITEsip:bob@shanghai.comSIP/2.0
Via:SIP/2.0/UDP218.19.98.1:5060
〃主叫侧用户代理地址//（该部分为注释部分）
To:sip:bob@shanghai.com
〃被叫用户账号地址//
From:siprtom@guangzhou.com:tag=2089095865
〃主叫用户账号地址，tag由主叫侧用户代理生成〃
Call-ID:1039412186@218.19.98.1
〃呼叫标识//
CSeq:1 INVITE
//前一部分是一个整数，表示发送消息的序列；后一部分表示消息模式〃
Accept:application/sdp
//主叫方能够接收和处理的消息体格式为SDP方式//
Content-Type:application/sdp
〃本次会话采用SDP方式〃
Content-Length:271
〃消息体长度〃
Contact:<sip:tom@218.19.98.1:5060;transport=udp>
〃主叫方的地址〃
(以下内容为SDP信息)
v=0
o=tom1390815520974596213908155209745962INIP4218.19.98.1
s=n
p=+l 972 6841000
c=IN IP4 218.19.98.1
t= 0 0
m=audio50000RTP/AVP8
a=rtpmap:8PCMA/8000
a=ptime:10
(2)200消息
SIP/2.0 200 OK
Via:SIP/2.0/UDP61.130.1.43:5060;branch=z9hG4bK1241306276-908668528.0
Via:SIP/2.0/UDP61.130.1.166
//Via域表示呼叫经过的路径〃
To:<sip:02085009200@61.130.1.43>;tag=12739
〃拷贝INVITE消息中To域中的内容，但tag参数由被叫侧用户代理生成//
From:<sip:+86573000166@61.130.1.43>;tag=lc942
〃拷贝INVITE消息中From域中的内容〃
Call-ID:call-973631432-6@61.130.1.166
CSeq:1 INVITE
Contact:<sip:85009200@218.18.98.40>
//被叫侧用户代理地址//
Record-Route:<sip:61.130.1.43;lr>
//Record-route域表示下一个请求必须经过该地址//
Content-Type:application/sdp
Content-Length:197
〃消息体部分〃
2.6.2.5相关协议介绍
1.RFC2327
文档主要对SDP进行了描述。并不属于SIP的范围之内，但SIP直接引用SDP将其作为消息体的一种描述方式。
2.RFC2976
文档扩展了一个新的请求消息：INFO消息。目前主要有两个应用：
1） 当局间采用SIP-I时，用于把PSTN中的中间信令（例如INR）传送到对端软交换呼叫中心。
2） 传送DTMF信息。
3.RFC3311
文档扩展了一个新的请求消息：UPDATE消息。主要解决被叫实际应答地址与语音播放资源（例如彩铃语音资源）地址不同的情况。
4.RFC3372和RFC3398
IETF提出的文档，解决SIP域与PSTN域互通的问题。实际上我们所提到的SIP-T,指的就是这两个文档的内容。
5.TRQ2875和Q.1912
itu提出的文档，也是为了解决sip域与pstn域互通的问题。这两个文档的内容也就是我们在后续内容中提到的SIP-I.
2.6.2.6 SIP-T和SIP-I
1.什么是SIP-T和SIP-I
1）SIP-I或SIP-T是SIP的一种扩展应用，它属于SIP的扩展协议，不是一个新协议。两者的出发点都是为了解决SIP网络如何与PSTN互通的问题,只不过SIP-T是由IETF提出的,SIP-I由ITU提出。
2）提出的背景：1999年IETF提出SIP的时候，初衷是为了解决基于IP网络上的应用，随着SIP应用范围的不断扩大，人们开始考虑基于SIP的网络如何与现有PSTN融合或互通的问题。在应用中需要考虑以下话务模型：
√ 话务模型一：呼叫始发于PSTN,终止于SIP网络；
√ 话务模型二：呼叫始发于SIP网络，终止于PSTN；
√ 话务模型三：呼叫始发于PSTN,终止于PSTN,但中间通过SIP网络进行传送。
3）SIP-T：SEP-T是SIPforTelephone的简写，IETF提出了RFC3372和RFC3398,用以规范SIP网络如何与PSTN互通。其中RFC3372是一个基本框架文档，它定义了SIP实体在各种话务模型下局间信令如何进行选择；RFC3398则具体描述SIP消息如何与ISUP消息进行映射或封装。
在这三种话务模型中，话务模型三比较特殊，原有PSTN的通信被分成了两段，中间加入了SIP网络，此时SIP网络相当于“桥”的作用；为了保证主叫或被叫业务属性的透明传输，此时SIP消息的消息体中将包括ISUP信息,为了区别于其他话务模型下的普通SIP信令，此时称为SIP-T,实际上是一种特指（IETF提出SIP-T的本意是为了解决SIP网络如何与PSTN互通的问题，SIP中封装了ISUP信息只是SIP-T解决方案中的一种特例）。
4）sip-i；当sip成为一种趋势时，itu也开始制定相关标准，研究pstn如何与sip网络进行互通。只不过rru的相关文档是基于ietf的成果基础上得出的。ituu提出TRQ2815 和Q.1912（相对于IETF,TRQ2815类似于RFC 3372,Q.1912类似于RFC3398）规范相关行为。在Q,1912中，将封装了ISUP消息的SIP消息称为Sip-i。
因此，关于SIP在电话领域如何应用的问题，ITU和IETF都提出了相应规范，这两个规范并不是对立的，ITU的规范是在参考了IETF标准的基础上得出的。
2.SUM和SIP-T的本质
软交换呼叫中心网络是一个融合的网络，为了保证业务的延续性，运营商首先考虑的会是：在软交换呼叫中心网络体系中，原有PSTN终端的业务应当不丢失。这个出发点也是IETF、FTU制定SIP-T或SIP-I的初衷所在。
那么为了达到这个目的，实现上会有两种方式：
1）方式一：扩展SIP头消息。
2）方式二:考虑在消息体内容上作文章。由于SIP本身支持MIME方式，因此可以将PSTN中的ISUP消息直接封装在SIP消息中，然后发送到对端。
方式二不需要对SIP本身作出额外扩展，显然是实现业务最为快捷的方式。
反观方式一，需要分析所有PSTN补充业务对SIP的要求，如果考虑到所有PSTN补充业务的实现，SIP可能需要做出很多扩展。
因此在最初实现的选择上,采用了SIP消息中封装ISUP的技术方案来实现PSTN补充业务。
实际上，应用中可以将SHM作为携带业务参数的一种选择，因此未必只有在PSTN用户存在的情况下才选择SIP-I。为了业务需要，任何用户参与的呼叫，局间信令都可采用SDM。
3.SIP、SIP-I或SIP-T全要应用在软交换呼叫中心网络中的哪些地方
SIP信令（普通的SIP消息，消息体只包含SDP）可以应用于NNI、UNI。例如，软交换呼叫中心与SIP终端之间、软交换呼叫中心与软交换呼叫中心之间、软交换呼叫中心与应用服务器之间等。
SIP-I或SIP-T只能应用于NNI(SIP-T或SIP-I是指SIP中封装了ISUP信息,考虑到ISUP信息的重要性，不允许把ISUP信息传送到用户侧），例如软交换呼叫中心之间。
其中，对于NNL特别是软交换呼叫中心之间的信令，我们一般是说采用SIP或SIP-I（SIP-T）信令，其实采用SIP还是SUM是根据话务模型决定的，软交换呼叫中心可以根据不同的话务模型采用不同的信令。
