本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
使用 WebRTC 對 Amazon Kinesis Video Streams 進行故障診斷
使用下列資訊來疑難排解使用 Amazon Kinesis Video Streams with WebRTC 時可能遇到的常見問題。
建立peer-to-peer工作階段的問題
WebRTC 可協助減輕因下列原因發生的問題:
-
網路位址轉譯 (NAT)
-
防火牆
-
對等之間的代理
WebRTC 提供架構,只要對等連線,即可協助交涉和維護連線。它還提供一種機制,用於透過TURN伺服器轉送媒體,以防無法交涉peer-to-peer連線。
鑑於建立連線所需的所有元件,請務必了解一些可用於協助疑難排解建立工作階段相關問題的工具。
工作階段描述協定 (SDP) 優惠和答案
工作階段描述通訊協定 (SDP) 提供並回答會初始化對等之間的 RTC 工作階段。
若要進一步了解 SDP 通訊協定,請參閱 規格
-
優惠是由「檢視者」所產生,他們想要連接到在 Kinesis Video Streams with WebRTC 中以「主要」身分連線至訊號頻道的對等。
-
答案由優惠的接收者產生。
優惠和答案都是在用戶端產生,雖然它們可能包含到目前為止已收集的 ICE 候選項目。
適用於 C 的 Kinesis Video Streams WebRTC 開發套件
若要stdout從 SDK 將 SDPs記錄到 ,請設定下列環境變數:export DEBUG_LOG_SDP=TRUE。您也可以使用 sdpOffer事件,在 JavaScript 型用戶端中記錄 SDP 優惠和答案。若要查看此示範,請參閱 GitHub
如需其他資訊,請參閱 使用 WebRTC 監控 Kinesis 影片串流。
如果未傳回 SDP 答案,則對等可能無法接受 SDP 優惠,因為優惠不包含任何相容的媒體轉碼器。您可能會看到類似以下的日誌:
I/webrtc_video_engine.cc: (line 808): SetSendParameters: {codecs: [VideoCodec[126:H264]], conference_mode: no, extensions: [], extmap-allow-mixed: false, max_bandwidth_bps: -1, mid: video1}
E/webrtc_video_engine.cc: (line 745): No video codecs supported.
E/peer_connection.cc: (line 6009): Failed to set remote video description send parameters for m-section with mid='video1'. (INVALID_PARAMETER)
E/peer_connection.cc: (line 3097): Failed to set remote offer sdp: Failed to set remote video description send parameters for m-section with mid='video1'.
E/KinesisVideoSdpObserver: onSetFailure(): Error=Failed to set remote offer sdp: Failed to set remote video description send parameters for m-section with mid='video1'.
D/KVSWebRtcActivity: Received SDP offer for client ID: null. Creating answer
E/peer_connection.cc: (line 2373): CreateAnswer: Session error code: ERROR_CONTENT. Session error description: Failed to set remote video description send parameters for m-section with mid='video1'..
E/KinesisVideoSdpObserver: onCreateFailure(): Error=Session error code: ERROR_CONTENT. Session error description: Failed to set remote video description send parameters for m-section with mid='video1'..
當您檢閱 SDP 優惠內容時,請尋找開頭為 的行a=rtpmap,以查看正在請求哪些媒體轉碼器。
...
a=rtpmap:126 H264/90000
...
a=rtpmap:111 opus/48000/2
...
如果您使用 Safari 做為檢視器連線至主要傳送 H.265 媒體,且您遇到下列情況:
InvalidAccessError: Failed to set remote answer sdp: Called with SDP without DTLS fingerprint.InvalidAccessError: Failed to set remote answer sdp: rtcp-mux must be enabled when BUNDLE is enabled.
確認問題是由瀏覽器產生的 SDP 優惠所造成。在 SDP 優惠中,搜尋從 開始的行a=rtpmap,並檢查 H.265 行是否存在。它應該如下所示:
a=rtpmap:104 H265/90000
如果不存在,請在 Safari 設定中啟用適用於 WebRTC 的 H.265 轉碼器。
在 Safari 頂端導覽中,執行下列動作:
-
選取 Safari > 設定... > 進階。選取顯示 Web 開發人員的功能方塊。
-
選取特徵旗標。選取 WebRTC H265 轉碼器方塊。
重新啟動您的瀏覽器,讓變更生效。
評估 ICE 候選項目產生
ICE 候選項目是由對STUN伺服器進行呼叫的每個用戶端產生。對於使用 WebRTC 的 Kinesis Video Streams,STUN伺服器為 stun:stun.kinesisvideo.{aws-region}.amazonaws.com:443。
除了呼叫STUN伺服器以取得候選項目之外,用戶端通常也會呼叫TURN伺服器。他們會進行此呼叫,以便在無法建立直接peer-to-peer連線時使用轉送伺服器做為備用連線。
您可以使用下列工具來產生 ICE 候選項目:
-
Trickle ICE WebRTC 範例
,使用 Trickle ICE 來收集候選者
使用這兩種工具。您可以輸入 STUN和 TURN 伺服器資訊來收集候選項目。
若要使用 WebRTC 取得 Kinesis Video Streams 的TURN伺服器資訊和必要的登入資料,您可以呼叫 GetIceServerConfig API 操作。
下列 AWS CLI 呼叫示範如何取得此資訊,以便在這兩個工具中使用。
export CHANNEL_ARN="YOUR_CHANNEL_ARN" aws kinesisvideo get-signaling-channel-endpoint \ --channel-arn $CHANNEL_ARN \ --single-master-channel-endpoint-configuration Protocols=WSS,HTTPS,Role=MASTER
get-signaling-channel-endpoint 命令的輸出會傳回如下所示的回應:
{
"ResourceEndpointList": [
{
"Protocol": "HTTPS",
"ResourceEndpoint": "https://your-endpoint.kinesisvideo.us-east-1.amazonaws.com"
},
{
"Protocol": "WSS",
"ResourceEndpoint": "wss://your-endpoint.kinesisvideo.us-east-1.amazonaws.com"
}
]
}
使用 HTTPS ResourceEndpoint值來取得TURN伺服器清單,如下所示:
export ENDPOINT_URL="https://your-endpoint.kinesisvideo.us-east-1.amazonaws.com" aws kinesis-video-signaling get-ice-server-config \ --channel-arn $CHANNEL_ARN \ --service TURN \ --client-id my-amazing-client \ --endpoint-url $ENDPOINT_URL
回應包含TURN伺服器詳細資訊,包括 TCP 和 UDP 的端點,以及存取它們所需的登入資料。
注意
回應中的 TTL 值會決定這些登入資料有效的持續時間,以秒為單位。在 Trickle ICE WebRTC 範例
決定使用哪些候選項目來建立連線
了解哪些候選者用於成功建立工作階段會很有幫助。如果您有以瀏覽器為基礎的用戶端執行已建立的工作階段,您可以使用內建的 webrtc-internals 公用程式,在 Google Chrome 中判斷此資訊。
在一個瀏覽器索引標籤中開啟 WebRTC 工作階段。
在另一個索引標籤中,開啟 chrome://webrtc-internals/。您可以在此索引標籤中檢視有關進行中工作階段的所有資訊。
您將看到已建立連線的相關資訊。例如:
您也可以確認已建立連線的指標,如下所示。
ICE 相關逾時
在 KvsRtcConfiguration
檢閱日誌的預設設定:
2024-01-08 19:43:44.433 INFO iceAgentValidateKvsRtcConfig():
iceLocalCandidateGatheringTimeout: 10000 ms
iceConnectionCheckTimeout: 12000 ms
iceCandidateNominationTimeout: 12000 ms
iceConnectionCheckPollingInterval: 50 ms
如果您的網路品質不佳,並且想要提高連線機會,請嘗試調整下列值:
-
iceLocalCandidateGatheringTimeout- 提高此逾時限制,以收集其他潛在候選者來嘗試連線。目標是嘗試所有可能的候選配對,因此如果您的網路狀況不佳,請提高此限制,以便有更多時間收集。例如,如果主機候選項目無法運作,且需要嘗試伺服器反射 (srflx) 或轉送候選項目,您可能需要增加此逾時。由於網路不佳,系統會緩慢地收集候選項目,而應用程式不想在此步驟上花費超過 20 秒。增加逾時可提供更多時間來收集潛在候選者以嘗試連線。
注意
我們建議此值小於
iceCandidateNominationTimeout,因為 推薦步驟需要時間來處理新的候選項目。 -
iceConnectionCheckTimeout- 在不穩定或緩慢的網路中增加此逾時,其中封包交換和繫結請求/回應需要時間。增加此逾時允許至少一個候選配對嘗試由其他對等進行提名。 -
iceCandidateNominationTimeout- 增加此逾時,以確保嘗試與本機轉送候選項目的候選配對。例如,如果收集第一個本機轉送候選項目大約需要 15 秒,請將逾時設定為超過 15 秒的值,以確保嘗試與本機轉送候選項目配對以取得成功。如果值設定為小於 15 秒,則 SDK 會在嘗試潛在候選配對時遺失,導致連線建立失敗。
注意
我們建議此值大於
iceLocalCandidateGatheringTimeout,以便產生效果。 -
iceConnectionCheckPollingInterval- 此值預設為每個規格50 毫秒。變更此值會變更連線檢查的頻率,基本上會變更 ICE 狀態機器轉換的頻率。 在具有良好系統資源的可靠、高效能網路設定中,您可以降低 值,以協助更快速建立連線。增加 值有助於降低網路負載,但建立連線的速度可能會變慢。
重要
我們不建議變更此預設值。