P2P之风云再起

最近MSN非常非常不正常，几乎无法登录，几乎总是出现800E27FD的错误，重试成功的概率越来越小。

看网上资料好像是微软在急着收钱，所以免费的用户的日子越来越难过，真不知道微软是怎么想的，这不是把用户向门外推吗？

联系我的朋友，如果在MSN上找不到我，那就到SKYPE或QQ上找我吧～

SkypeID: ShrekSz
QQ: 2215712

最近MSN非常非常不正常，几乎无法登录，几乎总是出现800E27FD的错误，重试成功的概率越来越小。

看网上资料好像是微软在急着收钱，所以免费的用户的日子越来越难过，真不知道微软是怎么想的，这不是把用户向门外推吗？

联系我的朋友，如果在MSN上找不到我，那就到SKYPE或QQ上找我吧～

SkypeID: ShrekSz
QQ: 2215712

其中，Skype使用的是第三和第四中方式！


一、NAT/ALG 方式

普通NAT是通过修改UDP或TCP报文头部地址信息实现地址的转换，但对于VOIP应用，在TCP/UDP净载中也需带地址信息，ALG方式是指在私网中的VOIP终端在净载中填写的是其私网地址，此地址信息在通过NAT时被修改为NAT上对外的地址。

此时当然要求ALG功能驻留在NAT/Firewall设备中，要求这些设备本身具备应用识别的智能。支持IP语音和视频协议（H323、SIP、MGCP/H248）的识别和对NAT/Firewall的控制，同时每增加一种新的应用都将需要对NAT/Firewall进行升级。

在安全要求上还需要作一些折衷，因为ALG 不能识别加密后的报文内容，所以必须保证报文采用明文传送，这使得报文在公网中传送时有很大的安全隐患。
NAT/ALG是支持VOIP NAT穿透的一种最简单的方式，但由于网络实际情况是已部署了大量的不支持此种特性的NAT/FW设备，因此，实际应用中，很难采用这种方式。

二、MIDCOM 方式

与NAT/ALG不同的是，MIDCOM的基本框架是采用可信的第三方（MIDCOM Agent）对Middlebox(NAT/FW)进行控制，VOIP协议的识别不由Middlebox完成，而是由外部的MIDCOMAgent完成，因此VOIP使用的协议对Middlebox是透明的 。

由于识别应用协议的功能从Middlebox移到外部的MIDCOM Agent上，根据MIDCOM的构，在不需要更改Middlebox基本特性的基础上，通过对MIDCOMAgent的升级就可以支持更多的新业务，这是相对NAT/ALG方式的一个很大的优势。

在VOIP实际应用中，Middlebox功能可驻留在NAT/Firewall，通过软交换设备(即MIDCOMAgent)对IP语音和视频协议（H323、SIP、MGCP/H248）的识别和对NAT/Firewall的控制，来完成VOIP应用穿越NAT/Firewall 。
在安全性上，MIDCOM方式可支持控制报文的加密，可支持媒体流的加密，因此安全性比较高。

如果在软交换设备上实现对SIP/H323/MGCP/H248协议的识别，就只需在软交换和NAT/FW设备上增加MIDCOM协议即可，而且以后新的应用业务识别随着软交换的支持而支持，此方案是一种比较有前途的解决方案，但要求现有的NAT/FW设备需升级支持MIDCOM协议,从这一点上来说，对已大量布署的NAT/FW设备来说，也是很困难的，同NAT/ALG方式有相同的问题。

三、STUN 方式

解决穿透NAT问题的另一思路是，私网中的VOIP终端通过某种机制预先得到出口NAT上的对外地址，然后在净载中所填写的地址信息直接填写出口NAT上的对外地址，而不是私网内终端的私有IP地址，这样净载中的内容在经过NAT时就无需被修改了，只需按普通NAT流程转换报文头的IP地址即可，净载中的IP地址信息和报文头地址信息是一致的。STUN协议就是基于此思路来解决应用层地址的转换问题。

STUN的全称是Simple Traversal of UDP Through Network AddressTranslators，即UDP对NAT的简单穿越方式。 应用程序（即STUN CLIENT）向NAT外的STUNSERVER通过UDP发送请求STUN 消息，STUN SERVER收到请求消息，产生响应消息，响应消息中携带请求消息的源端口，即STUNCLIENT在NAT上对应的外部端口。然后响应消息通过NAT发送给STUN CLIENT，STUNCLIENT通过响应消息体中的内容得知其NAT上的外部地址，并将其填入以后呼叫协议的UDP负载中，告知对端，本端的RTP接收地址和端口号为NAT外部的地址和端口号。由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项，故媒体流可顺利穿越NAT。

STUN协议最大的优点是无需现有NAT/FW设备做任何改动。由于实际应用中，已有大量的NAT/FW，并且这些NAT/FW并不支持VoIP的应用，如果用MIDCOM或NAT/ALG方式来解决此问题，需要替换现有的NAT/FW，这是不太容易的。而采用STUN方式无需改动NAT/FW，这是其最大优势，同时STUN方式可在多个NAT串联的网络环境中使用，但MIDCOM方式则无法实现对多级NAT的有效控制。

STUN的局限性在于需要VOIP终端支持STUNCLIENT的功能，同时STUN并不适合支持TCP连接的穿越，因此不支持H323。另外STUN方式不支持对防火墙的穿越，不支持对称NAT（Symmetric NAT）类型（在安全性要求较高的企业网中，出口NAT通常是这种类型）穿越。

四、TURN方式

TURN方式解决NAT问题的思路与STUN相似，也是私网中的VOIP终端通过某种机制预先得公网上的服务地址（STUN方式得到的地址为出口NAT上外部地址，TURN方式得到地址为TURN Server上的公网地址），然后在报文净载中所要求的地址信息就直接填写该公网地址。
TURN的全称为Traversal Using Relay NAT，即通过Relay方式穿越NAT。TURN应用模型通过分配TURNServer的地址和端口作为私网中VOIP终端对外的接受地址和端口，即私网终端发出的报文都要经过TURNServer进行Relay转发，这种方式除了具有STUN方式的优点外，还解决了STUN应用无法穿透对称NAT（SymmetricNAT）以及类似的Firewall设备的缺陷，同时TURN支持基于TCP的应用，如H323协议。此外TURNServer控制分配地址和端口，能分配RTP/RTCP地址对（RTCP端口号为RTP端口号加1）作为私网终端用户的接受地址，避免了STUN方式中出口NAT对RTP/RTCP地址端口号的任意分配，使得客户端无法收到对端发来的RTCP报文（对端发RTCP报文时，目的端口号缺省按RTP端口号加1发送）。
TURN的局限性在于需要VOIP终端支持TURN Client，这一点同STUN一样对网络终端有要求。此外，所有报文都必须经过TURN Server转发，增大了包的延迟和丢包的可能性。

转自：http://www.netexpert.cn/redirect.php?tid=335&goto=lastpost&fpage=11

now the project of P2P media platform library is in my plan,this project target the application for P2P(PEER to PEER) realtime network,and will be a common library for various application.

here is the features now:
. Embed in any Applications you wish
. DLL interface with detail documents
. Skype protocol compatible optional
. Any media stream type support, not the Voice/Video/Message only
. etc ...

My team is working now ... ;)

最近MSN非常非常不正常，几乎无法登录，几乎总是出现800E27FD的错误，重试成功的概率越来越小。

看网上资料好像是微软在急着收钱，所以免费的用户的日子越来越难过，真不知道微软是怎么想的，这不是把用户向门外推吗？

联系我的朋友，如果在MSN上找不到我，那就到SKYPE或QQ上找我吧～

SkypeID: ShrekSz
QQ: 2215712

the Skype&aposs new version is launched today,I downloaded and tested it for my concerned CPU usage bug.

first I describe the bugs in my computer,anyway,the Skype version 1.1 works well....works like a charm in fact, even in the CS,the great game,the Skype is still works. but from the version 1.2,a bad dream is comming,Skype usually paused suddenly,one thing has stayed true,when I open the Skype&aposs option window,and drag from here to there and  time to time,the CPU usage 100% is always appear per about 5-6 times,at the moment,my computer is looked like dead except my mouse can be moved. same things occured at my first call somebody,when the connection created,and the talk keep time is displayed as 00:00:00,the pause is occured,and the pause will keep 7 seconds,in this seconds,everything is still,the caller and callee will hear nothing,the CPU usage waveform is also break in this time.

ok,let&aposs return the new version,it seem not be better :(     all the bugs is stillthere,maybe cause by my specical setting of my system,here is my system&aposs something special:

1 ie is forbiden to access the internet  :)
2 firefox 1.04
3 SKYNET firewall
4 macfee virus firewall
5 win2k
6 AMD XP 1900+
7 nforce chip set

id appreciate any help i can get!

the Skype&aposs new version is launched today,I downloaded and tested it for my concerned CPU usage bug.

first I describe the bugs in my computer,anyway,the Skype version 1.1 works well....works like a charm in fact, even in the CS,the great game,the Skype is still works. but from the version 1.2,a bad dream is comming,Skype usually paused suddenly,one thing has stayed true,when I open the Skype&aposs option window,and drag from here to there and  time to time,the CPU usage 100% is always appear per about 5-6 times,at the moment,my computer is looked like dead except my mouse can be moved. same things occured at my first call somebody,when the connection created,and the talk keep time is displayed as 00:00:00,the pause is occured,and the pause will keep 7 seconds,in this seconds,everything is still,the caller and callee will hear nothing,the CPU usage waveform is also break in this time.

ok,let&aposs return the new version,it seem not be better :(     all the bugs is stillthere,maybe cause by my specical setting of my system,here is my system&aposs something special:

1 ie is forbiden to access the internet  :)
2 firefox 1.04
3 SKYNET firewall
4 macfee virus firewall
5 win2k
6 AMD XP 1900+
7 nforce chip set

id appreciate any help i can get!

the Skype&aposs new version is launched today,I downloaded and tested it for my concerned CPU usage bug.

first I describe the bugs in my computer,anyway,the Skype version 1.1 works well....works like a charm in fact, even in the CS,the great game,the Skype is still works. but from the version 1.2,a bad dream is comming,Skype usually paused suddenly,one thing has stayed true,when I open the Skype&aposs option window,and drag from here to there and  time to time,the CPU usage 100% is always appear per about 5-6 times,at the moment,my computer is looked like dead except my mouse can be moved. same things occured at my first call somebody,when the connection created,and the talk keep time is displayed as 00:00:00,the pause is occured,and the pause will keep 7 seconds,in this seconds,everything is still,the caller and callee will hear nothing,the CPU usage waveform is also break in this time.

ok,let&aposs return the new version,it seem not be better :(     all the bugs is stillthere,maybe cause by my specical setting of my system,here is my system&aposs something special:

1 ie is forbiden to access the internet  :)
2 firefox 1.04
3 SKYNET firewall
4 macfee virus firewall
5 win2k
6 AMD XP 1900+
7 nforce chip set

id appreciate any help i can get!

对于Skype的监听，我想从两个层面来讨论，一个是监听的方法，一个是监听的范围。

讨论Skype的监听前，先确定一个必要的条件，那就是要能听到所有的通讯的包，这是原则，幸好这一点在本地和许多节点上都没有问题。
监听的方法涉及到Skype的协议和协议的加密层的解密，我目前的思路是这样的:
1 从长度、某特征字节值粗略判断一个Skype节点的HostScanner动作，并将其加入TTargetIpList中，保持对其数据的跟踪。
2 对TTargetIpList中的Skype节点进出的通讯包进行解码，获得其登录的SN节点，记录在TSuperNode中，并保持对其数据的跟踪
3 侦测到TTargetIpList中的节点发起一个Session，加入TSessionList,设置记录标志，启动后续数据包的记录，记录的包中的包括Chat Message packet、Voice stream packet、File transmission packet以及以后的Video stream packet等等。
4 侦测TSessionList中Session的结束，停止记录数据包。
5 对于记录下来的数据，进行解码，这个环节是非实时的，在后台处理就OK

侦听的范围分为在本地的侦听，这种方式的侦听在局域网内即可完成，并可以完成实时的解码和同步的语音侦听，而在其他节点包括骨干网的节点侦听就需要硬件设备完成1、2、3、4的步骤，因为这些步骤必须是实时完成并会涉及多路的侦听，PC机的资源不能可能完成这样的工作，步骤5可以在PC机上完成，当然一个管理界面应该是必须的，可以查找特定时段、特定IP等等匹配条件的通话录音、传输文件、视频等数据。

以上是自己一点不成熟的想法，协议解析完成后，重点可能在监听硬件的设计环节，需要把协议解析的动作移植到硬件中以提高处理能力。

对于Skype的监听，我想从两个层面来讨论，一个是监听的方法，一个是监听的范围。

讨论Skype的监听前，先确定一个必要的条件，那就是要能听到所有的通讯的包，这是原则，幸好这一点在本地和许多节点上都没有问题。
监听的方法涉及到Skype的协议和协议的加密层的解密，我目前的思路是这样的:
1 从长度、某特征字节值粗略判断一个Skype节点的HostScanner动作，并将其加入TTargetIpList中，保持对其数据的跟踪。
2 对TTargetIpList中的Skype节点进出的通讯包进行解码，获得其登录的SN节点，记录在TSuperNode中，并保持对其数据的跟踪
3 侦测到TTargetIpList中的节点发起一个Session，加入TSessionList,设置记录标志，启动后续数据包的记录，记录的包中的包括Chat Message packet、Voice stream packet、File transmission packet以及以后的Video stream packet等等。
4 侦测TSessionList中Session的结束，停止记录数据包。
5 对于记录下来的数据，进行解码，这个环节是非实时的，在后台处理就OK

侦听的范围分为在本地的侦听，这种方式的侦听在局域网内即可完成，并可以完成实时的解码和同步的语音侦听，而在其他节点包括骨干网的节点侦听就需要硬件设备完成1、2、3、4的步骤，因为这些步骤必须是实时完成并会涉及多路的侦听，PC机的资源不能可能完成这样的工作，步骤5可以在PC机上完成，当然一个管理界面应该是必须的，可以查找特定时段、特定IP等等匹配条件的通话录音、传输文件、视频等数据。

以上是自己一点不成熟的想法，协议解析完成后，重点可能在监听硬件的设计环节，需要把协议解析的动作移植到硬件中以提高处理能力。