转载自:
http://hi.baidu.com/nathan2007/blog/item/1ee3823422ebbdb6d1a2d376.html
作者:nathan
以下分析基于Fetion 2006 beta 2.1.0.0,其SIP-C协议的版本是2.0。
前面列出了飞信的SIP-C协议支持的所有SIP Method以及Header Field,下面就两个用户间的聊天,即互相发送文本消息来看看飞信通过SIP-C协议的工作过程。
先看看RFC规定的SIP的建立会话的标准过程,在RFC3261中通过SIP建立会话的过程是这样子的:
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
上图中F1-F14分别是步骤的编号,而Medai Session过程在飞信中,就是文本聊天消息的传递过程了。在RFC3428中对标准SIP的扩展了一个Message方法,通过Message方法承载这种即时消息,这样,上图中的Media Session按RFC3428的规定,就是这样的:
| F1 MESSAGE | |
|--------------------> | F2 MESSAGE |
| | ----------------------->|
| | |
| | F3 200 OK |
| | <-----------------------|
| F4 200 OK | |
|<-------------------- | |
| | |
| | |
| | |
User 1 Proxy User 2
飞信是完全依照以上RFC的要求来实现这一过程来的。
下面来看飞信具体实现的聊天过程是怎么样的。假定有这么一个聊天过程是:飞信用户A(飞信号为123456789,飞信用TCP方式工作在 111.111.111.111:1111)双击好友列表中的飞信用户B(飞信号为987654321,飞信用TCP方式工作在 222.222.222.222:2222),这时聊天窗口弹出,用户A对B发出:"Hello!测试“,然后用户A关闭了聊天窗口,结束了这次即时消息对话过程。
我们看用户A这一端来看整个聊天过程中,用户A与服务器(SIP的Proxy Server)的交互过程是 (请对照上面RFC的SIP会话建立过程,另外,下面的红色字是表示数据的发送方向,蓝色字是全部的SIP消息,即TCP包的包体部分。):
第一步:111.111.111.111:1111 >>>>>>>> 221.130.45.203:8080
I fetion.com.cn SIP-C/2.0
F: 123456789
I: 16
Q: 1 I
T: sip:987654321@fetion.com.cn;p=1972
K: text/html-fragment
K: multiparty
L: 137
v=0
o=-0 0 IN 111.111.111.111:1111
s=session
c=IN IP4 111.111.111.111:1111
t=0 0
m=message 1111 sip sip:123456789@fetion.com.cn;p=xxxx
上面是发到服务器的第一条消息,是一个SIP协议的INVITE请求,发到飞信的服务器,服务器地址是221.130.45.203,端口8080,协议是TCP,上面的SIP消息就直接放在TCP的包中,UTF-8编码。
消息的第1是请求行,I=INVITE(这缩写的标准在哪里?我还没找到来依据),fetion.com.cn是请求对象(又没用标准的uri),"sIP-C/2.0"是当前的SIP-C协议版本。
第2行开始是消息头:"F"即From,标识从用户A(123456789)发出的请求(依然没用标准uri,应该是 sip:123456789@xx.fetion.com.cn才对吧....);"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=0
o= (owner/creator and session identifier). 在目前飞信的INVITE中,前面是固定的,后面是发起人(用户A)的IP地址和端口
s= (session name). 在目前飞信的INVITE中,固定的为s=session
c=* (connection information - not required if included in all media).在目前飞信的INVITE中,除后面的发起人(用户A)的IP地址和端口外,前面是固定的。
t= (time the session is active) 。在目前飞信的INVITE中,固定的为"t=0 0"
m= (media name and transport address)。在目前飞信的INVITE中,"1111"是发起人的TCP端口,后面的sip:xxxxxxxx,是发起人的uri。
第二步:111.111.111.111:1111 <<<<<<<< 221.130.45.203:8080
SIP-C/2.0 100 Trying
Q: 1 I
T: sip:987654321@fetion.com.cn;p=xxxx
I: 16
这是服务器回过来的对第一步的INVITE消息的一个RESPONSE,所以,I=16,Q=1 I。表示正在查找用户B。
第三步:111.111.111.111:1111 <<<<<<<< 221.130.45.203:8080
SIP-C/2.0 200 OK
Q: 1 I
K: text/html-fragment
K: multiparty
T: sip:123456789@fetion.com.cn;p=xxx
I: 16
L: 135
v=0
o=-0 0 IN 222.222.222.222:2222
s=session
c=IN IP4 222.222.222.222:2222
t=0 0
m=message 2222 sip sip:987654321@fetion.com.cn;p=xxx
这是服务器转过来的用户B对用户A的INVITE的回复,是:OK,其中222.222.222.222:2222是用户B的IP和端口。
第四步:111.111.111.111:1111 >>>>>>>> 221.130.45.203:8080
A fetion.com.cn SIP-C/2.0
I: 16
Q: 1 A
T: sip:987654321@fetion.com.cn;p=xxx
F: 123456789
接着,用户A发出ACK消息。
第五步:111.111.111.111:1111 >>>>>>>> 221.130.45.203:8080
M fetion.com.cn SIP-C/2.0
F: 123456789
I: 16
Q: 2 M
T: sip:987654321@fetion.com.cn;p=xxxx
C: text/html-fragment
K: SaveHistory
L: 121
<Font Face='Arial' Color='-16777216' Size='9'>hello! </Font><Font Face='SimSun' Color='-16777216' Size='12'>测试</Font>
这就是用户A向对方发的即时消息,内容是“hello!测试"。这里用的是SIP Message方法,消息体是XML表示的即时消息,消息头跟INVITE相似。
第六步:111.111.111.111:1111 <<<<<<<< 221.130.45.203:8080
SIP-C/2.0 200 OK
Q: 2 M
T: sip:123456798@fetion.com.cn;p=xxxx
I: 16
D: Mon, 01 Mar 2007 00:00:00 GMT
XI: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
这是用户B收到第五步发出的即时消息后回过来的RESPONSE,结果是OK,其中XI这个消息头域的MessageID。
第七步:111.111.111.111:1111 >>>>>>>> 221.130.45.203:8080
B fetion.com.cn SIP-C/2.0
F: 123456789
I: 16
Q: 3 B
T: sip:987654321@fetion.com.cn;p=xxxxx
这是用户A开始关闭聊天窗口准备结束聊天了,向用户B发出了一个BYE的SIP请求消息。
第八步:111.111.111.111:1111 <<<<<<<< 221.130.45.203:8080
SIP-C/2.0 200 OK
Q: 3 B
T: sip:123456789@fetion.com.cn;p=xxxx
I: 16
这是最后用户B对对用户A发出的BYE的回复。
在用户B那边,整个交互过程跟用户A这边对应,用户A在发出INVITE,要求和B会话,而用户B这边则是回应邀请。
那发短信是怎么样的呢?也基本差不多,如发一个内容为test的短信到用户B时的SIP Message请求消息是这样的:
111.111.111.111:1111 >>>>>>>> 221.130.45.203:8080
M fetion.com.cn SIP-C/2.0
F: 12345678
I: 16
Q: 1 M
T: sip:987654321@fetion.com.cn;p=xxxx
N: SendSMS
L: 4
test
以上分析都是飞信通过TCP直连方式工作时的情况,飞信通过HTTP直连呢?工作过程跟上面完全一样,不同的是,连接的是221.130.45.203:80,协议是HTTP,采用的POST请求是:
POST /ht/sd.aspx?t=s&i=2 HTTP/1.1
POST的数据分就是上面一样的SIP消息了。
飞信发送通过即时消息聊天时,整个过程就是这样子。通过这个分析,我们也可以看到,飞信聊天时整个内容是既未加密又未变换的(MSN还作了点点变换),因此聊天过程是可以被截取的,因此通过飞信聊天是会被别人偷听的,就如同去年MSN曝出的监听事件一样。那这个问题是可以解决的吗?当然是可以的,其实扩展SIP的Message方法时,RFC中就提到这一点,我想飞信目前只是没去做,一旦这个问题暴露出来,对聊天内容进行加密,甚至是公开密钥的端到端强加密,都是可能和容易的,只不过不知道会不会不符合监管要求,呵呵:)。
补记:发现了吗?上面分析中提到的URI(在Header Field "To"中)中都带着小尾巴:p=xxxx,这里的xxxx是个数字,怎么来的呢?文中我没解释,因为我还没完全搞清楚,下回再说。
分享到:
相关推荐
飞信交互过程飞信交互过程飞信交互过程飞信交互过程
PPPoE协议详解,详细描述PPPOE协议的交互过程
SMB报文的交互过程
大家都知道要实现基本的流媒体传输,需要有基本的流媒体协议相联系,其中RTSP就是流媒体控制协议,在此用c#实现了RTSP交互的过程!
Libnids(Library Network Intusion Detection System)网络入侵检测开发包,基于libpcap和libnet开发,是仿照linux内核中的TCP/IP协议部分而实现的。由于Libnids支持TCP数据流的重组,所以我选择LIbnids做开发。 本次...
使用并熟悉Wireshark分析协议的界面环境(菜单、工具条和各种窗口等)。 3. 掌握使用Wireshark捕捉协议包。 4. 掌握保存抓包数据的方法。 5. 掌握过滤数据包的方法。 任务2:分析数据链路层帧结构 一、实验目的...
SAML协议的交互将在这二者之间展开。项目启动之后,访问如下网址: http://localhost:8080/webprofile-ref-project/app/appservlet 这是一个SP的模拟,第一次访问该网址时将会跳转到IDP,进行认证流程。
前端: 用Dcloud 的 uni-app全系,基于vue.js和...聊天窗口:可以发生文字消息、图片消息、表情;图片可以预览。 站内公告:在顶部显示可以及时显示后台发布的公告。 添加朋友:可以搜索对方的帐号名称然后添加到通
WiFi-WPS的详细交互过程解析,详细讲述M1-M8各个帧的功能与特性以及PBC和PIN码等方式的wps交互流程,还包括交互过程的帧类型以及各帧字段的含义等,
SSL交互和握手过程 SSL消息按如下顺序发送: 1.Client Hello 客户发送服务器信息,包括它所支持的密码组。密码组中有密码算法和钥匙大小; 2.Server Hello 服务器选择客户和服务器都支持的密码组到客户。 3....
QQ协议分析,包括报文格式、消息类型、报文交互等的分析
顺序图是一种描述时间维度的交互的图形,可以用来展示出用例图的行为顺序,或者用来展示出对象之间的消息发送和状态转换。本资源适合软件工程学习者和考生使用,帮助他们深入理解和掌握顺序图的原理和方法,提高软件...
ADB传输协议与交互指令预研.docx;devices与主机AUTH过程分析.txt;protocol.txt; adb pull命令对应指令数据.txt;adb push命令对应指令数据.txt; 打开adb命令行client命令对应指令数据.txt; 允许PC端adb调试AUTH...
2021《即时通信(聊天场景)交互体验测试规范》
一、实验目的: ... 使用并熟悉Wireshark分析协议的界面环境(菜单、工具条和各种窗口等); 3. 学会使用Wireshark捕捉协议包; 4. 分析俘获的踪迹文件的Ethernet帧结构; 5. 分析IEEE 802.11帧结构。(可选)
QWebEngineView之百度地图:内嵌本地HTML及js数据交互; 实现简单的百度地图加载与Qt结合,并可用js进行交互。
VISDMiner:一个交互式数据挖掘过程可视化系统.pdf
java使用udp协议在控制台聊天。 如果自测,run main和debug main1即可 要是有局域网小伙伴,可以改成相应ip与端口
GA 1277.3-2020 互联网交互式服务安全管理要求 第3部分:音视频聊天室服务.pdf