Web and Real-Time Multimedia

신명기

305-350 대전광역시 유성구 가정동 161번지

한국전자통신연구원 멀티미디어표준연구실

E-mail : mkshin@pec.etri.re.kr

URL : http://pec.etri.re.kr/~mkshin/

Abstract:

WWW(World Wide Web)은 인터넷 상에 광범히 분산된 다양한 형식의 데이터를 손쉽게 검색할 수  있으며, 모든 응용의 사용자 환경을 손쉽게 포함시킴으로서 새로운 미디어 타입의 통합을 위한 가장 성공적인 기술로 평가받고 있다. Tim Berners-Lee에 의해 처음 개발될 당시 WWW은 텍스트 기반의 구조에 맞추어 HTTP, HTML, URL이 제안되어, 이를 통해 비동기적(asynchronous)인 형태의 검색과 상호작용을 지원하도록 설계되었다. 반면 최근 인터넷상의 상당수를 차지하는 오디오, 비디오와 같은 실시간 환경의 멀티미디어 데이터들은 연속적(continuous), 동기적(synchronous)이며, 대화형 특징을 포함하고 있어 WWW 에서 이러한 미디어들을 통합하기 위해서는 구조적인 확장이 요구된다. 본 발표에서는 오디오/비디오를 웹상에서 이음새 없이 통합시키기 위한 노력들을 기술한다. 인터넷 실시간 멀티미디어 데이터를 WWW에서 처리하기 위한 현재의 기술과 문제점들을 분석하고, 이를 해결하기 위해 현재 연구중인 WWW 기본 구조의 확장과 기술적인 해결책들을 소개한다.

Keywords:

WWW(World Wide Web), Real-Time Multimedia, URL, HTTP, HTML, Plug-Ins, RTP(Real-time Transport Protocol), RTSP(Real-Time Streaming Protocol)

1. 서론

텍스트 기반의 하이퍼텍스트 개념에서 출발한 WWW(World Wide Web) 기술은 새로운 미디어 타입을 통합하기 위한 가장 성공적인 기술로 평가받고 있다. 첫단계로서 NCSA Mosaic은 웹 페이지 내에 이미지를 포함시킴으로서 WWW 대중화에 크게 기여했으며, VRML(Virtual Reality Modeling Language)은 두 번째 WWW의 미디어 혁신으로서 웹상에 가상현실 응용을 포함시켰다. 마지막으로 1995년에 개발된 선 마이크로시스템즈의 자바는 바이트 코드를 통한 플랫폼 독립적인 새로운 미디어(객체) 환경을 웹에 불어넣음으로서 차세대 WWW 기술을 이끌어 나갈 주요한 기술로 인정받고 있다. Tim Berners-Lee에 의해 처음 개발될 당시  WWW은 텍스트 기반의 구조에 맞추어 HTTP(HyperText Transfer Protocol), HTML(HyperText Markup Language), URL(Uniform Resource Locator)이 제안되어 이를 통해 서버와 클라이언트간의 비동기적인 형태의 검색과 상호작용을 지원하도록 설계되었다. 반면 최근 인터넷상의 상당수를 차지하는 오디오, 비디오와 같은 실시간 환경의 멀티미디어 데이터들은 연속적, 동기적이며, 대화형 특징을 포함하고 있어 WWW 에서 이러한 미디어들을 통합하기 위해서는 기존 URL, HTTP, HTML로 구성된 WWW 구조의  확장이 요구된다.

지금부터 본 논문에서는 웹상에서의 새로운(?) 미디어 타입(인터넷 상에서는 이미 우리이게 친숙한 반면)인 오디오/비디오를 웹상에서 통합시키기 위한 일련의 노력들을 기술한다. 몇년전만 해도 오디오, 비디오 파일을 웹 페이지에 포함시키는 것은 그 문서 전체를 브라우징 하는데 걸리는 시간을 오랫동안 지연시킴으로서 일반적으로 많이 사용되질 못했다. 반면 요즘은 스트림 기술을 통한 넷스케이프의 플러그-인이나 Vosaic(Video Mosaic) 시스템에서 볼 수 있듯이 별다른 지연 없이 실시간 멀티미디어 데이터를 웹 화면상에 곧 바로 브라우징 할 수 있다. 또한 인터넷 폰의 경우, 사용자 인터페이스로 웹 브라우저를 이용함으로서 인터넷 전송 프로토콜과 응용을 웹에 통합시키려는 다양한 노력들을 엿볼 수 있다. 이런 방식들의 대부분은 인터넷 오디오 비디오 전송 프로토콜에 의해 기존의 TCP 기반의 웹 프로토콜을 대신한 것으로 기존 웹이 지니는 기본적인 장점들을 활용하지 못한다는 단점을 가지고

있다. 즉 실시간 멀티미디어 응용을 웹 사용자 환경에 단순히 포함시킨 것으로  기존 텍스트 문서와 동기화가 이루어지지 않는 등 수동적인 통합에 불가하다. 본 발표에서는 W3C를 중심으로 한 인터넷 실시간 멀티미디어 데이터를 WWW에서 처리하기 위해 기존 URL, HTTP, HTML 기술의 확장과 기술적인 문제점/ 해결책들을 기술한다.

2. 실시간 멀티미디어 웹의 정의

현재의 웹은 네트웍 공간의 어드레스 디렉토리로서의 역할뿐 아니라 인터넷 응용의 사용자 환경을 대신하고 있다. 실시간 멀티미디어 기술과 웹 환경을 통합하기 위한 노력은 다음과 같은 두 가지 형태로 나누어 볼 수 있다. 첫 번째는 단순히 웹을 실시간 멀티미디어 응용의 사용자 환경으로 구축하는 방식으로 인터넷 실시간 기술(RTP, RTSP ... /UDP)로 전송 받은 데이터를 플러그-인을 통해 웹 상으로 재생만을 하게된다. 이러한 방식은 인터넷 폰이나 비디오 브로드캐스팅, 온-디맨드용으로 현재 많이 사용되고 있다. 예를 들어 현재 인터넷상의 MBONE을 통해 중계중인 라이브를 Precept사의 IP/TV 플러그-인 제품(RTP 네트워킹 포함)을 이용하면 비디오 세션을 웹 화면에 브라우징 할 수 있다. 이러한 방식은 인터넷 실시간 멀티미디어 기술과 현재의 웹 표준 기술을 단순히 통합시킨 것으로 기존 웹이 지니는 장점들(HTTP라는 단순한 단일 하이퍼텍스트 전송 프로토콜만의 사용, 모든 인터넷 자원의 접근을 위한 URL 적용, 미디어 제작/포함을 위한 HTML 태그 언어의 사용 ...)을 상당수 활용하지 못한다는 단점을 가지고 있다. 따라서 다음 단계로 궁극적으로 실시간 멀티미디어 데이터가 웹에 통합되기 위해서는 실시간 멀티미디어 특징을 수용할 수 있는 웹 구조의 확장이 요구된다. 예를 들어 동일한 웹 전송 프로토콜을 통해 연속적인 실시간 미디어들을 전송 받을 수 있어야 하며, URL을 통해 실시간 스트림에 직접 접근이 용이해야 한다. 또한 브라우징 되는 각 미디어(텍스트, 이미지, 오디오, 비디오)간의 동기화, 연속 미디어의 제어(Back, Loop, Forward ... ) 등이 제공되어야 한다.

1990년 WWW이 개발된 이래로 웹을 사용하는 클라이언트와 웹 서버의 컨텐트 내용에도 많은 변화가 있었다. 한마디로 다양한 멀티미디어 데이터의 포함과 이에 따른 재생기의 사용이다. 결론적으로 말하자면, 웹 컨텐트는 현재의 멀티미디어 CD-ROM 타이틀, 혹은 TV 프로그램과 같은 형태로 발전될 것이다. 이는 웹 시스템이 대화형과 연속성을 지닌 멀티미디어 미디어를 분배하고 받아보기 위한 CD-ROM, TV와 같은 동일한 환경을 제공할 때 가능하다.

표 . HTTP를 이용한 음성 파일 다운로드 후 재생하는 과정

단계	웹 클라이언트	네트웍 메시지	웹 서버
1	사용자가 링크를 클릭
2	request메시지를 전송	GET/sound.au
3	파일을 버퍼링, 지연시간 동안 기다림	HTTP 1.0 200 OK ... content-type audio/basic ... 12A589CB 7344 ... (long) 7000 FF34	sound.au파일을 포함하는 response 메시지를 전송
4	sound.au 재생

그림 . HTTP를 이용한 오디오 파일 다운로드 후 재생

3. 오디오/비디오 처리를 위한 현재의 웹 기술

3.1 HTTP를 이용한 파일 다운로드 후 재생

초창기 웹 시스템에서 오디오와 비디오 파일은 기존 웹 문서와 동일한 방식으로 처리되었다.  그림 1은 HTTP를 통한 그 처리과정을 나타낸 것이다. 오디오, 비디오를 웹 문서에 첨부하고자 하는 제작자는 자신의 플랫폼에 맞는 저작 도구를 이용하여 오디오, 비디오 파일을 정적으로 생성하여 웹 서버에 문서와 함께 저장시킨다. 웹 클라이언트는 HTTP를 통해 웹 문서에 접근하게 되며, 오디오는 독립된Helper Application을 이용하여 재생되게 된다.

HTTP 프로토콜은 근본적으로 파일 검색 프로토콜이다. 표 1. 에 sound.au 파일을 검색 후 재생하는 프로토콜 단계를 나타내었다. 모든 전송 단계는 TCP 기반의 HTTP를 사용한다. 이 과정에서의 문제점은 단계 3에서의 긴 다운로드 지연 시간에 있다. 따라서 TCP를 이용하면 실시간 환경이 보장되질 않는다.

3.2 실시간 스트리밍 기술의 사용

HTTP는 데이터 양이 큰 오디오나 비디오 검색을 위해서는 긴 지연 응답시간 때문에 사용되지 않는다. 이러한 이유로 대부분의 실시간 멀티미디어 웹 응용들은 (RealAudio, VDOLive, StreamWorks ...) HTTP 대신 UDP 기반의 프로토콜을 사용한다. 이러한 스트리밍 프로토콜의 목적은 가능한 한 클라이언트 쪽의 출력을 빨리 하는데 있다. 그림 2. 는 스트리밍 기술을 이용한 방식을 나타낸 것이다. 이 아이디어의 핵심은 또 하나의 클라이언트/서버  한 쌍을 추가하는 것이다. 클라이언트 측에서는 웹 브라우저와 Helper Application이 동작하며, 서버 측에서는 웹 서버와 미디어 서버가 각각 독립적으로 동작한다. 표 2. 에 스트리밍 프로토콜을 이용하여 스트림 파일을 재생시키는 프로토콜 단계를 나타내었다. 표 1. 과 비교되는 중요한 점은 3단계에서 직접 스트림 데이터를 전송 받지 않고, 대신 그 데이터를 받을 수 있는 파라미터(메타 파일)을 받는다는 데 있다. 표 2. 의 경우는 미디어 서버의 IP 어드레스와 파일의 이름을 사용을 사용하는 예를 나타낸 것이다. 이 이후부터는 전형적인 스트리밍 프로토콜의 시나리오대로 동작하게 된다.

그림 . 새로운 데이터 타입과 프로토콜의 플러그-인

표 . 스트리밍 프로토콜을 이용한 웹상에서의 스트림 재생 과정

단계	웹 클라이언트	네트웍 메시지	웹 서버
1	사용자가 링크를 클릭
2	request메시지를 전송	GET/stream.xdm
3	파라미터 파일을 수신	HTTP 1.0 200 OK ... content-type : application/x-mpg ... 129.254.201.2 -f stream.mpg	Helper 파라미터 정보를 담고있는 response메시지를 전송
4	Helper를 파라미터(129.254.201.2, stream.mpg)를 가지고 호출 재생기 클라이언트		재생기 서버
5	미디어 서버에 연결, 스트림 전송을 받아 재생	스트리밍 프로토콜	stream.mpg 파일 전송

이러한 방식은 일반적으로 많이 사용되고 있지만, 실시간 멀티미디어 웹 시스템을 구축하는데 있어 다음과 같은 4가지 단점을 포함하고 있다.

□ 관리 면에서의 오버헤드

-브라우저에 새로운 Helper(혹은 플러그-인) 인스톨

-HTTP 서버에 새로운 MIME 타입 인스톨

□ 실시간 어드레스(메타 파일 -> 미디어 주소)를 얻기 위한 추가적인 라운드-트립 지연

□ 비디오/오디오 제어(Rewind, Forward, Loop ...) 지원 못함

□ 각 미디어간(텍스트, 비디오, 오디오 ...)의 동기화 지원 못함

따라서 웹과 실시간 멀티미디어 데이터의 이음새 없는 통합을 위해서는 웹에서 자연스럽게 지원되는GIF/JPEG와 같은 미디어 형태로 실시간 멀티미디어 데이터가 웹에서 처리되어야 하며,  각 미디어간의 CD-ROM과 같은 동기화, 이를 위한 실시간 웹 통신 구조가 요구된다. 이러한 각각의 아이디어는 멀티미디어 문서 표현 기술(CD-ROM, MPEG, MacroMedia, HyTime ...) 과 인터넷 전송 기술(RTP, RTSP...)을 웹 표준 기술로 활용하려는 단계에서부터 출발한다.

4. 웹 표준기술과 실시간 오디오/비디오 기술의 통합

멀티미디어 문서 표현 기술과 인터넷 오디오/비디오 전송 기술, 웹 기술의 장단점을 나열하면 다음과 같다.

□ 멀티미디어 문서 표현 기술

-장점 - 모든 미디어 지원, 하이퍼링크, 저작(Authoring) 도구/언어 제공

-단점 - 네트웍용 아님, 컨텐트 재사용 불가, 표준 없음

□ 인터넷 오디오/비디오 전송 기술

-장점 - RTP, RTSP 사용, 무료

-단점 - 다른 미디어와 통합이 어려움, 하이퍼링크 개념 없음

□ World Wide Web

-장점 - 하이퍼링크 사용, 새로운 컨텐트(미디어)통합 용이

-단점 - 실시간 멀티미디어 데이터를 처리하는데 구조적인 문제 있음

따라서 본 논문에서는 WWW 입장에서 3 기술의 장점을 공유, 실시간 멀티미디어 웹 시스템을 구축하려는 노력과 이에 따른 최근 기술 동향을 분석한다.

4.1 실시간 멀티미디어 웹 컨텐트 표현 기술

실시간 멀티미디어 컨텐트를 제작하기 위해 웹과 인터넷 기술쪽에서는 기존의 CD-ROM의 경험을 상당수 활용하고 있다. 웹상에서 실시간 멀티미디어를 표현하기 위한 연구 노력은 W3C 입장과 그 외의 다른 그룹의 입장으로 나누어 구분하여 분석할 수 있다. 현재 W3C에서는 실시간 멀티미디어를 웹에 통합시키기 위하여 기존의 웹 표현 방식(HTML, GIF, PNG, image, 이미지 맵, URL)에 확장을 가하는 작업을 하고 있다. 크게 다음과 같은 연구 항목으로 구분할 수 있다.

□ 시간 표현과 미디어간 동기화를 위한 선언적 형식(Declarative Format for Time

Representation and Media Synchronization)

예를 들어 "1분간 그 비디오를 보여주며, 10초동안 지정된 정지화면을 보여준다" 와 같은 웹상의 표현기술이 요구되며, 또한 연속적인 각 미디어간의 동기화가 이루어 져야 한다.

미디어 동기화를 위해서는 현재 JavaScript와 VBScript를 사용할 수 있다. 이러한 스크립트언어는 제작/관리하기 힘들며, 검색 엔진과 변환 툴을 구축하는데 어렵다는 단점을 가지고 있다. 따라서 최근 W3C에서는 기존의 HTML 언어와 호환되는  CSS(Cascading Style Sheet), XML(eXtended Markup Language)를 제안하여 이와 관련된 문제를 해결하고자 하고 있으며, 마이크로소프트나 넷스케이프에서도 위의 표준 작업에 긍적적으로 참여하고 있다.

□ 오디오/비디오 재생 제어(Controlling Audio/Video Replay)

웹 페이지 내에 오디오를 사용하는 가장 단순한 방법은 배경 음악으로서 사용하는 것이다. 이 경우 연속적인 "loop", "rewind"  등의 제어가 요구될 수 있다. 현재 제안된 방식중의 하나는 다음과 같다.

<video|audio src="address:port/filepath option=cyclic|control>

또한 모든 객체를 대상으로 W3C에서는 "OBJECT "'태그를 위한 표준 애트리뷰트를   정의하고자 하는 노력을 기울이고 있다. 참고로 넷스케이프에서는 플러그-인을 통하여 다음가 같은 방식을 통해 자체적으로 제어 정보를 갖도록 구현해 놓고 있다.

<embed src=x.zvi autostart=TRUE loop=TRUE>

□ URL내에 오디오/비디오 스트림 내장(Embedding URL's into Audio/Video Streams)

하이퍼텍스트(텍스트, 이미지) 처럼 오디오/비디오도 하이퍼링크로 확장될 수 있어야 한다. 예들 들어 이미지 맵 기능과 유사한 비디오 맵 기능을 제공할 수 있도록 스펙이 확장되어야한다.

□ URL을 통한 오디오/비디오 파일 일부분의 어드레싱(Addressing Subparts of

Audio/Video Files via URL's)

오디오/비디오 파일의 시간적인 일부분을 URL을 통해 직접 접근하는 방식이 요구된다. 예를 들어 "시작 5분, 끝에서 10분 동안의 오디오 파일 F의 클립"을 검색할 수 있어야 한다.

□ 오디오/비디오 데이터를 위한 공통적인 폴백 형식(Common Fallback-Format for

Audio/Video Data)

또하나의 문제점은 오디오/비디오 데이터의 표준화된 코딩/디코딩의 문제로 기존 코덱들은 근본적으로 인터넷을 배경으로 개발된 것이 아니기 때문에 패킷 손실이나 동적인 대여폭에 많은 영향을 받을 수 있다. 이를 위한 하나의 해결책으로 W3C의 PNG 이미지 포맷에서 제안된 모델을 고려하여 이와 유사한 방식을 현재 연구중에 있다.

W3C이외의 그룹에서는 이와는 다른 방식으로 해결책을 찾고있다. 예를 들어 자바 기술의 경우, 실시간 멀티미디어 컨텐트를 위한 분산 클래스 형식으로서 자바 바이트 코드를 사용하며, 미디어 API를 통해 제작이 가능하도록 연구하고있다. DAVIC(Digital Audio Video Council)은 정보 표현을 위한 기본 형식으로 MPEG을 사용하고 있으며, 최근 제안된 MPEG-6에서는 플랫폼 독립적인 환경을 고려하여 자바 버츄얼 머신을 포함하도록 하고있다. 이외에도 QuickTime, HyTime 등의 기술을 활용한 방식도 현재 활발히 연구중이다.

4.2 실시간 멀티미디어 어드레싱 스킴

현재 W3C를 중심으로 새롭게 제안되고 있는 멀티미디어 URL 스킴 방식은 많은 논의점을 포함하고 있다. 예를 들어 실시간 MBONE 세션의 경우 다음과 같은 URL을 통해 그 세션에 접근할 수 있으며

mbone://address:port:ttl:format

eg) mbone://224.0.12.6:5555:127:h.261

온 디맨드 서비스의 경우 다음과 같은 스킴을 갖도록 제안된 바 있다.

cm://address:port:format/filepath

eg) cm://129.254.201.2:mpeg/a.mpg

이러한 방식에 대한 제안은 IETF의 MMUSIC 그룹의 경우에는 부정적인 입장을 취하고 있다.  MBONE 세션의 경우 인터넷에서는 SDP라는 프로토콜로서 세션 정보를 주고받게 되며, 이를 URL을 통해 표현하고자 할때, 그 외의 다양한 정보들(예를 들면 세션 생성자 정보, 대역폭,  각 미디어 정보에 따른 애트리뷰트 값 등)를 표현하기 위해서는 URL 스킴 자체가 복잡해지기 때문이다. 예를 들어 SDP에서는 다음과 같은 스킴으로 실시간 세션을 정의하고 있다.

v = 0

o = mkshin 2890844526 2890842087  IN IP4 129.254.201.2

s = WWW Workshop

i = A Workshop on WWW Technologies ...

u = http://pec.etri.re.kr/www-kr/

e = mkshin@pec.etri.re.kr

c = In IP4 224.0.12.6/127

t = 2890844526 2890842087

a = receveonly

m = audio 4444 VAT PCM2

m = video 5555 RTP H.261

결국 실시간 세션 정보와 같이 SDP를 이용할 수 있는 대상은 URL으로 사용되기 어려울 것으로 보이며, 실시간 데이터의 상호동작 정보만을 포함하고 있는 rtp:// ... ,  phone:// ..   등의 URL은 필요에 따라 표준으로 제안되어 사용될 수 있을 것으로 보인다. 예를 들어 인터넷 폰으로 사용되는 URL을 제안할 경우 아래와 같이 정의되어 사용될 수 있으며,

phone://mkshin@pec.etri.re.kr

이 과정은 그림 3. 에서 보는바와 같이 오디오 형식을 협상하는 과정을 제외하고는 "mailto" URL과 동일하게 동작하는 시나리오를 의미하게 된다.

그림 . "phone" URL 동작 과정

4.3 실시간 멀티미디어 전송 기술

앞에서도 언급했듯이 HTTP를 이용한 실시간 멀티미디어 데이터 전송은 불가능하며, 이를 위해 새로운 HTTP-NG 개발을 위한 연구가 활발히 진행중이다. 한가지 방편으로 기존 HTTP를 UDP위에 동작하도록 설계하는 접근 방식이 있으며, 이러한 방식은 RTP/ALF (Application Level Framing) 을 이용할 수 있다는 장점이 있으나 클라이언트-서버 구현 모델을 더욱 복잡하게 만든다는 단점을 가지고 있다. 따라서 1차로 그림 4. 와 같은 실시간 웹 프로토콜 과정을 생각해 볼 수 있다.

그림 . 제안된 새로운 실시간 웹 프로토콜 ?

제안된 방식 그림 4. 에서 가장 중요한 이슈가 되는 기술은 2 번째 단계로 클라이언트의 TCP 연결에 의해 request를 UDP 기반의 실시간 프로토콜로 전환하는 것이다. 이 과정이 이루어지면 RTP 와 같은 응용에서의 프래이밍 프로토콜을 통해 각 미디어 타입이 패킷화 되어 전송되게 되며, 이를 받는 수신자 측에서는 각 미디어  재생을 위한 응용에서  디코딩을 함으로서 전송에 따른 동기화는 이루어지게 된다.

또한가지 인터넷 실시간 전송 기술과 웹과 관계된 연구 동향으로는 웹 컨텐트 자체를 멀티캐스팅 함으로서 인터넷 대역폭을 효율적으로 사용하는 동시에 웹을 통한 공동작업 기술을 들 수 있다.

웹에서의 멀티캐스팅 사용은 크게 다음과 같은 두 가지 접근 방식으로 연구되고 있다.

□ 웹 서버의 로드를 최소화하기 위해 캐쉬 기법에 이용

-W3C Replication and Caching Activity

□ 클라이언트 브라우저에 웹 컨텐트 자체를 브로드캐스팅 - 공동작업 가능

그림 . WebCanal 멀티캐스팅 웹 응용(b)

그림 . WebCanal 멀티캐스팅 웹 응용(b)

-mMosaic(http://sig.enst.fr/~dauphin/mMosaic/index.html)

-mWeb(http://www.cdt.luth.se/~peppar/progs/mWeb/)

-WebCanal(http://monet.inria.fr/)

WebCanal의 경우, 프랑스 INRIA의 Tie Liao가 개발한 멀티캐스팅 웹 응용으로 MBone상에서 웹 자원을 공유할 수 있도록 한다. 자바로 구현되어 있으며, Light weight Reliable Multicast transport Protocol (LRMP)/RTP를 이용한다. 그림 5. 는 WebCanal의 사용자 환경과 이를 통한 웹 브라우저 화면을 나타낸것이다.

그림 6. 실시간 멀티미디어 웹을 위한 응용

지금까지 제안한 기술과 요구사항들을 총 정리하여 실시간 멀티미디어 웹 응용을 위한 프토토콜 스택을 재 구성하면 그림 6. 과 같다. 인터넷 상에서는 각각의 기술 요소에 따른 표준 작업들을 병행함과 동시에 실재로 네트웍 상에서 계속적인 실험을 진행하고 있다.

5. 결론

텍스트 기반의 하이퍼텍스트 개념에서 출발한 WWW 기술은 새로운 미디어 타입을 통합하기 위한 가장 성공적인 기술로 평가받고 있다. 최근 인터넷상의 상당수를 차지하는 오디오, 비디오와 같은 실시간 환경의 멀티미디어 데이터들은 연속적, 동기적이며, 대화형 특징을 포함하고 있어 WWW 에서 이러한 미디어들을 다른 미디어들과 동등하게 통합하기 위해서는 기존 URL, HTTP, HTML로 구성된 WWW구조의  확장이 요구된다. 본 논문에서는 웹상에서의 실시간 성격을 갖는 오디오/비디오를 웹상에서 통합시키기 위한 연구 동향들을 소개하였다. 현재 W3C를 중심으로 진행되고 있는 연구는 크게 실시간 멀티미디어 웹 컨텐트 표현 기술과 실시간 멀티미디어 전송기술로 나눌 수 있으며, 각각 멀티미디어 표현기술(MPEG, HyTime,  CD-ROM..), 인터넷 멀티미디어 전송기술(RTP, RTSP ...)에서 사용되는 기술을 응용하여 웹 표준기술과 접목하려는 노력들을 하고 있다. 이러한 일련의 연구 결과는 결국 넷스케이프와 마이크로소프트의 웹 브라우저 기술에 채택됨으로서 곧 조만간 웹 브라우저 상에서 실시간 데이터의 검색을 로컬에 있는 CD-ROM을 사용하듯이 편리하게 됨으로서 멀티미디어 사용자 환경의 변화가 일어날 것으로 예견된다.

References

[W3C97] W3C, W3C Activity: Real Time Multimedia, 1997. URL: http://www.w3.org/pub/WWW/AudioVideo/Activity-new

[RTMW97] W3C, Workshop "Real Time Multimedia and the Web" (RTMW '96), Sophia-Antipolis, October 24/25 '96. URL: http://www.w3.org/pub/WWW/AudioVideo/RTMW96.html

[Hoschka96a] Philipp Hoschka, Real Time: Audio and Video, W3C Advisory Committee Meeting, Boston, June '96. URL: http://www.w3.org/pub/WWW/Talks/960610PHILIPP/slide1.htm

[Hoschka96b] Philipp Hoschka, "Sound and Video on the Web"5th WWW conference Tutorial,  Paris, May '96. URL: http://www.inria.fr/rodeo/personnel/hoschka/WWW5tutorial.ps.gz

[BOF95] Birds of a Feather session "Towards a Real-Time Multimedia Web", 4th WWW conference, Boston, December '95. URL: http://www.inria.fr/rodeo/personnel/hoschka/bof/minutes.html

[Schulzrinne96] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson RTP: A Transport Protocol for Real-Time  Applications, 1996. URL: http://ds.internic.net/rfc/rfc1889.txt

[Handley96] M. Handley, Session Description Protocol, Internet Draft , 1996. URL: ftp://ftp.isi.edu/confctrl/docs/

[mMosaic96] ENST, mMosaic, 1996. URL: http://sig.enst.fr/~dauphin/mMosaic/index.html

[mWeb97] CDT, mWeb application, 1996. URL: http://www.cdt.luth.se/~peppar/progs/mWeb/

[WebCanal97] INRIA, WebCanal - Broadcast of Web Documents, 1997. URL: http://monet.inria.fr/