SIP即时消息 RFC3428
即时消息(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:user2@domain.com SIP/2.0 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse Max-Forwards:70 From: sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 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(注册过程中生成数据库),User2@domain.com匹配User2@User2pc.domain.com,生成信息F2 , MESSAGE SIP:user2@domain.com 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:user1@domain.com;tag=49394 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 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:user1@domain.com;tag=49394 To: sip:user2@domain.com;tag=ab8asdasd9 Call-ID: asd88asd77a@1.2.3.4 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:user1@domain.com;tag=49394 To: sip:user2@domain.com;tag=ab8asdasd9 Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Length:0 11.安全性考虑 多数情况下,SIP请求是用来建立和修改会话的,但MESSAGE方法却用SIP请求传送媒体本身。因此安全性的问题需要特殊考虑。一般还要考虑端到端(end-to-end)的安全性。 11.1.代理认证 11.2.使用SIPS URI 11.3.端到端加密 |