專利名稱：背靠背用戶代理及其傳輸信息的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，特別是IP多媒體子系統(tǒng)(IMS, IP Multimedia Subsystem )。
背景技術(shù)：
在IMS網(wǎng)絡(luò)中，許多SIP消息是由用戶代理(UA， User Agent)傳遞的。 由于用戶代理的能力(capability)和特征(characteristics)參差不齊，當(dāng)在 一些對話建立和業(yè)務(wù)開展過程中，中間網(wǎng)元和/或?qū)Χ擞脩舸?，了解其?用戶代理的能力信息是至關(guān)重要的。RFC 3840定義了一種在SIP消息的 Contact頭域的參數(shù)中攜帶用戶代理的能力和特征信息的方法，這樣用戶發(fā)起 注冊或?qū)υ挄r就可以在Contact頭域中將自己的能力和特征信息通知給中間 網(wǎng)元和/或?qū)Χ擞脩舸?，作為中間網(wǎng)元和對端用戶代理處理該對話的 一個 重要參考。如，在會議建立過程中，當(dāng)會議中心邀請用戶加入會議時，可以通過 Contact頭域中的isfocus參數(shù)讓終端感知到當(dāng)前對話的對端是會議中心，從而 可以指導(dǎo)用戶針對會議進(jìn)行相關(guān)操作，如訂閱會議狀態(tài)。RFC 3840所定義的 通過Contact來攜帶終端的能力和特征信息的方法，在信令路徑中都是Proxy 的情況下可以操作的很好；但是，如果信令路徑中存在背靠背用戶代理 (B2BUA， Back to Back User Agent)的話，由于背靠背用戶代理在轉(zhuǎn)發(fā)Invite 消息的同時會修改消息的Contact頭域，因此發(fā)起端UA的能力和特征信息將 在B2BUA處被修改，而無法傳遞到后續(xù)的網(wǎng)元和/或接收對話的UA。請參閱圖l,為現(xiàn)有技術(shù)中的會議申請流程示意圖。步驟S1:用戶發(fā)出INVITE請求，其中攜帶有sip: Conf-Factory，表示 申請會議。
步驟S2:用戶代理1接到該INVITE請求將其轉(zhuǎn)發(fā)。步驟S3:背靠背用戶代理接到該INVITE請求將其轉(zhuǎn)發(fā)。步驟S4:用戶代理2接到該INVITE請求將其轉(zhuǎn)發(fā)至?xí)h中心。步驟S5:會議中心接到該INVITE請求后，返回200 OK響應(yīng)，并在Contact頭域中攜帶Conf-ID及isfocus參數(shù)。步驟S6:用戶代理2接到該200 OK響應(yīng)后，將其轉(zhuǎn)發(fā)給背靠背用戶代理。步驟S7:背靠背用戶代理接到該200OK響應(yīng)后，將Contact頭域修改 為背靠背用戶代理的地址(Contact: B2BUA),然后轉(zhuǎn)發(fā)給用戶代理l。 步驟S8:用戶代理l接到該200OK響應(yīng)后，將其轉(zhuǎn)發(fā)給用戶。 由于背靠背用戶代理將Contact頭域修改為背靠背用戶代理的地址，導(dǎo) 致Contact頭域中原來攜帶Conf-ID及isfocus參數(shù)丟失，使得用戶無法依據(jù) 攜帶Conf-ID及isfocus參數(shù)獲知會議中心的地址，進(jìn)而無法進(jìn)行會議相關(guān) 的操作，從而影響會議業(yè)務(wù)的提供。發(fā)明內(nèi)容為解決現(xiàn)有技術(shù)中，背靠背用戶代理影響會議業(yè)務(wù)的問題，本發(fā)明提供 一種傳輸用戶代理的信息的方法。本發(fā)明還提供一種背靠背用戶代理。一種背靠背用戶代理傳輸信息的方法，其包括如下步驟收到對話建立 請求消息或?qū)υ捊㈨憫?yīng)消息的時，保留消息中原有的Contact頭域，在轉(zhuǎn)發(fā) 消息中添加Record-Route頭域，攜帶背靠背用戶代理自身地址。一種背靠背用戶代理，其包括接收單元、Record-Route處理單元及發(fā)送 單元，該接收單元用于接收對話建立請求消息或?qū)υ捊㈨憫?yīng)消息；該 Record-Route處理單元用于在所述消息中添加Record-Route頭域，內(nèi)容為該
背靠背用戶代理的地址；該發(fā)送單元用于發(fā)送該Record-Route處理單元處理 過的消息。上述背靠背用戶代理的通過Record-Route頭域攜帶路由地址，而不是修 改Contact頭域，使得會議中心在Contact頭域中攜帶的Conf-ID及isfocus 參數(shù)傳輸?shù)接脩簦脩艟涂梢愿鶕?jù)Conf-ID及isfocus參數(shù)進(jìn)行電話會議的 其他相關(guān)操作了，從而保證了會議業(yè)務(wù)的正常開展。


圖1為現(xiàn)有技術(shù)中的會議申請流程示意圖。 圖2為本發(fā)明第一實(shí)施方式會i義申請流程的示意圖。 圖3為本發(fā)明第一實(shí)施方式背靠背用戶代理的示意圖。 圖4為本發(fā)明第二實(shí)施方式對話流程的示意圖。
具體實(shí)施方式
請參閱圖2，為本發(fā)明第一實(shí)施方式會議申請流程的示意圖。由于背靠 背用戶代理在一次對話過程中關(guān)聯(lián)了兩個對話，需要對這兩個對話分別維護(hù) 一個路由集，且這兩個路由集是相互獨(dú)立，因此背靠背用戶代理在收到對話 建立請求消息時，取出對話建立請求消息中的所有的Record-Route保存，作 為對話建立請求方的路由集。背靠背用戶代理在轉(zhuǎn)發(fā)該請求消息時，先去掉 收到的請求中所有的Record-Route,同時為了不修改原請求消息中Contact頭 域又要保證UAS后續(xù)的請求能夠正確的路由到自己，背靠背用戶代理在轉(zhuǎn)發(fā) 的請求消息時添加Record-Route頭域，攜帶該背靠背用戶代理的地址。背靠背用戶代理在收到對話建立請求的響應(yīng)消息時，取出該響應(yīng)消息中的所有的Record-Route并去掉最后一個Record-Route，然后保存，作為到對 話建立響應(yīng)方的路由集。在轉(zhuǎn)發(fā)對話建立請求的響應(yīng)消息時，為了不修改原響應(yīng)消息中Contact 頭域又要保證UAC后續(xù)的請求能夠正確的路由到自己，背靠背用戶代理在響
應(yīng)消息中添加Record-Route頭域，內(nèi)容為自己的地址。步驟l:用戶A發(fā)出INVITE請求，其中攜帶有sip: Conf-Factory，表示申請會議。步驟2:用戶代理1接到該INVITE請求后，在該INVITE請求中添加 Record-Route頭域，內(nèi)容為用戶代理l的地址，然后將其轉(zhuǎn)發(fā)。步驟3:背靠背用戶代理接到該INVITE請求后，為了后續(xù)請求消息能 夠路由至用戶A,背靠背用戶代理通過獲取請求消息中的Record-Route列表 并保存，作為到用戶A的路由集，還需去掉收到的請求中所有的 Record-Route ，然后在該INVITE請求中添加Record-Route頭域，內(nèi)容為背 靠背用戶代理的地址，然后將其轉(zhuǎn)發(fā)。步驟4:用戶代理2接到該INVITE請求后，在該INVITE請求中添加 Record-Route頭域，內(nèi)容為用戶代理2的地址(Record-Route: Proxy2 )，然 后將其轉(zhuǎn)發(fā)給會議中心。步驟5:會議中心接到該INVITE請求后，在Contact頭域中攜帶Conf-ID 及isfocus參數(shù)，然后攜帶Record-Route返回200 OK響應(yīng)。步驟6:用戶代理2接到該200OK響應(yīng)后，將其轉(zhuǎn)發(fā)給背靠背用戶代理。步驟7:背靠背用戶代理接到該200OK響應(yīng)后，背靠背用戶代理可通 過獲取200 OK響應(yīng)消息中的Record-Route列表，并去掉Record-Route列表 中最后一個URI (因?yàn)樽詈笠粋€URI是背靠背用戶代理自己的地址，無需保 存)，然后保存修改后Record-Route列表，作為到會議中心路由集；還需去 掉收到的響應(yīng)消息中所有的Record-Route ,然后在響應(yīng)消息中添加 Record-Route頭域，內(nèi)容為自己的地址；另外，在步驟3中，背靠背用戶代 理已獲得到用戶A的路由集，此時背靠背用戶代理去掉收到的響應(yīng)消息中 所有的Record-Route后，在響應(yīng)消息中添加步驟3保存的用戶A的 Record-Route列表，然后在Record-Route列表頂部添加 一條Record-Route ，
內(nèi)容為背靠背用戶代理(B2BUA)的地址，然后將其轉(zhuǎn)發(fā)給用戶代理1。步驟8:用戶代理l接到該200 OK響應(yīng)后，將其轉(zhuǎn)發(fā)給用戶A，使得 用戶A可以獲得會議中心在Contact頭域中攜帶的Conf-ID及isfocus參數(shù)， 并進(jìn)行會議的后續(xù)操作。由于背靠背用戶代理的路由地址皆保存在Record-Route頭域，而不是修 改Contact頭域，既保證后續(xù)請求的正確路由，又保障Contact頭域中信息的 端到端傳輸，使得會議中心在Contact頭域中攜帶的Conf-ID及isfocus參數(shù) 傳輸?shù)接脩鬉，用戶A就可以根據(jù)Conf-ID及isfocus參數(shù)進(jìn)行電話會議的 其他相關(guān)操作了，從而保證了會議業(yè)務(wù)的正常開展。上述實(shí)施方式不局限于電話會議的對話，還可用于其他形式的對話，如 用戶之間的對話或用戶代理之間的對話等。請參閱圖3，為本發(fā)明第一實(shí)施方式背靠背用戶代理的示意圖。該背靠背 用戶代理單元10包括接收單元2、 Record-Route處理單元5、存儲單元8 及發(fā)送單元9，該接收單元2用于接收消息；該Record-Route處理單元5用 于去掉收到的消息中所有的Record-Route,然后在收到的消息中添加 Record-Route頭域，內(nèi)容為背靠背用戶代理單元自己的地址。該Record-Route 處理單元5還用于獲取請求消息的Record-Route列表作為該請求消息的請求 方的路由集；及獲取響應(yīng)消息的Record-Route列表，并去掉列表中的最后一 個URI(因?yàn)樽詈笠粋€URI是背靠背用戶代理自己的地址，無需保存)，作為 該響應(yīng)消息發(fā)送方的路由集；該存儲單元8用于保存該Record-Route處理單 元5獲取或處理的Record-Route列表；該發(fā)送單元9用于將Record-Route 處理單元處理過的消息發(fā)送出去。請參閱圖4，為本發(fā)明第二實(shí)施方式對話流程的示意圖。該對話流程為 兩個用戶之間的對話流程。步驟01:用戶A發(fā)出INVITE請求，并通過contact頭域攜帶用戶A的 能力信息(contact: A)。
步驟02:用戶代理1接到該INVITE請求后，在該INVITE請求中添加 Record-Route頭域，內(nèi)容為用戶代理1 ( proxyl )的地址，然后將其轉(zhuǎn)發(fā)。步驟03:背靠背用戶代理接到該INVITE請求后，為了后續(xù)請求消息能 夠路由至用戶A，背靠背用戶代理通過獲取請求消息中的Record-Route列表 并保存，作為到用戶A的路由集；還需去掉收到的請求中所有的 Record-Route,然后在該INVITE請求中添加Record-Route頭域，內(nèi)容為背 靠背用戶代理(B2BUA)的地址，然后將其轉(zhuǎn)發(fā)。步驟04:用戶代理2接到該INVITE請求后，在該INVITE請求中添加 Record-Route頭域，內(nèi)容為用戶代理2 ( Proxy2 )的地址，然后將其轉(zhuǎn)發(fā)給 用戶B。步驟05:用戶B接到該INVITE請求后，通過Contact頭域中攜帶用戶 A的能力信息獲知用戶A的能力，然后返回200 OK響應(yīng)，并通過Contact 頭域中攜帶用戶B的能力信息(contact: B),并攜帶請求消息中 Record-Route 。步驟06:用戶代理2接到該200 OK響應(yīng)后，根據(jù)其中的Record-Route 將其轉(zhuǎn)發(fā)給背靠背用戶代理。步驟07:背靠背用戶代理接到該200 OK響應(yīng)后，背靠背用戶代理可 通過獲取200 OK響應(yīng)消息中的Record-Route列表，并去掉Record-Route列 表中最后一個URI (因?yàn)樽詈笠粋€URI是背靠背用戶代理自己的地址，無需 保存)，然后保存修改后Record-Route列表，作為到用戶B的路由集；還需 去掉收到的響應(yīng)消息中所有的Record-Route,然后在響應(yīng)消息中添加 Record-Route頭域，內(nèi)容為自己的地址；另外，在步驟03中，背靠背用戶 代理已荻得到用戶A的路由集，此時背靠背用戶代理去掉收到的響應(yīng)消息 中所有的Record-Route后，在響應(yīng)消息中添加步驟03保存的用戶A的 Record-Route列表，然后在Record-Route列表頂部添力口一條Record-Route， 內(nèi)容為背靠背用戶代理(B2BUA)的地址，然后將其轉(zhuǎn)發(fā)給用戶代理1。
步驟08:用戶代理1接到該200 OK響應(yīng)后，將其轉(zhuǎn)發(fā)給用戶A，使 得用戶A可以獲得用戶B的能力信息，并進(jìn)行后續(xù)操作。步驟09:用戶A發(fā)送ACK消息，其中Requst-URI為用戶B的地址， Route為Proxy 1和B2BUA。步驟010:用戶代理1收到ACK消息后，將其轉(zhuǎn)發(fā)至B2BUA，其中 Requst-URI為用戶B的地址，Route為B2BUA。步驟Oil: B2BUA收到ACK消息后，ACK消息中的Route為背靠背 用戶代理的地址，刪除Route; ACK消息的Request-URI為用戶B的地址； B2BUA需要在轉(zhuǎn)發(fā)的ACK消息中添加到用戶B的路由集，然后轉(zhuǎn)發(fā)至用 戶B， Route為Proxy2。步驟012:用戶代理2收到ACK消息后，將其轉(zhuǎn)發(fā)至用戶B，其中 Requst-URI為用戶B的地址。步驟013:用戶B發(fā)送Bye消息，其中Requst-URI為用戶A的地址， Route為Proxy2和B2BUA。步驟014:用戶代理2收到Bye消息后，將其轉(zhuǎn)發(fā)至B2BUA，其中 Requst-URI為用戶A的地址，Route為B2BUA。步驟015: B2BUA收到Bye消息后，由于Bye消息中的Route為背靠 背用戶代理的地址，則刪除Route，由于Bye消息的Request-URI為用戶A 的地址；B2BUA需要在轉(zhuǎn)發(fā)的Bye消息中添加到用戶A的路由集，然后轉(zhuǎn) 發(fā)至用戶A， Route為Proxyl。步驟016:用戶代理1收到Bye消息后，將其轉(zhuǎn)發(fā)至用戶A,其中 Requst-URI為用戶A的地址。步驟017-020:用戶A經(jīng)由用戶代理1、 B2BUA及用戶代理2向用戶B 返回2000K響應(yīng)消 息。B2BUA在對話建立后，還可以向?qū)υ挼膬啥税l(fā)送對話內(nèi)的請求消息， 如relnvite、 Bye等，在構(gòu)造請求消息的Contact頭域時，可以填B2BUA自
己的地址，也可以填寫接收方的對端的Contact地址，如給用戶B發(fā)relnvite 或Bye時，Contact中填用戶A的地址，但由于relnvite消息會刷新遠(yuǎn)端目 標(biāo)地址(remote target URI),因此建議發(fā)送relnvite時填寫接收方對端的 Contact信息。由于背靠背用戶代理的路由地址皆保存在Record-Route頭域，而不是修 改Contact頭域，既保證后續(xù)請求的正確路由，又保障Contact頭域中信息的端 到端傳輸，使得兩個用戶在對話的過程中可以通過Contact頭域攜帶的能力 信息，用戶獲知對端能力信息帶來方便。上述方法或裝置不限于傳輸能力信息，還可以傳輸通過通過Contact頭域攜帶的其他信息。以上所述，僅為本發(fā)明較佳的具體實(shí)施方式
，但本發(fā)明的保護(hù)范圍并不局 限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易 想到的變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù) 范圍應(yīng)該以權(quán)利要求的保護(hù)范圍為準(zhǔn)。
權(quán)利要求
1. 一種背靠背用戶代理傳輸信息的方法，其包括如下步驟收到對話建立請求消息或?qū)υ捊㈨憫?yīng)消息的時，保留消息中原有的Contact頭域，在轉(zhuǎn)發(fā)消息中添加Record-Route頭域，攜帶背靠背用戶代理自身地址。
2. 如權(quán)利要求1所述的方法，其特征在于進(jìn)一步包括，當(dāng)收到對話 建立請求消息時，保存對話建立請求消息的Record-Route列表，作為到對話 建立請求方的路由集。
3. 如權(quán)利要求1所述的方法，其特征在于進(jìn)一步包括，當(dāng)收到對話 建立響應(yīng)消息時，獲取對話建立響應(yīng)消息中的Record-Route列表，去掉其中 的最后 一個Record-Route后保存，作為到對話建立響應(yīng)方的路由集。
4. 如權(quán)利要求1所述的方法，其特征在于進(jìn)一步包括，收到對話中 請求消息時，當(dāng)對話中請求消息的Route為背靠背用戶代理的地址時，則刪 除Route,在消息中添加到對話中請求消息的Requst-URI中地址的路由集并 轉(zhuǎn)發(fā)。
5. 如權(quán)利要求1至4任意一項(xiàng)所述的方法，其特征在于進(jìn)一步包括， 如果轉(zhuǎn)發(fā)消息中有Record-Route,則去掉轉(zhuǎn)發(fā)消息中的Record-Route。
6. —種背靠背用戶代理，其特征在于，包括接收單元、Record-Route 處理單元及發(fā)送單元，該接收單元用于接收對話建立請求消息或?qū)υ捊㈨?應(yīng)消息；該Record-Route處理單元用于在所述消息中添加Record-Route頭 域，內(nèi)容為該背靠背用戶代理的地址；該發(fā)送單元用于發(fā)送該Record-Route 處理單元處理過的消息。
7. 如;K利要求6所述的背靠背用戶代理，其特征在于該Record-Route 處理單元用于獲取收到的消息中的Record-Route,當(dāng)收到的消息為對話建立 請求消息時，獲取該對話建立請求消息的Record-Route列表作為到對話建立 請求方的路由集；當(dāng)收到的消息為對話建立請求的響應(yīng)消息時，去掉該響應(yīng)消息的Record-Route列表中的最后一個Record-Route,作為到該對話建立響 應(yīng)方的^各由集。
8. 如權(quán)利要求7所述的背靠背用戶代理，其特征在于其進(jìn)一步包括 一存儲單元，用于保存該Record-Route處理單元獲取的Record-Route列表。
9. 如權(quán)利要求6至8任意一項(xiàng)所述的背靠背用戶代理，其特征在于 該Record-Route處理單元還用于去掉所述消息中的Record-Route。
全文摘要
本發(fā)明提供一種背靠背用戶代理傳輸信息的方法，其包括如下步驟收到消息時，保留消息中原有的Contact頭域，在轉(zhuǎn)發(fā)消息中通過添加Record-Route頭域，內(nèi)容為背靠背用戶代理自身地址，以保證后續(xù)請求的正確路由，同時保障Contact頭域中信息的端到端傳輸。本發(fā)明還提供一種背靠背用戶代理。該方法通過Record-Route來保證后續(xù)請求能夠正確路由到B2BUA，而不是修改Contact頭域，使得能力信息可以通過Contact頭域攜帶，從而保證了會議業(yè)務(wù)的正常開展。
文檔編號H04L12/58GK101212418SQ20061006376
公開日2008年7月2日 申請日期2006年12月31日 優(yōu)先權(quán)日2006年12月31日
發(fā)明者楷 文, 楊開封, 蔣群兵, 超 陳 申請人:華為技術(shù)有限公司