WebRTC通話原理(六)，android開發從入門到精通光碟檔案

會話描述協議Session Description Protocol (SDP) 是一個描述多媒體連線內容的協議，例如解析度，格式，編碼，加密演算法等。所以在資料傳輸時兩端都能夠理解彼此的資料。本質上，這些描述內容的元資料並不是媒體流本身。 從技術上講，SDP並不是一個真正的協議，而是一種資料格式，用於描述在裝置之間共享媒體的連線。SDP包含內容非常多，如下面內容所示為一個SDP資訊。

//版本

v=0

//<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

o=- 3089712662142082488 2 IN IP4 127.0.0.1

//會話名

s=-

//會話的起始時間和結束時間，0代表沒有限制

t=0 0

//表示音訊傳輸和data channel傳輸共用一個傳輸通道傳輸的媒體，通過id進行區分不同的流

a=group:BUNDLE audio data

//WebRTC Media Stream

a=msid-semantic: WMS

//m=audio說明本會話包含音訊，9代表音訊使用埠9來傳輸，但是在webrtc中現在一般不使用，如果設定為0，代表不傳輸音訊

//使用UDP來傳輸RTP包，並使用TLS加密, SAVPF代表使用srtcp的反饋機制來控制通訊過程

//111 103 104 9 0 8 106 105 13 110 112 113 126表示支援的編碼，和後面的a=rtpmap對應

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126

//表示你要用來接收或者傳送音訊使用的IP地址, webrtc使用ICE傳輸，不使用這個地址, 關於ICE是什麼後面2.5節會講到

c=IN IP4 0.0.0.0

//用來傳輸rtcp的地址和埠，webrtc中不使用

a=rtcp:9 IN IP4 0.0.0.0

//ICE協商過程中的安全驗證資訊

a=ice-ufrag:ubhd

a=ice-pwd:l82NnsGm5i7pucQRchNdjA6B

//支援trickle，即sdp裡面只描述媒體資訊, ICE候選項的資訊另行通知

a=ice-options:trickle

//dtls協商過程中需要的認證資訊

a=fingerprint:sha-256 CA:83:D0:0F:3B:27:4C:8F:F4:DB:34:58:AC:A6:5D:36:01:07:9F:2B:1D:95:29:AD:0C:F8:08:68:34:D8:62:A7

a=setup:active

//前面BUNDLE行中用到的媒體標識

a=mid:audio

//指出要在rtp頭部中加入音量資訊

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

//當前客戶端只接受資料，不傳送資料，recvonly,sendonly,inactive,sendrecv

a=recvonly

//rtp,rtcp包使用同一個埠來傳輸

a=rtcp-mux

//下面都是對m=audio這一行的媒體編碼補充說明，指出了編碼採用的編號、取樣率、聲道等

a=rtpmap:111 opus/48000/2

a=rtcp-fb:111 transport-cc

//對opus編碼可選的補充說明，minptime代表最小打包時長是10ms，useinbandfec=1代表使用opus編碼內建fec特性

a=fmtp:111 minptime=10;useinbandfec=1

a=rtpmap:103 ISAC/16000

a=rtpmap:104 ISAC/32000

a=rtpmap:9 G722/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:106 CN/32000

a=rtpmap:105 CN/16000

a=rtpmap:13 CN/8000

a=rtpmap:110 telephone-event/48000

a=rtpmap:112 telephone-event/32000

a=rtpmap:113 telephone-event/16000

a=rtpmap:126 telephone-event/8000

//下面就是對Data Channel的描述，基本和上面的audio描述類似，使用DTLS加密，使用SCTP傳輸

m=application 9 DTLS/SCTP 5000

c=IN IP4 0.0.0.0

//可以是CT或AS，CT方式是設定整個會議的頻寬，AS是設定單個會話的頻寬。預設頻寬是kbps

b=AS:30

a=ice-ufrag:ubhd

a=ice-pwd:l82NnsGm5i7pucQRchNdjA6B

a=ice-options:trickle

a=fingerprint:sha-256 CA:83:D0:0F:3B:27:4C:8F:F4:DB:34:58:AC:A6:5D:36:01:07:9F:2B:1D:95:29:AD:0C:F8:08:68:34:D8:62:A7

a=setup:active

//前面BUNDLE行中用到的媒體標識

a=mid:data

//使用埠5000，一個訊息的大小是1024位元

a=sctpmap:5000 webrtc-datachannel 1024

以上就是一個SessionDescription的例子，雖然沒有video的描述，但是video和audio的描述是十分類似的。 SDP中有關於IP和埠的描述，但是WebRTC技術並沒有使用這些內容，那麼雙方是怎麼建立“直接”連線的呢？建立起連線最關鍵的IP和埠是從哪裡來的呢？這就需要ICE框架來完成這部分工作（參見後面的2.5節）。

注意：SDP由一行或多行UTF-8文字組成，每行以一個字元的型別開頭，後跟等號（“ =”），然後是包含值或描述的結構化文字，其格式取決於型別。以給定字母開頭的文字行通常稱為“字母行”。例如，提供媒體描述的行的型別為“ m”，因此這些行稱為“ m行”。

網路協商

彼此要了解對方的網路情況，這樣才有可能找到一條相互通訊的鏈路。需要做以下兩個處理。

1. 獲取外網IP地址對映。

2. 通過信令伺服器(signal server)交換“網路資訊”。

理想的網路情況是每個瀏覽器的電腦都是公網IP，可以直接進行點對點連線。如圖所示。

實際情況是我們的電腦和電腦之間都是在某個區域網中並且有防火牆，需要NAT(Network Address Translation，網路地址轉換)，如圖所示。

在解決WebRTC使用過程中的上述問題的時候，我們需要用到STUN和TURN。

NAT

NAT（Network Address Translation，網路地址轉換）簡單來說就是為了解決IPV4下的IP地址匱乏而出現的一種技術。 舉例就是通常我們處在一個路由器之下，而路由器分配給我們的地址通常為192.168.1.1 、192.168.1.2如果有n個裝置，可能分配到192.168.1.n，而這個IP地址顯然只是一個內網的IP地址，這樣一個路由器的公網地址對應了n個內網的地址，通過這種使用少量的公有IP 地址代表較多的私有IP 地址的方式，將有助於減緩可用的IP地址空間的枯竭。如圖所示。

NAT技術會保護內網地址的安全性，所以這就會引發個問題，就是當我採用P2P之中連線方式的時候，NAT會阻止外網地址的訪問，這時我們就得采用NAT穿透了。 於是我們就有了如下的思路：我們藉助一個公網IP伺服器，Peer-A與Peer-B都往公網IP/PORT發包,公網伺服器就可以獲知Peer-A與Peer-B的IP/PORT，又由於Peer-A與Peer-B主動給公網IP伺服器發包，所以公網伺服器可以穿透NAT-A與NAT-B併發送包給Peer-A與Peer-B。 所以只要公網IP將Peer-B的IP/PORT發給Peer-A，Peer-A的IP/PORT發給Peer-B。這樣下次Peer-A與Peer-B互相訊息，就不會被NAT阻攔了。 WebRTC的NAT/防火牆穿越技術，就是基於上述的一個思路來實現的。在WebRTC中採用ICE框架來保證RTCPeerConnection能實現NAT穿越。

ICE

ICE（Interactive Connectivity Establishment，互動式連線建立）是一種框架，使各種NAT穿透技術（STUN，TURN…）可以實現統一。該技術可以讓客戶端成功地穿透遠端使用者與網路之間可能存在的各類防火牆。

STUN

NAT 的UDP簡單穿越（Session Traversal Utilities for NAT）是一種網路協議，它允許位於NAT（或多重NAT）後的客戶端找出自己的公網地址，查出自己位於哪種型別的NAT之後以及NAT為某一個本地埠所繫結的Internet端埠。這些資訊被用來在兩個同時處於NAT路由器之後的主機之間建立UDP通訊。如圖2-7所示，STUN伺服器能夠知道Peer-A以及Peer-B的公網IP及埠。

總結

學習技術是一條慢長而艱苦的道路，不能靠一時激情，也不是熬幾天幾夜就能學好的，必須養成平時努力學習的習慣。所以：貴在堅持！

最後如何才能讓我們在面試中對答如流呢？

答案當然是平時在工作或者學習中多提升自身實力的啦，那如何才能正確的學習，有方向的學習呢？有沒有免費資料可以借鑑？為此我整理了一份Android學習資料路線：

這裡是一部分我工作以來以及參與過的大大小小的面試收集總結出來的一套 BAT大廠面試資料專題包 ，在這裡免費分享給大家，主要還是希望大家在如今大環境不好的情況下面試能夠順利一點，希望可以幫助到大家。 需要的小夥伴們可以 點選我的GitHub獲取 免費領取方式

好了，今天的分享就到這裡，如果你對在面試中遇到的問題，或者 剛畢業及工作幾年迷茫不知道該如何準備面試並突破現狀提升自己，對於自己的未來還不夠了解不知道給如何規劃，可以去我的主頁加一下技術群 。來看看同行們都是如何突破現狀，怎麼學習的，來吸收他們的面試以及工作經驗完善自己的之後的面試計劃及職業規劃。

最後，祝願即將跳槽和已經開始求職的大家都能找到一份好的工作！

這些只是整理出來的部分面試題，後續會持續更新，希望通過這些高階面試題能夠降低面試Android崗位的門檻，讓更多的Android工程師理解Android系統，掌握Android系統。喜歡的話麻煩點選一個喜歡再關注一下~