數(shù)據(jù)通道建立方法和通信設(shè)備的制造方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及網(wǎng)絡(luò)通信領(lǐng)域,特別涉及一種數(shù)據(jù)通道建立方法和通信設(shè)備。
【背景技術(shù)】
[0002] SCTP(Stream Control Transmission Protocol,流控制傳輸協(xié)議)是 IETF(Internet Engineering Task Force,互聯(lián)網(wǎng)工程任務組)定義的一種可靠的傳輸層協(xié) 議,它在兩個SCTP端點之間提供穩(wěn)定、有序的數(shù)據(jù)傳輸服務。SCTP端點是SCTP分組中邏輯 的接收方或發(fā)送方,兩個SCTP端點之間存在一個SCTP偶聯(lián)。一個SCTP偶聯(lián)下可以有多個 SCTP流,且每個SCTP流都有唯一的流標識。其中,SCTP流是從兩個SCTP端點之間建立的 一個單向邏輯通道,而數(shù)據(jù)通道則是包含一對出入流的雙向邏輯通道,且該對出入流擁有 相同的流標識。
[0003] 數(shù)據(jù)通道提供一種傳輸通道,允許兩個SCTP端點在數(shù)據(jù)通道之上采用數(shù)據(jù)協(xié)議 進行數(shù)據(jù)傳輸。在協(xié)商數(shù)據(jù)通道的過程中,兩個SCTP端點需要經(jīng)過至少一次的協(xié)商以建立 SCTP偶聯(lián),確定數(shù)據(jù)通道所關(guān)聯(lián)的流標識、數(shù)據(jù)通道所對應的標簽以及在數(shù)據(jù)通道上采用 的數(shù)據(jù)協(xié)議等內(nèi)容,并在此基礎(chǔ)上建立數(shù)據(jù)通道。IETF定義了兩種數(shù)據(jù)通道協(xié)商方式。其 中,一種是基于帶內(nèi)的采用DCEP(Data Channel Establishment Protocol,數(shù)據(jù)通道建立協(xié) 議)方式,另一種是基于帶外的采用SDP(Session Description Protocol,會話描述協(xié)議) 方式。
[0004] DCEP方式主要用于在兩個基于瀏覽器的終端之間協(xié)商建立數(shù)據(jù)通道?;跒g覽器 的終端是指采用WebRTC(Web Real-Time Communication,網(wǎng)頁實時通信)技術(shù)實現(xiàn)實時通 信的終端,該實時通信可以包括語音通話、視頻通話、文檔共享、消息收發(fā)等實時的信息交 互。
[0005] SDP方式主要用于在傳統(tǒng)終端與媒體網(wǎng)關(guān)之間、或者傳統(tǒng)終端與傳統(tǒng)終端之間協(xié) 商建立數(shù)據(jù)通道。傳統(tǒng)終端與基于瀏覽器的終端相對應,是指并不采用WebRTC技術(shù)實現(xiàn)通 信的終端。
[0006] 在實現(xiàn)本發(fā)明的過程中,發(fā)明人發(fā)現(xiàn)上述技術(shù)至少存在以下問題:在上述技術(shù)中, 只能夠?qū)崿F(xiàn)當通信兩端均只采用一種數(shù)據(jù)通道協(xié)商方式且該數(shù)據(jù)通道協(xié)商方式為相同的 方式時,通信兩端采用該數(shù)據(jù)通道協(xié)商方式協(xié)商建立數(shù)據(jù)通道。然而,從未來發(fā)展的角度, 為了實現(xiàn)基于瀏覽器的終端與傳統(tǒng)終端之間、或者基于瀏覽器的終端與媒體網(wǎng)關(guān)之間協(xié)商 建立數(shù)據(jù)通道,通信兩端中的至少一端需要同時支持兩種或者兩種以上的數(shù)據(jù)通道協(xié)商方 式。但是,上述技術(shù)并未給出相關(guān)的解決方案,也即當通信兩端中的至少一端同時支持兩種 或者兩種以上的數(shù)據(jù)通道協(xié)商方式時,通信兩端就無法協(xié)商建立數(shù)據(jù)通道。
【發(fā)明內(nèi)容】
[0007] 為了解決【背景技術(shù)】中存在的當通信兩端中的至少一端同時支持兩種或者兩種以 上的數(shù)據(jù)通道協(xié)商方式時,通信兩端就無法協(xié)商建立數(shù)據(jù)通道的問題,本發(fā)明實施例提供 了一種數(shù)據(jù)通道建立方法和通信設(shè)備。所述技術(shù)方案如下:
[0008] 第一方面,提供了一種數(shù)據(jù)通道建立方法,所述方法包括:
[0009] 發(fā)送端向接收端發(fā)送攜帶有第一提議屬性行和第二提議屬性行的提議消息;其 中,所述第一提議屬性行包括所述發(fā)送端支持的數(shù)據(jù)通道協(xié)商方式的信息,所述第二提議 屬性行包括本次請求的數(shù)據(jù)通道協(xié)商方式的信息,所述本次請求的數(shù)據(jù)通道協(xié)商方式為所 述發(fā)送端支持的數(shù)據(jù)通道協(xié)商方式中的一種;
[0010] 發(fā)送端接收所述接收端發(fā)送的應答消息,所述應答消息是所述接收端根據(jù)所述第 一提議屬性行、所述第二提議屬性行以及所述接收端支持的數(shù)據(jù)通道協(xié)商方式確定的;
[0011] 發(fā)送端根據(jù)所述應答消息與所述接收端之間建立數(shù)據(jù)通道;
[0012] 其中,所述發(fā)送端和所述接收端中的至少一端支持兩種或者兩種以上數(shù)據(jù)通道協(xié) 商方式。
[0013] 在第一方面的第一種可能的實施方式中,所述發(fā)送端和所述接收端中的一端支持 的數(shù)據(jù)通道協(xié)商方式包括數(shù)據(jù)通道建立協(xié)議DCEP方式和會話描述協(xié)議SDP方式,且另一端 支持的數(shù)據(jù)通道協(xié)商方式包括所述DCEP方式和所述SDP方式中的至少一種。
[0014] 結(jié)合第一方面或者第一方面的第一種可能的實施方式,在第一方面的第二種可能 的實施方式中,所述提議消息還包括第三提議屬性行,所述第三提議屬性行包括所述發(fā)送 端在所述數(shù)據(jù)通道上支持的數(shù)據(jù)協(xié)議的信息,以便所述接收端根據(jù)所述第三提議屬性行和 所述接收端在所述數(shù)據(jù)通道上支持的數(shù)據(jù)協(xié)議確定出兩端在所述數(shù)據(jù)通道上均支持的數(shù) 據(jù)協(xié)議。
[0015] 結(jié)合第一方面的第一種可能的實施方式或者第一方面的第二種可能的實施方式, 在第一方面的第三種可能的實施方式中,所述發(fā)送端根據(jù)所述應答消息與所述接收端之間 建立數(shù)據(jù)通道,包括:
[0016] 當所述應答消息中攜帶有對應于所述第二提議屬性行的第二應答屬性行時,通過 所述SDP方式與所述接收端之間建立所述數(shù)據(jù)通道;
[0017] 其中,所述第二應答屬性行是所述接收端確定同意采用的數(shù)據(jù)通道協(xié)商方式為所 述SDP方式時生成的。
[0018] 結(jié)合第一方面的第一種可能的實施方式或者第一方面的第二種可能的實施方式, 在第一方面的第四種可能的實施方式中,所述發(fā)送端根據(jù)所述應答消息與所述接收端之間 建立數(shù)據(jù)通道,包括:
[0019] 當所述應答消息中未攜帶有對應于所述第二提議屬性行的第二應答屬性行時,根 據(jù)所述應答消息中攜帶的對應于所述第一提議屬性行的第一應答屬性行檢測兩端是否均 支持所述DCEP方式;
[0020] 若檢測出兩端均支持所述DCEP方式,則通過所述DCEP方式與所述接收端之間建 立所述數(shù)據(jù)通道。
[0021] 結(jié)合第一方面的第二種可能的實施方式,在第一方面的第五種可能的實施方式 中,所述發(fā)送端接收所述接收端發(fā)送的應答消息之后,還包括:
[0022] 發(fā)送端讀取所述應答消息中攜帶的對應于所述第三提議屬性行的第三應答屬性 行,所述第三應答屬性行是所述接收端根據(jù)所述第三提議屬性行和所述接收端在所述數(shù)據(jù) 通道上支持的數(shù)據(jù)協(xié)議確定出兩端在所述數(shù)據(jù)通道上均支持的數(shù)據(jù)協(xié)議后生成的;
[0023] 發(fā)送端根據(jù)所述第三應答屬性行確定在所述數(shù)據(jù)通道上傳輸?shù)臄?shù)據(jù)協(xié)議。
[0024] 第二方面,提供了一種數(shù)據(jù)通道建立方法,所述方法包括:
[0025] 接收端接收發(fā)送端發(fā)送的攜帶有第一提議屬性行和第二提議屬性行的提議消息; 其中,所述第一提議屬性行包括所述發(fā)送端支持的數(shù)據(jù)通道協(xié)商方式的信息,所述第二提 議屬性行包括本次請求的數(shù)據(jù)通道協(xié)商方式的信息,所述本次請求的數(shù)據(jù)通道協(xié)商方式為 所述發(fā)送端支持的數(shù)據(jù)通道協(xié)商方式中的一種;
[0026] 接收端根據(jù)所述第一提議屬性行、所述第二提議屬性行以及接收端支持的數(shù)據(jù)通 道協(xié)商方式確定應答消息;
[0027] 接收端向所述發(fā)送端發(fā)送所述應答消息,以便所述發(fā)送端根據(jù)所述應答消息與所 述接收端之間建立數(shù)據(jù)通道;
[0028] 其中,所述接收端和所述發(fā)送端中的至少一端支持兩種或者兩種以上數(shù)據(jù)通道協(xié) 商方式。
[0029] 第三方面,提供了 一種通信設(shè)備,所述通信設(shè)備包括:
[0030] 發(fā)送模塊,用于向接收端發(fā)送攜帶有第一提議屬性行和第二提議屬性行的提議消 息;其中,所述第一提議屬性行包括所述發(fā)送端支持的數(shù)據(jù)通道協(xié)商方式的信息,所述第二 提議屬性行包括本次請求的數(shù)據(jù)通道協(xié)商方式的信息,所述本次請求的數(shù)據(jù)通道協(xié)商方式 為所述發(fā)送端支持的數(shù)據(jù)通道協(xié)商方式中的一種;
[0031] 應答接收模塊,用于接收所述接收端發(fā)送的應答消息,所述應答消息是所述接收 端根據(jù)所述第一提議屬性行、所述第二提議屬性行以及所述接收端支持的數(shù)據(jù)通道協(xié)商方 式確定的;
[0032] 通道建立模塊,用于根據(jù)所述應答消息與所述接收端之間建立數(shù)據(jù)通道;
[0033] 其中,所述發(fā)送端和所述接收端中的至少一端支持兩種或者兩種以上數(shù)據(jù)通道協(xié) 商方式。
[0034] 第四方面,提供了 一種通信設(shè)備,所述通信設(shè)備包括:
[0035] 接收模塊,用于接收發(fā)送端發(fā)送的攜帶有第一提議屬性行和第二提議屬性行的提 議消息;其中,所述第一提議屬性行包括所述發(fā)送端支持的數(shù)據(jù)通道協(xié)商方式的信息,所述 第二提議屬性行包括本次請求的數(shù)據(jù)通道協(xié)商方式的信息,所述本次請求的數(shù)據(jù)通道協(xié)商 方式為所述發(fā)送端支持的數(shù)據(jù)通道協(xié)商方式中的一種;
[0036] 應答確定模塊,用于根據(jù)所述第一提議屬性行、所述第二提議屬性行以及接收端 支持的數(shù)據(jù)通道協(xié)商方式確定應答消息;
[0037] 應答發(fā)送模塊,用于向所述發(fā)送端發(fā)送所述應答消息,以便所述發(fā)送端根據(jù)所述 應答消息與所述接收端之間建立數(shù)據(jù)通道;
[0038] 其中,所述接收端和所述發(fā)送端中的至少一端支持兩種或者兩種以上數(shù)據(jù)通道協(xié) 商方式。
[0039] 本發(fā)明實施例提供的技術(shù)方案帶來的有益效果是:
[0040] 通過發(fā)送端向接收端發(fā)送攜帶有第一提議屬性行和第二提議屬性行的提議消息, 接收接收端發(fā)送的應答消息,該應答消息是接收端根據(jù)第一提議屬性行、第二提議屬性行 以及接收端支持的數(shù)據(jù)通道協(xié)商方式確定的,并根據(jù)應答消息與接收端之間建立數(shù)據(jù)通 道;解決了當通信兩端中的至少一端同時支持兩種或者兩種以上的數(shù)據(jù)通道協(xié)商方式時, 通信兩端就無法協(xié)商建立數(shù)據(jù)通道的問題;當兩端中的至少一端支持兩種或兩種以上數(shù)據(jù) 通道協(xié)商方式時,通過兩端對數(shù)據(jù)通道協(xié)商方式的協(xié)商確定,進而在此基礎(chǔ)上完成數(shù)據(jù)通 道的建立,使得兩端能夠簡單、高效地建立數(shù)據(jù)通道,實現(xiàn)了不同終端、不同網(wǎng)絡(luò)之間的互 連互通。
【附圖說明】
[0041] 為了更清楚地說明本發(fā)明實施例中的技術(shù)方案,下面將對實施例描述中所需要使 用的附圖作簡單地介紹,顯而易見地,下面描述中的附圖僅僅是本發(fā)明的一些實施例,對于 本領(lǐng)域普通技術(shù)人員來講,在不付出創(chuàng)造性勞動的前提下,還可以根據(jù)這些附圖獲得其他 的附圖。
[0042] 圖1是本發(fā)明各個實施例所涉及的一種實施環(huán)境的結(jié)構(gòu)示意圖;
[0043] 圖2是本發(fā)明一個實施例提供的數(shù)據(jù)通道建立方法的方法流程圖;
[0044] 圖3是本發(fā)明另一實施例提供的數(shù)據(jù)通道建立方法的方法流程圖;
[0045] 圖4是本發(fā)明再一實施例提供的數(shù)據(jù)通道建立方法的方法流程圖;
[0046] 圖5是本發(fā)明還一實施例提供的數(shù)據(jù)通道建立方法的方法流程圖;
[0047] 圖6是本發(fā)明一個實施例提供的通信設(shè)備的結(jié)構(gòu)方框圖;
[0048] 圖7是本發(fā)明另一實施例提供的通信設(shè)備的結(jié)構(gòu)方框圖;
[0049] 圖8是本發(fā)明再一實施例提供的通信設(shè)備的結(jié)構(gòu)方框圖;
[0050] 圖9是本發(fā)明還一實施例提供的通信設(shè)備的結(jié)構(gòu)方框圖;
[0051] 圖10是本發(fā)明一個實施例所提供的發(fā)送端的結(jié)構(gòu)示意圖;
[0052] 圖11是本發(fā)明一個實施例所提供的接收端的結(jié)構(gòu)示意圖。
【具體實施方式】
[0053] 為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚,下面將結(jié)合附圖對本發(fā)明實施方 式作進一步地詳細描述。
[0054] 發(fā)明人發(fā)現(xiàn):當兩端中至少一端同時支持兩種或者兩種以上的數(shù)據(jù)通道協(xié)商方式 時,兩端之間需要通過協(xié)商確定最終采用的數(shù)據(jù)通道協(xié)商方式,并在此基礎(chǔ)上采用協(xié)商確 定的數(shù)據(jù)通道協(xié)商方式完成數(shù)據(jù)通道的建立。下面,將通過具體的實施例對本發(fā)明提供的 技術(shù)方案進行詳細介紹和說明。
[0055] 請參考圖1,其示出了本發(fā)明各個實施例所涉及的一種實施環(huán)境的結(jié)構(gòu)示意圖。該 實施環(huán)境包括:發(fā)送端120和接收端140。
[0056] 發(fā)送端120和接收端140可以同為基于瀏覽器的終端,也可以同為傳統(tǒng)終端,還可 以一端為基于瀏覽器的終端且另一端為傳統(tǒng)終端。在上述情況下,發(fā)送端120和接收端140 之間可以通過有線網(wǎng)絡(luò)或者無線網(wǎng)絡(luò)相連。
[0057] 或者,當發(fā)送端120或者接收端140中的一端為媒體網(wǎng)關(guān)時,另一端可以是基于瀏 覽器的終端或者傳統(tǒng)終端。
[0058] 其中,基于瀏覽器的終端是指采用WebRTC技術(shù)實現(xiàn)實時通信的終端,該實時通信 可以包括語音通話、視頻通話、文檔共享、消息收發(fā)等實時的信息交互;而傳統(tǒng)終端與基于 瀏覽器的終端相對應,是指并不采用WebRTC技術(shù)實現(xiàn)通信的終端。上述終端設(shè)備可以是手 機、平板電腦、電子書閱讀器、MP3 (Moving Picture Experts Group Audio Layer III,動態(tài)影 像專家壓縮標準音頻層面 3)播放器、MP4 (Moving Picture Experts Group Audio Layer IV, 動態(tài)影像專家壓縮標準音頻層面4)播放器、膝上型便攜計算機、臺式計算機和會議終端等 等。
[0059] 需要說明的一點是:在圖1所示的實施環(huán)境中,發(fā)送端120和接收端140的類型、 數(shù)量以及連接關(guān)系僅是示例性的。在實際應用中,發(fā)送端120和接收端140即為協(xié)商建立 數(shù)據(jù)通道以進行數(shù)據(jù)傳輸?shù)耐ㄐ艃啥?,且兩者的位置、功能可以互換。
[0060] 另外,在本發(fā)明各個實施例中,所涉及的通信設(shè)備可以是上文介紹的終端設(shè)備,也 可以是媒體網(wǎng)關(guān),或者其它用于協(xié)商建立數(shù)據(jù)通道以進行數(shù)據(jù)傳輸?shù)脑O(shè)備。
[0061] 請參考圖2,其示出了本發(fā)明一個實施例提供的數(shù)據(jù)通道建立方法的方法流程圖, 本實施例以該數(shù)據(jù)通道建立方法應用于圖1所示實施環(huán)境中的發(fā)送端側(cè)來舉例說明。該數(shù) 據(jù)通道建立方法可以包括如下幾個步驟:
[0062] 步驟202,發(fā)送端向接收端發(fā)送攜帶有第一提議屬性行和第二提議屬性行的提議 消息。
[0063] 其中,第一提議屬性行包括發(fā)送端支持的數(shù)據(jù)通道協(xié)商方式的信息,第二提議屬 性行包括本次請求的數(shù)據(jù)通道協(xié)商方式的信息,且本次請求的數(shù)據(jù)通道協(xié)商方式為發(fā)送端 支持的數(shù)據(jù)通道協(xié)商方式中的一種。
[0064] 其中,數(shù)據(jù)通道協(xié)商方式的信息,可以是明確的數(shù)據(jù)通道協(xié)商方式,也可以是能表 明數(shù)據(jù)通道協(xié)商方式的信息,這里不限定具體形式。
[0065] 步驟204,發(fā)送端接收接收端發(fā)送的應答消息,該應答消息是接收端根據(jù)第一提議 屬性行、第二提議屬性行以及接收端支持的數(shù)據(jù)通道協(xié)商方式確定的。
[0066] 步驟206,發(fā)送端根據(jù)應答消息與接收端之間建立數(shù)據(jù)通道。
[0067] 其中,發(fā)送端和接收端中的至少一端支持兩種或者兩種以上數(shù)據(jù)通道協(xié)商方式。
[0068] 可選的,發(fā)送端和接收端中的一端支持的數(shù)據(jù)通道協(xié)商方式包括DCEP方式和SDP 方式,且另一端支持的數(shù)據(jù)通道協(xié)商方式包括DCEP方式和SDP方式中的至少一種。
[0069] 可選的,若本次請求的數(shù)據(jù)通道協(xié)商方式為DCEP方式,則第二提議屬性行還包括 任意流標識符。該任意流標識符用于表示數(shù)據(jù)通道關(guān)聯(lián)的流標識為任意的,以便接收端在 確定出兩端均支持的數(shù)據(jù)通道協(xié)商方式包括DCEP方式時,根據(jù)任意流標識符確定同意采 用的數(shù)據(jù)通道協(xié)商方式為DCEP方式?;蛘?,
[0070] 若本次請求的數(shù)據(jù)通道協(xié)商方式為DCEP方式,則第二提議屬性行還包括任意流 標識符。該任意流標識符用于表示數(shù)據(jù)通道關(guān)聯(lián)的流標識為任意的,以便接收端在確定出 兩端均支持的數(shù)據(jù)通道協(xié)商方式有且只有SDP方式時,生成包括數(shù)據(jù)通道關(guān)聯(lián)的流標識為 指定流標識符的第二應答屬性行,該指定流標識符是接收端確定的?;蛘?,
[0071] 若本次請求的數(shù)據(jù)通道協(xié)商方式為SDP方式,則第二提議屬性行還包括指定流標 識符。該指定流標識符用于表示數(shù)據(jù)通道關(guān)聯(lián)的流標識為指定的,以便接收端在確定出兩 端均支持的數(shù)據(jù)通道協(xié)商方式包括SDP方式時,根據(jù)指定流標識符確定同意采用的數(shù)據(jù)通 道協(xié)商方式為SDP方式。或者,
[0072] 若本次請求的數(shù)據(jù)通道協(xié)商方式為SDP方式,則第二提議屬性行還包括指定流標 識符。該指定流標識符用于表示數(shù)據(jù)通道關(guān)聯(lián)的流標識為指定的,以便接收端在確定出兩 端均支持的數(shù)據(jù)通道協(xié)商方式有且只有DCEP方式時,確定同意采用的數(shù)據(jù)通道協(xié)商方式 為DCEP方式。
[0073] 可選的,提議消息還包括第三提議屬性行,該第三提議屬性行包括發(fā)送端在數(shù)據(jù) 通道上支持的數(shù)據(jù)協(xié)議的信息,以便接收端根據(jù)第三提議屬性行和接收端在數(shù)據(jù)通道上支 持的數(shù)據(jù)協(xié)議確定出兩端在數(shù)據(jù)通道上均支持的數(shù)據(jù)協(xié)議。
[0074] 可選的,該數(shù)據(jù)通道建立方法還可以包括:
[0075] 第一,發(fā)送端根據(jù)發(fā)送端在數(shù)據(jù)通道上支持的數(shù)據(jù)協(xié)議對應的應用的數(shù)量a確定 本次請求建立的數(shù)據(jù)通道的數(shù)量a,a > 1。其中,每種數(shù)據(jù)協(xié)議對應于至少一種應用。
[0076] 本步驟可以包括如下兩種可能的實現(xiàn)方式:
[0077] 1、若本次請求的數(shù)據(jù)通道協(xié)商方式為DCEP方式,則生成a個第二提議屬性行。其 中,每個第二提議屬性行包括一個流標識和一個標簽,且不同的第二提議屬性行中包括的 流標識均為任意流標識符,不同的第二提議屬性行中包括的標簽為互不相同的標簽,每個 標簽對應于一條數(shù)據(jù)通道。
[0078] 2、若本次請求的數(shù)據(jù)通道協(xié)商方式為SDP方式,則生成a個第二提議屬性行。其 中,每個第二提議屬性行包括一個流標識和一個標簽,且不同的第二提議屬性行中包括的 流標識為互不相同的指定流標識符,不同的第二提議屬性行中包括的標簽為互不相同的標 簽,每個標簽對應于一條數(shù)據(jù)通道。
[0079] 第二,發(fā)送端根據(jù)本次請求的數(shù)據(jù)通道協(xié)商方式生成a個第二提議屬性行。
[0080] 可選的,第三提議屬性行的確定過程可以包括如下幾個步驟:
[0081] 第一,對于發(fā)送端在數(shù)據(jù)通道上支持的每一個數(shù)據(jù)協(xié)議,發(fā)送端獲取數(shù)據(jù)協(xié)議對 應的應用的數(shù)量。
[0082] 第二,發(fā)送端根據(jù)數(shù)據(jù)協(xié)議對應的應用的數(shù)量為數(shù)據(jù)協(xié)議分配相同數(shù)量的標簽, 每個標簽為a個第二提議屬性行中包括的a個互不相同的標簽中的一個。
[0083] 第三,發(fā)送端將數(shù)據(jù)協(xié)議對應的協(xié)議標識與數(shù)據(jù)協(xié)議所分配的標簽進行關(guān)聯(lián)。
[0084] 第四,發(fā)送端生成包括各個數(shù)據(jù)協(xié)議對應的協(xié)議標識以及每個協(xié)議標識關(guān)聯(lián)的標 簽的第三提議屬性行。
[0085] 可選的,上述步驟206可以包括如下兩種可能的實現(xiàn)方式:
[0086] 1、當應答消息中攜帶有對應于第二提議屬性行的第二應答屬性行時,通過SDP方 式與接收端之間建立數(shù)據(jù)通道。其中,第二應答屬性行是接收端確定同意采用的數(shù)據(jù)通道 協(xié)商方式為SDP方式時生成的。
[0087] 2、當應答消息中未攜帶有對應于第二提議屬性行的第二應答屬性行時,根據(jù)應答 消息中攜帶的對應于第一提議屬性行的第一應答屬性行檢測兩端是否均支持DCEP方式; 若檢測出兩端均支持DCEP方式,則通過DCEP方式與接收端之間建立數(shù)據(jù)通道。
[0088] 可選的,上述步驟204之后,還可以包括如下幾個步驟:
[0089] 第一,發(fā)送端讀取應答消息中攜帶的對應于第三提議屬性行的第三應答屬性行。 該第三應答屬性行是接收端根據(jù)第三提議屬性行和接收端在數(shù)據(jù)通道上支持的數(shù)據(jù)協(xié)議 確定出兩端在數(shù)據(jù)通道上均支持的數(shù)據(jù)協(xié)議后生成的。
[0090] 第二,發(fā)送端根據(jù)第三應答屬性行確定在數(shù)據(jù)通道上傳輸?shù)臄?shù)據(jù)協(xié)議。
[0091] 綜上所述,本實施例提供的數(shù)據(jù)通道建立方法,解決了當通信兩端中的至少一端 同時支持兩種或者兩種以上的數(shù)據(jù)通道協(xié)商方式時,通信兩端就無法協(xié)商建立數(shù)據(jù)通道的 問題;當兩端中的至少一端支持兩種或兩種以上數(shù)據(jù)通道協(xié)商方式時,通過兩端對數(shù)據(jù)通 道協(xié)商方式的協(xié)商確定,進而在此基礎(chǔ)上完成數(shù)據(jù)通道的建立,使得兩端能夠簡單、高效地 建立數(shù)據(jù)通道,實現(xiàn)了不同終端、不同網(wǎng)絡(luò)之間的互連互通。
[0092] 另外,通過在第二提議屬性行中攜帶任意流標識符或者指定流標識符,可以使得 接收端在確定采用SDP方式建立數(shù)據(jù)通道時,在應答消息中直接反饋數(shù)據(jù)通道關(guān)聯(lián)的流標 識,避免兩端在后續(xù)過程中對流標識的進一步協(xié)商;或者,使得接收端在確定采用DCEP方 式建立數(shù)據(jù)通道時,可以生成未攜帶