KR100950872B1

KR100950872B1 - Ｖｏｉｐ 네트워크에서의 미디어 서버 리소스들의 관리

Info

Publication number: KR100950872B1
Application number: KR1020077023655A
Authority: KR
Inventors: 바바라 레스리 배너; 토마스 제이. 디에트리취; 자이 도빈; 크리스토퍼 헤펠; 제임스 에이. 이베짐; 게리 에이. 먼슨; 제임스 윌리엄 머피; 도미닉 엠. 리치아르드; 로버트 쥬니어 스토키
Original assignee: 에이티 앤드 티 코포레이션
Priority date: 2005-04-22
Filing date: 2006-04-17
Publication date: 2010-04-06
Also published as: WO2006115976A1; EP1872560A1; JP2008537413A; KR20070112475A; CA2599407A1; JP4823306B2

Abstract

미디어 서버 리소스들을 관리하는 방법이 개시되어 있다. 일 실시예에서 미디어 서버 리소스 브로커(140)는 애플리케이션 서버(120)로부터 미디어 서버 리소스들의 세트에 대한 요청을 수신한다. 미디어 서버 리소스 브로커는 제 1 미디어 서버의 이용 가능성 및 요청의 유형에 기초하여, 제 1 미디어 서버(160)에 의해 처리되어야 하는 서비스 요청을 결정하고, 제 1 미디어 서버의 어드레스를 애플리케이션 서버에 제공한다. 다른 실시예에서, IP 노드(210)가 서비스 요청을 제공한다. 애플리케이션 서버(120)는 서비스 요청을 수신하여 미디어 서버 리소스 브로커(140)로 미디어 서버 리소스들에 대한 요청을 보낸다. 미디어 서버 리소스 브로커는 요청이 제 1 미디어 서버(160)에 의해 처리되어야 하는 것을 결정한다. 미디어 서버 리소스 브로커는 IP 노드와 제 1 미디어 서버 사이에 콜을 확립하는데 이용하기 위한 포트 수 및 IP 어드레스를 얻기 위해 제 1 미디어 서버로 질의한다. 미디어 서버 리소스 브로커는 이후 그것이 미디어 서버의 적절한 포트와 콜을 확립할 수 있도록 IP 노드에 신호를 제공한다.

VOIP, 미디어 서버, 양방향 음성 응답, 전화 회의, 콜 레그

Description

ＶＯＩＰ 네트워크에서의 미디어 서버 리소스들의 관리{MANAGING MEDIA SERVER RESOURCES IN A VOIP NETWORK}

본 국제 출원은 2005년 4월 22일 출원된 임시 출원 번호 제60/674,244의 이익과, 2005년 12월 29일 출원된 미국 특허 출원 번호 제11/321,760과 2005년 12월 29일 출원된 미국 특허 출원 번호 제11/321,734의 우선권을 주장한다.

본 발명은 VoIP에 사용하기 위해 구성된 네트워크에서 미디어 서버 리소스들을 관리하는 분야에 관한 것이다.

VoIP의 사용은 주지되어 있다. 기본적으로, VoIP는 (아날로그인) 사람의 들을 수 있는 대화를 (디지털인)데이터 패킷들로 인코딩하고 디지털 패킷들이 인터넷 프로토콜(IP) 네트워크상에서 전송될 수 있도록, 예컨대, 이에 한정되는 것은 아니지만 mu-law 방식의 G.711와 같은 코덱의 사용을 필요로 한다. 주지된 바와 같이, IP 네트워크들은 음성뿐만 아니라, 예컨대 데이터 서비스들(파일 전송, 이메일, 인스턴트 메시징 등)에 추가하여 팩스 또는 비디오와 같은 다른 종류의 트래픽을 전송할 수도 있다. 그러한 융합된 또는 통합된 네트워크들은 경제적이며, 네트워크 제공자들 및 이용자들에게 동작상의 이점들을 제공한다.

VoIP 서비스들은 네트워크 내의 장비들, 일반적으로 미디어 서버들과의 미디 어-기반 발신자 상호작용(caller interaction)들을 필요로 한다. 그러한 상호작용들은 예컨대, 이에 한정되는 것은 아니지만, 이중 톤 다중-주파수(dual tone multi-frequency; DTMF) 또는 스피치 프롬프트-콜렉트 루틴들(speech prompt-and-collect routines)(예컨대, 무료 전화 서비스들 또는 음성메일 검색에 이용될 수 있다)을 위해, 고지(announcement)들을 듣기 위해, 또는 오디오 전화 회의(conference call)들에 참여하기 위한 것일 수 있다. 그러한 개념은 VoIP 이외의 서비스들, 더욱 일반적으로는 예컨대, 이에 한정되는 것은 아니지만 팩스 저장 및 전달 또는 비디오 회의를 포함할 수 있는 IP상의 서비스들(SoIP)로 알려진 서비스들에 까지 일반화되어 있다.

미디어 서버가 특정 서비스를 제공하는 방법의 로직 구동(logic driving)은 애플리케이션 서버에 의해 제공될 수 있다. 미디어 서버들과 함께 애플리케이션 서버들을 사용하기 위한 기본 아키텍쳐는 주지되어 있다. 그러나, 많은 수의 미디어 서버들과 함께 사용되는 애플리케이션 서버들은 많이 존재할 수 있다. 따라서, 다양한 애플리케이션 서버들에 관해 미디어 서버들의 이용을 관리하는데 무언가가 필요하다.

본 발명의 양상들은 VoIP 콜들(calls), 보다 일반적으로는 SoIP에 할당된 미디어 서버 리소스들을 관리하기 위한 방법에 관한 것이다. 일 실시예에서, 애플리케이션 서버는 VoIP 폰 또는 그 밖의 고객 장비와 같은 IP 노드로부터 발생하는 서비스 요청을 수신한다. 이에 응답하여, 애플리케이션 서버는 요청된 서비스를 제공하기 위해 미디어 서버 리소스들을 요청한다. 미디어 서버 리소스 요청은 미디어 서버 리소스 브로커에 전달될 것이다. 미디어 서버 리소스 브로커는 요청된 서비스를 제공하기에 적절한 미디어 서버를 결정하고, 애플리케이션 서버로 이 정보를 제공한다. 애플리케이션 서버는 이후 미디어 서버와 IP 노드가 접속되도록 할 수 있고, 애플리케이션 서버는 미디어 서버가 필요에 따라 IP 노드와 상호작용하도록 해주는 로직을 제공한다.

또 다른 실시예에서, 애플리케이션 서버는 VoIP 폰 또는 그 밖의 고객 장비와 같은 IP 노드로부터 발생하는 서비스 요청을 수신한다. 이에 응답하여, 애플리케이션 서버는 요청된 서비스를 제공하도록 미디어 서버 리소스들을 요청한다. 미디어 서버 리소스 요청은 미디어 서버 리소스 브로커에 전달될 것이다. 미디어 서버 리소스 브로커는 요청된 서비스를 제공하기 위해 적절한 미디어 서버를 결정하고, IP 어드레스를 결정하기 위해 미디어 서버에 질의한다. 미디어 서버 리소스 브로커는 이후 미디어 서버가 IP 노드에 접속되도록 할 수 있다. 애플리케이션 서버는 이후 미디어 서버가 IP 노드로 콜을 관리할 수 있도록 해주는 로직을 제공할 수 있다.

본 발명은 수반되는 도면들에서 예시적으로 설명되지만 이에 한정되는 것은 아니며, 동일한 참조번호들은 동일한 소자를 가리킨다.

도 1은 본 발명의 일 양상에 따른 VOIP를 분배하는데 이용하기 위한 시스템의 일 실시예를 개략적으로 도시한 도면.

도 2는 본 발명의 일 양상에 따른 간접적 방법을 이용하여 VOIP를 분배하는데 이용하기 위한 시스템의 일 실시예를 개략적으로 도시한 도면.

도 3은 본 발명의 일 양상에 따른 도 2에 도시된 시스템을 이용한 방법의 일 실시예를 도시한 도면.

도 4는 본 발명의 일 양상에 따른 중계(relay)방법을 이용하여 VOIP를 분배하는데 이용하기 위한 시스템의 일 실시예를 개략적으로 도시한 도면.

도 5는 본 발명의 일 양상에 따른 도 4에 도시한 시스템을 이용하는 방법의 일 실시예를 도시한 도면.

도 6은 본 발명의 일 양상에 따른 간적접인 방법의 일 실시예를 도시한 도면.

도 7은 본 발명의 일 양상에 따른 중계 방법의 일 실시예를 도시한 도면.

도 8은 본 발명의 일 양상에 따른 분배된 미디어 서버들의 세트의 개략적인 실시예를 도시한 도면.

전술한 바와 같이, VoIP를 제공하기 위한 아키텍쳐는 주지되어 있으며, 일례가 2003년 12월 22일자, 제목 "Common VoIP Architecture", AT&T 관점(Point Of View)/VoIP인 백서에 개시되어 있으며, 이 백서는 여기에서 전체로서 참조되어 통합된다. 그러나, 공유의 이점들이 동기가 된, 미디어 서버(MS)의 공유된 풀(shared pool)로 동작하는 다양한 서비스들을 지원하는 다수의 애플리케이션 서버들(AS)이 존재한다.

MS들의 공유 풀의 사용은 VoIP를 제공하는데 사용되는 리소스들의 사용을 더욱 효과적으로 만들 수 있다. 예를 들어, MS 리소스들이 지역적 레벨로 관리된다면 더욱 효율적이다. 관리되는 MS들의 수가 증가될수록, 그리고 MS들의 위치들이 더욱 분산될수록, 얻어질 수 있는 추가적인 효율은 더욱 현저해진다.

도 1로 돌아가서, 시스템의 높은 레벨의 개략도가 도시되어 있다. 시스템에 도시된 소자들 각각은 함께 링크된 하나 이상의 물리적 또는 논리적 소자들을 포함하는 모듈일 수 있다. AS(120)는 콜 제어 소자(call control element; CCE)(130)와 접속되어 있는 것으로 도시되어 있다. 일반적으로, AS는 예컨대, 음성메일과 같은 전화 시스템의 이용자들에게 서비스들을 제공할 수 있으며, 이들 서비스들은 예컨대, 경량 디렉토리 액세스 프로토콜(lightweight directory access protocol; LDAP) 룩업과 같은 네트워크 리소스들을 포함할 수 있다. AS는 또한 배후에서 복수의 당사자들을 멀티캐스트 회의로 접속하는 로직을 처리할 수 있고, 들을 수 있는 프롬프트들의 제공 및 이들 프롬프트들에 응답들의 수집을 통하여 이용자들과 상호작용하기 위한 스크립트를 제공할 수 있다. 따라서, AS는 원하는 서비스들을 발신자에게 제공하기 위해 필요한 로직을 제공할 수 있으며, 다른 디바이스들과 통신하는데 있어서 특정 프로토콜의 이용이 제한되지는 않는다. 일반적으로, AS는 특정 기능성을 위해 프로그램될 것이다. 따라서, 일 실시예에서, AS는 하나 이상의 레코딩된 메시지들을 재생하기 위한 명령들을 제공함으로써 콜을 콜센터로 처리하고, 이용자 입력들에 구조화된 응답들을 제공하며, 양방향 음성 응답(interactive voice response; IVR) 인터페이스들에 공통적인 수신된 디지트들(digits)을 처리하는데 필요한 로직을 제공하도록 프로그램될 수 있다.

일반적으로, AS(120)는 그 자체로 엔드-유저와의 미디어 상호작용을 수행하지 않으며, 대신 MS(160)에게 명령들을 제공할 것이다. 일 실시예에서, MS(160)는 음성 인식(speech recognition) 엔진, 컨퍼런싱 브리지(conferencing bridge), 텍스트-투-스피치(Text-To-Speech; TTS) 엔진을 포함할 수 있고, 또는 레코딩된 메시지들을 재생할 수 있고 발신자에 의해 입력된 디지트들을 수집하여, 개인은 AS(120)에 의해 제공된 로직과 상호작용할 수 있다.

AS(120)는 잠재적으로 착신 콜(incoming call)로부터 수신된 신호들과 상호작용할 수 있으며, 이는 직접 세션 개시 프로토콜(Session Initiation Protocol; SIP)을 이용하여 제공될 수 있다. 그러나, 그것은 AS(120)에 대한 프록시로서 동작하도록 콜 제어 소자(CCE)를 사용하는 것이 바람직할 수 있다. 따라서, 착신 콜들은 AS에서의 서비스 로직의 지시하에, CCE에 의해 라우팅될 수 있고, 원하는 바에 따라 CCE에 의해 콜 레그(call leg)들이 추가, 수정 또는 제거될 수 있다. 따라서, 도 1에 도시된 바와 같이, CCE(130)는 AS(120)가 콜들이 네트워크에 액세스 또는 나가는 방법의 상세들을 무시하도록 허용하여, AS(120)는 대신에 콜들이 처리되는 방법의 로직에 집중할 수 있게 된다.

AS(120)는 직접 착신 콜들을 처리하지 않도록 구성될 수 있는 반면, 착신 콜들로부터의 일정 양의 정보는 원하는 서비스를 제공하는데 도움이 될 수 있다. 따라서, AS(120)는 CCE(130)와 통신하도록 구성될 수 있다. AS와 CCE(130) 간의 통신 방법의 하나로 SIP가 사용된다. 추가적으로, AS(120)는 발신자와의 미디어 상호작용에 관해 무엇을 해야 할지를 지시하기 위해 MS(160)와 통신하도록 구성될 수 있다. 그러한 통신은 예컨대, 이에 한정되지는 않지만, 미디어 세션 마크업 언어(Media Sessions Markup Language; MSML), 미디어 오브젝트 마크업 언어(Media Objects Markup Language; MOML) 또는 음성 확장성 마크업 언어(Voice eXtensible Markup Language; VXML)를 필요로 할 수 있다.

AS(120), CCE(130) 및 MS(160)는 명령들 및 프로세싱 콜들의 상세들을 처리한다. 그러나, 도 8에 도시된 바와 같이, AS(120a)는 MS 모듈들(161-166)과 상호작용할 수 있으며, 여기서 각 MS 모듈은 상이한 지역에 위치한다. 여기서 사용된 바와 같이, 각 MS 모듈은 하나 이상의 물리적 서버들로 구성될 수 있고, 지역은 물리적인 위치, 도시, 시, 주 또는 나라로 구성될 수 있다. 따라서, 지역 레벨에서의 관리는 둘 이상의 지역들을 관리할 것이다. 상이한 지역들에서 MS들의 제공은, 가까이 위치한 또는 광활한 거리들에 이를 필요 없이 그러한 지역들에 위치한 개인들에게 서비스들을 제공할 수 있는 이점을 갖고 있음을 주의해야 한다. 그러나, 특정 지역에서 일어나는 일을 단순히 아는 것이 모든 지역들에서 전체적으로 이용 가능한 MS 리소스들이 효율적으로 이용되는지를 보증할 수는 없기 때문에, 다양한 MS들의 효율적인 이용은 더욱 복잡해진다.

예컨대, AS(120b)와 같은 추가적인 AS들은 또한 MS(161-166)를 이용할 수 있다(도 8에서는 명확성을 위해 AS(120b)와 MS들 간의 접속들을 도시하지 않았음). 그러나, AS(120a) 및 AS(120b)는 독립적으로 동작할 수 있으며, 상이한 서비스들을 지원할 수 있고, 상이한 서비스 제공자들에 의해 제공될 수도 있으며, AS(120a), AS(120b) 또는 MS(161) 어느 것도 다른 MS들에 관한 MS(161)상의 로드(load)를 안다고는 기대할 수 없다.

따라서, 리소스 이용을 향상시키도록, 미디어 서버 리소스 브로커(media server resource broker; MSRB)(140)가 이용될 수 있다. MSRB(140)는 MS 서비스들에 대한 요청들을 수신하고, 요청 및 MS들의 현재 이용에 기초하여, 요청된 서비스를 제공하기 위한 적절한 MS를 결정한다. MSRB(140)는 예컨대, 이에 한정되지는 않지만, 콜의 지리적 근원지, 다양한 MS들과 콜의 발생지와의 근접성, MS의 성능들, 지원되어야 할 필요가 있는 콜 레그들의 수, 필요한 리소스들의 유형(예, 음성 인식 엔진 또는 디지트 콜렉션이 요구될 것인지), 콜 레그가 액티브될 시간의 길이, 장래의 예약들(예, 주어진 서비스에 대한 최소 용량, 또는 앞으로 스케줄링된 전화 회의) 및 MS의 이용에 영향을 미칠 수 있는 그 밖의 파라미터 및, 그 결과 원하는 서비스의 전달과 같은, 이용 가능한 대역폭의 단순한 이용 비율 이외의 이용에 관한 추가적인 파라미터들을 고려할 수 있다. MSRB(140)가 MS 리소스들을 선택하기 위해 채용하는 몇몇 정보들은 AS(120)로부터 예컨대, 이에 한정되지는 않지만, 포트들에 대해 필요한 코덱의 유형, 포트 이용의 적절한 지속 기간, 지리적 선호, 필요한 포트들의 개수, 제어 프로토콜(예컨대, VXML 또는 미디어 서버 제어 마크업 언어(Media Server Control Markup Language; MSCML) 또는 미디어 리소스 제어 프로토콜(Media Resource Control Protocol; MRCP) 등)에 대한 선호, 회의 식별 번호(스케줄링된 전화 회의들에 관해), 요청이 이루어지는 고객 서비스, 또는 DTMF 콜렉션 또는 음성 인식의 유형이 필요한지 여부와 같은, 요청의 속성들로 올 수 있다.

예를 들어, 도 1로 돌아가서, MSRB SIP 컨트롤러(145)는 음성 인식 성능을 가진 MS에 대한 요청을 수신할 수 있다. 요청은 두 시간 동안 100개의 포트들에 대한 요구를 포함할 수 있다. 여기서 사용된 것으로서, 포트는 물리적 포트에 한정되지 않으며 대신 논리적 포트를 나타낼 수 있음을 주의해야 한다. 따라서, 포트는 각 착신 콜에 대해 원하는 서비스를 제공하기 위한 충분한 대역폭 및 처리 능력 및 성능들을 가진 유닛으로 간주될 수 있다. 따라서, 100개의 논리적 포트들에 대한 필요는 100개 이상의 콜들을 동시에 처리할 수 있는 충분한 용량을 가진 단일의 물리적 포트의 부분을 이용함으로써 만족될 수 있다. 더욱이, 그것은 개별 포트들의 할당 식별 및 추적과는 대조적으로, MSRB가 원하는 유형의 포트들이 액세스될 수 있는 MS 어드레스를 식별하고, 그 레벨로 리소스 할당을 추적하는데 충분하다.

MSRB SIP 컨트롤러(145)는 서버일 수 있고, 네트워크에서 모든 이용 가능한 MS들의 용량, 현재의 이용, 및 계획된 이용을 결정하기 위해 MSRB 데이터베이스(150)에 질의할 수 있다. 전술한 예에 계속하여, MS(160)가 2시간 동안 100개의 포트들을 제공하기 위한 충분한 용량을 가지고 있음을 결정한 후, MS(160)의 어드레스가 CCE(130)를 통해 AS(120)에 제공될 수 있다. 일 실시예에서, AS 및 CCE는 이후 더 이상 MSRB(140)를 필요로 하지 않고 MS(160)에 콜 레그들을 설정하기 위해 접속들(122 및 164)을 따라 MS(160)와 직접 관계할 것이다. 대안적인 일 실시예에서, 신호들은 CCE(130)를 통해 MSRB(140) 및 MS(160)상으로 흐를 것이다. 이들 두 가지 방법들은 이하에서 더 상세히 설명될 것이다.

MSRB(140)가 요청된 서비스들을 제공할 수 있는 MS의 식별을 AS에 제공할 때, MSRB(140)는 MSRB 데이터베이스(150)에 MS의 이용을 저장한다. 따라서, 전술한 예에 계속하여, MS 서비스들에 대한 장래의 요청들은 MS(160)가 두 시간 동안 할당된 100개의 포트들을 가지고 있다는 사실을 고려할 것이다. MSRB(140)가 네트워크에서 MS들의 세트를 이용하는 모든 AS들에 대해 요청들을 수신하고, MSRB(140)가 현재의 요청들 및 예약들 둘 다에 기초하여, 네트워크 상의 모든 MS들의 할당을 알고 있기 때문에, MSRB(140)는 각 AS에 의해 필요로 하는 서비스가 제공됨을 보증하는 동시에 다양한 MS들의 더 큰 이용을 제공할 수 있다.

위 예에서는 100개의 포트들이 2시간 동안 요청되었지만, 한 시간 후에 거의 모든 포트들은 프리상태가 될 수 있다. 예를 들어, MS(160)가 인포머셜(infomercial)과 같은 광고에 응하는 고객들 콜링에 대해 IVR을 제공하고 있었다면, 인포머셜의 종료는 착신 콜들의 수가 상당히 감소되도록 할 것이다. AS(120)는 콜 시그널링 경로에 있기 때문에, 임의의 시간에서 얼마나 많은 콜 레그들이 MS(160)에 접속되는지 알 수 있다. 한 시간 후에, 인포머셜에 대한 콜들을 처리하는 AS(120)는 착신 콜 볼륨이 나머지 1시간 동안에는 단지 40개의 포트들이 필요하다고 결정할 수 있어서, 이때 AS(120)는 그 많은 것들이 MS 유휴 풀 상태(idle pool)로 복귀될 수 있음을 MSRB(140)에게 알림으로써 포트들 중 60개가 프리상태가 될 것이다. 이러한 접근은 MSRB가 더욱 효율적으로 네트워크 리소스들을 관리할 수 있도록 해주며, 또한 그 밖의 잠재적인 이점들을 제공할 수 있다. 설명한 바와 같이, 시그널링 에러들 또는 AS 실패들과 같은 것들로 인해 동기를 벗어나는 AS 세트 및 MSRB(140)에 대한 예방 조치로서 MSRB가 실제적인 MS 이용을 추적할 수 있도록, 통신 경로(175)가 하나 이상의 운용 지원 시스템들(Operations Support Systems; OSS)(170) 및 MSRB(140) 간에 제공된다. OSS는 예컨대, 서비스 당 예약들, 회의 당 예약들, MS 계획된 정지 시간, MS의 계획되지 않은 정지 시간, MS 장비 추가들 및 MS 장비 제거들과 같은 요소들을 포함하는 이용 업데이트들을 제공할 수 있다. 일 실시예에서, MS 이용 정보는 MS(160)로부터 경로(180)를 사용하여 OSS(170)를 통해 MSRB(140)로 올 수 있다. 대안적인 실시예에서, 이용 정보는 경로(162)를 사용하여 직접 제공될 수 있다.

일 실시예에서, 예컨대 관찰된 콜 볼륨이 기대한 것 이상인 경우, 할당된 포트들의 개수를 감소시키는 대신, AS(120)가 대신 MSRB(140)로부터 추가적인 포트들을 요청할 수 있다.

그러나, 모든 요청들이 전부 만족되지는 않음을 주의해야 한다. 예를 들어, X개의 포트들에 대한 요청이 Y개의 포트들에 대한 제2 AS로부터의 요청 및 제3 AS로부터의 Z개의 포트들에 대한 요청과 함께 제1 AS에 수신될 수 있고, X, Y 및 Z의 합계가 MS 상에서 이용할 수 있는 N개의 포트들의 용량을 초과할 수 있다. 알 수 있는 바와 같이, 상이한 MS들은 상이한 수의 이용 가능한 포트들을 가지며, 따라서 상이한 이용 레벨을 가질 수 있다. 제1 AS로부터 X개의 포트들에 대한 요청이 전화 회의에 관한 것이고, 다른 요청들이 IVR에 관한 것이라면, 이때 하나의 가능한 응답은 X개의 포트들에 대한 요청을 AS에 제공하고, Y 및 Z 개의 포트들에 대한 요청들의 일부를 제2 및 제3 AS들에 제공한다. 제2 및 제3 AS들은 이때 부분적인 제공을 수용할 것인지를 결정할 수 있다. 제2 및 제3 AS들이 모두 부분적인 제공을 수용한다면, MSRB는 각 AS 요청에 대해 할당된 포트들의 개수를 기록한다.

또한, 전화 회의를 지원하기 위한 X개의 포트들에 대한 요청은 접속될 발신자들의 수를 과대 평가(또는 과소 평가)할 수 있으며, 또한 접속될 콜들의 시간을 과대 평가(또는 과소 평가)할 수 있다. 또한, AS는 MSRB에 원하는 포트들의 개수 및 유형들에 대해 그 요청을 변경할 수 있다. MSRB는 또한 다른 AS들에 의해 제공된 포트들의 이용을 알고 있다. 따라서, 포트들이 이용될 때 적절하다면, 그들은 다른 AS를 지원하기 위해 이동될 수 있다.

도 1에 도시된 바와 같이, 운용 지원 시스템(OSS)(170)은 MSRB(140)에 접속된다. 일 실시예에서, OSS(170)는 장래의 서비스에 대한 요청에 응답하여, 리소스들의 장래의 이용을 스케줄링하기 위해 MSRB에 요청할 수 있다. 예를 들어, 2000개의 콜 레그들을 갖는 큰 전화 회의를 계획하고 있는 개인은 전화 회의에 참여하기로 계획된 2000명의 사람들 모두가 실제적으로 전화 회의에 함께 할 수 있는지를 보증하기 위해, 미리 전화 회의를 스케줄링하기를 원할 수 있다. MSRB는 임의의 미리 스케줄링된 이용에 기초하여, 선호되는 MS가 전화 회의를 처리하도록 결정할 수 있다. MSRB는 또한 각 MS의 더욱 지속적인 이용 레벨이 제공되도록 MS들의 스케줄링된 사용을 조정할 수 있음을 주의해야 한다. 따라서, 제1 및 제2 MS를 가진 일 실시예에서, MSRB는 제1 MS의 미리 스케줄링된 사용을 제2 MS로 이동시킬 수 있고, 제1 MS가 새로운 요청을 처리하도록 스케줄링할 수 있다. 변경들은 또한 변하는 우선순위들에 응답하여 이루어질 수 있다(예를 들어, 전화 회의에 대한 포트들의 할당이 IVR에 대한 포트들의 할당보다 더 우선할 수 있다). 추가적인 변경들이 MS의 손실과 같은 기술적인 문제들에 응하여 이루어질 수 있다. 따라서, MSRB는 네트워크상에서 MS들을 이용하는 강하고 효율적인 수단을 제공한다.

VoIP 기술의 이용에서 주지된 바와 같이, 보더 소자(BE: border element), CCE, MS 및 AS 네트워크 소자들 중 및 BE 및 SIP 폰 간의 기초가 되는 시그널링은 예컨대, 이에 한정되지는 않지만, SIP, H.323, 또는 MGCP(Media Gateway Control Protocol)과 같은 프로토콜들의 몇몇 결합이 될 수 있다. SIP를 사용하는 일 실시예에서, 이는 전술한 소자들 중 임의의 두 개 사이에 채용될 수 있는 것으로, 일련의 요청 메시지들(예, INVITE, BYE, ACK) 및 응답 메시지들(예, 180 Alerting, 200 OK)이 미디어 세션들을 확립하고 제거(clear)하기 위해 사용될 수 있다. SIP 메시지들은 예를 들어, SIP URI의 형태로, SIP 시그널링 실체들을 식별하기 위해, 어드레스 정보를 나른다. SIP 메시지들은 또한 SDP(Session Description Protocol)를 사용하는 미디어 정보를 포함하는, 다양한 유형의 페이로드(payload) 정보를 나르며, 이 경우 SDP 컨텐트는 미디어 수신 IP 어드레스들 및 미디어 특성들(예, G.726-인코딩된 오디오) 및 미디어 종료점들의 포트 번호들과 같은 것들을 가리킬 것이다. 미디어 어드레스들의 교환은 미디어 연결을 확립한다. 미디어 그 자체는 실시간 전송 프로토콜(Real-time Transport Protocol; RTP)과 같은 프로토콜을 이용하여 전달된다.

추가적으로, 도 1은 VoIP 네트워크를 표현하고 있다. BE, CCE, AS 및 MS와 같은 소자들은 VoIP 네트워크들에 갖춰진 기능들의 특정 유형의 그룹핑들을 구현한다. 따라서, 이들 소자들은 개시된 실시예들에 한정되어서는 안되며, 오히려 설명된 기능들을 수행하는 소자들을 가리킨다. 예를 들어, 일 실시예에서, BE는 세션 보더 컨트롤러(Session Border Controller)가 될 수 있고, 네트워크-외부 실체들에 관한 트랜스코딩 기능들, 다양한 보안, 방법(policy) 및 프로토콜 인터워킹(protocol interworking)을 수행할 수 있으며, 이는 네트워크-내부적 및 네트워크-외부적 어드레스들 간의 번역을 포함할 수 있다. 일 실시예에서, CCE는 콜 에이전트(Call Agent) 또는 소프트스위치(Softswitch)가 될 수 있고, 예컨대 라우팅 또는 AS 인보케이션(invocation) 및 상호작용과 같은 기능들을 처리하는 기초 콜을 수행할 수 있다. 알 수 있는 바와 같이, 이들 소자들은 한정되지 않으며, 다양한 소자들의 그 밖의 변경들이 적절히 사용될 수 있다.

도 2 및 도 3으로 돌아가면, 착신 콜들을 처리하는 방법이 도시되어 있다. 우선 단계 305에서, 폰(210)은 일례로 IP 노드이며, SIP에서 사용되는 포맷인 인바이트(INVITE) 메시지를 BE(215)에 보낸다. 메시지는 임의의 다른 주지된 프로토콜로 제공될 수도 있으며, 이 메시지는 서비스 요청의 일례이다. 인바이트(INVITE) 메시지는 목적지 어드레스 및/또는 원하는 서비스의 유형의 몇몇 표시를 포함한다. BE(215)는 이후 논리적 방법(local policy)에 기초하여 콜을 허용할지 여부(착신 시그널링이 허용된 IP 어드레스로부터인지 또는 요청된 콜 대역폭이 허용된 파라미터들 이내인지 여부)를 결정한다. SIP 폰(이에 한정되지는 않으나, 예컨대, Linksys RT41P2)은 콜 발생 디바이스의 일례이고, 콜 발생 디바이스는 네트워크에 직접 접속되거나 또는 중개 네트워크들을 통해 연결될 수 있다.

다음으로, 콜을 허용한 후에, 단계 310에서, BE(215)는 인바이트(INVITE) 메 시지를 CCE(130)로 보낸다. 메시지 수신시 CCE(130)는 전화 번호(telephone number; TN) 또는 인바이트(INVITE)에서의 그 밖의 정보와 연관된 임의의 서비스 특징이 있는지를 결정하기 위해, 서비스 브로커(service broker; SB)에 질의할 수 있다. SB는 적절한 AS의 어드레스로 응답할 수 있다. 이후, 단계 315에서, CCE(130)는 AS(120)로 인바이트(INVITE) 메시지를 보내고, 이것은 TN 또는 인바이트(INVITE)에 포함된 그 밖의 정보와 연관된 AS이다.

단계 320에서, AS(120)는 네트워크 서버(network server; NS)(220)로부터 추가적인 정보를 요청한다. 이 요청은 디렉토리 요청이 될 수 있고, SOAP, LDAP, SMTP 또는 그 밖의 프로토콜에 의해 제공될 수 있고, MSRB에 의해 지원되는 네트워크 내의 서버로 향하거나 네트워크 외부(예, 인터넷 상 어딘가에)에 있을 수 있다.

단계 325에서, AS(120)는 MS 리소스들 및 원하는 MS 속성들을 요청하는 인바이트(INVITE) 메시지를 CCE(130)로 보낸다. 단계 340에서, CCE(130)는 요청을 MSRB(140)로 전달한다. MSRB(140)는 다수의 서버들로 구성될 수 있고, CCE(130)는 메시지를 라운드-로빈 방식(round-robin fashion)을 통해 상이한 서버로 보낼 수 있지만, MSRB(140)가 모든 MS 리소스들의 액티비티(activity)를 추적할 수 있도록, MSRB(140)에 연관된 모든 MS들에 대한 액티비티의 단일의 논리적 데이터베이스가 요구된다. 즉, 상이한 MSRB들이 동일한 MS 리소스들을 사용할 수 없음을 주의해야 한다.

단계 345에서, MSRB(140)는 요청 및 현재/계획된 이용 레벨들에 비추어 적절한 MS를 결정한다. 전화 회의들에서, 주어진 회의에서 모든 콜 레그들을 처리하기 위해 단일의 MS를 이용하는 것이 선호될 것이다. 그러나, IVR 유형의 콜들에서는 다수의 MS가 효율적으로 사용될 수 있으며, 따라서 MSRB(140)는 다양한 MS들의 현존하는 이용에 기초하여 순수 스필릿(split) 또는 가중된 할당에서, 상이한 MS들이 요청된 포트들의 일부를 제공할 수 있음을 결정할 수 있다.

단계 350에서, MSRB(140)는 CCE(130)를 통해 AS(120)로 MS 어드레스 및 다른 적절한 정보를 제공한다. AS 요청이 언급한 바와 같이 받아들여질 수 없다면, MSRB는 대안적으로 응답할 수 있다(예, 요청이 미 동부에서 100개에 대해 있었던 반면, 50개의 포트들은 미 서부의 MS에서 제공될 수 있다). 단계 355에서, AS(120)는 CCE(130)가 MS(160)와 콜 레그를 설정하도록 명령한다. 단계 360에서, CCE(130)는 인바이트(INVITE) 메시지를 MS(160)에 보내고, MS(160)가 콜에 참여하도록 요청한다. 단계 365에서, MS(160)는 CCE(130)에 응답을 보내고, 콜을 수용한다. 단계 370에서, CCE(130)는 BE(215)에 응답을 중계한다. 단계 375에서, BE는 전화기(210) 및 MS(160)가 미디어 링크를 확립할 수 있도록, 전화기(210)에 응답을 보낸다. 단계 380에서, AS(120)는 MS(160)가 전화기(210)로부터의 전화통화를 처리하도록 명령들을 제공한다. AS(120)가 MS 리소스들의 일부 또는 전부가 더 이상 필요하지 않다고 결정하면, 예컨대, 콜 또는 회의가 끝나거나 포트들이 거의 필요하지 않다면, 포트들의 전부 또는 일부가 MS 유휴 리소스 풀로 리턴되도록 MSRB(140)와 통신할 것이다. 일 실시예에서, AS는 포트들에 대한 현재의 필요가 포트들의 개수, 유형 또는 유형들의 혼합에 대한 최초 요청과 일치하는지를 결정할 수 있다. 또한, 현재-할당된 포트들은 추가적인 시간을 필요로 할 수 있다. 예를 들어, AS는 처음에는 G.711 코딩을 갖는 얼마간의 포트들을 요청할 수 있고, 다음 시간에는 G.711 포트들 3/4과 G.726 포트들 1/4의 혼합이 요구되도록 결정할 수 있다. AS는 새로운 혼합을 요청하는 새로운 요청을 MSRB로 보낼 수 있다. 어떤 MS 리소스들이 이용 가능한지 및 그 회의를 위해 현재 할당된 MS 리소스들이 G.726를 지원할 수 있는지에 기초하여, MSRB는 동일한 MS 리소스들 또는 상이한 MS 리소스로부터의 요청된 G.726 포트들로 AS에 응답할 수 있다.

실제적인 미디어 스트림은 링크(280)를 통해(BE(215)를 통해) 전화기(210)와 MS(160) 사이를 이동하며, 따라서 전술한 설명은 실제적인 미디어 스트림의 라우팅이라기보다는 제공하는 서비스에 관한 서비스 및 신호들을 요청하는 라우팅에 관한 것이고, 이는 실시간 전송 프로토콜(RTP)에 제공될 수 있음을 주의해야 한다.

알 수 있는 바와 같이, 전술한 방법은 MSRB가 X개의 연결(leg)들까지 전화 회의에 대해 적절한 MS를 최초 결정하고, AS에 정보를 제공할 수 있게 해준다. 이점으로부터, 전화 회의에 합류하고자 하는 추가적인 콜 레그들은 AS에 의해 그 회의를 처리하는 MS 리소스들에 대해 이미 알고 있는 MS 어드레스로 간단히 보내질 수 있다. AS는 각 개별적인 콜에 대해 MSRB에 요청할 필요가 없다. MSRB를 이용하는 이러한 "간접적" 방법은 다른 방법들에 비해 몇몇 장점들을 가지고 있으며, 여기서 AS는 MSRB에 MS 리소스들을 요청하고, MS로부터 콜 레그들을 설정하는 단계 또는 MS로부터 콜 레그들을 제거하는 단계로부터 분리된 단계들에서 MS 리소스들이 더 이상 사용될 수 없을 때 MSRB에 알린다. 몇몇 가능한 장점들은 다음을 포함할 수 있다. (1) MSRB가 콜 제거(clearing) 메시지들로부터 그것을 추론하는 것과는 대조적으로, AS가 할당된 MS 리소스들이 더 이상 필요하지 않을 때를 결정하게 해준다 - 예를 들어, 회의 상황에서 유용할 수 있다. (2) AS가 콜 또는 콜들의 집합에 대한 얼마간 또는 상이한 리소스들에 대한 요청을 수정하도록 해준다. (3) AS와 MSRB 간의 리소스 협상을 허용해준다. (4) 전화 회의가 다수의 MS 물리적 유닛들로 연결하도록 해주고, AS가 그들을 서로 링크시키고 전체로서 회의를 관리하게 해주는 네트워크 소자가 되도록 한다. 간접적 방법은 또한 IVR 솔루션에서 사용될 수도 있다. IVR 서비스가 제공되는 경우에 간접적 방법의 가능한 단점 한가지는(이 시나리오에서 MS 포트는 콜이 제거될 때 프리상태가 될 수 있다고 일반적으로 추론할 수 있다) MS 포트가 프리상태가 될 수 있음을 결정하는데 많은 지연이 생길 수 있다는 것이다. 그러나, 간접적 방법은 AS가 리소스들을 할당하고 MSRB의 부담(burden)을 감소시키는 방법을 강력하게 제어하도록 해주고, 이들 이점들은 다른 단점을 능가할 수 있다.

AS와 MSRB 간의 상호작용은 기본적으로 데이터베이스 요청들 및 응답들로 간주될 수 있으며, 여기서 MSRB가 데이터베이스가 된다. 전술한 설명이 SIP를 사용하여 CCE를 통한 AS와 MSRB 간의 통신에 대해 상세를 제공하고 있지만, 대안적인 실시예에서, AS와 MSRB는 직접 통신할 수 있다. 일 실시예에서, AS와 MSRB는 SIP 대신에 HTTP를 사용하여 통신할 수 있다. 예를 들어, AS는 MS 리소스들을 요청하는데 HTTP GET 메시지들을 사용할 수 있고, MSRB가 그들을 유휴 풀상태로 리턴하게 하도록 HTTP POST 메시지들을 사용할 수 있다. 알 수 있는 바와 같이, AS와 MSRB 간의 직접 통신을 위해 임의의 다른 적절한 프로토콜이 사용될 수도 있다.

도 4 및 도 5로 돌아가면, 착신 콜들을 처리하는 방법의 대안적인 실시예가 도시되어 있다. 단계 504부터 단계 520까지는 도 3의 단계 305부터 단계 320까지와 본질적으로 동일하다. 단계 524에서, AS(140)는 CCE(130)로 인바이트(INVITE)를 보내고, 이는 그 콜에 대한 MS 리소스들의 요청 및 MS에 그 콜을 확립하라는 요청 양자를 동반하는 것이다. 단계 530에서, CCE(130)는 MS 리소스들 및 콜 확립에 관한 요청을 MSRB(140)로 전달하고, MSRB(140)는 MS(160)가 요청 및 알려진/계획된 이용에 비추어 적절하도록 결정한다. 단계 534에서, MSRB(140)는 인바이트(INVITE) 메시지를 MS(160)으로 보내서 콜 레그를 설정하도록 한다. 단계 540에서, MS(160)는 MSRB(140)에 응답하여 착신 콜 요청을 수용한다. 단계 544에서, MSRB는 정보가 CCE(130)를 통해 전달되도록 경로(460)를 통해 응답 메시지를 AS(120)로 전달한다. 단계 560에서, AS(120)는 콜 설정 응답 메시지를 CCE(130)를 통해 BE(415)로 보낸다. 단계 564에서 BE(415)는 콜 설정 응답 메시지들을 전화기(210)로 제공한다. 단계 570에서, MS(160)는 AS(120)로부터 스크립트를 회수한다. 단계 574에서, MS(160)는 양방향 서비스가 시작되도록 링크(280)를 통해 전화기(210)로 오디오를 보낸다. 단계 580에서, 콜이 종료되고, MSRB(140)는 SIP 제거 시그널링으로부터 MS 리소스가 유휴 풀 상태로 되돌아갈 수 있음을 추론한다.

알 수 있는 바와 같이, MSRB(140)는 콜 확립 요청들을 AS(120)로부터 MS(160)로 중계한다. 따라서, IVR과 같은 서비스들에 대해서, 도 4 내지 5에 도시된 이 "중계" 방법의 실시예는 도 2 내지 3에 도시된 간접적 방법의 일실시예에 비해 MSRB와의 상이한 상호작용을 제공한다. 중계 방법은 콜 제거가 관찰되는 것으로 부터 이를 추론할 수 있는 경우, MSRB가 MS 리소스가 유휴 상태로 되돌아갈 수 있음을 보다 신속하게 결정할 수 있게 해주며, 간접적 방법에 비해 AS와 MSRB 간에 더 적은 단계들을 필요로 한다. 그러나, 중계 방법은 전술한 바와 같이, AS가 쓸 수 있는 제어의 양에 관해서는 간접적 방법에 비해 더 제한적일 수 있다.

도 6 및 도 7은 각각 간접적 방법 및 중계 방법을 추가적으로 도시하고 있다. 알 수 있는 바와 같이, 두 방법은 일정한 장점들을 가진다.

우선, 도 6을 보면, 단계 610에서, AS는 MS 리소스들을 요청한다. 일 실시예에서, 요청은 X 개의 포트들을 포함하는 전화 회의를 시작하도록 하는 것이 될 수 있다. 단계 615에서, CCE는 요청을 MSRB(전술한 바와 같이, 이것은 단일의 논리적 데이터베이스를 공유하는 하나 이상의 물리적 서버들이 될 수 있다)에 전달한다. 단계 620에서, MSRB는 MS 위치를 결정한다. 이 결정은 전송 지연을 최소화하기 위해 지리적 요소를 포함할 수 있다. 단계 625에서, MSRB는 200 OK 신호를 MS의 어드레스와 함께 CCE를 통해 AS로 보낸다.

단계 630에서, CCE는 AS의 요청으로 MS와 다양한 전화기들 간의 콜 레그들을 설정한다. 단계 635에서, 제어 레그(control leg)는 AS와 MS 사이에 설정된다. 제어 레그는 AS가 MS에게 예컨대, 말하는 사람의 레그 음성입력(leg voice input)을 제외하고 모두 뮤트시키거나 또는 모든 회의 레그들(conference legs)에게 고지를 재생시키거나, 또는 부가적인 회의를 생성하거나, 또는 N개의 소리가 가장 큰 레그들로부터의 입력을 혼합하라는 것과 같은, 명령들을 제공할 수 있도록 해준다. 더 나아가, 모든 예약된 포트들이 사용 중에 있다면, AS는 추가적인 포트들을 요청할 수 있다. 안전율을 제공하기 위해 종종 요청이 몇몇 추가적인 포트들을 포함할 수 있기 때문에, 이것은 일반적으로 이슈가 되지 않는다. 포트들을 다 써버리는 것을 방지하기 위해, 요청된 포트들의 개수의 비율을 콜 기간 동안 시험적으로 할당할 수 있으며, 일단 AS가 포트들이 필요없다고 결정하면 그들은 다른 사용을 위해 해제(release)될 수 있다. 여분의 포트들이 제공된다면, 이는 제공된 콜에서 기대되는 참여 레벨보다 더 높은 것에 대비해 버퍼로서 동작할 수 있으며, 이들은 하나 이상의 콜에서 공유될 수 있음을 주의해야 한다.

단계 640에서, 콜은 종료된다. 이것은 최종 콜 레그의 말단에 의해 결정될 수 있다. 단계 640에서 일단 콜이 종료되면, 단계 645에서 AS는 리소스들이 비할당될 수 있음을 MSRB에 신호를 보낸다. 일 실시예에서 신호는 바이(BYE) 메시지일 수 있다. 단계 650에서 미리 할당된 MS 리소스들이 유휴 풀 상태로 되돌아온다.

도 7로 돌아가면, 높은 레벨의 중계 방법의 설명이 도시되어 있으며, 다시 전화 통화 시나리오를 가정한다. 단계 705에서, 회의에 대한 제1 콜 레그가 네트워크로 들어오면, AS는 그 콜 레그가 MS에 확립되어야 함을 요청하는 동일한 메시지로 MS 리소스를 요청한다. 요청은 필요한 MS 리소스들의 유형 및 필요한 포트들의 개수를 포함해야 한다. 요청은 또한 알려졌다면, 콜의 기대 시간뿐만 아니라 발신자의 지리적 지역에 관한 정보를 포함할 수 있다. 설명한 실시예에서, 요청은 인바이트(INVITE) 메시지 형태로 CCE에 보내진다. 단계 710에서, CCE는 인바이트(INVITE) 메시지를 동일한 요청 정보와 함께 MSRB로 보낸다. 단계 715에서, MSRB는 적절한 MS의 위치를 결정하고, MS의 할당이 현재 유지되도록 MSRB 데이터베이스 에서 할당을 추적한다.

다음으로, 단계 720에서, MSRB는 콜 레그를 생성하도록 MS로 인바이트(INVITE) 메시지를 보낸다. 알 수 있는 바와 같이, MS는 다른 MS들에 대한 그 이용 가능성을 결정할 필요가 없기 때문에 더 적은 정보가 MS에 제공될 수 있다. 단계 725에서, MS는 콜의 수용을 가리키는 콜 설정 요청에의 응답 메시지(예, 200 OK)를 보냄으로써 MSRB에 응답한다. 단계 730에서, MSRB는 발신자가 MS에 접속될 수 있도록 CCE로 이 정보를 제공한다. 시그널링 경로는 CCE로 가는 도중에 AS를 통해 통과하며, 따라서 전화기로부터 MS로의 시그널링 경로는 BE로부터 CCE->AS->CCE->MSRB->MS를 통과함을 주의해야 한다.

단계 740에서, MS는 AS로부터 필요한 파일들 및 스크립트를 회수한다. 스크립트는 VXML 포맷이 될 수 있고, 회수는 HTTP 또는 다른 적절한 프로토콜을 통해 달성될 수 있다. 단계 745에서, 발신자 및 MS는 상호작용한다. 미디어 상호작용은 MS와 전화기 사이의 링크(280)(도 4)에서 이루어질 수 있으며, 주지된 방식으로 오디오 스트림을 전송하기 위해 RTP와 같은 임의의 적절한 프로토콜을 사용할 수 있다.

일단 상호작용이 완료되면, 단계 750에서 AS는 MS 및 발신자에 대한 콜을 제거한다. 단계 755에서, MSRB는 콜의 제거를 알고 MS 리소스들을 유휴 풀 상태로 되돌린다. 인지될 수 있는 바와 같이, MSRB는 콜을 제거하기 위한 시그널링 경로에 있기 때문에, MSRB는 포트가 더 이상 사용되지 않음을 콜 레그의 제거로부터 추론될 수 있는 경우에 이를 빠른 통지로 수신한다. 그러나, 큰 규모의 전화 회의에서, MSRB가 각 콜 레그의 시그널링 경로에 있다는 사실은 MSRB의 작업부하를 증가시킬 수 있다.

따라서, 간접적 방법들은 예를 들어, 큰 규모의 전화 회의들을 처리하는데 있어서, AS가 포트들이 사용되는 방법 및 바람직한 방법을 더 강력하게 제어하도록 해줄 수 있다. 그러나, 중계 방법은 각 콜 레그의 상태를 더 빠르게 업데이트할 수 있으며, IVR 유형 콜들을 처리하는데 바람직할 수 있다. 그러나, 이들 방법 어느 것도 특정 유형의 콜에 한정되지 않음을 주의해야 한다.

본 발명은 그 바람직하고 예시적인 실시예들의 관점에서 설명되었다. 수반되는 청구항들의 범위 및 정신 내에서, 당업자에게 수많은 다른 실시예들, 변경들 및 수정들이 본 개시 내용으로부터 이루어질 것이다.

Claims

IP 노드(210)에 서비스들을 제공하는 방법에 있어서:

(a) 애플리케이션 서버(120)에서 IP 노드로부터의 서비스 요청을 수신하는 단계;

(b) 상기 서비스 요청에 응답하여 미디어 서버 리소스 브로커(media server resource broker; 140)로부터 미디어 서버 리소스들을 요청하는 단계;

(c) 상기 애플리케이션 서버에 제 1 미디어 서버(160)의 선택을 제공하기 위해 상기 미디어 서버 리소스 브로커를 사용하는 단계로서, 상기 미디어 서버 리소스 브로커는 상기 미디어 서버 리소스들에 대한 요청 및 미디어 서버들의 세트 내의 상기 미디어 서버들의 이용에 관한 하나 이상의 파라미터들에 응답하여 상기 미디어 서버들의 세트로부터 상기 제 1 미디어 서버를 선택하는, 상기 미디어 서버 리소스 브로커 사용 단계;

(d) 상기 IP 노드와 상기 제 1 미디어 서버 사이에 콜을 확립하는 단계; 및

(e) 상기 애플리케이션 서버로부터 상기 제 1 미디어 서버로 상기 콜을 관리하기 위한 명령들을 제공하는 단계를 포함하고,

상기 하나 이상의 파라미터들 중 하나는 상기 제 1 미디어 서버의 이용된 및 이용되지 않은 용량의 현재량(current amount)인, 서비스 제공 방법.
제1항에 있어서,

상기 미디어 서버들의 세트는 분리된 지리적 영역들에 있는 미디어 서버들을 포함하는, 서비스 제공 방법.
제1항에 있어서,

(a)에서의 상기 서비스 요청은 세션 개시 프로토콜(Session Initiation Protocol), H.323, 미디어 게이트웨이 제어 프로토콜(Media Gateway Control Protocol), 스키니 클라이언트 제어 프로토콜(Skinny Client Control Protocol), MiNet, CorNet-IP, 별표간 교환 프로토콜(Inter-Asterisk eXchange Protocol), 스카이프(Skype), 및 Jajah의 리스트로부터 선택된 프로토콜로 제공되는, 서비스 제공 방법.
제1항에 있어서,

(b)의 상기 요청 단계는 하이퍼텍스트 전송 프로토콜(HyperText Transport Protocol)을 이용하여 상기 애플리케이션 서버로부터 상기 미디어 서버 리소스 브로커로 직접 이루어지는, 서비스 제공 방법.
제1항에 있어서,

(b)의 상기 요청 단계는:

(i) 콜 제어 소자에 인바이트(INVITE) 메시지를 전송하는 단계; 및

(ii) 상기 콜 제어 소자로부터 상기 미디어 서버 리소스 브로커로 제2 인바이트 메시지를 전송하는 단계를 포함하는, 서비스 제공 방법.
제1항에 있어서,

(b)의 상기 요청 단계는, 상기 미디어 서버 사용의 성질(nature), 필요한 포트들의 개수, 고객-가입(customer-subscribed) 서비스의 유형, 필요한 포트의 특성들, 포트 사용의 지속시간, 전화 회의 식별, 상기 미디어 서버의 위치에 대한 지리적 선호, 및 사용될 제어 프로토콜에 대한 선호의 리스트로부터 선택된 하나 이상의 속성들을 포함하는, 서비스 제공 방법.
제1항에 있어서,

(c)에서 상기 하나 이상의 파라미터들 중 하나는, 상기 세트 내의 각 미디어 서버의 성능, 상기 세트 내의 각 미디어 서버의 이용 가능한 포트들의 개수, 상기 세트 내의 각 미디어 서버의 지리적 위치, 상기 세트 내의 각 미디어 서버의 현재 이용, 및 상기 세트 내의 각 미디어 서버의 스케줄링된 이용의 리스트로부터 선택되는, 서비스 제공 방법.
제1항에 있어서,

(d)의 상기 콜 확립 단계는 실시간 전송 프로토콜을 이용하는, 서비스 제공 방법.
제1항에 있어서,

상기 제 1 미디어 서버는 복수의 미디어 서버들을 포함하는, 서비스 제공 방법.
제1항에 있어서,

(e)에서 상기 명령들을 제공하는 단계는,

(i) 미디어 세션 마크업 언어(Media Session Markup Language), 미디어 오브젝트 마크업 언어(Media Object Markup Language), 미디어 서버 제어 마크업 언어(Media Server Control Markup Language), 음성 확장성 마크업 언어(Voice eXtensible Markup Language), 콜 제어 확장성 마크업 언어(Call Control eXtensible Markup Language), 및 미디어 리소스 제어 프로토콜(Media Resource Control Protocol)로 구성되는 리스트로부터 선택된 언어를 이용하여 명령들을 전송하는 단계를 포함하는, 서비스 제공 방법.
제1항에 있어서,

(c)에서 상기 선택 단계는,

(i) 상기 미디어 서버들의 세트 내의 각 미디어 서버들에서 상기 요청된 미디어 리소스들을 제공하기에 적절한 이용 가능한 포트들의 개수에 기초하여, 상기 제 1 미디어 서버가 상기 요청된 미디어 서버 리소스들을 제공해야 함을 결정하는 단계를 포함하는, 서비스 제공 방법.
미디어 서버들의 세트의 이용을 제어하는 방법에 있어서:

(a) 미디어 서버 리소스 브로커(140)에서 미디어 서버 리소스에 대한 요청을 수신하는 단계;

(b) 상기 미디어 서버들의 세트 내의 각 미디어 서버들에 대해 상기 요청된 미디어 서버 리소스의 이용 가능성을 결정하는 단계;

(c) 선택된 제 1 미디어 서버(160)의 어드레스를 제공하는 단계로서, 상기 미디어 서버 리소스 브로커는 상기 결정된 이용 가능성에 기초하여 상기 미디어 서버들의 세트로부터 상기 제 1 미디어 서버를 선택하는, 상기 어드레스 제공 단계; 및

(d) 상기 제 1 미디어 서버의 할당 레벨의 변경을 추적하는 단계로서, 상기 변경은 상기 미디어 서버 리소스에 대한 요청에 기초하는, 상기 추적 단계를 포함하고,

상기 이용 가능성 결정 단계는:

(ⅰ) 상기 미디어 리소스에 대한 요청에서 요청된 미디어 리소스의 유형을 결정하는 단계; 및

(ⅱ) 상기 미디어 서버들의 세트 내의 미디어 서버들 중 어느 것이 상기 요청된 미디어 리소스의 유형을 만족시키는지를 결정하는 단계를 포함하는, 제어 방법.
제12항에 있어서,

(a)에서 상기 요청은 상기 미디어 서버 사용의 성질, 필요한 포트들의 개수, 고객-가입 서비스의 유형, 필요한 포트의 특성들, 포트 사용의 지속시간, 전화 회의 식별, 상기 미디어 서버의 위치에 대한 지리적 선호, 및 사용될 제어 프로토콜에 대한 선호의 리스트로부터 선택된 하나 이상의 속성들을 포함하는, 제어 방법.
제12항에 있어서,

상기 미디어 서버 리소스 브로커는 데이터베이스 모듈에 결합된 적어도 하나의 서버를 포함하고, (d)에서 상기 추적 단계는,

(i) 상기 데이터베이스 모듈에 저장된 상기 제 1 미디어 서버의 상기 할당 레벨의 기록을 업데이트하는 단계를 포함하는, 제어 방법.
제12항에 있어서,

상기 미디어 서버들의 세트는 상이한 지역들에 위치한 복수의 미디어 서버들을 포함하는, 제어 방법.
제12항에 있어서,

(b)의 상기 이용 가능성 결정 단계는:

(i) 요청된 포트들의 개수 및 유형을 상기 미디어 서버들의 세트 내의 각 미디어 서버에서 이용 가능한 포트들의 개수 및 유형과 비교하는 단계; 및

(ii) 상기 미디어 서버들이 상기 요청된 개수 및 유형을 만족시키는 충분한 포트들을 제공할 수 있도록, 상기 요청된 개수의 포트들을 제공한 후 가장 높은 레벨의 이용 가능한 여분의 포트들을 가진 상기 미디어 서버로서 상기 제 1 미디어 서버를 선택하는 단계를 포함하는, 제어 방법.
제12항에 있어서,

(e) 상기 미디어 서버의 이용 레벨에 관한 업데이트를 수신하는 단계를 더 포함하고, 상기 업데이트는 미디어 서버(160) 및 운용 지원 시스템(170)의 리스트로부터 선택된 모듈로부터 발생하는, 제어 방법.
제17항에 있어서,

상기 이용 레벨에 관한 상기 업데이트는, 계획된 정지 시간, 계획되지 않은 정지 시간, 장비 추가들, 장비 제거들, 서비스 당(per-service) 예약들, 회의 당(per-conference) 예약들, 및 미디어 서버 이용 상태의 리스트로부터 선택된 적어도 하나의 요소를 포함하는, 제어 방법.
제12항에 있어서,

(e) 상기 미디어 서버 리소스 브로커에서 장래의 미디어 서버 리소스들에 대한 요청을 수신하는 단계; 및

(f) 장래의 상기 미디어 서버 리소스들에 대한 요청과 연관된 계획된 할당을 데이터베이스 모듈(150)에 저장하는 단계를 더 포함하고, (b)에서 상기 미디어 서버들의 세트 내의 상기 미디어 서버들의 이용 가능성을 결정하는 단계는 상기 계획된 할당을 포함하는, 제어 방법.
삭제
삭제
삭제
삭제
삭제
IP 노드(210)에 서비스들을 제공하는 방법에 있어서:

(a) 애플리케이션 서버(120)에서 상기 IP 노드로부터 서비스 요청을 수신하는 단계;

(b) 상기 서비스 요청에 응답하여, 미디어 서버 리소스 브로커(140)로부터 미디어 서버 리소스를 요청하는 단계;

(c) 제 1 미디어 서버(160)가 상기 서비스 요청을 만족하도록 이용 가능함을 상기 미디어 서버 리소스 브로커로 결정하는 단계로서, 상기 제 1 미디어 서버는 미디어 서버 리소스에 대한 요청 및 미디어 서버들의 세트 내의 상기 미디어 서버들의 이용과 관련된 하나 이상의 파라미터들에 응답하여 상기 미디어 서버들의 세트로부터 선택되는, 상기 결정 단계;

(d) 상기 미디어 서버 리소스 브로커를 통해 상기 제 1 미디어 서버를 상기 IP 노드와 접속하는 단계로서, 상기 접속은 상기 제 1 미디어 서버와 상기 IP 노드 간에 콜을 확립하는데 사용하기 위한 포트 수 및 IP 어드레스를 제공하는, 상기 접속 단계;

(e) 상기 IP 노드와 상기 제 1 미디어 서버 사이에 콜을 확립하는 단계; 및

(f) 상기 콜을 관리하기 위한 명령들을 상기 애플리케이션 서버로부터 상기 제 1 미디어 서버에 제공하는 단계를 포함하고,

상기 하나 이상의 파라미터들 중 하나는 상기 제 1 미디어 서버의 이용된 및 이용되지 않은 용량의 현재량인, 서비스 제공 방법.
제25항에 있어서,

상기 미디어 서버의 세트는 분리된 지리적 지역들에 위치한 미디어 서버들을 포함하는, 서비스 제공 방법.
제25항에 있어서,

(a)에서의 상기 서비스 요청은 세션 개시 프로토콜, H.323, 미디어 게이트웨이 제어 프로토콜, 스키니 클라이언트 제어 프로토콜, MiNet, CorNet-IP, 별표간 교환 프로토콜, 스카이프, 및 Jajah의 리스트로부터 선택된 프로토콜로 제공되는, 서비스 제공 방법.
제25항에 있어서,

(b)의 상기 요청 단계는 하이퍼텍스트 전송 프로토콜을 사용하여 상기 애플리케이션 서버로부터 상기 미디어 서버 리소스 브로커로 직접 이루어지는, 서비스 제공 방법.
제25항에 있어서,

(b)의 상기 요청 단계는,

(i) 콜 제어 소자(130)에 인바이트(INVITE) 메시지를 전송하는 단계; 및

(ii) 상기 콜 제어 소자로부터 상기 미디어 서버 리소스 브로커로 제2 인바이트 메시지를 전송하는 단계를 포함하는, 서비스 제공 방법.
제25항에 있어서,

(b)의 상기 요청 단계는, 상기 미디어 서버 사용의 성질, 필요한 포트들의 개수, 고객-가입 서비스의 유형, 필요한 포트의 특성들, 포트 사용의 지속시간, 전화 회의 식별, 상기 미디어 서버의 위치에 대한 지리적 선호, 및 사용될 제어 프로토콜에 대한 선호의 리스트로부터 선택된 하나 이상의 속성들을 포함하는, 서비스 제공 방법.
제25항에 있어서,

(c)에서 상기 하나 이상의 파라미터들 중 하나는, 상기 세트 내의 각 미디어 서버의 성능, 상기 세트 내의 각 미디어 서버의 이용 가능한 포트들의 개수, 상기 세트 내의 각 미디어 서버의 지리적 위치, 상기 세트 내의 각 미디어 서버의 현재 이용, 및 상기 세트 내의 각 미디어 서버의 스케줄링된 이용의 리스트로부터 선택되는, 서비스 제공 방법.
제25항에 있어서,

(e)의 상기 콜 확립 단계는 실시간 전송 프로토콜을 사용하는, 서비스 제공 방법.
제25항에 있어서,

상기 제 1 미디어 서버는 복수의 미디어 서버들을 포함하는, 서비스 제공 방법.
제25항에 있어서,

(f)의 명령들 제공 단계는,

(i) 미디어 세션 마크업 언어, 미디어 오브젝트 마크업 언어, 미디어 서버 제어 마크업 언어, 음성 확장성 마크업 언어, 콜 제어 확장성 마크업 언어, 및 미디어 리소스 제어 프로토콜로 구성되는 리스트로부터 선택된 언어를 이용하여 명령들을 전송하는 단계를 포함하는, 서비스 제공 방법.
제25항에 있어서,

(c)의 상기 결정 단계는 상기 미디어 서버들의 세트 내의 상기 각 미디어 서버들에서 상기 요청된 미디어 서버 리소스들을 제공하기에 적절한 이용 가능한 포트들의 개수에 기초하는, 서비스 제공 방법.
미디어 서버들의 세트의 이용을 제어하는 방법에 있어서:

(a) 미디어 서버 리소스 브로커(140)에서 미디어 서버 리소스에 대한 요청을 수신하는 단계;

(b) 상기 미디어 서버들의 세트 내의 각 미디어 서버들(160)에 대해 상기 요청된 미디어 서버 리소스의 이용 가능성을 결정하는 단계;

(c) 제 1 미디어 서버의 IP 어드레스 및 포트의 개수를 IP 노드(210)에 제공하는 단계; 및

(d) 제 1 미디어 서버의 할당 레벨의 변경을 추적하는 단계로서, 상기 변경은 상기 미디어 서버 리소스에 대한 요청에 기초하는, 상기 추적 단계를 포함하고,

상기 이용 가능성 결정 단계는:

(ⅰ) 상기 미디어 리소스에 대한 요청에서 요청된 미디어 리소스의 유형을 결정하는 단계; 및

(ⅱ) 상기 미디어 서버들의 세트 내의 미디어 서버들 중 어느 것이 상기 요청된 미디어 리소스의 상기 유형을 만족시키는지를 결정하는 단계를 포함하는, 제어 방법.
제36항에 있어서,

(a)에서의 상기 요청은 세션 개시 프로토콜로 제공되는, 제어 방법.
제36항에 있어서,

(a)에서의 상기 요청은, 상기 미디어 서버 사용의 성질, 필요한 포트들의 개수, 고객-가입 서비스의 유형, 필요한 포트의 특성들, 포트 사용의 지속시간, 전화 회의 식별, 상기 미디어 서버의 위치에 대한 지리적 선호, 및 사용될 제어 프로토콜에 대한 선호의 리스트로부터 선택된 하나 이상의 속성들을 포함하는, 제어 방법.
제36항에 있어서,

상기 미디어 서버 리소스 브로커는 데이터베이스 모듈에 결합된 적어도 하나의 서버를 포함하고, (d)의 상기 추적 단계는,

(i) 상기 데이터베이스 모듈에 저장된 상기 제 1 미디어 서버의 상기 할당 레벨의 기록을 업데이트하는 단계를 포함하는, 제어 방법.
제36항에 있어서,

상기 미디어 서버들의 세트는 상이한 지역들에 위치한 복수의 미디어 서버들을 포함하는, 제어 방법.
제36항에 있어서,

(b)의 상기 이용 가능성 결정 단계는:

(i) 요청된 포트들의 개수 및 유형을 상기 미디어 서버들의 세트 내의 각 미디어 서버에서 이용 가능한 포트들의 개수 및 유형과 비교하는 단계; 및

(ii) 상기 미디어 서버들이 상기 요청된 개수 및 유형을 만족시키는 충분한 포트들을 제공할 수 있도록, 상기 요청된 개수의 포트들을 제공한 후 가장 높은 레벨의 이용 가능한 여분의 포트들을 가진 상기 미디어 서버로서 상기 제 1 미디어 서버를 선택하는 단계를 포함하는, 제어 방법.
제36항에 있어서,

(e) 상기 미디어 서버의 이용 레벨에 관한 업데이트를 수신하는 단계를 더 포함하고, 상기 업데이트는 미디어 서버(160) 및 운용 지원 시스템(170)의 리스트로부터 선택된 모듈로부터 발생하는, 제어 방법.
제42항에 있어서,

상기 이용 레벨에 관한 상기 업데이트는, 계획된 정지 시간, 계획되지 않은 정지 시간, 장비 추가들, 장비 제거들, 서비스 당 예약들, 회의 당 예약들, 및 미디어 서버 이용 상태의 리스트로부터 선택된 적어도 하나의 요소를 포함하는, 제어 방법.
제36항에 있어서,

(e) 상기 미디어 서버 리소스 브로커에서 장래의 미디어 서버 리소스들에 대한 요청을 수신하는 단계; 및

(f) 상기 요청의 계획된 이용을 데이터베이스 모듈(150)에 저장하는 단계를 더 포함하고, (b)의 상기 이용 가능성 결정 단계는 상기 계획된 이용을 포함하는, 제어 방법.
VoIP 네트워크를 통해 양방향 음성 응답 콜을 처리하는 방법에 있어서:

(a) 서비스 요청을 애플리케이션 서버(120)에 제공하는 단계로서, 상기 서비스 요청은 VoIP 폰(210)에 연관된 보더 소자(border element; 215)로부터 수신되는, 상기 서비스 요청 제공 단계;

(b) 미디어 서버 리소스들에 대한 요청을 미디어 서버 리소스 브로커(140)에 제공하는 단계;

(c) VoIP 네트워크 상의 제 1 미디어 서버(160)의 IP 어드레스를 결정하는 단계;

(d) IP 어드레스 및 포트 수를 결정하기 위해 상기 미디어 서버 리소스 브로커로 상기 제 1 미디어 서버에 질의하는 단계;

(e) 상기 미디어 서버 리소스 브로커를 통해 상기 제 1 미디어 서버를 상기 보더 소자에 접속하는 단계; 및

(f) 상기 VoIP 폰과 상기 제 1 미디어 서버 사이에 콜을 확립하는 단계를 포함하고,

상기 (c)의 결정 단계는:

(ⅰ) 상기 미디어 서버 리소스들에 대한 요청을 상기 미디어 서버들의 세트의 이용 가능성과 비교하는 단계; 및

(ⅱ) 상기 제 1 미디어 서버의 용량을 결정하는 것을 포함하는 상기 제 1 미디어 서버의 현재 이용을 결정하는 것에 의해, 상기 미디어 서버 리소스들을 제공하기 위하여 상기 미디어 서버들의 세트로부터 상기 제 1 미디어 서버를 선택하는 단계를 포함하는, 양방향 음성 응답 콜 처리 방법.
삭제
제45항에 있어서,

(ii)의 상기 선택 단계는,

(1) 상기 제 1 미디어 서버가 상기 미디어 서버들의 세트 내의 다른 미디어 서버들보다 더 낮은 할당 레벨을 가짐을 결정하는, 양방향 음성 응답 콜 처리 방법.
제45항에 있어서,

(f)의 상기 콜 확립 단계는 실시간 전송 프로토콜을 사용하는, 양방향 음성 응답 콜 처리 방법.