一種td-lte應(yīng)急通信下的實時語音通信方法
【專利摘要】本發(fā)明請求保護(hù)一種TD-LTE應(yīng)急通信下的實時語音通信方法，屬于應(yīng)急通信【技術(shù)領(lǐng)域】，包括：語音數(shù)據(jù)采集和語音數(shù)據(jù)的G.711壓縮；對壓縮后的數(shù)據(jù)進(jìn)行打包處理；利用TD-LTE網(wǎng)絡(luò)結(jié)合實時傳輸協(xié)議(RTP)對封裝的數(shù)據(jù)包進(jìn)行發(fā)送；接收端接收數(shù)據(jù)包，對其進(jìn)行解包處理并存儲在新的隊列中；使用G.711解碼方案對RTP包進(jìn)行解壓；語音數(shù)據(jù)的回放處理。本發(fā)明針對性的設(shè)計了語音緩存大小和丟包重傳處理方法，整個語音傳輸流程采用ALSA語音處理框架，結(jié)合TD-LTE網(wǎng)絡(luò)的優(yōu)勢，減小了應(yīng)急通信系統(tǒng)中語音通信的傳輸丟包和傳輸時延，滿足了應(yīng)急場景下的實時語音通信要求。
【專利說明】一種TD-LTE應(yīng)急通信下的實時語音通信方法

【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及應(yīng)急通信【技術(shù)領(lǐng)域】，尤其涉及一種TD-LTE應(yīng)急通信系統(tǒng)中實時語音通信的方法。

【背景技術(shù)】
[0002]應(yīng)急通信一般指出現(xiàn)人為或自然的突發(fā)性緊急事件時，利用特定的通信資源，保障救援和必要通信所需的通信手段與方法。在對突發(fā)事件進(jìn)行處理的過程中，保持事發(fā)現(xiàn)場各個救援單位之間以及救援單位與指揮中心的實時通信，尤其是建立快速可靠的語音通信，以便于對救援進(jìn)行有效的指揮調(diào)度，是應(yīng)急通信的一項基本要求。
[0003]實時語音通信最基本的要求是通話清晰，語音延時較小且通信網(wǎng)絡(luò)穩(wěn)定。影響實時通信話音質(zhì)量的因素有很多，需要考慮數(shù)據(jù)的傳輸帶寬和網(wǎng)絡(luò)環(huán)境的穩(wěn)定性。此外，語音延時和數(shù)據(jù)丟包也是影響話音質(zhì)量的關(guān)鍵因素。
[0004]隨著中國移動等電信運(yùn)行商對TD-LTE的加快建設(shè)和部署，國內(nèi)正逐步建成覆蓋全國的寬帶移動通信網(wǎng)絡(luò)。TD-LTE技術(shù)是移動通信與寬帶無線接入融合的典范，也是未來寬帶移動通信的主流標(biāo)準(zhǔn)之一。與現(xiàn)有應(yīng)急通信系統(tǒng)相比，基于TD-LTE技術(shù)的寬帶應(yīng)急通信系統(tǒng)具有更大的信道容量、更高的頻譜利用率、更強(qiáng)的抗干擾能力以及更好的傳輸性能。此外，TD-LTE網(wǎng)絡(luò)提供的下行100Mbps、上行50Mbps的傳輸速率，可以有效的支撐語音、視頻、圖像等實時通信的低延時要求。
[0005]經(jīng)過檢索發(fā)現(xiàn)目前在語音實時通信系統(tǒng)中，對數(shù)據(jù)包最常用的處理方法是在接收端設(shè)置一個接收隊列緩存，利用套接字將RTP包發(fā)送到接收端并存入到前面所述的緩存隊列當(dāng)中，并對數(shù)據(jù)包進(jìn)行重排。當(dāng)該緩存隊列滿時，就會對時間上最先發(fā)送的包進(jìn)行替換。這樣的方法可能會造成同一個語音包被多次接收處理，而且當(dāng)緩存隊列滿時的丟包處理可能會丟失大量的語音數(shù)據(jù)導(dǎo)致解碼回放效果不佳，在緩存隊列中對接收數(shù)據(jù)的重新排列也會增加處理數(shù)據(jù)的延時。
[0006]在眾多的檢索專利文獻(xiàn)中，發(fā)現(xiàn)相關(guān)專利如下:
[0007]一種基于RTP協(xié)議的網(wǎng)絡(luò)抖動處理技術(shù)(CN 103124412A)，該專利對語音數(shù)據(jù)包的處理方法是:接收數(shù)據(jù)并判斷是否為RTP數(shù)據(jù)包包；若是RTP數(shù)據(jù)包則判斷是否為重復(fù)的數(shù)據(jù)包；若不是重復(fù)的數(shù)據(jù)包則對數(shù)據(jù)包進(jìn)行排序，并將數(shù)據(jù)包的發(fā)送時間戳和延時時間按大小順序分別存到數(shù)組中，根據(jù)數(shù)據(jù)包的延時計算出緩存區(qū)大小并將數(shù)據(jù)插入緩存區(qū)；在緩存區(qū)中讀取數(shù)據(jù)播放。對于是否為重復(fù)數(shù)據(jù)包的判斷依據(jù)是數(shù)據(jù)包的發(fā)送時間戳，方法是在時間戳數(shù)組中查找是否存在該時間戳，加大了對數(shù)據(jù)的處理復(fù)雜度。而且在網(wǎng)絡(luò)不穩(wěn)定的情況下，該方法會由于延時的持續(xù)增加而增大其計算出的緩存區(qū)大小，在減小語音抖動的同時可能會加大延時。
[0008]一種即時語音通信方法(CN 101478616A)，此發(fā)明設(shè)計了一個網(wǎng)絡(luò)語音通信軟件平臺，其核心是通過對音頻數(shù)據(jù)中的不同碼率的數(shù)據(jù)采用針對的編碼處理，將處理后的數(shù)據(jù)發(fā)送給接收端的方法來保證其在一定語音碼率范圍內(nèi)的數(shù)據(jù)處理，減小語音傳輸中的失真現(xiàn)象。使用Socket編程技術(shù)完成網(wǎng)絡(luò)通信功能模塊。但是此發(fā)明缺少對數(shù)據(jù)包傳輸?shù)谋Ｕ蠙C(jī)制，在網(wǎng)絡(luò)狀況較差的情況下無法保障通信質(zhì)量。
[0009]根據(jù)以上分析，本發(fā)明設(shè)計一種TD-LTE應(yīng)急通信下的實時語音通信方法。


【發(fā)明內(nèi)容】

[0010]針對以上現(xiàn)有技術(shù)中的不足，本發(fā)明的目的在于提供一種解決現(xiàn)有技術(shù)方法在語音傳輸中的丟包和丟包重傳等問題，保障語音實時通信的方法，本發(fā)明的技術(shù)方案如下:一種TD-LTE應(yīng)急通信下的實時語音通信方法，其包括以下步驟:
[0011]101、在TD-LTE應(yīng)急通信下，采用ALSA語音處理框架對實時語音數(shù)據(jù)進(jìn)行采集，同時調(diào)用ALSA語音處理框架的音頻參數(shù)函數(shù)API完成對聲卡的工作參數(shù)的設(shè)置；
[0012]102、將步驟101中采集的實時語音數(shù)據(jù)傳給基于達(dá)芬奇技術(shù)平臺的G.711語音編碼器進(jìn)行編碼處理，并將編碼后的語音數(shù)據(jù)存放在隊列A中；
[0013]103、將隊列A中存放的編碼后的語音數(shù)據(jù)進(jìn)行封裝處理，并給每一個待發(fā)送的RTP實時傳輸協(xié)議數(shù)據(jù)包添加數(shù)據(jù)包號；
[0014]104、在TD-LTE網(wǎng)絡(luò)下采用Socket編程法將步驟103中封裝的RTP實時傳輸協(xié)議數(shù)據(jù)包傳輸至接收端，同時將此RTP數(shù)據(jù)包放到本地的歷史緩存區(qū)B中；
[0015]105、數(shù)據(jù)接收解包步驟:語音接收線程通過實時傳輸協(xié)議RTP協(xié)議中的輪詢機(jī)制循環(huán)監(jiān)聽指定的端口，接收RTP語音數(shù)據(jù)包，并對其進(jìn)行解包，分析是否發(fā)生丟包或重復(fù)收到RTP數(shù)據(jù)包，并進(jìn)行丟包和重傳處理步驟的判斷；
[0016]106、將接收到的RTP數(shù)據(jù)包采用基于達(dá)芬奇技術(shù)平臺的G.711語音編解碼器進(jìn)行解碼處理；
[0017]107、語音回放，即將解碼后的語音數(shù)據(jù)交給ALSA語音處理框架進(jìn)行回放。
[0018]進(jìn)一步的，步驟105中的丟包重傳處理步驟具體包括如下步驟；:
[0019]S1:發(fā)送端每將一個RTP數(shù)據(jù)包發(fā)送出去后，同時將該RTP數(shù)據(jù)包存放到本地的歷史緩存區(qū)中；
[0020]S2:接收端在接收到發(fā)送端傳輸?shù)腞TP數(shù)據(jù)包后，根據(jù)收到的RTP數(shù)據(jù)包的包號判斷此次傳輸是否發(fā)生丟包，如果沒有發(fā)生丟包，則將該RTP數(shù)據(jù)包放入隊列B中，否則向發(fā)送端發(fā)送重發(fā)請求信息，并將判斷丟失的數(shù)據(jù)包號返回給發(fā)送端；
[0021]S3:發(fā)送端收到接收端發(fā)送的重發(fā)請求信息后，根據(jù)返回數(shù)據(jù)包的包號補(bǔ)發(fā)請求重傳的RTP數(shù)據(jù)包；
[0022]S4:接收端接收到補(bǔ)發(fā)的RTP數(shù)據(jù)包后，將其放入隊列B中等待解碼回放；
[0023]S5:如果接收端再次收到了發(fā)送端補(bǔ)發(fā)過的同一 RTP數(shù)據(jù)包，則向發(fā)送端返回重傳錯誤信息和網(wǎng)絡(luò)阻塞信息；
[0024]進(jìn)一步的，步驟101中音頻參數(shù)函數(shù)API完成對聲卡的工作參數(shù)的設(shè)置的具體參數(shù)包括周期數(shù)per1ds、周期per1d和數(shù)據(jù)訪問模式。
[0025]進(jìn)一步的，步驟103的數(shù)據(jù)打包發(fā)送的內(nèi)容，具體包括語音緩存大小的設(shè)計和RTP數(shù)據(jù)包包號的添加，語音緩存大小結(jié)合MTU值和協(xié)議開銷設(shè)計為1200Byte，由此計算出封裝的RTP數(shù)據(jù)包的時間戳增量為1200。
[0026]進(jìn)一步的，步驟105中判斷是否發(fā)生丟包現(xiàn)象的方法為計算此次收到的RTP數(shù)據(jù)包的包號和前一次收到的RTP數(shù)據(jù)包的包號的差值。如果差值大于1，則發(fā)生丟包現(xiàn)象。
[0027]本發(fā)明的優(yōu)點及有益效果如下:
[0028]本發(fā)明提出一種TD-LTE應(yīng)急通信下的實時語音通信方法，用以解決當(dāng)前現(xiàn)有實時語音通信技術(shù)中的不足。為了減小語音通信的時延，增加語音數(shù)據(jù)的傳輸效率，本發(fā)明設(shè)計一個合理的語音緩存大小，解決了語音緩存過小導(dǎo)致的較低的數(shù)據(jù)傳輸效率和語音緩存過大造成的較大延時的問題。結(jié)合TD-LTE網(wǎng)絡(luò)本身的網(wǎng)絡(luò)優(yōu)勢和技術(shù)特點，進(jìn)一步滿足了實時語音通信的延時、網(wǎng)絡(luò)穩(wěn)定性和帶寬的要求。
[0029]本發(fā)明設(shè)計了一種數(shù)據(jù)丟包重傳處理機(jī)制來應(yīng)對網(wǎng)絡(luò)傳輸過程中的丟包現(xiàn)象，該方法可通過對接收到的相同數(shù)據(jù)包的次數(shù)進(jìn)行統(tǒng)計，作為判斷網(wǎng)絡(luò)阻塞狀況的一項依據(jù)。發(fā)送端可以根據(jù)網(wǎng)絡(luò)的阻塞狀況對數(shù)據(jù)的傳輸策略進(jìn)行調(diào)整，保障實時語音通信的質(zhì)量。

【專利附圖】

【附圖說明】
[0030]圖1是按照本發(fā)明優(yōu)選實施例的實時語音通信流程圖；
[0031]圖2是本發(fā)明的丟包重傳處理方法流程圖。

【具體實施方式】
[0032]下面結(jié)合附圖給出一個非限定的實施例對本發(fā)明作進(jìn)一步的闡述。但是應(yīng)該理解，這些描述只是示例的，而并非要限制本發(fā)明的范圍。此外，在以下說明中，省略了對公知結(jié)構(gòu)和技術(shù)的描述，以避免不必要地混淆本發(fā)明的概念。
[0033]如圖1所示，一個完整的實時語音通信包括以下步驟:
[0034]S1:語音采集。語音采集利用高級Linux聲音架構(gòu)ALSA語音處理框架實現(xiàn)。語音采集包括初始化音頻設(shè)備，即調(diào)用初始化音頻設(shè)備函數(shù)讀入音頻數(shù)據(jù)采集參數(shù)，將各個參數(shù)構(gòu)成參數(shù)結(jié)構(gòu)體之后將此結(jié)構(gòu)體傳遞給打開設(shè)備函數(shù)。調(diào)用打開音頻設(shè)備函數(shù)打開PCM設(shè)備，并將音頻參數(shù)傳遞給設(shè)置音頻參數(shù)函數(shù)。設(shè)置聲卡工作參數(shù)，包括周期數(shù)per1ds、周期per1d和數(shù)據(jù)訪問模式。本發(fā)明的音頻數(shù)據(jù)參數(shù)設(shè)置中音頻數(shù)據(jù)格式可設(shè)置為S8、S16_LE等，可選擇的采樣率有8kHz、16kHz和44.1kHz，聲道數(shù)可選擇I (單聲道)、2 (雙聲道)。以數(shù)據(jù)格式為S16_LE，采樣率8kHz，單聲道為例，可計算編碼前的數(shù)據(jù)流量為16kB/s ;
[0035]S2:語音編碼。語音編碼方案采用基于達(dá)芬奇技術(shù)平臺的G.711語音編解碼器。將語音數(shù)據(jù)采集之后即可調(diào)用G.711語音編碼器對數(shù)據(jù)進(jìn)行編碼處理，并將編碼后的語音數(shù)據(jù)存放在隊列A中。本發(fā)明的編碼動態(tài)參數(shù)和靜態(tài)參數(shù)均采用默認(rèn)參數(shù)設(shè)置，其中frameSize = 160，即編碼前一個語音包的大小為160Byte，compandingLaw = I,即米用A率PCM編碼。G.711的編碼壓縮率為50%，故編碼后一個語音包的大小為80Byte。根據(jù)步驟SI中的音頻參數(shù)選擇可計算壓縮后的數(shù)據(jù)流量為8kB/s ;
[0036]S3:數(shù)據(jù)打包發(fā)送。將編碼輸出的數(shù)據(jù)進(jìn)行封裝處理，對每一個待發(fā)送的RTP數(shù)據(jù)包添加數(shù)據(jù)包號。需要特別指出本發(fā)明對緩存區(qū)大小的設(shè)計，為了提高實時性，發(fā)端需盡快把語音緩存區(qū)中的數(shù)據(jù)發(fā)送出去。本發(fā)明使用UDP發(fā)送封裝好的語音數(shù)據(jù)，UDP發(fā)送數(shù)據(jù)包的最大長度取決于其MTU值的大小。由于UDP本身不提供大塊數(shù)據(jù)分割功能，當(dāng)語音緩存區(qū)太大時，語音層需要分割成小的語音數(shù)據(jù)塊進(jìn)行傳輸，但是拆分?jǐn)?shù)據(jù)塊會加大時間開銷，導(dǎo)致延時增大。另外，網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)包頭部包含了 RTP、UDP等的協(xié)議頭部，如果設(shè)置數(shù)據(jù)塊太小，會降低網(wǎng)絡(luò)傳輸效率。因此需要設(shè)計合適的語音緩存區(qū)大小，來保障實時語音通信的話音質(zhì)量。由于網(wǎng)絡(luò)層IP數(shù)據(jù)報的長度限制為1500Byte，計算上IP數(shù)據(jù)包首部占用的20Byte和UDP數(shù)據(jù)報的首部8Byte，UDP數(shù)據(jù)包的數(shù)據(jù)區(qū)最大長度限制為1472Byte。本發(fā)明設(shè)計RTP數(shù)據(jù)包的包號占用IByte的長度，選擇一個完整RTP包的數(shù)據(jù)量為1200Byte。由于編碼后一個語音包的大小為80Byte，所以一個完整的RTP數(shù)據(jù)包包含15個編碼后的語音包。由此也可以計算出RTP的時間戳增量值為1200 ；
[0037]S4:網(wǎng)絡(luò)傳輸。使用Socket編程技術(shù)將RTP數(shù)據(jù)包傳輸至接收端。網(wǎng)絡(luò)傳輸采用TD-LTE網(wǎng)絡(luò)，保障了實時語音通信的帶寬和延時要求；
[0038]S5:數(shù)據(jù)接收解包。語音接收線程通過RTP協(xié)議中的輪詢機(jī)制循環(huán)監(jiān)聽指定的端口，接收RTP語音數(shù)據(jù)包，并對其進(jìn)行解包分析，確定是否發(fā)生丟包或重復(fù)收到RTP數(shù)據(jù)包，并按照附圖2的方法進(jìn)行丟包和重傳處理；
[0039]S6:語音解碼。語音解碼方案同樣采用基于達(dá)芬奇技術(shù)平臺的G.711語音編解碼器。在接收端從隊列B中取出語音數(shù)據(jù)，調(diào)用G.711語音編碼器對數(shù)據(jù)進(jìn)行解碼處理。本發(fā)明的解碼動態(tài)參數(shù)和靜態(tài)參數(shù)也均采用默認(rèn)參數(shù)設(shè)置；
[0040]S7:語音回放。將解碼后的語音數(shù)據(jù)交給ALSA語音處理框架進(jìn)行回放。如圖2所示，本發(fā)明還設(shè)計了一種丟包重傳處理方法，來解決語音數(shù)據(jù)在傳輸過程中的丟包問題，它包括如下步驟；
[0041]S1:發(fā)送端每將一個RTP數(shù)據(jù)包發(fā)送出去后，同時將該RTP數(shù)據(jù)包存放到本地的歷史緩存區(qū)中；
[0042]S2:接收端在接收到發(fā)送端傳輸?shù)腞TP數(shù)據(jù)包后，根據(jù)收到的RTP數(shù)據(jù)包的包號判斷此次傳輸是否發(fā)生丟包，如果沒有發(fā)生丟包，則將該RTP數(shù)據(jù)包放入隊列B中，否則向發(fā)送端發(fā)送重發(fā)請求信息，并將判斷丟失的數(shù)據(jù)包號返回給發(fā)送端；
[0043]S3:發(fā)送端收到接收端發(fā)送的重發(fā)請求信息后，根據(jù)返回的數(shù)據(jù)包的包號補(bǔ)發(fā)請求重傳的RTP數(shù)據(jù)包；
[0044]S4:接收端接收到補(bǔ)發(fā)的RTP數(shù)據(jù)包后，將其放入隊列B中等待解碼回放；
[0045]S5:如果接收端再次收到了發(fā)送端補(bǔ)發(fā)過的同一 RTP數(shù)據(jù)包，則向發(fā)送端返回重傳錯誤信息和網(wǎng)絡(luò)阻塞信息；
[0046]在上述步驟S2中，判斷是否發(fā)生丟包現(xiàn)象的方法為計算此次收到的RTP數(shù)據(jù)包的包號和前一次收到的RTP數(shù)據(jù)包的包號的差值。如果差值大于1，則發(fā)生丟包現(xiàn)象；
[0047]在上述步驟S5中所提到的再次接收到相同包號RTP數(shù)據(jù)包的現(xiàn)象，是由于RTP包在傳輸過程中的網(wǎng)絡(luò)延時導(dǎo)致UDP “先發(fā)后到”，接收端誤判丟包而要求發(fā)送端補(bǔ)發(fā)同一數(shù)據(jù)包造成的。收到兩個相同包號的RTP數(shù)據(jù)包的現(xiàn)象越頻繁，說明網(wǎng)絡(luò)阻塞現(xiàn)象越嚴(yán)重。因此本發(fā)明可以對收到的相同包號的次數(shù)進(jìn)行統(tǒng)計，作為衡量網(wǎng)絡(luò)阻塞狀況的一個指標(biāo)，進(jìn)而調(diào)整語音數(shù)據(jù)的發(fā)送策略。
[0048]本發(fā)明設(shè)計了一種TD-LTE應(yīng)急通信系統(tǒng)中的實時語音通信方法，更加地設(shè)計了語音緩存大小和丟包重傳處理方法，減小了語音傳輸中的丟包現(xiàn)象和傳輸延時。本發(fā)明結(jié)合TD-LTE網(wǎng)絡(luò)的優(yōu)勢和特點，滿足了應(yīng)急場景下的實時語音通信要求。
[0049]以上這些實施例應(yīng)理解為僅用于說明本發(fā)明而不用于限制本發(fā)明的保護(hù)范圍。在閱讀了本發(fā)明的記載的內(nèi)容之后，技術(shù)人員可以對本發(fā)明作各種改動或修改，這些等效變化和修飾同樣落入本發(fā)明權(quán)利要求所限定的范圍。
【權(quán)利要求】
1.一種TD-LTE應(yīng)急通信下的實時語音通信方法，其特征在于:包括以下步驟: 101、在TD-LTE應(yīng)急通信下，采用ALSA語音處理框架對實時語音進(jìn)行采集，同時調(diào)用ALSA語音處理框架的音頻參數(shù)函數(shù)API完成對聲卡工作參數(shù)的設(shè)置； 102、將步驟101中采集的實時語音數(shù)據(jù)傳給基于達(dá)芬奇技術(shù)平臺的G.711語音編碼器進(jìn)行編碼處理，并將編碼后的語音數(shù)據(jù)存放在隊列A中； 103、對隊列A中存放的語音數(shù)據(jù)進(jìn)行封裝處理，并給每一個待發(fā)送的RTP實時傳輸協(xié)議數(shù)據(jù)包添加數(shù)據(jù)包號； 104、在TD-LTE網(wǎng)絡(luò)下采用Socket編程法將步驟103中封裝的RTP實時傳輸協(xié)議數(shù)據(jù)包傳輸至接收端，同時將此RTP數(shù)據(jù)包放到本地的歷史緩存區(qū)B中； 105、數(shù)據(jù)接收解包步驟:語音接收線程通過實時傳輸協(xié)議RTP協(xié)議中的輪詢機(jī)制循環(huán)監(jiān)聽指定的端口，接收RTP語音數(shù)據(jù)包，并對其進(jìn)行解包，分析是否發(fā)生丟包或重復(fù)收到RTP數(shù)據(jù)包，并進(jìn)行丟包和重傳處理步驟的判斷； 106、將接收到的RTP數(shù)據(jù)包采用基于達(dá)芬奇技術(shù)平臺的G.711語音編解碼器進(jìn)行解碼處理； 107、語音回放，即將解碼后的語音數(shù)據(jù)交給ALSA語音處理框架進(jìn)行回放。
2.根據(jù)權(quán)利要求1所述的一種TD-LTE應(yīng)急通信下的實時語音通信方法，其特征在于:步驟105中的丟包重傳處理步驟具體包括如下步驟: 51:發(fā)送端每將一個RTP數(shù)據(jù)包發(fā)送出去后，同時將該RTP數(shù)據(jù)包存放到本地的歷史緩存區(qū)中； 52:接收端在接收到發(fā)送端傳輸?shù)腞TP數(shù)據(jù)包后，根據(jù)收到的RTP數(shù)據(jù)包的包號判斷此次傳輸是否發(fā)生丟包，如果沒有發(fā)生丟包，則將該RTP數(shù)據(jù)包放入隊列B中，否則，向發(fā)送端發(fā)送重發(fā)請求信息，并將判斷丟失的數(shù)據(jù)包號返回給發(fā)送端； S3:發(fā)送端收到接收端發(fā)送的重發(fā)請求信息后，根據(jù)返回的數(shù)據(jù)包的包號補(bǔ)發(fā)請求重傳的RTP數(shù)據(jù)包； 54:接收端接收到補(bǔ)發(fā)的RTP數(shù)據(jù)包后，將其放入隊列B中等待解碼回放； 55:如果接收端再次收到了發(fā)送端補(bǔ)發(fā)過的同一 RTP數(shù)據(jù)包，則向發(fā)送端返回重傳錯誤信息和網(wǎng)絡(luò)阻塞信息。
3.根據(jù)權(quán)利要求1所述的一種TD-LTE應(yīng)急通信下的實時語音通信方法，其特征在于:步驟101中音頻參數(shù)函數(shù)API完成對聲卡的工作參數(shù)的設(shè)置的具體參數(shù)包括周期數(shù)per1ds、周期per1d和數(shù)據(jù)訪問模式。
4.根據(jù)權(quán)利要求1所述的一種TD-LTE應(yīng)急通信下的實時語音通信方法，其特征在于:步驟103的數(shù)據(jù)打包發(fā)送的內(nèi)容，具體包括語音緩存大小的設(shè)計和RTP數(shù)據(jù)包包號的添加，語音緩存大小結(jié)合MTU值和協(xié)議開銷設(shè)計為1200Byte，由此計算出封裝的RTP數(shù)據(jù)包的時間戳增量為1200。
5.根據(jù)權(quán)利要求1所述的一種TD-LTE應(yīng)急通信下的實時語音通信方法，其特征在于:步驟105中判斷是否發(fā)生丟包現(xiàn)象的方法為計算此次收到的RTP數(shù)據(jù)包的包號和前一次收到的RTP數(shù)據(jù)包的包號的差值。如果差值大于1，則發(fā)生丟包現(xiàn)象。
【文檔編號】H04W28/06GK104506287SQ201410836113
【公開日】2015年4月8日 申請日期:2014年12月29日 優(yōu)先權(quán)日:2014年12月29日
【發(fā)明者】余翔, 吳浩, 黃小敏, 段思睿 申請人:重慶郵電大學(xué)