Computer Networking - VOIP

Computer-Network-VOIP

VOIP

목표
- Low playout delay
- low late loss rate
네트워크 딜레이를 계속 추정 + 마진을 넣어 딜레이를 가변적으로 적용
1. 각 Talk spurt 첫부분에 딜레이를 적용
2. Slience 구간이 지난 이후
3. 다음 Talk spurt이 시작 될 때 딜레이를 재계산하여 적용
패킷 딜레이 계산 방법

image
- TCP RTT 추정할 때 그 방식 그대로 씀

패킷 유실이 없다면, 타임스탬프 확인
- Talkspurt 내의 패킷들은 20ms 간격임
- 그 이상 딜레이가 있었다는 것은 그 사이에 Silence 구간이 있었다는 것
  - Seq1 →(40ms)→ Seq2
패킷 유실이 있었던 것 같다면
- 타임스탬프 뿐만 아니라 시퀀스 넘버도 확인
- Seq1 →(40ms)→ Seq3

VOIP는 딜레이가 많이 없어야함
- 기존의 ACK/NAK 방식은 딜레이가 많이 걸릴 수 밖에 없음
- 그럼 어떻게 복구해야 할까?
  - Foward Error Correction (FEC)
    - 재전송을 하지 않고 충분한 비트를 미리 보내서 보낸 데이터를 바탕으로 복구

N개의 청크 그룹마다 하나의 추가적인 청크를 만듬
- 원본 청크들를 XOR하여 만듬
- 결과적으로 N+1 개의 청크가 되어 Bandwith도 1/N 늘어나는 셈
예시) 1010이라는 청크가 있다고 하면 → 10100 으로 됨
- 각각의 자리를 XOR하여 비트를 만듬
  
  image
- 만약 10X00 으로 하나의 청크가 로스되었다면?
  - 정상적으로 수신한 청크들을 다시 각각의 자리로 XOR하면 로스된 패킷을 알 수 있음
조건 : N+1에서 최대한 1개까지 패킷 로스됬을 때 복구 가능
또 N이 커질수록 패킷 유실 확률이 커지므로 적절한 값 정해야 함

P2P 컴포넌트들
- 클라이언트
  - 서로간에 직접 연결하여 통화
- 수퍼노드
  - 특별한 기능을 가진 스카이프 Peer
  - 자신에게 접속해있는 클라이언트 리스트 유지
- 오버레이 네트워크
  - 수퍼노드들은 서로간에 네트워크를 형성
  - 서로 유저 리스트 등 보관 및 공유
- 스카이프 로그인 서비스
동작 방법
1. 수퍼노드에 접속 (TCP)
2. 로그인 서버를 통해 로그인
3. 수퍼노드를 통해 전화할 유저의 IP 주소 가져옴
4. 얻은 IP 주소를 통해 전화
문제
- 전화할 두 사람이 NAT 뒤에 있다면?
  - Peer in NAT → Peer out of NAT : 연결 가능
  - Peer out of NAT → Peer in NAT : 연결 불가능
- 그래서 수퍼 노드를 이용해 중개하는 방식을 씀
  - A Peer in NAT → 수퍼노드 A
  - B Peer in NAT → 수퍼노드 B
  - 수퍼노드 A ↔ 수퍼노드 B

Sending 64 kbps PCM-encoded voice over RTP
- Application collects encoded data in chunks
  - Every 20 msec = 160 bytes in a chunk
- Audio chunk + RTP header from RTP packet in UDP segment
RTP header indicates type of audio encoding in each packet
- Sender can change encoding during conference
RTP header contains seq_num, timestamps

RTCP는 전체 대역폭의 5%만 차지하자
너무 많이 리포트 보내면 메인 미디어 대역폭을 너무 잡아먹으니
Example: Sender가 2Mbps로 데이터를 보낸다면
- 100Kbps만 RTCP가 쓰자
  - 여기서도 75%는 Receiver가, 25%만 Sender가 쓰자
    - 여기서도 Receiver가 많을 수 있기에 이 75Kbps를 균등하게 나눠 사용