Chapter 8. RTP의 이해 

SIP 와 SDP 프로토콜의 목적은 실시간으로 음성 및 영상 통화를 위해서 입니다. 이 장에서는 실시간 음성과 영상을 전송하기 위한 표준인 RTP에 대해 설명합니다.   



1. RTP 개요
실시간 음성, 영상 데이타를 IP 네트워크 상에서 전송하기 위해서는 항상 RTP를 사용합니다. RTP는 RFC 1889 A Transport Protocol for Real-Time Applications에 정의되어 있었지만, 2003년 RFC 1889를 대신하는 RFC 3550이 Standards Track으로 채택 되면서, RFC 1889가 폐기되었습니다. 


간략하게 RFC 3550의 앞부분에 명시된 개요 부분을 요약하면, RTP는 Real-time Transport Protocol의 약어로 음성, 영상 또는 시뮬레이션 데이터와 같은 실시간 데이터를 멀티캐스트 또는 유니캐스트 네트워크를 이용하여 전송하는 응용 서비스를 위한 end-to-end 네트워크 전송 프로토콜입니다. RTP는 RTCP (Real-time Control Protocol)에 의해 데이터의 전달 상황을 감시하며, 최소한의 제어 기능과 미디어 식별 기능을 제공합니다. 



2. RTP의 헤더 구조

RTP 패킷 구조를 먼저 보겠습니다. 


 

RTP는 전송프로토콜로 UDP(User Datagram Protocol)과 네트워크 프로토콜로 IP를 이용합니다. RTP가 신뢰할 수 있는 TCP를 이용하지 않고 UDP를 이용하는 것은 실시간 음성 및 영상을 처리하기 때문에 패킷 에러나 손실 발생 시 재전송 매커니즘이 무의미하기 때문입니다. 재전송을 받더라도 이미 재생할 시간이 지나가버린 뒤이기 때문입니다.


RFC 3550에 있는 RTP 헤더 포맷에 대해 살펴보겠습니다.





    • V (version) : 2 bit
      RTP의 Version을 나타냅니다. 현재는 2 값을 표시합니다. 

    • P (padding) : 1 bit
      만일 패킷 마지막에 하나 이상의 패딩 바이트가 있을 경우를 나타냅니다. 패딩 비트는 의미가 없는 비트를 의미하는 것으로 헤더나 패킷의 크기를 일정하게 유지하기 위해 의도적으로 추가하는 비트입니다.

    • X (Extension) : 1 bit
      고정 헤더 이후의 하나의 확장헤더가  추가적으로 있음을 의미합니다. 

    • CC (CSRC Count) : 4 bit
      RTP의 기본 크기인12 바이트 고정헤더 이후에 표시되는 CSRC identifier의 수를 표시합니다. 

    • M (Marker) : 1 bit
      패킷 스트림 내에서 프레임 경계와 같은 중요한 이벤트들을 표시하는 데 이용됩니다. 다음에 오는 PT 필드의 확장을 위해 M 비트를 없애기도 합니다. 

    • PT (Payload Type) : 7bit
      페이로드의 타입은 RTP가 전송하고 있는 내용이 음성 샘플이 G.711또는  H.264로 되어 있는지 등에 대한 정보를 나타냅니다. 또한, 수신 장비가 페이로드 타입을 이해할 수 없다면 반드시 무시해야 합니다. 이 말의 의미는 실제 Payload Type은 Capability Exchange 시에 항상 교환되므로 상호 인지를 하고 있어야 한다는 것입니다. 

    • Sequence number : 16 bit
      Sequence number는 보안상의 이유로 랜덤한 번호에서 시작하지만, 패킷이 증가할 때마다 1씩 증가됩니다. 이를 통해 수신장비는 패킷 손실을 인지하고, 복구 매커니즘을 동작하도록 합니다. 

    • Timestamp : 32 bit
      RTP 패킷의 첫번째 바이트의 샘플링 순간을 나타냅니다. 초기값은 Sequence number와 마찬가지로 랜덤하게 결정됩니다. 만일 샘플링이 160 단위로 발생한다면 각 블럭은 160 단위로 증가하게 될 것입니다. 실제 코덱에 대한  샘플링 레이트는 차이가 있을 수 있습니다.  

    • SSRC (Synchronization Source) Identifier : 32 bit
      동기화 소스로 랜덤하게 결정됩니다. 

    • CSRC (Contributing Source) Identifiers : 32 bit
      다수의 음원이 Audio Mixer를 통해 하나로 통합될 경우 사용되므로 옵션필드입니다. 이 필드를 통해 원 음원에 대해 알려줍니다. 이 목록에서는 모든 음원의 SSRC identifier가 포함됩니다.   


3. 음성 RTP 패킷 분석

음성 품질에 장애가 발생하면 RTP 패킷을 캡쳐해서 재생합니다. 시그널링이 정상적임에도 묵음이거나 음성이 깨진 경우에 자주 사용합니다. 아래 그림은 와이어샤크로 캡쳐한 RTP 패킷의 헤더 부분입니다.   




RTP 패킷을 분석할 때 일반적인 확인 사항을 정리해봅니다.  

    • Payload Type
      Payload Type 은 G.711 PCMU로 엔코딩된 페이로드를 포함하고 있음을 나타냅니다. 

    • SSRC
      동일한 SSRC를 가지므로 같은 미디어 세션의 RTP 패킷입니다. 

    • Sequence Number
      0번에서 1씩 증가하여 14번까지 보입니다. 사이에 빠진 번호가 없으므로 에 네트워크상에서 패킷 손실이 없음을 확인합니다. 국내 전화기의 경우  0에서 시작하는 것이 일반적이며, 외산 전화기는 랜덤하게 시작합니다. 

    • Timestamp
      RTP 페이로드내의 첫 바이트의 샘플링을 기준으로 볼때 패킷은 160 단위로 보냄을 알수 있으며, G.711을 사용하므로 한 패킷은 20ms 단위로 하나의 패킷을 생성합니다.


Timestamp와 Sequence Number는 보안을 이유로 RFC 3550의 권고사항에 따라 랜덤하게 생성하는 것이 좋습니다.



4. 영상 RTP 패킷 분석
아래 그림은 와이어샤크로 캡쳐한 영상 RTP 패킷입니다. 



Payload Type이 H.264이므로 영상을 실어서 보내는 RTP입니다. Timestamp의 시간이 모두 동일한 이유는 영상의 경우 전송할 데이터가 많기 때문에 한 패킷에 모두 전송할 수 없으므로 같은 영상 프레임임을 나타내는 것이며, Sequence number는 단순히 패킷의 순열을 나타내므로 1씩 증가합니다.

음성과 영상 패킷의 가장 큰 차이점은 Payload Type과 Timestamp의 시간 결정 방식입니다. 



5. RTP 관련 장애 처리

RTP 관련한 장애가 발생하였다면, 다음의 경우를 확인해 볼 필요가 있습니다

    • RTP 패킷이 정상적으로 수신되는 가?
      시그널링은 정상적이지만 RTP 패킷이 수신되지 않는 경우가 있습니다. 실제 RTP의 주소가 잘못되었거나, NAT 구간에서 정상적인 처리가 되지 못해 발생합니다.

    • SSRC가 변경되지는 않았는가?
      SSRC가 변경되면 다른 세션으로 인식되므로, 패킷은 폐기됩니다. 

    • Sequence number는 일정하게 증가하는 가?
      경우에 따라 Sequence number가 순차적으로 증가하지 않고 갑자기 증가하거나 감소하는 경우가 있습니다. 예를 들면, 100 다음 101이 와야 하는 데 400번이 오는 경우 입니다. 이럴 경우 수신 장비는 300개의 패킷이 손실된것으로 보고 재생하지 않는 경우가 간혹 있습니다. 또한 100 다음에 60이 왔을 경우에는 이미 받은 패킷으로 인식하고 재생하지 않는 경우가 있습니다. 이 때에 해결방법은 RFC 3550 Appendix A.3 Determining Number of Packets Expected and Lost 에 자세히 나와 있습니다. Appendix A.3에서 말하는 것은 갑자기 비연속적인 Sequence Number가 들어오더라도 3개 이상 연속될 경우 수신장비는 Sequence number가 재설정된것으로 인식하고 재생해야 합니다. 

    • Timestamp는 일정하게 증가하는 가?
      Timestamp를 통해 이 패킷의 재생 시점을 확인할 수 있으므로, 갑자기 감소하거나 크게 증가할 경우 문제를 일으킵니다.

    • 음질에 문제가 있을 경우
      와이어샤크로 RTP 패킷을 캡쳐하였을 경우에 음성 파일로 만들어서 재생할 수 있습니다. 음성 파일에 문제가 있다면, 송신장비에서 문제가 발생한 것이고, 음성 파일에 문제가 없다면 수신장비의 문제입니다. 

    • 일정시간 통화 중 갑자기 종료되는 현상
      통화중에 일정 시간 동안 유지되다가 갑자기 통화가 종료되는 경우는  RTCP를 의심할 필요가 있습니다. 일반적으로 RTCP를 비활성화합니다만, 사용하는 경우가 종종있습니다.

      RTCP는 일정한 간격으로 RTCP의 송신자 보고 및 수신자 보고를 받지 않으면 호가 종료된 것으로 인식합니다. RTP가 지속적으로 동일 세션으로 들어 오더라도 단말은 호를 종료하므로 RTCP를 사용하지 않도록 설정하면 문제가 해결할 수 있습니다.

위의 상황은 어떠한 트리거에 의해 오동작하기 때문에 일어나는 현상으로 장비를 처음부터 잘못 만들었을 확률은 매우 낮습니다. 따라서, 어떤 트리거가 이런 현상을 만드는 지를 찾는 것이 중요합니다. 





마치며 (에필로그)

막장 연재를 마무리짓습니다. 다시는 이런 짓하지말자...









이전글 보기


2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해


2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method


2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method


2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method


2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method


2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method


2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method


2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method


2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method

2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP


2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP


2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP


2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response


2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261


2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261


2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261


2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview


2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview


2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)


2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)


2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)




라인하
트 유씨누스(UCnus) (CCIEV #18487)
  --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일) 
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항) 
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스) 
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스) 
세상을 이롭게 하는 기술을 지향합니다. ________________________________________________________



저작자 표시 비영리
신고
Posted by 라인하트

댓글을 달아 주세요

  1. 2015.07.10 16:47  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다



티스토리 툴바