RFC3428补充内容.docVIP

即时消息(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格式。如果消息携带有Exp