KR20000034944A

KR20000034944A - 사용자 응용 프로그램과 전화 통신 프로그램사이의 ａｐｉ 및 그 방법을 구비한 무선 통신 장치 및 방법

Info

Publication number: KR20000034944A
Application number: KR1019990041254A
Authority: KR
Inventors: 마디스제임스이.
Original assignee: 비센트 비.인그라시아; 모토로라 인코포레이티드
Priority date: 1998-09-28
Filing date: 1999-09-27
Publication date: 2000-06-26
Also published as: JP2000165960A; TW457823B; EP0994614A3; IL131630A0; DE69924337T2; JP4362178B2; BRPI9904366B8; DE69924337D1; CA2282996C; AU4484599A; EP1519532A2; AR021829A1; CN1249640A; ATE291806T1; KR100342952B1; CN1226885C; HK1026997A1; US6269254B1; EP1519532A3; EP0994614B1

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}

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

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

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

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

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

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

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

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

GSM 통신 장치의 내용에는, 기존의 JTAPI 문법(syntax)과 방법 시그너춰(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)들이 포함된다. 음성 통신 소자에는 그 예로서 음성 코더가 포함되고, 데이터 통신 소자에는 그 예로서 데이타 모뎀이나 팩스 모뎀등이 포함된다. 마이크로 프로세서들은 Microware Systems Corporation of Des Moines, Iowa에 의해 공급되는 OS 9000등과 같은 오퍼레이팅 시스템(OS)(14)를 구비한다. 오퍼레이팅 시스템위에는 상용의 JAVA(TM) 가상 기계와 같은 가상 기계(15)가 존재한다. 이 가상 기계(15)상에서, 응용 프로그램(16)과 다양한 다른 JAVA(TM) 클래스(17)들이 실행된다. 이 클래스(17)중의 하나가 JTAPI 구현(18)이다. 마이크로 프로세서(11)는 호 제어, 프레이밍(framing) 및 블럭 코딩등의 일반적 바이트 레벨의 조작과 같은 기능을 수행하는 송수신기 소프트웨어(20)를 갖는다. 송수신기 소프트웨어(20)는 공통 서비스 공급자 모듈 인터페이스(CSPMI)(22)를 통해 오퍼레이팅 시스템(14)와 통신한다.

도 1의 구성의 대안으로서, 마이크로 프로세서 A 및 B는 도 2의 가상선으로 도시된 것과 같이 단일 집적 회로(25)로 효과적으로 통합될 수 있다. 이 실시예에서, 마이크로 프로세서(10), 하드웨어(13), 오퍼레이팅 시스템(14), 가상 기계(15) 및 여러 소프트웨어 소자(16-18)들은 도 1의 실시예와 동일하다. 마이크로 프로세서 B 대신에, 마이크로 프로세서(10)와 단일 집적 회로(25)로 집적된 디지탈 신호 처리기(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)는 JTAPI 시방서 1.2 판에 기재된 것바와 같이, "공급자(Provider)"와 같은 고레벨 객체의 문법이나 동작을 정의하고, 부록 A에 나타내었다. 또한, GSM에 특정한 소정의 동작이 지원되는데, 이를 위해 다음의 특정 의미 체계 구조(semantics)를 정의한다.

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

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

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

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

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 코드와 어드레스 플래그에 대한 목적지 어드레스 스트링을 분석한다. 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 문법과 방법 시그너춰(signature)를 사용하여 쉽게 억세스될 수 없다. 다른 시그너춰를 갖는 다음의 새로운 방법이 정의된다.

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

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

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

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

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

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

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

도 4는 도 3의 JTAPI 구현(18)의 상세를 도시한다. 이 방법의 중심에는 공급자(provider) 방법(40)이 있다. 이 공급자 방법은 오퍼레이팅 시스템(14)와 인터페이스한다. 본 명세서에서 사용되는 바와 같이, "방법"은 클래스 내부에 정의된 것으로 이 클래스의 인스턴스상에서 동작하는 기능을 의미한다. 공급자 방법(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()는 그 인자로서 터미널 객체를 기대함으로써, 이 터미널로의 단일 모드 호 설립을 허가한다. 이중 모드 호를 설립하기 위하여, 본 발명의 양호한 실시예는, 단일 개시 터미널 대신에 터미널 배열을 제1 인자로 취하는 방법을 추가하기 위해, call.connect()가 중첩되는 것을 허용한다. 이 터미널 배열은 명령 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
CalledParty1	PHONE_NUMBER	C
RepeatIndicator2	REPEAT_INDICATOR	O
CallType2	CALL_TYPE	O
DataParameters3	DATA_PARAMETERS	C
CLIRDisposition4	CLIR_DISPOSITION	O
CUGInfo5	CUG_INFO	O

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

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

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

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

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

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

패러미터 이름	패러미터 유형	M/O/C
CallHandle1	CALL_HANDLE	C

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

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

표 1에서, 호 유형(2)는 대체 호 유형을 나타내고, 이 대체 호 유형이 데이타 또는 팩스(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를 제공하고, getConferenceController()와 getTransferController()는 <널(NULL)>을 리턴한다.

setConferenceEnable(), getConferenceEnable(), setTransferEnable() 및 getTransferEnable()는 이 호를 전달 또는 회의하는 능력을 제어하는 내부 플래그들을 조작한다.

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

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

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

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

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

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

호 제공(call forwarding)이 "TermForwardingActiveEv" 특정 터미널에 대해 활성인 지를 애플리케이션이 결정할 수 있도록, 새로운 터미널 이벤트가 정의된다. 다른 서비스들(즉, 음성, 팩스 및 데이타)을 위한 제공(forwarding)은 적절한 터미널 객체(즉, 음성(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)에 있다고 판정되면, 프로그램(또는 방법)은 다른 기능이 탐색(scanning) 동작을 단계(154)에서 수행하는 동안, 단계(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를 사용한 2 실제 코드 예제가 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 상태

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 개의 터미널 접속이 RINGING 상태로 생성된다.

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

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

자바 전화 통신 관측자 모델 (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)는 호를 설립하기 위한 명령을 구비하고, 상기 전화 통신 프로그램(18)은 이 호를 설립하기 위한 상기 명령의 인자로서 상기 복수의 터미널 객체(54-58)를 식별하는 배열을 받아들여, 상기 복수의 터미널 객체(54-58)에 대한 호의 설립을 허용하는 무선 통신 장치.
제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)에게 식별시키는 무선 통신 장치.
무선 통신 장치에서 이중 모드 호를 설립하기 위한 방법에 있어서,

음성 유형(42), 팩스 유형(46) 및 데이타 유형(44)로부터 선택되는 다른 유형들의 복수의 터미널 객체(54-58)를 포함하는 배열을 그 인자로 갖는 명령을 사용하여, 호 접속 클래스를 응용 프로그래밍 인터페이스(API)(30)를 통하여 응용 프로그램(16)으로부터 호출하는 단계를 특징으로 하는 이중 모드 호 설립 방법.
제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)는, 상기 그룹 (a) 내지 (h)중 하나의 사건 클래스를 정의하는 명령을, 이 사건 클래스내의 사건을 정의하는 ID와 함께, 상기 응용 프로그램(18)으로부터 받아들이는 것을 특징으로 하는 무선 통신 장치.
제11항에 있어서, 각 정의된 사건은 방법을 정의하는 컴퓨터 프로그램을 갖고, 일조의 정의된 사건의 사건들에 대응하는 방법들을 위한 모든 컴퓨터 프로그램들은 하나의 클래스 객체내에 포함되며, 이 클래스 객체보다 더 하위 레벨의 어떤 객체에서도 재차 정의(subdefine)되지 않는 것을 특징으로 하는 무선 통신 장치.
사용자 응용 프로그램(16)과 전화 통신 프로그램(18)을 내장하는 메모리를 포함하는 무선 통신 장치의 동작 방법에 있어서,

호 객체(50)을 생성하기 위해 상기 전화 통신 프로그램(18)내의 프로그램을 호출하고, 상기 무선 통신 장치를 위한 무선 서비스가 설립되었는 지에는 관계없이 상기 호 객체(50)를 생성하는 단계; 및

호의 배치를 개시하기 위해 상기 전화 통신 프로그램(18)내의 프로그램을 호출하되, 무선 서비스가 설립되지 않은 경우에는 무선 서비스가 설립되는 것을 대기하는 단계를 특징으로 하는 무선 통신 장치 동작 방법.
제13항에 있어서, 상기 호의 배치를 개시하기 위한 상기 전화 통신 프로그램(18)내의 상기 프로그램을 호출한 뒤의 타임 아웃(timeout)이후에도 서비스가 설립되지 않으면, 상기 응용 프로그램(16)에 에러를 리턴하는 단계를 더 포함하는 무선 통신 장치 동작 방법.