專利名稱：：會話連接發(fā)起方法及設(shè)備的制作方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及通信領(lǐng)域，特別涉及設(shè)備管理和數(shù)據(jù)同步技術(shù)。
背景技術(shù)：
：隨著現(xiàn)代通信技術(shù)在人類工作和生活中扮演著日益重要的角色，人們對數(shù)據(jù)傳輸?shù)馁|(zhì)量提出了越來越高的要求，其中數(shù)據(jù)同步(DataSynchronization,簡稱"DS")是一個十分重要的指標(biāo)。開放移動聯(lián)盟(OpenMobileAlliance,筒稱"OMA")DS技術(shù)，是指移動設(shè)備與網(wǎng)絡(luò)服務(wù)器之間保持數(shù)據(jù)同步，同步的數(shù)據(jù)包括電話本、通訊錄、日程、短信、郵件等。OMADS4支術(shù)是基于同步標(biāo)記語言(SynchronizationMarkupLanguage,筒稱"SyncML"),基于該SyncML語言的還有OMA設(shè)備管理(DeviceManagement,簡稱"DM")技術(shù)。OMADM技術(shù)，是指服務(wù)器通過空中下載的方式對終端進行管理操作，比如參數(shù)配置，固件更新，軟件下載、安裝、刪除，故障診斷、修復(fù)，終端監(jiān)控等。在現(xiàn)有的SyncML消息中，提供了一種通知(Notification)機制，用于服務(wù)器下發(fā)Notification消息給終端設(shè)備，終端設(shè)備根據(jù)Notification里的SessionID(會話ID)、ServerID(服務(wù)ID)等信息發(fā)起與服務(wù)器的會話連接。Notification消息的下發(fā)可以通過短消息、OTAPUSH(空中下載推)等方式。目前，DS/DM服務(wù)器(DS或DM服務(wù)器)與DS/DM客戶端(DS或DM客戶端)之間進行的會話管理流程如圖1所示。在步驟110中，DS/DM服務(wù)器向DS/DM客戶端下發(fā)Notification消息，請求會話連接。接著，在步驟120中，DS/DM客戶端向DS/DM服務(wù)器發(fā)起會話連接，發(fā)送該DS/DM客戶端的認證信息、設(shè)備信息給該DS/DM服務(wù)器，該設(shè)備信息、認證信息包括在管理會話的Package#1(包1)消息中。接著，在步驟130中，該DS/DM服務(wù)器向該DS/DM客戶端發(fā)送Package#1消息，在該消息中攜帶用于進行會話操作的初始化包。然后，通過Package弁3Package弁4消息進行后續(xù)的會話操作，如步驟140所示。已有的OMADS的Notification消息格式與已有的OMADM的Notification消息格式大致相同，不同之處在于，DS里的Notification消息進一步對notification-body(消息體)進4亍了擴展。DS/DMNotification消息^>用的Digest(摘要)與Notification-hdr(消息頭)部分的格式如圖2所示。對Notification消息中的各字段的解釋如下<digest>::=128*BIT(比特)；'MD5摘要值，<version>::=10*BIT;'版本信息，<ui-mode>::=<not-specified〉/<background〉/;'用戶交互模式<informative〉/<user-interaction〉；〈not-specified〉:="00";'非特定，<background〉:="01";'后臺模式，<informative>::="10";'提示模式，<user-interaction>::="11";'確iMt式，<initiator>::=<client>/<server>;'會話發(fā)起方'<client〉:="0";'客戶端發(fā)起'<server〉:="1";'服務(wù)器發(fā)起，<future-use〉:=27*BIT;'留作擴展，<sessionid>::=16*BIT;'會話標(biāo)識,<length-identifier〉:=8*BIT;'服務(wù)器標(biāo)識《<server-identifier〉=<length-identifier>*CHAR;'服務(wù)器標(biāo)識<vendor-specific〉:=n*BIT;'留作擴展，在OMADS中的進一步對Notification消息的notification-body進行了擴展，擴展部分的格式如圖3所示。其中，字段"num-syncs"表明有幾個同步操作，字段"fUture-use"留作以后擴展，字段"syncl"，字段"syncN，，是具體的多個同步操作，字段"sync-type"為同步類型，字段"content-type"表明要同步的數(shù)據(jù)庫的內(nèi)容類型，字段"server-URI-length"表明字段"server-URI"的長度，該"server-URT字段用于存放要同步的服務(wù)器的數(shù)據(jù)庫名。由此可見，在OMADS的Notification消息里表明了同步的類型、待同步數(shù)據(jù)庫等信息。然而，本發(fā)明的發(fā)明人發(fā)現(xiàn)，目前的會話管理機制中存在空口資源浪費的問題。比如說，客戶端與服務(wù)器已經(jīng)通過了傳輸層認證，客戶端無需再上報認證信息。此時，如果客戶端再上報認證信息則是對空口資源的浪費?；蛘?，客戶端與服務(wù)器已經(jīng)通過了傳輸層認證，但是服務(wù)器要求客戶端仍然需要上報認證信息，進行應(yīng)用層認證，才能建立管理/同步會話。此時，如果客戶端沒有上報認證信息，則服務(wù)器會返回客戶端一個"缺少客戶端認證信息"的錯誤消息，客戶端需要再一次的上報認證信息，多了一次與服務(wù)器的交互，導(dǎo)致了空口資源的浪費。或者，服務(wù)器不需要客戶端上報完整的設(shè)備信息，但客戶端卻向服務(wù)器發(fā)送了完整的設(shè)備信息，導(dǎo)致了空口資源的浪費等。另夕卜，在目前的現(xiàn)有技術(shù)中，客戶端收到Notification消息后發(fā)起的同步類型是根據(jù)客戶端單方面的數(shù)據(jù)修改信息，而且同步類型(如慢同步、快同步、刷新同步等)也很陳舊。在智能同步中，要求同步的雙方能通過分析對方的數(shù)據(jù)修改信息及數(shù)據(jù)庫的信息來選擇性的發(fā)送數(shù)據(jù)信息及數(shù)據(jù)指纟丈信息。比如，如果服務(wù)器指定的同步方向為雙向，客戶端就不會發(fā)起單向同步。而在客戶端無法選擇合適的同步機制的情況下，將會導(dǎo)致會話效率的降低。
發(fā)明內(nèi)容本發(fā)明實施方式要解決的主要技術(shù)問題是提供一種會話連接、同步會話發(fā)起方法及設(shè)備，使得能夠節(jié)省網(wǎng)絡(luò)資源，另外，能夠提高會話效率。為解決上述技術(shù)問題，本發(fā)明的實施方式提供了一種會話連接發(fā)起方法，包含以下步驟接收來自數(shù)據(jù)同步或設(shè)備管理DS/DM服務(wù)器的觸發(fā)建立會話連接的消息，該消息中攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信自如果指示信息為要求上報，則向DS/DM服務(wù)器發(fā)送攜帶安全認證信息和/或設(shè)備信息的發(fā)起會話連接的消息。本發(fā)明的實施方式還提供了一種同步會話發(fā)起方法，包含以下步驟接收來自DS服務(wù)器的觸發(fā)建立會話連接的消息，該消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)；根據(jù)數(shù)據(jù)同步機制的協(xié)商參數(shù)選擇同步機制，并使用該同步機制向DS服務(wù)器發(fā)起同步會話。本發(fā)明的實施方式還提供了一種DS/DM客戶端，包括接收模塊，用于接收來自DS/DM服務(wù)器的觸發(fā)建立會話連接的消息，該消息中攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息；解析模塊，用于解析接收模塊收到的觸發(fā)建立會話連接的消息；發(fā)送模塊，用于在解析模塊從觸發(fā)建立會話連接的消息中解析出指示信息為要求上報時，向DS/DM服務(wù)器發(fā)送攜帶安全認證信息和/或設(shè)備信息的發(fā)起會話連接的消息。本發(fā)明的實施方式還提供了一種DS/DM服務(wù)器，包括生成模塊，用于生成觸發(fā)建立會話連接的消息，該消息中攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息；發(fā)送模塊，用于將生成模塊生成的觸發(fā)建立會話連接的消息，發(fā)送給DS/DM客戶端。本發(fā)明的實施方式還提供了一種DS客戶端，包括接收模塊，用于接收來自DS服務(wù)器的觸發(fā)建立會話連接的消息，該消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)；解析模塊，用于解析接收模塊收到的觸發(fā)建立會話連接的消息；選擇模塊，用于根據(jù)解析模塊從觸發(fā)建立會話連接的消息中解析出的數(shù)據(jù)同步機制的協(xié)商參數(shù)，選擇同步機制；同步會話發(fā)起模塊，用于使用選擇模塊所選的同步機制向DS服務(wù)器發(fā)起同步會話。本發(fā)明的實施方式還提供了一種DS服務(wù)器，包括生成模塊，用于生成觸發(fā)建立會話連接的消息，該消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)；發(fā)送模塊，用于將生成模塊生成的觸發(fā)建立會話連接的消息，發(fā)送給DS客戶端。本發(fā)明實施方式與現(xiàn)有技術(shù)相比，主要區(qū)別及其效果在于觸發(fā)建立會話連接的消息中攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息，DS/DM客戶端根據(jù)該指示信息決定向DS/DM服務(wù)器發(fā)送的發(fā)起會話連接的消息中，是否需要攜帶安全認證信息和/或設(shè)備信息。由于DS/DM客戶端能夠通過觸發(fā)建立會話連接的消息了解到DS/DM服務(wù)器發(fā)起會話的意圖，因此可避免由于安全認證信息和/或設(shè)備信息的上報不符合服務(wù)器要求的信息，而造成的客戶端與服務(wù)器的多次交互，從而節(jié)省了網(wǎng)絡(luò)資源。在觸發(fā)建立會話連接的消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)，使得DS客戶端能夠根據(jù)此信息選擇相應(yīng)的同步機制，從而減少了同步機制選擇的會話交互，提高了會話效率。圖l是流程圖2是現(xiàn)有技術(shù)中DS/DMNotification消息公用的Digest(摘要)與Notification-hdr(消息頭)部分的格式示意圖3是現(xiàn)有技術(shù)中進一步對DSNotification消息的notification-body(消息體)擴展部分的格式示意圖4是根據(jù)本發(fā)明第一實施方式的會話連接發(fā)起方法流程圖5是根據(jù)本發(fā)明第一實施方式中擴展的Notification消息的格式示意圖6是根據(jù)本發(fā)明第二實施方式的會話連接發(fā)起方法流程圖；圖7是根據(jù)本發(fā)明第三實施方式的同步會話發(fā)起方法流程圖；圖8是根據(jù)本發(fā)明第三實施方式中擴展的Notification消息的格式示意圖9是根據(jù)本發(fā)明第四實施方式中擴展的Notification消息的格式示意圖IO是根據(jù)本發(fā)明第五實施方式的會話連接發(fā)起系統(tǒng)的結(jié)構(gòu)示意圖；圖11是根據(jù)本發(fā)明第六實施方式的同步會話發(fā)起系統(tǒng)的結(jié)構(gòu)示意圖。具體實施例方式為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合附圖對本發(fā)明的實施方式作進一步地詳細描述。本發(fā)明的第一實施方式涉及一種會話連接發(fā)起方法，具體流程如圖4所示。在步驟410中，DS/DM服務(wù)器生成攜帶指示信息的觸發(fā)建立會話連接的消息，在本實施方式中，該消息為Notification消息。具體地說，DS/DM服務(wù)器根據(jù)實際需要，確定是否需要DS/DM客戶端上報安全認證信息和設(shè)備信息，上報的安全認證信息所屬的機制(如是機制為"auth-basic"的安全認證信息，還是才幾制為"auth-MD5"的安全認證信息)、以及上報設(shè)備信息時所使用的方式，并將確定結(jié)果通過指示信息攜帶在Notification消息中，使得接收到該Notification消息的DS/DM客戶端，能夠根據(jù)該Notification消息，獲知DS/DM服務(wù)器是否要求上報安全認證信息和/或設(shè)備信息、上報的安全認證信息所屬的機制、以及上報設(shè)備信息時所使用的方式?？梢酝ㄟ^擴展Notification消息的格式，在Notification消息中攜帶指示信息。比如說，如圖5所示，將用于攜帶指示信息的擴展字段放在DS/DSNotification消息中的notification-body(消息體)中，當(dāng)然，實際上擴展字l殳也可以it在notification-hdr(消息頭)中，如方文在notification-hdr中的字,殳"foture-use，，中。該擴展字段內(nèi)包含"auth-code"字段、"dev-code"字段、和"fUture-use"字段。其中，"auth-code"字段用于指示是否要求上報安全認證信息，以及上報的安全認證信息所屬的機制；"dev-code"字段用于指示是否要求上報設(shè)備信息，以及上報設(shè)備信息時所使用的方式；"fiiture-use"字段留作以后擴展。對擴展字段的說明如下<auth-code>::=3*BIT;'DM認證碼(應(yīng)用層認證)，<dev-code〉:=3*BIT;'設(shè)備信息碼，<fUture-use〉:=18*BIT;'留作擴展，具體地說，"auth-code"字段的取值及其含義如表1所示:<table>tableseeoriginaldocumentpage12</column></row><table>表1需要說明的是，當(dāng)"auth-code"字段取值為101時，說明DS/DM服務(wù)器對認證不做特殊的規(guī)定，DS/DM客戶端可以根據(jù)DS/DM標(biāo)準(zhǔn)中"DMAcc"上的認證類型"AAuthPref，值指定的認證方式或上次成功的會話所使用認證方式進行認證，其中，"DMAcc"為用于管理開放移動聯(lián)盟設(shè)備管理協(xié)議設(shè)置的管理對象。"dev-code"字段的取值及其含義如表2所示:<table>tableseeoriginaldocumentpage12</column></row><table>表2也就是說，當(dāng)"dev-code"字段取值為000時，說明DS/DM服務(wù)器要求DS/DM客戶端發(fā)起一個空會話，即該DS/DM客戶端在發(fā)起會話連接的消息(Package#1)中無需上報設(shè)備信息，可以在空會話建立后，收到來自DS/DM服務(wù)器的用于獲取設(shè)備信息的命令時，再上報該DS/DM客戶端的設(shè)備信息。在空會話建立后，如果DS/DM服務(wù)器需要DS/DM客戶端的設(shè)備信息，可以通過發(fā)一個Get命令獲取<Get〉<CmdID〉l</CmdID〉<Item><Target〉<LocURI〉./DevInfo</LocURI〉</Target></Item></Get>當(dāng)"dev-code"字段取值為001時，說明DS/DM服務(wù)器要求DS/DM客戶端上報完整的設(shè)備信息，在第一次管理會話時，DS/DM客戶端必須上報完整的設(shè)備信息給DS/DM服務(wù)器。在隨后的管理會話中，客戶端可以只上報更新的設(shè)備信息以節(jié)省傳輸流量。當(dāng)"dev-code"字段取值為010時，說明DS/DM服務(wù)器要求DS/DM客戶端上報更新的設(shè)備信息。DS/DM客戶端可以使用〈Put〉命令將更新的設(shè)備信息上報給DS/DM服務(wù)器，DS/DM客戶端必須保存設(shè)備信息的更新記錄。當(dāng)"dev-code"字段取值為Oil時，說明DS/DM服務(wù)器要求DS/DM客戶端不上報設(shè)備信息。如果DS/DM服務(wù)器不關(guān)心DS/DM客戶端的設(shè)備信息，或者DS/DM服務(wù)器認為DS/DM客戶端的設(shè)備信息對自己沒有用，可以要求DS/DM客戶端不上才艮，這樣可以節(jié)省傳輸流量。當(dāng)"dev-code"字段取值為100時，說明DS/DM服務(wù)器要求DS/DM客戶端上報設(shè)備信息的URI鏈接。DS/DM服務(wù)器可以根據(jù)DS/DM客戶端上報的設(shè)備信息的URI鏈接，得相應(yīng)的存儲的地方去獲取。在步驟420中，該DS/DM服務(wù)器將生成的攜帶指示信息的Notification消息，下發(fā)給DS/DM客戶端。具體地說，該DS/DM服務(wù)器可以通過OTAPUSH(或會話發(fā)起協(xié)議(SessionInitationProtocol,簡稱"SIP")PUSH)的方式或短消息的方式，將生成的攜帶指示信息的Notification消息，下發(fā)給DS/DM客戶端，請求會話連接。接著，在步驟430中，DS/DM客戶端解析收到的Notification消息，生成符合要求的發(fā)起會話連接的消息，該發(fā)起會話連接的消息即為Package#l消息。具體地說，DS/DM客戶端解析攜帶在Notification消息中的指示信息，判斷在隨后的Package#l消息中如何上報安全認證信息和設(shè)備信息，包括是否要上報安全認證信息，以及上報何種機制的安全認證信息；是否要上報設(shè)備信息，以及上報設(shè)備信息的方式。針對上述案例，DS/DM客戶端解析Notification消息中的擴展字段，根據(jù)擴展字段中"auth-code，，字段的取值，判斷出如何上報安全認證信息。比如說，如果該字段取值為000，則說明傳輸層認證通過，則不需要上報安全認證信息；如果字段取值為Oll,則說明傳輸層認證未通過，以認證機制"auth-basic，，上報安全認證信息等。類似地，根據(jù)擴展字段中"dev-code'，字段的取值，判斷出如何上報設(shè)^f言息，在此不再贅述。然后，DS/DM客戶端根據(jù)解析到的結(jié)果，生成Package弁l消息，該Package#1消息中攜帶符合DS/DM服務(wù)器要求的安全認證信息和/或設(shè)備信息。比如說，解析到"auth-code，，字段的取值為011,"dev-code，，字段的取值為010,則在Package#1消息中攜帶認證機制為"auth-basic"的安全認證信息，和更新的設(shè)備信息。接著，在步驟440中，DS/DM客戶端將生成的Package#1消息發(fā)送給DS/DM服務(wù)器。步驟450和步驟460分別與步驟130和步驟140相同，在此不再贅述。由于在本實施方式中，DS/DM客戶端能夠通過Notification消息了解到DS/DM服務(wù)器是否要求上報安全認證信息和/或設(shè)備信息、上報的安全認證信息所屬的機制、以及上報設(shè)備信息時所使用的方式。因此可避免由于安全認證信息和/或設(shè)備信息的上報不符合服務(wù)器要求的信息，而造成的客戶端與服務(wù)器的多次交互，從而節(jié)省了網(wǎng)絡(luò)資源。比如說，DS/DM客戶端與DS/DM服務(wù)器已經(jīng)通過了傳輸層認i正，DS/DM無需再上報認證信息。此時，只需在Notification消息將"auth-code"字段的取值設(shè)置為000，即可避免DS/DM客戶端再次上報安全認證信息，從而節(jié)約了空口資源。再比如說，DS/DM服務(wù)器僅僅是想與DS/DM客戶端建立一個空會話，希望DS/DM客戶端不必上報設(shè)備信息。此時，只需在Notification消息中將"dev-code"字段的取值設(shè)置為000,即可避免DS/DM客戶端上報設(shè)備信息，從而節(jié)約了空口資源。值得一提的是，在本實施方式中，DS/DM客戶端即為終端設(shè)備，如果該DS/DM客戶端不具備接收Notification消息的功能，則該DS/DM客戶端需要通過Notification客戶端接收Notification消息。Notification客戶端要依賴于業(yè)務(wù)實現(xiàn)，比如說，如果在業(yè)務(wù)實現(xiàn)上，是通過OTAPUSH方式發(fā)送Notification消息的，則該Notification客戶端將是OTAPUSH客戶端；如果是采用短消息發(fā)送，則該Notification客戶端將是短消息客戶端。類似地，如果DS/DM服務(wù)器不具備發(fā)送Notification消息的功能，則該DS/DM服務(wù)器需要通過Notification服務(wù)器發(fā)送Notification消息。本發(fā)明的第二實施方式涉及一種會話連接發(fā)起方法，本實施方式在第一實施方式的基礎(chǔ)上，進一步增加了在Notification消息中未明確指示是否要求上報安全認證信息的情況下，DS/DM客戶端的具體操作。具體流程如圖6所示，步驟610至步驟650分別與步驟410至步驟450相同，在此不再贅述。由于本實施方式中，在Notification消息中未明確指示是否要求上凈艮安全認證信息，也就是說，Notification消息中擴展的"auth-code"字段取值為101。因此，DS/DM客戶端會在本地查找管理對象"DMAcc"上是否有"AAuthPref，節(jié)點，如果有該節(jié)點并且該節(jié)點有值，則根據(jù)該節(jié)點中指定的認證方式上報安全認證信息；如果沒有該節(jié)點，或者有該節(jié)點但該節(jié)點無值，則按默i人的認證方式進行安全認證。比如說，默認的認證方式是在Package#1消息中上報認證機制為"auth-basic"的安全認證信息，那么，DS/DM客戶端將在生成的Package#1消息攜帶認證機制為"auth-basic"的安全認證信息。在本實施方式中，以默認的認證方式認證成功，也就是說，DS/DM服務(wù)器向DS/DM客戶端發(fā)送的Package#2消息中，攜帶表示認證成功狀態(tài)碼。接著，在步驟660中，當(dāng)DS/DM客戶端根據(jù)收到的Package#2消息，獲知認證成功后，記錄該默認的認證方式。以便在之后的認證中，使用該能夠通過認證的認證方式，從而提高了認證成功的概率。具體地說，可以有兩種記錄方式(1)將默認的認證方式記錄在用于指定認證方式的認證類型"AAuthPref，節(jié)點中。針對上述案例，即是將上報認證機制為"auth-basic"的安全認證信息的認證方式作為"AAuthPref，節(jié)點的值，記錄在該"AAuthPref，節(jié)點中。(2)將默認的認證方式記錄在管理對象"DMAcc"中擴展的與認證相關(guān)的節(jié)點中。針對上述案例，在"DMAcc"中擴展一個與認證相關(guān)的節(jié)點，將上報認證機制為"auth-basic"的安全認證信息的認證方式，記錄在該擴展的節(jié)點中。接著，進入步驟670,步驟670與步驟460相同，在此不再贅述。本發(fā)明的第三實施方式涉及一種同步會話發(fā)起方法，在本實施方式中，DS客戶端接收來自DS服務(wù)器的觸發(fā)建立會話連接的消息，該消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)。DS客戶端根據(jù)數(shù)據(jù)同步機制的協(xié)商參數(shù)選擇同步機制，并使用該同步機制向DS服務(wù)器發(fā)起同步會話。本實施方式中的觸發(fā)建立會話連接的消息為Notification消息。具體流程如圖7所示，在步驟710中，DS服務(wù)器生成Notification消息，并在該消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)。具體地說，可以通過擴展Notification消息的格式，在Notification消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)。如圖8所示，在Notification消息中擴展的字段包含"length-info"字段、"info"字段、"Direction"字段、"ID-Valid"字段、"preserve"字段、"log-valid"字段、"Changed-Items"字段、"Decision"字段、"Continuous-sync"字段、"Datastore-length"字段、和"Data-Store"字段。下面分別對各個擴展字段進行說明。對"length-info"字段和"info"字段的說明如下<length-info>::=8*BIT;'會話信息的長度，<info〉:=<length-info〉*CHAR(字符)；'會話信息，"length-info"字段用于表示字段"info"的長度；"info"字段用于表示會話信息，DS客戶端可以將此信息以可顯示文本的方式將會話信息顯示給用戶，比如"您有新的Email,請查收。"接收到此信息的DS客戶端(即終端)，就可以發(fā)起一個同步會話，將DS服務(wù)器上的新郵件同步到本DS客戶端。也就是說，可以使得DS客戶端在收到Notification消息后，根據(jù)其擴展字段中的會話內(nèi)容的信息，對是否需要發(fā)起會話進行判斷，并在確定需要發(fā)起會話后，選擇同步機制，將DS服務(wù)器上的新郵件同步到本DS客戶端。"Direction"字段用于表示同步方向，說明如下<Direction>::=<Not-specified>/<from-server>/<from-client〉/<two-way>;'方向信息，<Not-specified〉::=，00，；，非特定，<from-server>::=，01，；，從服務(wù)器，單向，<from-client>::=，10，；，從客戶端，單向，<two-way>::=，ll，；，雙向，"ID-Valid"字段用于表示DS服務(wù)器端數(shù)據(jù)條目的標(biāo)識是否有效，說明如下〈ID-Valid〉:=<valid>/<invalid〉；，ID有效性，<valid>::=，l，；，ID有效，<invalid〉:=，0，；，ID無效'DS服務(wù)器端需要維護雙方數(shù)據(jù)條目標(biāo)識信息的映射表，如果由于數(shù)據(jù)庫損壞等，導(dǎo)致標(biāo)識信息無效，將影響雙方的同步機制的選擇。"preserve"字段用于表示對數(shù)據(jù)的保存情況，比如是清除DS服務(wù)器端數(shù)據(jù)還是清除DS客戶端數(shù)據(jù)，說明如下<preserve>::=<not-specified>/<clear-client>/<clear-server〉/<merge>;，數(shù)據(jù)是否保存，<Not-specified>::=，00，；，非特定，<clear-client>::=，01，；，清除客戶端數(shù)據(jù)，<clear-server〉:=，10，；，清除服務(wù)器端數(shù)據(jù)，<merge〉:=，11，；，融合雙方的數(shù)據(jù)，"log-valid"字段用于表示DS服務(wù)器端的修改日志是否有效。修改日志是用于記錄DS服務(wù)器端數(shù)據(jù)庫、數(shù)據(jù)條目的改變情況的，如果修改日志無效，DS服務(wù)器將無法告知DS客戶端自身的哪些數(shù)據(jù)條目被改變了。這將影響雙方的同步才幾制的選擇。說明如下<log-valid>::=<valid〉/<invalid>;，修改日志有效性，<valid〉:=T;，修改日志有效，<invalid>::=，0，；1務(wù)改日志無效，"Changed-Items"字段用于表示DS服務(wù)器端改變的數(shù)據(jù)項(DataItem)數(shù)目的信息，il明如下<Changed-Items>::=8*BIT;'改變的Data-Item數(shù)目，"Decision"字l殳用于表示決定方向，即是由哪一方?jīng)Q定，決定的內(nèi)容包括沖突檢測、決定同步方向、同步類型等。說明如下<Decision〉:=<Client>/<Server>;'明卩一方?jīng)Q定，<Server〉:='1，；'服務(wù)器決定，<Client〉:='0，；'客戶端決定，"Continuous-sync"字段用于表示DS服務(wù)器是否希望開始連續(xù)的同步會話。在實時同步的情況下，DS客戶端需要與DS服務(wù)器保持常連接。如果DS服務(wù)器用此字段指示DS客戶端此會話為連續(xù)的同步會話，則DS客戶端需要保持與DS服務(wù)器的常連接，在常連接的情況下，DS服務(wù)器可以直接發(fā)起與DS客戶端的會話連接，而不需要再使用Notification消息來通知DS客戶端發(fā)起會話。此會話可以一直保持，以保證DS客戶端與DS服務(wù)器的同步數(shù)據(jù)保持實時同步，直到雙方中的一方使用會話命令斷開會話連接，或會話意外中斷。說明如下〈Continuous誦sync〉:=<true>/<false〉；，連續(xù)同步，<true>::=，l，；，連續(xù)同步，<false>::=，0，；，非連續(xù)同步，"Datastore-length"字l爻用于表示"Data-Store"字l殳的長度；"Data-Store"字段用于表示待同步數(shù)據(jù)庫的標(biāo)識。說明如下<Datastore-length>::=8*BIT;'數(shù)據(jù)庫標(biāo)識長度，<Data-Store>::=<Datastore-length〉*CHAR;'數(shù)據(jù)庫標(biāo)識，接著，在步驟720中，DS服務(wù)器將生成的攜帶協(xié)商參數(shù)的Notification消息，下發(fā)給DS客戶端。具體地說，該DS服務(wù)器可以通過OTAPUSH(或SIPPUSH)的方式或短消息的方式，將生成的攜帶協(xié)商參數(shù)的Notification消息，下發(fā)給DS客戶端。接著，在步驟730中，DS客戶端解析收到的Notification消息，選擇同步機制。具體地說，DS客戶端通過對收到的Notification消息進行解析，得到攜帶在該消息中的數(shù)據(jù)同步機制的協(xié)商參數(shù)，并根據(jù)該協(xié)商參數(shù)選擇合適的同步機制。其中，對同步機制的選擇包括以下之一或其任意組合對同步方向的選擇、對是否發(fā)送全部數(shù)據(jù)項的選擇、對是否只發(fā)送修改的數(shù)據(jù)項的選擇、對是否發(fā)送數(shù)據(jù)指纟丈信息的選擇、對是否需要對方比較數(shù)據(jù)項的選擇、對是否需要對方用接收的數(shù)據(jù)項覆蓋自身存儲的數(shù)據(jù)項的選擇。下面通過幾個舉例，對DS客戶端根據(jù)數(shù)據(jù)同步機制的協(xié)商參數(shù)，選擇合適的同步機制進行簡單說明。比如說，如果DS服務(wù)器指定的同步方向為單向，且決定方向為DS服務(wù)器，則DS客戶端應(yīng)該選擇單向同步。或者，如果DS服務(wù)器的ID映射表無效，因此即使DS客戶端發(fā)送數(shù)據(jù)項的標(biāo)識，DS服務(wù)器也無法識別，所以，DS客戶端應(yīng)該選擇發(fā)送數(shù)據(jù)指紋信息、或選擇發(fā)送全部數(shù)據(jù)。再或者，如果DS服務(wù)器改變的數(shù)據(jù)項較多，則DS客戶端應(yīng)選擇雙向同步或DS服務(wù)器單向同步，同時應(yīng)發(fā)送數(shù)據(jù)指紋信息，以避免雙方的數(shù)據(jù)項修改沖突。當(dāng)然，還有其它許多情況，在此不再一一例舉。接著，在步驟740中，DS客戶端使用選擇的同步機制向DS服務(wù)器發(fā)起同步會話。不難發(fā)現(xiàn)，由于在本實施方式中，在Notification消息中攜帶了數(shù)據(jù)同步機制的協(xié)商參數(shù)，因此可使得DS客戶端能夠根據(jù)此信息選擇相應(yīng)的同步機制，從而減少了同步機制選擇的會話交互，提高了會話效率。本發(fā)明的第四實施方式涉及一種同步會話發(fā)起方法，本實施方式在第三實施方式的基礎(chǔ)上，在Notification消息中進一步攜帶用于指示如何上報安全認證信息和設(shè)備信息的指示信息，包括是否要上報安全認證信息，以及上報何種機制的安全認證信息；是否要上報設(shè)備信息，以及上報設(shè)備信息的方式。由此可見，本實施方式實際上是第三實施方式與第一或第二實施方式的一種組合。本實施方式與第三實施方式的區(qū)別在于，在第三實施方式中，Notification消息攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)；而在本實施方式中，Notification消息不僅攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)，還攜帶用于指示如何上報安全認證信息和設(shè)備信息的指示信息。本實施方式與第一(或第二)實施方式的區(qū)別在于，在第一(或第二)實施方式中，服務(wù)器為DS或DM服務(wù)器，客戶端為DS或DM客戶端，Notification消息中攜帶用于指示如何上報安全認證信息和設(shè)備信息的指示信息；而在本實施方式中，服務(wù)器為DS服務(wù)器，客戶端為DS客戶端，Notification消息中不僅攜帶用于指示如何上報安全認證信息和設(shè)備信息的指示信息，還攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)。因此，需要擴展Notification消息中的字段，以便攜帶用于指示如何上報安全認證信息和設(shè)備信息的指示信息，以及數(shù)據(jù)同步機制的協(xié)商參數(shù)。擴展的Notification消息如圖9所示，擴展的字段包含"length-info"字段、"info"字段、"auth-code，，字段、"dev-code，，字段、"Direction"字段、"ID-Valid"字段、"preserve"字段、"log-valid"字段、"Changed-Items，，字段、"Decision"字段、"Datastore-length，，字段、和"Data-Store"字段。各字,殳分別已在第一或第三實施方式中已作過說明，在此不再贅述。由此可見，本實施方式不僅能夠避免由于安全認證信息和/或設(shè)備信息的上報不符合服務(wù)器要求的信息，而造成的客戶端與服務(wù)器的多次交互，從而節(jié)省了網(wǎng)絡(luò)資源。而且，DS客戶端能夠根據(jù)攜帶在Notification消息中的數(shù)據(jù)同步機制的協(xié)商參數(shù)，選擇相應(yīng)的同步機制，從而減少了同步機制選擇的會話交互，提高了會話效率。本發(fā)明的第五實施方式涉及一種會話連接發(fā)起系統(tǒng)，如圖10所示，包含DS/DM客戶端，和DS/DM服務(wù)器。在DS/DM服務(wù)器中包括生成模塊，用于生成觸發(fā)建立會話連接的消息，該消息中攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息；和發(fā)送模塊，用于將該生成模塊生成的觸發(fā)建立會話連接的消息，發(fā)送給DS/DM客戶端。其中，該指示信息還用于指示上報的安全認證信息所屬的機制，和/或指示上報設(shè)備信息時所使用的方式。比如說，是上報機制為"auth-basic"的安全認證信息，還是上報機制為"auth-MD5"的安全i人證信息；上才艮設(shè)備信息時，是使用以下哪知方式上報完整的設(shè)備信息、上報更新的設(shè)備信息、發(fā)起空會話、上報設(shè)^f言息的URI鏈接。在DS/DM客戶端中包括接收模塊，用于接收來自DS/DM服務(wù)器的觸發(fā)建立會話連接的消息(該消息即是攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息的消息)；解析模塊，用于解析該接收模塊收到的觸發(fā)建立會話連接的消息；和發(fā)送模塊，用于在該解析模塊從觸發(fā)建立會話連接的消息中解析出該指示信息為要求上報時，向DS/DM服務(wù)器發(fā)送攜帶安全認證信息和/或設(shè)備信息的發(fā)起會話連接的消息。本實施方式中的觸發(fā)建立會話連接的消息可以是Notification消息。由于DS/DM客戶端能夠通過觸發(fā)建立會話連接的消息了解到DS/DM服務(wù)器發(fā)起會話的意圖，因此可避免由于安全認證信息和/或設(shè)備信息的上報不符合服務(wù)器要求的信息，而造成的客戶端與服務(wù)器的多次交互，從而節(jié)省了網(wǎng)絡(luò)資源。值得一提的是，本實施方式中的DS/DM客戶端，還可以包括安全認證模塊，用于在解析出的指示信息并未明確指示是否要求上報安全認證信息時，按默認的認證方式進行安全認證；和記錄模塊，用于在按默認的認證方式進行安全認證成功后，記錄該默認的認證方式。以便在之后的認證中，使用該能夠通過認證的認證方式，從而提高了認證成功的概率。本發(fā)明的第六實施方式涉及一種同步會話發(fā)起系統(tǒng)，如圖11所示，包含DS/DM客戶端，和DS/DM服務(wù)器。在DS/DM服務(wù)器中包括生成模塊，用于生成觸發(fā)建立會話連接的消息，該消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)；和發(fā)送才莫塊，用于將該生成^t塊生成的觸發(fā)建立會話連接的消息，發(fā)送給DS客戶端。其中，數(shù)據(jù)同步機制的協(xié)商參數(shù)包含以下之一或其任意組合用于指示會話內(nèi)容的信息、用于指示會話內(nèi)容長度的信息、用于指示同步方向的信息、用于指示DS服務(wù)器端數(shù)據(jù)條目的標(biāo)識是否有效的信息、用于指示對數(shù)據(jù)的保存情況的信息、用于指示DS服務(wù)器端的修改日志是否有效的信息、用于指示DS服務(wù)器端改變的數(shù)據(jù)項數(shù)目的信息、用于指示決定方向的信息、用于指示DS服務(wù)器是否希望開始連續(xù)的同步會話的信息、用于指示待同步數(shù)據(jù)庫的標(biāo)識的信息、和用于指示該待同步數(shù)據(jù)庫標(biāo)識長度的信息。在DS客戶端中包括接收模塊，用于接收來自DS服務(wù)器的觸發(fā)建立會話連接的消息(該消息即是攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)的消息)，該消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)；解析模塊，用于解析該接收模塊收到的觸發(fā)建立會話連接的消息；選擇模塊，用于根據(jù)該解析模塊從觸發(fā)建立會話連接的消息中解析出的該協(xié)商參數(shù)，選擇同步機制；同步會話發(fā)起模塊，用于使用該選擇模塊所選的同步機制向DS服務(wù)器發(fā)起同步會話。本實施方式中的觸發(fā)建立會話連接的消息可以是Notification消息。由于在觸發(fā)建立會話連接的消息中攜帶了數(shù)據(jù)同步機制的協(xié)商參數(shù)，因此可使得DS客戶端能夠根據(jù)此信息選擇相應(yīng)的同步機制，從而減少了同步機制選擇的會話交互，提高了會話效率。另外，值得一提的是，在DS服務(wù)器的生成模塊生成的觸發(fā)建立會話連接的消息中，還可以攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息。在DS客戶端中，還可以包括發(fā)送模塊，用于在該解析模塊從觸發(fā)建立會話連接的消息中解析出的指示信息為要求上報時，向DS服務(wù)器發(fā)送攜帶安全認證信息和/或設(shè)備信息的發(fā)起會話連接的消息。以免由于安全認證信息和/或設(shè)備信息的上報不符合服務(wù)器要求的信息，而造成客戶端與服務(wù)器的多次交互，從而節(jié)省了網(wǎng)絡(luò)資源。綜上所述，在本發(fā)明的實施方式中，觸發(fā)建立會話連接的消息中攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息，DS/DM客戶端根據(jù)該指示信息決定向DS/DM服務(wù)器發(fā)送的發(fā)起會話連接的消息中，是否需要攜帶安全認證信息和/或設(shè)備信息。由于DS/DM客戶端能夠通過觸發(fā)建立會話連接的消息了解到DS/DM服務(wù)器發(fā)起會話的意圖，因此可避免由于安全認證信息和/或設(shè)備信息的上報不符合服務(wù)器要求的信息，而造成的客戶端與服務(wù)器的多次交互，從而節(jié)省了網(wǎng)絡(luò)資源。觸發(fā)建立會話連接的消息中的指示信息還可以進一步用于指示上報安全認證信息時所使用的機制，和/或上報設(shè)備信息時所使用的方式，使得DS/DM客戶端的上報能夠進一步滿足DS/DM服務(wù)器的需求。如果指示信息并未明確指示是否要求上報安全認證信息，則DS/DM客戶端才姿默i人的iU正方式進^f亍安全iU正，并在iU正成功后，記錄該iU正方式。以便在之后的認證中，使用該能夠通過認證的認證方式，從而提高了認證成功的概率。在觸發(fā)建立會話連接的消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)，使得DS客戶端能夠根據(jù)此信息選擇相應(yīng)的同步機制，從而減少了同步機制選擇的會話交互，提高了會話效率。雖然通過參照本發(fā)明的某些優(yōu)選實施方式，已經(jīng)對本發(fā)明進行了圖示和描述，但本領(lǐng)域的普通技術(shù)人員應(yīng)該明白，可以在形式上和細節(jié)上對其作各種改變，而不偏離本發(fā)明的精神和范圍。權(quán)利要求1.一種會話連接發(fā)起方法，其特征在于，包含以下步驟接收來自數(shù)據(jù)同步或設(shè)備管理DS/DM服務(wù)器的觸發(fā)建立會話連接的消息，該消息中攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息；如果所述指示信息為要求上報，則向所述DS/DM服務(wù)器發(fā)送攜帶安全認證信息和/或設(shè)備信息的發(fā)起會話連接的消息。2.根據(jù)權(quán)利要求1所述的會話連接發(fā)起方法，其特征在于，所述指示信息還用于指示上報的所述安全認證信息所屬的機制；所述安全認證信息所屬的機制為"auth-basic",或為"auth-MD5"。3.根據(jù)權(quán)利要求1所述的會話連接發(fā)起方法，其特征在于，所述指示信息還用于指示上報所述設(shè)備信息時所使用的方式；所述上報所述設(shè)備信息時所使用的方式為以下之一上報完整的設(shè)備信息、上報更新的設(shè)備信息、發(fā)起空會話、上報設(shè)備信息的統(tǒng)一資源標(biāo)識URI鏈接。4.根據(jù)權(quán)利要求3所述的會話連接發(fā)起方法，其特征在于，所述使用發(fā)起空會話的方式上報所述設(shè)備信息的方式如下在收到所述DS/DM服務(wù)器下發(fā)的用于獲取設(shè)備信息的命令時，上報所述設(shè)備信息。5.根據(jù)權(quán)利要求1至4中任一項所述的會話連接發(fā)起方法，其特征在于，所述觸發(fā)建立會話連接的消息為"Notification"消息。6.根據(jù)權(quán)利要求1至4中任一項所述的會話連接發(fā)起方法，其特征在于，還包含以下步驟如果所述指示信息并未明確指示是否要求上報所述安全認證信息，則按默認的認證方式進行安全i人證，并在認i正成功后，記錄該認i正方式。7.根據(jù)權(quán)利要求6所述的會話連接發(fā)起方法，其特征在于，所述記錄的方式:^下將所述默認的認證方式記錄在用于指定i人證方式的認證類型"AAuthPref'節(jié)點中；或者，將所述默認的認證方式記錄在"DMAcc"中擴展的與認證相關(guān)的節(jié)點中，該"DMAcc"為用于管理開放移動聯(lián)盟設(shè)備管理協(xié)議設(shè)置的管理對象。8.—種DS/DM客戶端，其特征在于，包括接收模塊，用于接收來自DS/DM服務(wù)器的觸發(fā)建立會話連接的消息，該消息中攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息；解析模塊，用于解析所述接收模塊收到的觸發(fā)建立會話連接的消息；發(fā)送模塊，用于在所述解析模塊從所述觸發(fā)建立會話連接的消息中解析出所述指示信息為要求上報時，向所述DS/DM服務(wù)器發(fā)送攜帶安全認證信息和/或設(shè)備信息的發(fā)起會話連接的消息。9.根據(jù)權(quán)利要求8所述的DS/DM客戶端，其特征在于，所述指示信息還用于指示上報的所述安全認證信息所屬的機制，和/或指示上報所述設(shè)備信息時所使用的方式。10.根據(jù)權(quán)利要求8所述的DS/DM客戶端，其特征在于，還包含安全認證模塊，用于在所述指示信息并未明確指示是否要求上報所述安全認證信息時，按默認的認證方式進行安全認證；,默i人的iU正方式。11.一種DS/DM服務(wù)器，其特征在于，包括生成模塊，用于生成觸發(fā)建立會話連接的消息，該消息中攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息；發(fā)送模塊，用于將所述生成模塊生成的觸發(fā)建立會話連接的消息，發(fā)送給DS/DM客戶端。12.根據(jù)權(quán)利要求11所述的DS/DM服務(wù)器，其特征在于，所述指示信息還用于指示上報的所述安全認證信息所屬的機制，和/或指示上報所述設(shè)備信息時所使用的方式。全文摘要本發(fā)明涉及通信領(lǐng)域，公開了一種會話連接、同步會話發(fā)起方法及設(shè)備，使得能夠節(jié)省網(wǎng)絡(luò)資源，另外，能夠提高會話效率。本發(fā)明中，觸發(fā)建立會話連接的消息中攜帶表示是否要求上報安全認證信息和/或設(shè)備信息的指示信息，DS/DM客戶端根據(jù)該指示信息決定向DS/DM服務(wù)器發(fā)送的發(fā)起會話連接的消息中，是否需要攜帶安全認證信息和/或設(shè)備信息。觸發(fā)建立會話連接的消息中的指示信息還可以進一步用于指示上報的安全認證信息所屬的機制，和/或上報設(shè)備信息時所使用的方式。在觸發(fā)建立會話連接的消息中攜帶數(shù)據(jù)同步機制的協(xié)商參數(shù)。文檔編號H04L9/32GK101340286SQ20071013772公開日2009年1月7日申請日期2007年5月30日優(yōu)先權(quán)日2007年5月30日發(fā)明者李克鵬,柴曉前,暉趙,琴趙申請人:華為技術(shù)有限公司