한 동안 업무에 집중하다 보니 글을 올리는 것이 뜸했습니다. 블로그 관리에 소홀해지지만,가끔 올라오는 댓글에 힘을 냅니다. H.323이나 SIP에 대해서는 패킷 분석을 했었는 데 정작 RTP에 대해서는 언급하지 않아서 이번 글에서 좀 자세히 다루어 보도록 하겠습니다.
프로토콜에 대해 이해하기 가장 빠르고 정확한 방법은 표준안을 보는 것이겠지만, 개발자가 아닌 이상에 엔진이어들이 가만히 앉아서 문서를 보는 것은 쉽지 않은 일입니다. 저 또한 장애처리를 할 경우에 참조용으로 주로 사용합니다만, RFC 문서의 경우는 그나마 쉽게 이해할 수 있도록 정리가 잘 되어 있습니다. 특히, RFC의 앞 개요 및 용어 정의 부분만 읽어도 상당히 업무에 도움이 됩니다. 시간나시면, 관심있는 프로토콜에 대해 읽어보실 것을 권해 보드립니다.
RFC 3550의 개요
실시간 음성, 영상 데이타를 IP 네트워크 상에서 전송하기 위해서는 항상 RTP를 사용합니다. RTP는 RFC 1889 A Transport Protocol for Real-Time Applications에 정의되어 있었지만, 2003년 RFC 1889를 대신하는 RFC 3550이 Standards Track으로 채택 되면서, RFC 1889가 폐기되었습니다. 따라서, 요즘 나오는 음성 및 영상 장비들은 RFC 3550을 지원합니다.
간략하게 RFC 3550의 앞부분에 명시된 개요 부분을 요약하면, RTP는 음성, 영상 또는 시뮬레이션 데이터와 같은 실시간 데이터를 멀티캐스트 또는 유니캐스트 네트워크를 이용하여 전송하는 응용 서비스를 위한 end-to-end 네트워크 전송 프로토콜입니다. RTP는 IP/UDP를 통해 전송되며, RTCP (Real-time Control Protocol)에 의해 데이터의 전달 상황을 감시하며, 최소한의 제어 기능과 미디어 식별 기능을 제공합니다.
RTP는 음성, 영상, 실시간 데이터 등을 전송하기 위한 프로토콜이라는 것을 알 수 있습니다.
RTP의 헤더 구조
프로토콜을 이해하기 위해서는 프로토콜의 헤더 구조를 이해하는 것이 가장 쉽게 이해할 수 있습니다. 다음 그림은 RTP 프로토콜 헤더 구조로써 RFC 3550에서 발췌하였습니다.
V (version) : 2 bit
RTP의 Version을 나타냅니다. 현재는 2 값을 항상 표시합니다.
P (padding) : 1 bit
만일 패킷 마지막에 하나 이상의 패딩 바이트가 있을 경우를 나타냅니다. 패팅 비트란, 의미가 없는 비트를 의미합니다. 패킷을 만들기 위해 의도적으로 추가된 비트입니다.
X (Extension) : 1 bit
고정 헤더 이후의 하나의 확장헤더가 추가적으로 있음을 의미합니다.
CC (CSRC Count) : 4 bit
12 바이트 고정헤더 이후에 표시되는 CSRC identifier의 수를 표시합니다.
M (Marker) : 1 bit
패킷 스트림 내에서 프레임 경계와 같은 중요한 이벤트들을 표시하는 데 이용됩니다. 항상 트러블 슈팅시에 보면 중요할 것 같지만, 별로 의미가 없는 비트입니다. 다음에 오는 PT 필드의 확장하여 표시 비트를 없애기도 합니다.
PT (Payload Type) : 7bit RTP 페이로드의 타입을 나타냅니다. 즉, 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
동기화 소스를 나타내며, 랜덤하게 결정됩니다. 같은 RTP 세션내에 서로 다른 값을 가져야 합니다.
CSRC (Contributing Source) Identifiers : 32 bit
다수의 음원이 Audio Mixer를 통해 하나로 통합될 경우 나타냅니다 .따라서, 이 필드를 통해 원 음원에 대해 나타냅니다. 이 목록에서는 모든 음원의 SSRC identifier가 포함됩니다.
음성 RTP 패킷 분석
기본적인 헤더 구조에 대해 살펴보았지만, 여전히 잘 이해하지 못하리라 생각됩니다. 그럼 실제 패킷을 보면서 다시 한 번 살펴보겠습니다. 일반적으로 Signaling은 정상적으로 이루어졌는 데, 음성이 들리지 않거나 이상하게 들릴경우 RTP를 분석해 볼 필요가 있습니다.
위의 그림은 Ethereal을 통해 RTP 패킷을 캡쳐한 것이며, 일 대일 음성 통화로 단방향만을 캡쳐한 것임을 알수 있습니다. 즉, 221.148.189.104에서 211.41.22.132로 향하는 RTP만이 켭쳐된 것으로, Payload Type이 G.711u 이므로 음성을 전송하는 RTP임을 알 수 있습니다. 아래 그림은 RTP 부분만을 확대하였습니다.
Payload Type 을 보시면 G.711 PCMU로 엔코딩된 페이로드를 포함하고 있음을 나타내며, SSRC가 같으므로, 동일한 세션에서 발생한 음성임을 확인할 수 있습니다. Sequence Number가 0에서 시작하여 1씩 증가하고 있기에 네트워크상에서 패킷 손실이 없음을 확인할 수 있습니다. 일반적으로 국내 전화기의 경우 0에서 시작하는 것이 일반적이며, 외산 전화기는 랜덤하게 시작합니다. Timestamp를 보시면, RTP 페이로드내의 첫 바이트의 샘플링을 기준으로 볼때 패킷은 160 단위로 보냄을 알수 있으며, 시간상으로 보면 일반적으로 20ms 단위로 하나의 패킷이 생성됩니다. Timestamp와 Sequence Number는 보안적인 이슈를 고려한다면, RFC 3550의 권고사항에 따라 랜덤하게 생성하는 것이 더욱 좋으리라 생각됩니다.
영상 RTP 패킷 분석
Payload Type이 H.264이므로 영상임을 짐작할 수 있으며, Timestamp의 시간이 모두 동일한 이유는 영상의 경우 전송할 데이터가 많기 때문에 한 패킷에 모두 전송할 수 없으므로 같은 영상 프레임임을 나타내는 것이며, Sequence number는 단순히 패킷의 순열을 나타내므로 1씩 증가합니다.
음성 또는 영상에 대해 장애 처리 시 확인할 사항
일반적으로 장애처리 시에 다음과 같은 사항을 확인하시면 쉽게 트러블슈팅이 가능합니다.
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를 통해 이 패킷의 재생 시점을 확인할 수 있으므로, 갑자기 감소하거나 크게 증가할 경우 문제를 일으킵니다.
음질에 문제가 있을 경우
Ethereal을 이용하여 RTP 헤더를 페이로드를 분석하거나, 필요시에 음성파일로 만들어 재생해 볼 수 있습니다. 들어보면, 수신장비의 문제인지 송신 장비의 문제인지를 확인할 수 있습니다.
위의 경우 일반적인 상황에서 발생하지 않습니다. 대부분 어떠한 트리거에 의해 오동작하기 때문에 일어나는 현상이며, 이 트리거를 찾아내 해결하는 것이 중요합니다.
경우에 따라, 통화중에 일정하게 통화가 종료되는 경우가 간혹있습니다. 이럴경우는 RTCP를 의심할 필요가 있습니다. 즉, 일정한 간격으로 RTCP의 송신자 보고 및 수신자 보고를 받지 않으면, 호가 종료된 것으로 인식하므로 RTP가 지속적으로 들어오더라도 호를 종료하는 수가 있습니다. 이럴 때는 RTCP를 최초부터 사용하지 않도록 설정하면 문제가 해결됩니다.
