相关专题：
摘要 随着网络技术及通信技术的快速发展，传统电信网络与下一代网络之间的互通成为一个很热门的话题。网络互通的主要问题之一是承载协议的相互转换。文章介绍了ISUP网络同SIP网络互通的呼叫流程，详细阐述了ISUP协议同SIP协议的相互映射问题。
1、概述
随着Internet技术的飞速发展，各种各样的数据业务、多媒体业务不断地涌现出来，同时由于移动网络的飞速发展，网络用户也在不断地增加。人们希望能够方便快捷的使用业务，并且对业务的简单化、多样化及通用移动性的要求越来越高，同时希望能够达到固定移动的无缝融合通信。
另外，传统的PSTN技术已经趋于完善，单纯的话音业务一方面无法满足用户的需求，另一方面也不能支撑产业的进一步发展。应运而生的下一代网络，就是希望能够在全网实现无缝通信。那么各种业务、各个用户群之间要想达到无缝通信，在相互通信的时候就需要保持传输协议的一致性。
2、网络互通涉及的问题
IMS是3GPP在Release 5版本标准中提出来的支持IP多媒体业务的子系统，能够同时提供话音业务和各种数据业务，但是IMS毕竟是在移动领域中开发出来的，多数业务也是在移动领域来开发的。无论是对运营商还是用户都不希望被局限在移动网络中，毕竟传统的固定网络用户还是比较多的，两种网络可能会在相当长的时间里共存。既然共存，当然要互通有无，这样问题就出现了。IMS网络基于SIP协议体系，而传统的固定网络则是基于SS7协议体系。如果存在于这两种不同网络中的用户终端要进行会话，就会涉及到网络协议不一致的问题。
协议互通的关键问题在于网络接口的设计。所以，要需考虑出口网关和入口网关的设计。可以考虑在IMS网络和PSTN网络的接口处放上一个转换设备，就像一个翻译器一样，将对应的呼叫消息翻译成适合于在各自的网络上传送的消息格式。网络接口处的出口网关就可以完成这样一种工作。
3、ISUP终端到SIP终端的呼叫流程
虽然呼叫双方所在的网络支撑协议可能不同，但是各种电话终端的呼叫都有一个类似的过程：首先，主叫方发出呼叫消息，若找不到被叫会收到释放消息，若找到被叫，需看被叫是否忙，忙就回一条释放消息，空闲则返回一条应答消息；被叫接听则返回接听消息，开始通话；最后挂机方发出释放消息。
3.1 完整呼叫应答的建立过程（见图1）
（1）当一个PSTN用户希望同一个SIP用户建立会话时，PSTN网络会产生一个IAM消息发送到网关；
（2）网关基于收到的IAM消息，产生一个INVITE消息，并发送到适当的SIP节点；
（3）当SIP节点判断收到的INVITE消息能够证明呼叫拥有充足的地址信息时，会产生一个180或18x临时响应；
（4）网关根据收到的18x临时响应，产生一个ACM消息。如果响应不是180，ACM会携带一个没有任何指示值的“被叫用户状态”消息；
（5）SIP节点可能会更进一步的使用18x临时消息来表示会话的进行；
（6）发出ACM消息后，所有的临时消息将被翻译成ISUP CPG消息；
（7）一旦SIP节点回答了呼叫，就会发出一个200 OK消息；
（8）网关基于收到的200 OK消息，向ISUP节点发出一个ANM消息；
（9）网关向SIP节点发送一个ACK消息来确认已经收到了INVITE消息的最终响应。
3.2 会话的拆除
关于会话的拆除，涉及到谁先挂机的问题。
（1）如果是SIP终端先挂机，此时SIP节点会发送一条BYE消息到MGC，MGC基于收到的BYE消息，会马上向SIP节点返回一条200 OK响应消息。然后MGC需要马上释放网关中占用的资源，并向ISUP节点发送一条REL消息，ISUP节点会返回一条RLC消息来证明资源已释放。
（2）如果是ISUP终端先挂机，ISUP节点要向MGC发送一条REL消息，网关基于收到的REL消息，向ISUP节点返回一条RLC确认消息，同时向SIP节点发送一条BYE消息，SIP节点基于此BYE消息向网关返回一条200 OK消息作为确认。此期间，网关同时还要做资源释放的工作。
4、消息映射
由于ISUP同SIP采用不同的消息封装机制，ISUP采用的是二进制编码，而SIP采用文本编码方式。因此，MGC收到ISUP消息后通过ISUP-MIME方式把ISUP消息内容封装在SIP消息体中，传送到SIP接收端MGC再把所需内容提取出来，从而完成对ISUP消息的透明传送，实现IP网同PSTN网络的无缝连接。具体过程见图2。
图2 请求响应流程
由于ISUP在SIP网络中是透明传送的，因此MGC就需要完成ISUP同SIP信令的转换。呼叫信令的转换，最直观的方法就是翻译。MGC根据确定的对应关系对SIP消息和ISUP消息进行映射，MGC收到一条ISUP消息后，需要理解ISUP消息中的关键信息并进行翻译，然后填入SIP头部及SIP消息体中。翻译过程一定是一一对应的。例如，IAM翻译成INVITE，ACM翻译成Ringing，REL翻译成BYE等等。也就是说逐条地取出A信令消息参数值，映射到B信令消息体中，再接着传送。下面就对主要的信令消息的映射做一下简单的分析。
4.1 IAM消息的映射
MGC收到IAM消息后，对消息进行分析，将其映射成INVITE请求消息，再将其发送出去。接下来映射的重点就在于如何将IAM中的关键参数映射到INVITE消息中。MCC收到IAM消息后会去读取IAM消息中的被叫用户号码，即参数CPN。读出来后翻译成目的地tel URI放入到INVITE消息的To域和Reguest-URI域。但当FCI参数中的“号码已转移”位表明被叫方号码已转移时，就只能寻求其他参数了。在tel URL翻译完成后，还需要在其中附加一些ISUP字段。
（1）如果IAM中存在有CIP或TNS字段，则MGC应该从所给参数中取出CIC并加以分析。在通过本地策略验证之后，将一个“cic=”字段附加到目的地tel URL的后面。有一点需要注意的是，CIC应该附加到国家代码的后面。比如在中国，“5062”就应该是“+86-5062”。
（2）如果FCI参数中的“号码已转移”位表明已经执行过本地号码转移的操作或者IAM消息的CPN中存在有本地路由号码，则必须在URL之后附加一个“npdi=yes”字段。同时要把此路由号码转换成tel URL的形式拷贝到“rn=”字段中。如果CPN中没有路由号码，且IAM消息中存在有通用数字参数GDP，则对此GDP参数进行转换并拷贝到“rn=”字段附加到tel URL之后。
（3）多数情况下，To字段和Request-URI都是由目的地tel URL来提供的。但是，如果IAM中存在有OCN参数的话，To字段就应该由OCN参数翻译得来。
（4）From头字段的构造依赖于IAM中的CIN参数。如果CIN不存在，网关会自行构造一个只包含有网关主机名的虚拟的From头字段，如果CIN存在，则需要将其翻译为tel URL来生成From头字段。
4.2 1xx响应消息的映射
MGC收到的响应消息中，如果是100 trying消息则网关不触发任何PSTN消息。如果是18x消息，且消息体中没有ISUP消息，此时网关需要判断在此之前是否有ACM发送出去。如果之前没有ACM发送出去，MGC将依据表1来响应消息。
表1 18x响应消息的映射（MGC未发送ACM）
如果之前已发送过ACM消息，那么ISUP消息的响应则依据表2。
表2 18x响应消息的映射（MGC已发送ACM消息）
4.3 200响应消息的映射
收到200 OK响应消息后，网关需要建立一条双向通道，向PSTN发送一条ANM应答消息，同时向SIP网络发送一条ACK确认消息。但是，如果网关在发送ACM消息之前收到200 OK消息的话，MGC应该向PSTN发送一条CON消息而非ANM消息。
4.4 REL响应消息的映射
如果是正常的会话结束，且PSTN端先挂机，PSTN端会向MGC发送一条REL消息，网关依据此REL消息，向SIP端点发送一条BYE消息来通知SIP网络另一端已挂机。假如SIP端还未接通，PSTN终端就挂机了，此时网关依据收到的REL消息向SIP终端发送一条CANCEL消息，告诉SIP终端取消会话。
4.5 异常响应消息的映射
前面介绍的会话建立过程，是在假设没有任何异常发生的情况下完成的。但是实际当中，呼叫双方在会话建立过程中可能出现这样或那样的问题。因此还需要考虑异常响应消息的映射问题。比如说，网关连接不上URI中Contact头字段中所指的tel URL地址，或者说没有匹配的ENUM，这时就要用到重定向了。
3xx类响应消息是由重定向服务器来产生的。当网关收到来自于SIP端口的3xx响应消息时，即与其中的Contact头字段中所指示的用户联系，同时向PSTN端口发送一条事件代码为6的CPG消息，告诉PSTN网络呼叫正在被处理。
网关收到4xx～6xx类响应消息时，表明网关之前发送到SIP端口的INVITE消息被拒绝了。多数情况下，网关需要释放它所占用的资源，并发送一条带有原因值的REL消息给PSTN网络，同时还要给SIP网络发送一条资源释放的ACK确认消息。PSTN端口也需要给MGC发送一条RLC确认消息，告诉网关已完成资源释放。
4xx～6xx异常响应消息与REL原因代码之间的映射关系参考文献1中有详细介绍，此处不再赘述。
5、结束语
IP多媒体子系统（IMS）是在GSM向UMTS的演进过程中，由3GPP在Release 5版本中提出。IMS网络的特点是以纯IP网络作为承载网络，以SIP（会话初始协议）作为基本的通信协议来建立会话。而传统的PSTN网络采用的程控交换体系，其信令系统采用的是7号信令系统。那么就涉及到会话过程中呼叫信令的转换问题。
本文对ISUP协议与SIP协议互通进行了简单的介绍，并对此两种协议在互通时的映射问题做了详细地分析。以上仅限于理论上的分析研究，在实际应用当中可能还会遇到很多无法预料的问题。因此还有很多有关这两种协议的映射问题有待于进一步的深入探讨。相信在不久的将来，随着FMC的升温，对于ISUP与SIP互通的研究也将会不断的成熟与完善。
参考文献
[1] IETF RFC 3398 Integrated Services Digital Network（ISDN）User Part（ISUP）to Session Initiation Protocol（SIP）Mapping
