(轉) Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1362093
即時消息(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.端到端加密
