科学技术与工程
Ｓｃｉｅｎｃｅ科学Ｔｅｃｈｎｏｌｏｇｙ技术ａｎｄ与Ｅｎｇｉｎｅｅｒｉｎｇ工程
Ｖｏｌ．６ｃ
Ｎｏ．１１Ｊｕｎ．２００６
１６７１－１８１５（２００６）１１－１５５６－０５２００６Ｓｃｉ．Ｔｅｃｈ．Ｅｎｇｎｇ．６卷
针对ＳＩＰ的ＳＴＵＮ解决方案的设计与实现
郭常清
（湖南大学软件学院，长沙４１００８２）
摘要从ＳＩＰ消息的特ＳＩＰ是一个基于文本的应用层协议，但ＳＩＰ协议本身无法实现让ＳＩＰ消息安全地穿过ＮＡＴ和防火墙。
点出发，提出一种无需扩展ＳＩＰ协议的应用层解决方案，引入ＳＴＵＮ协议，取得ＩＰ地址和端口的映射关系，修改ＳＩＰ和ＳＤＰ消息的内容来保证通信连接，从而实现对ＮＡＴ的穿越。关键词
ＶｏＩＰ协议（ＳＩＰ）网络地址翻译器ＳＴＵＮ
中图法分类号ＴＰ３９３；文献标识码Ａ
目前，ＶｏＩＰ技术在世界范围内已获得广泛应用，而基于ＳＩＰ［１］（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ［ＲＦＣ２５４３］，会话初始化协议）的软交换技术已成为ＶｏＩＰ技术研究的一个新的热点。
行了详述。
１ＳＩＰ技术简介
——服务ＳＩＰ协议采用基于文本格式的客户端—器方式，以文本形式表示消息的语法、语义和编码，客户机发起请求，服务器进行响应。ＳＩＰ独立于底层协议———ＴＣＰ、ＵＤＰ或ＳＣＴＰ，采用自己的应用层可靠机制来保证消息的可靠传递。ＳＩＰ消息中使用的ＳＤＰ（ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ［ＲＦＣ２３２７］，会话描述协议）用于ＳＩＰ端点之间媒体通道建立所需参数的描述。
一个基本的ＳＩＰ呼叫一般包括以下几个头域：
ＳＩＰ［１］是ＩＥＴＦ提出的在ＩＰ网络上进行多媒体
通信的应用层控制协议。可用于建立、修改、终结多媒体会话和呼叫。其特点是简单、便于扩展和扩充，且ＳＩＰ借鉴了许多已有的Ｉｎｔｅｒｎｅｔ协议，是实现增值综合业务的理想手段，具有很好的发展潜力。
由于我国广泛使用的宽带城域网、企业网中普遍采用ＮＡＴ［２］（ＮｅｔｗｏｒｋＡｄｄｒｅｓｓＴｒａｎｓｌａｔｏｒ［ＲＦＣ１６３１］，网络地址翻译器），ＳＩＰ是一个基于文本的应用层协议，建立会话所需的地址信息描述均存在于ＳＩＰ消息中。而包含丰富地址信息的ＳＩＰ消息处于应用层，
Ｃａｌｌ－ＩＤ、Ｒｅｑｕｅｓｔ－ＵＲＩ、Ｖｉａ、Ｆｒｏｍ、Ｔｏ、Ｃｓｅｑ、Ｃｏｎｔｅｎｔ－
这几个头域中携带Ｌｅｎｇｔｈ、Ｃｏｎｔｅｎｔ－Ｔｙｐｅ和Ｃｏｎｔａｃｔ。
了会话过程的基本地址信息，通过它们即可完成一个较完整的ＳＩＰ呼叫。文中将详述对这几个头域的改写。ＲＦＣ２５４３中对ＳＩＰ请求（Ｒｅｑｕｅｓｔ）定义了
ＮＡＴ只对ＴＣＰ／ＵＤＰ和ＩＰ包头中的地址和端口进行
翻译，从而造成载荷内的地址和端口与ＩＰ包头的源地址和源端口不一致，会导致ＮＡＴ外和ＮＡＴ内的用户之间无法从ＳＩＰ消息中得到有效的地址信息，
无法完成正常的会话建立过程。
为解决以上问题，文中采用ＳＴＵＮ［３］（Ｓｉｍｐｌｅ
ＩＮＶＩＴＥ、ＡＣＫ、ＯＰＴＩＯＮＳ、ＢＹＥ、ＣＡＮＣＥＬ和ＲＥＧＩＳＴＥＲ等６个方法。通过ＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ和ＲＥＧＩＳＴＥＲ等几个方法即可完成一个相对完整的ＳＩＰ呼叫过
程。同样，ＲＦＣ２５４３对ＳＩＰ响应（Ｒｅｓｐｏｎｓｅ）定义了相关的回答，与基本连接直接相关的有１００（Ｔｒｙｉｎｇ）、
ＴｒａｖｅｒｓａｌｏｆＵＤＰＴｈｒｏｕｇｈＮＡＴ［ＲＦＣ３４８９］）实现对ＮＡＴ的
穿越，将ＳＴＵＮ取得的（ＩＰ：端口）映射直接写入ＳＩＰ
消息来建立正确的连接。系统采用Ｍｉｃｒｏｓｏｆｔ主推的
１８０（Ｒｉｎｇｉｎｇ）、２００（ＯＫ）和４０４（Ｎｏｔｆｏｕｎｄ）等，文中
将对以上信息进行分析。
ＲＴＣＣｌｉｅｎｔＡＰＩ进行开发，以满足ＳＩＰ软交换系统
的全球统一标准，在文中对解决方案和实现方法进
２００６年１月６日收到
２ＳＴＵＮ穿越原理及系统实现方案
２．１
开发环境简介
系统所采用的开发环境如图１所示。
１１期郭常清：针对ＳＩＰ的ＳＴＵＮ解决方案的设计与实现１５５７
因此，除了消息本身，ＳＩＰ所控制的媒体流的传输也无法完成。
２．３ＳＴＵＮ所定义的ＮＡＴ类型分类
ＳＴＵＮ协议用来帮助位于ＮＡＴ之后的实体发
现ＮＡＴ的存在，判断ＮＡＴ的类型，从而得到由ＮＡＴ分配的绑定映射地址。ＳＴＵＮ无需对ＮＡＴ进行改变，适用于处理在应用程序实体与公网间有多重
ＮＡＴ的情况。
在实际应用中，ＵＤＰ在不同类型的ＮＡＴ中处
图１硬件拓扑图
理是不一样的。根据ＮＡＴ工作方式的不同，ＳＴＵＮ协议将ＮＡＴ分为四类。
ＰＣ＃１的ＩＰ配置为１９２．１８．７．１２８，在此机器上运
行ＳＴＵＮＣｌｉｅｎｔ；在ＰＣ＃２上安装两块网卡，ＩＰ分别
配置成１９２．１８．７．１和１７２．１８．７．１２４，ＰＣ＃２充当ＮＡＴ由ＰＣ＃３充Ｓｅｒｖｅｒ，由ＰＣ＃１和ＰＣ＃２共同组成私网。
当ＳＴＵＮＳｅｒｖｅｒ，安装两块网卡，ＩＰ分别配置为１７２．１８．７．１０和１７２．１８．７．１１，鉴于ＳＴＵＮ协议要求使用四个（ＩＰ：端口）对来完成对ＮＡＴ类型的判断，使用端口３４７８、３４７９，即可得到（１７２．１８．７．１０：３４７８）（１７２．１８．７．１０：３４７９）（１７２．１８．７．１１：３４７８）（１７２．１８．７．１１：
ＦｕｌｌｃｏｎｅＮＡＴ：是指所有来自相同内部ＩＰ地址
和端口的请求都映射到某一个相同的外部ＩＰ地址
和端口上。此外，任意的外部主机可以通过发送信息包到内部主机对应的外部ＩＰ地址上来发送信息包（在ＰＣ＃２上安装软件ＷｉｎＲｏｕｔｅＬｉｔｅ４．２，可模拟出此环境）。
ＲｅｓｔｒｉｃｔｅｄｃｏｎｅＮＡＴ：是指所有来自相同内部ＩＰ地址和端口的请求都映射到某一个相同的外部
与ＦｕｌｌｃｏｎｅＮＡＴ不同的是，一个ＩＰ地址和端口上。
外部主机只能在内部主机曾经发送过信息包给它的情况下，才能够发送信息包到该内部主机（ＩＰ必须一致，成功，
端口号可以不一样，１０．０．０．１：６６６６－＞
３４７９）等四个（ＩＰ：端口）对，ＰＣ＃４充当公网用户，ＩＰ
配置为１７２．１８．７．１２５。分别在ＰＣ＃１和ＰＣ＃４上运行
所开发的ＲＴＣＣｌｉｅｎｔ进行通话。
２．２ＮＡＴ所带来的问题
ＮＡＴ顾名思义就是实现了网络地址的翻译，目
前广泛应用于私有地址域与公有地址域的转换以缓解ＩＰｖ４地址匮乏的问题。由于ＮＡＴ的存在，那些使用到ＩＰ地址的高层应用将受到限制，如图１所示，以ＰＣ＃１和ＰＣ＃４之间建立ＳＩＰ连接的情况为例，当ＮＡＴ内的ＰＣ＃１向公网上的ＰＣ＃４发送
１７２．１８．７．１０：３４７８，１７２．１８．７．１０：３４７８－＞１０．０．０．１：６６６６１７２．１８．７．１０：３４７９－＞１０．０．０．１：６６６６也成功）
（在ＰＣ＃２上安装软件ＷｉｎＧａｔｅＶ５．０．２，可模拟出此
环境）。
ＰｏｒｔｒｅｓｔｒｉｃｔｅｄｃｏｎｅＮＡＴ：类似于ｒｅｓｔｒｉｃｔｅｄｃｏｎｅ
也就是说，只有在内ＮＡＴ，但是限制的还包括端口。
部主机（通过ＩＰ地址和端口号）给外部主机发送过信息包的情况下，该外部主机才可以发送信息包给该内部主机，并需要明确地表明原来接收内部主机信息时的ＩＰ地址和端口号（Ｒｅｓｔｒｉｃｔｅｄｃｏｎｅ
ＩＮＶＩＴＥ请求时，请求的头为：
ＩＮＶＩＴＥ：ＰＣ＃１＠１７２．１８．７．１２５ＳＩＰ／２．０
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ１９２．１８．７．１２８
……（略）
ＩＮＶＩＴＥ消息的源ＩＰ地址经过ＮＡＴ后，被翻译为
然而在ＳＩＰ协议中，ＰＣ＃４不会１７２．１８．７．１２４：４５０４０。
按此地址返回１００（Ｔｒｙｉｎｇ）响应，而是按Ｖｉａ中的由于这是个私有地址，发１９２．１８．７．１２８：２９３６２返回。
回的响应无法送到ＰＣ＃１中，连接无法建立。
同样地，对于ＳＩＰ所控制的媒体流的传输，有关地址和参数信息保存在ＳＩＰ消息的ＳＤＰ消息体中。
ＮＡＴ不需要相同的端口号，１０．０．０．１：６６６６－＞１７２．１８．７．１０：３４７８，１７２．１８．７．１０：３４７８－＞１０．０．０．１：６６６６成功，１７２．１８．７．１０：３４７９－＞１０．０．０．１：６６６６不成功）（在ＰＣ＃２上安装软件Ｓｙｇａｔｅ４．０，可模拟出此环境）。
ＳｙｍｍｅｔｒｉｃＮＡＴ：指的是所有来自相同内部ＩＰ
地址和端口到同一目的地的请求都映射到某一个相同的外部ＩＰ地址和端口上。假如相同的主机使用相同的源ＩＰ地址和端口号发送信息包到另一目的
１５５８科学技术与工程６卷
地，那么将会映射到另一外部地址上。而且，只有当外部主机接收到内部主机的信息包后才能发送信息包回给该内部主机（１０．０．０．１：６６６６－＞１７２．１８．７．１０：
ＲＥＱＵＥＳＴ属性只存在于绑定请求中。这两个属性
分别用于判定客户端是处于ＲｅｓｔｒｉｃｔｅｄｃｏｎｅＮＡＴ或
是ＰｏｒｔｒｅｓｔｒｉｃｔｅｄｃｏｎｅＮＡＴ后面。它们指示服务器使用另外的ＩＰ地址和端口号来发送绑定响应。这个属性是可选项。
（４）ＣＨＡＮＧＥＤ－ＡＤＤＲＥＳＳ，它位于绑定响应当中，假如客户端需要和“改变ＩＰ”“改变端口号”，它通知客户端改变后所用的源ＩＰ地址和端口号。
（５）ＳＯＵＲＣＥ－ＡＤＤＲＥＳＳ，它只位于绑定响应当中，它表明响应是由什么地方所发送的，源ＩＰ和端口号是什么。在探测二次ＮＡＴ配置中非常有效。
由以上所述可以得出，在实际的网络环境中，共有６种可能的情况：
（１）在公众ｉｎｔｅｒｎｅｔ上，（２）在拦截ＵＤＰ的防火墙内，
（３）可以允许ＵＤＰ出去，而响应必须回到请求的主机上（很像ｓｙｍｍｅｔｒｉｃＮＡＴ，但是没有地址翻译，叫这种为ｓｙｍｍｅｔｒｉｃＵＤＰＦｉｒｅｗａｌｌ），
（４）Ｆｕｌｌ－ｃｏｎｅＮＡＴ，（５）ＳｙｍｍｅｔｒｉｃＮＡＴ，
（６）ＲｅｓｔｒｉｃｔｅｄｃｏｎｅｏｒＰｏｒｔｒｅｓｔｒｉｃｔｅｄｃｏｎｅＮＡＴ。正确识别ＮＡＴ类型是实现穿越的关键，该过程的原理如图２所示。
现结合硬件拓扑图１和判别原理图２解释判
３４７８，外部地址为１１５．６８．４５．１２３，１０．０．０．１：６６６６－＞１７２．１８．７．１１：３４７９，采用的外部地址为１１５．６８．４５．１３４）
（ＳＴＵＮ无法穿越此类ＮＡＴ）。
２．４
ＳＴＵＮ技术绑定原理简介
ＳＴＵＮＣｌｉｅｎｔ：客户端是一个发送ＳＴＵＮ请求的实体。ＳＴＵＮ客户端可以运行在终端系统上（ｅｎｄ
ｓｙｓｔｅｍ），譬如ＰＣ机，或者是网络中的一个元素，譬
如一个会议服务器。
ＳＴＵＮＳｅｒｖｅｒ：服务器是接收ＳＴＵＮ请求，发送ＳＴＵＮ响应的实体。一般来说，ＳＴＵＮ服务器都附属
在公用因特网上。
ＳＴＵＮ协议是一种简单的Ｃ／Ｓ协议。客户端发
送请求到服务器，然后服务器给予响应。请求有两种，一种是绑定请求，通过ＵＤＰ发送；另一种是共享秘密请求，通过ＴＬＳｏｖｅｒＴＣＰ传送。ＳＴＵＮ绑定请求被用于发现ＮＡＴ的存在，并且发现ＮＡＴ所产生的对应公共ＩＰ地址和端口号。绑定请求通过ＵＤＰ协议发送到服务器上，当绑定请求到达服务器后，说因此，服务不定已经通过了一层或多层的ＮＡＴ了。
器所收到的请求的源地址肯定就是由最靠近服务器的ＮＡＴ所提供的对应地址，ＳＴＵＮ服务器复制源地址和端口号到绑定响应中去，并且按照源地址和端口号发回响应。经过多层的ＮＡＴ后，响应还是会回到客户端上的。
技巧在于利用ＳＴＵＮ协议来发现ＮＡＴ的存在，判断出类型，并得到和利用它们所分配的绑定。
几个主要的ＳＴＵＮ属性定义如下。
（１）ＭＡＰＰＥＤ－ＡＤＤＲＥＳＳ（ＩＰ地址和端口号），它总是位于绑定响应中，代表了服务器所收到的绑定请求中的源ＩＰ地址和端口号。如有ＮＡＴ存在，该（ＩＰ：端口）就是内部（ＩＰ：端口）所对应的外部映射。
（２）ＲＥＳＰＯＮＳＥ－ＡＤＤＲＥＳＳ（ＩＰ地址和端口号），它在绑定请求中，代表需要送到的ＩＰ地址和端口号。（不一定需要有，没有的话，服务器会回送到请求的源地址和端口）。
（３）ＣＨＡＮＧＥ－ＲＥＱＵＥＳＴ，它包括两个标志负责来控制发送响应的ＩＰ地址和端口号。这两个标志分别是“改变ＩＰ”和“改变端口号”。ＣＨＡＮＧＥ－
图２类型判别原理图
１１期郭常清：针对ＳＩＰ的ＳＴＵＮ解决方案的设计与实现１５５９
断过程。
该流程使用三个测试。在测试Ｉ上，客户端发送
果，如图３所示。
ＳＴＵＮ绑定请求到服务器上（没有设定ＣＨＡＮＧＥ－ＲＥＱＵＥＳＴ属性的标记，也没有ＲＥＳＰＯＮＳＥ－
这导致服务器发送响应到发出请ＡＤＤＲＥＳＳ属性）。
求的ＩＰ和端口号。在测试ＩＩ中，客户端发送绑定请求（带有ＣＨＡＮＧＥ－ＲＥＱＵＥＳＴ属性中的和“改变ＩＰ”的标记）。在测试ＩＩＩ中，客户端会发“改变端口号”
送仅带有标记的绑定请求。“改变端口号”
客户端（１９２．１８．７．１２８：２９３６２）先开始测试Ｉ，在
ＳＴＵＮＳｅｒｖｅｒ上使用（１７２．１８．７．１０：３４７８），假如该测
试没有产生任何响应，那么客户端就会知道不能使用ＵＤＰ连接。假如产生了响应，客户端就需要检测
ＭＡＰＰＥＤ－ＡＤＤＲＥＳＳ属性。假如得到的地址和端口
号和发送信息包的ＩＰ地址和端口号一致的话，就证明并没有经过ＮＡＴ转换。然后进行测试ＩＩ。
此时ＳＴＵＮＳｅｒｖｅｒ发送响应时使用（１７２．１８．７．１１：３４７９），假如收到一个响应，那么客户
端就会知道它拥有与ｉｎｔｅｒｎｅｔ开放的接口（至少，它位于一个功能类似ｆｕｌｌ－ｃｏｎｅＮＡＴ的防火墙后面，但是缺乏了地址翻译功能）。假如收不到响应，那么客户端就会知道它位于ｓｙｍｍｅｔｒｉｃＵＤＰｆｉｒｅｗａｌｌ的后面。
那么当ＩＰ地址和端口号并不符合通过测试Ｉ所得到响应的ＭＡＰＰＥＤ－ＡＤＤＲＥＳＳ属性，那就证明它必定位于ＮＡＴ背后。然后进行测试ＩＩ（此时ＳＴＵＮ
图３映射绑定关系图
由图３可知，得到五对绑定的映射地址，例如：内部（ＩＰ：端口）为（１９２．１８．７．１２８：２９３６２），外部为（１７２．１８．７．１２４：４５０４０），应在后台持续运行此程序，使
ＳＴＵＮＣｌｉｅｎｔ不断向ＳＴＵＮＳｅｒｖｅｒ发送请求，保证映射
地址的实时更新，才能保证会话连接的长时间有效。
２．５使用所取映射改写ＳＩＰ消息
１）对Ｖｉａ头域的改写
Ｖｉａ纪录请求所通过的路径。
原为Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ１９２．１８．７．１２８：２９３６２，改为Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ１７２．１８．７．１２４：４５０４０。由内网用户发出的ＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ和
Ｓｅｒｖｅｒ上发回响应的是（１７２．１８．７．１１：３４７９）），假如
收到响应的话，客户端就会知道它处于ｆｕｌｌ－ｃｏｎｅ假如没有收到响应，再进行测试Ｉ，但是ＮＡＴ后面。
这次，将使用从响应中ＣＨＡＮＧＥＤ－ＡＤＤＲＥＳＳ属性所得到的ＩＰ和端口号来进行测试Ｉ，即使用（１７２．１８．７．１１：３４７９）。假如返回的ＭＡＰＰＥＤ－
ＲＥＧＩＳＴＥＲ等４个请求消息和１００（Ｔｒｙｉｎｇ）、１８０（Ｒｉｎｇｉｎｇ）、２００（ＯＫ）等３个回答中的Ｖｉａ头域均应
进行以上修改。
２）对ＳＤＰ消息体的修改
ＳＤＰ消息体中描述了与会话及相关媒体特性的
有关内容。与连接直接相关的头域为：
“Ｃｏｎｎｅｃｔｉｏｎｃ＝”，描述主机的ＩＰ地址。“Ｍｅｄｉａｍ＝”接收端口以及接收媒体流的类型信息。
原为ｃ＝ＩＮＩＰ１９２．１８．７．１２８，
ＡＤＤＲＥＳＳ属性中的ＩＰ和端口号与第一次测试Ｉ所
得到的不一样，就证明它处于ｓｙｍｍｅｔｒｉｃＮＡＴ后面。
假如地址和端口号相同的话，就证明客户端处于
ＲｅｓｔｒｉｃｔｅｄＮＡＴ或ＰｏｒｔｒｅｓｔｒｉｃｔｅｄＮＡＴ后面。为了确定究竟是处于哪个后面，将要进行测试ＩＩＩ。即让
假如得到ＳＴＵＮＳｅｒｖｅｒ上使用（１７２．１８．７．１１：３４７８）。
一个响应，就是处于ＲｅｓｔｒｉｃｔｅｄＮＡＴ后面，反之，就是ＰｏｒｔｒｅｓｔｒｉｃｔｅｄＮＡＴ。
类型判断结束后，将返回映射端口的绑定结
ｍ＝ａｕｄｉｏ２９３６２ＲＴＰ／ＡＶＰ０，
改为ｃ＝ＩＮＩＰ１７２．１８．７．１２４，
ｍ＝ａｕｄｉｏ４５０４０ＲＴＰ／ＡＶＰ０。
由公网用户返回的２００（ＯＫ）中的ＳＤＰ消息体中的
相应部分应进行同样的修改．
１５６０科学技术与工程６卷
３）对Ｃｏｎｔａｃｔ头域的修改
Ｃｏｎｔａｃｔ头域通常标明能到达用户的下一个
重定向等操作密切相关。ＵＲＬ，与注册、
原为Ｃｏｎｔａｃｔ：〈ｓｉｐ：ｐｃ＃１＠１９２．１８．７．１２８：２９３６２〉改为Ｃｏｎｔａｃｔ：〈ｓｉｐ：ｐｃ＃１＠１７２．１８．７．１２４：４５０４０〉对ＲＥＧＩＳＴＥＲ中的Ｃｏｎｔａｃｔ头域，应进行同样的修改。
协议，完全可以在网络层实现对有效数据的定位，从而完成对文本数据的解析和修改。同时，采用在底层对ＳＩＰ消息进行改写的方法，避免了将消息先送往应用层，然后再返回底层完成发送，可以提高效率。
参
１２３
考文献
４）对Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ头域进行修改。
由于ＳＩＰ消息被改写，将导致消息体长度发生改变，应对相关的ＩＮＶＩＴＥ及２００（ＯＫ）等消息的
ＨａｎｄｌｅｙＭ，ＳｃｈｕｌｚｒｉｎｎｅＨ，ＳｃｈｏｏｌｅｒＥ，ＲｏｓｅｎｂｅｒｇＪＳＩＰ：Ｓｅｓｓｉｏｎｉｎｉｔｉａｔｉｏｎｐｒｏｔｏｃｏｌ．ＲＦＣ２５４３，Ｍａｒｃｈ１９９９
ＥｇｅｖａｎｇＫ，ＦｒａｎｃｉｓＰ．ＴｈｅＩＰｎｅｔｗｏｒｋａｄｄｒｅｓｓｔｒａｎｓｌａｔｏｒ．（ＮＡＴ）．ＲＦＣ１６３１，Ｍａｙ１９９４ＲｏｓｅｎｂｅｒｇＪ，
ＷｅｉｎｂｅｒｇｅｒＪ，
ＭａｈｙＲ．ＳＴＵＮ：Ｓｉｍｐｌｅｔｒａｖｅｒｓａｌｏｆ
ｕｓｅｒｄａｔａｇｒａｍｐｒｏｔｏｃｏｌ（ＵＤＰ）ｔｈｒｏｕｇｈｎｅｔｗｏｒｋａｄｄｒｅｓｓｔｒａｎｓｌａｔｏｒｓ（ＮＡＴｓ）．ＲＦＣ３４８９，Ｍａｒｃｈ２００３
Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ进行改写。
３结论
本文提出的解决方案实现于应用层，无需对协
４５
ＳｒｉｓｕｒｅｓｈＰ，ＫｕｔｈａｎＪ，ＲｏｓｅｎｂｅｒｇＪ．Ｍｉｄｄｌｅｂｏｘｃｏｍｍｕｎｉｃａｔｉｏｎ
议进行扩展。可以直接利用现有的ＳＩＰ协议栈等资源。最根本的依据是ＳＩＰ本身是一个纯文本形式的
ａｒｃｈｉｔｅｃｔｕｒｅａｎｄｆｒａｍｅｗｏｒｋ．ＩＥＴＦ，Ｆｅｂ２００１
ＲｏｓｅｎｂｅｒｇＪ，ＷｅｉｎｂｅｒｇｅｒＪ，ＳｃｈｕｌｚｒｉｎｎｅＨ．ＳＩＰＥｘｔｅｎｓｉｏｎｆｏｒＮＡＴＴｒａｖｅｒａｌ．ＩＥＴＦ，Ｎｏｖ２１２００１
ＩｍｐｌｅｍｅｎｔａｔｉｏｎｔｈｅＴｒａｖｅｒｓｉｎｇｏｆＮＡＴｉｎＳＩＰ－ｂａｓｅｄＶｏＩＰＳｙｓｔｅｍ
ＧＵＯＣｈａｎｇｑｉｎｇ
（ＤｅｐａｒｔｍｅｎｔｏｆＳｏｆｔｗａｒｅ，ＨｕｎａｎＵｎｉｖｅｒｓｉｔｙ，Ｃｈａｎｇｓｈａ４１００８２）
［Ａｂｓｔｒａｃｔ］ＳＩＰｉｓａｔｅｘｔ－ｂａｓｅｄａｐｐｌｉｃａｔｉｏｎ－ｌａｙｅｒｐｒｏｔｏｃｏｌ．Ｉｔｃａｎ＇ｔｂｅｕｓｅｄｉｎＮＡＴｏｒｆｉｒｅｗａｌｌｅｎｖｉｒｏｎｍｅｎｔ．
ＡｃｃｏｒｄｉｎｇｔｏｔｈｅｓｐｅｃｉａｌｔｉｅｓｏｆｅｎｔｉｔｉｅｓｏｆＳＩＰｍｅｓｓａｇｅｓ，ａｎａｐｐｌｉｃａｔｉｏｎｌａｙｅｒｓｏｌｕｔｉｏｎｗｉｔｈｏｕｔｅｘｐａｎｄｉｎｇＳＩＰ，ｂｙ
ａｃｈｉｅｖｉｎｇｔｈｅｍａｐｐｅｄｒｅｌａｔｉｏｎｏｆＩＰａｄｄｒｅｓｓａｎｄＰｏｒｔｓｗｉｔｈＳＴＵＮａｎｄｏｖｅｒｗｒｉｔｉｎｇｔｈｅＳＩＰｍｅｓｓａｇｅｓａｎｄＳＤＰｍｅｓｓａｇｅｓｔｏａｓｓｕｒｅｔｈｅｃｏｍｍｕｎｉｃａｔｉｏｎｃｏｎｎｅｃｔｉｏｎａｒｅｐｒｅｓｅｎｔｅｄ．ＩｎｔｈｉｓｗａｙｔｈｅｓｙｓｔｅｍｃａｎｉｍｐｌｅｍｅｎｔｔｈｅｔｒａｖｅｒｓｉｎｇｏｆｔｈｅＮＡＴ．［Ｋｅｙｗｏｒｄｓ］ＶｏＩＰ
ｓｅｓｓｉｏｎｉｎｉｔｉａｔｉｏｎｐｒｏｔｏｃｏｌ
ｎｅｔｗｏｒｋａｄｄｒｅｓｓｔｒａｎｓｌａｔｏｒ
ＳＴＵＮ
因篇幅问题不能全部显示，请点此查看更多更全内容