[go: up one dir, main page]

KR20030007816A - 응용프로그램 및 서비스 서버 관리를 위한 프로토콜독립형 제어 모듈을 이용한 매체 세션 틀 - Google Patents

응용프로그램 및 서비스 서버 관리를 위한 프로토콜독립형 제어 모듈을 이용한 매체 세션 틀 Download PDF

Info

Publication number
KR20030007816A
KR20030007816A KR1020027016349A KR20027016349A KR20030007816A KR 20030007816 A KR20030007816 A KR 20030007816A KR 1020027016349 A KR1020027016349 A KR 1020027016349A KR 20027016349 A KR20027016349 A KR 20027016349A KR 20030007816 A KR20030007816 A KR 20030007816A
Authority
KR
South Korea
Prior art keywords
request
application
requests
service
protocol
Prior art date
Application number
KR1020027016349A
Other languages
English (en)
Other versions
KR100889977B1 (ko
Inventor
브라이언 마퀴트
로버트 헤르난데스
폴 와이벨
브레트비. 버처
마크비. 애보트
제시 멜렌데스
Original Assignee
샌드체리, 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/965,057 external-priority patent/US7185094B2/en
Application filed by 샌드체리, 인코포레이티드 filed Critical 샌드체리, 인코포레이티드
Publication of KR20030007816A publication Critical patent/KR20030007816A/ko
Application granted granted Critical
Publication of KR100889977B1 publication Critical patent/KR100889977B1/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1106—Call signalling protocols; H.323 and related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1017—Server selection for load balancing based on a round robin mechanism
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1036—Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Abstract

본 발명은 응용프로그램의 멀티플렉싱을 제공한다. 특히, 접근 서버(308/310)는 응용프로그램(312)에 접근하기 위해 사용자(302, 402, 2410)로부터 요청을 수신한다. 수신한 요청을 바탕으로, 접근 서버(308/310)는 접근 서버(308/310)와 사용자(302, 402, 2410) 사이에 통신 링크를 구축한다. 요청한 응용프로그램(312)에 대한 가용 경로(1808)를 이용할 수 있을 경우 접근 요청이 입력 요청 큐(1804)에 저장된다. 입력 요청 큐(1804)와 응용프로그램(312)간에 통신 경로(1808)가 구축되고, 저장된 요청이 제거되어 응용프로그램(312)에 전달된다. 더욱이, 본 발명은 다중 프로토콜 포맷 사이에서 응용프로그램(312)과 서비스(314)를 요청한 클라이언트(302, 402, 2410)에게 제공하기 위해 프로토콜 독립형 제어 모듈(1900)을 제공한다. 특히, 제어 모듈은 요청한 프로토콜을 식별할 수 있고, 식별된 프로토콜을 지원할 수 있는 응용프로그램 및 서비스 제공자(312, 314)를 선택할 수 있다.

Description

응용프로그램 및 서비스 서버 관리를 위한 프로토콜 독립형 제어 모듈을 이용한 매체 세션 틀{MEDIA SESSION FRAMEWORK USING PROTOCOL INDEPENDENT CONTROL MODULE TO DIRECT AND MANAGE APPLICATION AND SERVICE SERVERS}
종래의 소프트웨어 패키지에서는 설계된 기능 수행을 위해 메모리, 데이터베이스, 또는 그 외 다른 응용프로그램에 접근하여야 했다. 예를 들어, 특정 형태의 데이터 변환을 필요로하는 소프트웨어 패키지에 사용자가 접근할 수 있다. 소프트웨어 패키지를 이용하여 변환을 실행하는 한가지 방법은 소프트웨어 패키지 내에 직접 변환을 프로그래밍하는 것이다. 그러나 최근에는 응용프로그램이 복잡한 기능을 요구할 때, 사용자가 소프트웨어 패키지(응용프로그램이라 불림)에 접근하고 이소프트웨어 패키지가 또다른 소프트웨어 패키지(서비스 프로그램이라 불림)에 접근하는 경향이 있다. 복잡한 기능을 자체적으로 실행하도록 응용프로그램을 프로그래밍하는 대신에, 요청받은 기능을 전문적으로 실행하도록 설계된 다른 서비스 프로그램에 접근하도록 응용프로그램이 프로그래밍된다.
도 1과 2는 상기 요청들을 처리할 수 있는 음성 인지 서비스를 필요로하는 응용프로그램을 음성 인지 서버에 할당하기 위한 종래의 시스템을 도시한다. 도 1과 2의 종래 시스템은 단순한 음성 인지 서비스를 넘어 복잡한 다른 기능에도 접근하기 위한 광폭 응용프로그램을 가지는 것이 일반적이다. 그러나 음성 인지 서비스는 공통적인 응용프로그램이다. 게다가, 도 2의 종래 시스템은 서비스 프로그램 멀티플렉싱을 필요로하는 한가지 공통 종류의 응용프로그램을 구성하는 음성 인지 응용프로그램용이다.
보다 세밀히 살펴보면, 도 1은 종래 시스템(100)을 도시한다. 종래 시스템(100)은 다수의 음성-처리 모듈(102)과, 각각의 음성 처리 모듈(102)에 할당된 다수의 전화 라인(104)을 포함한다. 음성 처리 모듈(102)은 다수의 클라이언트(106)와 한개의 음성 처리 서버(108)를 또한 포함한다. 시스템(100)은 음성 인지 서버에 음성 인지 요청을 할당하기 위해 "라운드 로빈(round robin)" 전략을 이용한다. 이 구조에서, 음성 처리 모듈(102)의 클라이언트(106) 중 하나가 유입 전화 라인(104) 중 하나를 통해 음성을 수신한다. 음성을 수신한 클라이언트(106)에는 음성 처리 서버(108)가 미리 할당되어 있다.
시스템(100)은 상기 음성 처리 모듈 상의 현 부하에 상관없이 라인의 다음음성 처리 모듈(102)에 호출(call)이 도달하면 시스템(100)이 호출을 할당하기 때문에 "라운드 로빈" 전략을 구현한다. 이 종래 시스템(100)은 시스템 부하나 메시지 종류에 따른 사용상의 변화를 제시하지 못한다. 이러한 시스템에서는 무력한 작업흐름 할당으로 인한 효율 손실이 나타날 수 있다. 이 종래 시스템은 특정 서버들의 서로 다른 능력을 제시하지 않는다.
도 1에서 설명되는 간단한 라운드-로빈 시스템의 비효율성을 인식함으로서, 도 2는 이 결함을 치유하고자 시도하는 음성 인지 응용프로그램의 서비스 프로그램 멀티플렉싱을 위한 또다른 기존 접근법을 도시한다. 이 구조(200)에서는 한개 이상의 응용프로그램(210)이 다수의 스피치 인지 서버(218)(즉, 서비스 프로그램) 중 하나로부터 서비스를 필요로한다. 서버(218) 중 하나에 대한 접근을 얻기 위해, 서버(218)를 필요로하는 응용프로그램(210)이 버스(240) 상에서 메디에이터(mediator)(206)와 대화한다. 메디에이터(206)는 호출 감지 및 스피치 중단점 표시(즉, 종료 표시)처럼 응용프로그램의 여러 표준 전화통신 태양을 제어한다. 메디에이터(206)는 버스(242) 상에서 리소스 관리자(214)와 또한 대화한다. 리소스 관리자(214)의 주된 작업은 주어진 응용프로그램 요청에 대한 스피치 인지 서버(218)의 적절한 사례를 식별하는 것이다. 다시 말해서, 메디에이터(206)는 서버(218) 중 하나에 대한 접근을 요청하는 응용프로그램(210)으로부터 요청을 수신한다. 메디에이터(206)는 이 요청을 리소스 관리자(214)에 전송하여, 서버(218) 중 하나에 접근을 제공한다.
상기 요청을 만족시키기 위해 요구되는 메시지 종류, 특히 리소스를 바탕으로, 구조(200) 내 서버(218)의 현 부하와 함께, 리소스 관리자(214)는 스피치 인지 서버(218)의 사례 중 어느 것이 가장 적절한 지를 결정한다. 메시지 종류를 검사할 때, 리소스 관리자(214)는 각각의 스피치 인지 서버(218)의 음성을 처리하기 위해 필요한 문법, 의문스런 문법에 대한 각각의 스피치 인지 서버(218)의 처리 능력, 그리고 각각의 스피치 인지 서버(218)의 자유 처리 용량을 평가할 수 있다. 스피치 인지 서버(218)가 주어진 호출에 할당될 경우, 이 리소스 관리자(214)는 버스(246)를 통해 스피치 인지 서버(218)와 통신할 것이고, 서버(218)를 필요로하는 응용프로그램(210)은 메디에이터(206)와 통신하기 위해 버스(240)를 이용함으로서 서버(218)와 통신하며, 이때 상기 메디에이터(206) 역시 서버(218)와 통신하기 위해 버스(244)를 이용한다.
이 종래 구조는 동종의 다중 서비스, 즉, 스피치 인지 서버(218)와는 다른 다중 서비스를 제시하지 못한다. 스피치 인지 서버(218)는 멀티플렉싱된 리소스일 뿐이다. 다시 말해서, 이 기존 시스템은 단일 응용프로그램에 대해 다수의 서로 다른 서비스를 멀티플렉싱하려 시도하지 않는다. 본 예에서, 종래 시스템은 수많은 스피치 인지 서버(218)를 멀티플렉싱하지만, 수많은 스피치 인지 서버(218)를 수많은 이미징 서버, 그 외 다른 스피치 응용프로그램 관련 서버, 또는 그 외 다른 비-스피치 응용프로그램 서버와 멀티플렉싱하려 시도하지 않는다.
추가적으로, 시스템 서브-구성성분간 연결이 고정된다. 이 연결들은 응용프로그램(210)과 메디에이터(206)간 버스, 메디에이터(206)와 리소스 관리자(214)간 버스(242), 메디에이터(206)와 스피치 인지 서버(218)간 버스(244), 그리고 리소스관리자(214)와 스피치 인지 서버(218)간 버스(246)를 포함한다. 이 연결들은 큰 응용프로그램 공간에서 호환하여 사용될 수 없고, 분산형, 비-국부 네트워크에서 실용적이지 않을 것이다.
더욱이, 할당될 리소스가 동적이지 않다. 고정된 세트의 리소스가 초기 설정에서 규정된다. 고정된 연결은 높은 대역폭이나 낮은 시스템 생산성을 필요로한다. 더욱이, 기존 시스템, 특히 스피치 인지 시스템은 로드 밸런싱(load balancing)이나 응용프로그램(210) 동적 할당을 제시하지 못한다.
이 기존 시스템은 문법 종류, 특정 문법을 가진 스피치 인지 서버 능력, 그리고 현 처리 용량과는 다른 리소스 종류를 제시하지 못한다. 응용프로그램과 응용프로그램이 동작하는 환경에 따라, 로드 밸런싱 및 동적 시스템 조성에 있어 중요할 수 있는 앞서와는 다른 리소스들이 폭넓게 존재한다.
기존 전화통신은 회로-스위칭 기반 네트워크로부터 패킷 기반 네트워크로의 스위칭이다. OSI(Open System Interconnection)는 여러 다른 호스트 상에서 협력작용하는 응용프로그램간의 호스트-호스트 데이터 전송을 지원하는 한가지 특히 유용한 디지털 데이터 통신 프로토콜이다(별개의 호스트 사이를 프로토콜이 규정할 때, 협력작용하는 응용프로그램들은 동일 호스트 상에 위치할 수 있다). 그러나 통상적으로, VoIP(Voice over Internet Protocol)에 대한 패킷-기반 네트워크는 전통적인 TCP/IP(Transmission Control Protocol/Internet Protocol)을 이용하여 기능하도록 설계된다. TCP/IP는 OSI 시스템으로 매핑되지 않는다. 특히, 패킷 기반의 기존 TCP/IP는 전송되어야 하는 다중 매체에 대한 실시간 전송의 제시나작업시간(session)(호출 제어)을 적절하게 규정하지 않는다.
추가적으로, 기존 연결들이 사용자 데이터그램 프로토콜(UDP)인지, 전송 제어 프로토콜(TCP)인지, 또는 또다른 프로토콜인 지와 같이 프로토콜 의존적인 경향이 있다. 따라서, 가령, UDP를 이용하는 서비스나 응용프로그램은 TCP를 이용하여 전송하는 요청자와 함께 동작할 수 없다.
따라서, 프로토콜 독립 원칙 하에 여러 서버를 멀티플렉싱할 수 있으면서 공지 기술에서 식별된 이들 문제점 및 그 외 다른 문제점을 해결하는 구조를 발전시키는 것이 바람직하다.
본 발명은 제어 모듈을 이용한 응용프로그램 및 서비스 서버의 방향 설정, 관리, 그리고 접근에 관한 것이고, 관리, 동적 리소스 할당, 그리고 로드 밸런싱(load balancing) 제공에 관한 것이다. 특히, 본 발명은 매체 작업시간 틀(media session framework)의 일부로 프로토콜 독립형 서비스 콘트롤러를 이용하여 한개 이상의 처리 유닛이나 서버에 위치하면서 처리 장치나 서버 사이에 만족할만한 로드 밸런싱을 유지하는 응용프로그램 및 호출(call) 서비스에 대하여 동적으로 접근하고 이를 이용한다.
도 1은 서비스 프로그램 분산을 위한 기존 시스템의 블록도표.
도 2는 기존 스피치 인지 시스템의 블록도표.
도 3은 본 발명에 따른 네트워크 구조의 블록도표.
도 4는 본 발명에 따른 네트워크 구조의 도면.
도 5는 도 3에 도시되는 매체 서버(308)의 블록도표.
도 6은 도 3에 도시되는 매체 서버(308)의 또다른 블록도표.
도 7은 본 발명에 따른 호출 설정 과정의 순서도.
도 8은 본 발명에 따른 SIP 신호전송 구축을 설명하는 순서도.
도 9는 본 발명에 따르는 매체 서버(308)를 통한 아웃바운드 처리 및 인바운드 처리 개시를 설명하는 순서도.
도 10은 도 3에 도시되는 제어 모듈(310)의 블록도표.
도 11은 본 발명에 따라 서비스 프로그램을 응용프로그램에 동적으로 할당하는 과정의 작업 순서도.
도 12는 본 발명에 따르는 과정 모니터 서비스의 블록도표.
도 13은 도 12에 도시되는 과정 모니터와 박스 모니터간 대화의 블록도표.
도 14는 본 발명에 따르는 트래킹 로깅(tracking logging) 및 어카운팅 작용(accounting operation)의 블록도표.
도 15는 "OSI"와 "TCP/IP"의 수직구조를 예시한 블록도표.
도 16은 본 발명에 따르는 매체 작업시간 틀을 설명하는 블록도표.
도 17은 본 발명에 따르는 매체작업시간 틀을 통합한 프로세서(1700)의 도면.
도 18은 서비스 콘센트레이터(1712)의 상세도.
도 19는 본 발명에 따르는 프로토콜 독립형 제어 모듈의 기능 블록도표.
도 20은 작업시간 층 신호전송 프로토콜(1906)의 상세도.
도 21은 작업시간 메시지 프로세서(1908)의 상세도.
도 22는 본 발명엔 따르는 프로토콜 독립형 제어 모듈을 이용한 시스템의 기능 블록도표.
도 23은 본 발명에 관련된 한가지 가능한 방법의 순서도(2300).
도 24는 본 발명에 따르는 기능 블록도표.
본 발명의 목적에 따라 본 발명의 장점을 얻기 위해 응용프로그램의 멀티플렉싱 방법이 제공된다. 특히, 한개 이상의 응용프로그램에 접근하는 한개 이상의 접근 서버가 제공된다. 한개 이상의 응용프로그램에 접근하기 위해 접근 서버에서 한 명 이상의 사용자로부터의 요청이 수신된다. 수신한 요청에 따라, 한개 이상의 접근 서버와 한 명 이상의 사용자 사이에 통신 링크가 구축되고, 수신된 요청은 입력 요청 큐에 저장된다. 요청받은 응용프로그램으로의 통신 경로가 가용한 지가 확인되고, 통신 경로가 가용할 경우 입력 요청 큐와 한개 이상의 응용프로그램 사이에 통신 경로가 구축되고, 저장된 요청이 제거되어 요청받은 응용프로그램에 전달된다.
본 발명은 서비스 멀티플렉싱용 장치를 또한 제공한다. 이 장치는 한개 이상의 응용프로그램에 대한 접근을 제공할 수 있는 한개 이상의 접근 서버를 포함한다. 한개 이상의 접근 서버는 한개 이상의 에이전트(agent)와 한개 이상의 서비스 콘센트레이터(service concentrator)를 포함한다. 서비스 콘센트레이터는 한개 이상의 응용프로그램 핸들러(application handler), 한개 이상의 입력 서비스 큐(input service queue), 그리고 한개 이상의 요청 핸들러(request handler)를 포함한다. 상기 한개 이상의 응용프로그램에 접근하기 위한 다중 요청을 상기 한개 이상의 접근 서버가 수신하게 되고, 상기 한개 이상의 응용프로그램에 접근하기 위한 다중 요청을 상기 한개 이상의 서비스 콘센트레이터가 멀티플렉싱하게 된다.
본 발명은 한개 이상의 응용프로그램으로의 접근을 위한 한개 이상의 요청을 제어하는 데이터를 처리하기 위해 내장된 컴퓨터 판독 코드를 포함한 컴퓨터 이용 매체를 가진 컴퓨터 프로그램 프로덕트를 또한 제공한다. 컴퓨터 이용 매체는 한개 이상의 응용프로그램으로의 접근을 위한 한개 이상의 요청을 수신하도록 설정된 요청 수신 모듈을 포함한다. 한개 이상의 응용프로그램으로의 접근을 요청하는 한 개 이상의 클라이언트와의 통신 링크를 구축하도록 설정된 통신 구축 모듈에서 이 요청이 수신된다. 한개 이상의 수신 요청을 저장하도록 저장 모듈이 설정되고, 한개 이상의 응용프로그램으로의 접근을 행할 수 있게 하는 통신 경로인 지를 확인하도록 확인 모듈이 설정된다. 상기 한개 이상의 응용프로그램과의 통신 링크 구축을 위해 통신 구축 모듈이 추가로 설정된다.
도 3은 본 발명의 한 실시예를 도시한다. 특히, 도 3은 본 발명의 한 실시예에 따른 네트워크 구조(300)를 도시한다. 구조(300)는 공중 스위칭 전화통신망(PSTN)(304)과 매체 서버(308) 사이에 인터페이스를 제공하는 전화통신 보드(306)를 포함한다. 다시 말해서, 도 3은 본 발명에 따르는 서버 내에 위치하는 응용프로그램에 표준 PSTN(304) 상에서 호출(call)을 위치시키는 것을 도시한다. 구조(300)는 전화통신 보드(306)와 매체 서버(308)에 부가하여, 제어 모듈(310), 한개 이상의 응용프로그램(312), 그리고 한개 이상의 서비스 프로그램(314)을 포함한다. 구조(300)의 각 부분이 서로 별개인 구분된 것으로 도시되지만, 단일 서버처럼 한 처리 장치 내에 이 부분들이 통합내장될 수도 있다. 게다가, 이 부분들 한 중앙 위치에 놓일 수도 있고, 다수의 원격 위치에 산개되어 위치할 수도 있다. 소프트스위치로 대체할 수 있는 매체 서버를 도면 등에서 발견할 수 있다. 소프트스위치는 종래의 하드웨어 텔레콤 스위치와 동일한 기능을 수행하는 소프트웨어 프로그램이다. 소프트스위치는 매체 서버(308)같은 기능을 수행할 수도 있으나, 일반적으로 대형의 캐리어 그레이드 환경에 대해 만들어진다. 매체 서버나 매체 게이트웨이가 소형, 저비용 환경에 보다 적절하다.
실행 중에, 사용자는 표준 전화(302)로부터 표준 전화 번호로의 호출(call)을 실행한다. 이 표준 전화번호는 전화통신 보드(306)에 등록하기 위해 할당된다. PSTN(304)은 전송용으로 수많은 전화 라인을 멀티플렉싱하는 T-1, DS3, 또는 유사 트렁크 라인의 일부로, 전화(302)로부터 (상기 전화 번호를 수신하도록 설정되는) 전화통신 보드(306)에게로 종래 방식으로 호출을 이동시킨다. 전화통신 보드(306)는 종래 방식으로 하드웨어 수준에서 (호출 감지 및 종료같은) 표준 호출 관리를 처리하지만, 전화통신 보드(306)가 소프트웨어를 이용할 수도 있고 소프트웨어와 하드웨어의 일부 조합을 이용할 수도 있다. 실행 중에, 전화통신 보드(306)가 호출을 수신할 때, 보드(306)는 이를 매체 서버(308)에 알린다. 매체 서버(308)는 통지를 수신하고, 호출 수신을 위한 가용 포트의 주소를 전화통신 보드(306)에 제공한다. 전화통신 보드(306)는 그후 연결된 호출을 매체 서버(308)의 가용 포트에 전달한다.
매체 서버(308)는 전화통신 보드(306)로부터 호출을 수신하며, 매체 서버(308)가 호출 데이터에 일부 처리를 실행할 수 있다. 그리고 매체 서버가 호출 데이터에 대한 일부 처리를 실행하는 것이 선호된다. 먼저, 호출 신호 처리가 구축되고 그후 매체 연결이 이루어진다.
먼저, 전화통신 보드(306)는 PRI-ISDN 신호처리 프로토콜같은 표준 PSTN 신호처리 프로토콜을 이용하여, 또는 종래 방식으로 전화통신 보드(306)에 의해 조작되는 바와 같이 상기 신호처리 프로토콜 버전을 이용하여, 통신 채널(322) 상에서 호출 데이터를 매체 서버(308)의 입력 포트에 전달한다. 매체 서버(038)의 입력 포트는 전화통신 보드(306)에 의해 표준 PSTN 신호 프로토콜을 수신하도록 포맷된다. 매체 서버(308)는 PRI-ISDN 신호처리 데이터를 표준 인터넷 프로토콜, 특히 SIP(Session Initiation Protocol) 프로토콜(선호됨)로 변환하는 것이 선호된다. 표준 PSTN 신호 프로토콜로부터 SIP 프로토콜로 변환은 도 5-9를 참고하여 더욱 상세하게 설명될 것이다.
두 번째로, 이 프로토콜 변환의 일부로, 매체 서버(308)는 SIP 응용프로그램 INVITE를 발생시켜서 이를 통신 채널(324) 상에서 제어 모듈(310)에 전달한다. 매체 서버(308)에 의해 발생한 SIP 응용프로그램 INVITE는 호출한 전화번호에 대응하며, 응용프로그램(312) 중 하나에 매핑될 수 있다. 더욱이, SIP 응용프로그램 INVITE는 매체 서버(308)의 포트 주소 정보를 내장할 수 있고, 이 주소에 응용프로그램(312)이 연결될 것이다.
제어 모듈(310)은 통신 채널(324) 사에서 수신한 SIP 응용프로그램 INVITE를 검사하여, 응용프로그램(312) 중 어느 것이 호출받은 전화번호에 대응하는 지를 결정한다. 가령, 이 경우에, 호출은 응용프로그램(312) B를 지향한다. 구조(300)의 고유 설정 때문에, 여러 응용프로그램(312) B에 접근할 수 있다. 또한, 응용프로그램(312) B는 여러 다른 처리 유닛 상에서 가용할 수 있고, 이는 여러 다른 국부/원격 위치에 놓일 수 있다. 따라서, 제어 모듈(310)은 종래의 IP 프로토콜 뒤에 이어져서, 응용프로그램(312) B를 실행시킬 수 있고 구조(300) 상에서 접근가능한 하드웨어 플랫폼에서 실행되는 응용프로그램(312) B의 적절한 사례를 놓이게 한다. 제어 모듈(310)이 IP 네트워크 상의 가용 응용프로그램(312) B의 주소나 위치를 식별하면, 제어 모듈(310)은 통신 채널(326) 상에서 SIP 응용프로그램 INVITE를 응용프로그램(312) B의 상기 사례에 전달한다.
응용프로그램(312) B를 요청하는 호출에 관련된 매체 서버(308) 상의 포트 주소처럼 SIP 응용프로그램 INVITE의 정보를 이용하여, 응용프로그램(312) B는 통신 채널(326) 상에서 전달되는 SIP 응용프로그램 INVITE를 수용하고, 매체 서버(308) 상의 적절한 포트로 통신 채널(328) 상에서의 매체 연결을 설정한다. 이제 응용프로그램(312) B는 매체 서버(308)를 통해 통신 채널(328) 상에서 호출자(caller)(302)에게로/로부터 데이터를 전송하고 수신할 수 있고, 이때 매체 서버(308)는 필요한 프로토콜 변환을 실행하며, 통신 채널(322) 상에서 전화통신 보드(306)에, 그리고 마지막으로 통신 채널(320) 상에서 호출자(3020)에게 데이터를 전송할 수 있다. 매체 서버(308)로부터 제어 모듈(310)까지의 통신 채널(324)과 제어 모듈(310)로부터 응용프로그램(312) B까지의 통신 채널(326)이 액티브하게 유지되어, 아래에 설명될 제어 기능을 제공한다.
제어 모듈(310)은 한 순간에 지닌 최적의 정보를 이용하여 응용프로그램(312) B의 특정 사례를 선택한다. 응용프로그램(312) B가 SIP 응용프로그램 INVITE를 실제로 수신할 때까지, 그 상황이 변화하여 더 이상 가용하지 않을 수 있다. 이 경우에, 응용프로그램(312) B는 SIP 응용프로그램 INVITE를 거절한다. 첫 번째 식별된 응용프로그램(312) B가 SIP 응용프로그램 INVITE를 거절하면, 제어 모듈(310)은 SIP 응용프로그램 INVITE를 다음 최적의 가용 응용프로그램(312) B로 전송함으로서 가용 리소스 검색을 계속한다. 제어 모듈(310)이 응용프로그램(312) B의 가용 사례를 식별할 수 없을 경우, 제어 모듈(3100은 사용자에게 추후 호출이나 보류를 알리는 표준 응답을 발생시킬 수 있다.
호출자와의 대화 중 어떤 시점에서, 응용프로그램(312) B는 서비스 프로그램 X, Y, Z같은 가용 보조 서비스 프로그램(314) 중 하나가 필요한 지를 결정할 수 있다. 이 서비스 프로그램(314)들은 응용프로그램(312) B와 같은 처리 유닛 내에 위치할 수도 있고, 이격된 위치의 별개의 처리 유닛에 위치할 수도 있다. 요청받은 서비스 프로그램(314)에 대한 접근을 얻기 위해, 응용프로그램(312) B는 서비스 프로그램(314) Y처럼 가용 서비스 프로그램(314) 중 하나에 접근하기 위해 통신 채널(326) 상에서 SIP 서비스 INVITE를 제어 모듈(310)에 전송한다. SIP 응용프로그램 INVITE에서처럼, 제어 모듈(310)은 SIP 서비스 INVITE를 수신하고, 구조(300) 상에서 접근가능한 서비스 프로그램(314) Y를 실행할 수 있는 하드웨어 플랫폼 상에서 실행되는 서비스(314) Y의 적절한 사례를 위치시킨다. 제어 모듈(310)이 IP 네트워크 상에서 가용 서비스 프로그램(314) Y의 주소나 위치를 식별하면, 제어 모듈(310)은 SIP 서비스 INVITE를 통신 채널(330) 상에서 서비스 프로그램(314) Y의 상기 사례에 전달한다. 서비스 프로그램(34) Y는 국부적인 위치나 이격된 위치에 놓일 수 있다.
서비스 프로그램(314) Y를 호출하고 있는 응용프로그램(312) B의 주소와 응용프로그램(312) B에 접근하는 매체 서버(308)의 포트 주소처럼 SIP 서비스 INVITE의 정보를 이용하여, 서비스 프로그램(314) Y는 통신 채널(330) 상에서 전달된 SIP 서비스 INVITE를 수용하고, 응용프로그램(312) B에 되돌아가는 통신 채널(332) 상에서, 그리고 매체 서버(308) 상의 적절한 포트에 되돌아가는 통신 채널(334) 상에서 매체 연결을 설정한다. 응용프로그램(312) B는 이제 서비스 프로그램(314) Y와 통신할 수 있고, 서비스 프로그램(314) Y는 호출자(302)와 통신할 수 있다. 예를 들어, 서비스 프로그램(314) Y는 텍스트-스피치 서비스일 수 있고, 응용프로그램(312) B는 음성 응용프로그램일 수 있다. 본 예에서, 응용프로그램(312) B는 텍스트-스피치 변환을 위해 통신 채널(332) 상에서 텍스트를 서비스 프로그램(314) Y에 전달할 수 있다. 서비스 프로그램(314) Y는 이 요청을 처리할 수 있고, 통신 채널(334) 상에서 매체 서버(308)를 통해 이동하는 상기 변환의 스피치나 오디오 결과를 호출자(302)에게 전송할 수 있다.
서비스 프로그램(314) Y와 응용프로그램(312) B 간의 작업시간 구축이 아래에 설명된다(도 11). 서비스 프로그램과 응용프로그램간 상호연결은 일례로 든 것으로, 매체 서버(308), 제어 모듈(310), 응용프로그램(312), 그리고 서비스 프로그램(314) 중 어느 것 사이에서의 상호연결 구축의 어떤 조합에도 본 발명의 작업시간 형태가 적용될 수 있다.
도 4는 본 발명의 한 실시예에 따르는 네트워크 구조(400)를 도시한다. 도 4는 본 발명에 따라 표준 인터넷 프로토콜(IP) 네트워크(404) 상에서 호출을 서버 내에 위치하는 응용프로그램에 위치시키는 것을 도시한다. 도 3에서는, 호출이 표준 PS수 신호처리 프로토콜(PRI-ISDN)과 전송 프로토콜(펄스 코드 변조-PCM)를 이용하여 종래의 PSTN 상에서 위치한다. 이들은 각각 SIP 및 실시간 전송 프로토콜(RTP)로 변환되어야 한다. 매체 서버(308)는 이 두 변환을 모두 실시하고, 전화(302)의 호출자와, 제어 모듈(310), 응용프로그램(312), 그리고 서비스 프로그램(314)간에 인터페이스로 나타난다. 제어 모듈(310), 응용프로그램(312), 그리고 서비스 프로그램(314) 모두는 SIP 신호처리 및 RPT 전송 프로토콜을 이용하여 통신한다. 그러나 도 4에서는 호출자가 SIP에 의해 실행되는 연산 장치(402)를 이용하여, IP 네트워크(404)에 호출(또는 요청)을 위치시킨다. 이 연산 장치(402)는 컴퓨터일 수도 있고, SIP에 의해 실행되는 전화일 수도 있으며, SIP에 의해 실행되는 또다른 연산장치일 수도 있다. 따라서, 장치(402)는 신호처리용 SIP와 매체 전송용 RTP를 먼저 이용하여, 신호처리 변환을 실행하기 위해 매체 서버나 다른 인터페이스를 통해 호출이 이동할 필요가 없게 한다. 다른 측면에서, 도 4에서의 호출 과정은 도 3에서와 같다. 장치(402)가 IP 전화통신에 의해 실행되지만 SIP용으로 설정되지 않았을 경우, 매체 서버는 IP 전화통신 실행 장치를 SIP 신호로 변환하는 데 사용될 수 있을 것이다.
그러나 설명의 명료함을 위해, 구조(400)의 동작과정이 충분하게 설명될 것이다. 구조(400)는 제어 모듈(310), 한개 이상의 응용프로그램(312), 그리고 한개 이상의 서비스 프로그램(314)을 포함한다. 실행 시에, 사용자는 컴퓨터 기반 전화나, 표준 SIP 신호처리 프로토콜을 이용하는 타연산 장치일 수 있는 호출 장치(402)로부터 호출을 한다. 장치(402)가 SIP 포맷 신호를 생성하고 매체 전송이이미 RTP이기 때문에, 프로토콜 및 전송 변환을 위해 매체 서버(308)를 통해 호출이 이동할 필요가 없다. 따라서, 호출 장치(402)는 SIP 응용프로그램 INVITE를 잘 알려진 SIP 주소로 전송한다. 이 주소는 특정 종류의 응용프로그램에 관련된 것이다. 호출은 IP 네트워크(404) 상에서 이동한다. IP 네트워크(404)는 호출 장치(402)를 제어 모듈(310)에 연결하는 통신 채널(422)을 포함한다. 물론, 통신 채널(422)은 보기 편리하게 도시되었다. 왜냐하면, 표준 인터넷 프로토콜이 패킷 전송을 이용하고 호출 장치(402)로부터의 데이터는 여러 루트나 채널 상에서 제어 모듈(310)의 IP 연결에 도달하기 때문이다. 제어 모듈(310)은 도 3에서처럼 호출을 이동시킨다. 제어 모듈(310)은 통신 채널(422) 상에서 수신한 SIP 응용프로그램 INVITE를 검사하고, 응용프로그램(312) 중 어느 것이 SIP 응용프로그램 INVITE의 SIP 주소에 대응하는 지를 결정한다. 예를 들어, 이 경우에 호출은 응용프로그램(312) B용으로 의도된 것이다.
제어 모듈(310)은 구조(400) 상에서 접근가능한 응용프로그램(312) B를 실행할 수 있는 하드웨어 플랫폼에서 실행되는 응용프로그램(312)의 적절한 사례를 위치시킨다. 이는 종래의 IP 프로토콜 다음에 이어진다. 제어 모듈(310)이 IP 네트워크 상에서 가용 응용프로그램(312) B의 주소나 위치를 식별하면, 제어 모듈(310)은 통신 채널(326) 상에서 SIP 응용프로그램 INVITE를 응용프로그램(312) B의 상기 사례에 전송한다.
응용프로그램(312) B를 이용하기 위해 호출하고 있는 호출 장치(402)의 URL 주소같은 SIP 응용프로그램 INVITE의 정보를 이용하여, 응용프로그램(312) B는 통신 채널(326) 상에서 전송된 SIP 응용프로그램 INVITE를 수용하고, 통신 채널(426) 상에서 호출 장치(402)에 대한 매체 연결을 설정한다. 응용프로그램(312) B는 이제 통신 채널(426) 상에서 호출자(402)에게로 데이터를 송신할 수 있고 호출자(402)로부터 데이터를 수신할 수 있다. 호출 장치(402)로부터 제어 모듈(310)에게로의 통신 채널(422)과, 제어 모듈(310)로부터 응용프로그램(312) B까지의 통신 채널(326)이 액티브하게 유지되어, 아래에 상세하게 설명되는 것과 같은 제어 기능을 제공한다.
도 3에서처럼, 제어 모듈(310)은 한 순간에 취하는 최적의 정보를 이용하여 응용프로그램(312) B의 특정 사례를 선택한다. 응용프로그램(312) B가 SIP 응용프로그램 INVITE를 수신할 때까지, 더 이상 가용해지지 않도록 그 상황이 변경될 수 있다. 이 경우에, 응용프로그램(312) B는 SIP 응용프로그램 INVITE를 거절한다. 첫 번째 식별된 응용프로그램(312) B가 SIP 응용프로그램 INVITE를 거절할 경우, 제어 모듈(310)은 그다음번 최적의 가용 응용프로그램(312) B에게 SIP 응용프로그램 INVITE를 전송함으로서 가용 리소스에 대한 검색을 계속할 것이다. 어떤 응용프로그램(312) B도 가용하지 않을 경우, 사용자에게 추후 호출이나 보류를 알리는 표준 응답이 발생될 수 있다.
호출자(402)와의 대화 중 어떤 순간에, 응용프로그램(312) B는 서비스 프로그램 X, Y, Z같은 가용 보조 서비스 프로그램(314) 중 하나를 필요로하는 지를 결정할 수 있다. 응용프로그램(312) B는 도 3에 연계하여 앞서 설명한 바와 같이 보조 서비스 프로그램에 접근할 수 있다. 그러나, 서비스 프로그램(314)이 SIP 서비스 INVITE를 수용할 때, 서비스 프로그램(314)은 매체 서버(308)처럼 중간 매체를 통한 이동 대신에, 통신 경로(432)를 이용하여 호출 장치(402)에 직접 연결되도록 호출 장치(402)의 URL 주소를 이용할 것이다. 따라서, 응용프로그램(312) B가 서비스 프로그램(314) Y와 통신할 수 있고, 서비스 프로그램(314) Y가 호출 장치(402)와 통신할 수 있다. 예를 들어, 서비스 프로그램(314)은 텍스트-스피치 서비스일 수 있고, 응용프로그램(312) B는 음성 응용프로그램일 수 있다. 본 예에서, 응용프로그램(312) B는 텍스트-스피치 변환을 위해 통신 채널(430) 상에서 서비스 프로그램(314) Y에 텍스트를 전송할 수 있다. 서비스 프로그램(314) Y는 통신 채널(432) 상에서 호출자(402)에게 상기 변환의 스피치나 오디오 결과를 전송할 수 있다.
도 5와 6은 본 발명의 한 실시예에 따르는 매체 서버(308)에 대한 내부 구조(500)를 도시한다. 앞서 언급한 바와 같이, 매체 서버(308)의 기능 중 하나는 프로토콜 변환을 실행하는 것이다. 매체 서버(308)는 따라서 펄스 코드 변조(PCM) -> 실시간 전송 프로토콜(RTP) 변환 섹션(308A)과 PRI-ISDN -> SIP 변환 섹션(308B)을 가진다. 도 6을 참고하여, 이 변환들이 더 상세하게 설명될 것이다.
도 6에 도시되는 바와 같이, PCM -> RTP 변환 섹션(308A)은 엔드포인트 관리자(504)와 한개 이상의 트랜슬레이터 핸들러(506)를 포함하지만, 도 6에 도시되는 바와 같이, 매체 서버(308) 내의 한개의 트랜슬레이터 핸들러는 전화통신 보드(306) 상에서 각각의 포트에 대해 존재하는 것이 선호되며, 이때 전화통신 보드(306) 상의 각각의 포트는 전화 라인에 대응한다. 따라서, 24포트 전화통신보드(306)를 지원하는 매체 서버(308)는 트랜슬레이터 핸들러(5061-50624)를 가질 것이다. 각각의 트랜슬레이터 핸들러(506)는 G.711 송신기(510)와 G.711 수신기(508)를 또한 포함한다. G.711 표준의 사용은 예시적인 것이며, 다른 표준이 마찬가지로 사용될 수 있다. 매체 서버(308)는 보드 콘트롤러(502)를 또한 포함한다. 보드 콘트롤러(502)는 매체 서버(308)와는 별도의 실체로 나타나지만, 매체 서버(306)와 일체로 형성될 수도 있다. 이것은 설계상의 문제이다. 트랜슬레이션 핸들러(506)가 구성성분들로 나타날 때, 요구대로 핸들러를 발전시키는 소프트웨어를 이용하는 것이 선호된다.
도 6에 도시되는 바와 같이, PRI-ISDN -> SIP 변환 섹션(308B)은 보드 호출 제어 이벤트 핸들러(BCCEH)(512), SIP 관리자(514), SIP 사용자 에이전트(SUA)((516), 그리고 PRI-ISDN -> SIP 트랜슬레이터(518)를 포함한다.
도 7은 호출 설정 과정, "매체 서버의 호출 설정(Call Setup in the Media Server)"을 나타내는 순서도(700)이다. 전화통신 보드(306)가 호출을 수신하면, 보드(306)는 호출 신호를 보드 콘트롤러로 전달한다(단계 702). 보드 콘트롤러(502)의 특징은 전화통신 보드(306)의 하드웨어에 따라 변화할 것이다. 현 보드에 대한 여러 경우, 이는 C 다이너믹 링크일 것이지만 이는 한 예에 불과하다.
보드 콘트롤러(502)는 호출을 수신하고, 호출이 있었음을 나타내는 이벤트를 보드 호출 제어 이벤트 핸들러(512)에 전달한다(단계 704). 보드 호출 제어 이벤트 핸들러(512)는 호출 설정, 호출 제거, 그리고 그 외 다른 호출 제어를 조율하는 데책임이 있는 SIP 관리자(514)에게 신호를 보낸다(단계 706). SIP 관리자(514)는 엔드포인트 관리자(504)에게 G.711 수신기(508) 생성을 요청한다(단계 708).
SIP 관리자(514)로부터 이 요청을 수신하면, 엔드포인트 관리자(504)는 트랜슬레이터 핸들러(5061)를 생성하고(단계 710), 이어서 트랜슬레이터 핸들러(5061) 내부에 G.711 수신기(508)를 생성한다(단계 712). 트랜슬레이터 핸들러(5061)는 트랜슬레이터 핸들러(5061)가 G.711 수신기(508)를 생성하지만(단계712), SIP 신호처리가 적절하게 구축되고 트랜슬레이터 핸들러(5061)가 시작될 때까지는 트랜슬레이터 핸들러(5061)가 G.711 수신기(508)를 시작하지 못한다. 엔드포인트 관리자(504)는 트랜슬레이터 핸들러(5061)를 생성하고(단계710), 트랜슬레이터 핸들러(506)는 종래 방법을 이용하여 G.711 수신기(508)를 생성한다(단계 712). G.711 수신기(508)는 응용프로그램(312)으로부터 데이터를 "수신"하여, 이를 호출자(302)에게 전송한다. 이를 "아웃바운드 과정(outbound operation)"이라 부른다. 마찬가지로, G.711 송신기(510)는 이때 아직 생성되지 않은 것으로, 호출자(302)로부터 데이터를 수신할 것이고, 이를 응용프로그램(312)에 "송신"할 것이다. 이는 "인바운드 과정(inbound operation)"이라 불린다.
G.711 수신기(508)의 생성의 일부로서, 그러나 수신기 시작 이전에, G.711 수신기(508)는 매체 서버(308)에 RTP와 RTCP용 포트를 개방한다. 이들은 아웃바운드 과정을 위해, 즉, 데이터를 호출자에게 전송하기 위해 연결을 구축할 때 응용프로그램(312)이 사용할 포트이다. 포트들은 각각의 호출에 대해 동적으로 할당된다. 어떤 플랫폼이 포트를 구축하거나 할당하고 있을 때, 이 포트들은 가용 포트의 풀로부터 끌어오는 것이 선호되지만, 새로이 생성될 수도 있다.
G.711 수신기(508)가 생성된 후, 도 8의 순서도(800)을 참고하여 아래에 상세하게 설명되는 바와 같은 SIP 신호처리가 구축된다(단계 716).
SIP 신호처리가 아래 순서도(800)처럼 구축된 후, SIP 관리자(514)는 트랜슬레이터 핸들러(5061) 시작을 엔드포인트 관리자(504)에게 요청한다(단계716). 트랜슬레이터 핸들러(5061)는 먼저 G.711 수신기(508)를 시작하고(단계 718), 이때 G.711 수신기의 포트들은 응용프로그램(312)에 연결된다. G.711 수신기(508)는 응용프로그램(312)으로부터 호출 장치까지 데이터 패킷 헤딩에 대한 RTP 포트로의 리스닝을 시작한다.
그후 트랜슬레이터 핸들러(5061)는 G.711 송신기(510)를 생성한다(단계720). G.711 송신기(510)는 호출자(302)로부터 응용프로그램(312)까지 데이터를 전송할 것이다. SIP 신호처리를 구축하기 위한 최종 SIP 메시지에서, 응용프로그램(312)은 호출자로부터 데이터를 수신할 포트를 표시하였다. G.711 송신기(510)는 포트를 구축하여, SIP 메시지에 표시되는 응용프로그램(312)처럼 호출자(302)로부터 데이터 수신을 위해 응용프로그램(312)이 구축한 포트로 데이터를 송신한다.
트랜슬레이터 핸들러(5061)는 그후 호출자(302)로부터 응용프로그램(312)까지 전달될 필요가 있는 데이터를 기다리는 G.711 송신기(510)를 개시한다(단계720). G.711 수신기(508)와 G.711 송신기(510)를 시작한 후, 트랜슬레이터 핸들러(506)는 아웃바운드 과정을 시작하고(단계722), 인바운드 과정을 시작하며(단계 724), 이는 순서도(900A와 900B)에 도시된다.
도 8의 순서도(800)는 호출에 대한 SIP 신호처리 구축을 나타낸다. 이는 SIP 신호처리 구축을 위한 표준 과정을 따른다. 첫 번째 단계 중 하나로, 매체 서버(308)는 호출장치(302)가 호출하고 있는 응용프로그램(312)에 대한 SIP 응용프로그램 INVITE를 제어 모듈의 SIP 사용자 에이전트(520)에게 전송하기 위해 SIP 사용자 에이전트(516)를 이용한다(단계 802). 매체 서버(308)는 응용프로그램(312)으로부터 수신한 데이터를 호출자(320)에게 전송하기 위해 G.711 수신기(508)에 의해 개방되는 RTP/RTCP 포트의 IP 주소와 포트 번호를 본 SIP 응용프로그램 INVITE에 포함한다. 이로 인해 응용프로그램(312)이 연결을 구축하게 되고, 이 연결에 의해 매체 데이터를 호출자(302)에게 전송한다.
제어 모듈(310)의 SIP 사용자 에이전트는 SIP 응용프로그램 INVITE를 수신하고(단계 804), 제어 모듈(310)은 도 3과 4에 도시되는 바와 같은 응용프로그램(312) B처럼, 호출 장치(302)가 호출하고 있는 응용프로그램(312)의 적절한 사례를 식별한다(단계 806). 제어 모듈(310)은 SIP 사용자 에이전트(520)를 이용하여, SIP 응용프로그램 INVITE를 요망 응용프로그램(312)의 식별 사례에 전달한다(단계 808). 응용프로그램(112) B의 사례를 호스팅하는 하드웨어 박스의 SIP 사용자 에이전트(522)는 SIP 응용프로그램 INVITE를 수신하고(단계810), 호출을 수용할 수 있는 지 여부를 결정한다(단계 812). (주목: 도 6에서 응용프로그램(312)A, 응용프로그램(312) B, 그리고 응용프로그램(312) C는 각각의 박스에 그 고유 SIP 사용자 에이전트(SUA)(522)를 가지는 형태의 별도의 분리된 하드웨어 박스 사에서 모두 실행되는 것처럼 묘사된다. 실제로, 동일한 하드웨어 박스 상에서 호스팅된 응용프로그램(312)들은 동일한 SIP 사용자 에이전트(522)를 이용한다). SIP 응용프로그램 INVITE를 수용할 수 있는 지 여부를 결정하기 위해, 응용프로그램(312)을 호스팅하는 하드웨어 박스의 SIP 사용자 에이전트(522)는 요망 응용프로그램(312)의 가용 사례가 있는 지, 그리고 매체 서버(308)와 통신할 적절한 가용 포트 세트가 있는 지를 확인한다.
호출을 수용할 수 없는 경우, 하드웨어 박스의 SIP 사용자 에이전트(522)는 SIP 응용프로그램 INVITE를 거절하고(단계812의 'no' 브랜치), 제어 모듈(310)의 SIP 사용자 에이전트(520)는 호출 장치(302)가 호출하고 있는 응용프로그램(312)의 그다음번 최적 사례를 식별하려 시도한다(단계806으로 복귀). 호출을 수용할 수 있는 경우(단계812의 yes 브랜치), 하드웨어 박스의 SIP 사용자 에이전트(522)는 호출자(302)에게 데이터를 전송하기 위한 응용프로그램(312)용 포트를 구축하기 위해 적절한 내부 모듈과 협상한다(단계 814). 데이터를 호출자에게 전송하기 위한 포트는 SIP 응용프로그램 INVITE의 일부분으로 전송된 포트에, 즉, 응용프로그램(312)으로부터 데이터를 수신하고 호출 장치(302)에 전송하기 위해 G.711 수신기(508)가 생성한 포트에, 특별히 연결되도록 상기 포트들을 설정함으로서 구축된다.
하드웨어 박스의 SIP 사용자 에이전트(522)는 호출자(302)로부터 데이터를수신하고자 응용프로그램(312)용 포트를 구축하기 위해 적절한 내부 모듈과 또한 협상한다(단계 816).
응용프로그램(312)이 모든 필요 설정을 마치면, 선택된 응용프로그램(312)에 연계된 하드웨어 박스의 SIP 사용자 에이전트(522)는 200 OK 메시지를 제어 모듈(310) 상의 SIP 사용자 에이전트(520)에 전송한다(단계 818). SIP 사용자 에이전트(520)는 매체 서버(308) 상의 SIP 사용자 에이전트(516)에게 수용허가를 전달한다(단계 820). (SIP 200 OK 메시지는 SIP 표준에 연계된 통상적인 확인 신호이나, 다른 프로토콜 및 협상, 제휴 전략도 물론 적용할 수 있다). 응용프로그램(312)으로부터의 200 OK 메시지는 호출 장치(302)로부터 데이터를 수신하기 위해 응용프로그램(312)이 구축한 매체 포트에 대한 IP/포트 정보를 포함한다(단계 816). 이는 응용프로그램(312)에 연계된 포트 중 어느 것이 호출 장치(302)로부터 데이터를 수신할 지를 매체 서버(308) 상의 트랜슬레이터 핸들러(5061)에게 알려준다. 트랜슬레이터 핸들러(5061)는 이 포트 정보를 이용할 G.711 송신기(510)를 생성한다. G.711 송신기(510)는 호출자(302)로부터 데이터를 수신하기 위해 응용프로그램(312)이 구축한 포트에 연결하기 위한 송신기(510) 포트를 구축한다(단계 822와 단계 720).
아웃바운드 과정은 응용프로그램(312)으로부터 호출 장치(302)까지 RTP 연결 상에서 G.711 수신기(508)를 통해 데이터를 전송한다. 아웃바운드 과정의 특징은 전화통신 보드(306)에 설치된 하드웨어에 따라 변하며, 보드 콘트롤러(502)는 매체서버(308) 상의 G.711 수신기(508)의 RTP 포트로부터 데이터를 판독하는 과정과 이를 전화통신 보드(306)에 기록하는 과정을 포함한다.
통상적으로, 트랜슬레이터 핸들러(506)는 아웃바운드 과정 개시를 위해 보드 콘트롤러(502)에게 호출을 행한다. 현 일부 보드의 경우에, 이 과정의 한 단계는 G.711 수신기(508)와 전화통신 보드(306)간에 데이터를 버퍼링할 것이다. 이것이 하드웨어 보드에 따라 변하지만, 이 과정이 행하여지는 한가지 방식은 전화통신 보드(306)가 데이터 버퍼를 판독하게 하고 판독한 데이터의 버퍼를 호출 장치(302)에 전송하도록 하는 것이다.
일부 현 보드에 대한 아웃바운드 과정의 이러한 버퍼링을 위한 한가지 방법이 도 9A의 순서도(900A)에 도시되어 있다. 전화통신 보드(306)가 새 버퍼를 필요로할 때(단계 902), 보드(306)는 엔드포인트 관리자(504)에게 이를 요청하고(단계 904), 이어 트랜슬레이터 핸들러(5061)로부터 데이터의 다음 세그먼트를 요청한다(단계 906). 트랜슬레이터 핸들러(5061)는 응용프로그램(312)에 연결된 g.711 수신기(508)의 RTP 포트로부터 판독함으로서 데이터를 얻는다(단계 908). 이 데이터는 적절히 패키지화되어 전화통신 보드(306)에 전달된다(단계 910).
트랜슬레이터 핸들러(5061)는 인바운드 연산을 또한 시작한다(순서도 700의 단계 718). 인바운드 과정은 G.711 송신기(510)에 대하여 앞서 설명한 RTP 연결에서 호출 장치(302)로부터 응용프로그램(312)까지 데이터를 전송한다. 이 과정은 아웃바운드 과정에 대해 상호적이며, 도 9B의 순서도(900B)에 의해 나타난다.
공중 스위칭 전화통신망(PSTN)(304)과 상호작용하기 위해서는 한 서버에 두 프로토콜 변환이 필요하다. 즉, PRI-ISDN->SIP와, PCM->RTP가 필요하다.
다시 도 6에서, PRI-ISDN으로부터 SIP로의 변환은 전화통신 보드(306)가 ISDN 데이터를 분석하여 헤더 정보 조각을 SIP관리자(514)에게 전송하는 과정으로 시작되는 것이 선호된다. 이 데이터들은 호출자의 전화번호, 호출받는 전화번호, 실제 전화 라인의 번호(가령, T-1의 24개 라인 중 6번 라인), 그리고 이벤트같은 것들을 포함한다. 이벤트는 "새전화", "사용자가 끊은 전화", 그리고 전화 상태 변화를 표시하는 다른 이벤트같은 것들을 포함한다.
SIP 관리자(514)는 여러 용도로 이 정보를 이용한다. 에를 들어, 새 전화의 경우, G.711 수신기(508) 생성을 엔드포인트 관리자(504)에게 요청하여, 어느 전화 라인에서 호출이 진행되고 있는 지를 엔드포인트 관리자(504)에게 알린다. SIP 관리자(514)는 SIP 메시지 전송시 이 정보를 또한 이용한다. 이벤트에 따라, SIP 관리자(504)는 상기 이벤트에 적절한 SIP 메시지 생성을 PRI-ISDN -> SIP 트랜슬레이터(518)에 요청한다. 예를 들어 "사용자가 끈 전화" 이벤트가 SIP BYE 메시지를 나타낼 때 "새 호출" 이벤트는 SIP INVITE 메시지를 나타낼 수 있다.
전형적인 SIP 메시지는 인터넷 엔지니어링 태스크 포스(Internet Engineering Task Force) 내 인터넷 엔지니어링 스티어링 그룹(Internet Engineering Steering Group)이 관리하는 표준 문서 RFC 2543에 설명된 바와 같이 다양한 필드를 가진다. PRI-ISDN -> SIP 트랜슬레이터(518)가 새 메시지를 생성할 때, 이 변환기(518)는 통상적으로, 1) 의도한 수신자의 SIP 주소, 2) 송신할 매체종류, 3) 송신자가 상기 매체 종류를 수신할 포트, 그리고 4) 호출 id를 식별하기 위한 필드를 포함한다.
표준 PSTN 전화번호로부터 SIP 주소로의 변환은 직관적이다. "sip"는 전화번호에 미리 연계되어 있다. 가공의 예로서, Acme 사의 전화번호 202-555-4567는 sip: 으로 변환될 수 있다. 송신할 매체 종류는 잘 알려진 것으로 송신자에 의해 공급된다. 데이터가 수신할 포트의 예가 위에 주어진다. G.711 수신기는 이 포트들을 할당한다. 마지막으로, 호출 id는 각각의 호출을 독자적으로 식별하기 위해 사용되는 내부 구조물이다. PSTN 상에서 들어오는 호출의 경우, 호출 id는 전화통신 보드에 의해 관리되는 전화 라인에 직접 매핑된다.
SIP로부터 ISDN으로의 변환은 상호적이다. SIP 관리자(514)는 전송자와 수신자의 SIP 주소를 표준 전화 번호로 변환한다. SIP 관리자(5140는 호출 id를 전화통신 보드(306) 상의 실제 전화 라인으로 매핑한다. SIP 관리자(514)는 SIP 메시지 종류를 이용하여, 전화통신 보드(306)에 대한 적절한 이벤트를 결정한다. 예를 들어, SIP BYE 메시지가 전화통신 보드(306)에 대한 "전화끊기" 이벤트를 도출할 것이다.
PCM에서 RTP로의 변환은 다음과 같이 진행된다. 매체의 유입 스트림의 경우에, 전화통신 보드(306)는 다수의 채널에 멀티플렉싱된 G.711 데이터를 내장한 PCM 데이터를 수신한다. 전화 보드(306)는 멀티플렉싱을 설명하는 포맷으로부터 특정 전화 라인에 연계된 G.711 데이터를 분리시킨다. 전화통신 보드(306)는 RTP를 이용하여 전송할 수 있는 패킷으로 G.711 데이터를 패키지화하는 엔드포인트관리자(504)에 데이터를 전달한다. 상기 패키지화된 데이터는 G.711 송신기(510)를 통해 응용프로그램(312)에 전달된다.
유출 매체 스트림의 경우에, 이 과정은 상호적이다. 엔드포인트 관리자(504)는 RTP 구조설정을 제거하고, G.711 데이터를 전화통신 보드에 전송하여, 표준 전화 라인 상에서의 멀티플렉싱을 위해 패키지화한다.
도 10은 본 발명의 한 실시예에 따르는 제어 모듈(310)에 대한 내부 구조(1000) 도면이다. 도 10은 도 3의 모든 태양과 동일하며, 제어 모듈(310)이 확대되어 있다. 구조(1000)가 SIP-동작 호출 장치(402)를 이용하여 도 4를 참고하여 도시될 수 있으나, 제어 모듈(310)은 유사하게 동작하며, 따라서 내부 구조(1000)는 표준 전화(302)를 이용하여 응용프로그램(312)에 접근하는 것에 대해서만 설명될 것이다.
도 10은 도 3에 도시되는 구조(300)와 동일한 구성성분을 포함한다. 즉, 호출자(302), 전화통신 보드(306), 매체 서버(308), 제어 모듈(310), 응용프로그램(312), 그리고 서비스(314)를 포함한다. 제어 모듈(310)의 확대도는 그 서브구성성분, 루팅 관리자(1002)와 로케이션 서비스(1004), 그리고 리소스 관리자(1006)간의 상호작용을 도시한다. 다시 말해서, 도 10은 제어 모듈(310)의 내부 루팅 기능에 상세하게 초점을 맞춘, 본 발명에 따른 서버 내에 위치하는 응용프로그램에 표준 PSTN 상의 호출을 위치시키는 과정을 도시한다.
실행 시에, 응용프로그램(312)과 서비스 프로그램(314)은 아래 설명되는 바와 같이 종래 시스템 구조 명세에 따라 과정 모니터 시스템(1200)에 의해 시작된다. 응용프로그램(312)과 서비스 프로그램(314)이 시작된 후, 응용프로그램(312)은 통신 채널(1024) 상에서 신호를 전송함으로서 로케이션 서비스(1004)에 등록하고, 서비스 프로그램(314)은 통신 채널(1026) 상에서 신호를 전송함으로서 로케이션 서비스(1004)에 등록한다. 로케이션 서비스(1004)는 이 신호들을 이용하여 룩업표에 여러 정보 필드를 내장한 데이터베이스를 갱신하고 유지한다(선호됨). 로케이션 서비스(1004) 내 두 필드가 응용프로그램 종류 필드와 URL 주소 필드이다(선호됨). 따라서, 루팅 관리자(1002)는 로케이션 서비스(1004)에 접근하여 상기 응용프로그램(312) 및 서비스 프로그램(314)의 IP 주소를 결정할 수 있다.
응용프로그램(312) 및 서비스 프로그램(314)의 특정 사례(각각 응용프로그램(312) A, B, 또는 C, 서비스 프로그램(314) X, Y, 또는 Z)가 사용됨에 따라, 과정 모니터 서비스(1200)에 액티비티 정보가 전달된다. 과정 모니터 서비스(1200)는 다용도로 이 정보를 이용한다. 이 중 한가지 용도는 하드웨어 및 소프트웨어 이용 정보를 루팅 관리자(1002)에게 가용하게 함으로서, 시스템의 리소스 이용을 최적화하도록 루팅 관리자가 리소스를 할당할 수 있도록 하는 것이다.
도 10에 도시되는 바와 같이, 호출자가 전화(302)를 이용하여 응용프로그램(312) 중 하나에 접근할 때, PSTN(304)은 전화통신 보드(306)을 통해 매체 서버(308)에 호출을 전달하여 도 5-9에서 설명한 프로토콜 변환을 실행하고, SIP 응용프로그램 INVITE를 제어 모듈(310)에 전달한다. 제어 모듈(310)은 프로토콜 처리를 실행하고, 루팅 관리자(1002)는 SIP 응용프로그램 INVITE 요청을 수신한다.
루팅 관리자(1002)와 로케이션 서비스(1004)는 도 10에 제어 모듈(310)의 부속 성분으로 도시된다. 하지만, 이 관계는 설계상의 문제로서 제어 모듈(310)의 내부나 외부적으로 달리 구현될 수 있다. 마찬가지로, 리소스 관리자(1006)가 제어 모듈(310)에 대해 외부적인 것으로 도시되었으나, 이역시 변화할 수 있다.
루팅 관리자(1002)가 단일 실체로 도 10에 제시되었다. 실제로는 루팅 관리자(1002)가 서로 다른 능력을 지닌 서로 다른 종류의 루팅 관리자(1002)를 구현하는 데 사용될 수 있는 응용프로그램 인터페이스(API)를 명시한다. 루팅 관리자는 폭넓은 형태를 취할 수 있다.
한 종류의 루팅 관리자(1002)는 도 1의 종래 시스템의 로드 밸런싱과 유사하게, 응용프로그램(312) 및 서비스 프로그램(314)의 리소스 할당을 위해 간단한 라운드 로빈 알고리즘을 구현할 수 있다. 또하나는 도 2의 종래 시스템처럼 스피치 응용프로그램용 루팅 알고리즘을 이용할 수 있다. 이는 음성을 처리하는 데 필요한 문법, 상기 문법에 대한 여러 다른 스피치 인지 서버의 처리 능력, 그리고 각각의 스피치 인지 서버의 가용 용량에 관한 정보를 통합할 수 있다. 도 2에 대하여 설명된 전략을 이용한 루팅 관리자(1002)는 서비스 프로그램(314)에 대한 요청만을 전달할 수 있을 것이고, 응용프로그램(312)에 대한 요청은 전달할 수 없을 것이다.
루팅 관리자 API를 이용하여 구현될 수 있는 또다른 종류의 루팅 관리자(1002)는 도 12와 13에 설명되는 과정 모니터 시스템(1200)에 의해 누적되는 정보를 이용할 수 있다. 도 10은 과정 관리 시스템(1200)에 의해 수집되는 정보에 인터페이스인 리소스 관리자(1006)와 상호작용하는 이 종류의 루팅 관리자(1002)를설명한다. 그러나, 본 발명의 공개내용을 읽고나면, 응용프로그램(312)과 서비스 프로그램(314)의 균형조정을 위한 여러 다른 루팅 알고리즘을 생성하는 것이 가능하다는 것을 알 수 있을 것이다.
제어 모듈(310)이 프로토콜 처리를 실행한 후, 루팅 관리자(1002)는 이 요청을 수신하여, 호출자(302)가 응용프로그램(312) B의 한 사례를 요청하고 있는 지를 결정한다. 루팅 관리자(1002)는 아래에 설명되는 과정 모니터 시스템(1200)으로부터 축적되는 정보와 루팅 알고리즘을 이용하여, 호출을 전달할, 로케이션 서비스(1004)에 등록된 응용프로그램(312) B의 사례를 결정한다. 루팅 관리자(1002)가 특ㅈ정 응용프로그램(312) B를 결정하면, 루팅 관리자(1002)는 로케이션 서비스(1004)에 내장된 IP 주소 정보를 이용하여, 통신 채널(1002) 상에서 상기 특정 응용프로그램(312) B에 SIP 응용프로그램 INVITE를 전달한다. 앞서 지적한 바와 같이, 루팅 관리자 API에 따라 발전한 여러 다른 종류의 루팅 관리자(1002)가 이 결정을 위해 여러 다른 전략을 이용할 것이다.
루팅 관리자(1002)는 통신 링크(1028) 상에서 리소스 관리자(1006)를 참고함으로서 과정 모니터 서비스(1200)에 의해 누적되는 상세한 하드웨어 및 소프트웨어 이용 정보를 이용한다. 루팅 관리자(1002)에 의한 참고 이후 리소스 관리자(1006)는 응용프로그램(312) B의 모니터된 사례에 대한 하드웨어 및 소프트웨어 이용 정보를 패키지화하여, 루팅 관리자(1002)에 이 정보를 전달한다. 루팅 관리자(1002)는 리소스 관리자(1006)로부터 전달받은 정보를 바탕으로, 요청을 전달할 응용프로그램(312) B의 특정 사례를 결정한다. 리소스 할당시 하드웨어 및 소프트웨어 이용정보를 모두 이용하는 것이 선호된다. 응용프로그램(312) B의 특정 사례가 가용할 수 있지만, 과도하게 이용되어 최소의 메모리, CPU 사이클, 그리고 그 외 다른 하드웨어 리소스만을 가지는 하드웨어 박스 상에 위치할 수 있다. 응용프로그램(312) B의 두 번째 사례가 이용가능할 수 있고, 조금만 사용된 하드웨어 박스 상에 위치할 수 있다. 응용프로그램(312) B의 제 2 사례에 요청을 전달하는 것이 선호된다. 루팅 관리자(1002)가 요청 처리에 적절한 응용프로그램(312) B의 특정 사례를 결정하였을 때, 루팅 관리자(1002)는 링크(1030) 상에서 로케이션 서비스(1004)를 참고하여, 상기 특정 응용프로그램(312) B의 IP 주소와 포트 번호를 결정한다. IP 주소와 포트 번호를 얻으면, 루팅 관리자(1002)는 상기 주소 및 포트 번호를 제어 모듈(310)에 되보내고, 제어 모듈(310)은 식별된 응용프로그램(312) B에 SIP 응용프로그램 INVITE를 전달한다.
응용프로그램(312) 중 하나가 서비스 프로그램(314) 중 하나에 접근을 요청할 때 유사한 과정이 발생한다. SIP 서비스 INVITE가 통신 채널(326)을 따라 제어 모듈(310)에 전달되고, 제어 모듈(310)은 프로토콜 변환을 처리하여, 이 요청을 루팅 관리자(1002)에게 넘긴다. 루팅 관리자(1002)는 요청받은 서비스 프로그램(314)의 종류, 가령, 서비스 프로그램(314) Y를 구축한다. 루팅 관리자(1002)는 응용프로그램(312)에 따라 앞서 설명한 과정과 유사한 방식으로 SIP 서비스 INVITE를 식별하고 전달한다.
특히, 루팅 관리자(1002)는 과정 모니터 서비스(1200)에 의해 누적된 하드웨어 및 소프트웨어 이용 정보를 이용한다. 하드웨어 및 소프트웨어 이용 정보를 얻기 위해, 루팅 관리자(1002)는 통신 링크(1028) 상에서 리소스 관리자(1006)와 협의하여, 요청을 전달할 서비스 프로그램(314) Y의 특정 사례를 식별한다. 협의 중에, 리소스 관리자(1006)는 서비스 프로그램(314)의 모니터 사례에 관하여 하드웨어 및 소프트웨어 이용 정보에 관한 정보를 루팅 관리자(1002)에게 제공하며, 루팅 관리자(1002)는 요청을 전달할 서비스 프로그램(314) Y의 특정 사례를 결정한다.
루팅 관리자(1002)가 요청 처리에 적절한 서비스 프로그램(314) Y의 특정 사례를 결정할 때, 루팅 관리자(1002)는 특정 서비스 프로그램(314) Y의 상기 IP 주소를 알아내기 위해 링크(1030) 상에서 로케이션 서비스(1004)를 참고한다. 루팅 관리자(1002)가 IP 주소를 가지면, 루팅 관리자(1002)는 제어 모듈(310)에 이를 되보내고, 제어 모듈(310)은 서비스 프로그램(314) Y의 상기 사례에 SIP 서비스 INVITE를 전달한다.
본 발명의 고유 시스템 구조에서는 특히 스피치 인지 분야에서 현 구현보다 더 많거나 같은 수의 응용프로그램(312)으로부터 요청을 서비스하게 하는 서비스 프로그램(314)이 점점 줄어 거의 없다. 예를 들어, 서비스 프로그램(314) Y는 A와 B에 동시에 서비스를 제공하는 것처럼 서로 다른 종류의 여러 응용프로그램(312)이나 여러개의 응용프로그램(312) B에 서비스를 제공할 수 있다. 이 특징을 달성하기 위해, 서비스 프로그램이 다중 응용프로그램 및 호출 장치와 상호작용하도록 하기 위해 멀티플렉싱 구성성분이 필요하다.
도 11은 본 발명의 한 실시예에 따라 멀티플렉싱 능력을 묘사하는 한가지 멀티플렉싱 구조(1100)을 도시한다. 멀티플렉싱 구조(1100)는 서비스 프로그램(314)으로 구현되어, 앞서 설명한 바와 같이 서비스 프로그램(314)들이 멀티플렉싱될 수 있다. 구조(1100)는 클라이언트(1102)와 한개 이상의 서비스 구성서분(1124)을 포함한다. 클라이언트(1102)는 본 발명의 한 실시예에 따르는 서버내에 위치하는 (이격되어 있거나 국부적으로 위치하는) 응용프로그램(312)에 대응할 수도 있고, 이러한 서버에 대해 외부적인 (국부적으로 위치하거나 이격되어 위치하는) 다른 종류의 응용프로그램에 대응할 수도 있다.
서비스 구성성분(1124)은 도 3, 4, 10으로부터 서비스 프로그램(314)에 대응한다. 서비스 구성성분(1124)은 SIP 사용자 에이전트(1104) 내에, 가상 포트 관리자(1106), 과정 큐 관리자(1112), 서비스 플랫폼 전용 API(Application Programmer Interface)(1120), 그리고 서비스 플랫폼(1122)을 포함한다. 서비스 플랫폼(1122)은 실제 서비스를 실행하고, 인터넷 상에서 접근하는 시스템에 위치한 서버를 포함한 적절한 소스에 의해 제공될 수 있다.
도 11은 서비스 프로그램(314)으로부터 서비스에 대한 응용프로그램(312)에 의한 요청과, SIP 프로토콜 및 큐-기반 멀티플렉싱 전략을 모두 이용한 요청의 충족을 도시한다. 이 요청 및 요청 충족은 본 발명에 따르는 서버의 범주에서 이루어진다. 클라이언트(1102)는 본 발명에 따르는 서버 내에 위치하는 응용프로그램일 수 있다. 그러나 대안으로, 클라이언트(1102)가 서비스를 요청할 때 서비스 구성성분(1124)이 위치하는 서버에 접근하는 외부 응용프로그램일 수도 있다.
구조(1100)의 각 부부들이 별개의 것으로 도시되지만, 개별 조각들이 단일 서버같은 한 처리 장치 내에 내장될 수도 있고, 여러 처리 장치 내에 내장될 수도있다. 추가적으로, 이 부분들이 하나의 중앙 위치에 놓일 수도 있고, 다수의 이격된 위치 상에서 산개되어 놓일 수도 있다. 전형적인 사용은 클라이언트들이 한 세트의 하드웨어 상의 한 세트의 위치에 놓이고 서비스들이 다른 하드웨어 상의 다른 위치에 놓이는 것이다.
실행 시에, 서비스 구성성분(1124)은 수많은 포트를 가지며, 각각의 포트는 필요에 따라 다수의 클라이언트(1102) 중 하나에 연결된다. 서비스 구성성분(1124)은 서비스 플랫폼(1122)에 연결되는 다수의 통신 채널을 가진다.
서비스 구성성분(1124)은 클라이언트(1102) 상호작용을 위한 포트 세트와, 서비스 플랫폼(11220을 가진 별도의 통신 채널 세트를 관리하도록 최초에 설정된다. 서비스 구성성분(1124)은 서비스 플랫폼(1122)에 대한 통신 채널보다는 클라이언트(1102)에 대해 더 많은 포트를 가진다. 서비스 플랫폼(1122)은 한번에 하나의 요청을 처리하기 위해 단일 통신 채널을 이용한다. 따라서, 서비스 플랫폼(1122)에 대한 통신 채널이 가용해질 때까지 서비스 구성성분(1124)은 클라이언트(1102)로부터 요청이나 입력을 대기한다. 서비스 구성성분(1124)은 과정 큐 관리자(1122)에 위치한 캐시 메모리(1114) 입력 큐에서 클라이언트(1102)로부터 입력을 대기한다. 메모리가 FIFO식 대기 시스템인 것이 선호되지만 FILO 등 다른 방식이 사용될 수도 있다. 마찬가지로, 서비스 플랫폼(1122)으로부터의 출력은 요청한 클라이언트(1102)로 가는 도중에 포트 관리자(1106)에게 되돌아가기 전에 과정 큐 관리자(1112)에 위치한 캐시 메모리(1116) 출력 큐에서 대기한다.
서비스 플랫폼(1122)을 가진 통신 채널로부터 다수의 클라이언트(1102)를 가진 통신 채널을 분리함으로서, 서비스 구성성분(1124)은 서비스 플랫폼(1122)의 용량을 넘는 다수의 입력 요청을 처리할 수 있다. 즉, 서비스 플랫폼(1122)이 가진 가용 채널보다 더 많은 클라이언트(1102)들이 동시에 서비스를 요청할 수 있다. 서비스 플랫폼(1122)이 요청을 완료하여 통신 채널을 비우고 대기한 요청 중 하나를 받아들일 때까지, 서비스 플랫폼(1122)에 대한 통신 채널 수를 넘는 과량의 클라이언트(1102) 요청은 대기행렬화된다.
실행 시에, 다수의 클라이언트(1102) 중 하나는 특정 서비스 프로그램을 요청하고, 이 프로그램은 서비스 플랫폼(1122)에 위치한다. 클라이언트(1102)는 SIP 서비스 INVITE를 구성하여 제어 모듈(310)에 전송함으로서 요청을 한다. 적절한 루팅 이후, 요청이 서비스 구성성분(1124)에 위치하는 SIP 사용자 에이전트(1104)에 통신 채널(1140) 상에서 전달된다. SIP 사용자 에이전트(1104)의 작업은 요청한 클라이언트(1102)와 서비스 구성서분(1124)간 통신을 협상하는 것이다. 이를 위해, 가용 포트 과정(1108)이 있는 지가 먼저 결정된다. 없다면, 에이전트(1104)는 SIP 서비스 INVITE를 거절한다.
가용 포트 과정(1108)이 있다면, SIP 사용자 에이전트(1104)는 통신 채널(1142) 상에서 포트 과정(1108)에 메시지를 전송한다. 이 메시지는 요청한 클라이언트(1102)에 다시 통신 채널(1146, 1144)를 구축하는 것을 알려주는 메시지이다. 이는 SIP 서비스 INVITE 내 SIP 사용자 에이전트(1104)에 주소 정보를 제공한다. 모든 경우는 아니지만 많은 경우에, 도 11에 도시되는 포트 과정(1108)에 대하여, 클라이언트(1102)와 포트 처리(1108)간 각각의 연결에 대하여 두 세트의 통신채널이 구축된다. 이들 통신 채널들은 매체 1(MT1)에 대한 채널(1146)과 매체 2(MT2)에 대한 채널(1144)를 포함한다. 통상적으로 이들 통신 채널 중 하나는 클라이언트(1102)로부터 서비스 구성성분(1124)까지 전달되는 입력을 위해 사용될 것이다. 이는 요청한 클라이언트(1102)와 포트 과정(1108)간 양방향 통신 및 매체 흐름을 구축한다. 매체 조류는 클라이언트(1102)에 의해 요청받은 서비스에 대응하고 서비스 플랫폼(1122)에 의해 제공되는 서비스에 대응하지만, 매체 종류가 대응하지 않을 경우 매체 종류를 적절히 변형시키기 위해 인터페이스가 제공될 수 있다.
다른 실시예에서, 요청한 클라이언트(1102)와 포트 과정(1108)간에 임의 숫자의 통신 채널이 구축될 수 있다. 두 세트의 통신 채널이 포트 과정(1108a)에 대하여 설명된 것처럼 다음 예에서 유용하다. 요청한 클라이언트(1102)는 본 발명에 따르는 서버에 호출자 다이얼링에 의해 불러온 스피치 관련 응용프로그램이다. 서비스 플랫폼(1122)은 텍스트 -> 스피치 서비스(TSS)이다. 텍스트를 서비스 구성성분에 전송하기 위해 한 통신 채널(1144a)이 전송 제어 프로토콜(TCP)을 이용하고, 요청한 클라이언트(1102)에 오디오를 되보내기 위해 RTP 및 실시간 전송 제어 프로토콜(RTCP)을 이용한다.
서비스가 음성 인지 서버일 때도 두 세트의 통신 채널이 유용하다. 이 경우에, 도 11에 도시되지는 않으나, 서비스 구성성분(1124)에 유입되는 음성 입력을 위해 RTP/RTCP 통신 채널 쌍이 사용되고, 요청한 클라이언트(1102)에 되돌아가는 텍스트 출력을 위해 TCP 통신 채널이 사용된다.
주어진 포트 과정에 대하여 다른 세트의 통신 채널이 반드시 요청 클라이언트(1102)에 연결될 필요는 없다. 본 예에서, 입력될 텍스트가 요청 클라이언트(1102)로부터 올 수 있으나, 오디오 출력은 호출자에게 다시 되보낼 수 있다.
통신 채널이 구축되면, 포트 과정(1108)은 서비스 실행을 위해 추가적 입력을 필요로할 수 있다. 그러하다면, 입력 통신 채널(1144) 상에서 입력을 수신할 때까지 기다린다. 서비스 프로그램이 텍스트-스피치 서비스를 제공하는 예에서, 입력은 ASCII 텍스트로서, 통신 포트가 적절히 구축된 후에만 전송된다. 서비스 구성성분(11240이 음성 인지 서비스를 제공하는 예에서, 입력은 오디오 스트림으로서, 통신 포트가 적절히 구축된 후에만 전송된다. 다른 예에서 입력 및 출력 매체 종류는 변할 것이다.
포트 과정(1108)이 요청에 필요한 모든 것을 가질 때, 포트 과정(1108)은 요청 객체(도시되지 않음)를 생성하며, 이 객체에는 서비스 플랫폼(1122)에 대한 충분한 정보가 있어서 요청을 충족하고 결과를 적절한 포트 과정(1108)에 되보내어, 요청한 클라이언트(1102)나 호출 장치(302)에 전달할 수 있다.
포트 과정(1108)은 입력 큐(1114)상에 요청 객체를 위치시킨다. 작업자 스레드(Worker Thread; WT)(1118)는 서비스 플랫폼(1122)과의 백엔드 조율에 책임이 있다. 작업자 스레드(1118)가 비어있을 때, 작현 요청 객체에 대한 입력 큐(1114)를 확인한다. WT(1118)가 요청 객체를 찾아내면, WT(1118)는 입력 큐(1114)로부터 요청 객체를 제거하여 서비스 플랫폼(1122)에 요청을 전달하기 위해 이 정보를 이용한다. 본 발명에 따르는 서버의 구조 내에서, 서비스 플랫폼(1122)은 어떤 종류의서비스도 제공할 수 있다. 스피치 응용프로그램의 경우에, 이는 음성 인지 서비스, 텍스트-스피치 서비스, 음성 확장 마크업 랭기지(VXML) 스크립트 서버, 음성 프람프트 서비스, 또는 그 외 다른 서비스일 수 있다. 다른 종류의 응용프로그램의 경우에, 호환되는 서비스 목록이 존재할 수 있다.
멀티플렉싱 구조(1100)는 일반적인 것으로, 거의 모든 종류의 서비스 프로그램이 구조(1100)를 이용할 수 있다. 결과적으로, 멀티플렉싱 구조(1100)의 한가지 선호되는 실시예는 서비스 플랫폼 전용 API(1120) 부속구성성분을 포함한다. 서비스 플랫폼 전용 API(1120)는 특정 서비스 플랫폼(1122)과의 상호작용을 위해 범용 멀티플렉싱 구조(1100)에 대한 수단을 제공한다. 서비스 플랫폼 전용 API(1120)는 데이터 변환, 통신, 또는 서비스 플랫폼(1122)과의 상호작용에 필요한 그 외 다른 연산을 실행한다.
WT(1118)는 서비스 플랫폼(1122)에 요청하기 위해 서비스 플랫폼 전용 API(1120)를 이용한다. 서비스 플랫폼(1122)이 요청 처리를 완료할 경우, 결과를 WT(1118)에 되보낸다. WT(1118)가 원 포트 과정(1108)에 결과를 되보낼 수 있을 때, WT(1118)가 결과를 적절히 패키지화하여 출력 큐(1114)에 밀어넣는 것이 가능하다. 그러나, 출력 큐가 필요하지는 않다. 복귀 스레드는 출력 큐(1116) 상에서 잠들어, 무언가가 출력 큐(1116)에 놓일 때 깨어나서, 출력 큐(1116)로부터 결과를 제거하여 이 결과를 원 포트 과정(1108)에 제공한다. 출력 큐(1116) 사용이 통상적으로 필요하지 않다. 왜냐하면, 입력이 출력보다 훨씬 수가 많아서, 원 요청의 포트 과정(1108)에 출력 결과를 직접 전달하는 결과를 낳기 때문이다.
원 포트 과정(1108)은 통신 채널(1146) 상에서 이 결과를 출력 수신지에 전달한다. 출력 수신지는 도 11에 도시되는 바와 같이 요청한 클라이언트(1102)일 수도 이고, 전화통신 범주에서, 호출 장치(302)일 수도 있으며, 또는 IP 범주에서 SIP-동작 장치(402)일 수도 있다. 이 장치는 요청 클라이언트(1102)에 첫 번째로 접촉한다.
도 12는 처리 모니터 서비스(1200)를 도시한다. 처리 모니터 서비스(1200)는 본 발명에 따르는 서버 전체에서 리소스의 동작과 가용도를 조율하는 분산형 함수이다. 과정 모니터 서비스(1200)는 두개의 주 구성성분을 가진다. 즉, 다른 구성성분들을 제어하는 과정 모니터(1202)와 박스 모니터(1204)를 포함한다. 과정 모니터(1202)는 제어 모듈(310)과 동일한 하드웨어 박스 상에 위치하거나, 제어 모듈(310)에 아주 근접한 하드웨어 박스 상에 위치하는 것이 선호되고, 박스 모니터(1204)는 서버 내 모든 하드웨어 박스에 위치하는 것이 선호된다.
과정 모니터 서비스(1200)는 다중 서버 상에서 실행되는 다중 소프트웨어 과정을 모니터할 수 있다. 어느 하드웨어 박스에서 어느 소프트웨어 과정이 실행되는 지를 정적으로, 그리고 동적으로 설정하기 위한 수단을 제공함으로서 리소스의 가용도를 조율한다. 초기화 정보에 따라, 과정 모니터(1202)는 특정 하드웨어 박스 상의 박스 모니터(1204)에게 특정 소프트웨어 과정의 로딩 및 개시를 요청할 수 있다.
또한, 소프트웨어 과정이 어떻게 사용되고 있는 지, 그리고 얼마나 큰 처리 용량이 서버에 요구되는 지를 모니터링하면서, 과정 모니터(1202)는 초과 수요가있을 경우 새 과정을 로딩하고 시작하도록 박스 모니터(1204)에 지시할 수 있고, 과량의 용량이 있을 경우 과정을 셧다운시킬 것을 박스 모니터(1204)에 지시할 수 있다. 시작 및 중지는 시스템 구성 파일(도시되지 않음)을 이용한다. 현재 사용되는 것보다 더 많은 특정 리소스 A의 사례가 주어진 하드웨어 박스 상에서 개시될 때, 그리고 현재 필요한 것보다 더 적은 앞서와는 다른 리소스 B의 사례가 동일 하드웨어 박스 상에서 개시될 때 특정 과정을 셧다운시키는 능력이 유용할 수 있다. 이 경우에, 과정 모니터(1202)는 리소스 A의 일부 사례를 셧다운시키도록, 그리고 리소스 B의 일부 추가 사례를 개시하도록 상기 하드웨어 박스에 대한 박스 모니터(1204)에 명령할 수 있다.
과정 모니터 서비스(1200)는 과정 상태를 모니터함으로서, 그리고 페일-오버(fail-over) 능력을 제공함으로서 시스템 신뢰도를 향상시킨다. 과정이 부적절하게 동작하거나 중단될 때, 과정 모니터 서비스(1200)는 과정들을 재시작한다. 아래에 설명되는 그 수직 클러스터링 구조로 인해, 시스템은 매우 큰 수의 하드웨어 및 소프트웨어 리소스까지 확대될 수 있다.
과정 모니터 서비스(1200)는 하드웨어 박스 자체의 동작을 모니터하고 하드웨어 관리를 행한다.
과정 모니터 서비스(1200)는 소프트웨어를 업데이트하고 관리하는 능력을 제공한다. 특정 소프트웨어 패키지를 업데이트할 필요가 있을 경우, 과정 모니터(1202)는 상기 소프트웨어 패키지의 사례를 실행하는 모든 박스 모니터(1204)에게 상기 사례들의 셧다운을 지시할 수 있다. 이 셧다운은 즉각적으로 이루어질 수도 있고, 현 작업 완료 후 새 작업을 실행하기 전에 이루어질 수도 있다. 소프트웨어 과정의 모든 사례가 특정 박스 상에서 종료될 경우, 상기 소프트웨어 패키지의 새 버전이 상기 박스 상에 로딩될 수 있고, 새 버전의 사례들이 시작될 수 있다.
마찬가지로, 과정 모니터 서비스(1200)는 하드웨어 업데이트 및 관리 기능을 제공한다. 좀 더 성능이 좋은 하드웨어 박스로 바꾸거나 그 메모리나 그 외 다른 구성성분을 업데이트 및 수리하기 위해, 서비스로부터 빠져나오려면 특정 하드웨어 박스가 필요할 수 있다. 과정 모니터(1202)는 상기 하드웨어 박스 상의 모든 소프트웨어 과정을 상기 하드웨어 박스가 즉각적으로, 또는 안정적으로 다운시키도록 박스 모니터(1204)에 지시할 수 있다. 상기 하드웨어 박스 상의 모든 소프트웨어 과정들이 다운되었을 경우, 하드웨어 박스는 업그레이드나 수리를 위해 서비스로부터 빠져나올 수 있다.
과정 모니터 서비스(1200)는 페일-오버(fail-over)에 대한 백업 과정 모니터를 포함하는 것이 선호되고, 이로 인해 높은 신뢰도 과정의 관리 시스템이 가능하다. 각각의 과정 모니터(1202)는 관련된 백업 과정 모니터(1208)를 포함한다. 추가적으로, 마스터 과정 모니터(1206)는 관련된 백업 과정 모니터(1208)를 또한 가진다.
과정 모니터 서비스(1200)는 수직구조에 따라 클러스터 구조를 취한다. 클러스터(13011~1301n)로 도 13에 도시되는 각각의 클러스터는 다수의 박스모니터(1204)를 모니터하는 한개 이상의 과정 모니터(1202)를 포함한다. 각각의 과정 모니터(1202)와 각각의 박스 모니터(1204)는 별도의 처리 장치이다. 이 과정 모니터(1202)와 박스 모니터(1204)는 별도의 서버에 위치할 수도 있고, 단일 서버에 통합될 수도 있다. 과정 모니터(1202)와 박스 모니터(1204)는 관리 리소스의 모니터 및 접근 수단을 제공한다.
도 12에서 관리 리소스1, 2, ...N으로, 도 13에서 박스1 과정1,...,박스1 과정L, 등으로 도시되는 관리 리소스는1) 모니터 용도의 상태 정보와,2) 관리 리소스가 실행하고자 하는 액션을 제공할 수 있는 소프트웨어 과정이다. 예를 들어, 하드웨어 박스 1의 박스 모니터(1204)(도 12)는 하드웨어 박스 1의 관리 리소스 1, 2, ...N에 접근한다. 관리 리소스는 본 발명의 한 실시예에 따르는 서버에 위치한 응용프로그램이나 서비스 프로그램에 의해 이용되는 소프트웨어나 하드웨어 리소스이다. 스피치 관련 응용프로그램의 경우에, 이 관리 리소스들은 음성 인지 서비스, 텍스트-스피치 발생 서비스, 그리고 프람프트 서비스, 이뿐 아니라 플랫폼 서비스와 최상위 리소스 관리 서비스같은 스피치 전용 리소스를 포함할 수 있다.
박스 모니터(1204)의 단일 사례가 관리할 리소스를 지닌 각각의 물리적 박스에 전개된다. 박스 모니터(1204)는 패시브 관리자이다. 박스 모니터(1204)는 이를 관리하는 과정 모니터(1202)로부터 요청에 응답한다. 과정 모니터(1202)는 박스모니터(1204) 관리 리소스 상의 상태 레포트를 요청하고, 박스 모니터(1204)에게 리소스 관리, 리소스 시작, 리소스 다운, 리소스 발진의 작용을 취하도록 지시한다. 박스 모니터(1204)는 짧은 주기의 구간에서 과정 모니터(1202)에 보고하지만(선호됨), 구간 길이가 길 수도 있다.
다수의 박스 모니터(1204)와는 별도의 서버에 한개의 과정 모니터(1202)가 설치된다. 한개의 과정 모니터(1202)가 한개의 박스 모니터(1204)를 가지는 서버에 설치될 수도 있고, 고유 독립형 서버에 설치될 수도 있으며, 또는 여러 협력 서버에 프로그래밍될 수도 있다. 과정 모니터(1202)는 박스 모니터(1204) 종류, 그 구성 파일, 그리고 박스 모니터(1204)가 보고하는 정보를 바탕으로 하여 박스 모니터(1204)에 적절한 명령을 발급한다.
박스 모니터(1204)를 초기에 위치시키기 위해, 과정 모니터(1202)는 멀티캐스트 IP 메시지를 이용하는 것이 선호된다. 과정 모니터(1202)와 그 박스 모니터(1204)간 이어지는 통신은 HTTP와 HTTPS 프로토콜을 이용하지만, 다른 통신 프로토콜이 사용될 수도 있다.
앞서 언급한 바와 같이, 과정 모니터 서비스(1200)는 클러스터 표시를 통합한 수직 보고 모델을 이용한다. 도 13은 클러스터의 수직 구조를 도시한다. 인컴패싱 클러스터(encompassing cluster)(1302)같은 인컴패싱 클러스터는 다수의 클러스터(13011~1301n)의 논리 그룹이다. 하나의 논리 그룹 클러스터가 두 수직 레벨로, 즉, 과정 모니터(1202)와, 과정 모니터(1202)가 관리하는 박스 모니터(1204)로 이루어지는 것이 선호된다. 본 발명의 작은 실시예에서, 전형적인 클러스터는 단일 과정 모니터(1202)와 이에 의해 관리되는 박스 모니터들(1204)로 구성될 수 있다. 도 13에 도시되는 바와 같이, 인컴패싱 클러스터(1302)는 마스터 과정모니터(1206), 페일-오버(fail-over) 기능을 제공하는 백업 마스터 과정 모니터(1308), 클러스터(13011~1301n)에 대한 다수의 과정 모니터(12021~1202n), 그리고 각각의 클러스터(13011~1301n) 내 각각의 하드웨어 박스에 대한 다수의 박스 모니터(1204)를 포함한다. 클러스터(13011) 내에서는 과정 모니터1(12021)이 하드웨어 박스 1, 하드웨어 박스 2, 하드웨어 박스 N 상의 박스 모니터 1~N을 모니터한다.
도 13에 도시되는 바와 같이, 단일 마스터 과정 모니터(1206)는 본 발명의 한 실시예에 따라 설계된 네트워크의 모든 클러스터에 대해 존재한다. 물론, 과정 모니터의 다층이 시스템 관리를 확장할 수 있다. 예를 들어, 단일 수퍼 마스터 과정 모니터는 마스터 과정 모니터(1206) 세트 위에 관리층으로 존재할 수 있다. 각각의 클러스터는 그 고유 과정 모니터(1202), 백업 과정 모니터(도시되지 않음), 그리고 다수의 박스 모니터(1204)를 포함한다. 박스 모니터(1204)는 클러스터 내 개별 서버를 관리한다. 대안으로, 각각의 박스 모니터(1204)는 서버의 한 부분으로 지정되어, 서버의 상기 부분에 할당된 특정 리소스를 모니터할 수 있다. 도는 박스 모니터(1204)가 모니터하는 것이 여러 서버 상에서 할당된 관리 리소스일 수 있다. 인컴패싱 클러스터(1302)의 각각의 박스 모니터(1204)는 과정 모니터(1202)에 보고하고, 이어 마스터 과정 모니터(1206)에 보고한다. 박스 모니터(1204)와 과정 모니터(1202)에 의해 보고되는 데이터는 수직구조의 각각의 레벨을 통과하여 제공된다. 이렇게 모인 데이터는 아래 설명되는 적절한 인터페이스 툴이나 그래픽 사용자 인터페이스에서 볼 수 있다.
도 12와 연계하여 앞서 설명한 바와 같이, 박스 모니터(1204)는 발명의 한 실시예에 따라 플랫폼의 서버 성분의 리소스를 관리한다. 관리 리소스는 상태 정보를 제공하거나 실행할 수 있는 작용을 가용하게 하는 소프트웨어 과정이다. 박스 모니터(1204)가 일부 정보 처리를 실행하도록 설계될 수 있을 때, 박스 모니터(1204)가 관리 과정에 관해 어떤 구체적 사항도 알지못하는 패시브 에이전트인 것이 선호된다. 대신에 관리 과정 모니터(1202)로부터 지시를 수신하고 이를 보고하기만 한다.
과정 모니터 서비스(1200)는 설치된 박스가 부팅될 때 시작하는 과정 모니터(1202)와 박스 모니터(1204)에 의존한다. 예를 들어 도 12의 하드웨어 박스 1은 초기에 꺼질 수 있다. 과정 모니터(1202)는 하드웨어 박스 1을 등록하지 않을 수 있고, 따라서, 하드웨어 박스 1은 응용프로그램이나 서비스 프로그램의 개시를 보고하지 않을 수 있고 지시받지 않을 수 있다. 하드웨어 박스 1이 시작되면, 박스 모니터(1204)는 과정 모니터(1202)에게 이를 통지한다. 과정 모니터(1202)는 이 정보를 로케이션 서비스(1004)에 등록한다. 마찬가지로, 박스 모니터(1204), 과정 모니터(1202), 그리고 마스터 과정 모니터(1206)에 의해 모니터되는 과정에 대한 이용 정보는 리소스 관리자(1006)에 의해 접근할 수 있고, 특정 요청이 지시되는 응용프로그램과 서비스의 사례를 결정하기 위해 루팅 관리자(1002)의 버전에 의해 이용될 수 있다.
마찬가지로, 전체 클러스터가 다운일 경우, 부팅될 때 과정 모니터(1202)는박스 모니터(1204)가 아래 설명하는 바와 같이 과정 모니터(1202)에 등록하는 방식과 마찬가지 방식으로 마스터 과정 모니터(1206)에 등록한다.
시작될 때 부트스트랩을 실행하기 위해, 박스 모니터(1204)는 가용 통신 포트, IP 주소, 그리고 에이전트 종류를 명시하는 초기화 매개변수를 이용한다. 새 값이 실행시 명령 라인에 명시되지 않을 경우 박스 모니터(1204)는 디폴트 초기화값을 이용한다.
시작 이후, 박스 모니터(1204)는 클러스터의 과정 모니터(1202)에 의해 주기적으로 "누가 여기 있나요?"라는 발견 질의 방송을 듣는다. 앞서 설명한 바와 같이, 이 발견 질의는 멀티-캐스트 IP 메시지로 전송된다. 박스 모니터(1204)가 이 메시지를 수신하면, 박스 모니터(1204)는 과정 모니터(1202)에 발견 응답을 전송한다. 과정 모니터(1202)는 박스 모니터(1204)의 발견 응답 메시지 내 정보를 이용하여 박스 모니터를 클러스터 내에서 액티브한 것으로 등록하고, 박스 모니터(1204)의 보고 종류에 특별한 리소스 구성 파일을 로딩한다. 과정 모니터(1202)에 등록하는 것은 한번만 발생한다. 박스 모니터(1204)는 관리 과정 모니터(1202)로부터 지시를 기다린다.
일반적으로, 박스 모니터(1204)는 관리하는 박스에서 다음의 세가지 기능을 실행한다. 즉, 1) 관리 리소스 상에서 작용을 실행한다. 2) 관리 리소스의 상태를 보고한다. 3) 관리 리소스에 의해 전송된 통지내용을 처리한다.
특정 박스 모니터(1204)에 의해 제공되는 모니터 서비스는 박스 상에 전개되는 운영 체제 및 소프트웨어 구성성분에 따라 좌우된다. 이 방식으로, 박스모니터(1204)는 그 종류에 따라 분류될 수 있다. 각각의 박스 모니터(1204)는 관련 관리 리소스 구성 파일을 가진다.
박스 모니터(1204)가 관리할 수 있는 리소스에 관한 정보는 그 구성 파일에 저장된다. 관리 리소스 구성 파일은 두 종류의 리소스, 즉, 시작 스크립트와 모니터 과정에 관한 정보를 내장한다. 박스 모니터(1204)는 그 구성 파일 내 정보에 직접 접근하지 않는다. 그보다는 그 관리 과정 모니터(1202)가 어떤 지시받은 작업의 실행을 박스 모니터(1204)에게 알리기 위해 관리 리소스 구성 파일의 정보를 이용한다. 이 작업들은 스크립트 실행과, 관리 리소스 구성성분이나 디스크립터(도시되지 않음)의 로딩 및 시작을 포함하며, 이들은 박스 모니터(1204)의 관리 리소스에 링크를 제공한다.
과정 모니터(1202)는 클러스터 내 네트워크 관리 처리에 대한 초점의 기능을 한다. 앞서 언급한 바와 같이, 과정 모니터(1202)는 멀티캐스트 IP 메시지로 "여기 누가 있나요?" 질의를 주기적으로 방송함으로서 그 클러스터(1301) 내 박스 모니터(1204)를 동적으로 찾아낸다. 과정 모니터(1202)의 태양으로부터, 그 클러스터 내의 박스 모니터(1204)는 그자체로 관리되는 리소스이다. 박스 모니터(1204)처럼, 위에 놓인 하드웨어 박스가 부팅될 때 과정 모니터(1202)가 시작된다. 부트스트랩 활동을 실행하기 위해, 과정 모니터(1202)는 가용 통신 포트, IP 주소, 타임아웃, 그리고 그 외 다른 활동을 명시하는 초기화 매개변수를 이용한다. 과정 모니터(1202)는 실행시에 명령 라인에 새 값이 명시되지 않을 경우 디폴트 초기값을 이용한다.
시작 이후, 과정 모니터(1202)는 마스터 구성 파일을 판독한다. 마스터 구성 파일은 공지된 박스 모니터(1204) 종류를 식별하고, 관련 관리 리소스 구성 파일이 어디 위치하는 지를 식별한다. 박스 모니터(1204)에 비해 과정 모니터(1202)는, 상태 보고서를 요청하고 과정 모니터(1202)가 관리하는 박스 모니터(1204)에 지시를 전송하는 액티브한 실체이다. 박스 모니터(1204)가 "누가 여기 있나요?" 질의에 응답할 경우, 과정 모니터(1202)는 상기 박스 모니터(1204)를 클러스터 내에서 액티브한 것으로 등록한다. 박스 모니터(1204)의 응답은 그 통신 채널(IP 주소와 포트가 선호됨)과 그 박스 모니터(1204) 종류를 식별한다.
박스 모니터(1204)가 관리할 수 있는 리소스에 관해 과정 모니터(1208)가 알도록 하기 위해, 특정 박스 모니터(1204) 종류에 연계된 구성 파일에 접근한다. 과정 모니터(1202)는 박스 모니터(1204)가 실행할 지시받은 세트의 작용을 발급하도록 이 구성 파일에 나열된 리소스를 이용한다.
과정 모니터(1202)는 그가 관리하는 박스 모니터(1204)와 그 관리 리소스에 관한 데이터를 모집한다. 데이터 애그리게이터(data aggregator)(도시되지 않음) 서비스는 마스터 과정 모니터(1206)와 관리 뷰어 응용프로그램같은 고도의 관리 실체와 박스 모니터(1204)에 의해 관리되는 낮은 레벨의 과정 사이에 인터페이스를 제공한다. 데이터 애그리게이터 서비스는 여러 차원을 가진다. 관리 리소스가 시작될 때마다, 관리 리소스 콘트롤러가 생성되어 수직 구조에서 각각의 레벨 위로 전파된다는 점이 중요하다. 이 관리 리소스 콘트롤러는 프록시 객체로서, 고-레벨 관리 실체가 관리 리소스로부터 정보를 얻을 수 있게 하고 동작 변경을 위한 지시를발급할 수 있게 한다. 이 프록시 객체로 인해 관리 리소스 자체에서 멀리서 이 방법들을 불러올 수 있다.
과정 모니터 수직구조의 각각의 레벨은 상기 레벨 이하에서 모든 관리 리소스에 대한 관리 리소스 콘트롤러를 내장한다. 이로 인해 어떤 레벨에 위치한 관리 실체가 상기 레벨 이하의 관리 리소스에 대한 상태 정보를 얻을 수 있고, 상기 레벨 이하의 관리 리소스를 제어할 수 있다. 마찬가지로, 관리 뷰어 응용프로그램은 과정 모니터 수직구조의 특정 레벨에 관한 화면을 열 수 있다. 이 화면으로부터, 관리 뷰어 응용프로그램은 상기 레벨 이하의 관리 리소스에 관한 상태 정보를 얻을 수 있고, 상기 레벨 이하의 관리 리소스를 제어할 수 있다.
과정 모니터 서비스(1200)는 시스템 경보에 관한 관심자에게 알리는 데 사용되는 통지 구성성분을 포함한다. 시스템 운영자에 의해 구축된 기준에 따라 부적절하게 기능하거나 고장하는 동작이 있을 경우 언제라도 경보가 울린다. 통지 구성성분(도시되지 않음)은1) (사용자 규정 기준에 따라) 경보가 울려야 하는 지의 결정,2) 경보를 로그에 기록,3) 경보를 누구에게 알려야 하는 지 결정, 그리고4) 단계 3)에서 식별된 수신자에게 통지를 전송에 책임이 있는 구성성분들로 이루어진다. 통지는 디스플레이를 위한 관리 뷰어 응용프로그램에, 또는 분쟁 조정 액션을 취하는 모니터 프로그램에 전달될 수 있다. 통지는 적절한 액션을 취할 수 있는 운영자에게 이메일이나 페이지로 전송될 수도 있다.
과정 모니터(1202) 페일 오버(fail-over) 구성성분은 두 페일-오버 메카니즘을 구현한다. 먼저, 관리하는 박스 모니터(1204)에 "살아있어요?" 방송을 발급함으로서 동작 순서대로 있는 것을 확인하기 위해 박스 모니터(1204)를 계속적으로 모니터한다. 두 번째로, 과정 모니터(1202) 페일-오버 구성성분은 과정 모니터(1202)의 백업 사례가 항상 살아있고 최신 정보를 내장하는 지를 보장하여, 과정 모니터(1202)가 고장날 경우, 상기 과정 모니터의 백업 사례가 이를 대신할 수 있게 한다. 과정 모니터(1202)가 고장날 경우, 과정 모니터의 백업 사례가 주 과정 모니터(1202)로 들어와서, 백업으로 작용할 또다른 과정 모니터(1028)를 시작한다.
본 발명은 전체적으로 서버, 그리고 서버 내에서 실행되는 응용프로그램 및 서비스 세트의 상세한 동작을 추적하거나 로그 기록하는 데 중요한 상황에 사용될 수 있는 서버 생성을 가능하게 한다. 이 추적 정보는 서버와 그 구성성분들이 하드웨어 및 소프트웨어 리소스를 더 양호하게 배치하도록 하기 위해 어떻게 기능하는 지를 이해하는 데 사용될 수 있다. 추적 정보는 각각의 응용프로그램 및 서비스나 응용프로그램 및 서비스 세트에 의해 어느 리소스가 얼마나 많이 사용되는 지를 결정하는 데 사용될 수도 있다. 이 리소스 이용 정보는 응용프로그램 및 서비스 프로그램의 제공자와 클라이언트에게 대금을 청구하는 데 사용될 수도 있다.
로그 능력은 두가지 중요한 차원을 가진다. 즉, 임시 기억 장치에 정보를 로그하는 것과, 임시 기억 장치로부터 영구기억 장치로 정보를 전송하는 것이다.
도 14는 서버 동작을 추적하거나 검색할 수 있는 한가지 실시예를 도시한다. 도 14는 임시 기억 장치(1402), 영구 기억장치(1404), 그리고 다수의 추후 처리 모듈(1406)을 포함하는(선호됨) 추적 시스템(tracking system)(1400)을 도시한다. 예를 들어, 도 14는 응용프로그램(312) B와 서비스 프로그램(314) Y(도 3, 4, 10 참고)에 대한 정보 추적을 도시한다. 리소스 이용에 관한 정보의 추적이나 로그는 본 발명에서 여러 방식으로 가능하다. 도 3에서는 호출 장치(302)가 매체 서버(308)에 접근하여, 적절한 사례의 응용프로그램 B를 위치시키도록 제어 모듈(310)에 요청하는 SIP 응용프로그램 INVITE를 발생시켜서 제어 모듈(310)에 전송한다. 앞서 설명한 바와 같이, 제어 모듈(310)은 현 리소스 이용 및 다른 요소를 바탕으로 응용프로그램 B의 가용 사례를 찾아내는 것과 같이 표준 동작을 실행한다. 이 표준 동작은 별도의 추후 처리 분석 모듈(1406)에 의해 차후 이용을 위해 로그되며, 상기 모듈(1406)은 제 3 자 어카운팅이나 다른 모듈을 포함할 수 있다.
응용프로그램(312)이나 서비스 프로그램(314) 내에도 로그되는 응용프로그램들이 존재한다. 이는 특정 동작의 호출을 감싸는 소프트웨어 프로그램이나 래퍼(wrapper)(1408)의 세트에 의해 달성된다. 응용프로그램(312) B가 서비스 프로그램(314) Y처럼 텍스트-스피치 서비스를 원할 경우, 상기 서비스 프로그램(314) Y를 얻기 위해 응용프로그램(312) B에 내장된 모듈에 한 방법을 호출한다. 내장된 방법은 응용프로그램(312) B가 임시 기억 장치(1402)에 위치한 데이터 필드 내 서비스 프로그램(314)을 요청하고 있다는 사실을 먼저 로그하고, 그후 이 요청을 평상시처럼 텍스트-스피치 서비스 프로그램(314) Y에 넘기는 래퍼 코드(wrapper code)(1408)의 한 예다.
어카운팅은 본 발명의 한 실시예에 따라 만들어지는 서버에 의해 수집되어야 하는 데이터 세트를 규정한다. 로그 과정은 차후 대금청구 및 분석 추후 처리 모듈(1406)에 의해 이용될 수 있도록 어카운팅 데이터를 지속하는 과정이다. 일반적으로, 로그 과정은 모든 SIP에 의해 동작하는 구성성분에 의해 실행되며, 제어 모듈(310), 응용프로그램(312), 그리고 서비스 프로그램(314)을 포함한다. 초기 로그 과정은 임시 기억 장치(1402)에서 종료되고, 별도의 과정으로 인해 결정 지원 툴(1406)에 의해 이용하기 위해 로그 데이터가 영구 기억장치(1404)에 모이게 된다.
로그 서브시스템은 여러 다른 레벨의 우선순위로 데이터를 로그하기 위한 틀을 이용한다. 로그 상태는 데이터가 수집되어야 하는 논리 위치의 래퍼 코드(1408)에서 실행된다. 주어진 로그 상태는 여러 우선순위 레벨 중 하나에 놓일 수 있다. 로그 시스템은 적어도 네 개 이상의 우선순위를 이용한다. 즉, ERROR, WARN, INFO, 그리고 DEBUG를 이용한다. 그후, 어느 우선순위 레벨이 실제로 로그되는 지 결정하기 위한 매개변수들이 설정될 수 있다.
로그 능력은 세 개의 별도의 차원으로 이루어지는 것이 선호된다. 첫 번째는 앞서 설명한 로그 래퍼 코드(1408)이다. 이 래퍼 코드(1408)의 코드 레벨 상태는 상기 코드 세그먼트가 실행된다면 시스템의 상태를 설명하는 영구 데이터를 기록할 것이다. 두 번째는 임시 기억 장치(1402)이다. 임시 기억 장치 메카니즘(1402)은 상기 데이터를 최초에 로그하기 위해 일시적이고 고성능의 국부 기억 장치로서 강제적인 사항은 아니다.
세 번째는 영구 기억장치(1404)이다. 영구 기억 메카니즘(1402)은 임시 기억 장치(1402)로부터 장기적이고 신뢰도가 높은 영구 기억장치(1404)로 로그 데이터를 전송할 것이다. 미리프로그래밍된 래퍼 코드(1408)에 의해 식별되는 로그/추적 정보는 플랫 파일에 저장될 것이고, 영구 기억 장치(1404)에서는 임시 기억 장치(1402)와 관련 데이터베이스에 저장될 것이다. 추후 처리 모듈(1406)은 여러 종래 대금청구 및 분석 프로그램에 의해 요구되는 바와 같이 영구 기억 장치(1404) 데이터베이스 내 정보에 접근한다. 추후 처리 모듈(1406)은 시스템에 접근하는 별도 서버의 일부일 수도 있고, 기존의 서버 네트워크의 일부일 수도 있다.
대금 청구 및 분석을 위해 별도의 영구 기억 장치(1404)와 중간 임시 기억 장치(1402)를 이용하는 것이 선호된다. 왜냐하면 대금청구 및 분석 프로그램이 영구 기억 장치(1404)에 접근할 때 프로그램 실행에 최소한의 영향만 미치기 때문이다. 추가적으로, 래퍼 코드(1408)에 의해 임시 기억장치(1402)에 기록된 추적되거나 로그된 데이터는 임시 기억 장치(1402)에 신속하게 기록될 수 있고, 이때 실행중인 응용프로그램에는 최소한의 영향만 미친다. 독립적인 과정이 정규적 원칙으로 모든 데이터를 임시기억 장치(1402)로부터 영구 기억 장치(1404)로 이동시킬 것이다.
중요한 관심사는 동시에 로그되는 여러 과정 사이에서 경쟁(contention)을 줄이는 것이다. 선호되는 해법은 여러 다른 과정에 의해 이용될 수 있는 다중 로그 파일 세트를 제공하는 것이다. 임시 기억 장치(1402)가 고수되기 때문에, 다중 임시 로프 파일을 가지는 것이 비일관성을 발생시키지 않는다. 데이터가 영구 기억 장치(1404)에 전송될 때 일시적 관계가 적절히 재구축된다.
데이터가 다중 분산 파일로부터 영구 기억 장치(1404)로 여러 방식으로 전송될 수 있다. 한가지 방식은 모든 파일로부터 모든 데이터를 한번의 연산에 전송하는 단일 벌크 거래를 이용하는 것이다. 일반적으로, 이는 모든 파일이 처리될 때까지 모든 로그 파일을 잠글 것이고, 데이터베이스 내의 데이터가 주어진 시간스탬프를 가지는 것이 보장된다. 이러한 흐름은 중요하지 않지만, 이 접근법이 더 큰 설비에서 성능 문제를 생성할 수 있다. 왜냐하면 모든 파일이 잠기기 때문에 거래 중에 어떤 데이터도 로그되지 않기 때문이다.
임시 기억 장치(1402)의 다중 분산 파일로부터 영구 기억 장치(1404)의 대응하는 파일이나 데이터 필드까지 데이터를 전송하는 데 일련의 거래가 사용된다. 이 접근법은 각각의 파일에 대해 한개의 거래를 이용한다. 각각의 파일은 개별적으로 처리되고, 데이터 전송에 충분한 길이만큼만 잠긴다. 이로 인해 시스템은 데이터 전송 후 즉시 상기 파일로의 로그를 계속할 수 있다. 이는 응용프로그램 중단을 최소화한다.
데이터를 영구 기억 장치(1404)에 전송하는 것은 상대적으로 짧은 구간에 자동적으로 발생하도록 스케쥴링되는 것이 선호되지만, 그 여부는 설계상의 문제이다.
영구 기억 장치(1404)는 로그 데이터를 저장하기 위해 관련 데이터베이스(1404)를 이용하는 것이 선호된다. 관련 데이터베이스는 추후 처리를 위해 데이터를 불러오기 위해 분석 프로그램에 대한 표준 수단을 또한 제공한다.
데이터가 영구 기억 장치(1404)에 전송되면, 추후 처리 모듈(1406)이 추후 처리 틀(도시되지 않음)을 이용하여 추후 대금청구 및 분석 프로그램을 실행시킨다.
앞서 설명한 바와 같이, 여기서 설명되는 구조들은 세션층과 프레젠테이션층을 더 양호하게 형성하기 위해 OSI 프로토콜에 대해 개량된 TCP/IP 시스템을 바탕으로 한다. 이는 종래 TCP/IP의 일부가 아니다. 설명을 명확하게 하기 위해, 종래 TCP/IP 시스템을 앞서 설명한 바와 같이 OSI 프로토콜을 따르는 TCP/IP 시스템으로 개량하는 것은 도 15-18을 참고하여 설명될 것이다.
OSI 프로토콜은 특정 기능을 실행하기 위해 일련의 층들을 구축함으로서 호스트-호스트 통신을 규정한다. 도 15에 도시되는 바와 같이, OSI 프로토콜은 일곱 개 층의 수직구조 시스템(1500)을 규정한다. 시스템(1500)은 물리적층(1502), 데이터링크층(1504), 네트워크층(1506), 전송(transport)층(1508), 작업시간(session)층(1510), 제시(presentation)층(1512), 그리고 응용프로그램층(1514)을 포함한다. 도 15는 TCP/IP 모델(1550)을 또한 도시한다. TCP/IP 모델(1550)은 다음 방식으로 OSI 시스템(1500)에 매핑된다. 물리적 층(1502)과 데이터링크층(1504)이 조합되어 호스트-네트워크층(1552)을 형성한다. 네트워크층(1506)은 인터넷 프로토콜(IP)층(1554)에 필적한다. 전송층(1508)은 TCP/UDP(Transmission Control Protocol/User Datagram Protocol)층(1556)에 필적한다. TCP/IP 모델(1550)은 세션층(1510)이나 프레젠테이션층(1512)과 동등한 층을 제공하지 않는다. 응용프로그램층(1514)은 응용프로그램층(1558)에 대응한다.
OSI 프로토콜은 다음과 같이 여러 층을 형성한다.
물리적 층(1502)은 통신 채널에서 비트나 데이터의 전송을 규정한다. 일반적으로, 1과 0의 비트 사이를 나타내기 위해 전압 레벨이 이용된다. 물리적 층(1502)은 버스 워크(bus work), 동축 케이블, 광섬유, 무선 프로토콜(블루투스 등)같은 통신 매체로 직접 통신한다.
데이터 링크층(1504)은 1바이트의 정보를 "프레임"으로 묶고, 에러없이 데이터 프레임을 전송한다. 데이터 링크층(1504)은 "프레임 시작" 인디케이터를 프레임에 딸리게 할 수 있다. 더욱이, 데이터 링크층(1504)은 각각의 프레임에 대해 체크섬을 발생시킬 수 있고, 이는 데이터 확인을 포함한 다수의 기능을 위해 사용될 수 있다. 데이터 프레임의 다른 부분은 에러 확인에 대한 제어값, 주소, 등을 포함할 수 있다.
네트워크 층(1506)은 한 연산 장치로부터 또다른 연산 장치까지 프레임의 "패킷 루팅"을 실행한다. 통상적으로, 연산 장치들은 별도의 것으로 잔주되지만, 연산장치들이 공존할 수도 있다. 광범위하게 알려진 네트워크층 프로토콜은 인터넷 프로토콜(IP)로서, TCP/IP 모델에서 이용된다.
전송층(1508)에서는 네트워크층(1506)에서 전달된 다중 데이터 프레임(패킷)의 송수신이 가능하다. 전송층의 한가지 기능은 데이터 프레임을 송신 순서대로 재조립하는 것이다. 전송 데이터의 또다른 기능은 데이터 확인 및 손실된 데이터 프레임의 재전송일 수 있다. TCP/IP 모델은 LF반적으로 사용자 전송 제어 프로토콜(TCP)나 사용자 데이터그램 프로토콜(U에)을 이용한다. 이 프로토콜에서 가장 큰 차이점은 TCP가 순서 패킷으로부터 재조립하고 손실된 패키지를 재전송하지만 U에는 패킷만을 전송할 뿐이다.
작업시간층(1510)에서는 동일하거나 다른 호스트 연산 장치의 응용프로그램이 "작업시간(session)"을 형성한다. 작업시간은 PSTN식 호출과 기능이 유사하다. TCP/IP 모델은 외부적으로 규정된 세션층 프로토콜을 가지지 않는다. 일반적으로, 세션은 심플렉스, 해프 듀플렉스, 풀 듀플렉스로 분류될 수 있다. 심플렉스 세션은 단일 호스트 송신과 한개 이상의 호스트 송신으로 제한된다. 해프 듀플렉스는 다중 송신 호스트를 포함하지만, 단 하나의 호스트만이 한번에 데이터를 송신한다. 풀 듀플렉스는 병렬로 호스트 송신을 포함한다. 세션 구축의 일부분으로, 세션층(1510)은 세션 구축에 관련된 규칙, 데이터 통신을 위한 송신 프로토콜 식별에 관련된 규정, 그리고 세션 종료나 호출 종료에 관한 규정들을 포함한다.
프레젠테이션층(1512)은 호스트간 데이터 전송에 관한 규정을 포함한다. 전송의 일부분으로, 데이터 포매팅에 대한 협의가 다중 장치간에 반드시 구축되어야 한다. 예를 들어, 데이터는 ASCII 방식으로 포맷될 수 있다.
응용프로그램층(1514)은 응용프로그램이나 서비스 응용프로그램을 포함한다. 예를 들어, 텍스트-스피치 시스템에서, 서비스 응용프로그램은 텍스트 데이터 방식으로부터 오디오 데이터 방식으로의 변환일 수 있다.
현재, VoIP는 매체 전송을 위해 TCP/IP를 이용한다. 그러나 앞서 설명한 바와 같이, 종래 TCP/IP 모델은 OSI 프로토콜 세션 층 및 프레젠테이션층에 연계된 호출 제어 및 프레젠테이션을 위한 적절한 방법을 가지지 않는다. 이 층들을 TCP/IP 모델에 삽입하는 한가지 가능한 방식은 호출 제어를 위한 세션 개시 프로토콜, 멀티미디어 물리적 전송 모델 식별을 위한 세션 설명 프로토콜, 그리고 데이터 포맷 및 매체 전송 프로토콜을 포함한다. 이 층들을 지닌 한가지 TCP/IP모델(1600)이 도 16에 도시된다. TCP/IP 모델(1600)은 TCP/IP 모델에 도시되는 모든 층들을 포함하고, 세션층(1602)을 포함한다. 세션층(1602)은 매체 세션틀(1604)을 포함하고, 이는 세션 개시 프로토콜 섹션(1606), 세션 설명 프로토콜(1608), 그리고 실시간 전송 프로토콜(1610)의 상호작용 규정을 포함한다. 도 16이 SIP, S에, RTP,를 도시하고 있으나, 다른 프로토콜이 사용될 수도 있다.
도 17은 세션층(1600)이 구현될 수 있는 프로세서(1700)를 도시한다. 프로세서(1700)는 SIP 사용자 에이전트(1706)에서 클라이언트(1702)로부터 입력(1704)을 포함한다. 클라이언트(1702)는 응용프로그램을 호출하는 사용자일 수 있고, 별도의 호스트 프로세서 상의 응용프로그램일 수도 있으며, 내장된 프로세서 상의 응용프로그램일 수도 있다. 내부적으로, 입력(1704)은 호출 생성 요청이다. 호출 생성 요청은 앞서 언급한 바와 같이 연결 정보 및 그 외 다른 디스크립터를 포함하는 SIP 인비테이션이다. SIP 사용자 에이전트(1706)는 SDP 에이전트(1708)와 상호작용하여 멀티미디어 전송 프로토콜과 데이터 포맷 프로토콜같은 여러 프로토콜을 식별하고, 포트가, 더욱이 어느 포트가 식별된 매체 전송 프로토콜을 지원하는 지를 식별한다. SIP 사용자 에이전트(1706)는 이 호출을 서비스 콘센트레이터(1712)에 전달하고, 이어 이 요청을 서비스 응용프로그램(1714)에 전달한다. 이는 도 18을 참고하여 다시 설명된다.
도 18은 서비스 콘센트레이터(1712)를 더욱 상세하게 설명한다. 서비스 콘센트레이터(1712)는 요청 핸들러(1802), 입력 큐(1804), 그리고 응용프로그램 핸들러(1806)를 포함하고, 응용프로그램 핸들러(1806)는 비스 응용프로그램플랫폼(1810)에 연결된 작업자 스레드(1808)를 가진다. 작업자 스레드(1808)는 무선연결, 동축케이블, 광섬유 연결등의 통신 링크를 포함한다. 서비스 콘센트레이터(1712)는 다수의 여러 다른 프로토콜 하에서 기능하는 요청 핸들러(1802)를 가질 수 있다. 따라서, SDP 에이전트(1708)와 MTP 에이전트(1710)는 식별된 프로토콜을 지원할 수 있는 특정 요청 핸들러(1802)에 호출을 전달하도록 SIP 에이전트(1706)에게 지시한다. 요청 핸들러(1802)는 서비스 요청을 승낙하여 서비스 요청을 입력 큐(1804)에 전달한다. 입력 큐(1804)는 작업자 스레드(1808)의 서비스 요청 처리가 가능하다고 응용프로그램 핸들러(1806)가 표시할 때까지 서비스 요청을 홀딩한다. 다량의 요청이 큐에 저장될 수 있기 때문에, 응용프로그램 핸들러(1806)보다 더 많은 요청 핸들러(1802)를 지원할 수 있다. 응용프로그램 핸들러(1806)가 빈 작업자 스레드(1808)를 표시할 때, 큐에 저장된 서비스 요청이 제거되어 서비스 응용프로그램 플랫폼(1810)에 전달된다. 요청한 서비스가 실행되면, 응용프로그램 핸들러(1806)는 결과를 서비스 요청이 표시한 주소로 되보낸다. 응용프로그램 핸들러(1806)는 결과를 출력 큐에 되보낼 수 있고, 다시 결과를 요청 주소로 보낼 수 있다.
요청이 처리되고 응용프로그램 핸들러(1806)가 완료 서비스 요청을 적절한 주소로 다시 보낸 경우, 에이전트(1706)는 호출 연결을 종료하여서, 다음 서비스 요청을 발생시키기 위해 요청 핸들러를 비운다. 요청 핸들러는 요청을 완료하기 전에 해제될 수 있다.
본 발명이 TCP/IP 통신 표준과 SIP(Session Initiation Protocol)나RTSP(Realtime Transport Signaling Protocol)을 이용하여 설명되지만, 다중 통신 프로토콜을 사용하는 것도 가능하다. 따라서, 제어 모듈(310)같은 제어 모듈이 프로토콜에 독립적일 수 있다. 도 19는 프로토콜 독립형 제어 모듈(190)을 도시한다. 프로토콜 독립형 제어 모듈(PICM)(1900)은 앞서 설명한 매체 세션 틀에 따라 여러 설계 레벨을 도시한다. 특히, PICM(1900)은 네트워크층(1902), 전송층(1904), 세션층 신호전달 프로토콜(1906), 세션 메시지 프로세서(1908), 그리고 응용프로그램 구성성분(1910)을 포함한다. 앞서 언급한 매체 세션 틀과 마찬가지로, PICM(1900)은 네트워크층(1902)에 대해 종래의 인터넷 프로토콜을 이용한다. 전송층(1904)은 한개 이상의 전송 프로토콜을 포함하지만, 보다 많은 전송 프로토콜을 포함할 수도 있다. 예를 들어, 도 19는 UDP 및 TCP 프로토콜을 포함하는 것으로 전송층(1904)을 도시한다. 일반적으로, 전송층(1904)은 PICM(1900)이 지원할 것으로 기대되는 각각의 프로토콜을 지원할 수 있어야 한다. 도 19는 지능형 리소스 로케이터 응용프로그램(1912), 서비스 관리자 응용프로그램(1914), 루팅 관리자 응용프로그램(1916), 어카운팅 관리자 응용프로그램(1918), 그리고 제 3자 호출 제어 응용프로그램(1920)을 지원하는 PICM(1900)을 또한 도시한다. 이 응용프로그램들은 예시적인 것으로, 더할 수도 있고 덜할 수도 있다. 층(1906, 1908, 1910)은 도 20-24를 참고하여 설명된다.
도 20은 세션층 신호전달 프로토콜(1906)의 구성성분 설계를 도시한다. 이는 도 15-18에서 설명한 매체 세션 틀 프로토콜과 유사하다. 특히, 세션층 신호전달 프로토콜(1906)은 네트워크 엔드포인트 바인딩층(2002), 프로토콜 연결층(2004),프로토콜 스택(2006), 그리고 세션 프로토콜 구성성분 응용프로그램 제공자 인터페이스(API)(2008)를 포함한다.
네트워크 엔드포인트 바인딩 층(2002)은 송신에 필요한 데이터 스트림 소켓에 대응한다. 예를 들어, 네트워크 엔드포인트 바인딩은 RTSP에 대해 TCP 소켓(또는 포트)을, SIP에 대해 UDP 소켓을 생성할 수 있다. 각각의 소켓이나 포트는 요청 핸들러에 대응한다. 요청 핸들러는 지정된 프로토콜과 함께 미리 생성되도록 설계될 수도 있고, 지정된 프로토콜을 포함한 요청에 따라 생성되도록 설계될 수도 있다. 프로토콜 연결층(2004)은 네트워크 엔드포인트를 통해 전달되거나 수신되는 메시지들을 처리하는 기능을 내장한다. 프로토콜 스택(2006)은 아래 설명되는 세션 메시지를 발생시키는 기능을 내장한다. 세션 프로토콜 성분 API는 프로세서 스택에 대한 세션 메시지 프로세서 접근을 허용한다. 일반적으로, 이 시스템은 다중-스레드 멀티플렉싱 기능을 이용하지만, 다른 직렬/병렬 구성으로 동작할 수도 있다.
앞서 언급한 바와 같이, 프로토콜 스택(2006)은 세션 메시지 프로세서(1908)에 네트워크 상에서 전달되는 각각의 요청이나 응답에 대한 세션 메시지를 발생시킨다. 세션 메시지 프로세서는 세션 메시지를 수신하고, 응용프로그램 호출과 데이터 프로토콜을 결정한다. 예를 들어, 세션 메시지 프로세서(1908)가 SIP 등록 메시지를 수신할 경우, 세션 메시지 프로세서(1908)는 SIP 프로토콜을 불러오고, 지능형 리소스 로케이터(또는 리소스 로케이터)를 호출하여, SIP 응용프로그램 및 서비스에 대한 SIP REGISTER FUNCTION(SIP 등록 기능)을 개시한다. 응용프로그램은 호출을 수용하거나 거절할 수 있다.
도 21은 세션 메시지 프로세서(1908) 구성성분 설계를 도시한다. 세션 메시지 프로세서(1908)는 다수의 프로토콜 구성성분(2102)을 포함하고, 이 경우에는 SIP 성분, RTSP 성분, 그리고 H.323 성분, 세션 테이블(2104)이 포함된다.
요청을 전달할 때, 세션 메시지 프로세서는 세션 객체나 태그를 발생시켜서 세션 테이블(2104)에 저장하게 한다. 세션 객체는 특정 세션 및 세션 상태에 대한 고유 식별자를 포함한다. 예를 들어, SIP 요청은 고유 식별자로 호출 식별 스트링을 이용할 수 있고, 세션 객체는 응용프로그램이나 서비스 인바이트에 관련된 세부사항을 내장할 수 있다.
PICM(1900)은 한개 이상의 응용프로그램을 포함한다. 예를 들어, PICM(1900)은 리소스 로케이터(1930), 루팅 관리자(1940), 서비스 관리자(1950), 어카운팅 관리자(1960), 그리고 제 3자 호출 제어(3PCC)(1970)를 포함할 수 있다. 이들 응용프로그램 중 일부는 부분적으로 루팅 관리자(1002), 로케이션 서비스(1004), 그리고 리소스 관리자(1006)에 대응한다.
리소스 로케이터(1930)는 응용프로그램(312)이나 서비스(314)(도 5)같은 특정 리소스나 응용프로그램과 서비스가 어디서 어떻게 접근되는 지를 저장하는 기능을 제공한다. 여러 다른 위치 프로토콜이 사용될 수 있지만, 인터넷 환경에서는 특정 리소스의 위치가 고유 URL이다. 위에서 어떻게 라는 사항은 SIP, RTSP, 등처럼 응용프로그램이나 통신 프로토콜 요청사항 표시를 포함한다.
리소스 로케이터(1930)는 여러 종류의 리소스 위치를 이용할 수 있다. 한가지 가능한 리소스 위치 방법은 동적 리소스 등록을 포함한다. 이 경우에, 개별 리소스는 등록 메시지를 리소스 로케이터(1930)에 전송한다. 이 메시지들은 리소스인 것, 가령, 텍스트-스피치 컨버터, 신호 프로토콜인 것, 가령, SIP 프로토콜, 그리고 로케이션인 것, 가령, URL 주소를 포함한다. 통상적으로, 각각의 리소스는 리소스 로케이터(1930)에 리프레셔 등록을 전송하여, 리소스 정보가 만료되거나 실효되는 일이 없게 한다. 리소스는 이 정보 제거를 위해 리소스 로케이터(1930)로 등록탈퇴할 수도 있다. 다른 종류의 리소스 등록이 정적(static)일 수도 있다. 본 예에서, "누가 여기 있나요?"같은 일부 종류의 투표 요청이나 수작업 입력에 의해 리소스 로케이터(1930)에 대한 정보 입력은 가용 리소스에 전달되는 메시지를 타이핑한다. 일반적으로, 등록 정보는 영구 메모리(1404)(도 14)같은 영구 메모리에 저장된다.
루팅 관리자(1940)는 신호 전달을 위한 규정을 내장한다. 예를 들어, 루팅 관리자(1940)가 응용프로그램과 서비스간에 신호를 보낸다. 루팅 규정은 여러 요청에 대한 루팅 해법을 제공하기 위해 서비스 관리자에 의해 이용된다. 여러 다른 루팅 규정이 사용될 수 있고, 일부 예가 아래에 제시된다.
- 로드 밸런싱 루팅(load balancing routing): 공지된 등록 리소스 세트가 주어졌을 때, 이 알고리즘은 공지된 리소스 사이에 로드 밸런싱을 얻기 위해 간단한 라운드 로빈 접근법을 이용한다.
- 리스트 비지 루팅(least busy routing): 공지된 등록 리소스 세트와 로드 상태 정보를 과정 모니터로부터 부여받았을 때(도 12, 13), 이 알고리즘은 요청에 대한 적절한 리소스를 선택하기 위한 가장 덜 바쁜 접근법을 이용한다.
- 타임 베이스 루팅(time based routing): 공지된 등록 리소스 세트와 시간-기반의 루팅 규정이 주어졌을 때, 알고리즘은 적절한 리소스를 선택한다.
다른 루팅 규정도 물론 가능하다. 한개보다 많은 루팅 관리자가 각각의 PICM에 대해 존재할 것이고, 서비스 관리자는 개별 요청 매개변수를 바탕으로 적절한 루팅 관리자를 얻을 것이다. 게다가, 루팅 관리자는 아웃바운드 관점이나 인바운드 관점으로부터 해법을 얻도록 설정될 수 있다. 다시 말해서, 루팅 해법은 송신지 기반일 수도 있고, 수신지 기반일 수도 있다. 더우기, 루팅 관리자는 다음 루트 결정을 돕기 위해 루팅 해법의 데이터베이스를 유지관리할 수 있다. 예를 들어, 간단한 로드밸런싱 요청을 이용하여 100개의 등록 리소스가 요청을 서비스할 수 있다. 첫 번째 요청은 예를 들어 루트 1에서 전달될 수 있다. 이 정보는 저장되어, 다음 요청이 루트 2 결정을 위해 루트 1에 관한 정보를 이용할 수 있다.
서비스 관리자(1950)는 응용프로그램 및 서비스에 대한 요청이 충족되는 지를 확인한다. 도 22는 서비스 관리자(1950)의 동작에 관한 기능 도표(2200)를 도시하며, 도 23은 서비스 관리자(1950)의 동작을 설명하는 순서도(2300)이다. 도표(2200)는 리소스 클라이언트(2210)(호출자(302)(도 5)나 응용프로그램(1102) 요청 서비스(도 11)에 대응), PICM(1900), 리소스 기억 메모리(2220)(로케이션 서비스(1004)(도 10)나 영구 기억장치(1404)(도 14)에 대응), 일련의 리소스(22301~n), 그리고 신뢰할만한 메시지 큐(2240)를 포함한다. 이는 어카운팅 관리자의 설명과 연계하여 아래에서 더욱 자세하게 설명될 것이다. 순서도(2300)는PICM(1900)의 초기화로 시작한다(단계2302). PICM(1900)이 다중 전송 프로토콜을 지원할 수 있지만, 본 예는 단순화를 위해 SIP에 제한된다. 그다음, 리소스(22301~n)을 포함한 일련의 리소스가 초기화된다(단계 2304). 물론 여러 종류의 리소스가 가용하지만, 단일 리소스가 요청되고 공급되는 경우만 생각한다. 이 리소스들이 PICM(1900)에 등록한다(단계 2306). 등록은 리소스 등록 측면에서 동적일 수 있고 리소스 폴링 및 수동 입력 측면에서 정적일 수 있는 것으로서, SIP일 경우에는 프로토콜 정보를 포함하고, URL일 경우에는 로케이션 정보를 포함한다. PICM(1900)은 기억 메모리(2220)에 정보를 저장한다(단계 2308). 등록 단계는 타이머나 날짜 지정 태그같은 유효기간 데이터 설정 단계를 포함할 수 있다(단계 2308a). 그래서, 등록이 업데이트되지 않을 경우 어떤 시간 이후 또는 이런 날짜에 의해 등록이 만료된다. 등록이 메모리에 성공적으로 저장된 후, PICM(1900)은 등록 승인 메시지를 리소스에 보낸다(단계 2310). 만료 데이터가 등록 데이터에 포함되면, PICM(1900)은 그 등록을 업데이트할 필요가 있을 때를 표시하는 정보를 리소스에 전달할 수 있다(단계 2310a). 리소스는 승인 메시지를 받지 못할 경우 얼마 시간 이후에 다시 등록을 시도할 것이다.
리소스등록이 완료되면, PICM(1900)은 특정 리소스 이용 요청을 처리할 수 있다. 클라이언트는 PICM(1900)에 리소스 요청을 전송함으로서 리소스를 요청한다(단계 2312). 본 경우에, 클라이언트는 SIP INVITE 메시지를 전송한다. 서비스 관리자(1950)는 PICM(1900)이 SIP INVITE 메시지를 수신하였는 지를 결정한다(단계2314). 서비스 관리자(1950)는 그후, 요청을 전송할 한개 이상의 리소스 위치를 식별하기 위해 메모리에 접근하고자 리소스 로케이터를 이용한다(단계 2316). 한개 이상의 리소스가 식별되면, 서비스 관리자(1950)는 식별된 리소스 중 특정한 하나에 요청을 전달하는 데 적절한 루트를 선택하기 위해 루팅 관리자(1960)에 접근한다(단계 2318a). 루팅 관리자는 특정 시스템 루팅 프로토콜을 바탕으로 루트를 선택한다. 루트 선택과 동시에, 세션 객체가 또한 발생되어 세션 표에 저장하기 위해 서비스 관리자에게 되돌아온다(단계 2318b). 세션 객체는 루팅과 동시에 발생될 필요가 없다. 그후 서비스 요청은 리소스의 적절한 사례에 도달할 때까지 다음 수신지에 전달된다(단계 2320). 수신하면, 리소스 사례는 요청이 승인되어야 하는 지 거절되어야 하는 지를 결정한다(단계 2322). 승인되면, 요청 승인 응답이 PICM(1900)에 전송된다(단계 2324). 거절되면, 제어가 단계 2316으로 되돌아가 그 다음으로 가용한 리소스를 식별한다. 요청 승인 응답을 수신하면, PICM(1900)은 URL 표시에서 리소스가 승인한 요청을 클라이언트에 전송한다(단계 2326). 그후 클라이언트는 요청 처리를 위해 적절한 리소스에 직접 연결된다(단계 2328).
어카운팅 관리자(1960)는 PICM(1900)에 의해 실행된 기능을 바탕으로 어카운팅 이벤트를 발생시킨다. 한가지 가능한 어카운팅 이벤트는 PICM과 리소스 요청의 동작의 세부사항을 알리는 서비스 관리자(1950)에 의해 발생되는 호출 상세 레코드이다. 부가적으로, 서비스 관리자는 응답 리소스의 상세사항을 알리는 호출 상세 리포트를 발생시킬 수 있다. 이 레코드는 호출 상세 레코드를 바탕으로 어카운팅 이벤트를 발생시키는 어카운팅 관리자에게 생성된다. 어카운팅 이벤트는 신뢰할만한 메시지 큐(2240)나 다른 종류의 파일 구조처럼 어카운팅 메모리 시스템에 저장될 수 있다. 일반적으로, 어카운팅 이벤트는 클라이언트 정보, 이벤트 종류 정보, 프로토콜 이용 정보, 리소스 이용 정보 등과 같은 서비스의 대금 청구에 필요한 정보를 레코드할 수 있다.
PICM(1900)이 요청 클라이언트를 적절한 리소스 사례에 연결한 경우, 3PCC 응용프로그램(1970)이 세션을 제어한다. 핸드쉐이킹 프로토콜, 호출 감지 및 종료 프로토콜이이 당 분야에 잘 알려져 있어서 더 이상 설명하지 않는다.
도 24는 앞서 언급한 시스템의 견고함을 설명하는 구조(2400)를 도시한다. 특히, 구조(2400)는 클라이언트(2410), PICM(2420)(페일-오버 백업(2422)을 포함할 수 있음), 저장 메모리(2430), 프록시PICM(2440), 네트워크(2450), 그리고 네트워크(2450)에 연결된 리소스(2460)를 포함한다. 시스템의 크기는 시스템에 추가된 각각의 프록시 PICM에 의해 증가된다. 따라서, 초기 클라이언트 요청이 PICM(2420)에 도달할 때, PICM(2420)은 앞서 설명한 방식으로 요청을 실제 서비스할 프록시 PICM으로 이 요청을 리디렉션할 수 있다. 더욱이, PICM(또는 프록시 PICM)이 인터넷을 통해 리소스에 접근하기 때문에, 시스템에 의해 이용할 수 있는 리소스 숫자는 PICM의 시간당 처리량에 의해 크게 제한된다. 따라서, 시스템에 추가된 각각의 프록시는 전체 시스템 처리량을 증가시키고, 전체 시스템 능력을 증가시킨다.

Claims (60)

  1. 응용프로그램을 멀티플렉싱하기 위해 한개 이상의 프로세서에서 실행되는 방법으로서, 상기 방법은,
    - 한개 이상의 응용프로그램에 접근하는 한개 이상의 접근 서버를 제공하고,
    - 상기 한개 이상의 응용프로그램에 접근하기 위해 접근 서버에서 한명 이상의 사용자로부터 요청을 수신하며,
    - 수신한 요청을 바탕으로, 상기 한개 이상의 접근 서버와 상기 한명 이상의 사용자 사이에 통신 링크를 구축하고,
    - 수신한 요청을 입력 요청 큐에 저장하며,
    - 요청한 응용프로그램으로의 가용 통신 경로를 확인하고,
    - 통신 경로가 가용할 경우, 입력 요청 큐와 한개 이상의 응용프로그램 사이클에 통신 경로를 구축하며,
    - 저장된 요청을 제거하고, 그리고
    - 저장한 요청을 요청받은 응용프로그램에 전송하는,
    이상의 단계를 포함하는 것을 특징으로 하는, 응용프로그램을 멀티플렉싱하기 위해 한개 이상의 프로세서에서 실행되는 방법.
  2. 제 1 항에 있어서, 상기 방법은,
    - 수신한 요청을 바탕으로 매체 전송 프로토콜을 식별하는
    단계를 추가로 포함하고, 이때 구축된 통신 링크가 식별된 매체 전송 프로토콜을 전송할 수 있는 것을 특징으로 하는 방법.
  3. 제 2 항에 있어서, 상기 방법은,
    - 송신한 데이터의 정확성을 확인하고, 그리고
    - 부정확한 데이터를 다시 전송하는,
    이상의 단계를 추가로 포함하는 것을 특징으로 하는 방법.
  4. 제 1 항에 있어서, 통신 링크를 구축하는 상기 단계는,
    - 세션 개시 프로토콜, H.323 프로토콜, MGCP 프로토콜, MEGACO 프로토콜, 그리고 H.248 프로토콜 중 한개 이상
    을 이용하는 것을 특징으로 하는 방법.
  5. 제 2 항에 있어서, 매체 전송 프로토콜을 식별하는 상기 단계는,
    - 세션 설명 프로토콜
    을 이용하는 것을 특징으로 하는 방법.
  6. 제 2 항에 있어서, 식별된 매체가 실시간 전송 프로토콜(RTP)인 것을 특징으로 하는 방법.
  7. 제 1 항에 있어서, 요청을 수신하는 상기 단계는,
    - 요청 핸들러에서 요청을 수용하고,
    - 서비스 요청을 발생시키며, 그리고
    - 발생한 서비스 요청을 저장을 위해 입력 요청 큐에 전송하는,
    이상의 단계를 추가로 포함하는 것을 특징으로 하는 방법.
  8. 응용프로그램을 멀티플렉싱하기 위해 한개 이상의 프로세서에서 실행되는 방법으로서, 상기 방법은,
    - 한개 이상의 요청 핸들러와 한개 이상의 응용프로그램 핸들러를 초기화하고,
    - 한개 이상의 응용프로그램에 접근하기 위해 한명 이상의 사용자로부터 한 개 이상의 요청을 수용하며,
    - 수용한 요청을 초기화된 요청 핸들러에 전달하고,
    - 전달된 수용 요청을 바탕으로 서비스 요청을 완료하며,
    - 입력 큐에 완료된 서비스 요청을 밀어넣고,
    - 입력 큐에 놓인 완료된 서비스 요청을 얻기 위해 응용프로그램 핸들러를 이용하며,
    - 완료된 서비스 요청을 한개 이상의 응용프로그램에 전송하고,
    - 완료된 서비스 요청을 실행하며, 그리고
    - 완료된 서비스를 되돌려보내는,
    이상의 단계를 포함하는 것을 특징으로 하는 응용프로그램을 멀티플렉싱하기 위해 한개 이상의 프로세서에서 실행되는 방법.
  9. 서비스 멀티플렉싱 장치로서, 이 장치는,
    - 한개 이상의 응용프로그램에 접근할 수 있는 한개 이상의 접근 서버,
    - 한 개 이상의 에이전트와 한개 이상의 서비스 콘센트레이터를 포함하는 한 개 이상의 접근 서버, 그리고
    - 한개 이상의 응용프로그램 핸들러, 한개 이상의 입력 서비스 큐, 그리고 한개 이상의 요청 핸들러를 포함하는 한개 이상의 서비스 콘센트레이터
    를 포함하여, 상기 한개 이상의 응용프로그램에 접근하기 위해 다중 요청을 수신하도록 상기 한개 이상의 접근 서버가 설정되고, 그리고 상기 한개 이상의 응용프로그램에 접근하기 위해 다중 요청을 멀티플렉싱하도록 상기 한개 이상의 서비스 콘센트레이터가 설정되는 것을 특징으로 하는 서비스 멀티플렉싱 장치
  10. 제 9 항에 있어서, 상기 한개 이상의 에이전트는,
    - 한개 이상의 SIP 사용자 에이전트
    를 포함하는 것을 특징으로 하는 장치.
  11. 제 10 항에 있어서, 상기 한개 이상의 에이전트는,
    - 한개 이상의 SDP 에이전트
    를 포함하는 것을 특징으로 하는 장치.
  12. 제 11 항에 있어서, 상기 한개 이상의 에이전트는,
    - 한개 이상의 MTP 에이전트
    를 포함하는 것을 특징으로 하는 장치.
  13. 제 12 항에 있어서, 상기 한개 이상의 MTP 에이전트는,
    - 실시간 전송 프로토콜
    을 포함하는 것을 특징으로 하는 장치.
  14. 제 9 항에 있어서, 상기 한개 이상의 서비스 콘센트레이터는,
    - 한개 이상의 서비스 출력 큐
    를 추가로 포함하는 것을 특징으로 하는 장치.
  15. 제 9 항에 있어서, 상기 장치는,
    - 서비스 요청을 전송하기 위한 한개 이상의 송신 클라이언트, 그리고
    - 처리된 요청을 수신하기 위한 한개 이상의 수신 클라이언트
    를 추가로 포함하는 것을 특징으로 하는 장치.
  16. 컴퓨터 프로그램 프로덕트로서, 상기 컴퓨터 프로그램 프로덕트는,
    - 한개 이상의 응용프로그램에 접근하기 위해 한개 이상의 요청을 제어하는 데이터를 처리하고자 내장된 컴퓨터 판독 코드를 포함하는 컴퓨터 이용 매체
    를 포함하고, 상기 컴퓨터 이용 매체는,
    - 상기 한개 이상의 응용프로그램에 접근하기 위해 한개 이상의 요청을 수신하도록 설정되는 요청 수신 모듈,
    - 상기 한개 이상의 응용프로그램에 접근을 요청하는 한개 이상의 클라이언트와의 통신 링크를 구축하도록 설정되는 통신 구축 모듈,
    - 상기 한개 이상의 수신 요청을 저장하도록 설정되는 저장 모듈,
    - 상기 한개 이상의 응용프로그램에 접근하게 할 수 있는 통신 경로 여부를 확인하기 위한 확인 모듈, 그리고
    - 상기 한개 이상의 응용프로그램과의 통신 링크를 또한 구축하도록 설정되는 상기 통신 구축 모듈
    을 포함하는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  17. 제 16 항에 있어서, 상기 컴퓨터 프로그램 프로덕트는,
    - 서비스 콘센트레이션 모듈
    을 추가로 포함하고, 상기 서비스 콘센트레이션 모듈은,
    - 저장 모듈에 저장될 한개 이상의 서비스 요청을 발생시키는 한개 이상의 요청 핸들러, 그리고
    - 저장된 요청을 제거하여 처리를 위해 저장된 요청을 상기 한개 이상의 응용프로그램에 전송하는 한개 이상의 응용프로그램 핸들러
    를 추가로 포함하는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  18. 제 16 항에 있어서, 상기 한개 이상의 클라이언트에 의해 표시되는 한개 이상의 주소에 한개 이상의 처리 요청을 출력하도록 상기 통신 모듈이 설정되는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  19. 제 16 항에 있어서, 전달하기 전에 한개 이상의 처리 요청을 저장하도록 상기 저장 모듈이 설정되는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  20. 제 17 항에 있어서, 상기 컴퓨터 프로그램 프로덕트는,
    - 호출 제어를 제공하도록 설정되는 SIP 에이전트 모듈
    을 추가로 포함하는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  21. 제 20 항에 있어서, 상기 컴퓨터 프로그램 프로덕트는,
    - 세션 설명을 제공하도록 설정되는 SDP 에이전트 모듈
    을 추가로 포함하여, SIP 에이전트 모듈이 상기 한개 이상의 요청을 호환가능한 요청 핸들러 모듈에 전송하는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  22. 제 21 항에 있어서, 상기 컴퓨터 프로그램 프로덕트는,
    - 전송 프로토콜을 제공하도록 설정되는 매체 전송 프로토콜 에이전트
    를 추가로 포함하는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  23. 컴퓨터 프로그램 프로덕트로서, 상기 컴퓨터 프로그램 프로덕트는,
    - 한개 이상의 응용프로그램에 접근하기 위해 한개 이상의 요청을 제어하는 데이터를 처리하고자 내장된 컴퓨터 판독 코드를 포함하는 컴퓨터 이용 매체
    를 포함하고, 상기 컴퓨터 이용 매체는,
    - 상기 한개 이상의 응용프로그램에 접근하기 위해 한개 이상의 요청을 수신하도록 설정되는 요청 수신 모듈,
    - 상기 한개 이상의 응용프로그램에 접근을 요청하는 한개 이상의 클라이언트와의 통신 링크를 구축하도록 설정되는 제 1 통신 구축 모듈,
    - 상기 한개 이상의 수신 요청을 저장하도록 설정되는 저장 모듈,
    - 상기 한개 이상의 응용프로그램에 접근하게 할 수 있는 통신 경로 여부를 확인하기 위한 확인 모듈, 그리고
    - 상기 한개 이상의 응용프로그램과의 통신 링크를 구축하도록 설정되는 제 2 통신 구축 모듈
    을 포함하는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  24. 제 23 항에 있어서, 상기 컴퓨터 프로그램 프로덕트는,
    - 한개 이상의 처리 요청을 수신하기 위해 한개 이상의 주소와 통신 링크를구축하도록 설정되는 제 3 통신 구축 모듈
    을 추가로 포함하는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  25. 전송 프로토콜에 상관없이 한개 이상의 리소스의 한개 이상의 제공자에게 상기 한개 이상의 리소스에 대한 한개 이상의 요청을 연결하기 위한 방법으로서, 상기 방법은,
    - 한개 이상의 리소스에 대한 한개 이상의 요청을 수신하고,
    - 상기 한개 이상의 요청에 관련된 전송 프로토콜을 결정하며,
    - 결정된 전송 프로토콜을 지원할 수 있는 상기 한개 이상의 요청 리소스의 한 개 이상의 제공자를 식별하고, 그리고
    - 한개 이상의 요청을 한 개 이상의 제공자에게 전달(routing)하는,
    이상의 단계를 포함하는 것을 특징으로 하는, 전송 프로토콜에 상관없이 한개 이상의 리소스의 한개 이상의 제공자에게 상기 한개 이상의 리소스에 대한 한개 이상의 요청을 연결하기 위한 방법.
  26. 제 25 항에 있어서, 수신 단계는,
    - 각각의 포트가 다수의 전송 프로토콜 중 하나를 수신할 수 있도록 다수의 수신 포트를 제공하고,
    - 수신한 한개 이상의 요청을 한개 이상의 프로토콜 핸들러에게 전송하며, 그리고
    - 상기 한개 이상의 수신 요청을 바탕으로 한개 이상의 세션 메시지를 발생시키는,
    이상의 과정을 추가로 포함하는 것을 특징으로 하는 방법.
  27. 제 26 항에 있어서, 전송 프로토콜을 결정하는 상기 단계는 전송 프로토콜 결정을 위해 상기 한개 이상의 발생된 세션 중 한개 이상을 이용하는 것을 특징으로 하는 방법.
  28. 제 25 항에 있어서,
    - 상기 한개 이상의 요청에 관한 상태 정보를 유지관리하는,
    단계를 추가로 포함하는 것을 특징으로 하는 방법.
  29. 제 28 항에 있어서, 상태 정보를 유지관리하는 상기 단계는,
    - 세션 상태에 관한 정보를 포함하는 세션 객체를 생성하고, 그리고
    - 고유 식별자를 이용하여 세션 객체를 저장하는,
    이상의 과정을 포함하는 것을 특징으로 하는 방법.
  30. 제 25 항에 있어서, 상기 식별 단계는,
    - 한개 이상의 리소스의 한개 이상의 제공자에 대한 정보를 등록하는
    과정을 포함하는 것을 특징으로 하는 방법.
  31. 제 30 항에 있어서, 상기 정보 등록 단계는,
    - 한개 이상의 등록된 제공자 각각에 대해 한개 이상의 고유 위치를 저장하고,
    - 상기 한개 이상의 등록 제공자각각이 지원하는 전송 프로토콜을 저장하며, 그리고
    - 상기 한개 이상의 제공자 각각에 의해 제공되는 상기 한개 이상의 리소스를 나타내는 정보를 저장하는,
    이상의 과정을 포함하는 것을 특징으로 하는 방법.
  32. 제 30 항에 있어서, 한개 이상의 리소스의 한개 이상의 제공자를 등록하는 상기 단계는,
    - 가용 리소스의 폴링(polling)
    을 포함하는 것을 특징으로 하는 방법.
  33. 제 30 항에 있어서, 식별 단계는 등록 정보를 이용하는 과정을 포함하는 것을 특징으로 하는 방법.
  34. 제 25 항에 있어서, 전달(routing) 단계는 전달 규정(routing rules)을 적용하는 과정을 추가로 포함하는 것을 특징으로 하는 방법.
  35. 제 34 항에 있어서, 전달(routing) 단계가 전달 규정(routing rules)을 적용하는 과정을 포함하는 것을 특징으로 하는 방법.
  36. 제 25 항에 있어서,
    - 상기 한개 이상의 수신 요청을 바탕으로 어카운팅 이벤트를 발생시키는,
    단계를 추가로 포함하는 것을 특징으로 하는 방법.
  37. 제 36 항에 있어서, 어카운팅 이벤트를 발생시키는 단계는 상기 한개 이상의 제공자를 또한 바탕으로 하는 것을 특징으로 하는 방법.
  38. 제 25 항에 있어서,
    - 상기 한개 이상의 요청을 충족시키기 위해 상기 한개 이상의 제공자에 대한 호출 연결을 구축하고, 그리고
    - 호출을 제어하는,
    이상의 단계를 추가로 포함하는 것을 특징으로 하는 방법.
  39. 제 25 항에 있어서,
    - 상기 한개 이상의 제공자 식별을 위해 한개 이상의 프록시 콘트롤러에 상기 한개 이상의 수신 요청을 전달하는
    단계를 추가로 포함하는 것을 특징으로 하는 방법.
  40. 리소스 요청을 리소스 제공자와 연결하기 위한 장치로서, 상기 장치는,
    - 한개 이상의 리소스에 대한 한개 이상의 요청을 수신할 수 있는 콘트롤러,
    - 한개 이상의 요청에 관련된 한개 이상의 전송 프로토콜을 결정할 수 있는 프로토콜 스택,
    - 결정된 전송 프로토콜을 지원할 수 있는 한개 이상의 요청 리소스의 한개 이상의 제공자를 식별할 수 있는 리소스 로케이터, 그리고
    - 한개 이상의 제공자에게 이 요청을 전달(routing)하는 라우터(router),
    를 포함하는 것을 특징으로 하는 리소스 요청을 리소스 제공자와 연결하기 위한 장치.
  41. 제 40 항에 있어서, 상기 콘트롤러가 한개 이상의 프로토콜 핸들러를 포함하는 것을 특징으로 하는 장치.
  42. 제 40 항에 있어서, 상기 장치는
    - 상기 콘트롤러에 의해 수신되는 상기 한개 이상의 요청을 바탕으로 한개 이상의 세션 메시지를 발생시키는 세션 메시지 프로세서
    를 포함하고, 상기 세션 메시지 프로세서는 상기 한개 이상의 발생된 세션 메시지를 프로토콜 스택에 전송하며,
    상기 프로토콜 스택은 한개 이상의 전송 프로토콜 결정을 위해 상기 한개 이상의 발생된 세션 메시지를 이용하는 것을 특징으로 하는 장치.
  43. 제 40 항에 있어서, 리소스 로케이터가,
    - 한개 이상의 제공자에 관한 데이터베이스 내장 정보
    를 포함하는 것을 특징으로 하는 장치.
  44. 제 43 항에 있어서, 데이터베이스에 내장된 상기 정보는,
    - 상기 한개 이상의 제공자 각각에 대한 고유 위치,
    - 상기 한개 이상의 제공자 각각에 의해 지원되는 한개 이상의 전송 프로토콜, 그리고
    - 상기 한개 이상의 제공자 각각에 의해 지원되는 한개 이상의 리소스
    를 포함하는 것을 특징으로 하는 장치.
  45. 제 44 항에 있어서, 상기 리소스 로케이터는,
    - 한개 이상의 리소스로부터 정보를 구할 수 있는 신호를 전송하기 위한 폴 발생기(poll generator)
    를 포함하는 것을 특징으로 하는 장치.
  46. 제 40 항에 있어서, 상기 라우터(router)는 규정 성분을 포함하여서, 한개이상의 요청이 전달될 한개 이상의 제공자 식별로부터 한개의 실제 제공자를 규정 성분이 선택하는 것을 특징으로 하는 장치.
  47. 제 46 항에 있어서, 규정 성분이 로드 밸런싱(load balancing) 규정을 이용하는 것을 특징으로 하는 장치.
  48. 제 46 항에 있어서, 규정 성분이 가장 한가한 규정을 이용하는 것을 특징으로 하는 장치.
  49. 제 46 항에 있어서, 규정 성분이 시간 기반의 전달(routing) 규정을 이용하는 것을 특징으로 하는 장치.
  50. 제 40 항에 있어서,
    - 수신한 한개 이상의 요청을 바탕으로 한개 이상의 어카운팅 레코드를 발생시키는 어카운팅 이벤트 발생기
    를 포함하는 것을 특징으로 하는 장치.
  51. 제 50 항에 있어서, 발생된 한개 이상의 어카운팅 레코드가 실제 제공자를 또한 바탕으로 하는 것을 특징으로 하는 장치.
  52. 제 40 항에 있어서, 상기 장치는,
    - 실제 제공자와 클라이언트 간에 호출 연결을 구축하기 위한 호출 콘트롤러
    를 포함하고, 상기 호출 콘트롤러가 호출을 제어하는 것을 특징으로 하는 장치.
  53. 제 40 항에 있어서, 상기 장치는,
    - 상기 한개 이상의 요청을 프록시 콘트롤러에 전달하기 위한 포워딩 콘트롤러(forwarding controller)
    를 포함하는 것을 특징으로 하는 장치.
  54. 컴퓨터 프로그램 프로덕트로서, 상기 컴퓨터 프로그램 프로덕트는,
    - 한개 이상의 응용프로그램에 접근하기 위해 한개 이상의 요청을 제어하는 데이터를 처리하고자 내장된 컴퓨터 판독 코드를 포함하는 컴퓨터 이용 매체
    를 포함하고, 상기 컴퓨터 이용 매체는,
    - 한개 이상의 리소스에 대해 한개 이상의 요청을 수신하도록 설정되는 요청 수신 모듈,
    - 한개 이상의 요청에 관련된 한개 이상의 전송 프로토콜을 결정하도록 설정되는 프로토콜 결정 모듈,
    결정된 한개 이상의 전송 프로토콜을 지원할 수 있는 상기 한개 이상의 요청된 리소스의 한개 이상의 제공자를 식별하도록 설정된 리소스 로케이터 모듈, 그리고
    - 식별된 한개 이상의 제공자의 실제 제공자에게 상기 한개 이상의 요청을 전달하도록 설정되는 전달 모듈(routing module)
    을 포함하는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  55. 제 54 항에 있어서, 상기 컴퓨터 프로그램 프로덕트는,
    - 프로토콜 핸들러 모듈과,
    - 세션 메신저 모듈
    을 포함하고, 이때, 상기 요청 수신 모듈은 수신한 한개 이상의 요청을 프로토콜 핸들러 모듈에 전송하도록 설정되고,
    상기 프로토콜 핸들러 모듈은 한개 이상의 전송 프로토콜을 식별하고 식별한 한개 이상의 전송 프로토콜을 세션 메신저 모듈에 전송하도록 설정되며,
    상기 세션 메신저 모듈은 수신한 한개 이상의 요청을 바탕으로 세션 메시지를 발생시키도록 설정되는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  56. 제 54 항에 있어서,
    - 한개 이상의 리소스의 상기 한개 이상의 제공자에 관한 정보를 저장하도록 설정되는 저장 모듈
    을 포함하는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  57. 제 56 항에 있어서,
    - 상기 한개 이상의 제공자에 관한 로케이션 정보,
    - 상기 한개 이상의 제공자에 의해 지원되는 전송 프로토콜 정보, 그리고
    - 한개 이상의 제공자에 관련된 상기 한개 이상의 리소스
    를 저장하도록 상기 저장 모듈이 설정되는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  58. 제 54 항에 있어서,
    - 로드 밸런싱 규정(load balancing rules), 가장 한가한 규정(least busy rules), 그리고 시간 베이스 규정(time based rules)을 포함하는 전달 규정(routing rules)을 이용하여 실제 제공자에게 상기 한개 이상의 요청을 전달하도록 상기 규정 모듈이 설정되는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  59. 제 54 항에 있어서, 상기 컴퓨터 프로그램 프로덕트는,
    - 수신된 상기 한개 이상의 요청을 바탕으로 한개 이상의 어카운팅 레코드를 발생시키도록 설정되는 어카운팅 모듈
    을 포함하는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
  60. 제 59 항에 있어서, 상기 한개 이상의 제공자를 바탕으로 상기 한개 이상의 어카운팅 레코드를 발생시키도록 상기 어카운팅 모듈이 또한 설정되는 것을 특징으로 하는 컴퓨터 프로그램 프로덕트.
KR1020027016349A 2001-03-30 2002-04-01 응용프로그램 및 서비스 서버 관리를 위한 프로토콜독립형 제어 모듈을 이용한 매체 세션 틀 KR100889977B1 (ko)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US28021301P 2001-03-30 2001-03-30
US60/280,213 2001-03-30
US09/965,057 2001-09-26
US09/965,057 US7185094B2 (en) 2001-03-30 2001-09-26 Media session framework using a control module to direct and manage application and service servers
US10/113,853 US20020156900A1 (en) 2001-03-30 2002-03-29 Protocol independent control module
US10/113,853 2002-03-29
PCT/US2002/010259 WO2002079910A2 (en) 2001-03-30 2002-04-01 Media session framework using protocol independent control module to direct and manage application and service servers

Publications (2)

Publication Number Publication Date
KR20030007816A true KR20030007816A (ko) 2003-01-23
KR100889977B1 KR100889977B1 (ko) 2009-03-24

Family

ID=27381396

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020027016349A KR100889977B1 (ko) 2001-03-30 2002-04-01 응용프로그램 및 서비스 서버 관리를 위한 프로토콜독립형 제어 모듈을 이용한 매체 세션 틀

Country Status (6)

Country Link
US (1) US20020156900A1 (ko)
EP (1) EP1470489A4 (ko)
KR (1) KR100889977B1 (ko)
CN (1) CN100426266C (ko)
BR (1) BR0204493A (ko)
WO (1) WO2002079910A2 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101091910B1 (ko) * 2005-12-29 2011-12-08 삼성테크윈 주식회사 실시간 전송 프로토콜을 사용하는 비디오 서버의 제어 방법및 그 기록 매체

Families Citing this family (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7058817B1 (en) 1999-07-02 2006-06-06 The Chase Manhattan Bank System and method for single sign on process for websites with multiple applications and services
US8571975B1 (en) 1999-11-24 2013-10-29 Jpmorgan Chase Bank, N.A. System and method for sending money via E-mail over the internet
US7260635B2 (en) 2000-03-21 2007-08-21 Centrisoft Corporation Software, systems and methods for managing a distributed network
US10185936B2 (en) 2000-06-22 2019-01-22 Jpmorgan Chase Bank, N.A. Method and system for processing internet payments
US8335855B2 (en) 2001-09-19 2012-12-18 Jpmorgan Chase Bank, N.A. System and method for portal infrastructure tracking
US7113900B1 (en) 2000-10-24 2006-09-26 Microsoft Corporation System and method for logical modeling of distributed computer systems
US7606898B1 (en) 2000-10-24 2009-10-20 Microsoft Corporation System and method for distributed management of shared computers
US8849716B1 (en) 2001-04-20 2014-09-30 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US20030187992A1 (en) * 2001-05-07 2003-10-02 Steenfeldt Rico Werni Service triggering framework
WO2002099598A2 (en) 2001-06-07 2002-12-12 First Usa Bank, N.A. System and method for rapid updating of credit information
US7266839B2 (en) 2001-07-12 2007-09-04 J P Morgan Chase Bank System and method for providing discriminated content to network users
WO2003038561A2 (en) 2001-11-01 2003-05-08 First Usa Bank, N.A. System and method for establishing or modifying an account with user selectable terms
US20030101054A1 (en) * 2001-11-27 2003-05-29 Ncc, Llc Integrated system and method for electronic speech recognition and transcription
US8498871B2 (en) 2001-11-27 2013-07-30 Advanced Voice Recognition Systems, Inc. Dynamic speech recognition and transcription among users having heterogeneous protocols
US7987501B2 (en) 2001-12-04 2011-07-26 Jpmorgan Chase Bank, N.A. System and method for single session sign-on
AU2003217532A1 (en) * 2002-02-18 2003-09-09 Centrisoft Corporation Software, systems and methods for managing a distributed network
US20180165441A1 (en) 2002-03-25 2018-06-14 Glenn Cobourn Everhart Systems and methods for multifactor authentication
EP1357763A1 (en) * 2002-04-23 2003-10-29 Hewlett-Packard Company Adaptor module
US7917639B2 (en) * 2002-05-31 2011-03-29 Nokia Corporation Multimedia application interface
KR100497230B1 (ko) * 2002-07-23 2005-06-23 삼성에스디아이 주식회사 플라즈마 디스플레이 패널의 구동 장치 및 구동 방법
US20040057464A1 (en) * 2002-09-23 2004-03-25 Michael Sanders Generic Transport layer
US7058660B2 (en) 2002-10-02 2006-06-06 Bank One Corporation System and method for network-based project management
US8301493B2 (en) 2002-11-05 2012-10-30 Jpmorgan Chase Bank, N.A. System and method for providing incentives to consumers to share information
ATE352165T1 (de) * 2003-01-06 2007-02-15 Koninkl Philips Electronics Nv Anwendungsauswahl unter berücksichtigung mehrerer faktoren
US8122106B2 (en) 2003-03-06 2012-02-21 Microsoft Corporation Integrating design, deployment, and management phases for systems
US7890543B2 (en) 2003-03-06 2011-02-15 Microsoft Corporation Architecture for distributed computing system and automated design, deployment, and management of distributed applications
US7072807B2 (en) 2003-03-06 2006-07-04 Microsoft Corporation Architecture for distributed computing system and automated design, deployment, and management of distributed applications
US7689676B2 (en) 2003-03-06 2010-03-30 Microsoft Corporation Model-based policy application
US7020130B2 (en) * 2003-03-13 2006-03-28 Mci, Inc. Method and apparatus for providing integrated voice and data services over a common interface device
US7698435B1 (en) 2003-04-15 2010-04-13 Sprint Spectrum L.P. Distributed interactive media system and method
US7269562B2 (en) * 2003-04-29 2007-09-11 Intervoice Limited Partnership Web service call flow speech components
US7613822B2 (en) * 2003-06-30 2009-11-03 Microsoft Corporation Network load balancing with session information
US7567504B2 (en) * 2003-06-30 2009-07-28 Microsoft Corporation Network load balancing with traffic routing
US7606929B2 (en) 2003-06-30 2009-10-20 Microsoft Corporation Network load balancing with connection manipulation
US7636917B2 (en) 2003-06-30 2009-12-22 Microsoft Corporation Network load balancing with host status information
US7590736B2 (en) * 2003-06-30 2009-09-15 Microsoft Corporation Flexible network load balancing
US7376129B2 (en) * 2003-10-29 2008-05-20 International Business Machines Corporation Enabling collaborative applications using Session Initiation Protocol (SIP) based Voice over Internet protocol Networks (VoIP)
US7822016B2 (en) * 2004-01-20 2010-10-26 Aspect Software, Inc. IP ACD using SIP format
US7492715B2 (en) * 2004-02-27 2009-02-17 Samsung Electronics Co., Ltd. Apparatus and method for real-time overload control in a distributed call-processing environment
US7778422B2 (en) 2004-02-27 2010-08-17 Microsoft Corporation Security associations for devices
US7546082B2 (en) * 2004-03-02 2009-06-09 Telcordia Technologies, Inc. Application-layer multicast for mobile users in diverse networks
US20050246529A1 (en) 2004-04-30 2005-11-03 Microsoft Corporation Isolated persistent identity storage for authentication of computing devies
US7735085B2 (en) * 2004-05-26 2010-06-08 Qualcomm Incorporated System for application priority based on device operating mode
US20060002403A1 (en) * 2004-06-30 2006-01-05 Glenayre Electronics, Inc. Distributed IP architecture for telecommunications system
US7480244B2 (en) * 2004-07-23 2009-01-20 Samsung Electronics Co., Ltd. Apparatus and method for scalable call-processing system
US7688805B2 (en) * 2005-03-31 2010-03-30 Microsoft Corporation Webserver with telephony hosting function
US7802144B2 (en) 2005-04-15 2010-09-21 Microsoft Corporation Model-based system monitoring
US7797147B2 (en) 2005-04-15 2010-09-14 Microsoft Corporation Model-based system monitoring
US8489728B2 (en) 2005-04-15 2013-07-16 Microsoft Corporation Model-based system monitoring
CN101204061A (zh) * 2005-05-18 2008-06-18 诺基亚西门子通信有限责任两合公司 软开关中用于切换优先级比邀请消息高的后续消息的方法和计算机产品
JP2006343943A (ja) * 2005-06-08 2006-12-21 Murata Mach Ltd ファイルサーバ装置及び通信管理サーバ装置
US8549513B2 (en) 2005-06-29 2013-10-01 Microsoft Corporation Model-based virtual system provisioning
KR100921554B1 (ko) * 2005-08-30 2009-10-14 주식회사 케이티 음성통화중에 다양한 콘텐츠를 공유 및 제어할 수 있는콘텐츠공유서비스를 제공하는 시스템 및 그 방법
US8583926B1 (en) 2005-09-19 2013-11-12 Jpmorgan Chase Bank, N.A. System and method for anti-phishing authentication
US8462772B1 (en) * 2005-09-22 2013-06-11 Verizon Patent And Licensing Inc. Method and system for providing party line emulation in a SIP-based network
US7941309B2 (en) 2005-11-02 2011-05-10 Microsoft Corporation Modeling IT operations/policies
CN100437536C (zh) * 2005-11-12 2008-11-26 华为技术有限公司 一种多用户访问缓存方法和系统
CA2640745C (en) * 2006-02-27 2015-05-19 Vonage Holdings Corp. Method and system for bidirectional data transfer
US7873034B2 (en) * 2006-06-29 2011-01-18 Ubiquity Software Corporation Limited System and method for providing feature mediation and orchestration on internet protocol service networks
JP4855162B2 (ja) * 2006-07-14 2012-01-18 株式会社日立製作所 パケット転送装置及び通信システム
US8793490B1 (en) 2006-07-14 2014-07-29 Jpmorgan Chase Bank, N.A. Systems and methods for multifactor authentication
US20080031232A1 (en) * 2006-08-03 2008-02-07 Bluenote Networks, Inc. Web services and plug-in framework in VOIP environment
US8451725B1 (en) 2006-12-31 2013-05-28 At&T Intellectual Property Ii, L.P. Method and apparatus for distributed compositional control of end-to-end media in IP networks
US8473735B1 (en) 2007-05-17 2013-06-25 Jpmorgan Chase Systems and methods for managing digital certificates
US8004977B2 (en) * 2007-11-28 2011-08-23 Alcatel Lucent Method of implementing packet-based resource allocation and persistent resource allocation in a wireless communication system
US8321682B1 (en) 2008-01-24 2012-11-27 Jpmorgan Chase Bank, N.A. System and method for generating and managing administrator passwords
CN101409717B (zh) * 2008-12-01 2012-07-04 用友软件股份有限公司 协议无关的soa系统和业务处理方法
US9608826B2 (en) 2009-06-29 2017-03-28 Jpmorgan Chase Bank, N.A. System and method for partner key management
CN101969435B (zh) * 2010-09-30 2013-02-20 北京新媒传信科技有限公司 基于sip-c协议的交互方法及系统
US9419957B1 (en) 2013-03-15 2016-08-16 Jpmorgan Chase Bank, N.A. Confidence-based authentication
US10148726B1 (en) 2014-01-24 2018-12-04 Jpmorgan Chase Bank, N.A. Initiating operating system commands based on browser cookies
US9813396B2 (en) 2015-10-30 2017-11-07 Rovi Guides, Inc. Methods and systems for managing content subscription data
US10178421B2 (en) 2015-10-30 2019-01-08 Rovi Guides, Inc. Methods and systems for monitoring content subscription usage
US10277663B1 (en) 2016-06-24 2019-04-30 Amazon Technologies, Inc. Management of asynchronous media file transmissions
US10728291B1 (en) * 2016-06-29 2020-07-28 Amazon Technologies, Inc. Persistent duplex connections and communication protocol for content distribution
US10147415B2 (en) * 2017-02-02 2018-12-04 Microsoft Technology Licensing, Llc Artificially generated speech for a communication session
JP7032158B2 (ja) * 2018-02-05 2022-03-08 アズビル株式会社 通信制御コントローラ
US10805113B2 (en) * 2018-08-07 2020-10-13 Dh2I Company Application transmission control protocol tunneling over the public internet
CN110730274B (zh) * 2019-10-17 2021-11-19 厦门快商通科技股份有限公司 语音抓包解析方法、系统、移动终端及存储介质
CN113037700B (zh) * 2019-12-25 2024-02-09 拓尔思天行网安信息技术有限责任公司 一种边界视频服务的负载方法、装置、设备及存储介质
CN112511528B (zh) * 2020-11-26 2022-10-11 中移（杭州）信息技术有限公司 流媒体分发方法、系统、服务器和存储介质
CN113129905B (zh) * 2021-03-31 2022-10-04 深圳鱼亮科技有限公司 一种基于多麦克风阵列节点的分布式语音唤醒系统
US11729588B1 (en) 2021-09-30 2023-08-15 T-Mobile Usa, Inc. Stateless charging and message handling
KR102352265B1 (ko) * 2021-12-08 2022-01-17 하승석 웹 애플리케이션 개발 플랫폼 제공 시스템 및 방법
CN114465991B (zh) * 2022-01-20 2024-02-09 北京嗨学网教育科技股份有限公司 软电话的连接方法和装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3370704B2 (ja) * 1992-10-12 2003-01-27 株式会社日立製作所 通信制御方法
US5537417A (en) * 1993-01-29 1996-07-16 International Business Machines Corporation Kernel socket structure for concurrent multiple protocol access
CA2118278C (en) * 1993-12-21 1999-09-07 J. David Garland Multimedia system
US5956509A (en) * 1995-08-18 1999-09-21 Microsoft Corporation System and method for performing remote requests with an on-line service network
US5758186A (en) * 1995-10-06 1998-05-26 Sun Microsystems, Inc. Method and apparatus for generically handling diverse protocol method calls in a client/server computer system
US5754774A (en) * 1996-02-15 1998-05-19 International Business Machine Corp. Client/server communication system
US5894554A (en) * 1996-04-23 1999-04-13 Infospinner, Inc. System for managing dynamic web page generation requests by intercepting request at web server and routing to page server thereby releasing web server to process other requests
US6049820A (en) * 1996-06-03 2000-04-11 International Business Machines Corporation Multiplexing of clients and applications among multiple servers
US5790789A (en) * 1996-08-02 1998-08-04 Suarez; Larry Method and architecture for the creation, control and deployment of services within a distributed computer environment
US5903877A (en) * 1996-09-30 1999-05-11 Lucent Technologies Inc. Transaction center for processing customer transaction requests from alternative media sources
US5946498A (en) * 1996-11-12 1999-08-31 International Business Machines Corporation Delivery of client remote procedure calls to a server via a request queue utilizing priority and time-out
US6182141B1 (en) * 1996-12-20 2001-01-30 Intel Corporation Transparent proxy server
US6088728A (en) * 1997-06-11 2000-07-11 Oracle Corporation System using session data stored in session data storage for associating and disassociating user identifiers for switching client sessions in a server
US6098108A (en) * 1997-07-02 2000-08-01 Sitara Networks, Inc. Distributed directory for enhanced network communication
US6105068A (en) * 1998-02-10 2000-08-15 3Com Corporation Method and apparatus for determining a protocol type on a network connection using error detection values stored within internetworking devices
US6314108B1 (en) * 1998-04-30 2001-11-06 Openwave Systems Inc. Method and apparatus for providing network access over different wireless networks
US6138159A (en) * 1998-06-11 2000-10-24 Phaal; Peter Load direction mechanism
US6542964B1 (en) * 1999-06-02 2003-04-01 Blue Coat Systems Cost-based optimization for content distribution using dynamic protocol selection and query resolution for cache server
AU2001251644A1 (en) * 2000-04-17 2001-10-30 Circadence Corporation Conductor gateway buffer prioritization
US20050038688A1 (en) * 2003-08-15 2005-02-17 Collins Albert E. System and method for matching local buyers and sellers for the provision of community based services

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101091910B1 (ko) * 2005-12-29 2011-12-08 삼성테크윈 주식회사 실시간 전송 프로토콜을 사용하는 비디오 서버의 제어 방법및 그 기록 매체

Also Published As

Publication number Publication date
CN1460212A (zh) 2003-12-03
EP1470489A4 (en) 2005-11-30
EP1470489A2 (en) 2004-10-27
CN100426266C (zh) 2008-10-15
KR100889977B1 (ko) 2009-03-24
US20020156900A1 (en) 2002-10-24
WO2002079910A2 (en) 2002-10-10
BR0204493A (pt) 2003-03-18
WO2002079910A3 (en) 2003-03-13

Similar Documents

Publication Publication Date Title
KR100889977B1 (ko) 응용프로그램 및 서비스 서버 관리를 위한 프로토콜독립형 제어 모듈을 이용한 매체 세션 틀
US7185094B2 (en) Media session framework using a control module to direct and manage application and service servers
US8300772B2 (en) Method and apparatus for emergency call processing
US7688805B2 (en) Webserver with telephony hosting function
US7809846B2 (en) Resilient application layer overlay framework for converged communication over Internet protocol networks
US9215079B2 (en) Servlet API and method for XMPP protocol
US20090113460A1 (en) Systems and methods for providing a generic interface in a communications environment
US20020159439A1 (en) Dynamically downloading telecommunication call services
US8711842B2 (en) Distributed IP-PBX signal processing
JP2009005373A (ja) セッション開始プロトコルアダプタ
JPH10116193A (ja) 通話制御装置および通話を制御する方法
US8799478B2 (en) Web services and session initiation protocol endpoint for converged communication over internet protocol networks
CN109617990B (zh) 一种融合通信资源云共享方法及系统
US20060239251A1 (en) Multi-user media client for communication devices
US7340523B2 (en) High performance call distribution system using a dispatcher and multiple processors for processing session initiation dialogs
US20050243981A1 (en) Enhanced media resource protocol messages
JP2005518715A (ja) サービス品質要求の相関
JP2008537413A (ja) ＶｏＩＰネットワークにおけるメディアサーバリソースの管理
GB2472985A (en) Media Resource Broker Location Function
CN100372346C (zh) 一种基于软交换的媒体服务器
CN1604584B (zh) 用于控制通信连接的装置和方法
Pailer et al. Using PARLAY APIs over a SIP system in a distributed service platform for carrier grade multimedia services
Chou et al. Web services for service-oriented communication
US7027430B1 (en) Communication network utilizing autonomous servers to establish a communication session
Chou et al. Web services methods for communication over IP

Legal Events

Date Code Title Description
PA0105 International application

Patent event date: 20021130

Patent event code: PA01051R01D

Comment text: International Patent Application

PG1501 Laying open of application
A201 Request for examination
PA0201 Request for examination

Patent event code: PA02012R01D

Patent event date: 20070328

Comment text: Request for Examination of Application

E902 Notification of reason for refusal
PE0902 Notice of grounds for rejection

Comment text: Notification of reason for refusal

Patent event date: 20080630

Patent event code: PE09021S01D

E701 Decision to grant or registration of patent right
PE0701 Decision of registration

Patent event code: PE07011S01D

Comment text: Decision to Grant Registration

Patent event date: 20090102

GRNT Written decision to grant
PR0701 Registration of establishment

Comment text: Registration of Establishment

Patent event date: 20090316

Patent event code: PR07011E01D

PR1002 Payment of registration fee

Payment date: 20090317

End annual number: 3

Start annual number: 1

PG1601 Publication of registration
PR1001 Payment of annual fee

Payment date: 20120306

Start annual number: 4

End annual number: 4

FPAY Annual fee payment

Payment date: 20130312

Year of fee payment: 5

PR1001 Payment of annual fee

Payment date: 20130312

Start annual number: 5

End annual number: 5

FPAY Annual fee payment

Payment date: 20140312

Year of fee payment: 6

PR1001 Payment of annual fee

Payment date: 20140312

Start annual number: 6

End annual number: 6

FPAY Annual fee payment

Payment date: 20150316

Year of fee payment: 7

PR1001 Payment of annual fee

Payment date: 20150316

Start annual number: 7

End annual number: 7

LAPS Lapse due to unpaid annual fee
PC1903 Unpaid annual fee

Termination category: Default of registration fee

Termination date: 20170209