成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

聊聊多人語音通話的基本原理

移動開發
本文主要是介紹一些基本工作原理,包括移動Mesh網絡,VOIP技術等。常見的網絡拓撲結構有點對點拓撲結構、星型拓撲結構、樹型拓撲結構、環型拓撲結構和總線型拓撲結構等。

0.引言

本文主要是介紹一些基本工作原理,包括移動Mesh網絡,VOIP技術等。

1.移動Mesh網絡

1.1 常見的網絡拓撲結構

常見的網絡拓撲結構有點對點拓撲結構、星型拓撲結構、樹型拓撲結構、環型拓撲結構和總線型拓撲結構等。常見網絡拓撲結構如下圖所示: 

聊聊多人語音通話的基本原理

點對點拓撲結構(perr-to-peer,簡稱 P2P),是一種無路由節點、網絡成員直接交換信息的網絡結構。這種結構在通信上較為簡單,但應用開發較為復雜,需要打洞,在有些場景可以應用到。

在星型拓撲結構的網絡中,子節點都直接與中心節點相連,其具有結構簡單,延遲低等優點,但是可靠性較低、部署成本較高。它目前常見于企業、學校和家庭網絡中,運營商網絡由路由器接入后,各個設備通過網絡線纜或者無線網絡連接路由器或交換機接入互聯網。總線型拓撲結構則是一種所有節點掛在同一條總線上的拓撲結構,其沒有網絡中心,這種拓撲結構的優點是可擴展性好,但是維護困難,分支結構定位故障較難。

2.Mesh網絡拓撲結構

Mesh 網絡拓撲結構,是一種在網絡節點上使用動態路由的方式進行數據傳輸的拓撲結構。這種網絡拓撲結構可以保證每個節點與其他節點之間連接的可靠性,當網絡中有某個節點故障時,這種結構允許其他節點使用“跳躍”(hip)的方式形成一條新的、可用的路由進行數據傳輸。

Mesh 網絡具有以下幾個特點:

  • 自組織:網絡節點可以即時加入 Mesh 網絡,網絡拓撲結構會隨之改變,使得該節點可以與網絡中的任意一個節點連接。
  • 自愈性:如果 Mesh 網絡中的網絡成員因為關機、故障等原因不能工作,網絡會自動調整網絡拓撲結構,使得原來被破壞的路由被有效的路由替換。
  • 多跳:Mesh 網絡中的所有節點都具備轉發數據包的能力,網絡中的節點可以通過多跳與物理上不能直接通信的節點進行數據傳輸。

相對于傳統 Wi-Fi 的 AP(Access Point)工作模式使用的星型網絡拓撲結構,Mesh 網絡使用的 Mesh 拓撲結構在網絡成員節點傳輸距離以及移動性上都有了很大的改進。

3.IEEE 802.11s 標準

IEEE 802.11s 是 IEEE(電機電子工程學會)對 802.11 無線網絡協議中無線網狀網絡的補充標準,它定義了無線設備如何交互以組成一個 Mesh 無線局域網,這個網絡的拓撲結構是可以隨時變化的。不同于傳統Ad-Hoc 網絡中使用傳輸層的路由協議實現多跳功能,802.11s 協議擴展了 MAC(媒體訪問控制)層標準,定義了一個使用無線感知進行自配置多跳拓撲結構的架構和協議,其支持包括廣播、組播和單播方式的數據傳輸。

802.11s 使用的路徑選擇協議為混合無線 Mesh 協議(Hybrid Wireless Mesh Protocol,簡稱 HWMP),即同時使用了先驗式路由協議和反應式路由協議,上述路徑選擇協議中包含了四種路徑選擇消息包,分別為根節點通告(Root Announcement,簡稱 RANN)、路徑請求(Path Request,簡稱 PREQ)、路徑回復(Path Reply,簡稱 PREP)和路徑錯誤(Path Error,簡稱 PERR)。混合無線 Mesh 協議如下圖: 

聊聊多人語音通話的基本原理

先驗式路由協議對于網絡中的每個節點,會建立一個樹形的路由拓撲結構,根節點可以通過兩種方式建立路由表,一種是使用根節點宣告包,另一種是使用路徑請求包。

使用根節點宣告包方式其路徑請求是由根節點以外的其他節點以單播的方式發送給根節點,而根節點必須使用路徑回復包進行回復。

使用路徑請求包的方式時,不會使用路徑回復包,而且路徑請求包是由根節點發送的

反應式路由協議,又稱為按需路由協議,是基于 RM-AODV(Radio-Metric Ad hoc On-Demand Distance Vector)的協議,使用路由請求和路由回復機制在兩個節點之間建立路由,節點間使用路由請求包和路由回復包進行信息數據交互,并在路由回復包中采用序列號以保證路由的時效性

目前 IEEE 802.11s 標準已經被 Linux 內核支持,在 Linux 上可以方便地使用支持802.11s 標準的無線網卡組建基于 802.11s 的無線 Mesh 網絡。

4.Vo IP 技術

Vo IP 是一種語音通話技術,通過將語音信號數字化處理、編碼壓縮、網絡傳輸、解碼、還原成音頻信號實現語音通信,其中關鍵技術為語音編碼技術和實時網絡傳輸技術。其流程如下圖所示: 

聊聊多人語音通話的基本原理

5.音頻編碼技術

語音編碼是一種將語音數字信號壓縮的技術。由于數字化的語音信號在存儲、傳輸上的可靠性、抗干擾能力和保密性都遠優于模擬的語音信號,因此,目前幾乎在所有的系統中都采用數字化的方式進行語音的存儲和傳輸。未經過壓縮的語音數據因為體積過大,受限于存儲設備的容量和傳輸網絡的帶寬,不適合直接進行存儲和網絡傳輸,音頻編碼技術應運而生。音頻編碼技術可以大大的壓縮音頻數據的體積,減少了存儲消耗的硬件資源與傳輸占用的帶寬和時間,增加了在有限的資源下可以存儲和傳輸的語音數據量。

根據是否保留原始音頻數據的全部信息,音頻編碼技術通常被分為有損音頻編碼技術和無損音頻編碼技術,有損音頻編碼技術在犧牲部分原始音頻數據的情況下可以達到更高的音頻數據壓縮率,而無損音頻編碼技術則可以還原出完整的原始音頻數據。

在 Vo IP 技術中,由于網絡帶寬的限制,往往會使用有損音頻編碼技術,且這些音頻編碼算法可以達到的壓縮率通常比較高。此外,由于實時網絡傳輸的不可靠性,使用的音頻編碼算法需要具備從殘損數據中獲得接近完整音頻數據的功能。常用的音頻編碼算法有 G.711、G729、AAC、Speex、Opus 等,這些音頻編碼算法壓縮后的音質與比特率的關系對比如下圖所示,延遲與比特率的關系如下圖所示: 

聊聊多人語音通話的基本原理
音頻編碼算法壓縮后的音質與比特率的關系
聊聊多人語音通話的基本原理
部分音頻編碼算法延遲與比特率的關系

如果需要實現多方語音通話功能,對延遲的要求高,由于系統中各成員之間的距離可能較遠,整個網絡的帶寬較小,在保證音頻質量的情況下,音頻數據碼率需要盡可能的低,選擇使用 Opus 音頻編碼算法實現語音數據編解碼。

Opus 是一種有損音頻編碼算法,包含了 SILK 和 CELT 兩種聲音編碼技術,其開發目的是希望用單一格式包含聲音和語音,取代 Speex 和 Vorbis 音頻編碼算法,且適用于網絡上低延遲的實時音頻傳輸。Opus 可以調節編碼比特率,它在較低比特率時使用線性預測編碼,在高比特率時使用變換編碼,非常適合用于低延遲語音通話的編碼。此外 Opus 也可以透過降低編碼比特率,達成更低的算法延遲,最低可以到 5 ms。

6.RTP 實時傳輸協議

RTP 協議是一種基于 IP 網絡傳輸音視頻數據的網絡傳輸協議,它被廣泛應用于通信和流媒體應用,例如語音會話、視頻會議、網絡電視服務等。它在網絡模型中是一個應用層協議,在傳輸層之上,通常 RTP 協議是基于 UDP 協議的,在一些特殊應用場景之下也可以基于 TCP 協議。 

聊聊多人語音通話的基本原理

表中幾個重要的字段的解釋如下:

  • SN(Sequence Number,序列號):為了解決網絡傳輸時時延抖動的問題,RTP協議使用一個長度為 16 位的序列號來確定數據報的順序,每個發出的數據報會被標記上連續的序列號,用于接收端對亂序到達的 RTP 數據報進行排序,同時可以用于統計 RTP 傳輸的丟包情況。
  • PT(Payload Type,負載類型):RTP 協議使用 PT 字段來標識 RTP 報文所傳輸的流媒體數據的類型,常見的數據類型有 AAC、Speex、Opus、H.264 等。
  • Timestamp(時間戳):由于時延抖動的存在,目標主機接收到數據報的順序和時間間隔與發送時的存在偏差,如果每次都立即播放接收到的數據,則播放效果會與我們預期的大不相同。實際中,接收端通常會設置一個播放時延,時間戳在這個時延區間內的包會被存入緩沖區等待播放,即打上發送時間戳。
  • SSRC(Synchronization Source,同步源):RTP 協議在設計之初就考慮到了組播的方式,在進行組播時,IP 地址和端口無法用于確定唯一的一個網絡地址,因此 RTP 協議中使用一個長度為 32 位的字段標識 RTP 包來源,它是一個隨機數,且能保證其在一個 RTP 會話中的唯一性。RTP 協議不僅解決了使用 IP 協議進行實時流媒體數據傳輸時存在的問題,同時也為應用層的流媒體應用程序提供了規范的傳輸協議,使得開發者不需要重復實現類似的私有協議。此外,RTP 協議也是一個開源的協議,開發者可以根據各自的應用需求對其進行修改。

 

 

責任編輯:未麗燕 來源: 今日頭條
相關推薦

2021-02-08 21:40:04

SockmapBPF存儲

2012-01-12 14:37:34

jQuery

2010-08-20 13:29:33

OFDM

2013-04-07 14:09:55

Android應用基本

2020-03-21 14:57:14

手機定位智能手機APP

2009-02-24 09:43:00

IP電話原理

2011-11-29 12:17:00

2010-03-17 13:35:02

2019-11-28 10:45:28

ZooKeeper源碼分布式

2016-08-18 00:04:09

網絡爬蟲抓取系統服務器

2016-08-17 23:53:29

網絡爬蟲抓取系統

2010-06-18 17:28:37

Linux Anacr

2020-11-26 13:54:03

容器LinuxDocker

2011-07-07 14:10:21

Cocoa 內省 hash

2009-06-11 09:56:09

MySQL Repli原理

2020-12-29 16:55:44

ZooKeeper運維數據結構

2011-07-07 14:46:10

Cocoa Xcode

2010-03-18 20:13:03

Java socket

2010-09-26 17:13:31

2013-07-05 14:41:27

Android
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 在线观看亚洲 | 欧美国产日韩一区 | 久久久xxx| 国产99在线 | 欧美 | 精品国产乱码久久久久久蜜退臀 | 久久久精品网站 | 伊人久久在线 | 国产在线精品一区二区 | 久久中文网 | 一区二区三区中文字幕 | 国产ts人妖系列高潮 | av一级| 最新超碰| 久久久久久高潮国产精品视 | 中文字幕亚洲欧美 | 国产精品欧美一区二区三区不卡 | 天天久久| 日韩成人精品一区 | 久久久久久91 | 美女视频一区二区三区 | 成人精品一区二区三区中文字幕 | 欧美视频一区 | 中文字幕日韩欧美一区二区三区 | 精品一区二区电影 | 日韩精品一区二区三区在线播放 | 亚洲激情综合 | 国产精品久久久久久久白浊 | 99精品免费视频 | 激情国产 | 国产成人jvid在线播放 | 欧美国产精品 | 国产91久久久久久久免费 | 亚洲国产精品日本 | 欧美日韩国产一区二区三区不卡 | 亚洲视频在线观看免费 | 在线播放第一页 | 成人av一区二区亚洲精 | 成人av免费网站 | 麻豆av网| 久久久精 | 亚洲精品一区二区在线观看 |