KR100342952B1

KR100342952B1 - 사용자 애플리케이션 프로그램과 전화 통신 프로그램 간의 ａｐｉ 및 메소드를 구비한 무선 통신 장치 및 방법

Info

Publication number: KR100342952B1
Application number: KR1019990041254A
Authority: KR
Inventors: 마디스제임스이.
Original assignee: 비센트 비.인그라시아, 알크 엠 아헨; 모토로라 인코포레이티드
Priority date: 1998-09-28
Filing date: 1999-09-27
Publication date: 2002-07-04
Also published as: BRPI9904366B8; AU734151B2; EP0994614B1; EP1519532A3; AR021829A1; IL131630A; ATE291806T1; IL176365A; AU4484599A; EP0994614A2; DE69924337T2; EP1519532A2; CN1249640A; TW457823B; JP2000165960A; US6269254B1; DE69924337D1; CA2282996A1; HK1026997A1; EP0994614A3

Abstract

무선 통신 장치는, 사용자 애플리케이션 프로그램(16)과 전화 통신 프로그램(18)을 내장하는 메모리, 및 이들 간의 애플리케이션 프로그래밍 인터페이스(API)(30)를 포함한다. 이 API의 다양한 특성이 설명된다. 한 특성으로, API(30)는 호를 설립하기 위한 명령을 구비하고, 전화 통신 프로그램(18)은 이 호를 설립하기 위한 명령의 인수로서, 수개의 터미널 객체(54-58)를 식별하는 배열을 수용하여, 복수의 터미널 객체에 대한 호의 설립을 허용한다. 다른 특성으로, 이벤트들의 그룹화가 기술되고, API(30) 명령은 이 그룹들 중 한 이벤트 클래스와, 이벤트 클래스 내의 이벤트를 정의하는 ID를 함께 정의한다. 또 다른 특성으로, 전화 통신 프로그램(18) 내의 프로그램은 호 객체(50)를 생성하기 위해 호출된다. 호 객체(50)는 무선 통신 장치에 대한 무선 서비스가 설립되었는 지에 관계없이 생성된다.

Description

사용자 애플리케이션 프로그램과 전화 통신 프로그램 간의 ＡＰＩ 및 메소드를 구비한 무선 통신 장치 및 방법{RADIO COMMUNICATIONS DEVICE AND METHOD WITH API BETWEEN USER APPLICATION PROGRAM AND TELEPHONY PROGRAM AND METHOD}

본 발명은 사용자 애플리케이션 프로그램 (통상, 애플리케이션 또는 애플릿으로 지칭됨), 전화 통신 프로그램 (예를 들어, 전화 통신 클래스의 인스턴스), 및 사용자 애플리케이션 프로그램과 전화 통신 프로그램 간의 애플리케이션 프로그래밍 인터페이스(application programming interface: API)를 구비하는 무선 통신 장치에 관한 것이다. 본 발명은 API의 특징 및 API를 통해 도출되는 방법, 예를 들어 이중 모드 통화를 구현하는 방법에 관한 것이다.

Java(TM) 등과 같은 객체 지향 프로그램 언어는 플랫폼, 오퍼레이팅 시스템, 및 장치들에 걸친 프로그램의 이식성(portability)으로 인하여 점점 더 많은 장치들에서 사용되고 있다. 이는 한 장치를 위해 개발된 프로그램이 다른 특징, 예컨대 다른 오퍼레이팅 시스템이나 다른 마이크로프로세서를 갖는 다른 장치에도 보다 쉽게 사용될 수 있다는 것을 의미한다.

객체 지향 프로그램의 이러한 인기는, 이러한 언어가 널리 사용되어 왔었던 전통적인 개인용 컴퓨터나 다른 플랫폼보다 그 메모리 크기 및 처리 전력이 훨씬 작은 장치들로 확장되고 있다. 그러나, Java(TM) 등의 객체 지향 프로그램 언어들을 매우 작은 플랫폼 상에서 사용하는 데에는 여러 이유로 인하여 문제점이 발생하였다. 그러한 문제점의 일례로서, 완전한 세트의 객체 클래스(object classes)를 지원하여야 할 필요를 들 수 있다. 여기서, 객체(object)란 소정의 방식으로 다른 프로그램들과 상호 작용하는 자급식(self-contained) 컴퓨터 프로그램을 말하며, 클래스(class)란 유사한 특징을 갖는 객체들 집합에 대한 포괄적 템플레이트(generic template)를 말한다. 서로 다른 플랫폼에 걸친 프로그램의 이식성을 유지하기 위해서는 임의의 주어진 애플리케이션이 도출될 수 있도록 클래스들 내에 일관성(uniformity)이 존재하여야 하는 문제가 있다. 예를 들어, pJava(TM)는 매우 큰 클래스 라이브러리 세트를 갖고 있어, 이 클래스 라이브러리 전체 세트 중 일부 세트만을 사용하여 'eJava(TM)'라 불리는 소규모의 언어를 정의하기 위해서는 노력이 필요하게 된다.

클래스의 예로는 Java(TM) 전화 통신 API(Java(TM) telephony API: JTAPI)를 통해 도출되는 전화 통신 클래스가 있다. 이러한 클래스의 인스턴스는 'JTAPI 구현'으로 불리기도 한다.

JTAPI는 Java(TM) 기반 컴퓨터-전화 통신 애플리케이션용의 이식 가능한 객체 지향 애플리케이션 프로그래밍 인터페이스이다. 이는 월드 와이드 웹(world wide web) 상의 다음 URL(universal resource locator)에 기술되어 있다: www.javasoft.com/products/JTAPI/index.html. Java(TM) 전화 통신 API는 제1 및 제3 당사자 전화 통신 애플리케이션 도메인(domain)을 모두 지원한다. API는 개선된 전화 통신 애플리케이션에 필요한 이러한 특징들을 제공하여, 간단한 애플리케이션의 프로그래밍을 쉽게 하도록 설계된다. 자바 전화 통신 API는 API의 집합이다. 기본 호 모델과, 전화 호를 배치하고 전화 호에 응답하는 등의 초보적인 전화 통신 기능들을 제공하는 '중심(core)' API가 존재한다. 중심 API는 호 센터 및 매체 스트림 액세스와 같은 특정 전화 통신 도메인을 위한 기능을 제공하는 표준 확장 API들로 둘러싸인다. JTAPI를 사용하여 기술된 애플리케이션은 다양한 컴퓨터 플랫폼과 전화 시스템에 걸친 이식성을 제공한다. JTAPI의 버전 1.2는 1997년 12월에 공중에 발표되었다.

JTAPI의 사용의 한 예는, JTAPI 애플리케이션 또는 자바 애플릿이 단지 디스플레이, 키보드, 프로세서, 및 몇몇 메모리만을 구비한 네트워크 컴퓨터 등과 같은 원격 스테이션 상에서 실행되는 네트워크 구성이다. 이 컴퓨터는 전화 통신 자원을 관리하는 중앙화된 서버를 사용하여, 네트워크 자원을 액세스한다. JTAPI는 자바의 RMI(remote method invocation), 또는 전화 통신 프로토콜 등과 같은 원격 통신 메커니즘을 통해, 이 서버와 통신한다. 자바 전화 통신 API는 자바 언어 패키지들의 집합으로 구성된다. 각 패키지는 컴퓨터-전화 통신 애플리케이션의 소정의 특성을 위한 일부을 제공한다. 전화 통신 서버를 구현하는 것은 플랫폼 하드웨어의 능력에 따라 서버가 지원하는 패키지들을 선택하는 것이다. 애플리케이션은 현재 사용하고 있는 구현에 의해서 지원되는 패키지에 대해 문의하기도 한다. 또한, 애플리케이션 개발자는 애플리케이션이 태스크(task)를 수행하는 데 필요한 지원되는 패키지들에만 관심을 가질 수도 있다. 예를 들어, 호 패키지는 애플릿 설계자로 하여금 웹 페이지에 간단히 전화 기능을 추가할 수 있도록 하며, 많은 표준 확장 패키지들이 JTAPI 중심 패키지를 확장시킨다. 호 제어, 호 센터, 매체, 전화, 개인 데이터, 및 용량 패키지와 같은 이들 확장 패키지는 API에 부가적인 전화 통신 기능을 제공한다.

JTAPI와 같은 표준 전화 통신 API를 무선 전화나 다른 무선 통신 장치를 위한 전화 통신 API로 사용하는 것이 바람직하다.

JTAPI를 무선 통신 장치를 위한 전화 통신 API로 사용하는데, 특히 이동 통신 세계화 시스템(Global System for mobile: GSM) 무선 전화를 위한 전화 통신 API로 사용하는 데에는 많은 문제점이 있다. 일반적으로, JTAPI는 여전히 약 130k 바이트의 총 클래스 파일 크기를 갖는 63개 이상의 이벤트 클래스를 정의하여야 한다는 부담을 갖는다. 이는 무선 전화를 위한 전체 프로그램의 상대적으로 경미한 요소에 대한 실질적인 메모리 할당을 의미한다. JTAPI 호환 가능한 프로그램을 위한 메모리 요구를 줄일 필요가 있다.

GSM 통신 장치의 내용에는, 기존의 JTAPI 문법(syntax)과 메소드 시그너처(method signature)를 사용하여 쉽게 액세스될 수 없는 GSM 기능들이 존재한다. 더구나, 이중 모드 호 (음성과 팩스 호 또는 음성과 데이터 호를 위해, GSM에서 사용되는 용어)를 지원할 필요가 있으며, 이중 모드 호의 개념은 유선 전화 통신 및 JTAPI에서는 잘 알려져 있지 않다. 단순히 JTAPI에 추가하거나 JTAPI를 줄이는 것은 만족스러운 해결책을 제공하지 못하는데, 그 이유는 JTAPI에 추가하는 것은 이벤트 클래스들을 찾을 필요성을 증가시키고, 또 JTAPI를 줄이는 것은 플랫폼 간의 이식성을 허용하는 표준 API의 이점을 제거해버리기 때문이다.

따라서, 무선 통신 장치용의 전화 통신 API와 최소 메모리를 차지하고 무선 전화 통신 특유의 기능을 지원하는 관련 클래스들에 대한 필요성이 존재한다.

도 1은 본 발명의 제1 실시예에 따른 무선 전화 장치의 일례를 도시한 도면.

도 2는 본 발명의 제2 실시예에 따른 무선 전화 장치의 일례를 도시한 도면.

도 3은 도 1 및 도 2의 무선 전화 중 하나의 소프트웨어 구조를 도시한 소프트웨어 아키텍처 다이어그램.

도 4는 도 3의 JTAPI 메소드 구현을 보다 상세히 설명하는 프로그램 흐름도.

도 5 및 도 6은 도 3의 JTAPI 메소드 구현을 상세히 설명하는 흐름도.

도 7 내지 도 13은 JTAPI를 설명하는 부록 1에서 참조되는 도면.

도 1을 참조하여, 최하 계층의 하드웨어와 최상 계층의 애플리케이션 소프트웨어의 서로 다른 계층의 면에서 무선 전화를 설명한다. 무선 전화는 제1 마이크로프로세서(10)(마이크로프로세서 A), 제2 마이크로프로세서(11)(마이크로프로세서 B), 및 소정의 RF 하드웨어(13)를 포함한다. 마이크로프로세서 A 및 마이크로프로세서 B는 함께 연결된다. 마이크로프로세서 B는 RF 하드웨어(13)에 연결된다. RF 하드 웨어(13)는 적어도 수신기와 송신기를 포함한다. 또한, RF 하드웨어(13)에는 음성 통신 소자(23)들과 데이터 통신 소자(24)들이 포함된다. 음성 통신 소자에는 그 예로서 음성 코더가 포함되고, 데이터 통신 소자에는 그 예로서 데이터 모뎀이나 팩스 모뎀 등이 포함된다. 마이크로프로세서는 Des Moines, Iowa의 Microware Systems Corporation에 의해 공급되는 OS 9000 등과 같은 오퍼레이팅 시스템(14)(operating system: OS)을 구비한다. 오퍼레이팅 시스템 상에는 상용의 Java(TM) 가상 기계(virtual machine)와 같은 가상 기계(15)가 존재한다. 이 가상 기계(15) 상에서, 애플리케이션 프로그램(16)과 다양한 다른 Java(TM) 클래스(17)들이 실행된다. 이 클래스(17) 중의 하나가 JTAPI 구현(18)이다. 마이크로프로세서(11)는 호 제어, 프레이밍(framing), 및 블럭 코딩 등의 일반적 바이트 레벨의 조작과 같은 기능을 수행하는 송수신기 소프트웨어(20)를 갖는다. 송수신기 소프트웨어(20)는 공통 서비스 공급자 모듈 인터페이스(common service provider module interface: CSPMI)(22)를 통해 오퍼레이팅 시스템(14)과 통신한다.

도 1의 구성의 대안으로서, 마이크로프로세서 A 및 마이크로프로세서 B는 도 2의 가상선으로 도시된 것과 같이 단일 집적 회로(25)에 효과적으로 통합될 수 있다. 본 실시예에서, 마이크로프로세서(10), 하드웨어(13), 오퍼레이팅 시스템(14), 가상 기계(15), 및 여러 소프트웨어 소자(16-18)들은 도 1의 실시예와 동일하다. 마이크로프로세서 B 대신에, 마이크로프로세서(10)와 단일 집적 회로(25)로 집적된 디지털 신호 처리기(digital signal processor: DSP)가 있다. DSP(27)는 프레이밍과 블럭 코딩 등의 다른 바이트 레벨의 조작을 수행하는 DSP 코드(28)을 가지는 한편, 호 처리 등의 다른 송수신기 소프트웨어 기능은 마이크로프로세서(10) 상에서 오퍼레이팅 시스템(14)을 사용하여 실행되는 송수신기 소프트웨어 코드에 의해 수행된다. 적절한 집적 회로(25)로는 Illinois주 Schaumburg의 Motorola, Inc.로부터 제공되는 M-core(TM) 집적 마이크로프로세서와 DSP가 있다.

도 3에는, 애플리케이션(16) ('전화 애플릿'이라 함)과 JTAPI 메소드 구현(18)이 도시되어 있다. 전화 애플릿(16)과 JTAPI 메소드 구현(18) 간을 인터페이스하는 JTAPI 인터페이스(30)가 도시되어 있다. JTAPI 메소드 구현(18)은 CSPMI(22)를 통하여 GSM 송수신기(30) 등의 무선 송수신기로부터의 입력을 제어 및 수신한다. GSM 송수신기(30)는 제2 마이크로프로세서(11), RF 하드웨어(13), 및 송수신기 소프트웨어(20)를 포함한다 (모두 도 1에 도시되어 있음).

JTAPI(30)는, '공급자(Provider)'와 같은 고레벨 객체의 문법이나 동작을 정의하며 부록 A에 상술된 JTAPI 명세서 버전 1.2에 기재된 것바와 같다. 또한, GSM에 특정한 소정의 동작이 지원되는데, 이를 위해 다음의 특정 의미 체계 구조(semantics)를 정의한다.

JTAPI 공급자의 도메인은 간단하게는 이동국(mobile station: MS)이다. 공급자 도메인의 유일한 어드레스들은 단일 회선 전화용의 도메인에서의 단일 어드레스와 같은 MS 어드레스들이다.

Provider.getAddresses()는 전형적으로 1 엔트리(entry)만을 갖는 MS에 대한 어드레스 배열을 리턴한다. MS가 다중 회선 및 전화 번호를 지원한다면, 이 제1 엔트리가 디폴트 또는 주 어드레스가 된다.

Provider.getAddress()는 MS에 할당된 번호만을 받아들인다. 디폴트로는, 주 어드레스 즉, getAddresses()[0]이 리턴된다.

Provider.getTerminals()는 MS에 의해 지원되는 터미널의 배열을 리턴한다. 각 호 운반자(bearer) 유형 (이하 참조)에 대해 별도의 터미널이 정의된다.

Provider.getTerminals()는 터미널의 이름을 특정하는 스트링(string)을 취한다. 디폴트로는, 음성 터미널이 리턴된다. 모든 구현은 각 터미널에 대한 이름으로서 VOICE, DATA, 및 FAX를 지원하여야만 한다 (이하 참조).

Provider.createCall()는 공급자(Provider)가 OUT_OF_SERVICE에 있다 하더라도 셧 다운(shut down)되지 않는 한, 호를 생성할 것이다. 이 호는 Provider가 IN_SERVICE에 있을 때까지는 성공적으로 배치될 수 없다. 이러한 특징이 JTAPI 1.2 createCall() 사전 조건(pre-comditions)에 주어진 변화이고, 이에 대해서는 도 5 및 도 6을 참조하여 이하에서 보다 상술한다.

Call.connect()는 공통 SS 코드와 어드레스 플래그에 대한 목적지 어드레스 스트링을 파싱(parsing)한다. Call.connect()로 들어오는 목적지 번호 스트링이 '+' 문자로 시작하는 경우에는, 번호 유형(type-of-number: TON)이 INTERNATIONAL로 설정되고, 그렇지 않은 경우에는 TON은 UNKNOWN으로 설정된다. 스트링이 숫자만을 포함하고 있다면, 번호화 계획 식별자(numbering-plan identifier: NPI)는 ISDN이고, 그렇지 않다면 UNKNOWN이다.

TerminalConnection.join()과 TerminalConnection.leave()는 이중 모드 (음성과 데이터 또는 음성과 팩스) 호에서 호의 모드를 변화시키는 데 사용된다. 하나의 호에서 활성인 정확히 하나의 TerminalConnection은 항상 존재한다. 다른 TerminalConnection 상에서 join()을 부르는 것은 호 모드의 변경을 가져오고, 활성 TerminalConnection() 상에서 leave()를 호출하면 자동적으로 대체 TerminalConnection을 활성화시킨다.

애플리케이션은 MediaTerminalConnection에 대해 정의된 API를 사용하여 호의 정보 내용과 상호 작용할 수 있다. Connection.getTerminalConnections()로부터 리턴된 TerminalConnection이 MediaTerminalConnection을 구현한다면, 애플리케이션은 다음 메소드들을 사용할 수 있다: JTAPI 1.2에 정의된 바와 같이 구현되는 MediaTerminalConnection.getMediaAvailability(); JTAPI 1.2에 정의된 바와 같이 구현되는 MediaTerminalConnection.getMediaState(); 호 상에서 DTMF 톤을 발생시키는 데 사용되는 MediaTerminalConnection.generateDtmf(). MediaTerminalConnection에서의 모든 다른 메소드들은 선택적이다.

공급자(Provider)는 서비스를 벗어날 때, 반드시 임의의 활성 호를 단절하지는 않을 것이다. 공급자는 일시적인 통신 실패로 간주하고, 그 호를 활성화된 상태로 유지하여 호를 재설립하려고 시도할 수도 있다. 애플리케이션은 ProvOutOfServiceEv 다음에 CallInvalidEv와 관련 ConnDisconnectedEv 이벤트가 뒤따르지 않는다면 (즉, 이들 후자가 타임아웃 시간 이내에 뒤따라오지 않는다면), 공급자가 호를 재설립하려고 시도하고 있다고 간주할 수 있다.

또한, 몇몇 GSM 기능들은 현존 JTAPI 문법과 메소드 시그너처를 사용하여 쉽게 액세스될 수 없다. 다른 새로운 메소드나 다른 시그너처를 갖는 메소드가 정의된다.

Provider.getNetworkID()는 현재 네트워크의 이름을 리턴한다.

Provider.getServiceLevel()는 동작 서비스 레벨 즉, NONE, EMERGENCY, FULL을 리턴한다.

Provider.isRoaming()는 MS가 홈 PLMN 상에 있지 않을 경우 참(true) 값을 리턴한다.

이 새로운 메소드들은 애플리케이션으로 하여금 현재 공중 육상 이동 네트워크(public land mobile network: PLMN), 동작 서비스 레벨(operating service level), 및 유닛이 홈 PLMN상에 존재하는 지의 여부를 결정할 수 있게 한다.

JTAPI에서, 터미널 객체는 호의 물리적인 종점을 나타낸다. 이 호는 음성을 운반하고 있다고 가정한다. GSM을 위해 정의된 다른 운반자 유형들을 지원하기 위해서, 부가적인 터미널 하위 클래스들이 각 주요 호 운반자 유형에 하나씩 정의된다. 터미널의 데이터 터미널 하위 클래스는 GSM 데이터 호의 물리적인 종점을 나타낸다. 터미널의 팩스 터미널 하위 클래스는 GSM 팩스 호의 물리적인 종점을 나타낸다.

전형적인 GSM MS는 VOICE, DATA, 및 FAX 터미널의 적어도 3개의 터미널을 지원할 것이다. MS는 부가적인 터미널 인스턴스나 하위 클래스 (예를 들어, 내부 데이터용 내부 데이터 터미널 및 접속된 PC로 보내지는 데이터용의 모뎀 데이터 타미널)들을 지원할 수도 있다. 애플리케이션은 적절한 터미널 상으로 들어오는 호 이벤트를 관측함으로써, 들어오는 다양한 운반자 유형의 호를 수용한다.

이제, 도 4를 참조하여 이중 모드 GSM 호 지원을 위한 특징들을 설명한다.

도 4는 도 3의 JTAPI 구현(18)의 상세를 도시한다. 이 메소드(method)의 중심에는 공급자 메소드(40)(provider method)가 있다. 이 공급자 메소드는 오퍼레이팅 시스템(14)과 인터페이스한다. 본 명세서에서 사용되는 바와 같이, '메소드(method)'는 클래스 내부에 정의된 것으로 이 클래스의 인스턴스 상에서 동작하는 함수(function)를 의미한다. 공급자 메소드(40)는 음성 터미널 객체(42), 데이터 터미널 객체(44), 팩스 터미널 객체(46), 및 어드레스 객체(48)와 연관되어 있다. 호가 설정될 때, 공급자 메소드(40)는 호 객체(50)를 생성한다. 이 호 객체(50)는 국부 접속 객체(52)를 생성한다. 간단한 음성 접속에 대해서는, 이 국부 접속 객체(52)가 음성 터미널(42)을 참조하는 터미널 접속 객체(54)를 생성한다. 이하에서 상술하겠지만, 국부 접속 객체(52)는 또한 제2 터미널 접속 객체(56) (및 심지어는 제3 터미널 접속 객체(58)까지)를 생성한다. 제2 터미널 접속 객체(56)는 데이터 터미널 객체(44)를 참조한다. 제3 터미널 객체(58)가 존재한다면, 이는 팩스 터미널(46)을 참조할 수 있다. 이하에서 설명하겠지만, 또 다른 구성으로, 제2 및 3 터미널 접속 객체가 데이터 및 팩스 호를 생성할 목적으로 생성될 수 있다.

호가 3방향 호인 경우라면, 호 객체(50)는 필요하다면 그 자체의 관련 터미널 접속 객체들(62-66) 외에도 부가적인 원격 접속 객체(60)를 생성할 것이다. 또한, 또 다른 호 (예를 들어, 홀드 상태의 호)가 존재한다면, 공급자 메소드(40)는 부가적인 제2 호 객체(70)를 생성할 수 있다. 제2 호 객체는 그 자체의 대응하는 국부 접속 및 터미널 접속을 갖는다. 모든 경우에, 주어진 무선 전화에 대해서, 음성 터미널, 데이터 터미널, 및 팩스 터미널의 단지 3개의 터미널만이 존재한다. 따라서, 모든 경우에, 국부 접속(52), 원격 접속(60), 및 임의의 다른 국부 접속 또는 원격 접속들에 의해 생성되는 다양한 터미널 접속 객체들은 모두 각각의 음성 터미널 객체(42), 데이터 터미널 객체(44), 및 팩스 터미널 객체(46)를 참조한다.

상술한 과정에서는, GSM 송수신기(30)가 무선 전화 통신 채널을 통해서 원격 스위치를 갖는 호를 설정하는 것이 목적이다. 또, 이 호가 이중 모드인 경우 (예를 들어, 음성과 데이터 또는 음성과 팩스)에는, JTAPI 메소드 구현(18)이 이중 모드 능력을 가진 호를 설정하고, 이중 모드 호가 설립되었음을 CSPMI(22)를 통하여 GSM 송수신기에 알려, GSM 송수신기(30)가 이 호가 이중 모드 호임을 GSM 시스템에 알림으로써, 차례로 호 설정 요구를 수신할 때 GSM 시스템을 스위치시켜, 호를 설립하고, 이 호의 데이터 또는 팩스 기능을 지원하기 위해 그 내부 작동 기능의 모뎀을 확보해 둔다. 또한, JTAPI 명령 call.connect()를 사용하여, 전화 애플리케이션(16)의 자극(instigation)에서 이 이중 모드 호를 설립하는 것이 목적이다.

JTAPI 버전 1.2에서, call.connect()는 그 인수(arguement)로서 터미널 객체를 기대함으로써, 이 터미널로의/로부터의 단일 모드 호 설립을 허용한다. 이중 모드 호를 설립하기 위하여, 본 발명의 양호한 실시예는, 단일 발신 터미널(originating terminal) 대신에 터미널 배열을 제1 인수로 취하는 메소드를 부가하기 위해, call.connect()가 오버라이딩(overriding)되는 것을 허용한다. 이 터미널 배열은 명령 call.connect의 인수이고, 음성 터미널과 데이터 터미널, 또는 음성 터미널과 팩스 터미널, 또는 데이터 터미널과 팩스 터미널, 또는 음성 터미널, 데이터 터미널, 및 팩스 터미널 등과 같은 터미널 객체들의 배열을 포함한다. 메소드 공급자(40)가 인수로서 배열 및 이 명령으로 호출될 때는, 호 객체(50)와 국부 접속 객체(52)를 생성한다. 국부 접속 객체(52)는 제1 및 2 터미널 객체(54 및 56)를 생성한다. 국부 접속 객체(52)는 그 터미널에 대해 제1 터미널 접속 객체(54)에게 문의하고, 제1 터미널 접속 객체(54)는 그 터미널 (즉, 참조하고 있는 터미널)이 음성 터미널임을 나타내도록 국부 접속 객체(52)에 응답한다. 유사하게, 제2 터미널 접속 객체(56)는 국부 접속 객체(52)에 의해 문의를 받으며, 그 터미널이 데이터 터미널이라고 응답한다. 국부 접속 객체(52)는 데이터 터미널 접속 및 음성 터미널 접속이 설립되었음을 호 객체(50)에 알린다. 호 객체(50)는 이중 노드 호가 설립되었음을 공급자(40)에게 알린다. 공급자(40)는 이중 모드 호가 설립되었음을 CSPMI(22)를 통해 (OS(14)를 통하여) GSM 송수신기에 알린다.

공급자(40)는 다음과 같이 송수신기(30)를 통해 호를 설립한다. 공급자(40)는 그 유형으로 PlaceCallReq를 갖는 버퍼를 생성하고, 다음 표 1로부터 파라미터 M/O/C를 추가한다. 이들 파라미터들은 호를 기술한다.

파라미터 이름	파라미터 유형	M/O/C
CallType	CALL_TYPE	M
CalledParty¹	PHONE_NUMBER	C
RepeatIndicator²	REPEAT_INDICATOR	O
CallType²	CALL_TYPE	O
DataParameters³	DATA_PARAMETERS	C
CLIRDisposition⁴	CLIR_DISPOSITION	O
CUGInfo⁵	CUG_INFO	O

1. 긴급 호에 대해서는 선택 사항, 그 이외의 모든 다른 호 유형에 대해서는 강제 사항.

2. 다중 호 유형(Multiple Call Type) 호에 대해서 강제 사항.

3. 어떤 호 유형이 팩스나 데이터에 대한 것일 때 강제 사항.

4. 클라이언트가 CLIR 신청 디폴트(subscription default)를 오버라이딩하고자 할 경우 포함될 수 있음.

5. 클라이언트가 CUG 신청 디폴트를 오버라이딩하고자 할 경우 포함될 수 있음.

이 버퍼의 내용은 직렬 링크(22)를 통해 송수신기(30)로 보내지고, 받아들여지면, 송수신기는 다음 표 2로부터 확인 메시지를 리턴한다.

파라미터 이름	파라미터 유형	M/O/C
CallHandle¹	CALL_HANDLE	C

1. 호 요구가 성공적일 경우 강제 사항.

이 확인 메시지는 마이크로프로세서(10)로 하여금 다음 명령에서 이 호를 식별할 수 있게 하는 호-조작(call-handle)을 준다.

표 1에서, 호 유형(2)은 대체(alternate) 호 유형을 나타내고, 이 대체 호 유형이 데이터 또는 팩스 (GSM에서 초기 호 유형은 항상 음성임)임을 나타낸다. 이러한 방식으로, 공급자(40)는 대체 호 유형이 존재하고 이는 데이터 (또는 팩스)임을 송수신기(30)에 알린다. 따라서, 송수신기(30)가 이 호를 설정할 때는, 이어서 스위치는, 대체 호 유형이 존재하고 이 대체 호 유형이 데이터 모뎀 (또는 팩스 모뎀)의 예약을 필요로 함을 통보받는다.

제1 터미널 배열 엔트리는 초기적으로 활성 터미널이지만, 호는 이 배열 내에서 선언된 임의의 터미널을 조작할 수 있도록 구성된다. 즉, 다른 터미널로의 터미널 접속은 호 제어 terminalconnection.bridgedstate (또는, terminalconnection.passivestate) 내에 배치된다. 상술한 바와 같이, 연합/이탈(joined/leave)은 호의 현재 모드를 제어하는 데 사용된다. 이러한 connect()의 변형은 이중 모드 호 파라미터를 초기 선언하는 (즉, 애플리케이션(16)이 이 호에 참여하는 모든 터미널을 선언할 것을 요구하는) GSM 요구 사항을 지원하는 데 사용된다.

Call.connect()는 목적지 어드레스 스트링의 TON(번호 유형) 및 NPI(번호화 계획 식별자)들이 상술한 바와 같이 추정될 수 없는 경우, 이들을 명확히 특정하는 메소드를 부가하도록 오버라이딩된다.

Call.setEmergency()는 긴급 모드 플래그를 설정하도록 정의된다.

Call.setCUGInfo()는 폐쇄 사용자 그룹 정보를 목적지 어드레스 스트링 내의 SS(supplementary services) 코드의 사용 대신, 프로그램 형식으로 특정하도록 정의된다.

Call.setCallerIdRestricted()는 호출 라인(calling line) 식별 제한 요구를 목적지 어드레스 스트링 내의 SS 코드의 사용 대신, 프로그램 형식으로 특정하도록 정의된다.

Call.offHook()는 지원되지 않는다.

애플리케이션은 트랜스퍼 또는 컨퍼런스 제어기(transfer or conference controller)를 특정할 수 없다. setTransferController()와 setConferenceController() 메소드는 MethodNotSupported를 버리고(throw), getConferenceController()와 getTransferController()는 <NULL>을 리턴한다.

setConferenceEnable(), getConferenceEnable(), setTransferEnable() 및 getTransferEnable()는 이 호를 트랜스퍼 또는 컨퍼런스하는 능력을 제어하는 내부 플래그들을 조작한다.

Call.consult() 호출은 목적지 어드레스 스트링을 포함하여야만 하고, 특정되지 않은 변형은 지원되지 않는다.

Connection.reject(int)는 호를 거절할 때의 거절 이유를 애플리케이션이 특정할 수 있도록 정의된다. 이는 사용자-결정-사용자-통화 중(user-determined-user-busy) 기능을 지원한다.

Connection.addToAddress()는 지원되지 않는다.

Connection.park()는 지원되지 않는다.

터미널 접속 (데이터 터미널 접속)의 하위 클래스는 네트워크와 종점 데이터 터미널 사이의 물리적인 링크를 나타내는 것으로 정의된다. 메소드들은 데이터 속도, 모뎀 유형, 프로토콜 계층 등과 같은 데이터 호 파라미터를 특정하고 문의하도록 정의된다. 유사하게, 터미널 접속의 하위 클래스 ((팩스 터미널 접속), 매체 터미널 접속의 하위 클래스로서 보다 더 정확히 기술됨)는 네트워크와 종점 터미널 사이의 물리적인 링크를 나타내는 것으로 정의된다. 메소드들은 데이터 가중치, 그룹 모드 등의 팩스 호 파라미터를 특정하고 문의하도록 정의된다.

팩스 터미널 접속(FaxTerminalConnection)은 또한 팩스 매체 스트림을 구성하고 데이터 페이지와 페이지 끝 지시자(end-of-page indicator)를 송신하기 위한 매체-특정(media-specific) 메소드를 제공한다.

호 전송(call forwarding)이 'TermForwardingActiveEv' 특정 터미널에 대해 활성인지를 애플리케이션이 결정할 수 있도록, 새로운 터미널 이벤트가 정의된다. 다른 서비스들 (즉, 음성, 팩스, 및 데이터)을 위한 전송은 적절한 터미널 객체 (즉, 음성(VOICE), 데이터(DATA), 팩스(FAX))를 통한 시그널링(signaling)이다.

Provider.createCall()이 OUT_OF_SERVICE에 있다 하더라도 셧 다운되지 않는 한 호를 생성할 것이고, 이 호는 이 공급자(Provider)가 IN_SERVICE에 있을 때까지는 성공적으로 배치될 수 없음은 이미 설명한 바 있다. 이제 이 특징에 대해 도 5 및 도 6을 참조하여 보다 상세히 설명한다.

도 5에서는, 애플리케이션(16)이 어떤 이유로건 호를 배치하거나, 접속 또는 패킷 데이터 세션을 설립하고자 하는 경우에 대해서 설명한다. 일반적으로, 애플리케이션(16)은 사용자로의 인터페이스이고, 예를 들어 사용자가 무선 통신 장치 (이동국 즉, MS)의 전원을 기동하고, 전화 번호의 다이얼 등을 통해서 호를 개시하고자 한다. 애플리케이션(16)은 API(30)를 거친 Provider.createCall() 명령을 통해 Provider.createCall 메소드를 호출함으로써 (단계 100), 도 5에 도시된 프로그램 (또는 메소드)을 시작한다. 만약, 단계 101에서 통신 장치가 셧 다운 모드에 있는 경우에는, 프로그램은 간단히 단계 102에서 에러를 리턴하고, 단계 103에서 프로그램을 빠져나온다. 만약, 장치가 셧 다운 모드에 있지 않은 경우에는, 단계 110에서 호 객체(50)가 생성되고, 도 5의 프로그램이 단계 111에서 완료되어, 도 6의 프로그램을 개시하도록 준비된다.

호 객체(50)의 생성 직후, 또 다른 어떠한 이벤트나 조건이 없다면 (또, 어떠한 이벤트의 오버라이딩도 없다면), 애플리케이션(16)은 API(30)를 거친 Call.connect() 명령을 통해 Call.connect 메소드를 호출한다 (단계 150). 단계 151에서, 통신 장치가 서비스 중이 아닌 상태(out of service)에 있다고 판정되면, 프로그램 (또는 메소드)은 단계 154에서 다른 함수(function)가 탐색(scanning) 동작을 수행하는 동안, 단계 152에서 대기하게 된다. 일반적으로, 탐색 과정에서 셀룰러 네트워크로의 접속을 허용하는 데에는 약 10초의 대기 시간이면 충분하다. 단계 151 또는 단계 156에서, 통신 장치가 무선 통신 네트워크와 서비스를 설립하면, 단계 158이 개시되어 호를 배치하기 위한 명령이 직렬 인터페이스(22)를 거쳐 송수신기(30)로 보내진다. 도 6의 프로그램은 단계 160에서 종료한다.

이러한 방식으로, 사용자는 서비스가 설립되기 전이라도, 호를 배치하기 위해 전화 번호의 다이얼링을 시작할 수 있다. 일반적으로, 사용자는 서비스가 설립되었는지에는 상관없이 통신 장치의 전원이 기동되자마자 곧바로 호 배치를 시작하기를 원하기 때문에, 이러한 특징은 특히 유용하다. 서비스의 설립은 장치의 전원 기동 동작 (예를 들어, 전원 키를 누르거나 플립을 여는 것)에 응답하여 개시될 수 있고, 도 5 및 도 6의 메소드는 사용자나 애플리케이션의 몇몇 다른 동작에 응답하여 병렬로 시작될 수 있다.

JTAPI 정의가 각각의 다른 JTAPI 이벤트에 대해 별개의 클래스를 갖는다는 것은 중요한 문제이다. 이는 MS에게 63개 이상의 이벤트 클래스들, 약 130k 바이트의 총 클래스 파일을 정의하여야 한다는 부담을 지운다.

본 발명의 한 특성에 따르면, 애플리케이션은 이벤트 클래스의 유형보다는 이벤트 ID에 기초하여 디스패치(dispatch)된다. 이는 많은 이벤트 클래스들을 훨씬 더 작은 수의 이벤트 카테고리 클래스의 집합으로 대체한다. 애플리케이션은 이 이벤트 ID를 사용하여 광범위한 유형의 특정 클래스를 결정한다. 이로 인해, 객체 캡슐화(object encapsulation)의 심각한 손실없이 상당한 공간 절약을 가져올 수 있다.

이벤트 클래스들은 다음과 같이 8개의 특유의 클래스들로 그룹지어 질 수 있다.

- EV : 모든 이벤트의 기본 클래스

- ProvEv : 공급자(provider) 이벤트

- CallCtlAddrEv : 어드레스 및 호 제어 어드레스 이벤트

- CallCtlCallEv : 호 및 호 제어 호 이벤트

- CallCtlConnEv : 접속 및 호 제어 접속 이벤트

- CallCtlTermEv : 터미널 및 호 제어 터미널 이벤트

- CallCtlTermConnEv : 터미널 접속 및 호 제어 터미널 접속 이벤트

- MediaEv : 매체 이벤트

이들 특유의 클래스들로 그룹이 이루어진 특정 이벤트들이 다음 표 3에 나타나 있다.

이제까지 설명한 것은 단지 하나의 예로서만 주어진 것이고, 다양한 변형이 본 발명의 사상과 범주 내에서 이루어질 수 있다.

요약하면, 무선 통신 장치를 위한 전화 통신 API 및 공급자 메소드를 포함하는 관련 구현은, 무선 전화 통신 기능을 위한 객체 지향 컴퓨터 프로그램의 개발에 매우 적절하다. API를 사용함으로써, 플랫폼 간의 매우 높은 이식성을 허용할 수 있고, 구현에 있어서 메모리에 대한 요구 사항이 매우 낮게 된다. 더구나, 지금까지 간단한 유선 전화 통신 호의 설립에 사용되었던 표준 JTAPI 이벤트 클래스들을 사용함으로써, GSM 무선 전화 시스템에서 요구되는 것과 같은 이중 모드 호 기능이 지원된다.

본 발명의 한 특성에 따르면, 무선 통신 장치는 애플리케이션 프로그램과 이동 전화 프로그램을 내장하는 메모리를 포함한다. 이동 전화 프로그램은 이 장치에 연결되는 무선 네트워크를 기술하는 파라미터를 보유한다. 이들 파라미터에는 현재 네트워크의 이름, 현재 네트워크의 동작 서비스 레벨, 현재 네트워크가 홈 네트워크인지 여부를 가리키는 지시 중 하나 이상이 포함된다. 이 파라미터들은 송수신기로부터 또는 이동 인터넷 프로토콜 접속을 통해 이동 전화 프로그램으로 운반된다. 사용자 애플리케이션 프로그램과 이동 전화 프로그램 간의 애플리케이션 프로그래밍 인터페이스는 이들 파라미터를 호출하여 이를 애플리케이션 프로그램으로 리턴하는 적어도 하나의 명령 (예를 들면, Provider.getNetworkID(); Provider.getServiceLevel(); 또는 Provider.isRoaming())을 갖는다.

부록 1

자바 전화 통신(Java Telephony) API

개요

버전 1.2

소개

자바 전화 통신 API(JTAPI)는 자바 기반의 컴퓨터-전화 통신 애플리케이션을 위한 이식성의 객체 지향 애플리케이션 프로그래밍 인터페이스이다. JTAPI는 호 센터 애플리케이션 개발자로부터 웹 페이지 개발자에 이르기까지 다양한 대중을 위해 제공된다. JTAPI는 제1 및 제3자 전화 통신 애플리케이션 도메인을 모두 지원한다. API는 개선된 전화 통신 애플리케이션에 필요한 이러한 특징들을 제공하여, 간단한 애플리케이션의 프로그래밍을 쉽게 하도록 설계된다.

자바 전화 통신 API는 사실 API의 집합이다. '중심(core)' API는 기본 호 모델과, 전화 호를 배치하고 전화 호에 응답하는 등의 초보적인 전화 통신 기능들을 제공한다. 중심 API는 호 센터 및 매체 스트림 액세스와 같은 특정 전화 통신 영역을 위한 기능을 제공하는 표준 확장 API들로 둘러싸인다. 본 문서에서는 이하에서 JTAPI 중심 및 확장 패키지 아키텍처에 대해 설명한다.

자바 전화 통신 API를 사용하여 기술된 애플리케이션은 다양한 컴퓨터 플랫폼과 전화 시스템에 걸쳐 이식성을 제공한다. JTAPI의 구현은 Sun Microsystem의 SunXTL, Microsoft와 Intel의 TAPI, Novell과 Lucent의 TSAPI, 및 IBM의 CallPath 등과 같은 현존하는 컴퓨터-전화 통신 통합 플랫폼을 위해 이용할 수 있다. 또한, 각 하드웨어 판매자는 자신의 고유 하드웨어 상부에 자바 전화 통신 API의 구현을 제공하도록 선택할 수 있다.

문서 조직의 개요

본 문서는 다음 섹션들로 되어 있다.

자바 전화 통신 API 특징 - JTAPI의 특징과 그 설계되는 원리를 기술한다.

지원되는 구성 - JTAPI가 사용될 수 있는 환경과 그 설계를 위한 컴퓨터 및 소프트웨어 구성을 요약한다.

자바 전화 통신 패키지 아키텍처 - 자바 전화 통신 API가 다양한 자바 언어 패키지들로 어떻게 조직화되는 지를 요약하고, 각 패키지에 대한 간단한 설명을 보다 상세한 문서들과의 링크를 통해 설명한다.

자바 전화 통신 호 모델 - 전화 호와 전화 호를 구성하는 다른 객체들이 이 API로 어떻게 표현되는 지를 설명한다.

중심 패키지 메소드 - 전화 호의 배치, 전화 호의 응답, 및 전화 호로의 접속의 단절 등과 같은 가장 초보적인 전화 통신 동작을 수행하는 중심 패키지에서 이용가능한 중요 메소드들을 간단히 요약한다.

접속 객체 상태 - 접속 객체들이 존재할 수 있는 상태를 설명하고, 각 상태로부터 가능한 천이들에 대해 설명한다.

터미널 접속 객체 상태 - 터미널 접속 객체가 존재할 수 있는 상태를 설명하고, 각 상태로부터 가능한 천이들에 대해 설명한다.

전화 호의 배치 - 어떤 전화 통신 API에 있어서도 가장 중요한 공통적인 특징은 전화 호를 배치하는 것이다. 본 섹션은 전화 호를 배치하기 위해 필요한 JTAPI 메소드의 호출을 설명하고, 호 모델에서의 상태 변화를 조사한다. 이 분석은 호가 어떻게 배치되고, 응답되고, 종료되는 지를 설명할 것이다.

자바 전화 통신 관측자 모델 - JTAPI 관측자 모델을 설명한다. 애플리케이션은 JTAPI 호 모델에서 변화의 비동기적 인식을 위해 관측자를 사용한다.

애플리케이션 코드 예제는 여기에 포함되지 않았지만, 자바 전화 통신 API를 사용한 두 개의 실제 코드 예제가 California, Palo Alto의 Sun Microsystems, Inc.에 의해 출판된 자바 전화 통신 API 버전 1.2 개요에 나타나 있다. 한 예는 특정 전화 번호로 전화 호를 배치한다. 다른 한 예는 들어오는 전화 호에 응답하는 지정된 터미널을 보여준다.

공급자의 위치 및 획득 - 애플리케이션이 JTAPI 공급자 객체를 생성하고 확득하는 메소드에 대해 설명한다.

보안 - JTAPI 보안 전략을 요약한다.

자바 전화 통신 특징(Java Telephony Features)

자바 전화 통신 API의 특징 및 설계 원리는 다음과 같다.

가장 기초적인 전화 통신 애플리케이션으로 단순화한다.

데스크탑 애플리케이션으로부터 분포된 호 센터 전화 통신 애플리케이션에까지 이르는 다양한 크기의 프레임 워크를 제공한다.

직접 서비스 공급자로의 애플리케이션과 인터페이스하거나, 또는 SunXTL, TSAPI 및 TAPI와 같은 기존의 전화 통신 API들로의 자바 인터페이스로서 기능한다.

표준 확장 패키지로 증가되는 단순 코어(core)에 기초한다.

자바 실행 시간(run-time)이 사용될 수 있는 넓은 범위의 하드웨어 구성 상에서 실행될 수 있다.

지원되는 구성(Supported Configurations)

JTAPI는 전화 통신 자원으로의 직접 액세스를 갖는 중앙화된 서버, 네트워크을 통한 전화 통신 자원으로의 액세스를 갖는 원격 네트워크 컴퓨터를 포함하는 다양한 시스템 구성 상에서 실행된다. 제1 구성에서는, 도 7에 도시된 바와 같이 네트워크 컴퓨터가 JTAPI 애플리케이션을 실행하고, 네트워크를 통해 전화 통신 자원을 액세스한다. 제2 구성에서는, 도 8에 도시된 바와 같이, 애플리케이션은 자체의 전화 통신 자원을 구비한 컴퓨터 상에서 실행된다.

네트워크 컴퓨터(NC) 구성(Network Computer Configuration)

네트워크 구성에서, JTAPI 애플리케이션 또는 자바 애플릿은 원격 워크스테이션 상에서 실행된다. 이 워크스테이션은 단지 디스플레이, 키보드, 프로세서, 및 몇몇 메모리만을 구비한 네트워크 컴퓨터일 수도 있다. 이는 전화 통신 자원을 관리하는 중앙화된 서버를 사용하여, 네트워크 자원을 액세스한다. JTAPI는 자바의 RMI, JOE, 또는 전화 통신 프로토콜 등과 같은 원격 통신 메커니즘을 통해, 이 서버와 통신한다. 다음 다이어그램은 이 구성을 보여준다.

데스크탑 컴퓨터 구성(Desktop Computer Configuration)

데스크탑 컴퓨터에서는, JTAPI 애플리케이션 또는 자바 애플릿은 전화 통신 자원을 수용하고 있는 동일한 워크스테이션 상에서 실행된다. 도 8은 이 데스크탑 컴퓨터의 구성을 도시한다.

자바 전화 통신 패키지 아키텍처(Java Telephony Package Architecture)

자바 전화 통신 API는 자바 언어 패키지들의 집합으로 구성된다. 각 패키지는 컴퓨터-전화 통신 애플리케이션의 소정 양상을 위한 특정 기능을 일부 제공한다. 전화 통신 서버의 구현은 그들이 지원하는 패키지들을 선택하는데, 이는 그들의 플랫폼과 하드웨어에 의존한다. 애플리케이션은 현재 사용하고 있는 구현에 의해서 지원되는 패키지에 대해 문의하기도 한다. 또한, 애플리케이션 개발자는 작업을 수행하는 데 필요한 지원되는 패키지 애플리케이션에만 관심을 가질 수도 있다. 도 9는 JTAPI 패키지의 아키텍처를 도시한다.

자바 전화 통신 API의 중앙에는 '중심(core)' 패키지가 있다. 중심 패키지는 전화 호와 초보적인 전화 기능을 모델하는 기초적인 프레임 워크를 제공한다. 이들 기능에는 전화 호의 배치, 전화 호에의 응답, 및 전화 호 접속의 단절 등이 포함된다. 간단한 전화 통신 애플리케이션은 이들 작업을 수행하기 위해 단지 중심 패키지만의 사용을 필요로 하고, 다른 패키지들의 상세 사항에 대하여는 관심이 없을 것이다. 예를 들어, 중심 패키지는 애플릿 설계자로 하여금 웹 페이지에 간단히 전화 기능을 추가할 수 있도록 한다.

많은 '표준 확장' 패키지들이 JTAPI 중심 패키지를 확장시킨다. 이들 확장 패키지 각각은 API에 부가적인 전화 통신 기능을 제공한다. 현재, 다음과 같은 확장 패키지들이 이 API를 위해 존재한다. 호 제어, 호 센터, 매체, 전화, 개인 데이터, 및 용량 패키지. 각 패키지는 그것이 JTAPI에 가져다주는 기능에 따라 다음과 같이 요약되고, 별도의 소개 문서와 명세서로 연결된다.

JTAPI 패키지 아키텍처는 구현(implementation)과 애플리케이션을 위한 양방향 도로이다. 다시 말하면, 전화 통신 서버 구현은 그 하드웨어 능력에 따라서 (중심 패키지 이외에) 어떤 확장 패키지를 구현할 것인지를 선택하고, 애플리케이션은 그 애플리케이션의 원하는 작업을 수행하기 위해 사용될 필요가 있는 확장 패키지를 (중심 패키지에 추가하여) 선택한다. 애플리케이션은 구현이 지원하는 확장 패키지를 위한 구현을 문의하기도 하고, 애플리케이션 개발자는 애플리케이션에 필요하지 않은 패키지의 상세에 대해서는 관심을 기울일 필요가 없다.

자바 전화 통신 표준 확장 패키지(Java Telephony Standard Extension Packages)

각 JTAPI 확장 패키지는 중심 API로의 확장을 기술하는 자체 명세를 가지고 있고, 대부분의 경우에 이를 설명하는 별도의 개요 문서를 갖고 있다. 이하의 차트는 이용가능한 각 확장 패키지의 리스트를 개별 개요 문서로의 링크와 함께 나타내고 있다.

호 제어 패키지(Call Control Package)

java.telephony.callcontrol 패키지는 호를 홀드 상태로 배치하고, 전화 호를 전달하고, 전화 호를 컨퍼런스하는 등의 보다 발전된 호 제어 특징을 제공함으로써, 중심 패키지를 확장한다. 또한, 이 패키지는 전화 호의 보다 상세한 상태 모델을 제공한다.

호 센타 패키지(Call Center Package)

java.telephony.callcenter 패키지는 대규모 호 센타를 관리하는 데 필요한 발전된 특징들을 수행하는 능력을 애플리케이션에 제공한다. 이들 발전된 특징들에는 라우팅(Routing), 자동 호 분배(ACD), 호 예상(Predictive Calling), 및 애플리케이션 데이터를 전화 통신 객체와 관련짓기 등이 포함된다.

매체 패키지(Media Package)

java.telephony.media 패키지는 전화 호와 관련된 매체 스트림으로의 액세스를 애플리케이션에 제공한다. 이들은 매체 스트림으로부터 데이터를 읽고 쓸 수 있다. 또한, DTMF(터치-톤) 및 논-DTMF 톤 검출 및 생성이 java.telephony.media 패키지내에 제공된다.

전화 패키지(Phone Package)

java.telephony.phone 패키지는 애플리케이션이 전화 하드웨어 폰 세트의 물리적인 특징을 제어할 수 있게 한다. 구현은 구성 요소의 집합으로 터미널을 기술할 수도 있는데, 여기서 각 구성 요소 유형들은 이 패키지 내에서 인터페이스를 갖는다.

능력 패키지(Capabilities Package)

java.telephony.capabilities 패키지는 어떤 동작이 수행될 수 있는지를 애플리케이션이 문의할 수 있게 한다. 능력은, 구현의 특징 지원 여부를 나타내는 정적 능력과, 주어진 호 모델의 현재 상태에 대해 소정 동작의 허용 여부를 나타내는 동적 능력의 두 형태를 갖는다.

개인 데이터 패키지(Private Data Package)

java.telephony.privatedata 패키지는 애플리케이션이 데이터를 하드웨어 스위치와 직접 통신할 수 있게 한다. 이 데이터는 스위치가 스위치-지정 동작을 수행하도록 명령하는데 사용될 수 있다. 또한, 애플리케이션은 데이터 조각을 자바 전화 통신 API 객체와 함께 '수송(piggy-back)'하는데, 이 패키지를 사용할 수 있다.

자바 전화 통신 호 모델(The Java Telephony Call Model)

JTAPI 호 모델은 6개의 자바 객체로 구성된다. 이 객체들은 중심 패키지 내의 자바 인터페이스를 사용하여 정의된다. 각 호 모델 객체는 전화 세계의 물리적 또는 논리적 실체를 나타낸다. 이들 호 모델 객체의 주 목적은 전화 호와 전화 호내에 포함된 종점을 기술하는 것이다. 이 호 모델 객체들은 특정한 메소드로 상호 관련되어 있는데, 이하에서 이를 요약하였고, 중심 패키지 규격에 대해 보다 상세히 기술되어 있다.

도 10은 JTAPI 호 모델과 이 호 모델을 구성하는 객체들을 도시한다. 각 객체에 대해 설명한다.

공급자 객체(Provider Object)

공급자 객체는 전화 통신 서비스-공급자 소프트웨어의 추상적 관념이다. 공급자는 서버에 연결된 PBX, 데스크탑 기계 내의 전화 통신/팩스 카드, 또는 IP 등과 같은 컴퓨터 네트워킹 기술을 관리한다. 공급자는 전화 통신 하위 시스템의 서비스-특정 특징들을 은닉하고, 자바 애플리케이션과 애플릿이 장치와는 무관하게 이 전화 통신 하위 시스템과 상호 작용할 수 있게 한다.

호 객체(Call Object)

호 객체는 전화 호, 서비스 공급자와 호 참가자 사이에서 흐르는 정보를 나타낸다. 전화 호는 호 객체와 0 또는 그 이상의 접속들로 구성된다. 2 당사자 호 시나리오에서는, 전화 호는 하나의 호 객체와 두 개의 접속을 갖는다. 컨퍼런스 호는 하나의 호 객체와 관련된 3개 이상의 접속을 갖는다.

어드레스 객체(Address Object)

어드레스 객체는 전화 번호를 나타낸다. 이는 전화 호의 논리적 종점에 대한 추상적 관념이다. 이는 물리적 종점과는 확실히 구별된다. 실제로, 하나의 어드레스는 몇 개의 물리적 종점들 (즉, 터미널들)에 대응한다.

접속 객체(Connection Object)

접속 객체는 호 객체와 어드레스 객체간의 통신 링크를 모델링한다. 이는 호와 어드레스 (즉, 논리적 종점)간의 관계에 관한 것이기 때문에, 이 관계는 '논리적' 관점으로 지칭되기도 한다. 접속 객체는 호와 어드레스 사이의 관계의 현재 상태를 나타내는 몇몇 상태들 중 하나일 수 있다. 이들 접속 상태는 후에 요약한다.

터미널 객체(Terminal Object)

터미널 객체는 전화와 같은 물리적 장치와 그 관련 특징들을 나타낸다. 각 터미널 객체는 몇몇 사무실 전화가 다중 호 외관을 관리할 수 있는 것과 같이, 그와 관련된 하나 이상의 어드레스 객체들 (전화 번호)을 갖는다. 터미널은 하드웨어의 물리적 조각에 대응되기 때문에, 호의 '물리적' 종점이라 부르기도 한다.

터미널 접속 객체(TerminalConnection Object)

터미널 접속 객체는 접속과 터미널 객체에 의해 표현되는 호의 물리적 종점사이의 관계를 모델링한다. 이 관계는 (접속이 논리적 관점을 모델링하는 것과는 대조적으로) 접속의 '물리적' 관점이라 부르기도 한다. 터미널 접속은 접속과 특정 터미널 사이의 관계의 현재 상태를 기술한다. 터미널 접속과 관련된 상태들은 이후 설명하기로 한다.

중심 패키지 메소드(Core Package Methods)

중심 패키지는 전화 호의 배치, 전화 호에의 응답, 및 전화 호로의 접속 단절과 같은 그 주된 특징을 지원하는 3개의 다른 메소드들을 정의한다. 이들 메소드에는 Call.connect(), TerminalConnection.answer(), 및 Connection.disconnect()가 있다.

Call.connect()

애플리케이션은 일단 유휴(idle) 호 객체 (Provider.createCall()을 통해 얻어짐)를 갖게 되면, Call.connect() 메소드를 사용하여 전화 호를 배치한다. 애플리케이션은 발신 터미널 (물리적 종점)과 그 터미널 상의 발신 어드레스 (논리적 종점) (터미널이 다중 전화 번호를 갖는 경우)를 특정하여야만 한다. 또한, 목적지 전화 번호 스트링을 제공한다. 2개의 접속 객체가 Call.connect() 메소드로부터 리턴된다. 각각은 전화 호의 발신 및 목적지 종점을 나타낸다.

TerminalConnection.answer()

애플리케이션은 들어오는 호가 언제 나타나게 될 것인지를 위해 관측자 (후술함)와 함께 터미널 상을 모니터한다. 터미널로 들어오는 전화 호는 링잉(RINGING) 상태 (후술하는 터미널 접속 상태 참조)에 있는 그 터미널로의 터미널 접속에 의해 표시된다. 이 때, 애플리케이션은 그 들어오는 전화 호에 응답하기 위해 TerminalConnection.answer()를 호출할 수도 있다.

Connection.disconnect()

Connection.disconnect() 메소드는 전화 호로부터 어드레스를 제거하는 데 사용된다. 접속 객체는 전화 호에 대한 이 어드레스의 관계를 나타낸다. 일반적으로, 애플리케이션은 접속이 접속(CONNECTED) 상태에 있을 때, 이 메소드를 호출하여, 접속을 단절(DISCONNECTED) 상태로 옮긴다. 중심 패키지에서, 애플리케이션은 그 호로부터 전체 어드레스를 제거하고, 이 호의 일부분인 그 어드레스와 관련된 모든 터미널들 역시 제거된다. 호 제어 확장 패키지는 애플리케이션이 개별 터미널들을 단지 이 호로부터만 제거하는 능력을 제공한다.

접속 객체 상태(Connection Object States)

접속 객체는 항상 호와 어드레스간의 관계를 반영하는 상태에 있다. 접속이 존재하는 상태는 정보 목적의 애플리케이션에 중요한 것만은 아니고, 접속 객체 상에서 어떤 메소드 및 연산이 호출될 수 있는지를 항상 나타낸다. 접속 객체가 겪게 되는 상태 변화는 이하 상태 천이도에 도시된 규칙에 의해 지배된다. 이 천이도는 접속 객체가 주어진 현재 상태에 대해 천이할 수 있는 가능한 상태들을 애플리케이션 개발자에게 제공한다. 이 상태 천이 규칙은 애플리케이션 개발자에게는 쓸모가 없다. 도 11은 접속 객체에 대해 가능한 상태 천이를 도시한다. 각 상태의 의미에 대해 간단히 요약한다.

유휴(IDLE) 상태

유휴 상태는 모든 새로운 접속 객체에 대한 초기 상태이다. 일반적으로 접속은 유휴 상태에서 다른 상태로 재빨리 천이한다. 유휴 상태에서의 접속은 당사자가 어떠한 형태로 전화 호에 막 참여하였음을 나타낸다. 유휴 상태에서는 어떠한 중심 메소드도 유효하지 않다.

진행 중(INPROGRESS) 상태

진행 중 상태는 전화 호가 현재 목적지 종점으로 배치되고 있음을 나타낸다.

경보(ALERTING) 상태

경보 상태는 전화 호의 목적지 당사자가 들어오는 전화 호로 경보를 받게 됨을 나타낸다.

접속(CONNECTED) 상태

접속 상태는 한 당사자가 전화 호의 활성 일부가 됨을 나타낸다. 접속 상태에서의 접속은 관련 당사자가 호상에서 다른 당사자들과 통화하고 있거나 또는 톤(tone)에 연결되어 있음을 의미한다.

단절(DISCONNECTED) 상태

단절 상태는 한 당사자가 더 이상 전화 호의 일부가 되지 않음을 나타낸다. 단절 상태에서의 접속에 대해서는 어떠한 메소드도 유효하지 않다.

실패(FAILED) 상태

실패 상태는 종점에 배치된 전화 호가 실패하였음을 나타낸다. 예를 들어, 애플리케이션이 전화 호를 통화 중인 당사자에게 배치하기 위해 Call.connect()를 호출하는 경우, 이 호출되는 당사자와 관련된 접속은 실패 상태로 천이한다.

부지(UNKNOWN) 상태

부지 상태는 공급자가 현재의 접속 상태를 결정할 수 없음을 나타낸다. 접속은 단절 상태나 실패 상태에 있지 않는 한, 언제라도 부지 상태 안밖으로 천이할 수도 있다. 이 상태에 있는 접속 상에서 어떤 메소드를 호출하였을 때의 영향은 예측할 수 없다.

터미널 접속 객체 상태(TerminalConnection Object States)

터미널 접속 객체는 터미널과 접속 간의 관계를 나타낸다. 상술한 바와 같이, 이 객체들은 어떤 물리적 종점이 전화 호의 일부인지를 기술하는 호의 물리적 관점이다. 접속 객체와 유사하게, 터미널 접속 객체는 자체 상태 집합과 상태 천이도를 갖고 있다. 도 12에 도시된 상태 천이도와 각 상태의 간단한 설명을 이하에서 설명한다.

유휴(IDLE) 상태

유휴 상태는 모든 터미널 접속 객체에 대한 초기 상태를 나타낸다. 이는 접속 객체의 유휴 상태와 동일한 의미를 갖는다.

능동(ACTIVE) 상태

능동 상태는 터미널이 능동적으로 전화 호의 일부가 됨을 나타낸다. 이는 종종 터미널 핸드셋이 오프-훅(off-hook)되어 있음을 의미한다.

링잉(RINGING) 상태

링잉 상태는 터미널이 들어오는 전화 호가 이 터미널에 존재함을 사용자에게 시그널링(signalling)하고 있는 것을 나타낸다.

해제(DROPPED) 상태

해제 상태는 터미널이 한때 전화 호의 일부였으나, 이후 그 전화 호가 해제되었음을 나타낸다. 해제 상태는 모든 터미널 접속의 최종 상태이다.

수동(PASSIVE) 상태

수동 상태는 터미널이 전화 호의 일부가 되지만, 능동적으로 그렇지는 않다는 것을 나타낸다. 수동 상태에 있는 터미널 접속은 그 터미널 상의 자원이 이 전화 호에 의해 사용되고 있음을 나타낸다. 발전된 기능을 제공하는 패키지들은 터미널들이 수동 상태로부터 호에 참가할 수 있게 허용한다.

부지(UNKNOWN) 상태

부지 상태는 공급자가 터미널 접속의 현재 상태를 결정할 수 없음을 나타낸다. 이는 접속 객체의 부지 상태와 동일한 의미를 갖는다.

전화 호의 배치(Placing a Telephone Call)

전술한 섹션들을 통해 JTAPI 호 모델, 중심 패키지 내의 필수적인 메소드들, 및 접속과 터미널 접속 상태에 대해 살펴보았다. 본 섹션에서는, 이러한 모든 정보와 함께, 대부분의 전화 통신 애플리케이션에서 찾아볼 수 있는 공통적인 시나리오에 대해 설명한다. 본 섹션은 애플리케이션이 간단한 전화 호를 배치할 때 전체 호 모델이 일반적으로 겪는 상태 변화에 대해 설명한다. 독자는 이 간단한 예제에 대한 호 모델 변화에 대해 논리적인 이해를 갖게 될 것이다.

호 모델에 의해 겪게 되는 상태 변화를 설명하는 데 사용되는 도구가 도 13에 도시되어 있다. 이 도면은 호 모델 타이밍도로서, 다양한 객체들에서의 변화들이 종축을 따라 시간이 경과함에 따라 도시되어 있다. 본 타이밍도는 애플리케이션이 Call.connect() 메소드를 호출한 이후의 전형적인 상태 변화를 도시한다.

도 13에서는, 불연속 시간 단계가 종축의 하향 방향으로 정수로 표현되어 있다. 시간은 이 축의 하향으로 증가하지만, 정수들은 실제 (시계) 시간을 의미하는 것은 아니다.

도 13은 전체적으로, 단일 전화 호를 나타낸다. 이 경우에, 도면은 2-당사자 전화 호를 나타낸다 (Call.connect() 메소드는 항상 2-당사자 호를 초래함). 타이밍도는 좌측과 우측의 두 부분으로 나누어질 수 있다. 좌측 절반은 전화 호의 발신지 종점을, 우측 절반은 전화 호의 목적지 종점을 나타낸다.

타이밍도의 좌측 (발신지 측)에서, 두 개의 수직선은 도면에 도시된 바와 같이, 발신지 터미널과 어드레스 (이들은 Call.connect() 메소드의 인수에 해당함)를 나타낸다. 수평선들은 표시된 바에 따라 접속 객체 또는 터미널 접속 객체를 나타낸다. 접속 객체는 내측 영역에 도시되어 있고, 터미널 접속 객체는 외측 영역에 도시되어 있다.

유사하게, 타이밍도의 우측 (목적지 측)에서, 두 개의 수직선은 목적지 터미널과 어드레스를 나타낸다. 본 예에서는, 목적지 어드레스와 관련된 두 개의 목적지 터미널이 존재한다. 이러한 구성은 도 10에 이미 도시한 바 있다. 2개의 터미널이 존재하기 때문에, 목적지 측에는 2개의 터미널 접속 객체가 존재함을 주목하기 바란다.

도 13을 읽는 방법은 다음과 같다. 시간이 경과함에 따라, 접속 및 터미널 접속 객체는 상태를 변화시킨다. 새로운 접속 또는 터미널 접속 수평선이 나타나는 것은 그러한 유형의 새로운 객체가 생성됨을 의미한다.

전화 호를 배치하는 본 예에서는, 두 개의 접속이 유휴 상태로 생성된 후, 발신지 접속은 접속 상태로, 목적지 접속은 진행 중 상태로 각각 천이함을 알 수 있다. 이 때, 발신 터미널로의 터미널 접속이 생성되어, 능동 상태로 천이하게 된다. 목적지 접속이 경보 상태로 천이하게 될 때, 2개의 터미널 접속이 링잉 상태로 생성된다.

이 때, 목적지 터미널들 중 하나에 있는 사람이 호에 응답한다. 이 경우, 그 터미널 접속은 능동 상태로 이동하고, 다른 터미널 접속은 수동 상태로 이동한다. 동시에, 목적지 접속은 접속 상태로 동시에 이동한다. 전화 호가 종료될 때, 모든 접속은 단절 상태로 이동하고, 모든 터미널 접속은 해제 상태로 이동한다.

마지막으로, 본 문서에서는 전화 호의 '논리적' 및 '물리적' 관점이란 용어를 사용하였다. 본 타이밍도는 이러한 개념을 명확히 보여준다. 애플리케이션은 접속 객체의 상태 변화들 (즉, 논리적 관점)을 모니터한다. 본 터이밍도를 살펴봄으로써, 독자는 이들 상태가 전화 호의 진행에 대한 상위 레벨 관점을 제공함을 이해할 수 있다. 터미널 접속 상태 변화들은 물리적 관점을 나타낸다. 터미널 접속 상태 변화를 관찰함으로써, 애플리케이션은 각 물리적 종점에서 무엇이 일어나는 지를 알 수 있다.

자바 전화 통신 관측자 모델 (The Java Telephony Observer Model)

자바 전화 통신 API는, JTAPI 호 모델에서 다양한 변화의 애플리케이션을 비동기적으로 인식하기 위해, 관측자/관측 가능한 모델을 사용한다. 이들 변화에는 객체의 상태 변화나 객체의 생성 등이 포함될 수 있다.

공급자, 호, 터미널, 및 어드레스 객체는 관측자를 갖는다. 이들 관측자에 대응하는 인터페이스는, 각각 공급자 관측자(ProviderObserver), 호 관측자(CallObserver), 터미널 관측자(TerminalObserver), 및 어드레스 관측자(Address Observer)이다.

공급자 관측자(ProviderObserver)는 공급자 객체에 모든 상태 변화를 보고한다. 중심 패키지에 대하여, 상태 변화들은, 공급자가 서비스 이탈 상태(OUT_OF_SERVICE)로부터, 서비스 중 상태(IN_SERVICE)로, 셧 다운 상태(SHUTDOWN)로 상태 변화할 때, 보고된다.

호 관측자(CallObserevr)는 호 자체의 상태 변화뿐 아니라, 전화 호의 일부가 되는 모든 접속 및 터미널 접속들에 대한 상태 변화 정보를 보고한다. 이 상태 변화들은 어드레스 관측자나 터미널 관측자 상에서는 보고되지 않는다.

때때로, 애플리케이션은 들어오는 전화 호에 대해서 어드레스 또는 터미널 객체를 모니터하기를 원한다. 이러한 경우에, 애플리케이션은 Address.addCallObserver()나 Terminal.addCallObserver() 메소드를 사용한다. 이 메소드들은 구현(implementation)에게 호 관측자(CallObserver)를 어드레스 또는 터미널로 들어오는 임의의 호에 자동적으로 추가하도록 명령한다. 이 호 관측자들은 호가 이 어드레스 또는 터미널을 일단 떠나게 되면, 제거된다.

어드레스 및 터미널 관측자는 이들 객체들에서의 임의의 상태 변화를 보고한다. 중심 패키지에는, 이들 객체들을 위한 어떠한 이벤트도 존재하지 않는다. 그러나, 어드레스 관측자(AddressObserver) 및 터미널 관측자(TerminalObserver) 인터페이스는 여전히 존재하고, 다른 패키지들은 이 인터페이스들을 확장하기도 한다.

공급자의 배치 및 획득(Locating and Obtaining Providers)

자바 전화 통신 API는 JTAPI의 전화 통신 서버 구현이 그 서비스를 애플리케이션에 유용하도록 하는 규약을 정의한다.

애플리케이션을 서버에 연결하는 2 요소는 다음과 같다.

JtapiPeerFactory

JtapiPeerFactory 클래스는 전화 통신 서비스를 필요로 하는 애플리케이션의 제1 접촉 위치이다. 이는 명명된 JtapiPeer 객체나 디폴트 JtapiPeer 객체를 리턴하는 능력을 갖는다. 이는 정적(static) 클래스로 정의된다.

JtapiPeer

JtapiPeer 인터페이스는 자바 전화 통신 API의 판매자의 특정 구현을 위한 기초가 된다. JTAPI의 구현을 공급하는 각 판매자는, JtapiPeerFactory에 의해 로드(load)되는 클래스내에서 이 인터페이스를 구현하여야만 한다.

애플리케이션은 이 JtapiPeer 객체를 구현하는 클래스를 통해서, 공급자 객체를 얻는다.

JtapiPeerFactory : 시작

JtapiPeerFactory는 JTAPI로 정의된 정적 클래스이다. 그 유일한 대중적 메소드 getJtapiPeer()는 요구되는 JtapiPeer 구현을 얻거나, 또는 디폴트 구현을 리턴한다.

getJtapiPeer()는 원하는 JTAPI 서버 구현 클래스의 이름을 그 클래스의 객체 인스턴스를 리턴하기 위한 파라미터로 취한다. 어떠한 이름도 제공되지 않으면, getJtapiPeer()는 디폴트 JTAPI 서버 구현 객체를 리턴한다.

JtapiPeer : 공급자 객체의 획득(Getting a Provider Object)

JtapiPeer는 인터페이스이다. 이는 JTAPI 서버 구현기에 의해 사용되며, 애플리케이션이 공급자 객체의 획득, 이들 공급자상에서 사용가능한 서비스들의 문의, 및 JtapiPeer 객체 인스턴스의 이름의 획득 등을 하기 위하여 사용하는 메소드들을 정의한다. JtapiPeer 인터페이스를 구현하는 클래스들을 생성함으로써, JTAPI 구현은 다음 메소드들이 애플리케이션에 사용 가능하도록 한다.

애플리케이션은 새로운 공급자 객체를 획득하기 위해 JtapiPeer.getProvider() 메소드를 사용한다. 각 구현은 하나 이상의 다른 '서비스'를 지원하기도 한다. JtapiPeer.getServices() 메소드를 사용하여, 사용 가능한 서비스들의 리스트를 얻을 수 있다.

애프리케이션은 또한 선택 인수를 공급자에 공급한다. 이 인수들은 JtapiPeer.getProvider() 메소드로 보내지는 스트링 인수에 부가된다. 스트링 인수는 다음 형식을 갖는다.

<서비스 이름>; 인수 1 = 값 1; 인수 2 = 값 2; ...

여기서, <서비스 이름>은 선택 사항이 아니며, 이에 뒤따르는 각 선택 인수 쌍은 세미콜론으로 구별된다. 이 인수들에 대한 키(key)는 2개의 표준 정의된 키를 제외하고는 구현-특정적이다.

1. login : 공급자에게 로그인 사용자 이름을 제공한다.

2. passwd : 공급자에게 패스워드를 제공한다.

애플리케이션은 이 JtapiPeer 객체 인스턴스의 이름을 얻기 위하여, JtapiPeer.getName() 메소드를 사용한다. 이는 JtapiPeerFactory.getJtapiPeer() 메소드의 인수로서 사용되는 것과 동일한 이름의 이름 파라미터를 갖는다.

자바 전화 통신 API에서의 보안(Security in the Java Telephony API)

JTAPI peer 구현은 민감한 동작으로의 액세스를 제어하기 위해, 자바 '모래 상자(sandbox)' 모델을 사용한다. JTAPI 메소드의 호출자들은, 실행 시스템에 의해 결정되는 기준을 사용하여, '인증(trusted)' 또는 '비인증(untrusted)'으로 구분된다.

인증 호출자는 JTAPI 기능으로의 전체 액세스가 허가된다. 비인증 호출자는 시스템의 상태와 관계없는 동작으로 제한된다.

JTAPI는 자체 보안 메커니즘을 제공하는 전화 통신 서버나 구현을 액세스하는 데 사용될 수 있다. 이 메커니즘은 적절히 유지되며, 사용자 이름 및 패스워드와 같은 파라미터들은 JtapiPeer.getProvider() 메소드 상의 파라미터를 통해 제공된다.

Claims

무선 통신 장치에 있어서,

사용자 애플리케이션 프로그램(16)과, 동작 시에 복수의 터미널 객체(54-58)를 갖는 전화 통신 프로그램(18)을 내장하는 메모리; 및

상기 사용자 애플리케이션 프로그램(16)과 상기 전화 통신 프로그램(18) 간의 애플리케이션 프로그래밍 인터페이스(API)

를 포함하되,

상기 API(30)는 단일 모드 호를 설립하기 위한 인수(argument)를 수용하기 위한 명령을 갖고,

상기 전화 통신 프로그램(18)은, 상기 단일 모드 호를 설립하기 위한 상기 명령의 인수로서, 상기 복수의 터미널 객체(54-58)를 식별하고 상기 단일 모드 호를 설립하는 데 사용하는 명령과 동일한 명령을 사용하여 상기 단일 모드 호를 오버라이딩(overriding)하여 상기 복수의 터미널 객체(54-58)에 대한 이중 모드(dual mode) 호의 설립을 가능하게 하는 배열을 수용하는 무선 통신 장치.
제1항에 있어서,

상기 복수의 터미널 객체(54-58)는 음성 터미널 객체(42), 팩스 터미널 객체, 및 데이터 터미널 객체(44)를 포함하는 그룹으로부터 적어도 2개의 서로 다른 터미널 객체를 선택할 수 있는 무선 통신 장치.
제1항에 있어서,

적어도 상기 복수의 터미널 객체(54-58) 중의 제1 터미널 객체에 의해 제어되는 음성 소자와 상기 복수의 터미널 객체(54-58) 중의 제2 터미널 객체에 의해 제어되는 데이터 소자를 구비하는 무선 통신 장치.
제3항에 있어서,

적어도 상기 전화 통신 프로그램(18)이 실행되는 가상 기계(15)를 갖는 제1 프로세서(10)와 상기 음성 소자와 상기 데이터 소자를 제어하는 송수신기 소프트웨어(20)가 실행되는 제2 프로세서(11)를 더 포함하는 무선 통신 장치.
제4항에 있어서,

상기 제1 프로세서(10)와 상기 제2 프로세서(11) 간의 직렬 링크(22)를 더 포함하는 무선 통신 장치.
제4항에 있어서,

상기 제1 프로세서(10)와 상기 제2 프로세서(11) 간의 링크(22)를 더 포함하되, 상기 링크(22)는 호를 설립하기 위한 명령이 주 유형 및 대체 유형 중 한 가지임을 상기 송수신기 소프트웨어(20)에게 식별시키는 - 상기 대체 유형은 이중 모드 호를 나타냄 - 무선 통신 장치.
무선 통신 장치에서 이중 모드 호를 설립하기 위한 방법에 있어서,

애플리케이션 프로그래밍 인터페이스(API)(30)를 통하여 애플리케이션 프로그램(16)으로부터 단일 모드 호를 설립하는 데 적절한 호 접속 클래스를 호출하는 단계; 및

배열을 포함하는 인수를 갖는 명령을 사용하여 상기 단일 모드 호를 오버라이딩하기 위한 수단을 제공하는 단계 - 상기 배열은 음성 유형(42), 팩스 유형(46) 및 데이터 유형(44)으로부터 선택되는 다른 유형들의 복수의 터미널 객체(54-58)를 포함함 -

를 포함함으로써, 상기 단일 모드 호 접속 클래스를 사용하여 상기 이중 모드 호의 설립을 가능하게 하는 이중 모드 호 설립 방법.
제7항에 있어서,

상기 호 접속 클래스에서 음성 터미널(42)을 참조하는 제1 접속 객체 및 데이터 터미널(44)과 팩스 터미널(46) 중 하나를 참조하는 제2 접속 객체를 호출하는 단계

를 더 포함하는 이중 모드 호 설립 방법.
제7항에 있어서,

상기 애플리케이션 프로그램(16)은 단일 터미널 객체를 포함하는 인수를 갖는 명령을 사용하여 이중 모드 호의 설립을 지원하지 않는 호 접속 클래스와도 인터페이스할 수 있는 이중 모드 호 설립 방법.
제7항에 있어서,

상기 호 접속 클래스는 단일 터미널 객체를 포함하는 인수를 갖는 명령에 의해 호출될 수 있어, 단일 모드 호를 설립할 수 있는 이중 모드 호 설립 방법.
무선 통신 장치에 있어서,

사용자 애플리케이션 프로그램(16)과 전화 통신 프로그램(18)을 내장하는 메모리; 및

상기 사용자 애플리케이션 프로그램(16)과 상기 전화 통신 프로그램(18) 간의 애플리케이션 프로그래밍 인터페이스(API)

를 포함하되,

상기 전화 프로그램(18)은 이벤트 식별자(ID)를 각각 갖는 정의된 이벤트 세트를 구비하고, 상기 정의된 이벤트 세트는

(a) 기본 클래스,

(b) 공급자(provider) 이벤트 클래스,

(c) 어드레스 및 호 제어 어드레스 이벤트 클래스,

(d) 호 및 호 제어 호 이벤트 클래스,

(e) 접속 및 호 제어 접속 이벤트 클래스,

(f) 터미널 및 호 제어 터미널 이벤트 클래스,

(g) 터미널 접속(54) 및 호 제어 터미널 접속 이벤트 클래스, 및

(h) 매체 이벤트 클래스

로 그룹이 지어지고,

상기 API(30)는 상기 애플리케이션 프로그램(16)으로부터의 명령을 수용하고, 상기 명령은 상기 이벤트 클래스 내의 이벤트를 정의하는 ID와 함께, 상기 그룹 (a) 내지 (h) 중 하나로부터 단일 모드 호를 설립하기 위한 이벤트 클래스를 정의하며, 상기 ID는 상기 단일 모드 호의 설립을 오버라이딩하고 동일한 이벤트 클래스를 사용하여 이중 모드를 설립하기 위한 것인 무선 통신 장치.
제11항에 있어서,

각 정의된 이벤트는 메소드를 정의하는 컴퓨터 프로그램을 갖고, 정의된 이벤트 세트 중의 이벤트들에 대응하는 메소드들을 위한 모든 컴퓨터 프로그램들은 하나의 클래스 객체 내에 포함되며, 상기 클래스 객체보다 더 하위 레벨의 객체들에서 부차로 정의(subdefine)되지 않는 것을 특징으로 하는 무선 통신 장치.
삭제
삭제