1. 실시간 수송 프로토콜
1.1 실시간 수송 프로토콜 - RTP(Real-time Transport Protocol)
(1) RTP 특성
□ 실시간 멀티미디어 서비스를 위한 수송 계층 프로토콜이다.
□ UDP 기반으로 신뢰성 있는 서비스를 제공하지 않는다.
▷ 시간정보, 정보매체의 동기화 기능 제공
□ RTP는 완전한 프로토콜 조합을 규정하지는 않는다.
▷ 프로토콜의 프레임워크, 기본 역할, 동작, 메시지 포맷을 정의
□ 특별한 응용이 RTP와 결합되어 완벽한 프로토콜이 된다.
(2) RTP 관련된 표준
□ RTP는 다른 다양한 표준 프로토콜과 함께 사용된다.
▷ 세션 공지, 개시, 제어
▷ 미디어 압축
▷ 네트워크 전송
(3) RTP 번역기와 혼합기
□ RTP가 사용될 때는 그림3, 그림4와 같이 발신지(Source)와 목적지(Destination) 사이에 혼합기(Mixer)와 번역기(Translator)라는 중간 시스템들이 존재할 수 있다.
(※ RTP에서의 발신지(Source)는 음성과 영상이 각각 다른 발신지이며, 동시에 다른 목적지가 된다.)
▷ 혼합기 : 하나 또는 여러 발신지로부터 RTP 패킷을 받아, 그들을 묶어서 새로운 RTP 패킷을 만들어 전달한다.
▷ 번역기 : 여러 송신자들로부터 받은 각 RTP 패킷의 부호화 형식을 바꾼다든지, 멀티캐스트를 유니캐스트로 전환한다든지, 방화벽(Firewall)의 응용수준 필터(Application level filter)와 같은 역할을 하는 중간 시스템이다.
▷ 통신에 참여하는 모든 참여자들이 동일한 환경에서 참여한다면 혼합기와 번역기는 필요하지 않다.
→ 하지만, 전세계에서 인터넷을 통해 통신을 하는 참여자들이 모두 동일한 환경일 수는 없다.
(※ 예를 들어, 느린 속도의 데이터만 처리가 가능한 참여자가 고속 처리가 가능한 회의에 참여하고자 할 때, 또는 그 반대의 경우에 한명의 참여자로 인해 다수의 참여자에게 불이익을 줄 수 있으므로, 이를 방지하기 위해 혼합기와 번역기를 사용하여, 환경이 다른 참여자에게도 적절한 형태로 데이터를 변환하여 전달한다.)
(4) RTP 패킷의 구조
□ 첫 12옥텟은 기본 헤더 구간으로서 모든 RTP 패킷에 공통적으로 포함되며, 기여발신지 식별자(CSRC) 구간은 혼합기(Mixer)에 의해 새롭게 생성된 RTP 패킷에만 존재한다.
□ V(Version) 비트 : 첫 2비트 V는 개정판(Version) 구간으로서 RTP 프로토콜의 개정판번호를 나타낸다.
▷ 현재는 RTP 제2판이 사용되고 있다.
□ P(Padding) 비트 : RTP 패킷의 유료부하에 정보 매체 이외에 채워넣기(Padding) 옥텟들이 들어 있는지를 나타낸다.
□ X(eXtension) 비트 : RTP의 기본 헤더(첫 12옥텟) 이후에 헤더 확장 구간이 존재하는지를 나타낸다.
□ CC 구간 : RTP 기본 헤더 이후에 오는 CSRC 식별자들의 수가 기록된다.
□ M(Marker) 비트 : 여러 용도로 사용(RTP 패킷열에서 프레임 정렬과 같은 중요한 표시가 필요할 때 사용 등)
□ 유료부하 유형(PT:Payload Type) 구간 : RTP 유료부하에 들어있는 정보의 유형을 나타낸다.
□ 순서번호(Sequence Number) 구간 : RTP 패킷이 하나 전송될 때마다 1씩 증가하는 값으로, 수신자가 패킷손실을 검출하고, 패킷의 순서를 재구성할 때 사용된다.
▷ 순서번호의 초기값은 무작위(Random) 값으로 선택된다.
□ 타임스탬프(Time Stamp) 구간 : RTP 패킷의 유료부하에 들어 있는 정보 매체의 첫 번째 옥텟이 표본화(Sampling)된 시간을 나타낸다.
▷ 매체들간 또는 하나의 매체 내에서의 동기화와 지연변이의 계산에 사용된다.
□ 동기발신지 식별자(SSRC) 구간 : RTP 패킷을 생성한 발신지를 나타내기 위한 식별자
▷ 한 세션 내에서 여러 개의 RTP 발신지가 있으면 각 발신지들이 생성한 RTP 패킷은 다른 SSRC 값으로 구별된다.
□ 기여발신지 식별자(CSRC) 구간 : RTP 혼합기가 생성한 새로운 RTP 패킷에 포함되어 있는 각 RTP 패킷들의 발신지를 나타낸다.
(5) RTP 패킷의 식별자
□ SSRC(Synchronous Source 식별자)
▷ RTP 패킷을 생성한 발신지 표시
▷ 동일한 물리적 발신자 내에서 응용별로 다른 SSRC 가짐
→ 음성 정보, 영상 정보(서로 다른 타이밍 정보, 매체유형 변경을 위해)
▷ 특정한 하나의 RTP 세션 내에서 그 값이 유일하도록 각 발신자 별로 무작위로 선택
▷ 두 개 이상의 발신자가 동일 SSRC를 가질 수 있음
→ RTP 프로토콜이 해결
□ CSRC(Contributing Source 식별자)
▷ 여러 SSRC를 갖는 RTP 패킷이 혼합기에 의해 단일 RTP 플로우로 만들어질 경우
→ 혼합기가 새로운 RTP 패킷의 SSRC가 되며,
→ 기존 SSRC 들은 CSRC가 된다.
□ [그림6]의 패킷의 전달 과정은 다자간 회의 환경에서 각 참가자들의 음성 패킷을 혼합기에서 하나의 음성정보열로 만들어 이를 모든 수신자들에게 전달하는 경우의 예제이다.
▷ RTP 패킷의 전달 과정은 다음과 같다.
❶ 각각의 송신자들은 각 RTP 패킷을 번역기로 전송한다.
❷ 번역기는 여러 송신자들로부터 받은 RTP 패킷의 부호화 형식을 바꾸어 혼합기로 전송한다.
❸ 혼합기는 새로운 RTP 패킷을 생성하고, 새로운 동기발신지 식별자(SSRC) 값을 가진다.
❹ 혼합기는 번역기에서 받은 각 RTP 패킷들의 SSRC 값들을 새로운 RTP 패킷의 기여발신지 식별자(CSRC) 값으로 하여 전달한다.
☞ [그림6]에서는 각 송신자의 SSRC(49, 73) 값들이 새로운 RTP 패킷의 CSRC(49, 73)값으로 된다.
(6) RTP 패킷의 다중화
□ RTP 패킷의 다중화는 목적지 수송 주소를 통해 이루어진다.
▷ 음성과 영상이 각각 독립된 RTP 세션을 사용함을 의미한다.
▷ 음성과 영상을 사용하는 영상회의의 경우
→ 음성정보와 영상정보는 각각 서로 다른 목적지 수송 주소와 동기 발신지 식별자(SSRC)를 가지는 RTP 패킷으로 전달된다.
□ 매체별로 RTP 세션을 분리하는 이유
▷ 어떤 매체의 유료부하 유형이 세션 중간에 변경되었을 때, 어떤 매체의 것이 변경되었는지 알아낼 수 있는 방법이 없기 때문이다.
▷ 매체의 클록 속도가 서로 다른 여러 개의 유료부하 유형이 사용된다면 타임스탬프와 순서번호를 지정하기 위해 다른 메커니즘이 필요하기 때문이다.
→ 동기발신지 식별자(SSRC)가 한 RTP 세션에 대한 타임스탬프와 순서번호를 식별하도록 정의되어 있다.
▷ RTCP에는 유료부하를 식별할 수 있는 유료부하 유형(PT) 구간이 없기 때문이다.
→ RTCP 발신지와 각종 보고(Report) 패킷들이 동기발신지 식별자(SSRC)당 하나의 시간 정보와 순서번호 공간만을 서술하고 있다.
1.2 실시간 수송제어 프로토콜 - RTCP(Real-time Transport Control Protocol)
□ RTCP는 발신지 측의 응용과 목적지 측의 응용 사이에서 RTP 세션을 제어하거나 관리하는 프로토콜이다.
(1) RTCP 특징
□ RTCP는 RTP와 쌍(pair)으로 존재하며 양방향으로 사용된다.
□ RTP 세션을 제어 관리한다.
□ 데이터 전송 품질에 대한 정보를 응용계층에 제공한다.
▷ 송신자보고(SR, Sender Report)와 수신자보고(RR, Receiver Report) 패킷을 이용해 송신된 패킷 수에 대한 손실 패킷 수 비율, 도착 지연변이 등의 정보를 응용계층에 전달함으로써 적절한 조치를 취할 수 있도록 한다.
□ RTP 세션에 참여하는 참석자 파악
▷ RTCP는 CNAME(Canonical Name)이라는 RTP 발신지의 수송 레벨 식별자(Transport Level Identifier)를 운반하기 때문에, RTP 세션에 참고하고 있는 참가자를 파악할 수 있다.
▷ 목적지에서는 CNAME을 통해 어떤 참가자의 음성 세션과 영상 세션을 연관되어 있는 하나의 멀티미디어 세션으로 묶어 이들간의 동기화를 수행한다.
□ RTCP 패킷의 자원사용을 제한
▷ RTCP 패킷의 트래픽 볼륨을 전체 5% 이내로 제한한다.
→ 네트워크 자원을 과다하게 사용하는 것을 방지하고, 더 많은 참가자에게 RTP 세션을 허용하기 위해 제한한다.
▷ 참석자의 수에 따라 RTCP 패킷의 전송 빈도를 달리한다.
→ 각 참가자는 다른 모든 참가자들에게 RTCP 패킷을 보내기 때문에, 총 참가자 수를 파악할 수 있으며, 이를 그가 보낼 수 있는 RTCP 패킷의 수를 계산하는데 사용할 수 있다.
(2) RTCP 패킷 종류
□ 송신자 보고(SR)
▷ 세션에 참가하고 있는 발신지는 주기적으로 송신자 보고(SR) 패킷을 보내 다른 참가자들이 무었을 받아야 하는지를 알려준다.
▷ 현재 활성상태에 있는 발신지 세션 참가자들이 전송하고, 수신한 통계정보를 보냄
→ 보고(Report) 패킷을 보낸 이후, 다음 보고 패킷을 보낼 때까지 RTP 패킷을 하나 이상 보낸 송신자는 활성상태에 있는 송신자이다.
▷ 수신자 보고(RR)와의 차이점은 패킷 코드 이외에, 20옥텟의 송신자 정보 구간이 포함되어 있다는 것이다.
□ 수신자 보고(RR)
▷ RTP 패킷을 송신하지 않고 수신만 하는 참가자들이 수신한 통계정보를 보내는 것이다.
□ 송신자 서술(SDES:Source Description)
▷ 발신지를 식별하는데 필요한 정보를 제공(이름, 전자메일, 전화번호 등 기입)
□ 탈퇴(BYE)
▷ 세션을 탈퇴할 때 보냄
□ 응용(APP)
▷ 새로운 응용이나 추가된 기능 시험을 위해 사용된다.
(3) 패킷 구조 - 헤더
□ V(Version) 비트 : 첫 2비트 V는 개정판(Version) 구간으로서 RTCP 프로토콜의 개정판번호를 나타낸다.
▷ 현재는 RTCP 제2판이 사용되고 있다.
□ P(Padding) 비트 : 패킷의 유료부하에 정보 매체 이외에 채워넣기(Padding) 옥텟들이 들어 있는지를 나타낸다.
□ 수신 보고 카운트(RC:Reception Report Counter) 구간 : 이 패킷에 포함되어 있는 수신보고 블록의 수가 포함된다.
□ 패킷 유형(PT:Packet Type) 구간 : 유료부하 구간에 어떠한 종류의 패킷이 존재하는지를 표시 한다.
▷ SR = ‘200’, RR = ‘201, SDES = '202', BYE = '203', APP = '204'
□ 길이(Length) 구간 : 32비트 워드(Word) 단위로서 RTCP 패킷의 길이에 ‘1’을 뺀 값이 기록된다.
□ SSRC 구간 : SR 패킷 또는 RR 패킷을 보낸 발신지의 동기발신지 식별자(SSRC)가 기록된다.
(4) 패킷 구조 - 송신자 보고(SR)
□ NTP(Network Time Protocol) 타임스탬프 구간 : 이 보고 패킷을 보내는 절대시간(WallClock Time)이 기록된다.
▷ 이 절대시간은 다른 목적지들이 보낸 보고(Report) 메시지에 기록되어 있는 타임스탬프 값과 함께 사용되어, 수신자들까지의 왕복지연을 계산하는데 사용된다.
□ RTP 타임스탬프 구간 : NTP 타임스탬프와 동일한 시간에 대응한다.
▷ 매체들간 또는 한 매체내의 동기화에 사용된다.
□ 송신 패킷 수(Sender's Packet count) 구간 : 전송을 시작한 이래, 현재의 송신자보고 패킷을 보낼 때까지 전송한 총 RTP 패킷의 개수가 기록된다.
▷ 이 값은 발신지가 동기 발신지 식별자(SSRC)를 변경하면 ‘0’으로 리셋된다.
□ 송신 옥텟 수(Sender's Octet Count) 구간 : 전송을 시작한 이래 현재의 송신자보고(SR) 패킷을 보낼 때까지 전송한 총 유료부하의 옥텟수가 기록된다.
(※ 여기에는 패킷 헤더와 채워넣기(Padding) 옥텟이 포함되지 않는다.)
▷ 발신지가 동기발신지 식별자(SSRC)를 변경하면 ‘0’으로 리셋된다.
(5) 패킷 구조 - 수신자 보고(RR)
□ SSRC_n(Source Identifier) 구간 : 수신보고 블록에 들어 있는 정보와 관련된 발신지의 동기발신지 식별자(SSRC)가 기록된다.
□ 손실비(Fraction Lost) 구간 : 이전 송신자보고 또는 수신자보고 패킷을 보낸 이래, 발신지 SSRC_n이 보낸 RTP 패킷이 손실된 비율을 나타낸다.
▷ 손실된 패킷 수를 수신할 것으로 기대한 패킷 수로 나눈 값이다.
□ 누적 손실패킷 수(Cumulative Number of Packets Lost) 구간 : 수신을 시작한 이래, 발신지 SSRC_n이 보낸 RTP 패킷 중 손실된 총패킷 수이다.
□ 최대 수신 순서 번호(Extended Highest Sequence number Received) 구간 : 발신지 SSRC_n 으로부터 도착한 RTP 데이터 패킷에서 받은 가장 높은 시퀀스 번호
□ 도착 지연 변이(Interarrival Jitter) 구간 : RTP 패킷들의 도착 시간의 통계적 변이를 추정한 값으로 타임스탬프 단위로 측정된다.
□ 마지막 SR(Last SR) 구간 : 발신지 SSRC_n이 보낸 가장 최근의 RTCP 송신자 보고 패킷의 일부로 수신된 NTP 타임스탬프 64비트 가운데 32비트이다.
□ 마지막 SR 이후의 지연(Delay since Last SR) 구간 : 발신지 SSRC_n의 마지막 SR 패킷을 수신한 후, 수신보고 블록을 보낼 때까지의 지연을 1/65,536초 단위로 나타낸 것이다.
(6) 패킷 구조 - 송신자서술(SDES)
□ 패킷에는 송신자를 식별하는 항목들이 포함된다.
□ 송신자 카운트(SC) 구간 : 송신자서술(SDES) 패킷에 포함되어 있는 SSRC/CSRC 항목의 개수가 표시된다.
□ 각 항목은 SSRC/CSRC 식별자와 SSRC/CSRC에 관한 정보를 운반하는 0개 이상의 항목으로 구성된다.
▷ 각 항목은 8비트의 유형 구간과 정보의 길이를 나타내는 8비트 옥텟 카운터, 정보의 내용으로 구성된다. 정보의 내용은 다음과 같은 것들이 정의되어 있다.
¤ CNAME(Canonical Name) : 유일한 종단점 이름이며, SDES 형식에서 꼭 있어야 한다.
(TYPE=1, RTP 세션 내에서 유일, "user@host" 방식으로 값이 들어감)
¤ NAME : 사용자가 기록 가능한 이름(TYPE=2)
¤ EMAIL : 참가자의 전자우편 주소(TYPE=3)
¤ PHONE : 참가자의 전화번호(TYPE=4)
¤ LOC : 참가자의 지역 제공(TYPE=5)
¤ TOOL : 참가자에 의해 사용중인 RTP구현을 나타냄(TYPE=6)
¤ NOTE : 임시적인 메시지 전달을 위해 사용(주의/상태, TYPE=7)
¤ PRIV : 실험적인 또는 응용에 따른 SDES 확장(TYPE=8)
(7) 패킷 구조 - 탈퇴(BYE)
□ 회의를 탈퇴한다는 것을 알리는데 사용된다.
▷ 참가자가 세션을 떠났을 경우나, 충돌 등의 영향으로 SSRC가 변경되었을 경우
□ 길이(Length) 구간 : BYE 패킷에 포함된 SSRC/CSRC 식별자의 개수 표시
□ 탈퇴 이유(Reason for Leaving) 구간 : 탈퇴 이유를 나타내는 TEXT
(8) 패킷 구조 - 응용(APP)
□ 새로운 응용이나 기능이 개발된 경우, 패킷의 유형 값을 등록하지 않고 시험을 위한 목적으로 사용
▷ 만일 어떤 특정한 응용 패킷이 유용하다고 검증될 경우에는 공식적인 패킷유형 값을 할당받아 합법적인 RTCP 패킷으로 등록된다.
□ 서브타입(ST) : 응용에 종속되는 데이터를 위해 사용
□ 이름(Name) : 응용 패킷을 정의하는 이름으로 사용자가 선택
□ 데이터(Application-specific Data) : RTP에 의해 해석되지 않고 응용에 의해 해석
1.3 실시간 스트리밍 프로토콜 - RTSP(Real-time Transport Streaming Protocol)
(1) RTSP 특징
□ 인터넷을 이용하는 클라이언트/서버 환경에서 시간적 제약 조건이 비교적 느슨한 멀티미디어 정보를 전달하기 위한 통신 프로토콜이다.
□ 제작 : RealNetwork사, Netscape Communications사, 콜롬비아대학이 공동 제작
□ 표준화 : IETF MMUSIC(Multiparty Multimedia Session Control) 연구그룹에서 RFC 2326로 표준화
□ 동작 방식
▷ 클라이언트 : 서버에게 실시간 특성을 갖는 영상이나 음성정보의 전송을 요청
▷ 서버 : 클라이언트가 요구하는 정보를 전송
□ 기본적인 기능 : 일시정지(Pause), 완전정지(Stop), 계속(Resume), 종료(Close) 등
□ 사용 프로토콜 : TCP와 UDP를 포함하는 다양한 수송프로토콜 위에서 동작할 수 있고, RTP와 RTCP를 사용한다.
▷ 제어 메시지를 전송하기 위해서는, 신뢰성 있는 데이터 전송이 가능한 TCP를 사용한다.
□ RTSP는 HTTP(Hyper-text transfer protocol)에서 사용되는 확장 기법들이 RTSP에 바로 사용될 수 있도록, HTTP/1.1과 구문구조나 동작 등을 의도적으로 비슷하게 설계하였다.
▷ HTTP와 다른 점 : RTSP 서버는 상태(state)를 가지고 정보열의 전송 제어를 수행한다는 것과 다른 프로토콜 식별자를 가지고 있다는 것이 다르다.
□ RTSP의 응용 분야
▷ 현재 RealNetworks사의 G2라는 RTSP 클라이언트 프로그램, IBM의 RTSP Toolkit 등 인터넷 상의 주문형 비디오(Video on Demand) 형태의 서비스와 인터넷 라디오 방송에 많이 사용되고 있다.
(2) RTSP 동작과정
□ 클라이언트는 HTTP를 사용하여 웹서버(Web Server)로부터 세션 재생에 관한 정보를 받는다.
▷ 각 매체정보열 또는 이들을 엮어 만든 하나의 프로그램이라 할 수 있는 표현대상
(Presentation)은 RTSP의 URL(Uniform Resource Locator)에 의해 식별된다.
▷ 표현대상을 기술하는 파일에는 매체의 부호화 방식, 언어 등이 포함되어 있어서 클라이언트가 적절한 조합을 선택할 수 있게 되어 있다.
□ RTSP를 사용하여 클라이언트의 매체재생기(Media Player)와 멀티미디어 서버(Multimedia Server)에 제어 정보를 전달한다.
□ 세션의 설정과 해제는 RTSP에 의해 제어되고, 실제 멀티미디어 정보는 RTP를 통해 전달된다.
2. 인터넷 영상회의용 프로토콜과 응용
2.1 영상회의용 프로토콜 구조
인터넷에서 다자간 영상회의를 하는데 필요한 프로토콜들은 다음 그림과 같다.
□ 전달 네크워크와 관련된 부분
▷ 수송계층 이하의 프로토콜(UDP, TCP, IP)
▷ 자원예약 프로토콜(RSVP)
▷ 서비스품질 보장을 위한 네트워크 서비스(IntServ, DiffServ)
□ 회의 세션을 관리하는 부분
▷ 세션서술 프로토콜(SDP : Session Description Protocol)
▷ 세션공고 프로토콜(SAP : Session Announcement Protocol)
▷ 세션개시 프로토콜(SIP : Session Initiation Protocol)
▷ 단순회의제어 프로토콜(SCCP : Simple Conference Control Protocol)
□ 사용하는 매체의 부호화와 종단간 전달을 담당하는 부분
▷ 각 매체의 부호화 모듈
▷ RTP/RTCP, RTSP
□ 응용 프로그램들
▷ sdr(Session Directory)
▷ vat(Video Audio Tool)
▷ vic(Video Conference)
▷ wb(WhiteBoard)
□ 기타
▷ SMTP(Simple Mail Transfer Protocol)
▷ HTTP(Hyper Text Transfer Protocol)
2.2 세션관리 프로토콜
영상회의 세션이 만들어질 에정이라면, 회의 참가자들을 위해 회의 안내문을 작성한 다음, 이를 공고하여 회의가 있음을 알리고, 참가자들을 관리하고, 회의 진행을 제어하는 일이 필요할 것이다. 이러한 일을 통틀어 세션 관리라고 하며, 다음과 같이 이를 위해 필요한 프로토콜들의 집합을 세션 관리 프로토콜이라 한다.
(1) 세션관리 프로토콜
□ 세션서술 프로토콜(SDP)
▷ 멀티미디어 세션들을 기술하고 다양한 형식의 세션을 초기화하는데 사용된다.
□ 세션공고 프로토콜(SAP)
▷ 멀티캐스트 회의 세션들에 대한 공고 프로토콜이다.
□ 세션개시 프로토콜(SIP)
▷ 멀티캐스트 세션을 초기화 하는데 사용된다.
▷ 사용자가 멀티캐스트 세션에 참가하도록 하는 방법에 대한 프로토콜이다.
□ 단순회의제어 프로토콜(SCCP)
▷ 비교적 소규모의 긴밀한 회의제어에 사용되는 프로토콜이다.
(2) 세션서술 프로토콜(SDP)
□ 세션을 서술하는 형식만 명시
□ 서술된 정보의 분배
▷ SAP, SIP, RTSP, HTTP, IMAP 등의 프로토콜 사용
□ 세션서술 정보
▷ 세션의 이름과 목적, 시작 시간
▷ 세션에 사용되는 매체의 종류, 주소와 포트번호
▷ 회의에 사용될 대역폭, 세션 책임자의 연락처
□ UDP 패킷이나 MIME 메시지의 일부로 ASCII 문자가 사용된다.
□ 매개변수
▷ 세션서술변수(Session Description Parameter)
▷ 시간서술변수(Time Description Parameter)
▷ 매체서술변수(Media Description Parameter)
▷ 세부변수
→ 여러 개의 세부 변수로 구성된다.
→ 프로토콜 개정판, 소유자(Owner), 세션이름, 세션시각, 매체명과 수송주소는 반드시 포함되어야 한다.
(3) 세션공고 프로토콜(SAP)
□ SDP로 서술된 세션의 존재를 사용자에게 알리기 위한 프로토콜
□ 지정된(well-known) 멀티캐스트 주소와 포트번호 사용
▷ 주소 : 114.2.127.254
▷ 포트 : UDP port 9875
□ 세션이 공고되는 범위 : 그룹주소의 범위나 생존시한(TTL)에 의해 제한
▷ 즉, 원하는 범위 내에서만 세션이 이루어질 수 있도록 할 수 있다.
□ 공고에 의해 수신된 세션의 삭제 방법
▷ SDP 패킷에 포함된 세션의 시작과 끝을 표시하는 타임스탬프 이용
▷ 예측한 주기보다 10배 이상 기다려도 안 올 경우와 30분 동안 오지 않을 경우
▷ 현재의 세션을 지우라는 세션삭제 패킷을 받을 경우
→ 저장된 세션이 인증헤더(authentication key)를 가지고 있어야 한다.
→ 인증헤더가 없다면 삭제 패킷이 같은 주소를 가지고 있어야 한다.
□ 공고된 세션의 내용 변경
▷ 해당 내용이 변경된 SDP 패킷을 전송한다.
▷ 세션 삭제와 같은 규칙이 적용
→ 변경된 공고가 저장된 세션 공고와 동일한 암호열쇠에 의해 서명된 인증헤더를 포함해야 하며, 인증헤더를 포함하지 않을 경우는 변경하려는 세션과 동일한 호스트로부터 온 패킷이어야 한다.
(4) 세션 개시 프로토콜(SIP)
□ SIP(Session initiation protocol)은 응용계층 제어 프로토콜로서 멀티미디어 세션이나 호를 설정, 변경, 종료하는데 사용된다.
□ 영상회의, 원격회의, 인터넷 전화 등과 유사한 응용에 사용될 수 있다.
□ 사용자들을 유니캐스트나 멀티캐스트 세션으로 초대할 수 있으며, 이미 진행 중인 세션에 참가자를 추가하거나 사용 매체를 추가할 수도 있다.
□ SIP이 초대할 수 있는 대상은 사용자(사람) 뿐 아니라 서버(기계)가 될 수도 있다.
▷ 예를 들면, 어떤 회의 세션을 서버에 녹화하고자 하는 경우, 서버를 사용자와 동일하게 세션에 초대함으로써 서버를 참가자의 일원으로 만들고, 모든 참가자에게 멀티캐스트 되는 회의 세션 내용을 서버가 녹화하게 하면 된다.
□ SIP에서는 어떤 사용자를 관장하는 위치관리 서버가 어떤 사용자가 어디에 있으며, 어떻게 위치를 알아낼 것인지를 알거나, 그를 찾을 수 있는 다른 위치관리 서버를 알고 있다고 가정한다.
□ 세션의 개시는 특정한 사용자를 회의에 초대하는 방식으로 이루어진다.
▷ 발신자와 착신자는 SIP 주소에 의해 식별된다.
▷ SIP 호(call)를 시작할 때, 발신자는 DNS를 통해 SIP 서버를 찾아서 SIP 서버에 SIP 요청 메시지를 보낸다.
□ SIP 서버는 대리자(Proxy) 서버와 호 전환(redirect) 서버의 두 종류가 있다.
□ SIP는 대리자(Proxy) 서버와 호전환 서버, 두가지 형태의 위치관리 서버를 인식하고 있다.
▷ 대리자 서버 : 사용자에 대해 서버와 클라이언트 모두로 동작하며, 어떤 사용자의 주소로 연결 요청이 들어오면, 위치관리 서버를 통해 그 사용자의 현재 주소로 호를 중계하여 연결이 이루어질 수 있도록 해준다.
▷ 호전환 서버 : 의장이 초대하려고 했던 수신자에게 INVITE 요청 메시지를 전달하지 않는 대신, 현재 수신자에게 접근할 수 있는 다른 위치를 의장에게 알려준다.
□ SIP에서 초대가 성공적으로 이루어지기 위해서는 두 가지의 요청 메시지가 필요하다. 하나는 초대를 알리는 INVITE 요청 메시지이고, 다른 하나는 수신자가 회의 세션 초대에 응하겠다고 응답을 한 경우에 보내는 CONNECT 요청 메시지이다.
▷ INVITE 요청 메시지에는 보통 수신자가 세션에 참가할 것인지를 판단할 수 있도록 세션을 서술한 내용이 포함된다.
¤ 사용될 매체의 종류나 형식 등에 관한 정보도 포함된다.
▷ 수신자가 초대에 응하는 경우, 수신자는 자신이 원하는 매체의 종류와 형식에 관한 내용을 포함시켜 발신자에게 응답할 수 있다.
¤ 수신자는 발신자의 요청 메시지를 수신하고 해석한 후, SIP 응답 메시지로 응답을 한다.
(5) 단순회의 제어 프로토콜(SCCP)
□ 회의를 진행하고 그룹을 구성하고 있는 개별 참가자들 간의 상호작용을 다룬다.
□ 필요한 제어나 관리
▷ 응용 제어(Application Control) : 올바른 초기 상태로부터 시작될 필요가 있으며, 해당 응용이 존재한다는 것을 다른 참가자들에게 알림
▷ 참가자 관리(Membership Management) : 현재 회의 세션에 누가 참가하고 있고, 누가 어떤 응용에 접근하는지를 제어
▷ 발언권 관리(Floor Management) : 발언권을 가진 사람이 누구인가를 제어
▷ 네트워크 관리(Network Management) : 사용자는 네트워크에게 종단 간에 매체를 전달하는 연결을 설정하고 해제하라는 요청을 하고, 네트워크는 체증 발생시 참가자들에게 사용 대역폭을 변경하라고 요청한다.
□ 네트워크상의 회의 제어방법
▷ IP 멀티캐스트 위에서 RTP와 RTCP를 사용
→ 다지점-대-다지점의 비교적 느슨한 회의 제어방법
▷ 멀티캐스트 기반에서 RTP와 RTCP를 사용
→ 명확한 회의 참가자 관리와 발언권 관리 기능이 있고 참가자들간에 빈번하게 상호작용이 발생하는 긴밀한 회의 제어방법
→ 단순회의 제어 프로토콜(SCCP)이 이 방법을 제공하기 위해 제안되었지만, 인터넷 분야에서는 아직 긴밀한 회의제어를 위한 범용 표준 기법이 존재하지 않는다.
2.3 MBone의 구조 및 응용
MBone은 멀티캐스트 백본(Multicast Backbone)의 약자이나, 실제 백본망은 아니고 인터넷상에서 멀티미디어 데이터를 전달하고자 하는 요구를 만족시키기 위해 만들어진 가상 네트쿼크이다.
여기서 가상 네트워크라는 의미는 통신에 참여하는 호스트들간에 멀티미디어 데이터를 전달하기 위한 다른 물리적 망이 존재하는 것이 아니라 실제로는 인터넷상에서 구현되어 있지만 인터넷과는 다른 네크워크가 존재하는 것처럼 보이게 했다는 것이다.
(1) MBone의 구조
□ 1992년 3월 미국 샌디에고에서 열린 IETF회의 세션을 실시간 음성 방송한 것으로부터 시작되었다.
□ 구조와 동작원리
▷ 그물형(Mesh) 구조와 성형(Star) 구조의 조합으로 구성된다.
→ MBone의 백본망 : 그물형 구조의 링크를 갖고, 지역망과는 mrouter로 연결한다.
→ 지역 멀티캐스트망 : 백본망에 접속되어 있으며, 성형 구조이다.
▷ 호스트는 Multicast 패킷을 이해해야 MBone에 연결할 수 있다.
▷ MBone에 참여하는 노드들은 IP 멀티캐스트를 지원하는 라우터이다.
▷ IP 멀티캐스트를 지원하지 않는 라우터가 중간에 있을 때 다음 mrouter까지는 터널링 기법을 통해 데이터가 전달된다.
▷ IP 주소 중 D Class 주소를 이용하여 호스트 그룹에 주소를 할당하고 멀티캐스트 한다.
→ IP 주소들은 mrouter에 의해 물리적인 이더넷주소로 변환되어 전달된다.
→ 이더넷 멀티캐스트 주소 : 01.00.5E.00.00.00에서 하위 32비트 이용하여 할당한다.
→ IP 주소 : 224.0.0.0 ~ 239.255.255.255 사이 값으로 할당한다.
(2) MBone의 터널링 기법
□ 터널링 기법은 IP 멀티캐스트를 지원하지 못하는 라우터를 통하여 독립된 MBone 서브넷간에 멀티캐스트 패킷을 전달하기 위해 사용된다.
□ 각 터널의 측도(Metric)와 문턱값(Threshold)
▷ 측도 : 여러 개의 터널 후보 중에서 최적의 경로를 찾기 위한 것이다.
▷ 문턱값 : 멀티캐스트 패킷이 도달되는 구역을 제한하기 위해 사용되는데, 주로 IP 패킷 헤더의 생존시한(TTL) 구간을 사용한다.
□ 터널링의 두가지 선택 기법
▷ IP 패킷의 LSRR(Loose Source and Record Route) 기법: 멀티캐스트 라우터가 IP 패킷의 헤더에 IP LSRR 옵션을 추가함으로써 패킷을 변형시키고, IP 목적지 주소 구간에 터널의 반대편에 있는 멀티캐스트 라우터의 유니캐스트 주소가 놓여진다.
→ 이 방법의 경우, 어떤 구조를 채택하고 있는 라우터에서는 패킷을 느린 경로로 전환시키는 경우도 있기 때문에 문제가 발생할 소지가 있다. 이 문제를 해결하기 위해 캡슐화 기법이 제안되었다.
▷ 캡슐화 기법 : 터널을 통해 멀티캐스트 패킷을 전달하고자 하는 멀티캐스트 라우터가 새로운 헤더를 추가하고, 그 헤더의 목적지 주소를 터널의 반대편에 있는 멀티캐스트 라우터의 유니캐스트 주소로 설정하고, IP 프로토콜 구간을 ‘4’로 기록하여 IP 패킷의 유료부하에 IP 프로토콜을 사용하는 패킷이 들어 있음을 알린다.
(3) MBone 응용
MBone의 응용으로 가장 많이 사용되는 도구로는 sdr, vic, vat, wb와 같은 것들이 있다.
□ sdr(session directory tool) : 멀티미디어 정보 자체와는 무관하지만, 그런 정보들을 보여주거나 들려주는 도구들을 종합적으로 관리하는 프로그램
▷ 보통 MBone상의 회의(Conference)들은 세션(Session)으로 정의되며, 이런 각 세션들은 다수의 IP 멀티캐스트 주소를 가질 수 있고, 다수의 전송 매체를 복합적으로 포함할 수 있다.
□ vat(visual audio tool) : 인터넷상에서 음성회의를 제공하기 위한 응용이다.
▷ 유니캐스트 IP를 사용하여 점-대-점으로 동작할 수 있지만, 주로 여러 명이 참여하는 회의용으로 사용된다.
▷ UNIX와 MS Windows상에서 구현되어 있으며, 각종 제어(전송 양, 소리 조절 및 매체 입력의 조절 등) 기능을 제공하기 때문에 현재 가장 널리 이용되는 MBone 음성 툴이다.
▷ PCM, ADPCM, GSM, LPC 등 여러 가지 음성부호화 기법들을 지원하며, 암호화를 사용하면 프라이버시도 보호될 수 있다. 이 경우 각 참가자들은 사전에 그 세션의 암호열쇠(encryption key)를 알아야 한다.
▷ 음성의 재생 시점을 네트워크의 지연 특성에 적응시킴으로써 지연을 최소화하는 기능이 있다.
▷ 손실이나 지연과 같은 네트워크 성능에 관한 통계 기능을 제공하여 사용자가 네트워크의 상태를 감시할 수도 있다.
□ vic(video conferece) : MBone상에서 영상회의(video conference)를 하기 위해 고안된 도구이다.
▷ 하드웨어에 의한 압축 및 복원의 장점까지 가지고 있으며, 사용자 접면을 변경하거나 확장할 수 있도록 모듈화된 소프트웨어 구조를 가지고 있는 것이 특징이다.
▷ 단독적으로 실행되는 프로그램이지만, sdr의 플러그인(plug-in)으로 이용되기도 한다.
▷ 영상 재생(play)뿐만 아니라 영상 게이트웨이(video gateway)까지 제공하는 프로그램이며, 가장 이용이 많은 프로그램이다.
□ wb(white board) : 대화형 영상회의를 진행하는데 있어, 음성과 영상 이외에 중요한 요소가 텍스트나 그래픽 정보 등을 다루는 전자칠판이다.
▷ 비교적 적은 대역폭을 사용하며, 보통 64kbps 정도를 사용한다.
▷ 지연보다는 패킷 손실에 민감하기 때문에 100%에 가까운 매우 높은 신뢰성이 요구된다.
▷ 패킷손실이 발생하는 경우, 신뢰성을 보장하는 멀티캐스트 기법을 사용하여 재전송을 통해 패킷손실에 대응하는 방법을 주로 사용한다.
정리하기
1. 요약정리
□ 실시간 수송 프로토콜(RTP: Real-time Transport Protocol)은 여러 명이 참여하는 영상회의의 필요성에 의해 고안된 프로토콜로서, 종단간에 음성이나 영상 또는 모의실험 데이터 등 실시간 특성을 가지는 데이터의 전달이 필요한 응용에서 사용되는 프로토콜이다.
□ RTP는 실시간 멀티미디어 서비스를 위한 수송 계층 프로토콜로써, UDP 기반으로 신뢰성 있는 서비스를 제공하지 않는다.
□ RTP는 완전한 프로토콜 조합을 규정하지는 않고 특별한 응용이 RTP와 결합되어 완벽한 프로토콜이 된다.
□ RTP 패킷의 SSRC(Synchronous Source 식별자)는 RTP 패킷을 생성한 발신지 표시로써, 동일한 물리적 발신자 내에서 응용별로 다른 SSRC 가지며 특정한 하나의 RTP 세션 내에서 그 값이 유일하도록 각 발신자 별로 무작위로 선택한다.
□ RTP 패킷의 CSRC(Contributing Source 식별자)는 여러 SSRC를 갖는 RTP 패킷이 혼합기에 의해 단일 RTP 플로우로 만들어질 경우 혼합기가 새로운 RTP 패킷의 SSRC가 되며, 기존 SSRC 들은 CSRC가 된다.
□ RTCP(실시간 수송제어 프로토콜)는 발신지측의 응용과 목적지측의 응용 사이에서 RTP 세션을 제어하거나 관리하는 프
로토콜이다.
□ RTCP는 쌍(pair)으로 존재하며 양방향으로 사용되고 RTP 세션을 제어 관리한다.
□ RTCP는 데이터 전송 품질에 대한 정보를 응용계층에 제공하고 RTP 세션에 참여하는 참석자 파악 및 RTCP 패킷의 자원사용을 제한한다.
□ RTCP 패킷의 송신자 보고(SR)는 세션에 참가하고 있는 발신지는 주기적으로 송신자 보고(SR)패킷을 보내 다른 참가자들이 무었을 받아야 하는지를 알려준다.
□ RTCP 패킷의 수신자 보고(RR)는 RTP 패킷을 송신하지 않고 수신만 하는 참가자들이 수신한 통계정보를 보내는 것이다.
□ RTCP 패킷의 송신자서술(SDES)는 발신지를 식별하는데 필요한 정보를 제공(이름, 전자메일, 전화번호 등 기입)한다.
□ RTCP 패킷의 탈퇴(BYE)는 세션을 탈퇴할 때 보낸다.
□ RTCP 패킷의 응용(APP)은 새로운 응용이나 추가된 기능 시험을 위해 사용된다.
□ RTSP(실시간 스트리밍 프로토콜)는 인터넷을 이용하는 클라이언트/서버 환경에서 시간적 제약조건이 비교적 느슨한 멀티미디어 정보를 전달하기 위한 통신 프로토콜이다.
□ 영상회의 세션이 만들어질 에정이라면, 회의 참가자들을 위해 회의 안내문을 작성한 다음, 이를 공고하여 회의가 있음을 알리고, 참가자들을 관리하고, 회의 진행을 제어하는 일이 필요할 것이다. 이러한 일을 통틀어 세션 관리라고 하며, 다음과 같이 이를 위해 필요한 프로토콜들의 집합을 세션 관리 프로토콜이라 한다.
□ SDP(세션서술 프로토콜)는 멀티미디어 세션들을 기술하고 다양한 형식의 세션을 초기화하는데 사용된다.
□ SAP(세션공고 프로토콜)는 멀티캐스트 회의 세션들에 대한 공고 프로토콜이다.
□ SIP(세션개시 프로토콜)는 멀티캐스트 세션을 초기화 하는데 사용되고 사용자가 멀티캐스트 세션에 참가하도록 하는 방법에 대한 프로토콜이다.
□ SCCP(단순회의제어 프로토콜)는 비교적 소규모의 긴밀한 회의제어에 사용되는 프로토콜이다.
□ MBone은 멀티캐스트 백본(Multicast Backbone)의 약자이나, 실제 백본망은 아니고 인터넷상에서 멀티미디어 데이터를 전달하고자 하는 요구를 만족시키기 위해 만들어진 가상 네트워크이다.
□ MBone의 터널링 기법은 IP 멀티캐스트를 지원하지 못하는 라우터를 통하여 독립된 MBone 서브넷간에 멀티캐스트 패킷을 전달하기 위해 사용된다.
□ MBone의 응용으로 가장 많이 사용되는 도구로는 sdr, vic, vat, wb와 같은 것들이 있다.
2. 참고자료
김재균 저, 영상통신시스템, 영지문화사, 2000.
'정보과학 > 영상통신시스템' 카테고리의 다른 글
| (토론)시간적 데이터 중복 (1) | 2023.10.18 |
|---|---|
| 모바일 영상 통신 (0) | 2023.10.18 |
| 영상 통신을 위한 인터넷 기술 (1) (1) | 2023.10.18 |
| H.264/MPEG-4 Part 10 (2) (0) | 2023.10.18 |
| H.264/MPEG-4 Part 10 (1) (1) | 2023.10.06 |
