【转】SIP对Instant Message的支持——MESSAGE方法

Instant Message是指用户间实时的短消息通信，这些消息一般都比较简短。IM一般以实时对话的模式使用，也就是说，消息在用户之间的来回传输时延足够小，能够满足用户间实时对话的要求。

    以下是IETF定义的Instant Message系统模型。


图表 1 IETF定义的Instant Message模型

SIP协议中MESSAGE消息的扩展使得SIP能够支持IM通信。既然MESSAGE是对SIP消息的扩展，那么它也就继承了一般SIP请求的一切路由和安全特性。MESSAGE与INVITE不同，本身并不会初始化一个SIP对话。在普通应用中，IM应用像页面消息一样独立存在。MESSAGE可以利用其它SIP请求建立的对话来发送。

u  IM的两种模型

IM应用有页面模型和会话模型两种形式。在页面模型中，消息之间没有直接的联系，每个Instant message相互独立，任何形式的对话只是在用户终端界面显示的不同。与会话模型比较，会话模型有一个直接的对话上下文的联系，并且有明显的开始与结束标志。在SIP中，IM会话与一个媒体会话相关联，这个会话一般由INVITE事务发起、BYE事务终结。

每种模型都有着重要价值。现在大多数的IM客户段都支持这两种模型。用户既可以向某个联系人发送简单的消息，也可以邀请一个或多个联系人加入到同一个对话中。当用户要发送消息到一个或几个联系人时，可以使用页面模型；同样，在群组聊天等扩展的会话中，会话模型不可缺少。

由于页面模型使用的广泛性，本文只讨论基于页面模型的IM。当然，会话模型再IM中也十分重要。

另外，在SIP对话中传输MESSAGE消息时，必须确保MESSAGE请求的目的地正好是该对话的目的端。这样就限制了IM终端与信令终端的灵活性，要求二者必须统一。显然。这在IM应用中是不能接受的。但令一方面，从应用的角度来说，在SIP建立的对话中发送MESSAGE又是合理的。例如，在一个语音会话中，参与者可能想要发送一条消息给对方，这时会将IM与该会话关联后直接发送。但在实际部署中，不应该单纯地为了关联多个MESSAGE而创建对话。但这并不表示不能使用SIP来创建以IM为内容的媒体会话。

u  MESSAGE消息格式

在MESSAGE消息的使用中，Request-URI一般为接收方的URI。在用户端已经获知接受方的当前位置信息的情况下，Request-URI可以是一个设备地址。MESSAGE消息的消息体可以是任何MIME类型的消息体，包括message/cpim（见RFC3860）格式。由于各个IM协议都要求支持message/cpim格式，使用不同IM协议的各个终端可以就在不使用网关或其它转换器的情况下实现信息的交互。这可以帮助实现不同IM协议终端间安全的端到端通信。

另外，发送端可以通过添加Expires消息头来限制MESSAGE消息的生命周期。如果MESSAGE消息添加了Expires消息头，那么还需要添加Date消息头来标明消息的发送时间，以此来确定MESSAGE消息的超时时间。如果没有Date头域，接收端将以接受到消息的时间为起始来决定超时时间。没有Expires头域的消息不会超时。如果消息在向用户呈现之前超时，则UAS可以根据本地策略来处理超时的消息，例如删除消息、保留消息直到用户阅读。一旦用户阅读了消息，则该条消息超时。如果消息在中转过程中超时，同样根据本地策略来处理超时的消息。

关于即时消息收件箱地址的介绍可查看RFC3861。

MESSAGE请求在到达目的地前可能会穿越一系列的代理，这些代理将使用不同的传输即时协议。过程中每一跳的目的以及地址分配规则可以查看RFC3860。在穿越一些代理过程中，每一个代理会根据可用的路由信息重写Request-URI。

u  对MESSAGE消息的响应

一般来说，MESSAGE的最终接受代理会回复200 OK来表示对同意接收消息，但并不表明接受者已经阅读了该消息。

如果收到对MESSAGE的200 OK响应，发送端将认为消息已经被成功发送至目的地，但并不意味着接收端已经阅读了该消息。

如果接收到的是202 Accepted响应，则表示消息被发送至网关，并被存储转发至其它服务器，由其它服务器来完成最终的消息投递。一个对MESSAGE的2XX响应是不允许携带任何消息体的，同时在2XX消息中不能使用Contact头域。对于一个已经回复了202 Accepted响应的消息来说，还需要其它机制来确保该消息被成功发送至接受端，这里不再详细讨论。

4XX与5XX响应表示MESSAGE消息投递失败，6XX则表示消息被成功投递至接收端，但被接收端拒绝。

对于支持MESSAGE方法的地UAS必须能够接受并显示text/plain类型的消息体，同时也可以支持message/cpim格式。

u  MESSAGE拥塞控制

如上文所述，由于MESSAGE不同于其它SIP请求，MESSAGE请求携带IM媒体流，而其它SIP消息携带的则是关于媒体流的信令信息，而不是媒体本身。这样当呼叫信令与即时消息共享SIP下部结构时，IM流量会影响信令流的正常工作。因此，拥塞控制应该从SIP规范的层次来讨论，而不是作为一个独立的优化策略来讨论。由于MESSAGE与其它SIP方法的不同，对MESSAGE消息也应该特殊考虑。

可能的情况下，MESSAGE请求应该使用有端到端拥塞控制机制的传输协议进行传输，如TCP、SCTP。然而，SIP协议本身并不能禁止下一跳使用UDP传输。

在UAC不能确保每一跳的传输拥塞安全性的条件下，媒体会话外的MESSAGE请求大小不能超过1300字节，除非UAC能确保MESSAGE消息比所有中间路由的最小MTU小200字节。在使用媒体会话传输或间接内容类型的情况下，可以支持更大负荷的传输。

u  MESSAGE实例

下面的消息流给出了从U1到U2的初始IM通信过程，其中U1、U2在同一个域，直接仅仅经过一个代理。




图表 2 MESSAGE消息流

F1 MESSAGE:

MESSAGE sip:[e-mail] SIP/2.0

   Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse

   Max-Forwards: 70

   From: sip:[e-mail];tag=49583

   To: sip:[e-mail]

   Call-ID: asd88asd77a@1.2.3.4

   CSeq: 1 MESSAGE

   Content-Type: text/plain

   Content-Length: 18



   Watson, come here.

F2 MESSAGE:

MESSAGE sip:[e-mail] 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:[e-mail];tag=49394

   To: sip:[e-mail]

   Call-ID: asd88asd77a@1.2.3.4

   CSeq: 1 MESSAGE

   Content-Type: text/plain

   Content-Length: 18



   Watson, come here.

F3 200 OK:

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:[e-mail];tag=49394

   To: sip:[e-mail];tag=ab8asdasd9

   Call-ID: asd88asd77a@1.2.3.4

   CSeq: 1 MESSAGE

   Content-Length: 0

F4 200 OK:

SIP/2.0 200 OK

   Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;received=1.2.3.4

   From: sip:[e-mail];;tag=49394

   To: sip:[e-mail];tag=ab8asdasd9

   Call-ID: asd88asd77a@1.2.3.4

   CSeq: 1 MESSAGE

   Content-Length: 0



参考：

   RFC3428 Session Initiation Protocol (SIP) Extension for Instant Messaging

   RFC2778 A Model for Presence and Instant Messaging