飞信分析之五用即时消息聊天时的协议交互过程(转).docx

作者：nathan以下分析基于Fetion 2006 beta ,其SIP-C协议的版本是2.0。前面列出了飞信的SIP-C协议支持的所有SIP Method以及Header Field，下面就两个用户间的聊天，即互相发送文本消息来看看飞信通过SIP-C协议的工作过程。先看看RFC规定的SIP的建立会话的标准过程，在RFC3261中通过SIP建立会话的过程是这样子的： . . . . proxy proxy . . . Alices . . . . . . . . . . . . . . . . . . . . Bobs softphone SIP Phone | | | | | INVITE F1 | | | |-| INVITE F2 | | | 100 Trying F3 |-| INVITE F4 | | | |- | 180 Ringing F6 | | | 180 Ringing F7 |-| | 180 Ringing F8 |-| 200 OK F9 | |-| 200 OK F10 |-| | 200 OK F11 |-| | | | Media Session | | | BYE F13 | | | |上图中F1-F14分别是步骤的编号，而Medai Session过程在飞信中，就是文本聊天消息的传递过程了。在RFC3428中对标准SIP的扩展了一个Message方法，通过Message方法承载这种即时消息，这样，上图中的Media Session按RFC3428的规定，就是这样的： | F1 MESSAGE | | |- | F2 MESSAGE | | | -| | | | | | F3 200 OK | | | -| | F4 200 OK | | | 03:8080 I SIP-C/2.0F: 123456789I: 16 Q: 1 IT: sip:987654321;p=1972K: text/html-fragmentK: multipartyL: 137v=0o=-0 0 IN 11:1111s=sessionc=IN IP4 11:1111t=0 0m=message 1111 sip sip:123456789;p=xxxx上面是发到服务器的第一条消息，是一个SIP协议的INVITE请求，发到飞信的服务器，服务器地址是03，端口8080，协议是TCP，上面的SIP消息就直接放在TCP的包中，UTF-8编码。消息的第1是请求行，I=INVITE（这缩写的标准在哪里?我还没找到来依据）,是请求对象(又没用标准的uri)，sIP-C/2.0是当前的SIP-C协议版本。第2行开始是消息头：F即From,标识从用户A（123456789)发出的请求（依然没用标准uri，应该是sip:123456789才对吧.)；I即CallID,按标准的SIP的规定,这应该是一个随机产生的一个全局唯一的标识符,它应该在客户端和服务器整个交互的过程中保持不变,但在飞信的SIP-C协议中,这是一个序列号，第一次与8080端口建立连接发出第一个请求时，这个值为1,以后每次发出一个请求则加1；Q即CSeq，也就是Command Sequence，它由一个整数的序列号和一个SIP方法组成，SIP方法与这个消息的SIP方法相同，这个序列号在一个会话过程中每次加1,这样来标识SIP消息的顺序；T就是To啦，这里倒是用了标准uri的表示，K即Supported,表示客户端所支持扩展；L即Content-Length，就是消息体的长度。从v=0开始的是消息体，用SDP(Session Description Protocol)描述的，根据RFC:v= (protocol version)，在目前飞信的INVITE中，固定的v=0o= (owner/creator and session identifier). 在目前飞信的INVITE中，前面是固定的，后面是发起人(用户A)的IP地址和端口s= (session name). 在目前飞信的INVITE中，固定的为s=sessionc=* (connection information - not required if included in all media).在目前飞信的INVITE中，除后面的发起人(用户A)的IP地址和端口外，前面是固定的。t= (time the session is active) 。在目前飞信的INVITE中，固定的为t=0 0m= (media name and transport address)。在目前飞信的INVITE中，1111是发起人的TCP端口，后面的sip:xxxxxxxx，是发起人的uri。第二步：11:1111 03:8080 SIP-C/2.0 100 TryingQ: 1 IT: sip:987654321;p=xxxxI: 16这是服务器回过来的对第一步的INVITE消息的一个RESPONSE，所以，I=16,Q=1 I。表示正在查找用户B。第三步：11:1111 03:8080A SIP-C/2.0I: 16 Q: 1 AT: sip:987654321;p=xxxF: 123456789接着，用户A发出ACK消息。第五步：11:1111 03:8080M SIP-C/2.0F: 123456789I: 16 Q: 2 MT: sip:987654321;p=xxxxC: text/html-fragmentK: SaveHistoryL: 121hello! 测试这就是用户A向对方发的即时消息，内容是“hello!测试。这里用的是SIP Message方法，消息体是XML表示的即时消息，消息头跟INVITE相似。第六步：11:1111 03:8080 B SIP-C/2.0F: 123456789I: 16 Q: 3 BT: sip:987654321;p=xxxxx这是用户A开始关闭聊天窗口准备结束聊天了，向用户B发出了一个BYE的SIP请求消息。第八步：11:1111 03:8080M SIP-C/2.0F: 12345678I: 16 Q: 1 MT: sip:987654321;p=xxxxN: SendSMSL: 4test以上分析都是飞信通过TCP直连方式工作时的情况，飞信通过HTTP直连呢？工作过程跟上面完全一样，不同的是，连接的是03:80，协议是HTTP，采用的POST请求是：POST /ht/sd.aspx?t=s&i=2 HTTP/1.1POST的数据分就是上面一样的SIP消息了。飞信发送通过即时消息聊天时，整个过程就是这样子。 通过这个分析，我们也可以看到，飞信聊天时整个内容是既未加密又未变换的（MSN还作了点点变换），因此聊天过程是可以被截取的，因此通过飞信聊天是会被别人偷听的，就如同去年MSN曝出的监听事件一样。那这个问题是可以解决的吗？当然是可以的，其实扩展SIP的Message方法时，RFC中就提到这一