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:[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.端到端加密 

转自：http://blog.csdn.net/bat603/article/details/1362093