即時通訊服務技術主要包括即時訊息(Instant Messaging)與現狀資訊(Presence)技術，目前市場上有各種不同的即時通訊系統，各由不同的業者經營，均採用獨家私屬的通訊協定，所以用戶只能用相同的客戶端軟體才能進行即時通訊...
即時通訊服務技術主要包括即時訊息(Instant Messaging)與現狀資訊(Presence)技術，目前市場上有各種不同的即時通訊系統，各由不同的業者經營，均採用獨家私屬的通訊協定，所以用戶只能用相同的客戶端軟體才能進行即時通訊。
目前由網際網路工程任務小組(IETF)所提倡，主要有兩種標準正在發展中，包括SIMPLE(SIP for Instant Messaging and Presence Leveraging Extensions)和XMPP(eXtensible Messaging and Presence Protocol)。本文將對此兩種技術規格在架構、功能特性、通訊協定方面作一個介紹，並將此兩種技術規格作一比較。
「即時訊息」與「現狀資訊」即時通訊服務的主要特色在於可以知道誰正在線上，而得以傳送即時訊息與之交談；或是誰正忙碌或會議中，你可能就必須選擇其他溝通方式，像傳送簡訊或電子郵件等。另外一個特色在於訊息的傳送具即時性，有別於以往訊息系統(像電子郵件、簡訊、多媒體訊息等)採用先儲存然後轉發的機制。
目前全球主要即時通訊服務市場主要有AOL的「AIM Instant Messenger」、ICQ、微軟的「MSN Messenger」、Yahoo的「Yahoo Instant Messenger」、以及在中國大陸廣受歡迎的「QQ」，各由不同的業者經營，均採用獨家私屬(proprietary)的通訊協定，在功能上並沒有很大的差異，而在市場上各有各的擁戴者，但可確定的是用戶(subscriber)間只能在相同的即時通訊系統上才能進行通訊，不同系統之間是無法互通的。這樣的影響造成使用者在選擇即時通訊系統時，並不能僅止於個人的喜好和習慣，而必須考慮到其他同樣使用即時通訊系統的朋友、家人、同事等的選擇，因此也許您已經注意到有些人會在同一台電腦上安裝多套以上的即時通訊系統，以方便與散落在各處使用不同即時通訊系統的朋友聯絡。
為了讓不同即時通訊系統達到互通性(interoperability)，目前可能的解決方案有下列三種方向：1. 開發具多重通訊協定(multiple protocol)的用戶端軟體，如Trillian、Gaim等軟體，使用者可以將其所有分散於各不同即時通訊系統的親朋好友，透過此種軟體來統一管理。事實上你可以將此種軟體看成是一個具有多個即時通訊協定的綜合體，訊息在溝通時乃依照該聯絡人是屬於哪一個即時通訊系統便用哪一種協定來溝通。如此使用者必須選用此類軟體，而放棄其原本熟悉的操作介面。而且此類軟體可能面臨必須一直改版以適應新的或修改過的私屬性協定，不是長久之計。
2. 開發信息閘道器(Messaging Gateway)，如Jabber Component、iFollow Messenger Gateway等，讓使用者不需改變用戶端軟體即可透過此信息閘道器來轉換通訊位址、訊息格式和傳輸協定等，與不同即時通訊系統的使用者溝通。此信息閘道器應搭配某個即時通訊系統一同運作。
3. 訂定通訊協定標準，如IETF SIMPLE(SIP for Instant Messaging and Presence Leveraging Extensions)、IETF XMPP( Extensible Messaging and Presence Protocol )、OMA IMPS(Open Mobile Alliance Instant Messaging and Presence Service)等，讓有興趣提供即時通訊系統的服務開發者或供應商有依循標準，且可達到最佳之互通性。訂定標準通訊協定為一個必然趨勢，因此開發標準化的即時通訊系統並搭配信息閘道器與既存的即時通訊系統互通才是一個正確方向。近幾年來國際上已有相關標準組織進行即時通訊協定的標準化討論與制定，目前由網際網路工程任務小組(IETF)所提倡的主要有兩種標準正在發展中，包括SIMPLE和XMPP。
如圖1所示，IMPP為即時訊息與現狀資訊系統提供一個抽象化、一般化的模型，並發展即時訊息與現狀資訊系統共同的語言(如Presentity、Watcher、Principal等)，爾後的SIMPLE與XMPP則是遵照IMPP定義的架構、相關需求與資料格式，各自制訂即時訊息與現狀資訊系統的通訊協定標準。
由IMPP WG所產出的標準RFC文件共有8篇，分別是：
‧A Model for Presence and Instant Messaging(RFC 2778)
‧Instant Messaging/Presence Protocol Requirements(RFC 2779)
‧Date and Time on the Internet：Timestamps(RFC 3339)
‧Common Profile for Presence(RFC 3859)
‧Common Profile for Instant Messaging(RFC 3860)
‧Address Resolution for Instant Messaging and Presence(RFC3861)
‧Common Presence and Instant Messaging：Message Format(RFC 3862)
‧Presence Information Data Format(RFC 3863)
RFC 2778為制訂即時訊息與現狀資訊系統抽象化模型的標準文件，其包含定義相關元件與元件之間的行為，最重要的是訂定共同語言。RFC 2779則制訂即時訊息協定以及現狀資訊協定的相關需求，例如基本行為、認證加密與資料格式等。CPIM定義即時訊息協定的共同訊息格式，以及訊息傳遞中必要的資訊，並且描述通訊協定的操作與元件之間的行為。CPP則是定義現狀資訊協定的共同訊息格式、必要的資訊以及通訊協定的操作與元件之間的行為。由於 CPIM與CPP強調的是互通性，因此僅定義基本且必要資訊，若傳遞特定功能訊息或額外訊息，則不會對應至CPIM或CPP。由於CPIM和CPP提出與傳輸協定無關的即時訊息與現狀資訊之共通標準規範，因此在不同即時通訊服務協定系統互通上扮演中介的角色。
SIMPLE WG成立於2000年末，由幾家國際大廠如Dynamicsoft、Microsoft、Cisco等提案，選定SIP為即時訊息與現狀資訊的基本通訊協定，然後進行討論並制訂相關的SIP標準延伸。
提案者認為將SIP導入至即時訊息與現狀資訊系統是一件非常自然的事情，這是由於SIP的天性所致。SIP為IETF制定一種傳遞信號(signal)的通訊協定，主要用以協商、管理與終止媒體對話行程(media session)，此種媒體對話行程是由特定地資料傳送通訊協定來完成，例如RTP(Real-time Transport Protocol)。一般而言SIP是用來建立語音通話，並利用SDP(Session Description Protocol)來交換對話兩端彼此的能力，一旦協調好後，利用RTP傳遞語音封包。但標準中並沒有規定SIP只能用於語音通話的建立，它並不依賴特定的底層媒體，或者對話行程的種類。因此當訊息也算是一種媒體時，使用SIP就再自然不過。而且SIP在網路通訊的世界裡，已經算是被廣泛使用的通訊協定，其已經具備註冊(Registration)與認證(Authentication)的功能。
SIMPLE致力於符合RFC 2778的架構，並且依據RFC 2779的需求，制訂出一套完整的通訊協定，同時資料格式也會與CPIM相容。更重要的是，不會改變SIP原本的行為。
將SIP導入至現狀資訊系統，有一個優點是可利用SIP原有的基礎建設，且不會變更SIP原有的架構。SIP WG已經制訂了事件架構(Events Framework)，並訂定兩個SIP延伸訊息：SUBSCRIBE/NOTIFY，可用來訂閱現狀資訊和取得狀態改變通知。
圖2為一個Peer-to-Peer的現狀服務架構，其中：1.Bob與Alice所使用的裝置稱之為Presence User Agent，在SIP架構下稱為User Agent(UA)，負責發送與接收SIP訊息。2.SIP Network負責將SIP訊息繞送。當Bob欲得知Alice的現狀資訊時，先送出SUBSCRIBE訊息給Alice，Alice可選擇接受 (Accept)或拒絕(Reject)Bob成為她的Watcher，若選擇接受，則Alice往後的現狀資訊都將利用NOTIFY訊息通知Bob。
圖3為一個client-server的現狀服務架構。其中Presence Agent為SIP Registrar，亦為Presence Server，負責：1.SIP UA的登入與認證。2.接收其他UA的SUBSCRIBE訊息，與發出NOTIFY訊息。3.現狀資訊的管理與彙整。在圖3中，Alice所有可提供現狀資訊的裝置，都會透過Presence User Agent送出REGISTER訊息至SIP Registrar，以進行登入與認證；並透過PUBLISH訊息，將現狀資訊發佈至Presence Agent。而當Bob想要得知Alice的現狀資訊時，會送出SUBSCRIBE訊息，並經由SIP Network繞送至Alice的Presence Agent。Presence Agent可以使用XCAP或其他通訊協定，取得Alice對此一訂閱(subscription)要求的授權。Alice可選擇接受(Accept)或拒絕(Reject)Bob成為她的Watcher；若選擇接受，則Presence Agent會將Alice往後的現狀資訊利用NOTIFY訊息通知Bob。
即時訊息服務的架構如圖4所示，當Alice已經登入至Registrar，且Bob也已經成為Alice的Watcher時，那麼Bob即可利用SIP MESSAGE訊息與Alice進行即時通訊。
今年8月以前，SIMPLE WG並未出版任何一篇RFC，直到8月底才一口氣有3篇成為正式RFC文件，包括RFC 3856、3857和3858。不過在SIP WG中，有部分已出版的RFC已用在SIMPLE的架構裡。
1.現狀資訊服務之通訊協定：現狀資訊服務通訊協定的相關文件，包含有：
‧SIP-Specific Event Notification，RFC 3265：制訂Events Framework以及SIP延伸訊息─SUBSCRIBE/NOTIFY。
‧A Presence Event Package for the SIP，RFC 3856：制訂Events Framework的Event Package-presence。
‧A Watcher Information Event Template-Package for SIP，RFC 3857：制訂Events Framework的Event Template-Package-winfo。
‧An XML Based Format for Watcher Information，RFC 3858：制訂winfo事件的資料格式，並使用XML描述。
‧A SIP Event Notification Extension for Resource Lists：Resource Lists可用Events Framework得知所有Resource的狀態，本篇草案即在制訂相關的行為、操作與格式。本篇已被IESG同意提交標準，將成為RFC。
‧An Event State Publication Extension to the SIP：制訂SIP延伸訊息─PUBLISH。本篇已被IESG同意提交標準，將成為RFC。
2.即時訊息服務之通訊協定：即時訊息服務通訊協定的相關文件，包含有1.SIP Extension for Instant Messaging，RFC 3428：制訂SIP延伸訊息─MESSAGE。2.Indication of Message Composition for Instant Messaging：提供對方「正在寫入訊息」的指示，並制訂使用SIP MESSAGE來傳遞此指示的方法。本篇已被IESG同意提交標準，將成為RFC。
在2003年之前，SIMPLE最為人詬病的就是在即時訊息協定的相關討論不夠深入，僅止於「呼叫模式的SIP延伸訊息─MESSAGE。所謂的呼叫模式，就像簡訊一樣，是把文字包在一個MESSAGE訊息傳遞，然後進行1對1或1對多的交談。這種模式很簡潔，但相對地要達到如會議、保留或轉接等複合式對話功能時，就顯得捉襟見肘。於是SIMPLE WG提出MSRP(Message Session Relay Protocol)以解決這方面的問題。
由於使用者可提供現狀資訊，以及可進行即時通訊的裝置越來越多。SIMPLE WG也積極進行XCAP(The Extensible Markup Language Configuration Access Protocol)的制訂，以管理使用者的設定資料，如個人資料、好友名單、電話簿以及現狀資訊的授權等。將MSRP及XCAP分述如下：
1.MSRP：MSRP可稱之為「會議模式(Session Mode)」所使用的即時訊息通訊協定。這如同SIP處理語音一樣，語音通道是透過SIP傳遞信號，然後利用SDP交換能力資訊，最後建立RTP連線，語音封包則是在RTP連線上傳輸。MSRP的角色就如同RTP，只是傳輸的內容為文字訊息本身，如此可以避免每則訊息均須包含一長串的SIP headers。會議模式的優點除了可減少中介節點像SIP Proxy的負荷外，最大好處就是讓即時訊息的功能更完整，並且讓SIP強化自身的優點，以支援複合形式的交談功能，如結合影像、語音、文字訊息等的通訊方式。
2.XCAP：為一種用以存取使用者設定的通訊協定，使用者可將特定的設定資料用XML的形式儲存於Presence Server，並定義存取的方式。如此一來，即可支援使用者多個裝置同時提供現狀資訊與進行即時通訊。XCAP是利用HTTP來完成這些事情，亦即利用 HTTP的URI以XPATH語法來指定XML的元件、參數與路徑，再以HTTP的GET、PUT、DELETE等方法達到存取目的。
目前在SIMPLE WG討論的XCAP應用有三種：一個是Presence List的管理，提供好友名單的存取與管理功能；一個是Presence Authorization Rule的管理，就是設定使用者的現狀資訊可提供給誰，以及何時取得權限管理等相關設定；另一個為現狀資訊設定，提供使用者在離線狀態或隨時也可以設定其相關現狀資訊。
另一個符合IMPP規範的IETF標準是可延展訊息與現狀資訊協定(XMPP)。XMPP是一個XML-based的協定，它繼承了在XML環境中靈活的延展性，因此能夠表示任何的結構化之訊息。
XMPP WG雖然於2002年末才成立，但XMPP最初是起源於Jabber技術，該技術是作為一種即時通訊系統解決方案，用以傳輸(near)real- time的訊息與現狀資訊，並由Internet上open source團體開發推廣。Jabber技術的第一個產品便是一個非同步(asynchro-nous)與擴充性高的即時訊息與現狀資訊系統之服務平台，提供與AIM、ICQ、MSN或Yahoo類似的即時通訊系統功能。並且Jabber乃為一open source計畫，具有開放、自由且容易瞭解的特性，目前在不同平台上(如Windows、Linux、Java VM等)已有許多的open source實作產品，包括Jabber server、client與開發程式庫等。同時在2002年末由Jabber software基金會於IETF成立XMPP WG公開討論相關技術，致力於XMPP標準化，此基金會成員也成為XMPP核心草案的作者群。因此Jabber使用的核心通訊協定便是以XML為基礎的 XMPP，故Jabber的擴充性相當高，且容易與third-party產品整合。XMPP WG已於今年10月完成其所有草案規格文件，正式公開成為RFC文件，換句話說此WG任務已達成，因此WG已經結束。
Jabber網路拓璞架構與電子郵件系統類似，每一個client都需要有一個本地server用來接收發送訊息，client與server間使用 TCP socket且port為5222所建立而成，而server與server之間亦可以透過port為5269來互相傳遞訊息與現狀資訊。在此 client-server模式中，所有的訊息以及資料都必須透過server才能到達其他client端。儘管client端之前可以直接建立某些傳輸通道，但是，這些連接的通訊協商最初也是透過Jabber server完成的。因此，在互連網路中，可以同時存在於許多個Jabber server，並且各個server獨立工作，各自擁有自己的client。任意兩個server只要能夠互相連絡到，即能互相溝通，並傳遞訊息。
由於client帳號是與server相關，因此，client ID的形式與電子郵件地址類似，[node@]domain [/resource]，此稱之為JID(Jabber ID)。Domain name是主要識別依據，用以表示Jabber server，node表示client名稱，resource為一個可選擇的識別，用來加以描述client的資訊，例如client的位置或所使用的設備。
Jabber架構下，Jabber server主要負責的工作有：1.處理Jabber client的connections以及直接與client相互溝通。2.與其他Jabber server相互溝通。3.處理client註冊、認證、現狀資訊、好友名單以及離線訊息儲存等等功能。Jabber client主要負責的工作有：1.與Jabber server建立溝通連線。2.parse及interpret XML stream。3.了解Jabber核心資料型態。
Jabber使用的核心通訊協定即為XMPP。由IETF XMPP WG所制定產出的RFC技術標準文件共有4篇：
‧Extensible Messaging and Presence
Protocol(XMPP)：Core，RFC 3920。文中主要定義了XMPP的核心，包括交換XML結構化資料的elements、錯誤處理方法、選用SASL為認證方法及選用TSL為加密技術。
‧Extensible Messaging and Presence Protocol (XMPP)：Instant Messaging and Presence，RFC 3921。文中主要定義基於XMPP的即時訊息與現狀資訊協定，包括即時訊息與現狀資訊溝通的XMPP stanzas等以及定義關於符合RFC2779的內文，例如contact lists、privacy lists及presence subscriptions管理。
‧Mapping the Extensible Messaging and Presence Protocol(XMPP)to Common Presence and Instant Messaging(CPIM)，RFC 3922。文中主要定義出XMPP系統與CPIM相容系統中即時訊息與現狀資訊的轉換，包括位址轉換以及XMPP elements和attributes與CPIM headers和PIDF objects的轉換。
‧End-to-End Object Encryption in the Extensible Messaging and Presence Protocol(XMPP)，RFC 3923。文中定義了在XMPP之下end-to-end object signing和encryption方法。
XMPP架構中，兩個節點間所建立的session是利用＜stream＞tag封裝起來的XML文件，如圖6所示。並使用＜/message＞、＜/presence＞以及＜/iq＞之XML「chunks」來達成Jabber的服務溝通。一個message chunk可能包括底下幾個attributes：
‧to：描述將接收此message chunk的位置。
‧from：描述此message chunk的傳送者。
‧id：一個可選擇的唯一識別，目的為了追蹤此messages。
‧type：一個用以描述交談內容的可選擇項目。
而message chunk亦可包含底下child ele-ments：
‧body：message的內容。
‧subject：message的主題。
‧thread：隨機的字串，用以追蹤交談的thread。
‧error：錯誤。
‧any properly-namespaced child element。
一個presence chunk可能包括底下幾個attributes：
‧to：描述將接收此presence chunk的位置。
‧from：描述此presence chunk的傳送者。
‧id：一個唯一識別，目的為了追蹤此presence。
‧type：描述狀態，現狀資訊要求，subscription要求。
而presence chunk亦可包含底下child ele-ments：
‧show：描述一個實體的狀態或是資源。
‧status：一個可選擇的natural-language，用以描述狀態。
‧priority：連結資源的優先權等級，為一非零的整數，零為最低等級。
‧error：錯誤。
‧any properly-namespaced child element。
Info/Query(IQ)是一種HTTP-like的「要求─回應」機制，確保一個實體產生一個要求以及從另一個實體上接收回應訊息，如圖7所示。一個iq chunk可能包括底下幾個attributes：
‧to：描述將接收此IQ chunk的位置。
‧from：描述此IQ chunk的傳送者。
‧id：一個可選擇的唯一識別，目的為了追蹤此interaction。
‧type：Specifies a distinct step within a request-response interaction。
而iq chunk中的type亦可包含底下attributes：
‧get：資訊的要求。
‧set：針對資料進行設定或修改。
‧result：回應一個成功的get或set要求。
‧error：錯誤。
為XMPP於Jabber client和Jabber server之間一個簡單完整stream例子。此外，Jabber為了達到與其他即時通訊系統互通，而開發了許多與其他即時通訊系統互連的閘道器，例如與AIM/ICQ互連的「AIM-t」、與Yahoo!Instant Messenger互連的「Yahoo!Transport」和與MSN互通的「MSN-tng」等等。因此只要加裝這些閘道器，Jabber client就能與其他即時通訊系統下的client進行溝通傳遞訊息。
目前SIP/SIMPLE及Jabber/XMPP兩大即時訊息與現狀資訊通訊協定的標準正廣泛的被採用，其規範的通訊協定及架構各不相同，因此各有其本身所擁有的優點以及存在的問題，在市場上也各有各的擁護者。
因SIMPLE可運作於client-server與peer-to-peer架構下，實際執行方式彈性非常大，應用的 範圍更因此比較廣，例如可以在ad-hoc網路下利用peer-to-peer方式建立一個即時訊息與現狀資訊服務系統等等。也因為其使用SIP為傳輸協定，存在著SIP架構所留下的包袱，包括存在著許多server，例如proxy server以及redirect server。當然，此一問題由另一個角度來分析將變成SIMPLE優點之一。在此架構下，SIMPLE server只是SIP server的一部分，也許是proxy server或是redirect server，不管是存在於那一個server上，因其只是建設於SIP基礎架構上，不必多花額外的server建置成本。
然而，SIP上的NAT穿透及firewall的問題，同樣也是存在於SIMPLE上；而由於Jabber/XMPP是使用client-server為基礎架構，在運作上需要先由Jabber client對Jabber server進行連結，因此並沒有如同SIP網路當中的NAT穿透及firewall問題存在，但是此Jabber server必須要有一個public address。
剛開始Jabber/XMPP批評了SIP/SIMPLE中並無壅塞控制(Congestion control)的觀念，這將有可能造成網路被即時訊息與現狀資訊服務的傳輸所霸佔。然而這只是當時RFC 2543所提出的SIP版本中的問題，於新版的RFC 3261 SIP版本當中已有規範壅塞控制了。
目前ITEF SIP WG也正努力推動於較早的SIP client支援具有查知何時需要壅塞控制的診斷功能；相較於Jabber/XMPP就沒有此一問題的存在。
SIP/SIMPLE另一個被Jabber/XMPP批評的問題為頻寬使用問題。他們提出SIMPLE因為將即時訊息資料堆疊於SIP當中，如此一來，每當人們傳送一則即時訊息時，就存在於SIMPLE handshake情況。然而，當持續傳送短訊息時，SIMPLE長時間的handshake將變成很沒效率，且增加中介節點像SIP Proxy的負荷。同時由於每則訊息均須包含一長串SIP headers，使得傳送訊息所使用的頻寬也較Jabber/XMPP多許多。舉例來說，當SIP/SIMPLE傳送一個Hello的即時訊息共需要使用 268bytes，如圖8所示，而一個NOTIFY的現狀資訊訊息共需要使用602bytes，如圖9所示；反觀Jabber/XMPP在即時訊息則低於 100bytes，如圖10所示，現狀資訊則只需要使用67bytes，如圖11所示。
很明顯的兩種標準協定都有其優點及存在的問題，然而目前各WG也針對其本身的問題提出一些新的解決方法來補強標準本身的完整性，例如SIMPLE提出 MSRP來支援複合型態對話的功能以強化SIP本身的優點。而Jabber/XMPP也正進行peer-to-peer的方式進行問題的討論與提出解決方法。由此可見，不管何種標準，都致力於其即時訊息與現狀資訊服務功能更加完善，並期望被廣泛的採用。至於服務開發者到底該決定依循那一種標準，並不是 IETF組織的責任，而是完全取決於市場上的反應與競爭，正所謂適者生存。像Microsoft、IBM和SUN均已開發SIP/SIMPLE based的即時通訊服務產品，可說是為SIP/SIMPLE背書；而Jabber、France Telecom、HP及一些中小企業則採用Jabber/XMPP為其產品標準。
電通所在即時訊息系統與現狀資訊的開發規劃上，除了將與電通所自行開發的SIP-based IP-PBX系統整合，以提供企業用戶包括語音和即時訊息完整的VoIP服務，並解決防火牆和NAT穿透的問題外，也將佈建於3GPP IMS(IP Multi-media Subsystem)核心系統上之應用服務；在系統建置上，除了包括3GPP IMS核心系統，如CSCF(Call Session Control Function)、HSS、和User Agent外，並建立應用伺服器(App-lication Server)來提供SIMPLE-based即時訊息與現狀資訊服務。主要運作是透過CSCF進行使用者註冊、認證、訊息繞接，並利用服務驅動 (Service Triggering)機制與應用服務伺服器溝通以支援即時通訊服務。而IP-PBX Call Server將提供話務建立與3rd party話務控制功能，並將話務狀態主動通知即時訊息與現狀資訊服務系統。至於為何我們選擇SIMPLE通訊規格為開發標準，主要還是在於考量下世代無線通訊(3G/B3G)之核心網路架構與其採用SIP為訊號傳輸標準。
就整體架構而言，我們也將提供開放性標準且易用的服務開發通訊介面給應用服務商，如XML/HTTPS，透過後端即時訊息與現狀資訊伺服器和名單管理伺服器，來查詢取得現狀資訊、傳送接收即時訊息服務以及好友名單管理等，因此得以在資料網路或電信網路上快速地建立具Presence-enabled特性多樣且新穎的加值服務。例如即時通訊客服中心系統(IM Call Center)，用戶可登入該系統查詢目前所有客服人員線上狀態，並透過即時訊息與客服人員交談，以即時快速地獲得幫助。若當某用戶所喜愛或習慣的客服人員正忙線時，該用戶可以得知其線上狀態，並進行預約，當客服人員一有空就立即通知該用戶，並進行連線即時交談；此外，具現狀資訊知覺(Presence- aware)的拍賣網站也是一項人性化的加值應用。我們相信人與人之間的即時互動將越來越被重視與推廣。
此外，在考量與既有網際網路或行動通訊網上不同即時通訊系統間的互通性上，一個具備多重通訊協定轉換之信息閘道器將被規劃(圖12)，用以轉換通訊位址、訊息格式、和傳輸協定等。在設計理念上，此訊息閘道器以IMPP所定義之共同現狀資訊與即時訊息規格(CPIM)為中介格式，負責將接收到的訊息格式先轉成CPIM，再依目的地即時通訊系統的標準，將CPIM轉成其對應的格式。如此可進行包括SIMPLE、XMPP、OMA SSP、Oscar、Yahoo、MSN等不同通訊協定與訊息格式的互轉，以達到網際網路、行動通訊網路上不同即時通訊系統的互通。不過，不同通訊協定與資料規格的轉換當然不可能十全十美，在互轉的過程中，一些屬於比較私有性的特殊加值功能可能因此而喪失無法使用。
電通所在SIP和SIMPLE此領域之相關基礎技術已累積不少研發經驗，包括像是SIP Protocol Stack、SIP Proxy Server的設計開發，先後與Siemens、Alcatel、Radvision、Dynamicsoft等國際大廠完成 Interoperability測試並獲得肯定。另外，在2004年8月電通所主辦的15th SIPit中，已經與IBM、Nokia Research Center、Inet等國際大廠完成SIMPLE互通測試。
未來Presence技術不論在網際網路、無線行動網路、乃至下世代無線通訊網路都將成為核心技術，提供現狀資訊的伺服器(Presence Server)不再只是一個應用服務伺服器而將是核心網路的一員，透過開放性標準介面或是OSA Gateway等技術，使得具Presence-ware特性的多樣化且新穎的加值服務將一一呈現在你我生活之中。
目前XMPP已經完成其所有草案規格文件討論，共計有4篇技術規格正式公開成為RFC文件，這一點SIMPLE顯然落後許多。但眾所皆知下世代無線通訊 (3G/B3G)之核心網路架構將演進成為全部利用IP技術之All-IP網路，選定SIP通訊協定作為訊號溝通介面標準，並採用以SIP為主的多媒體通訊話務控制技術，作為各異質網路間的通訊標準協定。而SIMPLE為SIP標準的延伸，因此3GPP在制定行動現狀服務通訊規格標準時除了提出其網路系統架構外，對於系統內部的服務邏輯與相關通訊介面將採用SIMPLE。此外，專為無線行動通訊協定制定標準的OMA國際標準組織，過去一直以OMA IMPS為其行動現狀服務系統標準，但該組織在2003年10月成立PAG，也開始討論並考慮用SIMPLE為其行動現狀服務系統。所以筆者確信在下世代 3G/B3G無線通訊多媒體服務技術中，Presence Service將以SIP/SIMPLE技術為核心，再透過信息閘道器與不同的即時通訊協定系統互通，而建構出完整、標準化且具互通性的即時訊息與現狀資訊核心系統。