안드로이드 음성 소켓 통신 (2월 단기)

안드로이드-음성을 패킷화 하여 P2P 소켓 통신.

처음엔 TCP로 구현했었는데

서버 과부하를 줄일 수 있도록 P2P로 구현하겠노라 큰소리 쳤습니다.

P2P는 홀펀칭이 필요하며 따라서 TCP로는 어렵다는 것을 알게 되었죠.

각 단말기들이 두개의 포트 즉,
- 음성신호를 녹음해서 보내는 포트
- 음성신호를 받아 처리하는 포트
를 열어 서로가 서로의 서버-클라이언트가 되게 한다는 것이었는데

사설 아이피를 갖는 3G와 4G 환경에서 통신을 시켜주기 위해

STUN Server를 JAVA로 구현했습니다. 사실 진정한 의미의 STUN은 아니었고

말하자면 딱 홀펀칭만 해주는 서버였죠.

다른 해외 논문들에서는 UDP로 symmetric NAT 환경에서도 80~90% 까지

홀펀칭이 잘된다고 나와있지만 제가 했을 땐 그렇진 않았어요.

Cone인데도 안되는 경우가 있었는데, 지금 생각해보면 Lock을 안해줘서 그런것 같네요.

(쓰레드 4개를 돌렸는데 그때 운영체제를 배우지 않아서 세마포어의 개념이 없었음.)


아직도 설날이고 뭐고 다 바쳐서 코딩하다가 결국

4G-4G에서 홀펀칭이 성공하여 전율하며 팀원에게 뛰어갔던

그때가 잊혀지지 않아요.

//////////////////////////////////////////////////////

1.기존의 프로토콜 대신 자체 개발한 새로운 프로토콜-하얍을 사용하는 
STUN(Simple Traversal of UDP Through NAT) 
서버를 외부 라이브러리 없이 직접 구현.

2.STUN서버는 RFC-3489에 기술된 NAT탐색 알고리즘을 사용하지 않고 
바로 홀펀칭을 시도한 후 결과를
클라이언트에게 전달하여 빠른 이니시에이팅이 가능함.

3.UDP패킷 바디에 음성을 그대로 실어 보냄으로써 
딜레이를 최대한으로 줄였음.
임시 테스트(4G-4G , Wifi-Wifi) 결과로는 
현재 어떤 보이스톡 서비스보다 딜레이가 적음.

4.기존의 보이스 톡은 서버경유방식(릴레이)
서버를 통해 가기 때문에 느릴 수밖에 없고
기존의 프로토콜을 그대로 사용하기 때문에 통신사에서 
mVoip 차단 솔루션으로 해당 패킷 랜덤드랍을 
하기가 비교적 쉬움

5.홀펀칭이 실패하는 경우는 Symmetric 기법을 사용하는 NAT환경인데 
IPTime 등에 문의해본 결과 약 5년전에 이미  P2P를 지원하지 못하는
Symmetric 공유기를 모두 Cone 방식으로 교체 하여 기업이 아닌
일반인이 시중에서 Symmetric 공유기를 구매할 수는 없다고 답변.