174. (Aws/Amazon) [Aws Kinesis Video Streams] WebRTC 중복 SDP Offer 호출 시 Answer 응답 누락 상태 정리

---

[개발 환경 설정]

​

개발 환경 : Aws / Amazon Web Services

​

 

---

[설명 정리]

​

// --------------------------------------------------------------------------------------
[개발 및 환경]
// --------------------------------------------------------------------------------------

- 인프라 : Aws / Amazon Web Services


- 기술 구분 : Aws / Aws Kinesis Video Streams / KVS / WebRTC


- 사전) WebRTC 설명 : 

  >> WebRTC 란 웹, 애플리케이션, 디바이스 간 중간자 없이 오디오나 영상 미디어를 포착하고 실시간 스트림할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술입니다

  >> WebRTC 는 간단한 API 를 통해 웹 브라우저, 모바일 애플리케이션 및 커넥티드 디바이스 간에 실시간 통신을 활성화할 수 있습니다

  >> WebRTC 주요 용어 : 

    - SDP (Session Description Protocol) : 오디오/비디오 코덱, 해상도, 포트 등 스트리밍 정보를 담은 텍스트 포맷
    - Offer / Answer : 통신 연결을 협상하기 위한 SDP 메시지 (초기 연결 설정)
    - ICE (Interactive Connectivity Establishment) : NAT/P2P 환경에서도 연결 가능한 경로(IP, 포트 등)를 찾기 위한 기술
    - Candidate : 가능한 연결 경로 (IP + Port 조합)

  >> WebRTC SDP 오퍼 생성 (뷰어) 및 응답 (마스터) 스트리밍 플로우 : 

    [Viewer → Signaling Server] -- SDP Offer --> [Master] : 뷰어는 마스터로 스트리밍 오퍼 신호 보낸다
    [Master] -- SDP Answer --> [Viewer] : 마스터는 특정 뷰어의 오퍼 신호 확인 후 응답을 보낸다

    [Viewer] -- ICE Candidate --> [Master] : 스트리밍을 할 수 있는 경로 확인
    [Master] -- ICE Candidate --> [Viewer] : 스트리밍을 할 수 있는 경로 확인

    P2P 연결 성립 → 스트리밍 시작

// --------------------------------------------------------------------------------------






// --------------------------------------------------------------------------------------
[설 명]
// --------------------------------------------------------------------------------------

1. SDP Offer 전송 후 Answer 를 받지 못하는 상황 정리 (WebRTC 표준 (브라우저 구현 OR SDK 구현) 에서 자동으로 처리)

  >> ✅ Stable 상태가 아닌데 Offer 가 또 전송된 경우

    A → B : Offer(1)
    (B가 Answer 만들기 전)
    A → B : Offer(2)
    → B는 Offer(1)에 대한 Answer를 버리거나 Offer(2)를 무시

  >> ✅ Glare (동시 Offer 충돌) : 두 Peer 가 동시에 Offer를 보내는 경우

    - Glare 상황에서는 한쪽이 Offer를 버리고 그 Peer가 Rollback → Offer/Answer 순서를 재정렬해야 제대로 동작합니다

    - 임베디드/디바이스 WebRTC에서 glare 처리가 구현되어 있지 않으면 Answer 를 아예 받지 못하는 현상이 발생할 수 있습니다

    - 해당 상황 발생 시 뷰어는 rollback 적용 및 PeerConnection 을 재생성해서 다시 offer 전송을 시도할 수 있습니다

  >> ✅ setLocalDescription / setRemoteDescription 순서 오류 

    - SDP Offer/Answer 는 반드시 하기와 같은 순서가 보장되어야합니다

      $ setLocalDescription(offer)
      $ 상대에게 offer 전송
      $ setRemoteDescription(answer)

  >> ✅ Answer 처리 타이밍이 Offer 전송보다 늦는 경우

    Offer(1) 보냄
    → Answer(1) 조금 늦게 도착
    그 사이 Offer(2) 보냄
    → Answer(1)은 이미 무효 (state mismatch로 drop)
    → Answer(2)는 상대에서 생성되지 않거나 무시됨

  >> ✅ ICE Restart 시 Offer를 연속해서 보내는 경우 (상대가 Answer를 만들지 못함)

    - ICE Restart 역시 Offer를 보내는 작업이기 때문에 정상 Offer 이후 ICE Restart Offer를 너무 빨리 보내면 이전 Offer/Answer 사이클이 끝나기 전에 중첩됨


2. 디바이스 기기 환경에서 Answer 를 응답하지 못하는 흔한 케이스 정리

  >> 네트워크 지연으로 인해 Offer/Answer 타이밍이 뒤틀림

  >> 시그널링 서버에서 메시지가 순서 뒤집힘

  >> 로컬 로직에서 Offer 재발행이 너무 빠르게 일어남

  >> PeerConnection 재생성 없이 Offer만 다시 보내는 구조

  >> 설계 상 “중복 Offer 차단 로직”이 없음


3. ✅ SDP Offer 전송 후 Answer 응답을 받는 지연 시간 상황

  >> 정상적인 환경에서는 200ms ~ 2초 이내가 보통이지만, 특정 조건이 충족되면 10초 ~ 30초까지도 Answer 응답을 받기 까지 지연이 될 수 있습니다.

    - WebRTC는 ICE 후보 수집, STUN/TURN 탐색, 네트워크 NAT 매칭 등 P2P 연결을 위해 많은 비동기 작업을 수행합니다. 따라서 아래 조건이 겹치면 Answer 전송 자체가 딜레이되거나, 생성 지연이 발생할 수 있습니다.

  >> STUN/TURN 탐색 지연 (가장 흔한 원인) : 

    - 네트워크 환경이 좋지 않으면 ICE 후보 수집에 오래 걸립니다

      $ ICE Gathering Timeout (기본 40초까지 가기도 함) 때문에 Answer 생성이 지연됩니다.

    - 대칭 NAT (Symmetric NAT)

    - 방화벽에서 UDP 차단 → TCP fallback
    
    - TURN 서버 응답이 느림 또는 지연

    - 모바일 환경에서 신호 세기 약함

    - 이동통신망 + VPN 조합

  >> 상대 단말기에서 createAnswer() 실행이 늦는 경우 

    - CPU 부하·스레드 블로킹·메인스레드 정체 등으로 이 과정 자체가 밀려서 20초 걸릴 수 있습니다.

  >> 시그널링 서버에서 Offer/Answer 큐가 밀리는 경우

    - 시그널링 서버(WebSocket/MQTT/HTTP)가 다음 상황이면 Answer 전송이 실제로 20초 가까이 늦을 수 있습니다.

    - 메시지 순서 뒤틀림(out-of-order)

    - 큐 적체
    
    - 네트워크 패킷 drop

    - timeout 재전송 로직 동작

  >> ICE 연결성 체크에 실패 → 재시도 후 Answer 전송

    - 일부 WebRTC 구현/SDK는 ICE 연결성 확인이 끝나기 전까지 Answer를 늦게 보내는 설계 을 사용합니다. 이 경우 20~30초는 자연스러운 동작입니다.

  >> Offer를 너무 빨리 여러 번 전송 → 상태 꼬임

    - Offer(1) → Offer(2) → Offer(3) 이런 상황이면 > 상대가 Offer 처리 순서 꼬임 > Answer 생성이 밀림 > 일부 Answer drop > 결과 = Answer 가 재시도되어 20초 후 도착하는 형태도 있음

    - Offer 중복 전송이 원인이라면 다음 방식으로 해결 :

      $ Offer 보내기 전 signalingState == stable 체크
      $ Answer 수신 timeout(예: 10초) 설정 후 재시도
      $ 필요 시 rollback 또는 pc 재생성


4. 플랫폼 별 WebRTC 엔진 구현 방식 : 

  >> Chrome / LibWebRTC 내부 동작

    - 새 Offer 가 들어오면 signalingState != stable 이면 그 Offer 는 Drop

    - 또는 "glare" 상황이면 자동 Rollback → 기존 Offer 무효화

  >> WebRTC Native SDK / 모바일 SDK 

    - WebRTC 엔진(LibWebRTC 기반)이라 동일한 정책 사용

    - 직렬화된 Offer/Answer만 처리하도록 내부 Queue를 유지

  >> 일부 커스텀 SDK(예: IoT/디바이스용 WebRTC 엔진)

    - 충돌 Offer를 자체적으로 무시하거나

    - Err: Already have pending Offer 같은 메시지를 리턴하기도 함

// --------------------------------------------------------------------------------------






// --------------------------------------------------------------------------------------
[참고 사이트]
// --------------------------------------------------------------------------------------

[Aws Kinesis Video Streams] WebRTC SDP 협상 과정 프로세스 정리 정리

https://blog.naver.com/kkh0977/224030054470


[자바스크립트 AWS WebRTC 실시간 동영상 재생 수행]

https://blog.naver.com/kkh0977/223170500993?trackingCode=blog_bloghome_searchlist


[Aws Kvs WebRTC 실시간 영상 재생 관련 구성 요소 및 용어 정리]

https://blog.naver.com/kkh0977/223858189791


[업무 이슈] AWS WebRTC 실시간 비디오 재생 시 Client 클라이언트 연결 접속 및 해제 상태 확인 이슈

https://blog.naver.com/kkh0977/223966952222


[업무 이슈] 안드로이드 웹뷰에서 AWS WebRTC 웹 뷰어 영상 재생 중 앱 화면 종료 시 마스터에서 뷰어 close 상태가 늦게 감지 되는 이슈

https://blog.naver.com/kkh0977/224020488268


[Aws] WebRTC Viewer 뷰어 기기에서 실시간 디바이스 기기 해상도 확인 로직

https://blog.naver.com/kkh0977/224024795533

// --------------------------------------------------------------------------------------

 

---

[참고 사이트]

​

https://blog.naver.com/kkh0977/224030054470

118. (Aws/Amazon) [Aws Kinesis Video Streams] WebRTC SDP 협상 과정 프로세스 정리 정리

---