移動網(wǎng)絡推送業(yè)務技術報告——華為

1、yd/t 移動網(wǎng)絡推送業(yè)務技術報告ics 19目 次1 業(yè)務概述31.1 push安全需求31.2 系統(tǒng)元素52 業(yè)務特征62.1 pap62.2 push ota協(xié)議82.3 push特定的媒體類型92.4 尋址102.5 安全考慮123 push 代理網(wǎng)關服務133.1 概述133.2 ppg 的操作133.3 客戶端尋址214 push訪問協(xié)議244.1 概述244.2 pap協(xié)議處理過程分析244.3 pap尋址284.4 消息格式294.5 控制元素和屬性314.6 版本控制424.7 能力協(xié)商454.8 pap 參考信息454.9 舉例514.10 基于http的pap535 pu

2、sh ota 協(xié)議545.1 概述545.2 協(xié)議變量545.3 wsp上的push ota協(xié)議（ota-wsp）555.4 http上的push ota （ota-http）625.5 sip上的pushota協(xié)議（ota-sip）805.6 會話初始請求966 push 消息1056.1 概述1056.2 push 消息定義1066.3 代理規(guī)則1097 push客戶端與應用接口1107.1 概述1107.2 push客戶端-應用接口（push-cai）定義1107.3 安全考慮113附錄a （資料性）114附錄b114（資料性）114i1 業(yè)務概述1.1 push安全需求本技術報告定義與

3、push業(yè)務相關技術及安全相關的安全要求。push技術允許業(yè)務的使用者能接收推送的數(shù)據(jù)到他們的移動客戶端上。最初一個用戶可以去瀏覽push發(fā)起者pi維護的網(wǎng)頁。pi將提供業(yè)務給用戶。一個push業(yè)務的例子可以是本地的天氣預報業(yè)務，pi每天早上推送本地天氣預報到用戶的客戶端。 push的結構定義了三個實體：push業(yè)務發(fā)起者pi， push代理網(wǎng)關ppg和客戶端。當推送無連接的內(nèi)容到用戶的客戶端時，pi與ppg使用pap協(xié)議進行交互。ppg依次編譯push消息，并經(jīng)過ota協(xié)議發(fā)送到用戶的客戶端。push的安全方面的定義當前還不能滿足行業(yè)中各類提供wap push業(yè)務供應商的安全需要。因此，定義

4、push的各種安全需求是必要的。最終的目的是為了在pi與客戶端之間有一個完整的安全鏈，這樣用戶將可以完全相信客戶端將收到的push消息是來自可信任的發(fā)起者的。圖 1 push框架上圖展示了 push框架中的四個實體。不同實體間的安全/信任關系是push 安全的關鍵方面。這些關系及相關的關鍵問題有： 用戶應能夠信任pi傳遞的內(nèi)容是其請求的內(nèi)容。 用戶應能夠信任ppg傳遞的內(nèi)容是其從pi請求的內(nèi)容，并且用戶支持相應的push-ota的操作。e.g. 會話初始請求。 pi應該能夠信任ppg不會對push內(nèi)容做目標push客戶端及push-ota協(xié)議需要轉(zhuǎn)化的格式之外的任何修改。pi和ppg之間的交互

5、一般將會在面向連接的協(xié)議上發(fā)送，e.g. .http并且能夠使用已經(jīng)建立的internet安全協(xié)議，如ssl等，來確保保密性，完整性和鑒權。ppg與客戶端的交互按以下兩種方式進行： 面向無連接push 面向連接push面向無連接push可以使用ota方法發(fā)送，最常用的為sms。當前，當使用面向無連接的push時，未陳述安全問題。當使用面向連接的push時，各自承載層使用底層的安全協(xié)議，例如如果http協(xié)議則使用ssl。在nat和公共ip地址的終端情況時將要注意安全相關問題。1.1.1 威脅分析安全風險解釋：l 未授權的會話初始：嘗試使一個設備與一個未授權的ppg建立一個push會話（通過sir

6、）。這個未授權的會話發(fā)起可能引發(fā)攻擊，導致用戶的個人信息（信息盜取）盜取或向用戶發(fā)送垃圾郵件。l sir一般通過sms傳遞，未授權的sir通過ip層上傳遞的風險或許很低，但仍需要驗證。 l 有害的內(nèi)容傳遞：任何破壞用戶業(yè)務或威脅網(wǎng)絡安全的內(nèi)容的傳遞。有害內(nèi)容傳遞的目的可能使業(yè)務中斷，盜取，導致用戶被攻擊或病毒擴散。它可以直接在設備上操作，或欺騙設備或用戶來取回一些有害的內(nèi)容。l 業(yè)務的拒絕：重復push消息的傳遞干擾用戶業(yè)務。業(yè)務拒絕的目的可能為了困擾用戶或騷擾用戶而更換網(wǎng)絡提供商。l 未授權的push：嘗試傳遞未請求的push內(nèi)容。下表表示了當使用push時，不同情景的威脅分析的評估， l

7、高：相對容易實行，盡管可能不常見。網(wǎng)絡阻擋的能力較低。l 中：更多的工作完成l 低：很難意識到，網(wǎng)絡辦法容易實行場景風險類別公共ip地址私有ip地址運營商ip策略或授權的第三方ppg 網(wǎng)絡初始的移動終止sms移動初始的sms開放接入控制未授權的會話初始lowlownonenonehighhigh有害的內(nèi)容傳遞highmediumhighhigh to low (1)highhigh業(yè)務的拒絕highmediumhighhigh to low (1)highhigh未授權的pushhighmediumhighhigh to low (1)highhigh表 1 push威脅分析評估. 有效的接入

8、控制可以大量減少風險。情景解釋：l 公共ip設備地址移動網(wǎng)絡為設備分配公共ip地址。運營商可以提供一個ppg或依靠第三方ppg。 l 私有ip設備地址移動網(wǎng)絡為設備分配私有ip地址。第三方ppg 實現(xiàn)的push傳遞非常復雜，需要私網(wǎng)到公網(wǎng)的地址轉(zhuǎn)換（nat），運營商專門提供一個ppg。l 運營商或授權的第三方ppg指定開放的pi策略ppg不提供特殊的push來源、地址、內(nèi)容類型、或服務質(zhì)量的控制。l 運營商或授權的第三方ppg進行接入控制的pi策略ppg 對push來源、地址、內(nèi)容類型、或服務質(zhì)量提供一些級別的接入控制。l 網(wǎng)絡發(fā)起的止于移動設備的smspush消息由基于網(wǎng)絡的sms源發(fā)起的，

9、可能包含一些其它承載網(wǎng)絡中的不安全來源。沒有根據(jù)sms來源，目的地，或內(nèi)容設定特定的控制。l 移動設備發(fā)起sms移動設備發(fā)起push消息。沒有根據(jù)sms來源，目的地，或內(nèi)容特定的控制。1.2 系統(tǒng)元素push安全需求應在當前push結構框架中提出。pi為在普通web服務器上運行的一種典型的應用，與ppg使用pap通過http連接進行通信。ppg使用push-ota協(xié)議傳遞push內(nèi)容到客戶端。pap基于標準的internet協(xié)議，用來xml表達傳遞指令并且push內(nèi)容可以為任何mime媒體類型。 ppg負責傳遞push內(nèi)容到客戶端。這樣，其轉(zhuǎn)換pi提供的客戶端地址成為 一個移動網(wǎng)絡可以識別的格

10、式，如果客戶端當前不可用時存儲內(nèi)容等。ppg不只完成傳遞消息的功能，它還可以通知pi關于push提交的最終結果，選擇性的取消，覆蓋或為pi請求客戶端能力。 push-ota協(xié)議是完成push框架的一部分，負責從ppg傳輸內(nèi)容到客戶端及其用戶代理。通過http（ota-http），wsp（ota-wsp）或其他協(xié)議實現(xiàn)。ppg為push框架中主要功能實體。其責任包括作為從internet向移動網(wǎng)絡push內(nèi)容的接入點，及隨之相關的所有事情（鑒權，抵制解析等）。ppg為移動網(wǎng)絡的接入點，將執(zhí)行網(wǎng)絡的接入控制策略。例如，push內(nèi)容發(fā)送權限控制。2 業(yè)務特征2.1 pappap協(xié)議為pi推送內(nèi)容到移

11、動網(wǎng)絡的方法，并且能夠?qū)ぶ菲鋚pg。 圖 2 pap框架pap原來設計是獨立于底層傳輸機制。http為首選pap傳輸?shù)膮f(xié)議，其他協(xié)議（例如smtp）可以在未來描述。pap攜帶push 相關ppg使用的控制信息。這些信息使用xml表達。例如，一個新的消息被提交到 ppg， 控制信息和push內(nèi)容都攜帶在mime multipart/relatedrfc2387體中。這意味一個單獨的mime實體被傳輸獨立于操作類型。2.1.1 pap操作 pap 支持以下操作：l push提交（pi到ppg）l 結果通知（ppg到pi）l push取消（pi到ppg）l 之前提交的push消息的替換（pi到ppg

12、）l push操作的狀態(tài)詢問（pi 到ppg）l 無線設備的能力查詢（pi到ppg） push提交push提交消息包含三個實體：控制實體，內(nèi)容實體和可選的能力實體。它們封裝放入一個的multipart/related消息中，從pi發(fā)送到ppg。控制實體為一個xml文件，包含給ppg的傳遞指令，內(nèi)容實體是傳遞給客戶端的。在通過ota傳遞之前，ppg可轉(zhuǎn)換或不轉(zhuǎn)換內(nèi)容實體成優(yōu)化帶寬的形式?？蛇x的能力實體包含的終端能力，該信息以uaprof形式。pi可以包含此實體指示其假設的客戶端能力情況。如果此假設的能力信息與ppg識別的能力信息不一致 ，ppg可以拒絕該消息。 結果通

13、知如果pi請求關于最終傳遞的結果，結果通知消息將從ppg傳遞到pi指定的uri。該消息可以是xml實體，指示傳遞成功或失?。蛻舳瞬豢蛇_，超時等）。push框架的一個主要特點是：pi有可能依賴ppg發(fā)來的響應。當且僅當目標應用已經(jīng)接受push內(nèi)容時，終端才會返回確認。如果不能接受，必須中斷操作，pi知道內(nèi)容不能到達目的地。 push取消該消息是pi給ppg傳輸?shù)膞ml實體，用來取消之前提交的消息。ppg用一個xml實體進行響應，指示取消操作是否成功。 push替換如果pi請求替換一個之前push提交操作中提交的消息，重置可能有兩種情況：新的消息只發(fā)送給那些未接收到原

14、始消息的接受者，或新的消息應發(fā)送給所有的接收者。任何一種情況，對于未被傳遞的接收者的原消息應被取消。 狀態(tài)詢問狀態(tài)詢問是從pi到ppg的xml實體，用來請求之前提交消息的狀態(tài)。ppg用一個包含當前狀態(tài)的xml實體進行響應。 客戶端能力詢問客戶端能力詢問從pi傳遞到ppg的xml實體，請求網(wǎng)絡中一個特定設備的能力。ppg的響應包含一個multipart/related實體，包含兩個部分，第一部分包含請求結果，第二部分包含uaprof格式祖師的設備能力信息。 http傳輸當pap使用http作為傳輸協(xié)議時，信息傳輸使用http post請求和響應方法。當h

15、ttp傳輸成功，http的響應包含202響應碼（已經(jīng)接受待處理），當http處理成功， pap的響應文件可以包含pap錯誤信息， 關于http1.1具體參見rfc2616。2.2 push ota協(xié)議push ota協(xié)議是push框架組成部分，負責將push內(nèi)容從ppg傳遞給客戶端和其用戶代理。它運行在http（ota-http）或wsp（ota-wsp）之上。ota-wsp經(jīng)常用于在ppg和客戶端之間執(zhí)行無連接的push。面向連接的push，使用ota-http或ota-wsp是可選的。圖 3 ota框架2.2.1 ota-wspota-wsp協(xié)議變量構造上為wsp協(xié)議之上簡單的協(xié)議層，可以

16、用于oma定義的任何承載使用。ota-wsp使用由wsp提供的特性，并且擴展push特定的需求，通過引入新的業(yè)務原語和擴展現(xiàn)有的新的頭域。例如，ota-wsp繼承wsp的能力協(xié)商特性（可能使用uaprof），提供無連接（非確認push）和面向連接的（非確認和確認的push）業(yè)務。2.2.2 ota-http此協(xié)議變量使用http完成ppg與客戶端的空中通信，主要是基于ip承載網(wǎng)絡。http變量只提供面向連接的push。push內(nèi)容通過http post方式傳遞，意味著ppg作為http客戶端并且用戶作為 http服務器。為了避免客戶端因此被混淆，在push ota中使用ota-http時客戶端

17、稱作“終端”。push ota規(guī)范定義了兩種建立一個激活的tcp連接的方法（例如，用來傳遞push內(nèi)容的一個tcp連接）。這個方法包括ppg發(fā)起的建立tcp（po-tcp）連接和終端發(fā)起建立tcp（to-tcp）連接兩種。當承載已激活時，po-tcp允許建立一個激活的tcp連接，并且ppg應獲知終端的ip地址。to-tcp方法為另一種情況，經(jīng)常用在與sir機制聯(lián)合使用。通過使用長期會話的概念，ota-wsp個i客戶端提供了向ppg傳遞能力信息的方法。在ota-http中，終端注冊到ppg上，提供相似的功能性。這通過ppg發(fā)送http options請求給終端完成的，終端在響應中包含其能力和設置

18、信息（cpi）（可以選擇使用uaprof）。當ppg已經(jīng)知道cpi后，為了提高空中傳輸?shù)男剩峁┝吮苊庑畔⑥D(zhuǎn)發(fā)給終端的機制。ota-http也提供識別和選擇性鑒權終端和ppg的方法。鑒權方案使用rfc2617定義的“basic”和“digest” ，終端用來鑒權ppg。而向ppg鑒權終端則使用一個稍微修改的變量（rfc2617只定義了http客戶端，這里為ppg如何被鑒權的）。2.2.3 會話初始應用（sia）無論使用ota-http或ota-wsp，客戶端需要進行通信初始化。sia的指定就是為了完成客戶端一側通信初始化這個目的。sia監(jiān)聽來自ppg發(fā)起的sir，通過激活相應的承載，并且和該

19、ppg聯(lián)系作為響應。當使用ota-wsp，經(jīng)常是客戶端發(fā)起初始化建立底層的wsp會話。當期望建立發(fā)送push消息的wsp會話時，ppg發(fā)送sir到客戶端?？蛻舳私邮盏絪ir后，激活該sir中指明的承載，并且在該建立的承載上向指示的ppg建立一個wsp會話。sir機制經(jīng)常與 ota-http結合使用，尤其當ppg不知道客戶端ip地址，和/或當ppg不能激活所需的承載。這種情況下，sir指示客戶端激活一個特定的承載，并且向sir指定的ppg 建立一個激活的tcp連接（使用to-tcp方式）。無論接下來與ppg聯(lián)系時客戶端使用ota-wsp或是ota-http，發(fā)送到客戶端的sir使用面向無連接pu

20、sh（由ota-wsp提供）。在通常情況下需要確保sir足夠簡單能夠適合放到單個sms中。在多數(shù)當前移動網(wǎng)絡中，sms是可用的，使用一個well-know客戶端地址（msisdn，）并且提供可靠的傳輸層方法（例如，當使用面向無連接push時提供高可靠性）。2.3 push特定的媒體類型push框架允許在pi與客戶端之間傳遞任何mime媒體類型。本節(jié)描述的媒體類型的創(chuàng)建是為了滿足現(xiàn)有mime類型未能提供的功能而進行的擴展。其他帶有push規(guī)范化語法的媒體類型已經(jīng)由oma定義，滿足特定應用的需求（例如mms和provisioning）。注意：如果push指定的語法既不是為媒體類型本身定義，又不是為

21、用戶代理接收特定媒體類型使用，這樣的媒體類型將放置緩存中或在push接收后刪除（whl中使用）。2.3.1 業(yè)務指示 （si）業(yè)務指示（si）媒體類型以異步方式發(fā)送通知到終端用戶的能力。例如，這樣的通知可能是一個新到的郵件，股票價格的變動，新聞頭條消息，廣告，以及余額不多的提醒。si的最基本形式包含一個短消息和一個指示業(yè)務的uri。消息在終端用戶接收后顯示，并且用戶可以選擇立即啟動uri指示的服務，也可以推遲到以后處理。如果si延遲處理，客戶端會先存儲，終端用戶可以遲些操作。除了上面給出的基本功能，si允許pi控制以下：l 用戶中斷的級別(給每個si分配一個特定的優(yōu)先級)l 替換（接收到新的s

22、i即替換舊的si）l 刪除（通過發(fā)送“delete”si，刪除一個已經(jīng)接收的si） l 過期（為si分配一個過期的時間期限）這一章節(jié)描述的媒體類型中，si是客戶端執(zhí)行push時唯一強制使用的媒體類型。2.3.2 業(yè)務加載對比于si，業(yè)務加載（sl）不含任何用戶參與過程。一個sl傳輸包含指向內(nèi)容的uri，由客戶端自動下載而不需要終端用戶確認。還包含一個指示信息，指示內(nèi)容是否應被執(zhí)行、呈現(xiàn)或存放進緩存中是需要。如果內(nèi)容應該執(zhí)行或呈現(xiàn)，pi可以控制用戶中斷的級別。2.3.3 cache 緩存操作co緩存操作媒體類型提供一個使客戶端緩存中的特定對象失效，或使共享同一uri索引的所有對象實效的方法。這個

23、特性在緩存內(nèi)容的期限時間預先不能確定的情況下使用（例如，產(chǎn)看郵箱），以及內(nèi)容變更（新郵件到達）頻率要比用戶接入快的情況下使用非常有效。2.4 尋址push地址在客戶端和應用層出現(xiàn)。另外，兩個注冊的端口（安全和非安全）在無連接push上使用。當面向連接的ota-wsp使用時，任何攜帶push能力集的wsp會話都可以使用。ota-http只用在面向連接的push，使用激活tcp連接概念，專門特別永在push中。更多關于端口，會話，和激活tcp連接可以在pushota查找。2.4.1 客戶端尋址 pi使用客戶端地址指令ppg push消息應該發(fā)送到的客戶端。push ppg規(guī)范介紹了允許的地址配置。

24、l 用戶定義的識別符任意的文本字符串（例如，一個email地址）用來識別客戶端。ppg負責轉(zhuǎn)換此字符串成為一個移動網(wǎng)絡識別的地址格式。push ppg中的舉例，wappush=john.doe%40/type=user;為定義的用戶定義識別符wappush=+155519990730/type=user; 看上去向電話號碼的用戶定義識別符l 設備地址一個移動網(wǎng)絡識別的地址，例如，msisdn（sms等），或ip地址（gprs等）。push ppg中的舉例，wappush=+155519990730/type=plmn; 為一些無線網(wǎng)絡的電話號的設備地

25、址 wappush=0/type=ipv4; ipv4的設備地址type交換指示地址的類型（用戶定義或設備地址包含地址類型），并且 部分是一個ppg的internet主機名稱。更多信息，參看pushppg。2.4.2 應用及尋址 push內(nèi)容總是指向一個設備上的特定的用戶代理（或更多一般，一個特定的應用）。應用識別符可以是一個uri或一個注冊在omna數(shù)字值，來識別一個用戶代理。pushmsg定義了pi在push消息中包含x-wap-application的應用識別符。這個頭域當ppg傳遞消息客戶端時也傳輸?shù)娇蛻舳?，允許客戶端分派消息到目的用戶代理。 o

26、ta效率和數(shù)字識別符為了提高ota效率，一個數(shù)字識別符可以用來代替一個uri。omaomna已經(jīng)為well-known的用戶代理分配了數(shù)字，例如設備wae上的瀏覽器，來避免發(fā)送一個uri的開銷。如果ppg請求推送攜帶一個應用識別的uri的內(nèi)容，這個uri認為是一個由omna分配的數(shù)字識別符的uri，那么這個uri用數(shù)字識別符替代。pi本身使用一個數(shù)字識別符當push消息提交到ppg時，可能是一個未注冊的識別符。如果未注冊的識別符不建議用來配置應用，因為可能發(fā)生沖突。這個主要是為一些還未公共配置的用戶代理使用。2.4.3 舉例假設pi已經(jīng)提交一個消息給客戶端foo，為了一個bar的應用，到客戶端

27、foo的服務的ppg。另外，pi已經(jīng)請求消息應該以一個確認的方式（指面向連接的傳遞）傳遞。ppg（支持ota-http和ota-wsp）之前還未與客戶端進行通信，因此也不知道是否其支持ota-http或ota-wsp（或兩個）。當前沒有push會話或激活tcp連接在ppg和客戶端foo之間，也不需要建立。ppg發(fā)送一個sir到foo以一個面向無連接的方式，使用例如sms， 指示其希望推送一些內(nèi)容到應用bar。既然ppg不知道是否客戶端支持ota-http或ota-wsp，其包含sir中兩個變量的ppg聯(lián)系點。這個請求被發(fā)送到foo中的sia，就像任何其它push內(nèi)容（例如，通過指定專用的無連接

28、的push的一個端口，并且含有sia業(yè)能夠用識別符）?？蛻舳私邮盏絻?nèi)容，考慮使用sia向前發(fā)送。sia，接收到這個請求，檢查是否目標應用安裝在foo中，可能用戶設置指示目標應用接收push內(nèi)容。應用bar實際安裝在此客戶端上，因此客戶端在sir上執(zhí)行。假設客戶端只支持ota-wsp，意味著應該用其向ppg建立會話。 目前，此特定設備的擁有者不希望其它人知道其設備上安裝的應用（隱私保護）。sia注意到這點，向ppg建立一個push會話，指示會話接收任何應用的內(nèi)容。如果用戶已經(jīng)沒有嚴格要求隱私，會話可以用的應用可以清晰地列出來。 一旦會話已經(jīng)建立，ppg在這個會話上完成確認的push，并且客戶端接

29、收到pi提交的push內(nèi)容?？蛻舳私邮盏竭@個內(nèi)容，查看這個內(nèi)容是給應用bar的，并且傳遞到這個應用。當（僅當）應用負責push內(nèi)容，push原路返回確認（如果請求的話）。2.5 安全考慮當執(zhí)行push，安全和信任模型需要在多個領域內(nèi)考慮。以下給出可能遇到的問題的舉例： l pi如何被鑒權l(xiāng) ppg在其安全和信任模型中的角色l 對于pi和push內(nèi)容的接入控制策略l 客戶端如何鑒權其沒有證書的目標不管以上的事件，push框架都有能力提供客戶端足夠的信息來提供一個可信任的模型和其自己的安全策略。2.5.1 鑒權一個push 發(fā)起者pi在一種形式或另一種形式中被鑒權，依靠pi和ppg操作的安全環(huán)境。

30、下面列出一些可能解決方案：l 會話級證書的使用（tls，ssl）如果在pi和ppg之間的網(wǎng)絡不可信任（例如，internet，一個非常大的企業(yè)內(nèi)部網(wǎng)絡），tls/ssl能在pi和ppg之間使用。l http鑒權盡管http鑒權最普通的形式為基本的鑒權（例如，一個用戶id/密碼），其它形式的http鑒權（例如，分類）可能更優(yōu)越。這種方法和tls/ssl的主要不同為tls/ssl在可測量性和隱私性更強，前者在這些方面弱一些。l 技術的結合技術應該聯(lián)合使用。例如，pi與ppg間建立一個匿名的tls/ssl會話，因此http鑒權可以用來鑒權pi。l 共享隱秘的內(nèi)容類型參數(shù)使用共享的秘密，可能產(chǎn)生內(nèi)容類

31、型參數(shù)附加到push特定內(nèi)容類型。這些參數(shù)本質(zhì)上相似于那些為配置加載（provisioning bootstrap）的使用。l 可信任的網(wǎng)絡在一些真實的裝置情況下，pi和ppg之間的網(wǎng)絡是一個私網(wǎng)，因此，pi清晰地信任這樣的整套裝置。2.5.2 客戶端pi鑒權的委托“鑒權的委托”參考鑒權能夠傳遞的原理。如果客戶端和ppg可以建立信任，ppg可以為客戶端鑒權pi。例如，在客戶端已經(jīng)使用了wtls或waptls提供的方法來鑒權ppg，客戶端可以查看其可信任ppg列表。如果ppg列為可信任的，客戶端可以信任這個ppg，并且因此正確識別此pi。使用前面章節(jié)描述的方法，ppg可以通過各種隱私級別鑒權一個

32、pi。如果確實，ota協(xié)議可以為ppg指示此pi中傳遞給客戶端的消息是鑒權過的。如果這種方式中的ppg是可信任的，那么ppg的識別通過可以攜帶客戶端上的可選擇的過濾“whitelist”策略進行交叉檢測。如果ppg身份不再列表內(nèi)，也不在設備上的網(wǎng)關配置集中，客戶端可以忽略接收到的任何push消息。3 push 代理網(wǎng)關服務3.1 概述push服務是wap的一個組成部分，其體系結構如圖3所示，這個體系結構使得信息內(nèi)容能夠從有線網(wǎng)絡上被推送到兼容wap的移動設備上。push業(yè)務技術規(guī)范主要是針對內(nèi)容提供商把內(nèi)容推送（即不需要同步請求的發(fā)送）到客戶端（即支持push相應功能的移動設備）的需求。這與“

33、pull”技術相反?！皃ull”技術需要客戶端發(fā)出的同步請求。利用有線網(wǎng)絡和無線網(wǎng)絡之間的網(wǎng)關使得push業(yè)務更為便利。該網(wǎng)關稱為push代理網(wǎng)關（ppg）。本部分規(guī)范就是要規(guī)范ppg的功能。3.2 ppg 的操作3.2.1 概述本節(jié)主要定義ppg所執(zhí)行的操作：包括push提交處理、結果通知、傳送取消，以及push訪問協(xié)議（pap）狀態(tài)查詢等。ppg操作被定義為獨立的處理每一個push提交（包括隨后和這些push消息相關的操作）。當然，在各push提交之間還是有一些受限的交互。例如，對于可以支持多發(fā)送優(yōu)先級的ppg，一條消息可能會影響到另一消息(如低優(yōu)先級的)的處理時間，并且最終影響到發(fā)送的成

34、敗。需要注意的是，ppg并不應采用特定的順序發(fā)送push消息。3.2.2 push 提交處理 概述push發(fā)起者通過向ppg發(fā)送push消息觸發(fā)push的提交處理。push提交處理包括四個操作，下面三個操作在執(zhí)行時應按照先后的順序：l push提交的接受或者拒絕；l push消息在空中傳送，前提是push消息被接受并且符合ppg的策略和push發(fā)起者的要求；l 消息傳送的結果通知，前提是push消息已經(jīng)被終端所接收，并且push發(fā)起者要求傳送結果通知。第四個操作可以接收在push消息后的任何時間執(zhí)行，這取決于ppg的實現(xiàn)，即l pap協(xié)議的push消息應答。本節(jié)將對這四種操作予以

35、說明。 push 提交的接收和拒絕ppg對收到的每一個push提交消息可選擇接受或拒絕。ppg建議接收可能最終傳送到ota客戶端的pap push提交消息。但是如果push提交消息中包含的pap pushmessege元素不符合它的文檔定義dtd的要求，則這條push提交消息應被拒絕。其它用來決定push提交是否被接受的標準隨具體的實現(xiàn)而定。對于空中傳送所要求的消息處理（在描述）沒有完成的已接收、但還未傳送的push消息，應有如下的信息狀態(tài)報告：pap 屬性屬性值message-statepending.1 對先前提交的push消息的替換對先前提交的p

36、ush消息的替換是可選功能，主要完成對已提交、待push消息的替換。如果ppg支持替換功能，同時消息替換處于已確認狀態(tài)，則ppg應替換pap push-message消息pushpap所請求的消息。若ppg不支持替換功能，則當push發(fā)起者發(fā)出替換請求時，ppg應拒絕這個push提交。.2 客戶端發(fā)起的內(nèi)容請求ppg應支持ota-http或ota-sip方法指示客戶端，pi接受客戶端在響應中返回的內(nèi)容，以便滿足qos參數(shù)中要求的“confirmed-with-response”的傳遞方法。不支持ota-http或ota-sip方法的ppg，應拒絕pi使用此特征的push提交操作。

37、 空中消息傳送.1 概述消息的空中傳送包括兩個功能：l 消息處理；l 消息的空中傳送。本節(jié)將描述這兩個功能。.2 消息處理.2.1 概述為準備空中傳輸，ppg可能會轉(zhuǎn)換包含在push提交中的消息實體（如pushmsg中定義）。典型的轉(zhuǎn)換原因包括針對空中傳送效率的編輯或優(yōu)化，以及將內(nèi)容實體轉(zhuǎn)換成無線終端可接受的內(nèi)容類型。本節(jié)具體描述了這種轉(zhuǎn)換功能。.2.2 實體和消息頭的轉(zhuǎn)換ppg不能對任何在如rfc2616中定義的notransform緩存控制指示范圍內(nèi)無效的實體的消息體進行轉(zhuǎn)換。否則，ppg可能會以與實現(xiàn)相關的方式進行轉(zhuǎn)換

38、。所有被轉(zhuǎn)換實體的消息頭應進行修正以便能夠正確地反映被轉(zhuǎn)換的實體。所有的轉(zhuǎn)換應與pushmsg中的要求一致。..2.2.1 wsp 特定轉(zhuǎn)換ppg應支持wsp中所定義的二進制消息頭編碼。除非確切知道被尋址的終端支持非編碼格式，否則，ppg應為在ota-wsppushota上傳送而將內(nèi)容實體編碼成為對應的壓縮二進制格式wbxml。例如：在無連接模式發(fā)送的情況下，服務指示通常應被編碼成wbxmlwbxml。..2.2.2 http特定轉(zhuǎn)換為了減小在空中的數(shù)據(jù)傳送量，ppg建議支持基于otahttp之上ota傳送的內(nèi)容編碼。如果ppg支持，它應實現(xiàn)rfc1951中所定義的

39、壓縮編碼。..2.2.3 sip特定轉(zhuǎn)換為了減小在空中的數(shù)據(jù)傳送量，ppg建議支持基于ota-sip之上ota傳送的內(nèi)容編碼，如果ppg支持，ppg應實現(xiàn)rfc1951中定義的壓縮編碼。當ppg清楚知道目標終端支持以二進制格式wbxml方式編碼，則內(nèi)容實體可以用此編碼格式編碼。.2.3 x-wap-application-id（application-id）消息頭處理ppg應按照如下說明處理 pushmsg x-wap-application-id（application-id）的消息頭信息：l 如果消息頭包含一個已在omna中注冊的app-assigned-cod

40、e的pushmsg absoluteuri格式的application-id，則ppg應從消息頭信息中去掉所有app-assigned-code格式的application-id（ 如果存在的話） ， 然后用absoluteuri 格式的application-id 替換已注冊的app-assigned-code格式的application-id。l 如果消息頭包含一個沒有在omna中注冊app-assigned-code的pushmsgabsoluteuri格式的application-id ， 則ppg 應使用這個值， 除非存在pushmsg app-assigned-code 格式的ap

41、plication-id。這種情況（如果存在app-assigned-code格式的application-id）下，則應去掉absoluteuri格式的application-id。l 如果消息頭只包含pushmsgapp-assigned-code格式的application-id，則不需要進行替換或者刪除。l 如果處理后的消息頭標識了客戶端的默認應用，則ppg可能會去掉該消息頭。l 如果在push消息中沒有包含pushmsgx-wap-application-id的消息頭，則除非客戶端默認的application-id是wml用戶代理，ppg應加上消息頭。如果加上了消息頭，則applic

42、ation-id應是wml用戶代理的application-id。l 如果使用ota-sip方式，ppg應以urn形式，添加x-wap-application-id頭域的值為g.oma.pusheventapp特征標簽作為push資源標識符。如果是在oman注冊過的眾所周知的地址類型，那么建議使用名稱空間指定的字符串類型。否則，應包含urn的名稱空間標識。ppg可能會除掉含有客戶端默認值的所有消息頭。這個默認值可能會在ota協(xié)議定義，并利用與實現(xiàn)相關的機制進行提供或建立。例如如果客戶端只有一種push應用，則含有x-wap-application-id消息頭可能被去除，以優(yōu)化ota的通信。如果

43、沒有被編碼成數(shù)字格式，包含已注冊值的x-wap-application-id消息頭不能在空中傳送。.2.4 消息狀態(tài)對于上面步驟中可能遇到錯誤，或很明顯不可能成功進行消息發(fā)送的push提交，不能嘗試發(fā)送消息。注意，這可能會導致發(fā)送papresultnotification-message。對于實體和消息頭轉(zhuǎn)換處理失敗的消息應有如下的狀態(tài)報告：pap 屬性屬性值message-stateundeliverablecodetransformation-failure如果消息轉(zhuǎn)換成功，對于未傳送的消息應有如下狀態(tài)報告：pap 屬性屬性值message-statepending3.2.2

44、.3.3 消息的空中傳送.3.1 概述該功能的目的是向ota客戶端傳送消息。實現(xiàn)這項功能的關鍵所在是push otapushota協(xié)議的選擇、確認和非確認push方式的選擇，以及消息的空中傳送。ppg的實現(xiàn)可能包括對消息過期和取消、消息重傳和傳送超時、承載管理和wsp會話(如果使用otawsp)、注冊上下文（如果使用otahttp）管理或注冊狀態(tài)（如果使用ota-sip）等等的測試。.3.2 push ota 協(xié)議的選擇移動終端可能會同時支持otawsp和otahttp見pushota。ppg按照與實現(xiàn)相關的方式為面向連接的push選擇ota協(xié)議變量。ppg通過發(fā)送

45、會話初始請求（sir）向終端提交選取結果，sir中包含ota-wsp和otahttp的連接點的列表。這一過程和sir在 pushota中定義。ppg應通過獲得終端信息或網(wǎng)絡信息，根據(jù)對push客戶端已知的情況獲得push客戶端信息，選擇ota協(xié)議變量，如下：l 基于檢查在移動終端和ppg之間是否有sip注冊l 承載網(wǎng)絡是否可用l 通過查詢uaprof，判斷是否是移動終端能力支持的協(xié)議變量l pi指示push客戶端的信息還包括客戶端的承載方式列表，優(yōu)先級信息，客戶端的在線信息，能力信息，偏好信息或客戶端設置的信息等。ppg根據(jù)以上push客戶端信息，網(wǎng)絡情況信息，判斷使用的ota協(xié)議變量，向選擇

46、的push客戶端發(fā)送push消息。當優(yōu)先級高的ota協(xié)議變量不可用時，使用下一級協(xié)議變量作為push消息的承載方式。ppg可以通過發(fā)送sir消息，并在sir消息中給出ota-wsp，ota-http和ota-sip聯(lián)系點列表讓終端選擇適當?shù)某休d方式。此方法在push ota有定義。當然，pi如果指示其接受客戶端在響應中返回內(nèi)容來響應“confirmed push ”，那么應選擇ota-http或ota-sip方法。如果ppg無法選擇ota-http或ota-sip方法，pap應在“resultnotificationmessage”消息中指示傳遞方法選擇失敗。.3.3 承載網(wǎng)絡選

47、擇如果在pap push-message元素的qos部分要求使用特定的承載和或網(wǎng)絡，則ppg應使用特定的承載和或網(wǎng)絡，或?qū)τ趲в腥缦聽顟B(tài)報告的消息發(fā)送失?。簆ap 屬性屬性值message-stateundeliverabledescan appropriate, implementation-dependent valueevent-timetime or estimated time of failure.3.4 會話或注冊上下文的選擇與創(chuàng)建ppg可能會使用已有的wsp會話（如果使用otawsp）或注冊上下文（如果使用otahttp），或者采用實現(xiàn)相關的方式來創(chuàng)建合適的wsp

48、會話或注冊上下文（例如發(fā)起ota會話創(chuàng)建請求）。對于ota-sip，ppg建議使用push ota描述的流程，決定傳遞動作發(fā)起的時間。如果由于不能或失敗于創(chuàng)建合適的wsp會話或注冊上下文，ppg選擇不再做進一步的發(fā)送，則應報告如下的消息狀態(tài)：pap 屬性屬性值message-stateundeliverabledescan appropriate, implementation-dependent valueevent-timetime or estimated time of failure.3.5 傳送時間約束如果ppg支持傳送時間約束，則ppg不能超出pap deliver

49、-after-timestamp時間發(fā)送push消息。如果不能在pap deliver-before-timestamp時間內(nèi)傳送，則操作失敗，且應報告如下消息狀態(tài)：pap attributevaluemessage-stateexpireddescan appropriate, implementation-dependent valueevent-timetime or estimated time of failure.3.6 空中傳送假設沒有出現(xiàn)錯誤，如果用otawsp進行 ota傳送，則ppg應發(fā)送確認（po-confirmedpush）或非確認(po-push 或 p

50、o-unit-push)方式的push原語。如果用otahttp進行ota傳送，則ppg應利用httppost的方法傳送消息。如果使用ota-sip方式，ppg應使用sip invite/msrp方法傳遞消息。如果使用ota-http或ota-sip方式，pi支持接受客戶端在響應中返回內(nèi)容來響應“confirmed push”, x-wap-push-info頭域應包含“response”屬性標簽。對確認和非確認push方式的使用取決于pap delivery-method的屬性，并且和ppg的實現(xiàn)策略相關。..3.6.1 非確認push方式。ppg應利用otawsp（po-pu

51、sh.req或po-unit-push.req原語）或者otahttp發(fā)送非確認消息。如果使用otahttp，則ppg應報告同樣的pap result-notification消息，如同消息是利用ota-wsp以非確認方式發(fā)送的一樣。如果ppg發(fā)送po-push.req或 po-unit-push.req原語，或ppg利用ota-http代理這些原語發(fā)送消息，則應報告如下的消息狀態(tài)：pap attributevaluemessage-statedelivereddelivery-methodunconfirmedevent-timetime or estimated time of deliv

52、ery..3.6.2 確認push方式ppg應利用ota-wsp（po-confirmedpush.req原語）或ota-http發(fā)送確認信息。接下來的處理依賴于下述的push類型。如果ppg發(fā)送了po-confirmedpush.req原語或使用ota-http，最終結果如下依賴于push信息是否得到應答。1） 發(fā)送成功：如果ppg接收到說明成功發(fā)送到ota客戶端的po-confirmedpush.res原語，或包含說明成功發(fā)送的x-wap-push-status消息頭的http響應，則可能在與實現(xiàn)相關的ppg重試之后，應報告下述消息狀態(tài)：pap 屬性屬性值message-st

53、atedelivereddelivery-methodunconfirmedevent-timetime or estimated time of delivery2） 因為中斷而失敗：如果ppg接收到說明是被中斷的push嘗試的po-pushabort.ind原語，或說明push信息被拒絕的x-wap-push-status消息頭（ota-http），或通過msrp failure-report指示傳遞失?。╫ta-sip），則應報告如下的消息狀態(tài)：pap 屬性屬性值message-stateabortedcodepap-specified representation of the abo

54、rt parameter specified in push otadescan appropriate, implementation-dependent valueevent-timetime or estimated time of aborted delivery attempt3） 因為超時而失?。喝绻褂胦ta-wsp ，當ppg 在與實現(xiàn)相關的時間周期內(nèi)沒有收到otapo-confirmedpf時超時發(fā)生。如果使用ota-http，當ppg在與實現(xiàn)相關的時間周期內(nèi)沒有收到對http post請求的應答時超時發(fā)生。如果使用ota-sip，當ppg在與實現(xiàn)相關的時間周期內(nèi)沒有收到ms

55、rp success-report指示傳遞成功時，超時發(fā)生。如果超時發(fā)生時ppg選擇不再進行發(fā)送嘗試，則應報告如下的消息狀態(tài)：pap 屬性屬性值message-statetimeoutdescan appropriate, implementation-dependent valueevent-timetime or estimated time of last delivery attempt..3.6.3 oneshot傳遞ppg根據(jù).5.1方式傳遞“oneshot”消息。ppg應只嘗試傳遞一次push消息，并確保底層承載也使用此種傳遞嘗試。使用該種方法時，應報告如下消息狀態(tài)：pap 屬性屬性值message-statedelivereddelivery-methodoneshotevent-timetime or estimated time of delivery3.2.3 結果通知 概述如果在push