即时消息(IM)指的是近似实时的消息交互。即时消息通常很短,虽然并不要求这样。IM通常用于会话模式,也就是说,消息的交互是一来一回的,并且很快,近似于交互式的会话。
提出了MESSAGE方法,扩展了SIP协议以传送IM消息。由于MSEEAGE是SIP消息,所以它继承了SIP协议所有的路由和安全特性。 MESSAGE用MIME格式的body携带具体内容。MESSAGE本身并不建立dialog;在多数应用里,每条IM消息都是独立的,颇似分页消息。 MESSAGE也可以在dialog内发送。
1.简介
IM的历史。
SIP协议提供了在线功能,也提供了面向会话的通信应用,但还没有提供即时消息功能。
本规范提出了一个新的方法:MESSAGE,用于在body里携带即时消息的内容。
2.适用范围
用SIP传递即时消息,有两种模式:
pager模式,用信令传递IM,消息之间没有明确的联系,或者说“会话”的概念仅存在于用户的想象中。
session模式,用INVITE建立,用BYE结束的一个会话,IM是其中的媒体流。
两种模式都有存在的价值(设想一下腾讯公司QQ的普通消息和UDP直连的对话模式)。本文只关心pager模式。
为什么MESSAGE消息之间不关联。试想一下先创建一个dialog,MESSAGE在dialog内进行传递。这样所有的消息必然走相同的路由,由于 IM消息的流量通常很大,这样势必会引起拥塞问题。另一个问题是,如果MESSAGE必须走in dialog,那么IM的目的地就势必和会话的目的地一 样,而这种限制是不合理的。(阐述发消息的对象可以与打电话的对象不同的事实,所以消息不应该从Dialog中走)
一个MESSAGE走in dialog的例子:voice会话的一个参与者想同其中的一人进行IM交互(即想给正在通话的人发消息),这时把IM和该会话联系在一起是比较合理的。但是纯粹是为了把几个IM联系在一起而让MESSAGE都走in dialog是不允许的。
3.操作简介
当一个人想给另外一个人发IM消息时,构造一个MESSAGE,发出去即可。请示URI可以是SIP URI,也可以是其它类型的地址。要发的即时消息放
在body里。body可以是任何MIME格式。可能用message/cpim会好一点,因为已有的IM系统标准是message/cpim格式。
MESSAGE请求到达目的地之前可能经过多个SIP proxy。
像SIP其它请求一样,收到MESSAGE应回临时应答和最终应答。200-OK只说明消息成功到达了目的地,并不代码用户已经阅读。
MESSAGE不创建dialog。
4.UAC的操作
SIP相关的操作参照rfc3261。
MESSAGE body必须支持plain/text格式。可以选择支持message/cpim格式。
由于不创建一个dialog,所以MESSAGE不应该包含contact头域。
MESSAGE可以在in dialog里发送,此时代表这个消息和某个dialog有关联关系(即发消息的URI为SIP URI)。
最终应答的含义,
200-OK:消息已成功送达目的地,但不保证对方用户已阅;
202-Accept:消息已成功发送到某网关,但不保证网关一定能把该消息送达目的地。
外发proxy有可能把MESSAGE分叉,可以加Expire头域,Date头域表明消息的生存时间。
5.使用IM URI
Request URI,From头域,To头域可以填SIP URI,实在不行也可以填IM URI,此时会有proxy解析成SIP URI。
和路由相关的头域中的URI必须是SIP URI。
6.代理的操作
和SIP相关的操作参见rfc3261,需要注意的是,代理可以对MESSAGE进行分叉(fork)。
7.UAS的操作
和SIP相关的操作参见rfc3261。
200-OK:UAS收到MESSAGE,应立即回200-OK,但是是否把消息的内容显示给用户与本地策略有关 (是不是可以用来制作黑名单功能?) 。200-OK不能带body,,也不能携带Contact头域。
202-Accepted:如果自己不是MESSAGE的最终用户,就回202-Accepted。意味着该MESSAGE会被尽力转发,但不保证一定能到达目的地。
4xx, 5xx :4xx, 5xx表示消息未被成功发送。
6xx :6xx表示消息虽被成功发送,但已被拒收。
支持MESSAGE就必须支持text/plain格式的MIME type。也可以选择支持message/cpim格式。
如果消息携带有Expire头域,就处理超时,否则没有超时的概念。
如果UAS收到消息时该消息已经超时,可以选择处理该消息这和本地策略有关。例如可以选择丢弃,也可以正常显示给用户(标明超时),或采取其它策略。
如果消息不能被正确中继,如何处理该消息也与本地策略有关。
8.拥塞控制
MESSAGE用信令携带媒体,所以流量会很大,需要特殊考虑。
如果可能,MESSAGE最好使用有拥塞控制的传输层协议,如TCP,SCTP。
消息本身的大小不一不要超过1300个字节,除非你知道确切的PMTU大小。
对于不采用Dialog方式的消息,发往同一个目的URI的MESSAGE,如果上一个transaction还没有结束,就不允许发送下一个MESSAGE;而且如果不是路由设置每一跳在传输中采用拥塞控制,用Dialog传送的MESSAGE也禁止这么做。
有人曾建议为了减少拥塞,MESSAGE不必回临时应答。实际上没有必要规定这个。因为很多代理服务器根本就不关心是否是MESSAGE方法,他们只管转发。
9.方法定义
MESSAGE
10.例子
描述User1向处于一个Domain(domain.com)中的User2,发送即时消息的过程,经过一个简单代理Proxy。
| F1 MESSAGE | |
| -----------------〉| F2 MESSAGE |
| |--------------------〉|
| | |
| | F3 200 OK |
| |<-------------------- |
| F4 200 OK | |
|<-------------------| |
User1 Proxy User2
1. User 1向domain.com的服务器发送请求信令F1,
MESSAGE SIP:
[email protected] SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards:70
From: sip:
[email protected];tag=49583
To: sip:
[email protected]
Call-ID:
[email protected]
CSeq: 1 MESSAGE
Content-Type:text/plain
Content-Length: 18
Method type为MESSAGE,使用TCP协议发送(有拥塞控制),Body类型 text/plain,body长度18。
2. 代理Proxy收到请求F1,确认是从domain.com的服务器来的请求,到数据库中查询User2(注册过程中生成数据库),
[email protected]匹配
[email protected],生成信息F2 ,
MESSAGE SIP:
[email protected] SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
received=1.2.3.4
Max-Forwards:69
From: sip:
[email protected];tag=49394
To: sip:
[email protected]
Call-ID:
[email protected]
CSeq: 1 MESSAGE
Content-Type:text/plain
Content-Length: 18
3. User2收到F2,显示,向Proxy产生响应消息F3
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
received=1.2.3.4
From: sip:
[email protected];tag=49394
To: sip:
[email protected];tag=ab8asdasd9
Call-ID:
[email protected]
CSeq: 1 MESSAGE
Content-Length:0
直接回应 没有Body(200-OK不能带body,,也不能携带Contact头域)
4. 服务器收到F3 去掉最顶端的Via,向下一个Via标识的地址(User1)发送F4
SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:
[email protected];tag=49394
To: sip:
[email protected];tag=ab8asdasd9
Call-ID:
[email protected]
CSeq: 1 MESSAGE
Content-Length:0
11.安全性考虑
多数情况下,SIP请求是用来建立和修改会话的,但MESSAGE方法却用SIP请求传送媒体本身。因此安全性的问题需要特殊考虑。一般还要考虑端到端(end-to-end)的安全性。
11.1.代理认证
11.2.使用SIPS URI
11.3.端到端加密