SIP RTP

Overview

RTP 내용정리

Basic

실시간 음성, 영상 데이터를 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)에 의해 데이터의 전달 상황을 감시하며, 최소한의 제어 기능과 미디어 식별 기능을 제공한다.

Protocol

RTP는 전송 프로토콜로 UDP(User Datagram Protocol)과 네트워크 프로토콜로 IP를 이용한다. RTP가 신뢰할 수 있는 TCP를 이용하지 않고 UDP를 이용하는 이유는 실시간 음성 및 영상은 패킷 에러나 패킷 소실이 발생하더라도 TCP 재전송 매커니즘을 활용할 수 없기 때문이다. 재전송된 패킷은 수신 단말이 재생해야 할 시점을 이미 지나버린 이후가 될 확률이 높아 패킷을 폐기한다.

RTP 패킷당 페이로드 크기
--------------------------------------------------------------
| Ethernet(18 bytes) | IP(20 bytes) | RTP(12 bytes) | Sample |
--------------------------------------------------------------

섀논과 나이키스트 정리에 의해 G.711 코덱은 1초당 8000 개의 샘플링과 샘플당 8비트로 양자화한다. DSP 칩으로 G.711 코덱을 적용하면 10ms 단위당 음성 샘플을 160 바이트이고, G.729는 20 바이트이다. 만일 패킷당 10ms 단위로 페이로드를 만들면 초당 100개가 전송되고, 패킷당 20ms 단위로 페이로드를 만들면 50개가 전송된다. 일반적으로 20ms 단위로 하나의 패킷을 만들어 초당 50개의 패킷을 생성한다.

G.711

1 초당 8000 개의 샘플링
샘플당 8 비트(bit)
1초 음성에 사용되는 바이트(byte) = 8000 * 8(bit) / 8(byte 계산) = 8000 byte = 8Kb
만약 스테레오라면 8Kb x 2 = 16Kb

RTP Header

RFC 3550에 RTP 헤더가 정의되어 있다.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• 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.

패킷 내에서 프레임 경계와 같은 중요한 이벤트들을 표시.

Payload Type 필드의 확장을 위해 무시되기도 함.

The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. A profile MAY define additional bits or specify that there is no marker bit by changing the number of bits in the payload type field.

• PT (Payload Type)

7 bit.

페이로드 타입은 RTP가 전송하고 있는 실시간 데이터의 압축 코덱을 명시.

페이로드 타입은 Capability Exchange 협상에서 상호 인지 필수.

This field identifies the format of the RTP payload and determines its interpretation by the application. A profile MAY specify a default static mapping of payload type codes to payload formats. Additional payload type codes MAY be defined dynamically through non-RTP means. A set of default mappings for audio and video is specified in the companion RFC 3551. An RTP source MAY change the payload type during a session, but this field SHOULD NOT be used for multiplexing separate media streams. A receiver MUST ignore packets with payload types that it does not understand.

• Sequence number

16 bit.

보안을 이유로 랜덤 번호에서 시작하고 패킷이 늘어날 때마다 1씩 증가.

수신 측이 패킷 손실 여부 확인 가능.

The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number SHOULD be random(unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt, because the packets may flow through a translator that does.

• Timestamp

32 bit.

RTP 패킷의 첫 번째 바이트의 샘플링 순간을 표시.

초기값은 랜덤 넘버로 결정되지만 샘플링 레이트에 따라 증가량은 상이함.

The timestamp reflects the sampling instant MUST be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations. The resolution of the clock MUST be sufficient for the desired

• SSRC (Synchronization Source) Identifier

32 bit.

동기화 소스로 랜덤 넘버로 결정.

• CSRC (Contributing Source) Identifier

32 bit.

다수의 음원이 Audio Mixer 를 통해 하나로 통합될 경우 원래 음원의 목록을 표시.

RTCP Header

RFC 3550에 RTCP 헤더가 정의되어 있다.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=SR=200   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SSRC of sender                        |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender |              NTP timestamp, most significant word             |
info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             NTP timestamp, least significant word             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         RTP timestamp                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     sender's packet count                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      sender's octet count                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |                  profile-specific extensions                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SRTP Decode

libsrtp

• https://github.com/cisco/libsrtp

./configure --enable-openssl --enable-log-stdout --with-openssl-dir=/opt/homebrew/opt/openssl@3 --prefix=/usr/local

libsrtp provides useful utilities under the test folder.

• rtp_decoder: Performs the description.

Troubleshooting

• RTP 패킷이 정상적으로 수신되는가?

시그널링이 정상적이어도 RTP 패킷이 송수신되지 않는 경우가 있다. 실제 NAT(Network Address Translation) 이슈로 인해 주소가 잘못 지정되었을 수도 있다.

• SSRC 가 변경되지는 않았는가?

같은 통화의 패킷임에도 SSRC가 변경되면 다른 세션으로 인식되어 패킷은 폐기된다.

• 시퀀스 넘버는 일정하게 증가하는가?

시퀀스 넘버가 순차적으로 증가하지않고 갑자기 증가하거나 감소하는 경우가 있다. 예를 들어 100 다음 400번이 오는 경우 수신 단말은 300 개의 패킷이 손실된 것으로 보고 재생하지 않는다. 반대로 100 다음에 60 이 오는 경우 수신단말은 이미 수신한 패킷으로 인식하고 재생하지 않는다.

RFC 3550 Appendix A.3 Determining Number of Packets Expected and Lost 에 의하면, 갑자기 비연속적인 시퀀스 넘버가 3개 이상 연속될 경우 수신 단말은 시퀀스 넘버가 재설정된 것으로 인삭하고 재생해야 한다.

• 타임스탬프는 일정하게 증가하는가?

타임스탬프는 패킷의 재생 시점을 확인하므로 갑자기 감소하거나 크게 증가하면 안된다.

• 음질에 문제가 있는가?

와이어 샤크로 RTP 패킷을 캡쳐하여 음성 파일로 만들어서 재생할 수 있다. 음성 파일에 문제가 있다면 송신 단말에서 문제가 있는 것이고, 음성 파일에 문제가 없다면 수신 단말의 문제이다.

See also

• https://brunch.co.kr/@linecard/154 - RTP의 이해