본문 바로가기

Lecture & Tip/javascript[자바스크립트]

WebRTC 를 이용해 Chrome<->FireFox 간의 통신시 주의점.

오늘도 삽질의 연속입니다.


이번에는 WebRTC가 현재 지원되는 양대 브라우저 Chrome과 FireFox간의 PeerConnection연결시의 삽질기입니다.


기본적으로 PeerConnection의 연결 순서는

방에 들어가는 Guest의 경우에는 PeerConnection생성->Offer 송신->Answer 수신 순입니다.

그리고 반대로 방에 이미 들어와 있는 방장의 경우에는 Offer 수신 -> PeerConnection 생성 -> Answer 송신 순입니다.

이때 미디어스트림의 연결을 위한 ICE는 비동기적으로 연결이 됩니다. PeerConnection이 생성이 되고 LocalDescription이 설정되는 순간 시작됩니다.


오늘 저는 이곳에서 생각지도 못한 일을 보고 말았습니다.


잘될것이라 생각되던 FireFox <-> Chrome 연결이 PeerConnection 메세징 연결은 되는데 ICE가 시작을 안하는 겁니다.

WireShark로 packet 캡춰를 해보니 Chrome에서 Firefox쪽으로 STUN Binding을 시도하는데 계속 Binding Request Error - 401 (UnAuthorized) 라고 저를 괴롭히네요;


그래서 주구장창 삽질에 삽질을 거듭하다 알아버렸습니다...그 이유를 공개합니다~


FireFox의 SDP안에는 Candidate정보가 들어있어 FireFox간의 PeerConnection들은 Candidate의 추가 정보 없이 바로 SDP교환 만으로 연결이됩니다. 하지만 Chrome의 SDP안에는 Candidate정보가 없습니다. 


Chrome의 SDP 

{"sdp":"v=0\r\no=- 2780233228 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE audio video\r\na=msid-semantic: WMS K0XaoVysxEWQmRePgRuqdCkR8bAcMSvQWXBt\r\nm=audio 1 RTP/SAVPF 111 103 104 0 8 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:4Ta+AIUlLaWQVREa\r\na=ice-pwd:+O26tfTqVCo2TBjg55w/TW7C\r\na=ice-options:google-ice\r\na=fingerprint:sha-256 A8:BC:62:5A:CD:DA:3C:1A:51:91:DB:C2:A5:9E:B2:85:82:3B:7E:94:69:6F:16:B6:C0:E8:5F:CB:FC:B0:70:CA\r\na=sendrecv\r\na=mid:audio\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:+tLUInFCoAIDr14V7PymFkNrgtlD/THXqicwsdLI\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=10\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:126 telephone-event/8000\r\na=maxptime:60\r\na=ssrc:1134790672 cname:uls4ib6cKUOZoSSK\r\na=ssrc:1134790672 msid:K0XaoVysxEWQmRePgRuqdCkR8bAcMSvQWXBt K0XaoVysxEWQmRePgRuqdCkR8bAcMSvQWXBta0\r\na=ssrc:1134790672 mslabel:K0XaoVysxEWQmRePgRuqdCkR8bAcMSvQWXBt\r\na=ssrc:1134790672 label:K0XaoVysxEWQmRePgRuqdCkR8bAcMSvQWXBta0\r\nm=video 1 RTP/SAVPF 100 116 117\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:4Ta+AIUlLaWQVREa\r\na=ice-pwd:+O26tfTqVCo2TBjg55w/TW7C\r\na=ice-options:google-ice\r\na=fingerprint:sha-256 A8:BC:62:5A:CD:DA:3C:1A:51:91:DB:C2:A5:9E:B2:85:82:3B:7E:94:69:6F:16:B6:C0:E8:5F:CB:FC:B0:70:CA\r\na=sendrecv\r\na=mid:video\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:+tLUInFCoAIDr14V7PymFkNrgtlD/THXqicwsdLI\r\na=rtpmap:100 VP8/90000\r\na=rtpmap:116 red/90000\r\na=rtpmap:117 ulpfec/90000\r\na=ssrc:1734440088 cname:uls4ib6cKUOZoSSK\r\na=ssrc:1734440088 msid:K0XaoVysxEWQmRePgRuqdCkR8bAcMSvQWXBt K0XaoVysxEWQmRePgRuqdCkR8bAcMSvQWXBtv0\r\na=ssrc:1734440088 mslabel:K0XaoVysxEWQmRePgRuqdCkR8bAcMSvQWXBt\r\na=ssrc:1734440088 label:K0XaoVysxEWQmRePgRuqdCkR8bAcMSvQWXBtv0\r\n","type":"offer"}


Firefox의 SDP


{"sdp":"v=0\r\no=Mozilla-SIPUA-23.0a1 14543 0 IN IP4 0.0.0.0\r\ns=SIP Call\r\nt=0 0\r\na=ice-ufrag:bf658205\r\na=ice-pwd:e36bafda4793a973d11f67d7e5c69229\r\na=fingerprint:sha-256 02:30:EE:83:60:44:91:90:1D:36:54:C3:35:BB:32:46:B4:3D:60:9D:C6:89:DE:37:2A:6D:37:5C:79:A1:F9:E4\r\nm=audio 51868 RTP/SAVPF 109 0 8 101\r\nc=IN IP4 211.195.53.148\r\na=rtpmap:109 opus/48000/2\r\na=ptime:20\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-15\r\na=sendrecv\r\na=candidate:0 1 UDP 2111832319 10.211.55.2 58763 typ host\r\na=candidate:2 1 UDP 2111766783 10.37.129.2 60537 typ host\r\na=candidate:4 1 UDP 2113667327 192.168.10.3 51868 typ host\r\na=candidate:5 1 UDP 1694302207 211.195.53.148 51868 typ srflx raddr 192.168.10.3 rport 51868\r\na=candidate:0 2 UDP 2111832318 10.211.55.2 52716 typ host\r\na=candidate:2 2 UDP 2111766782 10.37.129.2 65239 typ host\r\na=candidate:4 2 UDP 2113667326 192.168.10.3 49396 typ host\r\na=candidate:5 2 UDP 1694302206 211.195.53.148 49396 typ srflx raddr 192.168.10.3 rport 49396\r\nm=video 57151 RTP/SAVPF 120\r\nc=IN IP4 211.195.53.148\r\na=rtpmap:120 VP8/90000\r\na=sendrecv\r\na=candidate:0 1 UDP 2111832319 10.211.55.2 52431 typ host\r\na=candidate:2 1 UDP 2111766783 10.37.129.2 51750 typ host\r\na=candidate:4 1 UDP 2113667327 192.168.10.3 57151 typ host\r\na=candidate:5 1 UDP 1694302207 211.195.53.148 57151 typ srflx raddr 192.168.10.3 rport 57151\r\na=candidate:0 2 UDP 2111832318 10.211.55.2 62458 typ host\r\na=candidate:2 2 UDP 2111766782 10.37.129.2 55023 typ host\r\na=candidate:4 2 UDP 2113667326 192.168.10.3 53994 typ host\r\na=candidate:5 2 UDP 1694302206 211.195.53.148 53994 typ srflx raddr 192.168.10.3 rport 53994\r\n","type":"offer"

}


다시 말해 FireFox는 Chrome으로 부터 받은 SDP만으로는 ICE연결이 되지않고 추가적인 ICE candidate정보를 받아야합니다.


저는 내부적으로 PeerConnection의 onicecandidate 이벤트에서 candidate정보를 받는 시점에 ice candidate를 시작하도록 동기화하였는데

FireFox가 onicecandidate 이벤트에서 candidate정보를 받지 않고 바로 종료해버려 동기화 시점을 놓쳐버렸습니다.


그래서 Chrome에서 추가적인 ICE candidate를 전송하였지만 FireFox에서는 candidate종료되었다고 생각하고 ICE candidate를 받아도 addIceCandidate하지 못하는 우를 범하였습니다;


너무 황당한 일을 겪은터라. 혹시나 비슷한 경험을 하고 계시다면 candidate 처리가 정상적인지 확인해보십시요.

설명이 너무 두서없어 이해가 안되신다면 메일주세용!


덧, FireFox로 테스트중 버그를 보고 찾아보니 Tracking 중인 이슈였습니다. 하지만 NEW!! 금방 수정은 안되겠네요.


https://bugzilla.mozilla.org/show_bug.cgi?id=829591


PeerConnection생성이 안되는 버그인지라 WebRTC 구현중이신 분들에게는 조심할 필요가 있습니다.

문제는 PeerConnection 생성시에 FireFox가 지원하지 않는 option이 들어오면 발생합니다. Chrome의 경우에는 지원하지 않는 옵션은 무시하는데 Firefox는 죽어버리네요;; 


그럼 다들 즐거운 WebRTC하시고 http://www.veckon.com도 많이 애용해주세요~ ^^