자료조사(9) - RTP Packet Payload Type

by Blogger 하얀쿠아
2012. 1. 3. 07:26 수행 프로젝트 이력/참여자주도형 정보공유 시스템 [2011.12~2012.02]
본 포스팅은 이번 프로젝트에서 사용하는 RTP 패킷에 대한 자료조사 덧붙임이다.
RTP 패킷의 헤더에는 데이터 형식을 지정하는 PT(Payload Type) 필드가 있다.
8비트가 할당되므로 0~255 까지의 숫자로 표현된다.

이번 프로젝트에서는 PCMA ( G.711 코덱 ) 형식의 음성 데이터를 주고 받는데, 해당 PT 번호는 8번이다.
아래는 몇가지의 PT번호를 나타내는 표이며 출처에 표기한 사이트에서 발췌하였다.

출처 : http://www.packetizer.com/in/q9.html

The information in this article applies to: H.323, H.225.0, H.245, RTP (RFC 3550)

If there is a static payload type defined for a media, it must be used. Several endpoints currently violate this requirement. Here are the relevant passages in H.225.0v2. 6.2.1: "Payload Type(PT): Only ITU-T payload types such as (0)[PCMU], (8)[PCMA], (9)[G722], and (15)[G728] shall be used. Dynamic payload types exchanged using H.245 signaling shall be used for any ITU-T payload types not listed in Annex B." 6.2.2: "Payload Type(PT): Only ITU-T payload types such as that for H.261 shall be used. Dynamic payload types may be used for H.263 or other ITU-T algorithms for which payload types do not exist." (A payload has been defined for H.263 since this was written, so now the static payload type of 34 must be used for H.263.)
    PT         encoding      audio/video    clock rate    channels
               name          (A/V)          (Hz)          (audio)
 
    0          PCMU          A              8000          1
    8          PCMA          A              8000          1
    9          G722          A              8000          1
    4          G723          A              8000          1
    15         G728          A              8000          1
    18         G729          A              8000          1
    31         H261          V              90000
    34         H263          V              90000
    96--127    dynamic       ?
 
    Table 2/Annex B-H.225.0:
    Payload types (PT) for standard audio and video encodings


 
이 댓글을 비밀 댓글로

자료조사(8) - RTP (real Time Procotol)

by Blogger 하얀쿠아
2011. 11. 27. 20:05 수행 프로젝트 이력/참여자주도형 정보공유 시스템 [2011.12~2012.02]

RTP(Real Time Protocol)

>> RFC 3550


☛ 개요

RTP는 오디오, 비디오 및 시뮬레이션 데이터와 같은 실시간 데이터를 멀티캐스트 또는 유니캐스트 네트웍을 이용해서 전송하는 응용 서비스에 알맞은 단말-대-단말 네트웍 전송 기능을 제공한다.  RTP는 자원 예약을 수행하지 않으며, 따라서 적시 전달, 순차 전달과 같은 서비스 품질도 보장하지 않는다. RTP 데이터 전송 기능은 제어 프로토콜에 의해 확장되는데, RTCP라 불리우는 이 제어 프로토콜은 데이터의 전달 상황을 감시하며, 최소한의 제어 기능과 매체 식별 기능을 제공한다. RTP와 RTCP는 하위의 전송 및 네트웍 계층에 무관하게 설계되었다.
   RTP는 별개의 독립 계층으로 구현되기 보다는 특정 응용에서 요구되는 정보를 제공하여 프로토콜의 처리가 응용의 처리 과정으로 통합될 수 있도록 설계되었다. 따라서 기존의 프로토콜들과는 달리 RTP는 응용의 필요에 따라 헤더를 변경하거나 추가하여 응용에 맞는 프로토콜이 될 수 있도록 하는 일종의 맞춤형 프로토콜이다. 이 문서에서는 RTP를 이용할 수 있을 것으로 추정되는 모든 응용들이 공통적으로 필요로 할 기능들 만을 명시하고 있다. 따라서, 특정 응용 서비스에 필요한 RTP를 구현하기 위해서는 이 문서 이외에 RTP 페이로드의 종류와 형식을 정의하는 프로파일 문서(Profile Specification)와 페이로드의 전송 방법을 정의한 페이로드 형식 문서(Payload Format Specification)가 필요하다.

☛ 특징
- UDP상에서 실행
  UDP는 TCP에 비해 신뢰성이 낮은 반면, 더 빠르게 데이터를 전달함. 이러한 UDP의 특성을 이용하여 RTP가 등장하였다. 그래서, RTP는 그 자체로 QoS 보장이나 신뢰성을 제공하지 못한다.(RTCP를 통해 QoS를 보장)
- 송신자는 데이터 단위를 RTP 패킷으로 캡슐화한 후 그 패킷을 UDP 세그먼트로 캡슐화해서 IP에게 넘겨준다.
- RTP 세션 다중화
   효과적인 프로토콜 처리를 위해서 다중화 점의 수는 최소화되어져야 한다. RTP의 경우에 다중화는 목적지 전송 주소에 의해 수행된다.. 예를 들어 오디오와 비디오로 이루어지는 회의에서 각 매체는 자신만의 목적지 전송 주소를 가지는 독자의 RTP 세션으로 전송되어야 한다.
- 수신자는 UDP 세그먼트로부터 RTP 패킷을 추출한 후에 RTP 패킷으로부터 데이터 단위를 추출해서 디코딩 및 렌더링을 위해 미디어 플레이어에게 전달한다.
- RTP는 다른 3계층, 4계층 프로토콜과도 같이 사용이 가능하며,
  하위 프로토콜에 별로 의존하지 않음.

☛ RTP 패킷헤더 필드
 


-부하타입, 순서번호, 타임스탬프, 근원지식별자 필드가 있다.
1. 페이로드타입필드의 길이는 7비트이다. 오디오 스트림의 경우, 사용되는 오디오 인코딩타입을 타나내기 위해 사용한다. 만일 송신자가 세션 중간에 인코딩을 변경하면, 송신자는 수신자에게 페이로드 타입 필드를 사용해서 이 변경사항을 알려준다. 예컨대, 송신자는 오디오 품질을 향상시키거나 RTP스트림 비트율을 감소시키기 위해 인코딩을 변경하고자 할 수도 있다.
표 RTP에서 제공하는 오디오 페이로드 타입

 

페이로드 타입 번호
오디오 포맷
샘플링 비율
비율
0
PCM μ-law
8 kHz
64 kbps
1
1016
8 kHz
4.8 kbps
3
GSM
8 kHz
13 kbps
7
LPC
8 kHz
2.4 kbps
9
G.722
16 kHz
48-64 kbps
14
MPEG 오디오
90 kHz
-
15
G.728
8 kHz
16 kbps
   비디오 스트림의 경우에 페이로드 타입은 비디오 인코딩 타입을 나타내기 위해 사용된다. 이 때도 송신자    는 세션 중에 비디오 인코딩을 변경할 수 있다.
표 RTP에서 제공하는 비디오 페이로드 타입
페이로드 타입 번호
비디오 포맷
26
Motion JPEG
31
H.261
32
MPEG 1 비디오
33
MPEG 2 비디오
2. 순서번호필드의 길이는 16비트이다. 순서번호는 전송되는 RTP 패킷마다 하나씩 증가하며, 패킷 손실을 감지하고 패킷 순서를 회복하기 위해 수신자가 사용할 수 있다. 예를 들어, 만일 애플리케이션의 수신자가 순서번호 86과 89사이에 공백이 있는 RTP패킷 스트림을 수신하면, 수신자는 패킷 87과 88을 잃어버렸음을 알게 된다. 그러면 수신자는 손실된 데이터를 막기l 위해 시도할 수 있다.
3. 타임스탬프 필드의 길이는 32비트 이다. 이 필드는 RTP 데이터 패킷의 첫 번째 바이트의 샘플링 시점을 나타낸다. 수신자는 네트워크에 의해 만들어진 패킷 지터를 제거하고 수신자가 동기적인 재생을 가능하도록 타임스탬프를 사용할 수도 있다. 타임스탬프는 송신자 샘플링 클록으로부터 생성된다. 예를 들어, 오디오의 경우에는 타임스탬프의 클록은 각 샘플링 주기마다 하나 증가한다. 만일 오디오 애플리케이션이 160개의 인코딩된 샘플로 구성된 chunk를 생성한다면, 근원지가 활성일 때 타임스탬프는 각 RTP 세션마다 160씩 증가한다. 타임스탬프 클록은 근원지가 비활성일 때 조차도 일정 비율로 계속 증가한다.

 
그림 RTP layer

4. 동기근원지 식별자(SSRC): SSRC 필드의 길이는 32비트 이다. 이 필드는 RTP 스트림의 근원지를 식별한다, 대개, RTP 세션의 각 스트림은 상이한 SSRC를 갖는다. SSRC는 송신자의 IP 주소 대신에 새로운 스트림이 시작될 때 근원지에서 임의 할당한 숫자이다. 두 스트림이 동일한 SSRC를 할당받을 확률은 매우 작다. 만일 이런 일이 발생하면 두 근원지는 새로운 SSRC 값을 선택한다.



RTP로 소프트웨어 애플리케이션 개발방법
1. 애플리케이션 개발자가 RTP 캡슐화를 수행하는 송신자의 코드와 RTP 패킷을 풀어보는 수신자의 코드를 직접 작성해서 RTP를 추가하는 것.
2. 캡슐화 및 역캡슐화를 수행하는 기존 RTP 라이브러리와 자바 클래스들을 애플리케이션 개발자가 사용하는 것이다.

   예를들어, 음성을 전달하기 위해 RTP를 사용하는 것에 대해 생각해보자. 음성 데이터는 64kpbs의 PCM으로 인코딩된다고 가정하자. 또한 애플리케이션이 인코딩된 데이터를 20밀리초의 데이터 단위(즉, 한 데이터 단위에 160바이트)로 모은다고 가정하자. 송신자는 오디오 데이터의 각 데이터 단위 앞에 오디오 인코딩 종류, 순서번호, 타임스탬프 등을 가진 RTP 헤더를 덧붙인다. RTP 헤더는 보통 12바이트이다. 오디오 데이터 단위에 RTP 헤더를 덧붙여서 RTP 패킷을 구성한 후, UDP 소켓 인터페이스로 전송한다. 수신자의 애플리케이션은 소켓 인터페이스에서 RTP 패킷을 수신한 후, RTP 패킷에서 오디오 데이터 단위를 추출하고, 추출된 RTP 패킷의 헤더 필드를 살핀 후에 오디오 데이터 단위를 적절히 디코드 및 재생한다.
        페이로드 타입이나 순서번호, 타임스탬프를 제공하는 개인 기법 대신에, 애플리케이션이 RTP를 사용하면 훨씬 쉽게 다른 네트워킹 멀티미디어 애플리케이션을 통합할 수 있다. 예를 들어. 만일 두 회사에서 인터넷 폰 애플리케이션을 개발할 때 RTP를 사용한다면, 한 회사의 인터넷 폰 제품을 사용하는 사용자가 다른 회사의 인터넷 폰 제품을 사용하는 사용자와 통신 가능할 거라고 기대할 수 있다.
        RTP 자체가 시간에 맞춘 데이터 전달을 보장하거나 다른 서비스 품질 보장을 제공하는 기법을 지원하지 않는다는 것이다. 즉, RTP는 패킷 전달을 보장하거나 패킷 전달 순서를 보장하지 않는다. 실제로 RTP 캡슐화는 종단 시스템에서만 된다. 라우터는 RTP 패킷을 전달하는 IP 데이터그램과 RTP 패킷을 전달하지 않는 IP 데이터 그램을 구분하지 않는다.
        RTP는 각각의 근원지(예:마이크로폰, 카메라)에게 자신만의 RTP 패킷 스트림을 생성할 수 있도록 허용한다. 예를 들어, 두명의 참여자가 있는 화상회의의 경우, 두 개의 오디오 송신용 스트림(각 방향으로 하나의 스트림)과 두 개의 비디오 송신용 스트림(각 방향으로 하나의 스트림)등 총 네 개의 RTP 스트림이 만들어질 수 있다. 그러나 MPEG1이나 MPEG2 같은 대다수 많이 사용되는 인코딩 기법은 인코딩 과정에서 오디오와 비디오를 하나의 단일 스트림으로 합친다. 인코더에서 오디오와 비디오를 합치면 각 방향으로 하나의 스트림만 생성된다.
        RTP 패킷은 유니캐스트 애플리케이션에 한정되지 않는다. RTP 패킷은 일대다 EH는 다대다 멀티캐스트 트리로 전송될 수도 있다. 다대다 멀티캐스트 세션에 대해, 세션의 모든 송신자와 근원지는 RTP 스트림을 전송하는 데 있어서 일반적으로 동일한 멀티캐스트 그룹을 사용한다. 화상회의 애플리케이션에서 다수의 송신자들에 의해 전송되는 오디오, 비디오 스트림과 같이 함께 포함된 RTP 멀티캐스트 스트림들은 하나의 RTP 세션에 속하게 된다.
이 댓글을 비밀 댓글로

자료조사(7) - RTP/RTCP 프로토콜 (실시간 통신 프로토콜)

by Blogger 하얀쿠아
2011. 11. 25. 12:11 수행 프로젝트 이력/참여자주도형 정보공유 시스템 [2011.12~2012.02]

RTP/RTCP

 * 관련문서 : RFC 1889, RTP - A Transport Protocol for Real-time Applications

IETF AVT WG에서 작성한 인터넷 표준이다. RFC 1889는 실시간 응용 데이터
전송을 위한 트랜스포트 프로토콜인 RTP와 제어 정보를 전달하는 RTCP로 구성된다.


RTP (Real-time Transport Protocol)
 

RTP는 멀티캐스트 또는 유니캐스트상에서 음성, 화상, 또는 모의 데이터와 같은 실시간 데이터를 전송하는 응용에 적합한 단대 단 트랜스포트 기능을 제공한다.

그러나 RTP는 자원 예약에 대한 내용은 다루지는 않으며, 특히 적시 데이터 전송 (timely delivery), QoS 보장, 뒤바뀐 순서의 전송 방지와 같은 기능을 제공하지 않는다. 따라서 트랜스포트의 의미는 실시간 데이터의 특성에 중점을 두어 제정한 표준이라고 할 수 있다. RTP패킷은 UDP를 이용하여 전달된다.


RTP패킷 양식 그림


(그림 1) RTP 패킷 양식


그림은 RTP 패킷 형태이다. 헤더는 고정 크기를 가지며 멀티미디어 정보에 따라서 헤더 뒤에 특정 정보 및 데이터가 붙게 된다.

V는 버전 필드이며 최근 
버전은 2.0이다. P는 32비트 단위로 패킷을 구성하기 위해서 사용된다.

P값이 세팅되면 payload 부분이 아닌 패딩 옥테트들이 패킷의 끝에 포함됨을 의미한다. 

X비트가 세팅되면 정확하게 한 개의 화장 헤더가 고정 헤더 다음에 온다는 것을 가리킨다.

CC는 고정 헤더에서 CSRC identifier의 개수를 가리킨다.

CSRC는 
RTP mixer가 combined stream으로 만드는 데 기여한 RTP 패킷 스트림의 소스이다. 즉, RTP 패킷들은 망을 통해서 전달되면서 중간 시스템에서는 여러 소스로부터 온 RTP 패킷들을 받고 이들을 적절히 조합시켜서 새로운 형태의 RTP 패킷을 만들고 이를 다음 시스템으로 전달하는데, 이러한 기능을 수행하는 중간 시스템을 RTP mixer라 한다. 

M은 멀티미디어 정보에 대한 프레임 영역을 나타낸다. 즉 패킷 안에서 음성과 화상 정보 등을 구별하는데 사용한다.

PT 필드는 RFC 1890에서 정의된 
프로파일의 RTP payload 양식을 지칭하고 응용에 의해서 해석된다.
프로파일은 
payload type code를 payload format으로 지정되고 고정된 대응을 시킨 것이다. 즉, PT가 0이면 인코딩 방식의 오디오 정보이고 800Hz clock rate를 갖으며 오디오 채널 1개를 갖는 것을 가리킨다. 현재 33개의 payload type이 정의 되어 있다.

sequence number는 RTP 패킷이 송신될 때마다 1씩 증가한다. 수신측은 이 필드를 이용하여 패킷분실을 감지 하고 패킷 순서를 재저장한다.

timestamp 필드는 RTP 
패킷의 첫 번째 옥테트가 샘플링된 시점을 나타낸다. 그 샘플링 시점은 일정하게 증가하는 클럭으로부터 생성된다. 이것은 실시간 데이터의 동기화와 지터 계산에 이용된다.

SSRC 필드는 카메라 또는 마이크 등의 데이터 원천지의 식별자를 가리킨다.

CSRC 필드는 RTP 패킷이 중간 시스템에서 혼합될 경우에 그 소스들을 구별할 수 있는 식별자들을 가리킨다. 그러나 다중화(multiplexing)와 체크섬은 UDP(User Datagram Protocol)을 이용한다. 또한 여러 목적지로의 데이터전송은 하위 계층에서 제공해야 한다.



이 댓글을 비밀 댓글로

자료조사(6) - H.323 프로토콜 의 구조

by Blogger 하얀쿠아
2011. 11. 25. 12:06 수행 프로젝트 이력/참여자주도형 정보공유 시스템 [2011.12~2012.02]

H.323 프로토콜을 구성하고 있는 여러 가지 관련 프로토콜의 구조에 대해 알아봅니다.


< 그림1 >


<그림1>은  H.323 프로토콜과 다른 프로토콜과의 관련성을 보여주고 있습니다.

H.323 프로토콜은 비디오와 보이스를 둘다 지원합니다.

(참고로 MGCP 는 보이스만 지원합니다.)


위 <그림1>처럼 H.323 에서 비디오 장비를 위한 코덱 으로는 H.261 과 H.263 이 정의 되어 있고 보이스를 위한 코덱 으로는 G. 시리즈의 코덱들이 있습니다.


여러분들이 잘 아시는 MPEG4 비디오 코덱이 H.263 코덱 입니다.

어쨌든 이러한 코덱들을 이용하는 미디어 스트림들은 RTP/RTCP 프로토콜을 이용하고 이것들은 UDP 프로토콜 기반에서 동작 합니다.


지금은 RTP 와 RTCP 프로토콜은 미디어 스트림이 전송될 때 사용되는 프로토콜이라고만 이해해 두십시오. 나중에 RTP와 RTCP 에 대해서도 자세히 다루겠습니다.


아래 <그림2>에서 보이듯이 미디어 스트림들은 다양한 코덱으로 인코딩 되며 RTP 프로토콜을 이용하여 전송 됩니다.



그림2 >

다시 <그림1> 보시면… T.120 프로토콜은 H.323 프로토콜내 에서 정의된 하나의 프로토콜입니다.

T.120 프로토콜은 데이터 공유를 지원하며 여러 유저들간의 실시간 통신을 위한 프로토콜 입니다.

대표적으로 T.120 프로토콜을 이용한 어플리케이션으로 마이크로소프트사의 화이트보드가 있습니다.

사용해 보신분들도 많으시겠지만 화이트보드를 이용하면 실시간으로 여러 사람의 PC 화면에 같은 자료를 공유하면서 회의를 하실수가 있습니다.

 

시스템 컨트롤 프로토콜로는 H.225, H.245, RAS 프로토콜이 있습니다.

H.225 ISDN Q.931 프로토콜처럼 콜의 생성과 유지, 종료를 관리하는 프로토콜 입니다.

H.323 프로토콜 마찬가지로 Q.931 프로토콜도 ITU-T 에서 발표한 프로토콜입니다.

그래서 실제로 H.225 프로토콜은 Q.931 프로토콜을 모태로 해서 만들어 졌고 매우 유사합니다.

 

다음으로 H.245 프로토콜은 콜에 참여한 단말 또는 게이트웨이간에 콜의 완성을 위해 필요한 코덱의 선택, RTP 위한 UDP 포트의 협의등 콜을 완성하기 위해 필요한 파라미터 값을 교환하기 위한 프로토콜 입니다.

 

마지막으로 RAS 프로토콜은 H.323 네트워크 내에서 게이트키퍼가 사용될 경우 각각의 단말이나 게이트웨이가 게이트키퍼와 통신을 사용되는 프로토콜 입니다.

 

위에서 언급한 시그널링 프로토콜 , H.225, H.245, RAS 프로토콜은 모두 TCP 프로토콜을 사용합니다.

, 보이스나 비디오 같은 미디어스트림은 UDP 프로토콜을 사용하고 콜을 만들기 위한 시그널 트래픽들은 안정적인 TCP 이용합니다.

 

내용을 토대로 예를 들어 보겠습니다.

<그림3> 참조 하십시오. 내용을 알기 쉽게 표현해 보았습니다

 

< 그림3 >

예를 들어 두대의 PC가 넷미팅 같은 H.323 어플리케이션을 가지고 Voice Over IP 콜을 한다고 가정하면…


두대의 PC 간의 콜 셋업은 H.225 프로토콜이 담당을하고 두대의 PC 간에 주고받을 보이스 트래픽을 위한 UDP 포트는 H.245 프로토콜을 통해 결정이 됩니다.


그리고 H.225 , H.245 프로토콜을 통해 만들어진 콜에 의해 전송되는 사람들의 목소리는 RTP,RTCP 프로토콜을 이용해 전송되게 됩니다.


오늘은 H.323 프로토콜을 구성하는 각각의 프로토콜의 개괄적인 성격과 전송프로토콜과의 관련성에 대하여 알아보았습니다.


출처 : http://blog.naver.com/PostView.nhn?blogId=mincloud1501&logNo=140012556932&redirect=Dlog&widgetTypeCall=true

이 댓글을 비밀 댓글로