KR101298342B1 - 분산된 다자간 회의를 제어하기 위한 메카니즘 - Google Patents

Abstract

본 명세서에 기술되는 기술 및 메커니즘은 풀 매시 아키텍쳐를 지원하는 분산된 다자간 회의에서 회의 멤버들 사이의 통신 경로를 제어하는 것에 관한 것이다. 동시다발적인 이슈를 조정하고 서비스의 질을 보증하기 위하여 몇몇 점검 사항들이 테스트된다. 먼저, 두 시스템 사이에 대기중인 통신 경로가 존재하는지 여부를 판정하는 검사가 이루어진다. 두번째로, 시스템 중 하나가 다자간 회의에서 탈퇴하는 프로세스 중인지를 판정하는 검사가 이루어진다. 세번째로, 회의 멤버의 최대수가 이미 회의내에 존재하는지 여부를 판정하기 위한 검사가 이루어진다. 이들 검사 중 임의의 검사에 실패하게되면, 두 시스템 사이의 통신 경로는 실패하게 된다. 여기에 성공하게 되면, 풀 매시 아키텍쳐를 유지하기 위하여 신규 시스템은 회의내의 각각의 다른 멤버들과 참가 프로세스를 개시한다.

다자간 회의, 통신 경로, 접속 요청, 접속 거부

Description

분산된 다자간 회의를 제어하기 위한 메카니즘{MECHANISM FOR CONTROLLING A DECENTRALIZED MULTI-PARTY CONFERENCE}

도 1은 본 명세서에 설명되는 기술들과 메카니즘들을 구현하는데 사용될 수 있는 컴퓨팅 디바이스의 예를 나타내는 도면;

도 2는 도 1에 도시된 컴퓨팅 디바이스가 2개 이상 포함될 수 있는 네트워크의 예를 나타내는 도면;

도 3은 본 명세서에 설명되는 기술들과 메카니즘들을 구현하기 위해 도 1에 도시된 컴퓨팅 디바이스 내의 컴포넌트들을 나타내는 기능 블럭도;

도 4는 도 2에 도시된 네트워크를 확립하고 유지하기 위한 회의 제어 프로토콜을 나타내는 표;

도 5는 도 2에 도시된 네트워크에 신규 사용자를 추가할 때 회의 제어 프로토콜의 동작을 나타내는 흐름도; 및

도 6은 일 멤버가 도 2에 도시된 네트워크를 벗어날 때 회의 제어 프로토콜의 동작을 나타내는 흐름도이다.

<도면의 주요 부분에 대한 부호의 설명>

302 : 사용자 인터페이스 310 : 매체 스트림 엔진

312 : 전송 모듈 304 : 회의 제어 모듈

308 : 메시지 서비스 I/F 306 : TCP/UDP I/F

본 발명은 일반적으로 컴퓨터-구현 회의 시스템에 관한 것으로, 보다 구체적으로는 분산된 다자간(multi-party) 회의 시스템들에 관한 것이다.

오늘날, 사람들은 상호 통신하기 위해 인터넷을 통한 메시징 서비스들을 자주 사용한다. 예를 들어, 개인은 그가 통신하기 원하는 친구들의 리스트를 생성할 수 있다. 친구들 각각은 리스트 상에 나타나는 고유한 사용자 아이디를 갖는다. 친구가 온라인 상태인 경우, 상기 개인이 그 친구가 통신할 수 있는 상태라는 것을 알 수 있게 하는 방식으로 그 친구의 사용자 아이디가 표시된다. 그러면, 상기 개인은 그 친구와의 "chat" 세션을 초기화하고, 일반적으로 인스턴트 메시지(IM; instant messages)라 불리우는 메시지들을 교환한다. 그 외의 친구들이 "chat" 세션에 추가되어, 다수의 사람들이 상호 통신하는 다자간 "chat" 세션에 이를 수 있다.

다자간 "chat" 세션을 갖는 것이 편리하기는 하지만, 사용자들은 메시지를 타이핑하는 것 보다는 다른 사람들을 볼 수 있으며, "실제 생화"과 유사한 경험을 경험하는 것에 더욱 관심을 갖게 되고 있다. 불행히도, 다자간 비디오 회의 시스템을 제공하는 것은 많은 도전과제들을 제공한다. 그 중 하나는 비디오 회의 애플리케이션의 높은 대역폭 요구와 인터넷 사용자들의 이질성 양자 모두를 취급할 수 있는 시스템을 설계하는 것이다. 또 다른 하나는 다수 당사자들간 통신을 유지하는 것이다.

많은 다자간 비디오 회의 시스템들이 LAN(Local Area Network) 상에서 동작만 할 수 있다. 이하의 내용은 LAN을 통해 동작하는 다자간 비디오 회의 시스템으로서: 1) 1990년 9월 캘리포니아주 로스앤젤레스에서 "컴퓨터-지원 협업에 관한 회의(Conference on Computer-Supported Cooperative Work)"의 진행 과정에서 "분산된 다수 당사자 데스크톱 회의 시스템(Distributed Multiparty Desktop Conferencing System): MERMAID"라는 제목으로 공개된 K. Watanabe 등이 저술한 논문에 개시된 MEMAID; 및 1994년 4월 IEEE 컴퓨터에 "MBONE, the Multicast Backbone"라는 제목으로 공개된 Mike Macedonia와 Don Bruzman이 저술한 논문이 있다. 이들 시스템은 LAN 상에서 동작하므로, 시스템은 LAN을 통해 전송되는 데이터량을 감소하기 위해 하드웨어 내에 멀티캐스트 특성들을 사용하기 때문에 대역폭 이슈는 문제가 되지 않는다. 불행히도, IP 멀티캐스트 인에이블드 라우터가 인터넷 상에서 보편적으로 채택되지는 않는다.

하드웨어 멀티캐스트 특성이 인터넷 상에서 보편적으로 채택되지는 않더라도, WAN(Wide Area Network) 상에서 다자간 비디오 회의 시스템을 구현하려는 시도는 있어 왔다. 캘리포니아주 산타모니카에 있는 "iVisit LLC" 사에서 제조되어 통상적으로 IVISIT라 불리우는 시스템은 서버-기반 통신 툴이다. IVSIT는 사용자들이 항상 액세스할 수 있는 중앙 서버들을 요구한다. 중앙 서버들은 멤버 등록 및 인증을 수행한다. 사용자들은 그들의 친구 리스트 상에서 확인된 다른 사용자들과 의 오디오/비디오 세션을 설정할 때 중앙 서버와 상호작용한다. IVISIT는 사용자로 하여금 동시에 다수 접속들을 하게 하고 다수의 비디오들을 볼 수 있게 하지만, 시스템이 이상적인 것은 아니다. 한 모드에서, 각각의 원하는 접속을 수동으로 수행하여야 한다. 다른 모드에서, 다수 당사자들은 단일 채트 룸 내에서 서로에게 인스턴트 메시지들을 보낼 것이지만, 비디오가 요구되는 경우, 비디오 통신은 이와는 독립적인 일-대-일 접속에 기반한다. 따라서, IVISIT는 일반 대중이 원하는 타입의 다자간 비디오 회의 시스템을 제공하지는 못한다.

캘리포니아주 산호세의 "WebEx Communication, INC" 사에서 제조되어 통상적으로 WEBEX라 불리우는 다른 시스템은 글로벌 비즈니스를 위해 온라인 미팅 서비스들을 제공한다. 이러한 서비스로는 애플리케이션 공유, 화이트 보드, 및 비디오 회의 등이 포함된다. WEBEX는 최종 사용자들 사이의 통신 라우팅을 위한 전세계적ㅇ니 많은 수의 스위칭 센터를 포함한다. 많은 수의 동시 비디오 회의들이 존재하는 경우 이러한 전략이 효율적이지만, WebEx는 소규모 개인 통신에 대하여는 너무 비싸다.

상술된 바와 같이, 서버가 통신을 취급하게 하는 것은 대규모 기업들에 대하여 효율적이지만, 서버-기반 시스템들은 소규모 개인 통신에 동작하기에는 여러 단점들을 갖는다. 그 중 하나는 서버의 구입 및 유지 비용이다. 다른 하나는 중앙 서버를 사용하기 때문에 생성되는 병목현상이다. 따라서, 지금까지, 일반 대중이 사용하기에 적합한 다자간 비디오 회의 시스템에 대한 만족스러운 해결책이 없었다.

본 명세서에 개시되는 기술들 및 메카니즘들은 풀 매시 아키텍쳐(full mesh architecture)를 지원하는 분산된 다자간 회의에서 회의 멤버들간 통신 경로들을 제어하는 것에 관련된다. 동시성 이슈들을 취급하고 서비스의 품질을 보장하기 위해 몇가지 점검 사항들이 테스트된다. 첫째, 2개 시스템들간 임의의 대기중인 통신 경로가 존재하는지 여부를 판정하는 점검이 이루어진다. 둘째, 시스템들 중 하나가 다자간 회의를 벗어나는 중인지 여부를 판정하는 점검이 이루어진다. 셋째, 최대 수의 회의 멤버들이 이미 회의에 존재하는지 여부를 판정하는 점검이 이루어진다. 이들 점검 중 어느 하나라도 실패하면, 2개 시스템간 통신 경로는 실패하게 된다. 성공하면, 신규 시스템은 풀 매시 아키텍쳐를 유지하기 위해 회의의 기타 멤버들간 상호와의 참가 프로세스(joining process)를 개시한다.

간략하게, 본 메가니즘은 분산된 다자간 비디오 회의 시스템을 확립하고 유지하는 회의 제어 프로토콜을 제공한다. 본 프로토콜은 몇 가지 점검 사항들을 사용하여 동시성 이슈들을 취급하고 서비스의 품질을 보장한다. 이하 상세히 설명되는 바와 같이, 본 회의 제어 프로토콜은 다이얼-업, 광역, 케이블 등의 서로 다른 타입의 인터넷 접속들 상에서 효율적으로 동작한다. 이들 및 기타 장점들은 이하 상세한 설명을 읽고 나면 자명하게 될 것이다.

도 1은 본 발명의 분산된 비디오 회의 메카니즘을 구현하기 위한 시스템의 일 예를 나타낸다. 본 시스템은 컴퓨팅 디바이스(100) 등의 컴퓨팅 디바이스를 포 함한다. 매우 기본적인 구성으로, 컴퓨팅 디바이스(100)는 통상적으로 적어도 하나의 처리 유닛(102)과 시스템 메모리(104)를 포함한다. 컴퓨팅 디바이스의 정확한 환경과 타입에 의존하여, 시스템 메모리(104)는 휘발성(RAM 등), 비휘발성(ROM, 플래시 메모리 등) 또는 이들의 조합일 수 있다. 시스템 메모리(104)는 통상적으로 운영 체제(105), 하나 이상의 프로그램 모듈들(106)을 포함하고, 프로그램 데이터(107)를 포함할 수 있다. 프로그램 모듈들(106)은 본 발명의 분산된 다자간 회의 메카니즘을 구현하기 위한 모듈들(130)을 포함한다. 이러한 기본적인 구성은 그 구성요소들이 점선(108) 내에 표시되는 도 1에 도시된다.

컴퓨팅 디바이스(100)는 추가적인 특징들이나 기능성을 가질 수 있다. 예를 들어, 컴퓨팅 디바이스(100)는 또한 예를 들어, 자기 디스크, 광 디스크 또는 테이프 등의 추가적인 저장 디바이스들(이동식 및/또는 비이동식)을 포함할 수 있다. 이러한 추가적인 저장 장치는 도 1에 이동식 저장장치(109)와 비이동식 저장장치(110)로 도시되어 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어들, 데이터 구조들, 프로그램 모듈들 또는 기타 데이터 등의 정보를 저장하기 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 포함할 수 있다. 시스템 메모리(104), 이동식 저장장치(109) 및 비이동식 저장장치(110)는 모두 컴퓨터 저장 매체의 예들이다. 따라서, 컴퓨터 저장 매체는, 이에 제한되는 것은 아니지만, RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD(Digital Versatile Disks) 또는 기타 광 저장 디바이스들, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장장치 또는 원하는 정보를 저장하는데 사용될 수 있고 컴퓨팅 디바이스(100)에 의해 액세스될 수 있는 기타 매체를 포함한다. 임의의 이러한 컴퓨터 저장 매체는 디바이스(100)의 일부일 수 있다. 컴퓨팅 디바이스(100)는 또한 키보드, 마우스, 펜, 음성 입력 디바이스, 터치 입력 디바이스 등의 입력 디바이스(들)을 포함할 수 있다. 디스플레이, 스피커, 프린터 등의 출력 디바이스(들) 또한 포함될 수 있다. 이들 디바이스는 당업계에 공지되어 있으므로 더 이상 논의할 필요는 없다.

컴퓨팅 디바이스(100)는 또한 디바이스로 하여금 네트워크 등을 통해 기타 컴퓨팅 디바이스들(118)과 통신하게 하는 통신 접속(116)을 포함한다. 통신 접속(들)(116)은 통신 매체의 일 예이다. 통신 매체는 통상적으로 컴퓨터 판독가능 명령어들, 데이터 구조들, 프로그램 모듈들 또는 반송파나 기타 전송 메카니즘 등의 변조된 신호에서의 기타 데이터에 의해 구현될 수 있다. "변조된 데이터 신호"라는 용어는 신호에 정보를 인코드하는 방식으로 하나 이상의 특징들이 설정되거나 변경된 신호를 의미한다. 예를 들어, 이에 제한되는 것은 아니지만, 통신 매체는 유선 네트워크 또는 직접-배선 접속 등의 유선 매체와 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함한다. 본 명세서에 사용되는 컴퓨터 판독 매체라는 용어는 저장 매체 및 통신 매체 양자 모두를 포함한다.

다양한 모듈들 및 기술들이 본 명세서에서는 하나 이상의 컴퓨터 또는 기타 디바이스에 의해 실행되는 프로그램 모듈들 등의 컴퓨터 판독가능 명령어들의 일반적인 콘택스트로 기술될 수 있다. 일반적으로, 프로그램 모듈들은 특정 태스크를 수행하거나 특정 추상 데이터 타입을 구현하기 위해 루틴, 프로그램, 오브젝트, 컴 포넌트, 데이터 구조를 포함한다. 이들 프로그램 모듈들 등은 본래 코드로서 실행되거나, 또는 가상 머신이나 기타 저스트-인-타임 컴파일 실행 환경 등에서 다운로드되어 실행될 수 있다. 통상적으로, 프로그램 모듈들의 기능성은 다양한 환경에서 원하는 바에 따라 조합되거나 분산될 수 있다.

이들 모듈 및 기술의 구현은 특정 형태의 컴퓨터 판독 매체 상에 저장되거나 이를 통해 전송될 수 있다. 컴퓨터 판독 매체는 컴퓨터가 액세스할 수 있는 임의의 가용 매체일 수 있다. 예를 들어, 이에 제한되는 것은 아니지만, 컴퓨터 판독 매체는 "컴퓨터 저장 매체" 및 "통신 매체"를 포함할 수 있다.

도 2는 도 1에 도시된 컴퓨터 디바이스들이 2개 이상 포함될 수 있는 네트워크의 예이다. 네트워크(200)는 풀 매시 회의 아키텍쳐를 사용하는 분산된 아키텍쳐이다. 풀 매시 회의 아키텍쳐를 기술하는 추가적인 정보는 본 명세서에 참조되는 "디지털 오디오 및 비디오에 대한 네트워크 및 운영 체제 지원에 관한 13차 국제 워크샵(13th International Workshop on Networ and Operating Systems Support for Digital Audio and Video)" 2003년도 72-81 페이지에 "신뢰성있는 분산 회의를 위한 프로토콜(A protocol for relaiable decentralized conferencing)"이라는 제목으로 J.Lennox와 H.Schulzrinne가 저술한 논문으로부터 얻을 수 있다. 상기 논문에 기재된 풀 매시 회의 아키텍쳐는 무선 디바이스들 및 56kbps 모뎀들을 갖는 사용자들 등 대역폭이 제한된 엔드 시스템들에 대하여는 적합하지 않다는 것을 상기 논문에서 언급하고 있다는 점에 주목하자. 이와는 대조적으로, 본원 회의 제어 프로토콜은 이러한 제한사항을 극복한다. 또한, 본원 회의 제어 프로토콜은 접속 프로세스 동안 네트워크 코스트를 저감하는 효율적인 프로토콜을 제공하고, 보다 빠른 참가 프로세스를 제공하며, 순간적인 네트워크 에러들에 기인하는 참가 프로세스 동안의 오류 가능성을 감소시킨다.

일반적으로, 풀 매시 회의 아키텍쳐에서, 각 회의 멤버[예를 들어, 회의 멤버(202-210) 등]는 다른 회의 멤버들과의 직접 통신 채널(2 회의 멤버들 사이의 화살표로 표시됨)을 갖는다. 각 회의 멤버(202-210)는 도 1에 도시된 컴퓨팅 디바이스(100) 등의 컴퓨팅 디바이스이다. 회의 멤버(202-210)는 본원 명세서에 기술된 회의 제어 프로토콜을 사용하여 풀 매시 회의 아키텍쳐를 확립하고 유지한다. 이하 상세히 설명되는 바와 같이, 본원 회의 제어 프로토콜은 소규모 시스템들에 적합한 간단한 회의 제어 프로토콜을 제공한다. 종래의 다자간 비디오 회의 시스템들과는 달리, 본원 아키텍쳐는 중앙 서버를 필요로하지 않는다. 따라서, 중앙 서버와 관련하여 상술된 단점들은 본원 아키텍쳐에 적용되지 않는다.

풀 매시 회의 아키텍쳐(200)에서, 각 회의 멤버(202-210)는 동등한 지위를 갖는다. 따라서, 다른 회의 멤버들과 비교하여 특별한 기능성 또는 특권을 갖는 회의 멤버는 없다. 또한, 각 회의 멤버는 어느때나 회의에 신규 사용자를 초대할 수 있는 동등한 능력을 갖는다. 이와 유사하게, 각 회의 멤버는 언때나 회의를 떠날 수 있다. 각 회의 멤버가 임의의 시간에 추가적인 사용자들을 초대하고 회의를 떠나더라도, 풀 매시 회의 아키텍쳐(200)의 안정성은 이하 설명되는 바와 같이 유지된다.

도 3은 본원 명세서에 설명되는 기술들 및 메카니즘을 구현하기 위한, 도 1 에 도시된 컴퓨팅 디바이스(100) 내의 모듈들(130)에 대한 일 실시예를 나타내는 기능 블럭도이다. 당업자려면 이해할 수 있듯이, 일부 실시예에서, 일 모듈의 전체 기능성 또는 일 모듈의 기능성 중 일부가 본 발명의 사상을 벗어나지 않고도 다른 모듈 내에 통합될 수 있다. 다자간 비디오 회의 시스템은 사용자 인터페이스(302), 매체 스트림 엔진(310), 전송 모듈(312), 회의 제어 모듈(304), 메시징 서비스 인터페이스(308), 및 전송 제어 프로토콜(TCP)/사용자 데이터그램 프로토콜(UDP) 인터페이스(306)를 포함한다.

사용자 인터페이스(302)는 매체 스트림 엔진(310) 및 회의 제어 모듈(304)와 통신한다. 매체 스트림 엔진(310)은 전송 모듈(312)과 통신하고, 이는 TCP/UDP 인터페이스(306)와 통신한다. 회의 제어 모듈(304)은 메시징 서비스 인터페이스(308)를 통해 메시징 서비스(도시되지 않음)와 통신한다. 또한, 회의 제어 모듈(304)은 TCP/UDP 인터페이스(306)를 통해 다른 컴퓨팅 디바이스들과 통신한다. 메시징 서비스(308)가 개방형 프로그래밍 인터페이스를 사용할 때, 회의 제어 모듈(304)은 당업자들에게 공지된 표준 프로그래밍 기술들을 사용하여 메시징 서비스와 통신할 수 있다.

사용자 인터페이스(302), 매체 스트림 엔진(310) 및 전송 모듈(312)의 동작은 본원 회의 제어 프로토콜이 동작하는 방식을 변경하지 않고도 여러가지 방식으로 발생할 수 있다. 따라서, 이하에서는 이들 기타 모듈들의 동작의 일 예를 설명하고, 회의 제어 모듈(304)를 보다 상세히 설명한다. 전자에 관하여, 사용자 인터페이스(302)는 회의 중 오디오/비디오 온 및 오프, 회의 참가 및 회의 탈퇴 등의 사용자 요청을 취급한다. 매체 스트림 엔진(310)은 오디오/비디오를 캡쳐하고 오디오/비디오를 재생한다. 매체 스트림 엔진(310)에 의해 캡쳐된 오디오/비디오는 전송 모듈(312)에 의해 TCP/UDP 인터페이스를 통해 다른 회의 멤버들에게 전송된다. 회의 제어 모듈(304)는 신규 사용자들이 메시 회의 아키텍쳐에 참가하고 현재 멤버들이 메시 회의 아키텍쳐를 탈퇴할 때 회의 멤버들간 통신을 취급한다. 본원 명세서는 메시 회의 아키텍쳐 및 회의 제어 프로토콜을 다자간 비디오 회의 시스템에 관하여 설명하지만, 이하 설명되는 본원 메카니즘은 그룹 텍스트 메시징 등의 기타 환경들에서도 구현될 수 있다.

도 4는 본원 회의 제어 프로토콜을 구현하기 위한 메시지 타입들을 나타내는 테이블(400)이고, 이는 도 2에 도시된 메시 회의 네트워크를 확립하고 유지하기 위한 것이다. 상술된 바와 같이, 메시 회의 네트워크의 각 회의 멤버는 네트워크에서의 다른 회의 멤버들 각각에 대한 통신 채널을 갖는다. 테이블(400)은 두 열을 갖는다: 제1 열(402)은 회의 제어 프로토콜에서 사용되는 메시지의 타입들을 나타낸다. 제2 열(404)은 각 타입의 메시지와 관련된 동작들을 설명한다. 도시된 바와 같이, 본원 회의 제어 프로토콜은 매우 간결하고 4개의 메시지 타입: 즉, JOIN 메시지(410), ACCEPT 메시지(412), REJECT 메시지(414) 및 LEAVE 메시지(416)를 사용한다. 본원 회의 제어 프로토콜은 간결한 프로토콜을 구현하기 때문에, 접속 셋업 프로세스 동안의 네트워크 코스트가 저감되고, 멤버들을 참가시키는 프로세스가 보다 빠르며, 참가 프로세스 동안 순간적인 네트워크 에러에 기인하는 오류의 기회가 감소된다.

JOIN 메시지(410)는 제1 컴퓨팅 디바이스로부터 다른 컴퓨팅 디바이스로 보내져 제1 컴퓨팅 디바이스가 다자간 회의를 확립하거나 이에 참가하기 원한다는 것을 나타낸다. ACCEPT 메시지(412)는 JOIN 메시지(410)에 응답하여 다른 컴퓨팅 디바이스로부터 보내어지고, 다른 컴퓨팅 디바이스가 JOIN 메시지(410)를 수용하였다는 것을 나타낸다. REJECT 메시지(414)는 JOIN 메시지(410)에 응답하여 다른 컴퓨팅 디바이스로부터 보내어지고, 다른 컴퓨터 디바이스가 JOIN 메시지(410)를 수용하지 않았다는 것을 나타낸다. 이하 도 5를 참조하여 상세히 설명되는 바와 같이, JOIN 메시지가 수용되지 않는 여러 시나리오가 있다. LEAVE 메시지(416)는 현재 다자간 회의에서의 제1 컴퓨팅 디바이스로부터 다자간 회의의 다른 컴퓨팅 디바이스들로 보내어져 제1 컴퓨팅 디바이스가 다자간 회의로부터 떠난다는 것을 나타낸다.

본원 회의 제어 프로토콜은 다자간 비디오 회의 시스템에 적합한 서비스 품질(QOS)을 제공한다. 이러한 서비스 품질은 참가 및 탈퇴 프로세스 동안 요건들(예를 들어, 점검 사항들)을 부과함으로써 달성된다. 일반적으로, 점검 사항들은 메시 회의 아키텍쳐가 절충되지 않는 방식으로 동시성 이슈가 취급된다는 것을 보장한다. 동시 동작들은 회의가 다른 기존 멤버의 동작들에 의해 불안정한 상태일 때 한 기존 멤버가 수행하는 동작들이다.

도 5는 도 2에 도시된 메시 회의 네트워크에 신규 사용자를 추가하는 참가 프로세스(500) 동안 회의 제어 프로토콜의 동작을 나타내는 흐름도이다. 참가 프로세스(500)는 풀 매시 아키텍쳐를 완전히 유지하기 위해 요구되는 각 접속마다 수 행된다. 초대된 신규 사용자는 요구되는 통신 채널 각각을 구축하는 것을 담당한다. 예를 들어, 현재 3명의 기존 멤버가 존재한다면, 신규 사용자는 기존 3명의 멤버들 각각에 대하여 한 번씩, 참가 프로세스(500)을 3회 수행할 것이다. 점선(501) 위의 동작들은 TCP 접속을 생성하기 위해 요구되는 처리를 나타낸다. 점선(501) 아래의 동작들은 통신 다이얼로그를 생성하기 위해 요구되는 처리를 나타낸다. 그리고, 통신 다이얼로그는 기존 회의 멤버의 오디오/비디오 스트림에 대한 가입 요청 등 회의 제어 메시지들을 보내기 위해 사용된다.

참가 프로세스(500)는 4개의 점검 사항들(502, 504, 506 및 508)을 포함한다. 이하 설명되는 바와 같이, 이들 점검 사항들 중 어느 하나라도 실패하면, 참가 프로세스(500)는 종료할 것이고, 신규 사용자는 회의에 참가할 수 없을 것이다. 도면의 좌측에 있는 라인은 다자간 비디오 회의의 기존 멤버(예를 들어 멤버 M)를 나타낸다. 도면의 우측에 있는 라인은 다자간 비디오 회의의 멤버가 되기를 원하는 신규 사용자(에를 들어, 신규 사용자 N)를 나타낸다. 어느 순간, 신규 사용자 N이 CONNECTION REQUEST 메시지를 보내기 전에, 신규 사용자 N은 다자간 비디오 회의를 알게 된다. 신규 사용자 N은 인터넷 메시징 서비스를 통해 기존 멤버 M으로부터 인터넷 인스턴트 메시지(IM)를 통해 다자간 비디오 회의를 알게될 수 있다. 인터넷 메시징 서비스는 여러 공지된 메시징 서비스들 중 하나일 것이다. 이들 메시징 서비스는 당업계에 공지된 것으로, 본원 회의 제어 프로토콜과의 상호작용을 설명하는 정도를 제외하고는 더 이상 본 명세서에서 논의될 필요는 없다. 인터넷 메시지는 IP 어드레스를 포함하고, 이는 신규 사용자 N가 참가 프로세스(500)에 전 반적으로 사용하는 것이다. 또한, 인스턴트 메시지는 고유 회의 ID를 포함할 수 있다. 일단 신규 사용자 N이 다자간 회의를 알게되고 회의에 참가하도록 초대되면, 회의 제어 프로토콜이 시작된다. 위 예에서, 신규 사용자 N은 인스턴트 메시지 내에 제공되는 링크를 클릭함으로써 회의 참가를 개시할 수 있다.

점검 사항(502)에서, 신규 사용자 N은 도 3에 도시된 다자간 비디오 회의 모듈의 인스턴스가 신규 사용자 N과 관련되는 컴퓨팅 디바이스 상에 미리 로드되었는지 여부를 판정한다. 다자간 비디오 회의 모듈들이 미리 로드되지 않았으면, 이들은 처리가 계속될 수 있도록 이 때에 로드된다. 일단 다자간 비디오 회의 모듈들이 로드되어 실행될 수 있으면, 신규 사용자 N은 아웃-오브-밴드 메카니즘으로부터 수신되는 IP 어드레스에 따라 기존 멤버 M에게 신규 사용자 N을 회의에 초대하였다는 인스턴트 메시지 등의 CONNECTION REQUEST 메시지를 보낸다. 이러한 CONNECTION REQUEST 메시지는 기존 멤버 M과 신규 사용자 N 사이의 TCP 접속 채널의 구축을 개시한다. 처리는 점검 사항(504)으로 진행한다.

점검 사항(504)에서, 기존 멤버 M은 2개의 통신 채널들이 동일한 2개의 컴퓨팅 디바이스들간 구축되는 것을 방지하는 동시성 점검을 수행한다. 2개의 통신 채널이 풀 매시 아키텍쳐에 손상을 주지 않는 반면, 각 통신 채널은 자원들을 사용하고, 이는 궁극적으로 이들이 다른 컴퓨팅 디바이스들에 의해 사용될 수 없게하여 자원을 낭비하게 된다. 따라서, 2개의 통신 채널을 갖는 것은 바람직하지 않다.

본원 회의 제어 프로토콜은 이중 통신 채널들을 방지하기 위해 컴퓨팅 디바이스들 각각에 멤버 리스터[예를 들어, 멤버 리스트(512 및 522)]와 함께, 대기 리 스트[예를 들어, 대기 리스트(510 및 520)]를 구현한다. 대기 리스트(510 및 520)과 멤버 리스트(512 및 522)가 별도의 리스트로서 도시되었지만, 당업자라면 대기 리스트 및 멤버 리스트 양자 모두에 필요한 정보를 포함하는 하나의 리스트를 컴퓨팅 디바이스가 가질 수 있다는 것을 이해할 것이다. 대기 리스트(510 및 520)는 CONNECTION REQUEST 메시지가 보내어질 때 CONNECTION REQUEST 메시지를 보낸 컴퓨터 디바이스 상에 갱신된다.

따라서, 도 5를 참조하면, 신규 사용자 N이 CONNECTION REQUEST를 보낼 때 대기 리스트(520)이 갱신된다. 도시된 바와 같이, 기존 멤버 M은 신규 사용자 N과 관련된 대기 리스트(520)에 열거된다. 멤버 리스트(522)는 컴퓨팅 디바이스가 다자간 비디오 회의 모듈을 로드하여 그 컴퓨팅 디바이스를 멤버로서 반영할 때 갱신된다. 따라서, 최상위 멤버 리스트(522)는 신규 사용자 N을 멤버로서 반영한다. 기존 멤버 M 또한 대기 리스트(510)를 갖는다는 점에 주목하자. 대기 리스트(510)는 기존 멤버 M이 CONNECTION REQUEST를 보낸 컴퓨팅 디바이스들을 열거한다. 도 5에 도시된 흐름도의 예에서, 기존 멤버 M은 신규 사용자 N에게 CONNECTION REQUEST를 보내지 않았고, 따라서 신규 사용자 N은 대기 리스트(510)에 없다. CONNECTION REQUEST가 보내어진 컴퓨팅 디바이스의 고유 ID는 멤버를 식별하기 위해 대기 리스트(520)에 추가된다.

따라서, 점검 사항(504)에서, 기존 멤버 M이 신규 사용자 N으로부터 CONNECTION REQUEST를 수신할 때, 기존 멤버 M은 자신의 대기 리스트[예를 들어, 대기 리스트(510) 등]를 점검한다. 신규 사용자 N이 대기 리스트(510)에 없으면, 기존 멤버 M은 신규 사용자 N에게 CONNECTION ACKNOWLEDGE(ACK) 메시지를 보낸다. 그러나, 신규 사용자 N이 대기 리스트에 이미 있으면, 기존 멤버 M은 대기 리스트에 있는 신규 사용자 N의 ID를 CONNECTION REQUEST 메시지로부터 수신되는 신규 사용자 N의 ID와 비교한다. 이러한 비교에 기초하여, 기존 멤버 M은 신규 사용자 N에게 CONNECTION REJECT 메시지 또는 CONNECTION ACK 메시지 중 하나를 보낼 것이다. 일 실시예에서, 이러한 비교는 신규 사용자 N의 IP 어드레스 비교를 포함한다. 이러한 실시예에서는, 컴퓨팅 디바이스의 IP 어드레스가 대기 리스트에 저장된 로컬 ID보다 클 때 CONNECTION ACK가 보내어진다. 따라서, 점검 사항(504)을 수행하는 것에 의해, 멤버 M과 신규 사용자 N 사이의 리던던트 경로는 확립되지 않는다.

신규 사용자 N이 CONNECTION ACK 메시지를 수신한다면, 이것은 TCP 접속이 이제 확립되었다는 신호를 보내는 것이다. 그런 다음, 신규 사용자 N은 JOIN 메시지를 기존 멤버 M에게 전송한다. 기존 멤버 M은 다른 검증을 실시한다(점검 사항 506 참조). 점검 사항(506)에서, 기존 멤버 M이 실제로 회의를 탈퇴하려는 중인지 여부를 판정하기 위하여 존재 플래그가 검사된다. 도 6과 관련하여 아래에 기술될 바와 같이, 기존 멤버 M이 탈퇴하려고 할때에, 기존 멤버 M은 그러한 소망을 나타내도록 존재 플래그를 설정한다. 따라서, 점검 사항(506)에서, 기존 멤버 M은 자신의 존재 플래그를 검사하여 신규 사용자 N으로부터 수신된 JOIN 메시지를 거부할지 여부을 판정한다. 존재 플래그가 회의를 탈퇴하려는 중임을 나타낸다면, 기존 멤버 M은 JOIN 메시지를 거부할 것이다. 그렇지 않다면, 기존 멤버 M은 점검 사항 (508)으로 진행할 것이다.

점검 사항(508)에서, 기존 멤버 M은 멤버 리스트(512) 및 대기 리스트(510)를 검사하여 회의가 다른 멤버를 추가할 수 있는지 여부를 판정한다. 다자간 비디오 회의 시스템에서 서로간에 통신할 수 있는 멤버의 수는 인터넷의 현재 대역폭 조건하에서 서비스의 질을 저하시키지 않으면서 사용자에게 최대 접속을 제공하도록 선택된다. 일 실시예에서, 이러한 회의 멤버의 한계는 5로 디폴트되어 있다. 다른 실시예에서, 회의 멤버의 최대수는 회의 개시자에 의해서 구성될 수 있다(즉, 사용자는 회의에 대한 제1 CONNECTION REQUEST 메시지를 전송함). 사전결정된 회의 멤버의 수가 이미 채워졌다면, JOIN 메시지는 실패하고 신규 사용자 N은 메시 구조내에 포함될 수 없다. 그러나, 점검 사항(508)을 통과하면, 기존 멤버 M은 ACCEPT 메시지를 신규 사용자 N에게 전송한다. ACCEPT 메시지는 기존 멤버 M의 입장에서 보았을 때에 현재 다자간 회의에 참가하고 있는 모든 회의 멤버들(예컨대, 멤버 A, B, M 및 N)을 식별한다. 이러한 단계에서, 기존 멤버 M은 신규 사용자 N을 멤버로 인식하고 신규 사용자 N을 멤버 리스트(512)에 포함할 것임을 이해할 것이다. 일단 이것이 완료되면, 한 사람이 탈퇴할 때까지는 기존 멤버 M과 신규 사용자 N 사이에 통신 대화가 가능해진다.

신규 사용자 N이 ACCEPT 메시지를 수신하는 때에, 신규 사용자 N은 대기 리스트(520)로부터 멤버 리스트(522)로 기존 멤버 M을 이동시킨다. 그 후에, 신규 사용자 N은 ACCEPT 메시지내에서 식별된 각각의 멤버들(예컨대, 멤버 A,B)에 대한 참가 프로세스(500)를 수행하는 것을 담당하게 된다. 신규 사용자 N이 CONNECTION REQUEST 메시지를 그들에게 전송할 때까지는 멤버 A 및 B는 대기 리스트(522)에 추가되지 않을 것이다.

도 6은 탈퇴 프로세스(leave process,600)동안 도 2에 나타난 메시 회의 네트워크로부터 멤버를 제거하는 회의 제어 프로토콜의 동작을 나타내는 순차 흐름도이다. 탈퇴 프로세스(600)동안, 탈퇴하는 멤버(예컨대, 멤버 A)는 LEAVE 메시지를 회의내의 각각의 다른 기존 멤버(예컨대, 멤버 B)에게 전송한다. 따라서, 탈퇴 프로세스(600)는 각각의 기존 멤버들에 대해서 1회 행해진다. 적어도 하나의 LEAVE 메시지 후에, 바람직하게는 제 1 탈퇴 메시지가 전송된 후에, 탈퇴하는 멤버 A는 회의를 떠나는 중임을 알리도록 자신의 존재 플래그를 갱신한다. 상기된 바와 같이, 참가 프로세스(500)는 점검 사항(506)동안 이러한 존재 플래그를 이용하여 탈퇴 멤버가 재참가하도록 "강제"되지 않을 것을 보증한다.

도 5에서의 참가 프로세스(500)동안의 각각의 점검 사항(502-506)과 도 6의 탈퇴 프로세스(600)이 의미는 몇몇 예시적인 시나리오를 기술함으로써 가장 잘 이해될 것이다.

점검 사항(502)을 참조하면, 점검 사항(502)은 분산된 다자간 프로그램 모듈의 단지 한 인스턴스만이 임의의 하나의 컴퓨팅 디바이스에 로딩될 것을 보증한다. 점검 사항(502)은 사용자가 재참가하기를 결정하기 바로 전에 회의를 탈퇴하는 상황을 다루는 데에 도움이 된다. 이러한 경우에, JOIN 메시지가 LEAVE 메시지보다 먼저 도달하는 것이 가능하다. 점검 사항(502)이 존재하지 않는 경우에 이러한 일이 발생한다면, 다른 멤버들은 먼저 도달한 JOIN 메시지를 무시하고 LEAVE가 도달 하는 때에 접속을 폐쇄할 것이다. 이것은 매우 바람직하지 못한 결과이다. 그러나, 점검 사항(502)을 수행함으로써, 이미 멤버 리스트에 올라와 있는 멤버로부터 JOIN 메시지를 수신한 기존 멤버는 이전의 접속을 폐쇄하고 현재 요청을 수용할 것이다.

점검 사항(504)을 참조하면, 점검 사항(504)은 단지 하나의 통신 채널만이 두 멤버들 사이에 존재할 것을 보증한다. 두 기존 회의 멤버들(예컨대 회의 멤버 A 및 B)가 각기 다른 신규 사용자(예컨대, 신규 사용자 C및 D)를 각각 초대하는 경우에 동일한 컴퓨팅 디바이스 사이에 두 통신 채널이 구축될 가능성이 있다. 메시 회의 네트워크를 실시하는 때에, 회의 멤버 A가 신규 사용자 C를 회의에 초대하는 때에, 회의 멤버 A는 신규 사용자 C에게 멤버 A 및 B가 현재 기존의 멤버임을 알릴 것이다. 이와 유사하게, 회의 멤버 B가 신규 사용자 D를 회의에 초대하는 경우에, 회의 멤버 B는 신규 사용자 D에게, A 및 B가 멤버임을 알릴 것이다. 멤버 C가 참가 프로세스를 멤버 B와 함께 개시하는 때에, 마지막에 멤버 B는 멤버 C에게 A,B 및 D가 멤버임을 알릴 것이다. 이와 유사하게, 멤버 D가 멤버 A와 함께 참가 프로세스를 개시하는 때에, 마지막에 멤버 A는 멤버 D에게 A, B 및 C가 멤버임을 알릴 것이다. 따라서, 멤버 C 및 D는 모두 서로간에 통신 대화를 확립하는 참가 프로세스를 개시할 것이다. 점검 사항(504)은 이들 통신 대화 중 단지 하나만이 확립될 것을 보증할 것이다.

점검 사항(506)을 참조하면, 점검 사항(506)은 전체 매시 회의 구조를 유지하기 위하여 탈퇴하는 멤버가 회의에 재참가하게 강제되지 않도록 보증한다. 예컨 대, 다자간 회의에 3명의 멤버(멤버 A,B 및 C)가 존재한다고 가정하자. 멤버 A는 다자간 회의를 탈퇴하기를 원하여 멤버 B 및 C에게 LEAVE 메시지를 전송한다. 멤버 A가 탈퇴중인동안, 멤버 B는 멤버 D를 다자간 회의에 초대한다. 이러한 상황에서, A는 성공적으로 다자간 회의를 탈퇴하기 전에 멤버 D의 CONNECTION REQUEST를 수신할 수 있을 것이다. 점검 사항(506)이 없는 경우에는, 멤버 A는 D의 CONNECTION REQUEST에 응답하여 회의에 재참가할 것이다. 그러나, 점검 사항(506)에서 탈퇴시에 존재 플래그를 이용함으로써, A는 자신이 탈퇴 중임을 결정하고, 신규 사용자 N에게 REJECT 메시지를 전송한다.

점검 사항(508)을 참조하면, 점검 사항(508)은 임의의 다자간 회의에 대하여 서비스의 질이 유지되도록 보증한다. 사용자의 수를 사전결정된 수로 제한함으로써, 회의 제어 프로토콜은 회의의 규모가 너무 커져서 회의의 질을 저하하는 것을 허용하지는 않을 것이다. 먼저 참가한 멤버들은 나중에 참가한 멤버들에 대하여 우선권을 가진다.

몇몇 상황에서는, 신규 사용자 N이 이미 새로운 멤버로 수용되고, 몇몇 컴퓨팅 디바이스상의 멤버 리스트에 나타날 수 있음에 주의하는 것이 중요하다. 신규 사용자 N이 CONNECTION REJECTION 메시지를 다른 기존 멤버로부터 수신한다면, 참가 프로세스(50)는 실패하고, 신규 사용자 N은 회의에 참가하지 않게 된다. 따라서, 신규 사용자 N은 LEAVE 메시지를 접속이 이미 확립된 모든 기존 회의 멤버들에게 전송하여야 한다.

임의의 회의 제어 프로토콜의 검증은 어렵지만, 현재 다자간 회의 제어 프로 토콜의 검증은 더욱 어려운데, 이는 프로토콜 동작이 이벤트가 발생하는 순서에 상당히 의존하고, 사실상 가능한 순서는 회의의 크기와 동작의 수와는 지수함수적인 관계에 있기 때문이다. 이러한 사실에 기인하여, 현재 다자간 회의 프로토콜의 유효성 검사는 모든 가능한 동시다발적인 시나리오에서의 프로토콜의 동작의 유효성을 검사함으로써 수행된다. 상기 언급된 바와 같이, 메시 회의 구조의 안정성은 항상, 멤버들이 동시에 참가하고 탈퇴하는 경우라도 보호되어야 한다. 동시다발적인 참가 및 탈퇴은 두명의 다른 멤버들 사이, 혹은 동일한 멤버에게 발생할 수 있을 것이다.

따라서, 네 타입의 이벤트가 정의되고 유효성이 검사된다. 아래의 표에 나타난 4개의 이벤트는 JOIN(J), LEAVE(L), BRIEF JOIN(BJ) 및 BRIEF LEAVE(BL)를 포함한다. JOIN 및 LEAVE는 위에서 설명되었다. BRIEF JOIN은 멤버가 참가한뒤 바로 탈퇴하는 경우를 일컫는다. BRIEF LEAVE는 멤버가 탈퇴한뒤 바로 재참가하는 경우를 일컫는다. 이들 네 이벤트에 근거하여, 현재 회의 프로토콜이 검사되었다. 테스트의 결과는 표 1에 나타나 있다.

표 1에 나타난 바와 같이, 15가지의 시나리오가 테스트되었다. 각 행은 테스트 시나리오 중 하나를 나타낸다. 초기 상태는 회의의 기존 멤버들을 식별한다. 동작 열은 동시에 발생한 동작 JOIN(J), LEAVE(L), BRIEF JOIN(BJ) 및 BRIEF LEAVE(BL)을 식별한다. 예컨대, 테스트 1에서 E와 F가 모두 JOIN 메시지를 전송하였다. 최종 상태 열은 초래될 최종 상태를 식별한다. 전형적으로, 수용될 수 있는 최종 상태는 단지 하나만이 존재한다. 그러나, 테스트 1에서는 현재 회의 프로토콜이 멤버의 수를 5로 제한하기 때문에, 두 명의 참가자 중 한 명만이 참석하도록 허용되거나, 아무도 참가하는 것이 허용되지 않는다. 표 1의 정보는 그 자체로 자명하기 때문에, 표 1의 분석이 더 이상 행해지지는 않는다. 현재 회의 프로토콜이 각각의 15개의 테스트를 통과하였고, 모든 회의 멤버들이 다른 멤버들 각각에 대하여 정확하게 하나의 단일의 활성 통신 채널로 안정화되었음에 주의하는 것이 중요하다. 현재의 다자간 비디오 회의 시스템은 보안 보호 또한 제공한다. 일 실시예에서, 보안 보호는 특유의 128 비트의 회의 ID를 각각의 회의에 할당하는 것을 포함한다. 128 비트 회의 ID는 GUID(Global Unique Identifier)와 유사하다. 회의 ID는 신규 사용자를 회의에 참석하도록 초대하는 회의 개시자에 의해서 생성된다. 동일한 회의에의 각각의 초대은 인스턴트 메시지내에 동일한 회의 ID를 가질 것이다. 그 후에, 회의를 식별하고 신규 사용자가 식별된 회의에 적절하게 초대되었음을 보증하기 위하여, 회의 ID는 JOIN 메시지와 함께 전송된다.

따라서, 상기된 바와 같이, 다자간 회의 시스템을 위한 현재 회의 제어 프로토콜은 전체 메시 회의 구조로 구성된 네트워킹된 컴퓨터들을 이용하여 작동한다. 따라서, 하나 이상의 집중형 서버를 가지는 것에 관련된 비용 및 단점들이 회피된다. 현재 회의 제어 프로토콜은 비용면에서 더 저렴한 다자간 비디오 회의에 대하여 신뢰할 수 있는 유연한 대안을 제공한다.

본 명세서 전반에 걸쳐서 "일 실시예" 또는 "예시적인 실시예" 라는 용어가 언급되었는데, 이는 특정한 특징, 구조 또는 특성이 본 발명의 적어도 하나의 실시예에 포함되었음을 의미한다. 따라서, 이러한 용어의 사용은 단지 하나의 실시예 이상을 일컫는 것일 수 있을 것이다. 더우기, 상기된 특징들, 구조들 또는 특성들은 하나 이상의 실시예에서 임의의 적절한 방식으로 결합될 수 있을 것이다.

그러나, 본 발명의 관련 기술 분야의 당업자는 하나 이상의 특정 세부 사항들 없이, 또는 다른 방법, 자원 재료 등으로 본 발명이 실시될 수 있음을 인식할 수 있을 것이다. 다른 경우에서, 단지 본 발명의 특징을 불명확하게 하는 것을 피하기 위하여, 공지된 구조들, 자원들 또는 동작들은 상세히 설명되지 않았다.

본 발명의 예시적인 실시예와 응용들이 기술되었지만, 본 발명이 상술한 구성 및 자원과 정확하게 일치하는 것에 한정되지는 않음을 이해하여야 할 것이다. 본 발명의 기술 분야의 당업자에 의해서 특허청구범위의 범위에서 벗어나지 않고서 본 명세서에 기술된 본 발명의 방법 및 시스템의 디바이스, 동작 및 세부사항에서 다양한 변경, 변화 및 변형이 이루어질 수 있을 것이다.

본 발명의 다자간 회의 시스템을 위한 현재 회의 제어 프로토콜은 전체 메시 회의 구조로 구성된 네트워킹된 컴퓨터들을 이용하여 작동한다. 따라서, 하나 이상의 집중형 서버를 가지는 것에 관련된 비용 및 단점들이 회피된다. 현재 회의 제어 프로토콜은 비용면에서 더 저렴한 다자간 비디오 회의에 대하여 신뢰할 수 있는 유연한 대안을 제공한다.

Claims (29)

1. 풀 매시 아키텍쳐(full mesh architecture)를 지원하는 분산된 다자간 회의(a decentralized multi-party conference)에서 회의 멤버들 사이에 통신 경로를 제어하는 방법으로서,

   제 1 시스템 내에서, 제 2 시스템으로부터 전송되는 접속 요청 메시지(a connection request message)를 수신하는 단계;

   상기 접속 요청 메시지에 응답하여, 상기 제 1 및 제 2 시스템 사이에 대기중인 통신 경로(a pending communication path)가 존재하는지 여부를 판정하는 단계;

   상기 제 1 및 제 2 시스템 사이에 대기중인 통신 경로가 존재하지 않는 경우 상기 제 1 및 제 2 시스템 사이에 접속 경로를 형성하기 위하여 접속 승인(a conncetion acknowledgement)을 상기 제 2 시스템에 전송하는 단계;

   상기 제 2 시스템으로부터 참가 메시지(a join message)를 상기 제 1 시스템에서 수신하는 단계;

   상기 참가 메시지에 응답하여 상기 제 1 시스템의 플래그를 읽음으로써, 상기 제 1 및 제 2 시스템 사이의 상기 접속 경로를 구축한 이후 상기 제 1 시스템이 상기 다자간 회의를 탈퇴하는 프로세스 중인지 여부를 판정하는 단계;

   상기 제 1 시스템이 상기 다자간 회의를 탈퇴하는 프로세스 중이 아니라는 판정에 응답하여, 상기 제 1 및 제 2 시스템 사이에 비디오 통신 채널을 형성하기 위하여 수용 메시지(an accept message)를 - 상기 수용 메시지는 현재 상기 다자간 회의에 있는 다른 회의 참가자를 식별하는 맴버 정보를 포함함 - 상기 제 1 시스템에서 상기 제 2 시스템으로 전송하는 단계; 및

   상기 제 1 시스템이 상기 다자간 회의를 탈퇴하는 프로세스 중이라는 판정에 응답하여 상기 제 1 시스템으로부터 상기 제 2 시스템으로 거부 메시지(a reject message)를 자동적으로 전송하는 단계

   를 포함하는, 방법.
2. 삭제
3. 제 1 항에 있어서,

   상기 멤버 정보는 상기 제 2 시스템을 상기 회의 멤버들 중 하나로서 포함하는, 방법.
4. 제 1 항에 있어서,

   상기 제 1 시스템은 상기 제 1 시스템상의 대기 리스트 - 상기 대기 리스트는 상기 제 1 시스템이 이미 이전의 접속 요청 메시지를 전송한 각각의 시스템에 대한 식별자(an identifier)를 저장함 - 를 점검함으로써 상기 제 1 및 제 2 시스템 사이에 대기중인 통신 경로가 존재하는지 여부를 판정하는, 방법.
5. 제 1 항에 있어서,

   상기 제 1 시스템은 상기 제 1 시스템상의 존재 플래그 - 상기 존재 플래그는 탈퇴 메시지가 상기 제 1 시스템으로부터 전송되는 경우에 갱신됨 - 를 점검함으로써 탈퇴 프로세스 중이 아님을 판정하는, 방법.
6. 제 1 항에 있어서,

   상기 수용 메시지의 전송은 상기 회의가 아직 회의 멤버의 최대수를 가지지 않음에 대한 판정에 또한 근거하는, 방법.
7. 제 6 항에 있어서,

   상기 회의 멤버의 최대수는 회의 개시자에 의해서 구성가능한, 방법.
8. 제 6 항에 있어서,

   상기 회의 멤버의 최대수는 현재 인터넷 대역폭 조건에 근거하는, 방법.
9. 제 6 항에 있어서,

   상기 회의가 아직 회의 멤버의 최대수를 가지지 않음에 대한 판정은 멤버 리스트 및 대기 리스트 모두에 리스팅된 멤버 수를 상기 회의 멤버의 최대수와 비교하는 것을 포함하는, 방법.
10. 제 6 항에 있어서,

    상기 회의 멤버의 최대수는 디폴트 값인, 방법.
11. 제 1 항에 있어서,

    상기 회의의 멤버가 되고, 상기 접속 요청 메시지를 전송함으로써 참가 프로세스를 개시하도록 상기 제 2 시스템을 초대하는 인터넷 인스턴트 메시지를 상기 제 2 시스템에 전송하는 단계를 더 포함하는, 방법.
12. 제 11 항에 있어서,

    상기 인터넷 인스턴트 메시지는 회의 식별자를 포함하는, 방법.
13. 제 12 항에 있어서,

    상기 접속 요청 메시지와 상기 참가 메시지는 상기 회의 식별자를 포함하는, 방법.
14. 제 1 항 및 제 3 항 내지 제 13 항 중 어느 한 항의 방법을 수행하는 컴퓨터 실행가능 명령들을 포함하는, 컴퓨터 판독가능 기록 매체.
15. 풀 매시 아키텍쳐를 지원하는 분산된 다자간 회의에서 회의 멤버들 사이의 통신 경로를 제어하는 방법으로서,

    제 1 시스템으로부터, 다자간 회의의 기존 멤버인 제 2 시스템에 접속 요청 메시지를 전송하는 단계;

    상기 제 2 시스템으로부터 접속 승인을 수신하는 단계;

    상기 제 2 시스템으로부터 수신된 상기 접속 승인에 응답하여 상기 제 2 시스템과의 통신 경로가 대기중임을 나타내기 위하여 상기 제 2 시스템과 관련된 식별자를 이용하여 상기 제 1 시스템상의 대기 리스트 - 상기 대기 리스트는 상기 제 1 및 제 2 시스템 사이에 중복되는 채널이 확립되는 것을 방지하는데 이용됨 - 를 갱신하는 단계;

    상기 제 1 및 제 2 시스템 사이에 비디오 통신 채널의 구축을 개시하기 위하여 상기 제 1 시스템으로부터 상기 제 2 시스템으로 참가 메시지를 전송하는 단계;

    상기 제 1 및 제 2 시스템 사이에 상기 비디오 통신 채널이 구축되었음을 나타내는 수용 메시지 - 상기 수용 메시지는 회의 참가자의 최대 인원수 및 상기 다자간 회의에 대한 제 3 의 회의 참가자를 식별하는 정보를 포함함 - 를 상기 제 2 시스템으로부터 수신하는 단계;

    상기 제 2 시스템과의 통신 경로가 더 이상 대기중이 아님을 나타내고, 상기 회의 참가자의 최대 인원수를 나타내고, 또한 상기 제 3 의 회의 참가자의 신원을 나타내도록, 상기 수신된 수용 메시지에 포함된 정보에 기초하여 상기 제 1 시스템상의 상기 대기 리스트를 갱신하는 단계;

    상기 제 1 시스템으로부터 상기 대기 리스트의 식별된 제 3 시스템 - 상기 제 3 시스템은 상기 다자간 회의의 기존 맴버(an existing member)임 - 에 접속 요청 메시지를 전송하는 단계;

    상기 제 3 시스템으로부터 접속 승인을 수신하는 단계;

    상기 제 3 시스템으로부터 수신한 상기 접속 승인에 응답하여, 상기 제 3 시스템과의 접속 경로가 대기중임을 나타내도록 상기 제 3 시스템과 연관된 식별자로 상기 제1 시스템의 상기 대기 리스트를 갱신하는 단계;

    상기 제 1 및 제 3 시스템 사이에 비디오 통신 채널을 구축하기 위하여 참가 메시지를 상기 제 1 시스템으로부터 상기 제 3 시스템으로 전송하는 단계;

    상기 제 1 및 제 3 시스템 사이의 상기 비디오 통신 채널이 구축되지 않음을 나타내는 거절 메시지를 상기 제 3 시스템으로부터 수신하는 단계; 및

    상기 제1 시스템의 상기 거절 메시지의 수신에 응답하여, 상기 제 1 및 제 2 시스템 사이의 상기 통신 경로를 제거하기 위하여 상기 제 1 시스템으로부터 상기 제 2 시스템으로 탈퇴 메시지(a leave message)를 전송하는 단계

    를 포함하는, 방법.
16. 제 15 항에 있어서,

    상기 수용 메시지는 현재 상기 다자간 회의에 참가하고 있는 회의 멤버들을 식별하는 멤버 리스트를 포함하는, 방법.
17. 제 16 항에 있어서,

    상기 제 1 시스템은 각각의 회의 멤버들에게 별도의 접속 요청 메시지를 전송함으로써 상기 멤버 리스트내의 식별된 상기 각각의 회의 멤버들과의 참가 프로세스를 개시함으로써, 상기 분산된 다자간 회의의 풀 매시 아키텍쳐를 유지하는, 방법.
18. 제 15 항에 있어서,

    상기 회의의 멤버가 되고, 상기 접속 요청 메시지를 전송함으로써 참가 프로세스를 개시하도록 상기 제 1 시스템을 초대하는 인터넷 인스턴트 메시지를 상기 제 2 시스템으로부터 수신하는 단계를 더 포함하는, 방법.
19. 제 18 항에 있어서,

    상기 인터넷 인스턴트 메시지는 회의 식별자를 포함하는, 방법.
20. 제 19 항에 있어서,

    상기 접속 요청 메시지 및 상기 참가 메시지는 상기 회의 식별자를 포함하는, 방법.
21. 제 15 항 내지 제 20 항 중 어느 한 항에 따르는 방법을 수행하는 컴퓨터 실행가능 명령들을 포함하는, 컴퓨터 판독가능 기록 매체.
22. 프로세서; 및

    프로그램 모듈들을 저장하도록 구성된 메모리 - 하나 이상의 프로그램 모듈은 상기 메모리에 로딩됨 -

    를 포함하고,

    상기 프로그램 모듈들은 매시 아키텍처를 이용하여 분산된 다자간 회의에 대한 제어를 담당하고, 회의 제어 모듈을 포함하며,

    상기 회의 제어 모듈이 실행되는 경우, 상기 프로세서는 회의 제어 프로토콜을 지원하도록 구성되고, 상기 회의 제어 프로토콜은

    다자간 회의에의 참가에 대한 허락을 구하는, 제 1 시스템으로부터 제 2 시스템으로의 접속 요청 메시지;

    상기 제 1 시스템과 상기 제2 시스템 사이에 존재하는 대기중인 통신 경로가 없는 경우에 상기 접속 요청 메시지를 승인하는, 상기 제 2 시스템으로부터 상기 제1 시스템으로의 접속 승인 메시지;

    상기 두 시스템 사이의 통신 경로를 개시하는, 상기 제1 시스템으로부터 상기 제 2 시스템으로의 참가 메시지;

    상기 제 2 시스템이 상기 다자간 회의를 탈퇴하는 프로세스 중이 아닌 경우에 상기 두 시스템 사이의 통신 경로를 완결(finalizing)하는, 상기 제 2 시스템으로부터 상기 제 1 시스템으로의 참가 수용 메시지 - 상기 참가 수용 메시지는 상기 다자간 회의 내 다른 시스템에 대한 하나 이상의 주소를 포함하고, 상기 하나 이상의 주소는 상기 제 1 시스템과 상기 다자간 회의 내 다른 시스템과의 통신 경로를 구축하는데 사용됨 -; 및

    상기 다자간 회의로부터 상기 제 1 시스템을 제외하기 위하여 상기 제 1 시스템으로부터 상기 제 2 시스템 및 다른 시스템으로의 탈퇴 메시지

    를 포함하는, 시스템.
23. 제 22 항에 있어서,

    상기 회의 제어 모듈이 실행되는 경우, 상기 프로세서는

    대기 리스트 - 상기 대기 리스트는 상기 회의의 기존 멤버인 시스템에 상기 접속 승인 메시지가 전송되는 때에 상기 기존 시스템에 대한 식별자를 상기 대기 리스트에 추가함으로써 갱신됨 - 의 유지를 지원하도록 더 구성되는, 시스템.
24. 제 23 항에 있어서,

    상기 대기 리스트에 대한 갱신은 접속 승인 메시지와 접속 거부 메시지에 근거하여 발생하는, 시스템.
25. 제 22 항에 있어서,

    상기 회의 제어 모듈이 실행되는 경우, 상기 프로세서는

    멤버 리스트 - 상기 멤버 리스트는 상기 다자간 회의의 각각의 회의 멤버를 열거하고, 탈퇴 메시지를 수신하거나 상기 통신 경로를 완결하는 상기 참가 수용 메시지를 수신하는 때에 갱신됨 - 의 유지를 지원하도록 더 구성되는, 시스템.
26. 제 22 항에 있어서,

    상기 회의 제어 모듈이 실행되는 경우, 상기 프로세서는

    시스템이 상기 다자간 회의를 탈퇴하는 프로세스 중인지 여부를 나타내는 존재 플래그 - 상기 존재 플래그는 상기 탈퇴 메시지와 관련하여 갱신됨 - 의 유지를 지원하도록 더 구성되는, 시스템.
27. 제 22 항에 있어서,

    상기 프로그램 모듈들은 사용자 인터페이스를 포함하며, 상기 사용자 인터페이스가 실행되는 경우, 상기 프로세서는 상기 다자간 회의에의 참가 또는 탈퇴에 대한 사용자 요청을 조정하도록 더 구성되는, 시스템.
28. 제 22 항에 있어서,

    상기 프로그램 모듈들은 메시징 서비스 인터페이스를 포함하고, 상기 메시징 서비스 인터페이스가 실행되는 경우, 상기 프로세서는 상기 회의 제어 모듈이 메시징 서비스와 통신할 수 있도록 더 구성되는, 시스템.
29. 제 28 항에 있어서,

    상기 프로그램 모듈들은 사용자 인터페이스를 포함하고, 상기 사용자 인터페이스가 실행되는 경우, 상기 프로세서는 상기 메시징 서비스로부터 인스턴트 메시지 - 상기 인스턴트 메시지는 상기 회의 제어 프로토콜을 개시하도록 시스템을 초대함 - 를 수신하도록 더 구성되는, 시스템.

Images