RTP: A Transport Protocol for Real-Time Applications(RFC1889)
1. 개요
RTP는 오디오, 비디오 및 시뮬레이션 데이터와 같은 실시간 데이터를 멀티캐스트 또는 유니캐스트 네트웍을 이용해서 전송하는 응용 서비스에 알맞은 단말-대-단말 네트웍 전송 기능을 제공한다. RTP는 자원 예약을 수행하지 않으며, 따라서 적시 전달, 순차 전달과 같은 서비스 품질도 보장하지 않는다. RTP 데이터 전송 기능은 제어 프로토콜에 의해 확장되는데, RTCP라 불리우는 이 제어 프로토콜은 데이터의 전달 상황을 감시하며, 최소한의 제어 기능과 매체 식별 기능을 제공한다. RTP와 RTCP는 하위의 전송 및 네트웍 계층에 무관하게 설계되었다.
RTP는 별개의 독립 계층으로 구현되기 보다는 특정 응용에서 요구되는 정보를 제공하여 프로토콜의 처리가 응용의 처리 과정으로 통합될 수 있도록 설계되었다. 따라서 기존의 프로토콜들과는 달리 RTP는 응용의 필요에 따라 헤더를 변경하거나 추가하여 응용에 맞는 프로토콜이 될 수 있도록 하는 일종의 맞춤형 프로토콜이다. 이 문서에서는 RTP를 이용할 수 있을 것으로 추정되는 모든 응용들이 공통적으로 필요로 할 기능들 만을 명시하고 있다. 따라서, 특정 응용 서비스에 필요한 RTP를 구현하기 위해서는 이 문서 이외에 RTP 페이로드의 종류와 형식을 정의하는 프로파일 문서(Profile Specification)와 페이로드의 전송 방법을 정의한 페이로드 형식 문서(Payload Format Specification)가 필요하다.
2. 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 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
모든 RTP 패킷의 상위 12바이트는 다음과 같이 고정되어 있으며, 이후의 CSRC 필드는 혼합기(Mixer)가 삽입했을 경우에만 존재한다. 고정 헤더 필드의 각 부분은 다음의 의미를 가진다.
n Version(V) : 2비트 필드로 현재는 항상 2 값을 가진다.
n Padding(P) : 1비트 필드로 1 값을 가지면 패킷에 하나 이상의 채워넣기 바이트가 포함되어 있음을 나타낸다. 마지막 채워넣기 바이트는 현 패킷에서 무시되어야 하는 채워넣기 바이트의 수를 나타낸다.
n Extension(X) : 1비트 필드로 1 값을 가지면 고정 헤더 이후에 정확히 하나의 확장 헤더가 등장함을 의미한다.
n CSRC Count(CC) : 4비트 필드로 고정 헤더 이후에 나열되는 CSRC 식별자의 수를 나타낸다.
n Marker(M) : 1비트 필드로 이 필드의 해석은 프로파일에 의해서 결정된다. 이 필드는 패킷 스트림 내에서 프레임 경계와 같은 중요한 이벤트들을 표시하는데 이용된다. 프로파일은 추가 표시 비트들을 정의하거나 PT 필드를 확장하여 표시 비트를 없앨 수도 있다.
n Payload Type(PT) : 7비트 필드로 RTP 페이로드의 타입을 나타낸다. 프로파일에서 페이로드 타입의 값과 실제 페이로드 형식을 연결한다.
n Sequence Number(SN) : 16비트 필드로 송신되는 각 RTP 패킷에 대해 1씩 증가하는 값을 가진다. 수신 측에서는 패킷 분실을 검출하거나 패킷의 순서를 맞추는데 이용된다. 초기값은 보안을 위해서 무작위로 설정된다.
n Timestamp : 32비트 필드로 RTP 데이터 패킷의 첫번째 바이트의 샘플링 순간을 나타낸다. 시계의 주파수는 페이로드의 데이터 형식에 종속되고 형식을 정의하는 프로파일이나 페이로드 형식 문서에 정적으로 명시된다. 초기값은 순번과 마찬가지로 무작위 수로 설정된다.
n Synchronization Source(SSRC) Identifier : 32비트 필드로 동기화 소스를 나타낸다. 이 값은 같은 RTP 세션 내에서 같은 SSRC를 가진 동기화 소스가 두개 이상 나타나지 않도록 무작위로 선택된다.
n Contributing Source(CSRC) Identifiers : 이 필드에는 0에서 15목록까지 포함될 수 있으며 각 목록은 32비트를 차지한다. CSRC는 현 패킷에 포함된 페이로드에 기여한 제공 소스들을 나타낸다. 제공 소스가 15개 이상일 경우에도 15개의 제공 소스만 기록된다. 이 필드는 혼합기에 의해 삽입되고 각 목록은 혼합되는 모든 소스들의 SSRC 식별자이다.
3. RTP 세션 다중화
효과적인 프로토콜 처리를 위해서 다중화 점의 수는 최소화되어져야 한다. RTP의 경우에 다중화는 목적지 전송 주소에 의해 수행된다.. 예를 들어 오디오와 비디오로 이루어지는 회의에서 각 매체는 자신만의 목적지 전송 주소를 가지는 독자의 RTP 세션으로 전송되어야 한다.
4. 프로파일에 따른 RTP 헤더 변경
Marker 비트와 PT 필드는 프로파일에 종속된 정보를 수송하지만 고정 헤더에 할당되어 있다. 그 이유는 많은 응용들이 그것들을 필요로 할 것이고 이렇게 제공하지 않으면 그 값들을 위해 또 다른 32비트를 확장해야 하기 때문이다. PT 필드는 프로파일에서 재정의할 수 있으며 Marker 비트가 있는 경우는 이 필드의 최상위 비트에 기록되어야 한다. 이 외의 특정 페이로드 형식을 위해 필요한 정보들은 패킷의 페이로드 섹션에 기록된다.
특정 응용에서 페이로드 형식과 무관한 부가적인 기능이 필요하면 그 응용이 따르는 프로파일에서 고정 헤더의 SSRC필드 이후에 바로 추가 헤더 필드를 정의한다. 그러한 응용들은 이 부가 필드를 바로 참조할 수 있으며, 프로파일과 무관한 감시기나 기록기들은 아직도 RTP 패킷의 첫 12바이트 만을 해석하여 처리할 수 있다. 이후 이 부가 필드가 모든 응용들에서 필요할 것으로 판단되면 새로운 RTP 버전에서 이 필드를 고정 헤더 필드에 포함시켜 영구적으로 이용될 수 있도록 한다.
5. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
고정 헤더 필드의 X 비트가 1이면 가변 길이 확장 헤더가 RTP 고정 헤더에 추가된다. 추가되는 위치는 SSRC 이후, 또는 CSRC가 존재하면 CSRC 이후 이다. 확장 헤더는 16비트의 길이 필드를 가지고 있는데, 이 필드는 4바이트의 확장 헤더를 제외하고 확장에 포함된 32비트 워드의 수를 나타낸다. 하나의 확장 헤더만이 RTP 고정 헤더에 추가될 수 있다. 그러나 확장 헤더의 상위 16비트가 프로파일에서 정의할 수 있도록 남겨져 있기 때문에 이 필드를 이용해서 여러 가지의 확장 헤더들을 실험할 수도 있고 다수의 연동 응용들이 각자의 확장 헤더를 실험해 볼 수도 있다.
6. RTP 제어 프로토콜 - RTCP
RTCP는 기본적으로 세션의 모든 참가자들에게 주기적인 제어 패킷을 보내어 다음의 기능들을 수행한다.
n 데이터 분배의 품질에 대한 피드백을 제공한다. 이 기능은 RTCP Sender Report(SR)와 Receiver Report(RR)에 의해 수행된다.
n RTP 소스의 식별을 위해 지속적인 식별자를 수송한다. 이 식별자는 CNAME(Canonical Name)이라 부른다. SSRC는 충돌이 발생하거나 프로그램이 다시 시작될 경우에 변경될 수 있기 때문에 수신자는 각 참가자들을 일관성 있게 유지하기 위해서 CNAME을 필요로 한다.
이 두 기능은 모든 참가자들이 RTCP 패킷을 송신할 것을 요구한다. 따라서 RTP가 많은 수의 참가자를 수용할 수 있기 위해서는 그 송신 비율이 제어되어야 한다. 각 참가자가 모든 다른 참가자들에게 제어 패킷을 전송하기 때문에 각 참가자는 전체 참가자의 수를 파악할 수 있게 된다. 이 참가자 수를 이용해서 제어 패킷 전송 간격을 조정한다.
n 최소한의 세션 제어 정보를 수송한다. 이 기능은 참가자가 마음대로 가입, 탈퇴할 수 있는 허술하게 제어되는 세션에서 유용하게 이용될 수 있는 기능으로 예를 들어 새로운 참가자의 신분 또는 이름을 제공함으로써 다른 모든 참가자의 사용자 인터페이스에 새로운 참가자의 이름을 알릴 수 있게 된다.
6.1 RTCP 패킷 형식
if encrypted: random 32-bit integer
|
|[------- packet -------][----------- packet -----------][-packet-]
|
| receiver reports chunk chunk
V item item item item
--------------------------------------------------------------------
|R[SR|# sender #site#site][SDES|# CNAME PHONE |#CNAME LOC][BYE##why]
|R[ |# report # 1 # 2 ][ |# |# ][ ## ]
|R[ |# # # ][ |# |# ][ ## ]
|R[ |# # # ][ |# |# ][ ## ]
--------------------------------------------------------------------
|<------------------ UDP packet (compound packet) --------------->|
#: SSRC/CSRC
각 RTCP 패킷은 RTP 데이터 패킷과 비슷하게 고정부로 시작을 해서 패킷의 종류에 따라 달라지는 가변 길이의 구조화된 요소들이 뒤따르고 항상 32비트 경계로 끝난다. 이러한 정렬 방식과 고정부의 길이 필드는 RTCP 패킷을 “Stackable”하게 만든다. 즉, 다수의 RTCP 패킷들로 복합 RTCP 패킷을 만들어 하나의 하위 프로토콜 패킷으로 전송할 수 있게 한다. 복합 패킷을 이루는 RTCP 패킷의 수는 하위 프로토콜의 최대 길이에 의해 한정된다. 복합 패킷의 개별 RTCP 패킷들은 독립적으로 처리되지만 프로토콜의 기능을 수행하기 위해서 다음의 제약이 주어진다.
n 송수신 보고(SR, RR)는 대역폭 제약이 허용하는 한 자주 보내서 송수신 통계 치의 정밀도를 최대화시켜야 한다. 따라서 주기적으로 전송되는 복합 RTCP 패킷에는 반드시 보고가 포함되어 있어야 한다.
n 새로운 수신자는 가능한 빨리 소스의 CNAME을 수신해서 소스를 식별하고 Lip-Sync와 같은 목적을 위해 그것을 매체와 연결해야 한다. 따라서 각 복합 RTCP 패킷은 SDES CNAME도 포함해야만 한다.
n 모든 RTCP 패킷들은 적어도 두개의 개별 패킷으로 구성된 복합 패킷의 형태로 전송되어야 한다. 이때 다음의 형식이 권고된다.
1) Encryption Prefix : 복합 패킷이 암화화 될 경우에만 무작위 32비트의 값이 전치된다. 이 값은 매번 전송되는 복합 패킷에 대해 새로운 값으로 선택된다.
2) SR 또는 RR : 복합 패킷의 첫 RTCP 패킷은 항상 보고 패킷이어야 한다. 이것은 수신되거나 송신된 데이터가 없을 경우에도 마찬가지로, 이 경우에는 빈 RR이 전송된다. 복합 패킷의 나머지 하나가 BYE일 경우에도 마찬가지로 보고 패킷이 첫 패킷으로 등장해야 한다.
3) 추가 RR들 : 수신 보고 소스의 수가 31을 넘어서면 첫 보고 패킷에 이어 첨가 RR 패킷이 나와야 한다.
4) SDES : CNAME을 포함하는 하나의 SDES 패킷은 각 복합 패킷에 반드시 포함되어야 한다. 다른 소스 설명 항목들도 응용에서 필요로 하면 대역폭 제한에 따라 포함될 수도 있다.
5) BYE 또는 APP : 주어진 SSRC/CSRC에 대해 마지막 패킷으로 전송되어야 하는BYE를 제외한 나머지 패킷들은 어떤 순서로도 이어질 수 있다.
변환기와 혼합기들은 다수의 소스로부터 전달되는 개별 RTCP 패킷들을 가능하면 항상 복합 패킷으로 합쳐서 보내는 것이 바람직하다. 그렇게 함으로써 패킷 오버헤드를 줄일 수 있기 때문이다. 복합 패킷의 전체 길이가 하위 프로토콜의 MTU를 초과할 경우는 복합 패킷을 잘라서 여러 개의 하위 프로토콜 패킷에 포함시켜 보낼 수 있다.
6.2 RTCP 전송 간격
RTP는 수명에서 수 천명의 참가자를 하나의 세션에 참가시킬 수 있도록 설계되었다. 오디오 회의의 경우에 데이터 패킷은 참가자의 수에 상관없이 비교적 일정한 비트율을 가지지만(언제나 발언하는 사람은 한 두 사람 이므로) 제어 패킷의 경우에는 참가자의 수에 비례하여 비트율이 증가(각 참가자가 나머지 모두에게 일정한 간격으로 제어 패킷을 전송하기 때문에)하게 된다. 따라서 제어 패킷의 전송 간격은 제어되어야 한다. RTCP에 할당되는 대역폭은 세션 대역폭의 5%로 고정되는 것이 바람직 하다.
6.2.1 세션 멤버 수 관리
새로운 참가자에 대한 새로운 SSRC를 가지는 다수의 패킷을 수신할 때 까지 그 참가자는 유효하지 않은 것으로 간주한다. 각 참가자는 어떤 사이트가 5개의 RTCP 보고 간격 동안 RTP 혹은 RTCP 패킷을 보내지 않으면 그 사이트를 비활성화 상태로 표시하거나 삭제한다. 일단 사이트가 유효화되면 나중에 비활성 상태로 표시되어도 30분 까지는 그 사이트의 상태는 유지되고 RTCP 대역폭을 공유하는 전체 사이트의 수에 계속 계산된다.
6.2.2 SDES 대역폭 할당
SDES의 필수 항목인 CNAME 이외에 NAME, EMAIL 등과 같은 부가적인 정보에 제어 대역폭을 할당하는 것을 신중하게 고려해야 한다. 이유는 부가 정보들이 수신 보고와 CNAME의 전송 간격을 늘려서 전체 프로토콜의 성능 저하를 유발할 수 있기 때문이다. 일반적으로 한 참가자에 할당된 RTCP 대역폭의 20% 미만이 이러한 정보들을 수송하는데 이용되도록 권유 된다. 더욱이 모든 SDES 항목이 모든 응용에 포함될 필요는 없다. 포함된 것들은 사용 정도에 따라 적정 비율의 대역폭을 할당받으면 된다.
6.3 송신자/수신자 보고
RTP 수신자는 자신이 동시에 송신자일 경우와 아닌 경우에 각각 SR와 RR를 보내서 수신 품질에 대한 피드백을 제공한다. 패킷 종류 코드 이외에 두 패킷의 다른점은 SR이 활성화된 송신자들에 의해서 이용되는 20바이트의 송신자 정보 섹션을 가지고 있다는 것이다. 한 사이트가 최종 보고 이후 RTCP 전송 간격 동안 아무 데이터 패킷이라도 보냈으면 SR을 보내고 그렇지 않았을 경우에는 RR을 보낸다.
SR이나 RR 모두 0개 이상의 수신 보고 블럭을 가진다. 보고 블럭은 이 수신자의 최종 보고 이후에 이 수신자에게 RTP 데이터 패킷을 보낸 SSRC들 각각에 대해 하나씩 존재한다. CSRC 리스트에 나열된 CSRC들에 대해서는 보고를 보내지 않는다. SR 이나 RR 패킷에는 최대 31개의 수신 보고 블럭이 포함될 수 있기 때문에 그것을 초과하는 경우에는 추가적인 RR 패킷들이 초기 SR 또는 RR 패킷에 연이어 쌓일 수 있다.
6.3.1 SR : 송신자 보고 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=end of header=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=end of sender information=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
송신자 보고 패킷은 세 개의 섹션으로 구성되며, 프로파일에 따른 네 번째 확장 섹션이 추가될 수도 있다.
헤더
n Report Count(RC) : 5비트 필드로 이 패킷에 포함된 수신 보고 블럭의 수를 나타낸다.
n Packet Type(PT) : 8비트 필드로 RTCP SR 패킷의 경우에는 200 값을 가진다.
n Length : 16비트 필드로 32비트 워드로 계산된 전체 패킷의 길이에서 1을 뺀 값으로 헤더와 채워넣기를 모두 포함한다. 0 값도 유효하다.
송신자 정보
n NTP Timestamp : 64비트 필드로 이 보고가 보내진 시간을 나타내고 Round-Trip 지연 계산에 이용된다.
n RTP Timestamp : 32비트 필드로 NTP Timestamp의 시간에 상응한다. 그러나 단위와 무작위 오프셋은 데이터 패킷의 RTP Timestamp들과 같다. 이것은 RTP Timestamp 계수와 실제 시간 간의 관계를 이용해서 해당 NTP Timestamp로부터 계산된다.
n 송신자 패킷 계수 : 32비트 필드로 전송 시작에서부터 이 SR 패킷이 생성될 때 까지 이 송신자에 의해 전송된 RTP 데이터 패킷의 총 수를 나타낸다. 이 값은 송신자가 SSRC 식별자를 변경하면 초기화 된다.
n 송신자 바이트 계수 : 32비트 필드로 전송 시작에서부터 이 SR 패킷이 생성될 때 까지 이 송신자에 의해 전송된 RTP 데이터 패킷에서 헤더와 채워넣기를 제외한 페이로드 바이트의 수를 나타낸다. 송신자가 SSRC 값을 변경하면 이 필드는 초기화 된다.
수신 보고 블럭
n SSRC_n : 32 비트 필드로, 이 수신 보고 블럭의 정보가 해당되는 소스의 SSRC 식별자를 나타낸다.
n Fraction lost : 8비트 필드로, 이전 SR 또는 RR 패킷이 송신된 이후 분실된 RTP 데이터 패킷의 비율이 고정 소수로 표현된다. 이것은 분실 비율을 256으로 곱한 후 정수부를 취하는 것과 같다. 이 값은 분실된 패킷의 수를 기대된 패킷의 수로 나누어 얻어진다. 중복 수신에 의해 분실이 음의 값을 가질 경우 분실 비율은 0이 된다.
n Cumulative number of packets lost : 24비트 필드로, 소스 SSRC_n으로부터 수신 시작 이래로 분실한 총 RTP 데이터 패킷 수로 예측된 패킷 수에서 실제 수신된 패킷 수를 뺀 값으로 정의된다. 실제 수신된 패킷 수에는 지연 도착된 것과 중복 도착된 것도 포함된다.
n Extended highest sequence number received : 32비트 필드로, 하위 16비트는 소스 SSRC_n으로부터 수신된 RTP 데이터 패킷의 최고 순번을 포함하고 상위 16비트는 그 순번을 부록A.1의 알고리즘에 따라 관리되는 순번 사이클의 해당 계수로 확장한다.
n Interarrival jitter : 32비트 필드로, Timestamp 단위로 측정되고 비부호 정수로 표현되는 RTP 데이터 패킷 도착 시간 간의 통계적 가변성의 측정값을 나타낸다. Si가 패킷 i로부터의 RTP Timestamp이고 Ri가 패킷 i의 RTP Timestamp 단위로 측정한 도착 시간일 때, 패킷 i와 j의 지터 D는 D(i,j) = (Rj-Ri) - (Sj-Si) = (Rj-Sj) - (Ri - Si)와 같이 표현되고, 도착간 지터 J는 J = J + (|D(i-1, i)| - J)/16로 정의된다. 여기서 1/16은 Gain Parameter로 적당한 수렴 속도를 보장하면서 좋은 소음 감쇄 율을 보장한다.
n Last SR Timestamp(LSR) : 32비트 필드로, 소스 SSRC_n으로부터 최근에 받은 RTCP SR의 일부인 64비트 NTP 타임스탬프의 중간 32비트를 나타낸다. SR을 아직 받지 않았으면 이 필드는 0 값을 가진다.
n Delay since last SR(DLSR) : 32비트 필드로, 소스 SSRC_n으로부터의 최종 SR 패킷 수신과 이 수신 보고 블럭 송신간의 지연을 나타내며, 1/65536초 단위로 표시된다. SSRC_n으로부터 아직 SR 패킷을 받지 못했을 경우 이 필드의 값은 0으로 설정된다.
[10 Nov 1995 11:33:25.125] [10 Nov 1995 11:33:36.5]
n SR(n) A=b710:8000 (46864.500 s)
---------------------------------------------------------------->
v ^
ntp_sec =0xb44db705 v ^ dlsr=0x0005.4000 ( 5.250s)
ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
(3024992016.125 s) v ^
r v ^ RR(n)
---------------------------------------------------------------->
|<-DLSR->|
(5.250 s)
A 0xb710:8000 (46864.500 s)
DLSR -0x0005:4000 ( 5.250 s)
LSR -0xb705:2000 (46853.125 s)
-------------------------------
delay 0x 6:2000 ( 6.125 s)
SSRC_r이 현재의 RR을 보내는 수신자를 의미할 때, 소스 SSRC_n은 SSRC_r에 대한 왕복 전송 지연을 다음과 같이 구할 수 있다. 이 RR이 수신된 시간(A)을 기록하고, 총 왕복 전송 시간 A-LSR을 최종 SR의 Timestamp 필드를 이용해서 계산한다. 그리고 여기서 DLSR을 빼서 왕복 전송 지연을 구한다.(A - LSR - DLSR)
6.3.2 RR : 수신자 보고 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RR 패킷의 형식은 패킷 종류 필드가 201 값을 가지고 송신자 정보 5워드(NTP/RTP Timestamp, Sender Packet/Byte Counter)가 생략되어 있다는 것을 제외하고는 SR과 같다. 보고할 데이터의 전송이나 수신이 없을 경우에는 복합 RTCP 패킷의 전단에 RC 값이 0인 빈 RR 패킷을 삽입한다.
6.3.3 송신자 수신자 보고 확장
송신자 또는 수신자에 대해서 주기적으로 보고되어야 할 추가 정보가 있을 경우 프로파일은 프로파일에 따른(profile-specific) 또는 응용에 따른(application-specific) 송신자와 수신자 보고에 대한 확장을 정의해야 한다. 추가적인 송신자 정보가 필요할 경우, 우선은 송신자 보고의 확장부에 포함되어야 한다. 수신자에 관계되는 정보가 포함될 경우 그 데이터는 기존의 수신 보고 블럭의 배열에 병치하는 블럭의 배열로 구조화될 것이다. 즉, 블럭의 수가 RC 필드에 반영될 것이다.
6.3.4 송신자 수신자 보고 분석
수신 품질 피드백은 송신자 뿐만 아니라 다른 수신자들이나 제삼자 모니터들에도 유용할 것이다. 송신자는 피드백에 따라서 전송 율을 변경할 수 있고, 수신자는 문제가 지역적인 것인지, 전역적인 것인지를 결정할 수 있으며, 망 관리자는 멀티캐스트 분배를 위한 그들의 망의 성능을 평가하기 위해서 RTCP 패킷 만을 수신하는 프로파일에 무관한 모니터를 이용할 수 있다.
송신자 정보와 수신자 보고 블럭에 모두 누적 계수가 이용되기 때문에 두 보고 사이의 차이점을 계산하여 단기 그리고 장기에 걸친 측정을 하고 보고의 분실에 대한 회복력을 제공한다. 수신된 최근 두 보고의 차이가 분배의 최근 품질을 측정하는데 이용될 수 있다. 두 보고 사이의 기간 동안 이러한 차이점으로부터 여러 가지 Rate들이 계산될 수 있도록 NTP 타임스탬프가 포함되었다. 타임스탬프는 데이터 인코딩을 위한 클럭 속도와 무관하기 때문에 인코딩과 프로파일에 무관한 품질 감시기를 구현할 수 있다.
6.4 SDES : 소스 설명 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=SDES=202 | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC/CSRC_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC/CSRC_2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
SDES는 헤더와 0개 이상의 Chunk로 구성된 3-계층 구조로 각 Chunk는 그 Chunk에 식별된 소스를 설명하는 Item들로 구성된다.
n Packet Type(PT) : 8비트 필드로, RTCP SDES 패킷의 경우에는 202 값을 갖는다.
n Source Count(SC) : 5비트 필드로, SDES 패킷에 포함된 SSRC/CSRC Chunk의 수를 나타낸다. 0 값도 유효하지만 아무런 의미도 없다.
각 Chunk는 SSRC/CSRC 식별자와 SSRC/CSRC에 관계되는 정보를 수송하는 0개 이상의 Item들의 리스트로 구성된다. 각 Chunk는 32비트 경계에서 시작한다. 각 Item은 8비트의 종류 필드와 텍스트의 길이를 나타내는 8비트의 바이트 계수, 그리고 텍스트 자체로 구성된다. 텍스트는 255 바이트까지 이용할 수 있지만 RTCP 대역폭 소비에 관계된다는 것을 인지해야 한다.
텍스트는 ISO 10646 Annex F에 명시된 UTF-2(UTF-8 또는 UTF-FSS로도 알려짐) 인코딩 방법에 따라 인코딩 된다. US-ASCII는 이 인코딩 기법의 부분집합이기 때문에 부가적인 인코딩을 필요로 하지 않고, 캐릭터의 최상위 비트를 1로 설정함으로써 멀티-바이트 인코딩 기법으로 인코딩 된 사실을 알린다.
종단 시스템은 고정 RTP 헤더의 SSRC와 같은 값의 소스 식별자를 포함하는 하나의 SDES 패킷을 보낸다. 각 Item들 가운데 CNAME 만이 필수이다.
CNAME(Canonical End-point Identifier, 1) : CNAME은 무작위로 할당된 SSRC 식별자에 충돌이 발생할 수 있고, 프로그램이 재시작 되었을 때 SSRC 식별자가 변경될 수 있기 때문에 새로운 SSRC 식별자와 상시적으로 남아있는 소스를 위한 식별자와의 바인딩을 제공한다. SSRC 식별자처럼 CNAME도 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME=1 | length | user and domain name ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CNAME은 가능하면 자동적으로 만들어져야 한다. 이러한 요구 사항을 만족시키기 위해서 프로파일이 별도로 명시하지 않은 한 “user@host” 또는 “host”의 형식이 이용되어야 한다. 이러한 형식의 장점은 NAME 아이템을 별도로 전달할 필요가 없다는 점이고, 단점은 한 사용자가 한 호스트에서 다수의 소스를 생성할 경우 각 소스에 대해 유일한 식별자가 제공되지 못한다는 점이다.
NAME(User name, 2) : 소스를 설명하는데 이용되는 실명으로, 사용자가 원하는 어떤 형태로도 기록될 수 있다. NAME은 적어도 세션 기간 동안에는 변함이 없어야 하며, 세션 내에서 유일할 필요는 없다. 프로파일에서 Item들의 우선순위를 정하여 전송되는 횟수를 결정하는데 도움을 줄 수 있다.
EMAIL(Electronic mail address, 3) : RFC822에 명시된 형식의 전자 메일 주소로, 세션 기간 동안에는 변함이 없어야 한다.
PHONE(Phone number, 4) : 국제 접속 코드를 + 기호로 변경한 형태의 전화번호이다. 예, +1 908 555 1212
LOC(Geographic user location, 5) : 이 Item은 응용에 따라서 정밀도가 달라진다. “Murray Hill, New Jersey”, “Room 2A244, AT&T BL MH”와 같이 표현될 수 있다. 정밀도의 결정은 구현자나 사용자에 달려있지만 각각의 형식과 내용은 프로파일에 서술되어 있을 수 있다. 이동 호스트를 제외하고는 세션 기간 동안에는 변함이 없어야 한다.
TOOL(Application or tool name, 6) : 실시간 스트림을 생성하는 응용의 이름과 버전 등을 나타낸다. 이 정보는 디버깅 목적에 유용하다. 이 정보 또한 세션 기간 동안에는 변함이 없어야 한다.
NOTE(Notice/status, 7) : 소스의 현 상태를 설명하는 임시 메시지(예, “on the phone, can’t talk”)를 전달하거나 세미나 중일 경우 발표의 제목을 전달하는 등의 목적으로 이용되는 부분 이지만 프로파일에 의해 다른 용도로 정의될 수도 있다. NOTE는 예외적인 정보를 수송하는 데만 이용되어야 하고 모든 참가자들이 일상적인 용도로 이용해서는 안된다. 그렇게 되면 제어 패킷 대역폭이 낭비되어 CNAME과 같은 중요한 정보가 전달되는 간격이 늘어나기 때문이다. NOTE Item이 활성화된 동안에는 디스플레이하는 것이 중요하기 때문에 NOTE Item이 RTCP 대역폭을 차지할 수 있도록 CNAME이 아닌 다른 Item들의 전송을 자제하는 것이 좋다. 수신 측에서 NOTE Item 반복 기간의 몇 배 기간 동안 또는 20~30 RTCP 기간 동안 NOTE를 받지 못하면 NOTE Item이 비활성화 된 것으로 간주해야 한다.
PRIV(Private extensions, 8) : 이 Item은 실험적인 또는 응용에 따른 SDES 확장을 정의하는데 이용된다. 이 Item은 길이-스트링 쌍으로 구성된 전치부(prefix)와 Item의 나머지를 채우고 원하는 정보를 수송하는 값 스트링(value string)을 포함한다. 전치부 길이 필드는 8비트 필드이고 전치 스트링은 PRIV Item을 이 응용이 수신할 다른 PRIV Item들에 대해 유일하게끔 정의하는 이름으로 사람에 의해서 선택된다. SDES PRIV 전치부는 IANA에 등록되지 않는다. 대신 어떤 종류의 PRIV Item이 일반적인 유용성을 가지고 있는 것으로 판명되면 IANA에 등록된 정규 SDES Item 타입을 할당되어 전치부를 필요하지 않게 해야 한다. 이렇게 하는 것이 사용을 단순화 시키고 전송 효율을 증가시킨다.
6.5 BYE : Goodbye RTCP 패킷
BYE 패킷은 소스가 더 이상 활성화 상태가 아님을 알린다.
n Packet Type(PT) : 8비트 필드로, RTCP BYE 패킷은 203 값을 갖는다.
n Source Count(SC) : 5비트 필드로 BYE 패킷에 포함된 SSRC/CSRC 식별자의 수를 나타낸다. 0 값도 유효하지만 의미는 없다.
BYE 패킷이 혼합기에 도착하면 혼합기는 SSRC/CSRC 식별자 변경 없이 그대로 전달한다. 혼합기가 수행이 중지될 때 자신의 SSRC 식별자와 자신이 처리하는 모든 제공 소스들을 나열한 BYE 패킷을 보내야 한다. 부가적으로 BYE 패킷은 8비트 바이트 계수와 계수 바이트 크기의 탈퇴 이유(예, “camera malfunction”, “RTP loop detected”)를 나타내는 텍스트를 포함할 수 있다.
6.6 APP : Application-defined RTCP 패킷
새로운 응용이나 새로운 기능이 개발되었을 때 패킷 종류 값을 등록할 필요 없이 실험을 목적으로 사용되기 위한 패킷이다. 인식할 수 없는 이름을 가진 APP 패킷은 무시되어야 한다. 실험 후에 광범위한 이용성이 판명되면 각 APP 패킷은 부 타입과 이름 필드 없이 재정의되어 RTCP 패킷 타입을 이용해서 IANA(Internet Assigned Number Authority)에 등록하도록 권고된다.
n Subtype : 5비트 필드로 일련의 APP 패킷들이 하나의 유일한 이름으로 정의될 수 있도록 하는 부 타입으로 사용되거나 응용에 종속되는 데이터를 위해 사용될 수 있다.
n Packet Type(PT) : 8비트 필드로 RTCP APP 패킷은 204 값을 가진다.
n Name : 4바이트 필드로 이 응용이 수신할 다른 APP 패킷들에 대해 유일하도록 APP 패킷을 정의하는 이름으로 사용자에 의해 선택된다.
n Application-specific Data : 가변 길이의 필드로 APP 패킷에 나타날 수도, 나타나지 않을 수도 있다. 이 필드는 RTP에 의해 해석되지 않고 응용에 의해 해석된다. 이 필드의 길이는 32비트의 배수여야 한다.
7. RTP 변환기와 혼합기
RTP 변환기와 혼합기는 두개 이상의 전송 계층 “cloud”를 연결한다. 일반적으로, cloud는 공통 네트웍 및 전송 프로토콜(예, IP/UDP)과 멀티캐스트 주소 또는 한 쌍의 유니캐스트 주소, 그리고 전송 계층 목적지 포트로 정의된다.
변환기 : RTP 패킷들을 SSRC 식별자 변경 없이 전달한다. 이렇게 하여 같은 변환기를 통과하여 변환기의 네트웍 소스 주소를 부여 받는 다양한 소스로부터의 스트림들이 수신기에서 구분될 수 있게 된다.
혼합기 : 하나 이상의 소스로부터 RTP 데이터 패킷 스트림을 수신해서 데이터 형식을 변경하여 스트림들을 같은 방법으로 결합하고 결합된 스트림을 전달한다. 일반적으로 다수의 입력 소스들 간에 타이밍 동기가 맞지 않기 때문에 혼합기는 이들간에 타이밍 정렬을 수행하여 결합된 스트림을 위한 타이밍을 만들어낸다. 이 경우 혼합기가 결합된 스트림의 타이밍 소스가 되고, 혼합기에 의해 전달되는 모든 데이터 패킷들은 혼합기의 SSRC 식별자를 부여 받게 된다. 혼합된 패킷에 스트림을 제공한 원래 소스들의 식별자를 유지하기 위해서 혼합기는 그들의 SSRC를 혼합된 패킷의 RTP 고정 헤더 바로 다음에 CSRC 식별자 리스트 필드에 기록한다. 혼합기 자신이 제공 소스인 경우에도 자신의 SSRC 식별자를 CSRC 리스트에 포함시킨다.
[E1] [E6]
| |
E1:17 | E6:15 |
| | E6:15
V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17)
(M1)-------------><T1>-----------------><T2>-------------->[E7]
^ ^ E4:47 ^ E4:47
E2:1 | E4:47 | | M3:89 (64,45)
| | |
[E2] [E4] M3:89 (64,45) |
| legend:
[E3] --------->(M2)----------->(M3)------------| [End system]
E3:64 M2:12 (64) ^ (Mixer)
| E5:45 <Translator>
|
[E5] source: SSRC (CSRCs)
------------------->
7.1 변환기에서의 RTCP 처리
변경된 또는 원래의 데이터 패킷을 전달하는 일 이외에 변환기와 혼합기는 RTCP 처리도 담당해야 한다. 많은 경우 이것들은 종단 시스템으로부터 전송된 복합 RTCP 패킷들을 분리하여 SDES 정보를 합치고 SR 또는 RR 패킷을 변경한다. 이 정보의 재전송은 패킷의 도착이나 변환기나 혼합기의 RTCP 간격 타이머에 의해 활성화된다.
7.2 혼합기에서의 RTCP 처리
혼합기는 새로운 데이터 스트림을 생성하기 때문에 SR 또는 RR 패킷들을 전혀 통과시키지 않고 대신 혼합기 양단의 종단 시스템을 위한 새로운 정보를 생성한다.
7.3 직렬 혼합기(Cascaded Mixers)
직렬로 연결된 혼합기들 가운데 두 번째 혼합기는 첫 혼합기에서 보내오는 결합된 패킷의 CSRC 리스트와 새로운 입력 패킷들의 SSRC 식별자들을 이용해서 CSRC 리스트를 새롭게 구성한다.
8. SSRC 식별자 할당과 이용
RTP 헤더와 RTCP 패킷의 다양한 필드들에 기록되는 SSRC 식별자는 RTP 세션 내에서 유일해야 하는 32비트 무작위 수이다. 특히 같은 네트웍의 참가자들이나 같은 시간에 시작하는 참가자들이 같은 수를 선택하지 않도록 하는 것은 아주 중요하다.
8.1 충돌 확률
식별자들이 무작위로 선택되기 때문에, 두개 이상의 소스들이 같은 번호를 선택할 가능성이 있다. 충돌은 모든 소스들이 동시에 시작할 경우 그 가능성이 가장 높다. 소수의 수가 N이고 식별자의 길이가 L(여기서는 32비트)일 때, 두 소스가 독립적으로 같은 값을 선택할 확률은 대략 1 - exp(-N**2 / 2**(L+1)) 일 때large N 정도 이다. 예를 들어, N이 1000이면 확률은 약 10**-4 이다.
일반적인 충돌 확률은 위의 최악의 경우에 비해 훨씬 낮다. 새로운 소스가 모든 소스들이 유일한 식별자를 가지고 있는 RTP 세션에 참가할 때, 충돌 확률은 공간 밖에서 이용되는 숫자들의 일부(the fraction of numbers used out of the space)로 N/2**L 이다. 다시 N이 1000일 때 확률은 약 2*10**-7 이다.
충돌 확률은 새 소스가 자신의 첫 패킷을 송신하기 이전에 다른 참가자들로부터 패킷을 수신할 기회가 높다는 점에서 더욱 줄어들게 된다. 즉, 새 소스가 다른 참가자들을 미리 추적해 볼 수 있다면 자신의 식별자가 다른 소스들의 식별자와 충돌하는지를 살펴볼 수 있고, 충돌의 경우 다른 식별자를 선택할 수 있게 되는 것이다.
8.2 충돌 해소와 루프 검출
SSRC 식별자 충돌 확률이 낮기는 하지만 모든 RTP 시스템들은 충돌 검출 기능과 충돌을 해결할 적절한 수단이 준비되어 있어야 한다. SSRC 식별자 충돌을 발견한 소스는 RTCP BYE 패킷을 보내고 다른 식별자를 선택해야 한다. 다른 두 소스의 식별자가 충돌하는 것을 발견(SSRC가 같고 소스 전송 주소나 CNAME이 다른)한 소스는 둘 중 하나로부터의 패킷은 포기하고 나머지는 받아들일 수 있다. 이 경우 이러한 상황이 오래 지속되지 않도록 충돌하는 두 소스가 충돌을 해결해야 한다.
9. 보안
RTP 응용들에서 요구하는 인증(Authentication), 무결성(Integrity), 그리고 신뢰성(Confidentiality) 등과 같은 보안 서비스는 궁극적으로 하위 계층 프로토콜들이 모두 제공할 것이다. 이러한 서비스들이 최근에 IP에 명시되었다. RTP를 이용할 것으로 보이는 초기의 오디오/비디오 응용들이 신뢰성 서비스의 필요성을 잘 확립 시켜 놓았기 때문에 다음 섹션에 하위 계층 서비스가 유용할 때 까지 RTP, RTCP와 함께 이용될 신뢰성 서비스를 정의한다. 이 서비스를 위한 프로토콜상의 부담(Overhead)은 그리 많지 않기 때문에 가까운 장래에 하위 계층 서비스에 의해 쓸모 없어진다 하더라도 피해는 크지 않을 것이다.
9.1 신뢰성
신뢰성은 의도된 수신자만이 수신된 패킷들을 디코딩할 수 있어야 함을 의미한다. 대부분의 경우 내용의 신뢰성은 암호화(Encryption)에 의해 성취된다. 기본 암호화 알고리즘은 RFC1423에 설명된 cipher block chaining(CBC) 모드의 DES(Data Encryption Standard) 알고리즘을 이용한다.
9.2 인증과 메시지 무결성
이 서비스들은 키 관리 하부구조 없이는 구현할 수 없기 때문에 현 RTP 버전에서는 명시하지 않는다. 장래에는 하위 계층 프로토콜에 의해서 이 서비스들이 지원될 것이다.
10. 네트웍 및 전송 프로토콜상의 RTP
RTP는 RTP 데이터와 RTCP 제어 스트림의 분리를 하위 프로토콜에 의존한다. UDP 및 비슷한 프로토콜들의 경우, RTP는 짝수 포트 번호를 이용하고 RTP에 해당하는 RTCP 스트림은 바로 상위의 홀수 포트 번호를 이용한다. RTP 데이터 패킷들은 길이 필드나 경계를 포함하지 않기 때문에 길이 확인은 하위 프로토콜에 의존한다. RTP 패킷의 최대 길이는 오직 하위 프로토콜에 의해서만 제한된다.
RTP 패킷들이 메시지 단위가 아닌 연속된 바이트 스트림으로 추상화하는 하위 프로토콜에 수송되어야 할 경우, RTP 패킷의 캡슐화는 프레이밍 기법을 지원하도록 정의되어야 한다. 프레이밍 기법은 여기서 정의하지 않는다.
'프로그래밍 > C | C++' 카테고리의 다른 글
| 윈도우 malloc (0) | 2013.08.14 |
|---|---|
| RTPLIB 1.0b 라이브러리 예제 (0) | 2013.08.14 |
| 문자열 처리 함수 정리 (0) | 2013.08.14 |
| FFMPEG 압축 기본적인 사용법 (0) | 2013.08.14 |
| [펌] C 프로그래머가 알아야할 것들 #4 (0) | 2013.08.14 |