KR20040108248A - 개방형 정산 프로토콜 정합 시스템 및 그 방법 - Google Patents

개방형 정산 프로토콜 정합 시스템 및 그 방법 Download PDF

Info

Publication number
KR20040108248A
KR20040108248A KR1020030039165A KR20030039165A KR20040108248A KR 20040108248 A KR20040108248 A KR 20040108248A KR 1020030039165 A KR1020030039165 A KR 1020030039165A KR 20030039165 A KR20030039165 A KR 20030039165A KR 20040108248 A KR20040108248 A KR 20040108248A
Authority
KR
South Korea
Prior art keywords
message
osp
request
state
processing
Prior art date
Application number
KR1020030039165A
Other languages
English (en)
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
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to KR1020030039165A priority Critical patent/KR20040108248A/ko
Publication of KR20040108248A publication Critical patent/KR20040108248A/ko

Links

Classifications

    • 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
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/5087—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to voice services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4535—Network directories; Name-to-address mapping using an address exchange platform which sets up a session between two nodes, e.g. rendezvous servers, session initiation protocols [SIP] registrars or H.323 gatekeepers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

1. 청구범위에 기재된 발명이 속하는 기술분야
본 발명은, 개방형 정산 프로토콜(OSP : Open Settlement Protocol) 정합 방법 및 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체에 관한 것임.
2. 발명이 해결하려고 하는 기술적 과제
본 발명은, 개방형 정산 프로토콜(OSP : Open Settlement Protocol)을 지원하지 않는 장치를 위하여 개방형 정산 프로토콜(OSP : Open Settlement Protocol) 서버로부터 인증 및 정산 서비스를 받을 수 있도록 하는 개방형 정산 프로토콜(OSP : Open Settlement Protocol) 정합 방법 및 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공하는데 그 목적이 있음.
3. 발명의 해결 방법의 요지
본 발명은, OSP 서비스를 이용하고자 하는 인터넷 서비스 제공자(ISP)로부터 주어진 요청을 받아 트랜잭션 관리 및 이벤트 전이의 처리를 수행하고 상기 인터넷 서비스 제공자(ISP)에게 전달할 정보를 받아 메시지로 구성하여 전달하기 위한 레코드 라우팅 처리수단; 탑재된 OSP 처리 기능을 바탕으로 상기 인터넷 서비스 제공자(ISP)와 관련하여 주어진 요청에 따라 상기 OSP 처리 서버에 대해 OSP 클라이언트로 동작하여 OSP 서비스를 이용할 수 있도록 하는 OSP 클라이언트 처리수단; 및 상기 레코드 라우팅 처리수단과 상기 OSP 클라이언트 처리수단을 통해 상기 제1 인터넷 서비스 제공수단과 상기 OSP 처리 서버에 대한 정합을 처리하도록 하기 위해 상기 OSP 클라이언트 처리수단과 상기 레코드 라우팅 처리수단에서 발생하는 이벤트에 대한 진행 결정을 수행하는 정합처리수단을 포함함.
4. 발명의 중요한 용도
본 발명은 인터넷 전화 서비스 시스템 등에 이용됨.

Description

개방형 정산 프로토콜 정합 시스템 및 그 방법{Adaptation System and Method for Open Settlement Protocol Client}
본 발명은, 개방형 정산 프로토콜(OSP : Open Settlement Protocol) 정합 시스템 및 그 방법 및 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체에 관한 것으로, 더욱 상세하게는 개방형 정산 프로토콜(OSP)을 지원하지 않는 장치를 개방형 정산 프로토콜(OSP) 서버와 연동시키기 위한 개방형 정산 프로토콜(OSP) 정합 시스템 및 그 방법과 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체에 관한 것이다.
통신 기술의 발달에 따라 기존의 통신망은 인터넷 프로토콜(IP : Internet Protocol) 기반의 차세대 네트워크(NGN : Next Generation Network) 구조로 통합이 추진되고 있으며, 서비스 형태도 음성주도형 서비스에서 음성과 데이터가 혼합된 멀티미디어형 서비스로 전환되는 추세이다. 또한, 기존 공중 교환 전화망(PSTN : Public Switched Telephone Network) 서비스를 인터넷 기반으로 대체하는 인터넷 전화 서비스가 출현하게 되었다. 인터넷 전화 서비스(VoIP : Voice Over Internet Protocol)는 인터넷으로 음성정보를 전달하는 음성 데이터 통합 기술로, 전화 사용자의 음성을 디지털 데이터로 변환시켜 인터넷 즉, IP 망을 통해 전송하는 것으로, 기존 공중 교환 전화망(PSTN)에서 처럼 회선을 독점적으로 사용하지 않기 때문에 통화요금을 대폭 낮출 수 있다.
오늘날의 기업들은 통신요금을 절감하고 음성과 데이터를 통합하여 사용할 수 있는 사설망 구축을 적극적으로 도입하거나 활용을 검토하고 있는 추세이며, 개인 사용자도 향후 IP 기반의 유무선 인터넷 전화 서비스를 많이 활용하게 될 것이다.
따라서, 인터넷 전화 서비스 공급자(ITSP : Internet Telephone Service Provider)와 사설기업망이 많이 생겨나게 되고, 이러한 환경에서는 인터넷 전화 서비스 공급자(ITSP)들과 사설기업망 가입자들 간에 다양한 통화 서비스를 교환하기 위하여 가격정보, 인증, 정산 정보를 교환하여야 한다. 이와 같이, 인터넷 전화 사업자들, 즉 인터넷 전화 서비스 공급자(ITSP)와 사설 통신망 간에 가격정보, 인증,정산 정보를 교환하기 위하여 필요한 프로토콜이 개방형 정산 프로토콜(OSP : Open Settlement Protocol)이다.
개방형 정산 프로토콜(OSP)은 인터넷 전화 서비스에서 사용자 인증과 과금을 관리하기 위한 통신규약으로서, 복수의 인터넷 전화 사업자들 간에 인증과 과금 정보를 주고 받을 때 사용한다. 개방형 정산 프로토콜(OSP)은 에치닷323(H.323), 에스아이피(SIP : session initiation protocol) 등의 호 제어 프로토콜을 지원하며, 클라이언트-서버 구조를 갖는다. 즉, OSP 서버는 라우팅 및 과금 정산의 주체가 되고, OSP 클라이언트는 인터넷 전화 서비스 공급자(ITSP) 또는 사설기업망의 호 제어 서버에 탑재되어 서비스가 제공된다.
인터넷 전화 사업자 A에 가입한 발신자가 인터넷 전화 사업자 B에 가입한 착신자로 호를 설정할 때 개방형 정산 프로토콜(OSP)은 다음과 같은 절차로 진행된다.
먼저 발신자가 인터넷 전화 사업자 A로 인터넷 전화 연결을 요청한다. 그러면, 인터넷 전화 사업자 A는 착신자 번호가 다른 인터넷 전화사업자 B에 속한 가입자임을 확인하고 OSP 서버로 인증 요구 메시지를 보낸다. OSP 서버는 인터넷 전화 사업자 A로 인터넷 전화 사업자 B의 주소 정보와 암호화 토큰을 포함한 인증 응답 메시지를 보낸다.
그러면, 인터넷 전화 사업자 A와 인터넷 전화 사업자 B 간에 호 설정이 이루어지고 통화가 이루어진다.
이후, 통화가 종료되면 인터넷 전화 사업자 A는 사용내역 정보를 포함하는사용내역 표시 메시지를 OSP 서버로 보내고, 그에 대한 응답으로 상기 OSP 서버로부터 사용내역 확인 메시지를 전달받는다.
마찬가지로, 인터넷 전화 사업자 B는 사용내역 정보를 포함한 사용내역 표시 메시지를 OSP 서버로 보내고, 그에 대한 응답으로 상기 OSP 서버로부터 사용내역 확인 메시지를 전달받는다.
상기한 바와 같이 개방형 정산 프로토콜(OSP)은 서로 다른 인터넷 전화 사업자간에 통화가 이루어지도록 하고, 그에 따른 정산을 할 수 있도록 정보를 제공한다.
한편, 개방형 정산 프로토콜(OSP)을 적용할 경우, 크게 3가지 형태로 구성이 가능하다.
첫째, 게이트웨이 기반의 제어 구조로, 발신측이 H.323 게이트웨이(또는, SIP 게이트웨이)만 갖추고 있는 환경에서 OSP 서버로부터 호 설정 서비스를 받아서 상기 발신측 게이트웨이가 라우팅 및 인증 기능을 수행하며, OSP 클라이언트가 발신측 H.323 게이트웨이(또는, SIP 게이트웨이)와 착신측 H.323 게이트웨이(또는, SIP 게이트웨이)에 탑재된다.
둘째, 서버기반 제어 구조로, 발신측이 H.323 게이트키퍼 또는 SIP 서버를 갖추고 있는 환경에서 OSP 서버로부터 호 설정 서비스를 받아서 상기 발신측 H.323게이트키퍼 또는 SIP서버가 라우팅 및 인증 기능을 수행하며, OSP 클라이언트가 발신측 H.323 게이트키퍼(또는, SIP 서버)와 착신측 H.323 게이트웨이(또는, SIP 서버)에 탑재된다.
셋째, 직접 제어 구조로, 발신측이 H.323 게이트웨이와 H.323 게이트키퍼를 갖추고 있는 환경에서 H.323 게이트키퍼가 라우팅과 인증을 위한 대행자로서의 기능을 수행하고, H.323 게이트웨이가 호 설정과 해제 기능을 수행한다. 즉, H.323 게이트키퍼는 인증 요구, 인증 응답 메시지 교환을 수행하고 H.323 게이트웨이는 사용내역 표시, 사용내역 확인 메시지 교환 기능을 수행한다. OSP 클라이언트는 발신측 H.323 게이트키퍼(또는, SIP 서버)와 H.323 게이트웨이(또는, SIP 게이트웨이) 및 착신측 H.323 게이트웨이(또는, SIP 게이트웨이)에 탑재된다.
이와 같이, 인터넷 전화 서비스 공급자 또는 사설 통신망 간에 가격정보, 인증, 정산 정보를 교환하기 위해서는 게이트웨이, 게이트키퍼, SIP 프락시 서버 등의 통신 장비가 개방형 정산 프로토콜(OSP)을 지원하는 OSP 클라이언트를 탑재하여야 한다.
그런데, 기존의 구축되어 있는 통신 장비가 개방형 정산 프로토콜(OSP)을 지원하지 않는 경우에, 이러한 통신 장비를 교체 또는 업그레이드하여야 하므로, 과도한 비용 및 시간의 손실이 뒤따를 뿐만 아니라, 일시적인 서비스의 중단이나 전면적인 재설정으로 인한 예기치 못한 오류 발생 등의 가능성이 있어 인터넷 전화 사업자에게 어려움을 안겨다 준다는 문제점이 있었다.
이러한 종래기술의 문제점에 대해 도면을 바탕으로 살펴보면 다음과 같다.
도 1 은 종래의 개방형 정산 프로토콜의 인터넷 전화 서비스 시스템에 대한 구성예시도이다.
도 1에 도시된 바와 같이, 인터넷 전화 서비스 시스템은 인터넷 서비스 제공사업자(ISP : Internet Service Provider) A(11), ISP B(12), OSP 서버(13), 상기한 ISP A(11)에 가입한 발신 단말기(14), ISP B(12)에 가입한 착신 단말기(15)를 포함한다.
여기서, ISP A(11)는 발신(Originating)측 게이트웨이(G/W : Gateway, 111)와 "RADIUS" 또는 "TACACST"의 데이터베이스 서버(112)를 포함하며, ISP B(12)도 마찬가지로 수신측 게이트웨이(Terminating G/W, 121) 및 "RADIUS"와 같은 데이터베이스 서버(112)를 포함한다.
도 1은 종래기술의 환경에서 정산 네트워크 토폴로지(Settlement network topology)에 기반한 전형적인 게이트웨이 서비스를 나타낸다.
일반 음성이나 팩스 서비스 호(Call)가 시작되면 착신측 게이트웨이(Terminating G/W, 121)로 라우트되기 위하여 "RADIUS"나 "TACACST"와 같은 데이터베이스 서버(112)와 접속하여 사용자 인증(user authentication) 및 아이에스피(ISP : intra-internet service provider) 호 어카운팅(call accounting) 정보를 수집한다.
아이브이알(IVR : Interactive Voice Response)과 같은 스크립트(script)를 이용하여 호 발신자(caller)의 데이터를 수집한 발신측 게이트웨이(originating G/W, 111)는 시작된 호를 정산 서버(Settlement server) 즉, OSP 서버(13)에게 전달(forward)한다.
정산 서버(Settlement server, 13)는 호에 대한 권한위임(authorization) 및 보다 상세한 정보를 토큰(token)에 넣어서 게이트웨이(111)로 전달한다.
전달된 토큰(token)은 발신측 게이트웨이(originating gateway, 111)를 통하여 착신측 게이트웨이(terminating gateway, 121)로 전달된다.
착신측 게이트웨이(terminating gateway, 121)는 IVR 등을 이용하여 정산 토큰(Settlement token)을 평가(validate)하고 성공적이면 그 호를 피비엑스(PBX : private branch exchange)를 통하여 전화나 팩스(FAX) 기계와 같은 착신측 단말기(15)로 전달(forward)한다. 이렇게 하여 통화가 이루어지도록 한다.
통화가 종료되면 착신측 게이트웨이(terminating gateway, 121) 및 발신측 게이트웨이(originating gateway, 111)는 정산 서버(Settlement server, 13)에게 호 세부내역(Call Detail)을 전송하고 정산 서버(Settlement server, 13)는 이를 받아서 두 데이터에 대한 협상을 통하여 정산 정보를 최적화된 룰(rule)에 의해서 조절한다.
상기한 바와 같은 도 1에서는 OSP의 전형적인 모델을 제시하고 있다. 이와 다른 종래의 경우를 살펴볼 수 있는데, 이는 도 2와 같다.
도 2 는 종래의 개방형 정산 프로토콜의 인터넷 전화 서비스 시스템에 대한 다른 구성예시도이다.
도 2는 종래기술의 환경에서 도 1과는 다른 경우로서, 발신자가 속한 VoIP 서비스 제공자(Provider)가 OSP 기능이 없는 경우의 서비스 모델을 나타낸다. 즉, 도 2는 발신측 단말기(originating terminal)이 OSP 기능이 없는 일반 VoIP인 경우를 나타내는 OSP 서비스 시스템 구성도이다.
도 2를 통해 통해 제시되는 종래의 OSP 서비스 시스템은, VoIP전화기(Phone)와 같은 VoIP 단말기(21), 발신측 ISP에 속하는 게이트키퍼(gatekeeper : G/K, 22), 게이트키퍼(22)와 인터넷(internet)으로 연결되는 착신측 게이트웨이(Terminating G/W, 23), 정산 서버(Settlement Server)라고 칭할 수 있는 OSP 서버(24), 착신 단말기로 연결하기 위한 5계층 스위치(class 5 switch) 또는 PBX와 같은 교환기(25) 및 착신 단말기(26)를 포함한다.
이를 바탕으로 도 2에 도시된 시스템의 동작을 살펴보면 다음과 같다.
VoIP 인증을 위하여 착신측 게이트웨이(Terminating gateway, 23)는 인터넷(internet)이나 인트라넷(intranet)으로 정산 서버(Settlement server) 즉, OSP 서버(24)와 연결된다.
OSP 서버(24)는 "Windows NT"나 "UNIX" 등과 같은 컴퓨터 운영 시스템으로 구성될 수 있다.
OSP 기능이 없는 VoIP 장비(21)가 H.323의 연결 요구(INVITE) 메시지를 게이트키퍼(gatekeeper, 22)로 보내면 게이트키퍼(gatekeeper, 22)는 OSP 기능이 있는 착신측 게이트웨이(terminating gateway, 23)로 호를 라우팅한다.
이때, 게이트키퍼(gatekeeper, 22)는 라우팅 정보로 디엔아이에스(DNIS : Destination number)를 이용한다. 또한, 게이트웨이(gateway, 23)는 자신이 구성한 피오티에스(POTS : plain old telephone service) 다이얼 피어(dial peer)에 의거하여 OSP 인증요청(AuthorizationRequest) 메시지를 정산 서버(Settlement server) 즉, OSP 서버(24)로 OSP 링크{Link(intranet 또는 internet)}를 이용해서 전송한다.
인증요청(AuthorizationRequest) OSP 메시지는 특유의 16비트 숫자(unique 16-bit number)로 만들어진 호-식별자(Call-ID)와 '이닷164 에이엔아이/디엔아이에스(E.164 ANI/DNIS)' 포맷(format)인 호출 번호(Calling number), 발신 번호(Called number)를 필수적으로 포함한다.
OSP 서버(server, 24)는 엘디에이피(LDAP : lightweight directory access protocol)나 오라클(Oracle)과 같은 데이터베이스(Database : DB)에 저장된 정보를 근간으로 하여 정보검색, 매칭 비교를 통해 라우팅 정보 및 사용자 인증 등에 관한 판단을 내린 후, 인증응답(AuthorizationResponse) OSP 메시지를 착신측 게이트웨이(terminating gateway, 23)에게 전송한다.
착신측 게이트웨이(terminating gateway, 23)는 응답 코드(Response Code)가 인증되었음을 의미하는 200이면 도면에 도시된 것처럼 티원-피알아이{T1-PRI(primary rate interface)} 스팬(span)들 중 하나를 통하여 PBX나 5계층 스위치(class 5 switch)와 같은 교환기(25)로 호 설정을 시작한다.
착신측 게이트웨이(Terminating gateway, 23)가 호 종료를 감지(detect)하면 OSP 서버(server, 24)로 사용시간 및 호 종료 이유를 포함하는 사용표시(UsageIndication) 메시지를 전송하고 호를 종료시킨다.
그러나, 상기한 바와 같은 종래의 서비스 시스템은 발신자 VoIP 서비스 제공자의 게이트웨이가 OSP 클라이언트 기능을 보유하지 않음으로 해서 OSP의 원래 기능인 발신측과 착신측에서 보내오는 정보를 바탕으로 하는 정산 처리가 이루어지지 못하여 OSP 서비스가 가지는 특징 및 효능을 충분히 발휘하지 못한다는 문제점이있었다.
본 발명은, 상기와 같은 문제점을 해결하기 위하여 제안된 것으로, 개방형 정산 프로토콜(OSP)을 지원하지 않는 장치를 위하여 개방형 정산 프로토콜(OSP) 서버로부터 인증 및 정산 서비스를 받을 수 있도록 하는 개방형 정산 프로토콜(OSP) 정합 시스템 및 그 방법 및 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공하는데 그 목적이 있다.
도 1 은 종래의 개방형 정산 프로토콜의 인터넷 전화 서비스 시스템에 대한 구성예시도.
도 2 는 종래의 개방형 정산 프로토콜의 인터넷 전화 서비스 시스템에 대한 다른 구성예시도.
도 3 은 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 대한 일실시예 구성도.
도 4 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 대한 일실시예 구성도.
도 5 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy)의 스펙을 나타내는 일실시예 블럭도.
도 6a 내지 도 6e 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템을 위한 프로토콜 데이터 유닛(PDU)에 대한 일실시예 설명도.
도 7 은 본 발명에 따른 개방형 정산 프로토콜 정합 방법에 대한 일실시예 흐름도.
도 8 은 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시에서의 일실시예 상태 전이도.
도 9 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에서 활용되는 레코드라우팅 요청(RecordRoutingRequest) 메시지에 대한 일실시예 설명도.
도 10 은 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy)의 레코드 라우팅(RecordRouting) 모듈에서 상태 결정에 대한 일실시예 흐름도.
도 11 은 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy) 상의 유휴 상태(Idle State) 메시지에 대한 상태 변화를 나타내는 일실시예 흐름도.
도 12a 내지 도 12c 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시에 대한 일실시예 설명도.
도 13 은 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy) 상의 상태2(State2, No Pending Trans) 메시지에 대한 상태 변화를 나타내는 일실시예 흐름도.
도 14 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy) 상에서 OSP 서버로부터 응답받은 메시지에 대한 처리 절차를 나타내는 일실시예 흐름도.
* 도면의 주요 부분에 대한 부호 설명
31 : ISP A 32 : ISP B
33 : 커넥트 프록시(Connect proxy) 34 : OSP 서버
35 : 단말기 A 36 : 단말기 B
311 : 발신측 게이트웨이 321 : 착신측 게이트웨이
312 : 발신측 레디우스(RADIUS) 서버
322 : 착신측 레디우스(RADIUS) 서버
51 : OSP 클라이언트 모듈 52 : 레코드라우팅 모듈
53 : 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈
71 : H.323 터미널 72 : 게이트키퍼
73 : 커넥트 프록시 74 : OSP 서버
75 : OSP 게이트웨이 76 : 일반 전화
상기의 목적을 달성하기 위하여 본 발명의 장치는, 개방형 정산 프로토콜(OSP)을 활용하는 통신 시스템에 있어서, 개방형 정산 프로토콜(OSP)에 대한 처리 기능을 탑재하지 않은 상태에서 소속된 단말기들에 인터넷 서비스를 제공하기 위한 제1 인터넷 서비스 제공수단; 네트워크를 통해 연결된 클라이언트들에게 개방형 정산 프로토콜(OSP)을 통한 서비스를 제공하기 위한 OSP 처리 서버; 상기 네트워크 상에 위치하여 상기 제1 인터넷 서비스 제공수단에서의 요청에 따라 상기 OSP 처리 서버의 클라이언트로서 동작하여 상기 제1 인터넷 서비스 제공수단을 통해 개방형 정산 프로토콜(OSP)을 이용하는 서비스를 제공할 수 있도록 하기 위한 정합수단; 및 개방형 정산 프로토콜(OSP)에 대한 처리 기능을 탑재하여 개방형 정산 프로토콜(OSP)을 통한 서비스를 이용하고자 하는 소속된 단말기들에게 상기 OSP처리 서버와 연계하여 서비스를 제공하기 위한 제2 인터넷 서비스 제공수단을 포함한다.
또한, 본 발명의 다른 장치는, 개방형 정산 프로토콜(OSP)에 대한 처리 기능이 없는 인터넷 서비스 제공자(ISP)와 개방형 정산 프로토콜(OSP) 처리 서버를 활용하는 통신 시스템에 있어서, OSP 서비스를 이용하고자 하는 상기 인터넷 서비스 제공자(ISP)로부터 주어진 요청을 받아 트랜잭션 관리 및 이벤트 전이의 처리를 수행하고 상기 인터넷 서비스 제공자(ISP)에게 전달할 정보를 받아 메시지로 구성하여 전달하기 위한 레코드 라우팅 처리수단; 탑재된 OSP 처리 기능을 바탕으로 상기 인터넷 서비스 제공자(ISP)와 관련하여 주어진 요청에 따라 상기 OSP 처리 서버에 대해 OSP 클라이언트로 동작하여 OSP 서비스를 이용할 수 있도록 하는 OSP 클라이언트 처리수단; 및 상기 레코드 라우팅 처리수단과 상기 OSP 클라이언트 처리수단을 통해 상기 제1 인터넷 서비스 제공수단과 상기 OSP 처리 서버에 대한 정합을 처리하도록 하기 위해 상기 OSP 클라이언트 처리수단과 상기 레코드 라우팅 처리수단에서 발생하는 이벤트에 대한 진행 결정을 수행하는 정합처리수단을 포함한다.
또한, 본 발명의 방법은, 개방형 정산 프로토콜(OSP) 정합 시스템에 적용되는 개방형 정산 프로토콜(OSP) 정합 방법에 있어서, 개방형 정산 프로토콜(OSP)에 대한 클라이언트 기능을 보유하지 않은 인터넷 서비스 제공자(ISP)로부터 네트워크를 통해 근원지(source), 목적지(Destination) 및 연결 요청된 호(call)에 대한 정보를 포함하는 라우팅 요청(request) 메시지를 전달받아 확인하는 제 1 단계; 전달받은 상기 라우팅 요청(request) 메시지에 대해 주어진 정보를 바탕으로 점검을 수행하고 인증 요청(AuthorizationRequest) 메시지를 생성하여 OSP 처리 서버로 발송하는 제 2 단계; 상기 인증 요청(AuthorizationRequest) 메시지를 전달받아 포함된 정보를 정보를 바탕으로 가입자 인증을 수행하고 라우팅 정보를 연산한 상기 OSP 처리 서버로부터 인증 결과 및 라우팅 정보를 인증 응답(Authorizationresponse) 메시지로 전달받는 제 3 단계; 상기 인증 응답(Authorizationresponse) 메시지에 담긴 정보를 파악하여 상기 라우팅 요청(request) 메시지에 대한 응답(RoutingResponse) 메시지로 구성하여 상기 인터넷 서비스 제공자(ISP)로 전달하는 제 4 단계를 포함한다.
또한, 본 발명의 다른 방법은, 개방형 정산 프로토콜(OSP) 정합 시스템에 적용되는 개방형 정산 프로토콜(OSP) 정합 방법에 있어서, 정합을 처리하기 위한 커넥트 프록시(Connect proxy)가 인터넷 서비스 제공자(ISP)로부터 라우팅 요청(Request) 메시지를 전달받아 요청 큐(Request Queue)의 비어있는지의 여부와 요청 트랜잭션(Request Transaction)의 처리(Processing)가 보류(pending) 중인지의 여부를 체크하여 유휴상태(Idle State) 또는 보류 처리 상태(No Pending TRANS State)로 상태 전이시키거나 요청 큐(Request Queue)에 적재하여 관리하는 제 1 단계; 유휴상태(Idle State)의 메시지에 대해 상기 커넥트 프록시(Connect proxy)의 정합처리수단에서의 처리 진행에 관한 승인 여부를 점검하여 승인된 경우에는 상기 메시지에 대해 승인된 요청(Approved Request) 상태로 전이시켜 관리하고, 승인 거부된 경우에는 미승인된 요청(Disapproved Request) 상태로 전이시켜 관리하는 제 2 단계; 상기 승인된 요청(Approved Request) 상태의 메시지 및 상기 미승인된 요청(Disapproved Request) 상태의 메시지에 대해 요청 해제(RequestRelease)의 여부를 파악하여, 요청 해제(RequestRelease)된 경우에는 상기 보류 처리 상태(No Pending TRANS State)로 상태를 전이시켜 관리하고, 요청 해제(RequestRelease)되지 않은 경우에는 메시지 전송 상태(Sending Message State)로 전이시키는 제 3 단계; 상기 보류 처리 상태(No Pending TRANS State)의 메시지에 대해 같은 요청의 새 메시지가 있는지의 여부, 요청 해제(RequestRelease)를 이유로 상태가 전이되었는지의 여부, 처리중인 요청프로세스에 대한 시간 경과(time out)가 발생한 상황에서 이의 처리 절차에 대한 상기 정합처리수단에서의 응답 내용에 따라 상기 메시지의 상태를 전이시키고 이에 따른 처리를 수행하는 제 4 단계; 상기 메시지 전송 상태(Sending Message State)의 메시지에 대해 이전의 상태를 감안하여, OSP 처리 서버로 인증요청(AuthorizationRequest) 메시지를 발송하여 서비스 요청한 후 상기 메시지에 대해 응답 대기하거나, 상기 인터넷 서비스 제공자(ISP)로 요청거부(RequestReject)의 메시지를 구성하여 전송하는 제 5 단계; 및 상기 OSP 처리 서버로부터 상기 인증요청(AuthorizationRequest) 메시지에 대한 응답을 받아 상기 OSP 처리 서버로부터의 응답 결과를 확인하고 이에 따라 라우팅응답(Routing Response) 메시지를 구성하여 상기 인터넷 서비스 제공자(ISP)로 발송하고 는 제 6 단계를 포함한다.
또한, 본 발명은, 프로세서를 구비한 개방형 정산 프로토콜(OSP) 정합 시스템에, 개방형 정산 프로토콜(OSP)에 대한 클라이언트 기능을 보유하지 않은 인터넷 서비스 제공자(ISP)로부터 네트워크를 통해 근원지(source), 목적지(Destination)및 연결 요청된 호(call)에 대한 정보를 포함하는 라우팅 요청(request) 메시지를 전달받아 확인하는 제 1 기능; 전달받은 상기 라우팅 요청(request) 메시지에 대해 주어진 정보를 바탕으로 점검하고 인증 요청(AuthorizationRequest) 메시지를 생성하여 OSP 처리 서버로 발송하는 제 2 기능; 상기 인증 요청(AuthorizationRequest) 메시지를 전달받아 포함된 정보를 정보를 바탕으로 가입자 인증을 수행하고 라우팅 정보를 연산한 상기 OSP 처리 서버로부터 인증 결과 및 라우팅 정보를 인증 응답(Authorizationresponse) 메시지로 전달받는 제 3 기능; 상기 인증 응답(Authorizationresponse) 메시지에 담긴 정보를 파악하여 상기 라우팅 요청(request) 메시지에 대한 응답(RoutingResponse) 메시지로 구성하여 상기 인터넷 서비스 제공자(ISP)로 전달하는 제 4 기능을 포함한다.
또한, 본 발명은, 프로세서를 구비한 개방형 정산 프로토콜(OSP) 정합 시스템에, 인터넷 서비스 제공자(ISP)로부터 라우팅 요청(Request) 메시지를 전달받아 요청 큐(Request Queue)의 비어있는지의 여부와 요청 트랜잭션(Request Transaction)의 처리(Processing)가 보류(pending) 중인지의 여부를 체크하여 유휴상태(Idle State) 또는 보류 처리 상태(No Pending TRANS State)로 상태 전이시키거나 요청 큐(Request Queue)에 적재하여 관리하는 제 1 기능; 유휴상태(Idle State)의 메시지에 대해 처리 진행에 대한 승인 여부를 점검하여 승인된 경우에는 상기 메시지에 대해 승인된 요청(Approved Request) 상태로 전이시켜 관리하고, 승인 거부된 경우에는 미승인된 요청(Disapproved Request) 상태로 전이시켜 관리하는 제 2 기능; 상기 승인된 요청(Approved Request) 상태의 메시지 및 상기 미승인된 요청(Disapproved Request) 상태의 메시지에 대해 요청 해제(RequestRelease)의 여부를 파악하여, 요청 해제(RequestRelease)된 경우에는 상기 보류 처리 상태(No Pending TRANS State)로 상태를 전이시켜 관리하고, 요청 해제(RequestRelease)되지 않은 경우에는 메시지 전송 상태(Sending Message State)로 전이시키는 제 3 단계; 상기 보류 처리 상태(No Pending TRANS State)의 메시지에 대해 같은 요청의 새 메시지가 있는지의 여부, 요청 해제(RequestRelease)를 이유로 상태가 전이되었는지의 여부, 처리중인 요청프로세스에 대한 시간 경과(time out)가 발생한 상황에서 이의 처리 절차에 대한 판단 내용에 따라 상기 메시지의 상태를 전이시키고 이에 따른 처리를 수행하는 제 4 기능; 상기 메시지 전송 상태(Sending Message State)의 메시지에 대해 이전의 상태를 감안하여, OSP 처리 서버로 인증요청(AuthorizationRequest) 메시지를 발송하여 서비스 요청한 후 상기 메시지에 대해 응답 대기하거나, 상기 인터넷 서비스 제공자(ISP)로 요청거부(RequestReject)의 메시지를 구성하여 전송하는 제 5 기능; 및 상기 OSP 처리 서버로부터 상기 인증요청(AuthorizationRequest) 메시지에 대한 응답을 받아 상기 OSP 처리 서버로부터의 응답 결과를 확인하고 이에 따라 라우팅응답(Routing Response) 메시지를 구성하여 상기 인터넷 서비스 제공자(ISP)로 발송하는 제 6 기능을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 포함한다.
상기한 도 2의 종래기술과 같이 발신자 VoIP 서비스 제공자(provider)가 소유한 게이트웨이가 OSP 클라이언트 기능을 보유하지 않은 경우에 OSP 주 기능중 라우팅, 인증을 대신 처리하는 OSP 에이전트 서버를 구비하여, 마치 도 1과 같이 발신자/착신자 서비스 제공자(Provider)에서 OSP 서비스 혜택을 받도록 하여, 효율적인 멀티미디어 전화서비스 시스템을 구축한다.
상술한 목적, 특징들 및 장점은 첨부된 도면과 관련한 다음의 상세한 설명을 통하여 보다 분명해 질 것이다. 이하 첨부된 도면을 참조하여 본 발명에 따른 바람직한 일실시예를 상세히 설명한다.
도 3 은 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 대한 일실시예 구성도이다.
도 3에 도시된 바와 같이, 본 발명에 따른 개방형 정산 프로토콜 정합 시스템은 인터넷 서비스 제공 사업자(ISP) A(31), 인터넷 서비스 제공사업자(ISP) B(32), 커넥트 프록시(Connect proxy, 33), OSP 서버(34), ISP A(31)에 가입한 단말기 A(35), 및 ISP B(32)에 가입한 단말기 B(36)를 포함한다.
여기서, 커넥트 프록시(Connect proxy, 33)는 ISP A(21)의 게이트키퍼(211)가 OSP 클라이언트를 탑재하고 있지 않으므로 OSP 클라이언트 기능을 수행하는 개방형 정산 프로토콜(OSP)의 정합을 위한 연결 장치로, 서로 다른 인터넷 서비스 제공사업자(ISP) 간에도 개방형 정산 프로토콜(OSP)을 사용하여 OSP 서버(34)로부터 인증 및 요금 정산 서비스를 받을 수 있도록 한다.
한편, ISP A(31)와 ISP B(32)는 OSP 클라이언트를 탑재한 게이트웨이(311, 321)와 가입자들에 대한 인증, 과금, 권한인증을 수행하는 레디우스(RADIUS) 서버(312, 322)를 포함하고 있다.
도 3을 살펴보면 이는 종래의 OSP 기본 모델이라 할 수 있는 도 1의 변형임을 알 수 있다. 특히, 서로 다른 ISP간에 OSP를 이용할 수 있도록 OSP 클라이언트 기능을 수행하지 못하는 ISP 측에 커넥트 프록시(Connect proxy)가 구비되어 OSP 정합에 이용된다.
도 4 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 대한 일실시예 구성도이다.
도 4를 통해 통해 제시되는 본 발명에 따른 OSP 정합 시스템은, VoIP 전화기(Phone)와 같은 VoIP 단말기(41), 발신측 ISP에 속하는 게이트키퍼(gatekeeper : G/K, 42), 커넥트 프록시(Connect proxy, 43), 정산 서버(Settlement Server)라고 칭할 수 있는 OSP 서버(44), 착신측 게이트웨이(Terminating G/W, 45), 착신측 게이트웨이(45)와 같은 ISP에 속하는 레디우스(RADIUS) 서버(46), 착신 단말기로 연결하기 위한 5계층 스위치(class 5 switch) 또는 PBX의 교환기(25) 및 착신 단말기(26)를 포함한다.
도 4는 도 3과 마찬가지로 커넥트 프록시(Connect proxy, 43)를 이용해서 OSP 서비스 시스템을 나타낸 구성도로서, OSP 기능이 없는 VoIP장비(41)는 H.323 게이트키퍼(gatekeeper, 42)에게 H.323 셋업(setup) 메시지를 보낸다.
H.323 게이트키퍼(gatekeeper, 42)는 착신측 게이트웨이(terminating gateway, 45)로의 라우팅 정보 및 착신측 게이트웨이(terminating gateway, 45)에서의 발신자(caller) 인증을 위한 정보를 얻기 위하여 본 발명에 따른 커넥트 프록시(Connect proxy, 43)로 근원지-정보(Source-Info) 및 목적지-정보(Dest-Info)를보낸다.
보다 구체적으로 살펴보면, 근원지-정보(Source-Info), 목적지-정보(Dest-Info), 호식별자(Call-ID), 발신자(Caller)의 아이피 주소(IP Adress) 및 "E.164" 정보, 착신자(Called)의 아이피 주소(IP Adress) 및 "E.164" DNIS를 포함한다.
라우팅요청(RoutingRequest) 메시지를 전달받은 커넥트 프록시(Connect proxy, 43)는 OSP 클라이언트의 역할을 다음과 같은 과정을 거쳐 수행한다.
- 커넥트 프록시(Connect proxy, 43)가 게이트키퍼(gatekeeper, 42)로부터 근원지-정보(Source-Info) 및 목적지-정보(Destination-Info)를 받는 과정.
- 커넥트 프록시(Connect proxy, 43)가 OSP 서버(44)로 인증요청(AuthorizationRequest) 메시지를 생성하여 보내는 과정.
- OSP 서버(44)가 커넥트 프록시(Connect proxy, 43)로부터 받은 '근원 VoIP 디바이스 이닷164(originating VoIP device E.164)' 및 가입자 식별정보(Subscriber ID)로 확인(Authentication)하는 과정.
- OSP 서버(44)가 목적지-정보(Dest-Info)의 "E.164" DNIS를 이용하여 착신측 게이트웨이(terminating gateway, 45)의 라우팅 정보(Routing Information)를 파악하는 과정.
- OSP 서버(44)가 커넥트 프록시(Connect proxy, 43)에게 가입자 확인(Subscriber Authentication) 및 라우팅 정보(Routing Information)를 응답(Response)하는 과정.
- 커넥트 프록시(Connect proxy, 43)가 게이트키퍼(gatekeeper, 42)에게 OSP링크(Link)를 이용하여 라우팅 요청(Routing Request)에 대한 응답(Response) 메시지를 생성, 전송하는 과정.
커넥트 프록시(Connect proxy, 43)로부터 라우팅응답(RoutingResponse) 메시지를 받은 게이트키퍼(gatekeeper, 42)는 착신측 게이트웨이(terminating gateway, 45)로 H.323 셋업(setup) 메시지 및 발신자(Caller)를 상세히 나타내는 토큰(Token) 정보를 '에치닷323 셋업 토큰 필드(H.323 setup token field)'에 입력한 후 전송한다.
착신측 게이트웨이(Terminating gateway, 45)는 IVR 등을 이용하여 정산 토큰(Settlement token)을 평가(validate)하고 성공적이면 그 호를 PBX와 같은 교환기(47)를 통하여 전화나 팩스(FAX)로 전달(forward)한다.
통화가 종료되면 착신측 게이트웨이(termianting gateway, 45)는 정산 서버(Settlement server) 즉, OSP 서버(44)에게 호 상세내역(Call Detail)을 전송하고, OSP 서버(44)는 사용표시(UsageIndication) 메시지의 사용상세내역(UsageDetail) 정보를 사용(Usage) 정보 DB에 등록 보관한다.
도 5 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy)의 스펙을 나타내는 일실시예 블럭도이다.
도 5의 주요 부분에 대하여 간단히 살펴보면 다음과 같다.
도면부호 "51"은 종래부터 존재하던 OSP 클라이언트 기능을 포함하는 OSP 핵심 모듈을 나타낸다.
도면부호 "52"는 본 발명을 위해 이용되는 핵심적인 모듈로서, OSP 기능이없는 VoIP 장비와 OSP 서버와의 연결을 위한 트랜잭션 관리 및 이벤트 전이에 대한 레포트를 상위 레벨인 컨넥트 프락시 어플리케이션(Connect Proxy Application) 모듈(53)로 제공한다.
도면부호 "53'은 컨넥트 프락시(Connect Proxy)의 두 핵심 모듈인 레코드라우팅(Record Routing) 모듈(52)과 OSP 클라이언트 모듈(51)간의 발생 이벤트에 대한 진행 결정을 내려주는 최상위 레벨의 어플리케이션 모듈이다.
이를 바탕으로 도 5에 대해 설명하면 다음과 같다.
상기한 것처럼, OSP 클라이언트 모듈(51)은 OSP 클라이언트의 본래 기능을 나타낸다.
레코드라우팅(Record Routing) 모듈(52)은 본 발명을 위해 본래의 OSP 클라이언트(51)에 추가로 구현된 것으로서, OSP 기능이 제공되지 않는 VoIP 엔티티(Entity)가 OSP 서비스를 이용할 수 있도록 가능하게 하는 모듈이다.
이 레코드라우팅(Record Routing) 모듈(52)은 게이트키퍼(gatekeeper)나 VoIP 디바이스로부터 유디피(UDP : User Data Protocol) 형식으로 전달된 레코드라우팅(RecordRouting) 메시지를 해석하고, 상위의 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)로 해석된 메시지 내용을 전달해주는 기능을 제공한다.
또한, 레코드라우팅(Record Routing) 모듈(52)은 반대로 OSP 서버(server)로부터 받은 응답(Response) 결과를 상위의 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)로부터 전달받아 레코드라우팅응답(RecordRoutingResponse) 메시지화해서 게이트키퍼(gatekeeper)나 VoIP 디바이스(device)로 전달하는 기능을 제공한다.
커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)은 레코드라우팅 모듈(RecordRouting module, 52)과 OSP 클라이언트 모듈(51) 사이의 터널링(tunneling) 역할을 수행한다.
상기한 도 5에 대해 다시 한 번 정리하여 설명하면 다음과 같다.
도 5를 통해 제시한 커넥트 프록시(Connect Proxy)는 OSP 클라이언트부(51), 레코드라우팅부(52), 어플리케이션부(53)를 포함한다고 할 수 있다. 상기 OSP 클라이언트부(51)는 OSP 서버로부터 인증 및 정산 서비스를 받을 수 있는 OSP 클라이언트의 본래 기능을 제공한다. 상기 레코드라우팅부(52)는 OSP 기능이 없는 장치로부터 전달된 레코드라우팅 요청(RecordRoutingRequest) 메시지를 해석하여 상기 어플리케이션부(53)의 승인을 받은 후 인증 요청(AuthorizationRequest) 메시지를 생성하여 OSP 서버로 전송하며, OSP 서버로부터 전달받은 인증 응답(AuthorizationResponse) 메시지를 라우팅 응답(RecordRoutingResponse) 메시지로 변환시켜 게이트키퍼(gatekeeper)로 전달하는 기능을 한다. 또한, 어플리케이션부(53)는 레코드라우팅부(52)와 OSP 클라이언트부(51) 사이에서 터널링(tunneling) 역할을 수행하며 메시지의 전송 여부를 승인하는 기능을 수행한다.
도 6a 내지 도 6e 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템을 위한 프로토콜 데이터 유닛(PDU)에 대한 일실시예 설명도이다.
즉, 도 6a 내지 도 6e 는 본발명에 따른 개방형 정산 프로토콜(OSP)정합 시스템에 있어서 커넥트 프록시(Connect proxy)를 통해 이용되는 프로토콜 데이터 유닛(PDU : Protocol Data Unit)의 구조를 하나의 예로서 나타내고 있다.
여기서, 도 6a는 PDU의 기본적인 구조를 나타내고 있고, 도 6b는 PDU의 한 부분인 엘리먼트 컴포넌트(Element Component)의 포맷을 나타내고 있으며, 도 6c는 도 6b에 나타난 속성(Attribute)에 대해 각 식별자(ID)별로 정의하고 있다. 또한, 도 6d는 도 6a에 제시된 바와 같이 동작 코드(Operation Code)에 대해 나타내고 있으며, 도 6e는 역시 도 6a에 제시된 프로토콜 타입(Protocol type)을 나타내고 있다.
이를 바탕으로 도 6a 내지 도 6e를 통해 제시되는 PDU에 대해 보다 상세히 설명한다.
개방형 정산 프로토콜(OSP)을 지원하지 않는 장치를 포함하는 인터넷 전화 서비스 시스템에 있어서 개방형 정산 프로토콜(OSP)을 정합하기 위하여 이용되는 PDU로는 대표적으로 레코드라우팅 요청(RecordRoutingRequest) 메시지와 레코드라우팅 응답(RecordRoutingResponse) 메시지가 있다.
레코드라우팅 요청(RecordRoutingRequest) 메시지와 레코드라우팅 응답(RecordRoutingResponse) 메시지는, 도 6a에 제시된 바와 같이, 최소 34 바이트를 가지며, 인터넷 프로토콜을 위한 IP 헤더(IP Header) 필드(601), 사용자 다이어그램 프로토콜을 위한 UDP 헤더(UDP Header) 필드(602), 개방형 정산 프로토콜(OSP) 정합 장치의 동작 타입을 나타내는 동작 코드(OP code) 필드(603),개방형 정산 프로토콜(OSP) 정합 장치라 할 수 있는 커넥트 프록시(Connect proxy)의 페이로드(payload)의 길이를 나타내는 길이(Length) 필드(604), 지원하는 프로토콜의 종류를 나타내는 타입(Type) 필드(605), 및 근원지(source)와 목적지(destination) 정보 및 비표준 데이터(non-standard Data)를 포함하는 엘리먼트(Eliment) 필드(606)를 포함한다.
더욱 상세히 살펴보면, 상기 동작 코드(OP code) 필드(603)는 개방형 정산 프로토콜(OSP) 정합 시스템의 커넥트 프록시(Connect proxy)에서의 동작 타입을 나타내는데, 도 6d를 통해 살펴볼 수 있는 바와 같이, 그 값이 0이면 요청(Request) 메시지이고, 그 값이 1이면 응답(Response) 메시지이며, 그 값이 2이면 사용자 데이터(User Data)이다.
상기한 타입(Type) 필드(605)는 지원하는 프로토콜의 종류를 나타내는데, 도 6e를 통해 나타나는 바와 같이, 그 값이 0 이면 H.323 프로토콜이고, 그 값이 1이면 SIP이며, 그 값이 2 이면 비표준(Non Standard)의 프로토콜이다.
상기 엘리먼트(Eliment) 필드(606)는 가변적인 길이를 가지며, 도 6b를 통해 보다 상세히 살펴볼 수 있다. 즉, 상기 엘리먼트(Eliment) 필드(606)는 전체 길이를 나타내는 길이(Length) 필드(611), 속성(Attribute)의 종류를 나타내는 속성식별자(Attribute ID) 필드(612), 속성의 길이를 나타내는 속성길이(Attribute Length) 필드(613), 및 가변길이 데이터를 가지는 값(Value) 필드(614)를 포함한다.
또한, 도 6c는 속성식별자(Attribute ID)에 따른 속성길이(AttributeLength)와 기술내용(Description)에 대하여 보다 상세히 나타낸 것이다. 도시된 바와 같이 엘리먼트(606)에 포함되는 각 속성(Attribute)들은 근원지의 정보(Source-Info)와 목적지의 정보(Destination-Info)를 포함하고 있다.
상기한 바와 같은 도 6a 내지 도 6e에 대해 다시 한 번 설명하면 다음과 같다.
도 6a 내지 도 6e는 본 발명에 따라 제시된 커넥트 프록시(Connect proxy)를 위한 PDU의 메시지 구조를 나타낸다.
도 6a에서 보면 레코드라우팅(RecordRouting) PDU는 최소 34바이트(byte)를 갖는 데이터 포맷으로서 IP 통신을 위한 20바이트(byte)의 IP 헤더(header)(601), 근원지(Source) 및 목적지(Destination) 파트(part)를 갖는 UDP 통신을 위한 UDP 헤더(header)(602), 도 6d를 통해 보다 상세히 설명되는 커넥트 프록시(Connect proxy)의 동작 타입(operation code)(603), 커넥트 프록시(Connect proxy)의 페이로드 길이(payload length)(604), 도 6e와 같이 지원프로토콜의 종류를 나타내는 프로토콜 타입(protocol type)(605), 그리고 도 6b와 도 6c를 통해 보다 상세히 설명되는 근원지-정보(Source-Info) 및 목적지-정보(Destination-Info) 그리고 비표준 데이터(Non-standard Data)를 포함하는 엘리먼트(element, 606)로 구성된다.
도 6b는 레코드라우팅(RecordRouting) 메시지의 컴포넌트 포맷(component format)으로서 4바이트(byte)의 크기를 가지고 컴포넌트(component) 전체길이를 나타내는 길이(Length) 필드(field)(611), 도 6c를 통해 보다 자세히 설명되는 속성(Attribute)의 종류를 나타내는 속성식별자(Attribute ID) 필드(field)(612),속성(Attribute)의 길이를 나타내는 속성길이(Attribute Length) 필드(field)(613), 그리고 가변길이 데이터 필드(field)(614)로 구성된다.
통신 프로토콜(protocol)은 도 6a 내지 도 6e를 통해 나타낸 바와 같은 데이터 형식을 표준화한 개념으로서 커넥트 프록시(Connect proxy)는 OSP 기능을 갖지않는 VoIP장비와의 통신을 위해 도 6a 내지 도 6e와 같은 데이터 전송 포맷(format)을 사용한다.
도 7 은 본 발명에 따른 개방형 정산 프로토콜 정합 방법에 대한 일실시예 흐름도이다.
즉, 도 7은 본 발명의 일실시예에 따른 개방형 정산 프로토콜(OSP) 정합 시스템을 바탕으로 개방형 정산 프로토콜(OSP)을 정합하는 방법에 대하여 설명하고 있다.
우선, 도 7에서 제시되는 본 발명에 따른 OSP 정합 시스템의 구성요소들을 간략히 살펴보면 다음과 같다.
- H.323 터미널(Terminal)(71) : VoIP 프로토콜(protocol)인 H.323 클라이언트(client) 기능을 갖는 피시 전화{PC(Personal Computer) phone), 게이트웨이(G/W), 혹은 피시 소프트 전화(PC soft phone)이 해당된다.
- 게이트키퍼(G/K, 72) : H.323 터미널(Terminal)(71)간의 호 관리를 위한 호 매니저 서버 시스템(Call Manager Server system)을 의미한다.
- 커넥트 프록시(Connect proxy, 73) : OSP 클라이언트(client) 기능을 탑재한 시스템으로서, OSP 기능이 없는 H.323 VoIP 엔티티(Entity)와 OSP 서버(server)간의 OSP 서비스(service) 중계역할을 담당하는 장비이다.
- OSP 서버(server)(74) : OSP 클라이언트(client)의 OSP 요청(request) 메시지에 대한 서비스(service)를 처리하는 서버 시스템(server system)이다.
- OSP G/W(75) : OSP 클라이언트(client) 기능을 보유한 H.323 네트워크(network)와 에스시엔(SCN : Switched Circuit Network) 보이스(voice) 네트워크(network)와의 인터페이스(I/F : Interface)를 담당하는 미디어 처리기로서, T1-PRI 스팬(span)들 중 하나를 통하여 PBX측의 5계층 스위치(class5 switch)와 호를 시작하게 된다.
- 일반 전화(General phone, 76) : 일반적인 전화기이다. SCN 일반 가입자 전화 라인(subscriber phone line)을 통하여 연결된다.
상기한 바와 같은 시스템을 그 적용대상으로 본 발명에 따른 OSP 정합 방법의 일실시예를 설명하면 다음과 같다.
먼저, 게이트키퍼(72)가 발신측 단말기(71)로부터 인터넷 전화 연결을 요청하는 호 설정 메시지(H.232 setup)를 받는다(701). 그리고, 상기 게이트키퍼(72)가 발신지 정보와 착신지 정보를 포함하는 레코드라우팅 요청(RecordRoutingRequest) 메시지를 생성하여 개방형 정산 프로토콜(OSP) 정합 장치라 할 수 있는 커넥트 프록시(73)에 전송한다(702).
그러면, 상기 커넥트 프록시(73)가 상기 전달받은 레코드라우팅 요청(RecordRoutingRequest) 메시지를 이용하여 인증 요청(AuthorizationRequest) 메시지를 생성한 후 OSP 서버(74)로 전송한다(703).
상기 OSP 서버(74)는 상기 전달받은 인증 요청(AuthorizationRequest) 메시지를 이용하여 인증을 수행하고, 목적지 게이트웨이로의 라우팅 정보를 파악한 후, 상기 인증 정보와 라우팅 정보를 인증 응답(AuthorizationResponse) 메시지에 실어서 상기 커넥트 프록시(73)로 전송한다(704).
인증 응답(AuthorizationResponse) 메시지를 전달받은 상기 커넥트 프록시(73)가 상기 인증 응답(AuthorizationResponse) 메시지를 해석하고 레코드라우팅 응답(RecordRoutingResponse) 메시지를 생성하여 상기한 게이트키퍼(72)로 전송한다(705).
이후 과정(706~716)은 종래의 방법과 동일하게 진행된다.
즉, 상기 게이트키퍼(72)가 전송받은 레코드라우팅 응답(RecordRoutingResponse) 메시지를 이용하여 착신측 OSP 게이트웨이(75)에 호 설정(H.323 setup) 메시지를 전송한다(706). 상기 착신측 OSP 게이트웨이(75)는 OSP 서버(74)로 인증 요청(AuthorizationRequest) 메시지를 전송하고(707), 상기 OSP 서버(74)로부터 응답으로 인증 응답(AuthorizationResponse) 메시지를 전달받는다(708).
그러면, OSP 게이트웨이(75)는 착신측 단말기(76)에게 링 신호(Ring Signalling)를 전송하고(709), 발신측 게이트키퍼(72)에 호 연결(H.323 Connect) 메시지를 전송하여(710), 발신측 단말기(71)에 전달되도록 한다(711).
이와 같은 과정을 거치면 호 연결이 완성되어 발신측 단말기(71)와 착신측 단말기(76)가 인터넷 전화 통화가 이루어진다(712).
이후, 착신측 OSP 게이트웨이(75)가 호 종료를 감지한 경우에는 사용 시간 및 통화에 대한 상세한 정보를 사용 내역(UsageIndication) 메시지에 실어서 OSP 서버(74)로 전송하고(713), 응답으로 사용 확인(UsageConfirm) 메시지를 전달받는다(714). 그러면, 상기 상기 착신측 OSP 게이트웨이(715)는 호 해제(H.323 Release Complete) 메시지를 상기 발신측 게이트키퍼(72)에 전송하고(715), 상기 발신측 게이트키퍼(72)는 다시 발신측 단말기(71)에 전달하여 호가 완전히 종료된다(716).
이와 같은 본 발명에 따른 OSP 정합 방법의 일실시예를 각 과정을 중심으로 정리하면 다음과 같다.
- 과정 701 : H.323 터미널(terminal)(71)이 H.323 G/K(72)에게 H.323 호 설정(call setup) 메시지를 전달하여 OSP 정합을 시작하는 과정.
- 과정 702 : H.323 G/K(72)는 목적지 디바이스(terminating device)로의 라우팅(Routing) 정보를 얻기 위해서 커넥트 프록시(Connect proxy, 73)로 레코드라우팅 요청(RecordRoutingRequest) 메시지를 발생시켜 전달하는 과정.
- 과정 703 : G/K(72)로부터 받은 레코드라우팅 요청(RecordRoutingRequest) 메시지에 응답하기 위해 OSP 인증 요청(AuthorizationRequest) 메시지를 생성, OSP 서버(74)로 전송하는 과정.
- 과정 704 : OSP 서버(74)는 OSP 서버 DB를 검색하여 목적지 디바이스(terminating device)의 라우팅(routing) 정보를 생성하여 응답(Response) 메시지로서 발송하는 과정.
- 과정 705 : 커넥트 프록시(Connect proxy, 73)가 OSP 서버(74)로부터 도착한 인증 응답(AuthorizationResponse) 메시지의 정보를 해석하고, UDP 통신으로 전달할 레코드라우팅 응답(RecordRoutingResponse) 메시지를 생성하여 G/K(72)가 발송하였던 레코드라우팅 요청(RecordRouning Request) 메시지에 응답하는 과정.
- 과정 706 : G/K(72)가 커넥트 프록시(Connect proxy, 73)에서 제공한 라우팅(routing) 정보에 의거하여 목적지 디바이스(terminating device)로 H.323 호 설정(call setup) 메시지를 전송하는 과정.
- 과정 707 : OSP 기능을 보유한 목적지 게이트웨이(terminating G/W, 75)가 OSP 서버(74)로 인증 요청(AuthorizationRequest) 메시지를 전달하는 과정.
- 과정 708 : 목적지 디바이스(terminating device) 즉, OSP 기능이 있는 착신측 OSP 게이트웨이(75)가 요청한 인증 요청(AuthorizationRequest) 메시지에 대한 응답 메시지를 OSP 서버(74)가 생성하여 OSP 게이트웨이(75)로 응답하는 과정.
- 과정 709 : 목적지 디바이스(terminating device)인 OSP 게이트웨이(75)가 T1-PRI 스팬(span)들 중 하나로 일반 전화 가입자에게 링(Ring) 신호를 발송하는 과정.
- 과정 710 : 목적지 게이트웨이(terminating G/W, 75)가 G/K(72)로 호 연결 신호를 보내는 과정.
- 과정 711 : 발신 VoIP 디바이스(originating VoIP device, 71)에게 G/K(72)가 목적지(terminating) G/W(72)로부터 온 연결(connect) 메시지를 전달하여 호 연결이 완성되는 과정.
- 과정 712 : 발신자가 이용하는 H.323 터미널(terminal)(71)과 수신자가 이용하는 일반 전화(General phone, 76)간에 음성(voice) 통신이 이루어지는 과정.
- 과정 713 : 목적지 게이트웨이(terminating G/W, 713)가 호 종료를 감지(detect)한 경우, 사용 시간 및 통화에 관한 자세한 정보를 OSP 메시지를 통하여 OSP 서버(server)(74)에게 전달하는 과정.
- 과정 714 : OSP 서버(74)가 목적지 디바이스(terminating device, 75)로부터 온 사용 내역(UsageIndication) 메시지에 대한 확인(Confirm) 메시지로 응답하는 과정.
- 과정 715 : 목적지 디바이스(terminating device, 75)가 G/K(72)에게 호 종료 신호를 보내는 과정.
- 과정 716 : G/K(72)는 H.323 터미널(terminal)(71)에게 호 종료 신호를 보내서 호 종료가 완전히 이루어지는 과정.
도 8 은 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시에서의 일실시예 상태 전이도이다.
도 8은 본 발명에 따른 커넥트 프록시(Connect proxy)에 있어서 상태(state) 변화에 대한 일실시예 다이어그램(diagram)으로서, OSP 서버(Server)와 H.323 G/K에 대해 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈과의 상호작용을 기술한다.
이러한, 도 8에 대해 보다 상세히 설명하기 위해 도 9 내지 도 14가 이용된다. 따라서, 도 8에 대해 설명해 나가면서 중간에 해당되는 도면에 대해 설명한다. 또한, OSP 서버(Server), H.323 G/K 및 커넥트 프록시(Connect proxy)와 같은 OSP정합 시스템에 포함되는 구성요소에 대해서는 도 7에서 사용되는 인용번호를 활용하고, 커넥트 프록시(Connect proxy)의 모듈들에 대해서는 이를 나타낸 도 5의 인용번호를 활용한다.
우선, H.323 게이트키퍼(gatekeeper)(72)가 네트워크(network)를 통하여 커넥트 프록시(Connect proxy, 73)에게 레코드라우팅 요청{RecordRoutingRequest(NW1)} 메시지를 전송하면, 커넥트 프록시(Connect proxy, 73)의 레코드라우팅(RecordRouting) 모듈(module)(52)은 커넥트 프록시(Connect proxy, 73)의 사용자 어플리케이션(User Application)인 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)로 이벤트(event)가 발생하였음을 알리고 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)에서의 응답을 기다린다.
커넥트 프록시(Connect proxy, 73)가 실제적으로 아무런 요청(Request) 메시지를 처리하지 않고 있는 상태, 즉 VoIP 엔티티(Entity){OSP 기능을 갖지 않은 게이트웨이(Non OSP G/W) 또는 게이트키퍼(Non OSP G/K)}가 레코드라우팅 요청(RecordRoutingRequest) 메시지를 발동(Invoke)할 수 있는 상태는 상태1{State1(IDLE)}, 상태2{State2(NO PENDING TRANS)}이다.
여기서, 레코드라우팅 요청(RecordRoutingRequest) 메시지에 대해 살펴보자. 도 9는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에서 활용되는 레코드라우팅 요청(RecordRoutingRequest) 메시지에 대한 일실시예 설명도로서, 도면에 도시된 바와 같은 정보를 포함한다.
커넥트 프록시(Connect proxy)의 레코드 라우팅(RecordRoute) 핵심(core) 모듈(module)(52)은 도 9에 제시된 내용을 갖는 레코드라우팅 요청(RecordRoutingRequest) 메시지가 도착하면 상태1(State1) 또는 상태2(State2)를 이벤트(event)로 발생시켜 사용자 어플리케이션(User Application)인 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)로 올려보낸다.
상태1(State1)과 상태2(State2)를 레코드 라우팅(RecordRouting) 모듈(52)에서 결정하는 절차(flow)는 도 10과 같이 표현된다.
도 10 은 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy)의 레코드 라우팅(RecordRouting) 모듈에서 상태 결정에 대한 일실시예 흐름도이다.
게이트키퍼(G/K, 72)로부터 새로운 메시지가 도착하면(1001), 레코드 라우팅(RecordRouting) 모듈(52)은 요청 큐(Request queue)가 비어있는지 확인하고(1002), 비어있으면 상태1(State1)으로 결정하여 전이시키고(1003), 그렇지 않으면 다시 요청 트랜잭션 프로세싱(Request Transaction processing)이 대기(pending)중인지를 체크하여(1004), 대기(pending) 중이면 상태2(State2)로 결정하여 전이시키고(1005), 그렇지 않으면 요청 큐(Request queue)로 큐잉(queuing)한다(1006).
이와 같이 하여 도 8에 도시된 바와 같은 상태1(State1) 및 상태2(State2)가 결정되는 것이다.
레코드 라우팅(RecordRouting) 모듈(52)에서 유휴 상태{Idle State(State1)}로 결정이 난 경우 새로운 요청(Request) 메시지가 도착하게 되면 아래에 설명하는 도 11과 같은 절차에 의하여 처리된다.
도 11 은 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy) 상의 유휴 상태(Idle State) 메시지에 대한 상태 변화를 나타내는 일실시예 흐름도이다.
우선, 상태1(State1), 즉 유휴상태(Idle State)의 메시지가 있는 상태에서, 새로운 요청 메시지(Request Message)가 들어오면(1101), 상태1(State1)의 메시지에 대해 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)로부터 승인이 이루어졌는지를 점검한다(1102). 점검 결과, 승인이 이루어졌으면, 상태1(State1)에 있는 메시지를 상태3(State3) 즉, 승인된 요청(Approved Request) 상태로 변경시키고(1103), 점검 결과, 승인이 이루어지지 않았으면, 상태4(State4) 즉, 미승인된 요청(Disapproved Request) 상태로 변경시킨다(1104).
도 12a 및 도 12b 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시에 대한 일실시예 설명도이다.
우선, 도 12a에서는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy)의 구조(structure)에 대해 도 5에 제시된 도면을 바탕으로 관련 부분만 다시 그려 설명하기로 한다.
도 12a에 도시된 것처럼 레코드 라우팅(RecordRouting) 모듈(52)은 H.323 G/K(72)로부터 온 레코드라우팅 요청(RecordRoutingRequest) 메시지를 요약/정리하여 트랜잭션 키(transaction key) 생성에 필요한 정보를 도 12b와 같이 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)로 전달한다(1201). 그러면, 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)은 트랜잭션(transaction) 생성이 가능한지를 체크하여, 그 결과를 레코드 라우팅(RecordRouting) 모듈(52)로 내려보낸다(1202).
커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)에서의 트랜잭션(transaction) 생성 요청(request)에 대한 반응(response)은 다음과 같이 3가지가 될 수 있다.
- 반응 1) 요청확인(requestConfirm)
- 반응 2) 요청거부(requestReject)
- 반응 3) 요청해제(requestRelease)
각각의 반응에 대해 설명하면 다음과 같다.
반응 1) 요청확인(requestConfirm)은 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)이 요청(request) 메시지에 대하여 긍정적인 반응(positive response)으로써 응답한 것으로, 상태5(STATE5, Sending Message)로 이벤트(event)의 전이가 일어난다.
반응 2) 요청거부(requestReject)는 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)이 요청(request) 메시지에 대하여 부정적인 반응(negative response)으로써 응답한 것으로, OSP 서버(74)로의 서비스 진행을 원하지 않음을 의미한다. 이 경우도 물론 상태5(STATE5) 이벤트(event)로 전이가 일어난다.
반응 3) 요청해제(requestRelease)는 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)이 요청(request) 메시지에 대하여 상기한 반응 2)와 같이 부정적인 반응(negative response)으로 응답한 것이나 상기 반응 2)와는 달리 요청에 대한 결과를 즉시 처리하지 못하거나 추가 정보가 있어야 함을 의미하며, 따라서 아직 요청에 대해 결정되지 않은 상태2(STATE2, NO PENDING TRANS)로 이벤트(event) 전이가 일어난다.
이러한, 반응 1,2,3에 대한 후속 처리를 정리하면 도 12c를 통해 보여지는 바와 같다.
우선, 반응 1)의 경우에는 상태5(STATE5, Sending Message)로 이벤트(event)의 전이가 일어나고, OSP 클라이언트 모듈(51)을 통해 확인된 응답(Confirming answer)을 바탕으로 하는 인증 요청(Authorization Request) 메시지로 구성되어 OSP 서버(74)를 목적지로 한다.
반응 2)의 경우에도 상태5(STATE5, Sending Message)로 이벤트(event)의 전이가 일어나지만, 거부된 응답(Reject answer)을 바탕으로 하는 레코드라우트 응답(RecordRoute Response) 메시지로 구성되어 H.323 G/K(72)를 목적지로 한다.
마지막으로, 반응 3)의 경우에는 상태2(STATE2, NO PENDING TRANS)로 이벤트(event) 전이가 일어나고 후속 메시지는 발생하지 않는다.
도 13 은 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy) 상의 상태2(State2, No Pending Trans) 메시지에 대한 상태 변화를 나타내는 일실시예 흐름도이다.
레코드 라우팅(RecordRouting) 모듈(52)에서 상태2(STATE2, NO PENDING TRANS)로 결정이 난 새로운 요청(request) 메시지가 도착하게 되면 도 13과 같은 절차에 의해 처리될 수 있다.
우선, 요청 큐(Request queue)에 있는 요청(Request) 메시지들 중 같은 트랜잭션 키를 생성하는 메시지가 존재하는지를 점검하여 해당하는 메시지를 찾아낸다(1301). 그리고, 상태2(State2, No Pending Trans)로 대기하고 있던 메시지에 대하여(1302), 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)로 메시지 전송여부 결정을 요청한다(1303). 즉, 응답(Response)을 요구하는 것이다. 이때, 시간 내에 응답이 오면 그에 따라 처리하면 되지만, 이러한 처리에 대해 시간 경과(Time out)가 발생하면, 시간 경과(Time out)에 대해 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)로 요청 불처리에 대한 응답을 할 것인지를 판단해 주도록 요청하고, 그에 대한 응답을 받아 이를 검사한다(1304).
검사 결과, 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)에서 시간 경과(Time out)로 질의한 요청 불처리에 대한 응답을 할 것인지에 대하여 요청거절(RequestReject) 응답을 하지 말도록 답변이 오거나 판단 자료가 소멸되어 판단이 이루어지지 않으면, 상태1(State1)으로 전이하고(1305, 과정822), 검사 결과, 요청거절(RequestReject) 응답을 하도록 답변이 왔으면, 상태5(State5)으로 전이하여(1306, 과정823), 불가 코드(Reject Code)의 요청 응답(Request Response) 메시지를 형성하여 전송한다(1307).
상기한 도 13에서 보여주는 상황와 다른 절차를 가지는 경우가 있는데, 이는 다음과 같다.
즉, 레코드 라우팅(RecordRouting) 모듈(52)에서 상태2(STATE2, NO PENDING TRANS)로 결정이 난 경우의 요청(request) 메시지가 도착하는 상황으로, 상태3(STATE3)이나 상태4(STATE4)로부터 요청해제(requestRelease)를 이유로 이벤트(event)의 전이가 일어나 상태2(STATE2, NO PENDING TRANS)가 된 경우로서 상태1(STATE1)로 이벤트(event)의 전이가 일어난다(822).
상기한 바와 같은 상태2(STATE2, NO PENDING TRANS)에 대해 정리하여 설명하면 다음과 같다.
1) 새로운 요청메시지를 커넥트 프록시(Connect Proxy, 73)가 받은 경우, 받은 메시지와 같은 요청이 이미 처리 보류 중인 경우가 있다.
- 처리1 : 클라이언트 네트워크(Client Network)로부터 온 메시지는 "네트워크(Network) -> 상태2(State2) -> 상태1(State1)"으로 전이된다.
- 처리2 : 새로 들어온 메시지는 상태1(State1)으로 전이되고, 현재 보류중인 메시지에 대하여 승인이 나서 상태3(State3)로 전이된다(813).
- 처리3 : 새로 들어온 메시지는 상태1(State1)으로 전이되고, 현재 보류중인 메시지에 대하여 승인이 나서 상태4(State4)로 전이된다(814).
2) 새로운 요청메시지를 커넥트 프록시(Connect Proxy, 73)가 받은 메시지와 같은 요청이 보류중이지 않은 경우, 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)의 판단에 따라 상태3(State3) 또는 상태4(State4)로 전이된다. 또한, 다음과 같은 처리가 이루어진다.
- 처리1 - "상태3(State3) -> 상태2(State2)" : 상태3(State3)에서 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)이 요청에 대한 응답으로 요청해제(requestRelease)로 응답한 경우, 상태2(State2)에서는 이에 대하여 요청한 클라이언트에게 요청거부(RequestReject)를 응답하라고 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)이 판단하면 상태5(State5)로 전이한다.
- 처리2 - "상태3(State3) -> 상태2(State2)" : 상태3(State3)에서 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)이 요청에 대한 응답으로 요청해제(requestRelease)로 응답한 경우, 상태2(State2)에서는 이에 대하여 요청한 클라이언트에게 요청거부(RequestReject)를 응답하지 말라고 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)이 판단하면 상태1(State1)로 전이한다.
- 처리3 - "상태4(State4) -> 상태2(State2)" : 상태1(State1)로 전이된다.
3) 처리중인 요청프로세스에 대하여 시간경과(Time Out)이 발생하면 다음과 같다.
- 처리1 - "상태2(State2) -> 상태5(State5)" : 상태2(State2)에서 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)이 처리중인 프로세스의 시간경과(Time Out)으로 인한 요청 불처리에 따른 결과에 대한 응답을 할 것인지를 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)에게 판단해 줄것을 요청한 결과, 라우팅 요청(Routing Request)을 한 클라이언트에게 요청거부(RequestReject)로 응답하라고 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)이 판단하면 상태5(State5)로 전이한다.
- 처리2 - "상태2(State2) -> 상태1(State1)" : 상태2(State2)에서 어플리케이션이 처리 중인 프로세스의 시간경과(Time Out)으로 인한 요청 불처리에 따른 결과에 대한 응답을 할것인지를 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)에게 판단해 줄 것을 요청한 결과, 라우팅 요청(Routing Request)을 한 클라이언트에게 요청거부(RequestReject)로 응답하지 말라고 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)이 판단하면 상태1(State1)로 전이한다.
- 처리3 - "상태2(State2) -> 상태8(State8) -> 상태1(State1)" : 상태2(State2)에서 어플리케이션이 처리 중인 프로세스의 시간경과(Time Out)으로 인한 요청 불처리에 따른 결과에 대한 응답을 할것인지를 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)에게 판단해 줄 것을 요청한 결과, 커넥트 프록시 어플리케이션(Connect proxy Application) 모듈(53)에서 요청한 트랜잭션이 내부 사건의 의해 이미 판단 자료가 소멸된 경우에는 상태8(State8, Tran Vacant)를 거쳐 상태1(State1)로 전이된다.
그리고, 그 다음으로, 상태5(STATE5, SENDING MESSAGE)에 대한 설명은 아래와 같다.
상태5(STATE5)는 커넥트 프록시 어플리케이션(Connect proxy Application)모듈(53)의 결정에 의하여 응답(response) 메시지 혹은 OSP 서버(74)로의 서비스(service) 요청(request) 메시지의 전송이 있게 된다. 이때, 전이가 일어나는 경우를 살펴보면 다음과 같다.
경우 1) 상태1(STATE1) -> 상태3(STATE3) -> 상태5{STATE5(OSP 서비스 수행)}
경우 2) 상태1(STATE1) -> 상태4(STATE4) -> 상태5{STATE5(OSP 서비스 거부)}
경우 3) 상태2(STATE2) -> 상태5{STATE5(OSP 서비스 수행)}
경우 4) 상태2(STATE2) -> 상태5{STATE5(OSP 서비스 거부)}
상기한 4가지 경우 중 경우 1, 3은 OSP 서버(74)에게 인증 요청(Authorization Request) 메시지를 H.323 G/K(72)가 현 상황의 주체인 커넥트 프록시(Connect proxy, 73)에게 전송한 메시지 내용에 의거 생성, 전송하고 그에 대한 응답을 받아 상태6(STATE6)으로의 전이가 일어나는 것이다(852).
반면 경우 2와 경우 4는 커넥트 프록시(Connect proxy, 73)에 의해 OSP 서버(74)로의 서비스 요청이 거절된 경우로서, 커넥트 프록시(Connect proxy, 73)에서 401 응답 코드(Response Code)값으로 H.323 G/K(72)로 레코드라우팅 응답(RecordRoutingResponse) 메시지를 전송하여 상태7(STATE7)로의 이벤트 전이가 일어나게 된다.
다음으로, 상태6(STATE6)에 대한 설명은 다음과 같다.
커넥트 프록시(Connect proxy, 73)는 OSP 서버(74)에게 인증요청(Authorization Request) 메시지를 전송한 후 OSP 서버(74)로부터 응답이 오기를 기다린다. OSP 서버(74)에게서 응답이 도착하면 도 14와 같은 절차로 처리된다.
도 14 는 본 발명에 따른 개방형 정산 프로토콜 정합 시스템에 있어서 커넥트 프록시(Connect proxy) 상에서 OSP 서버로부터 응답받은 메시지에 대한 처리 절차를 나타내는 일실시예 흐름도이다.
커넥트 프록시(Connect proxy, 73)가 OSP 서버(74)로부터 인증 응답(Authorization Response) 메시지를 전달받고(1401), 상태6(State6, Receive Response)으로 커넥트 프록시(Connect proxy, 73)에서의 해당 메시지에 관련한 이벤트를 전이시킨다(1402).
다음으로, 전달받은 인증 응답(Authorization Response) 메시지에서 상태코드(Status Code)를 체크하여, 상태코드(Status Code)가 200인지를 확인한다(1403).
인증 응답(Authorization Response) 메시지의 상태코드(Status Code)가 200인지를 확인한 결과, 200이면 OSP 서버(74)로부터 정상적으로 인증을 받은 것이므로, 이를 바탕으로 처리한다(1404~1406, 1408).
구체적으로 살펴보면, 우선, 해당 이벤트에 대한 응답 코드(Response Code)값을 200으로 설정하고(1404), 라우팅 정보(Routing Information)를 인증 응답(Authorization Response) 메시지의 목적지(Destination) 정보에서 얻어 라우팅 요청에 대한 응답(RoutingRequest Response)에서의 목적지주소(DestinationAddress)로 세팅한다(1405). 그리고, 레코드라우트 응답(RecordRoute Response) 메시지를 생성하여(1406), 커넥트 프록시(ConnectProxy, 73)에서 H.323 G/K(72)로 레코드라우트 응답(RecordRoute Response) 메시지를 전송한다(1408).
인증 응답(Authorization Response) 메시지의 상태코드(Status Code)가 200인지를 확인한 결과, 200이 아니면, 레코드라우트 응답코드(RecordRoute Response Code) 값을 상태코드(Status Code) 값으로 하여 메시지를 생성하고(1407), 생성된 레코드라우트 응답(RecordRoute Response) 메시지를 H.323 G/K(72)로 전송한다(1408).
이와 같은 도 14의 내용은 도 8에서 살펴보면, 상태5(Status5, Sending Message)에서 상태6(Status6, Received Response)으로 전이되는 과정(852)부터 상태6(Status6, Received Response) 상태에서의 처리를 거쳐, 상태6(Status6, Received Response)에서 상태7(Status7, Trans Idle)로 전이하는 과정(861)에 해당한다.
그리고 커넥트 프록시(Connect proxy, 73)에서 도 14의 다음에 일어날 과정을 살펴보면 다음과 같다.
도 14와 같은 절차를 거치면, 상태7(STATE7, TRANS IDLE)로 전이가 일어나며, 여기서 더 나아가면, 트랜잭션 키(transaction key)값을 해제(Release)한 후 상태2(STATE2)로의 전이가 일어난다(871). 후속적으로 상태2(Status2)에서 할당된 자원이 해제되어 상태1(Idle)로 돌아간다(822).
상기한 바와 같은 본 발명에 대한 설명을 통해, OSP 기능이 없는 VoIP 사업자망에서 OSP 서비스를 제공할 수 있도록 커넥트 프록시(Connect Proxy)를 제시할뿐만 아니라, OSP 기능을 제공하기 위한 VoIP 게이트웨이 또는 VoIP 게이트키퍼와 커넥트 프록시 사이에 의미전달을 위한 메시지 포맷을 제시하고, 커넥트 프록시에서의 OSP 서비스 플로우와 커넥트 프록시에서의 상태전이 및 해당 상태의 구현에 대해 제시하고 설명하고 있다.
상술한 바와 같은 본 발명의 방법은 프로그램으로 구현되어 컴퓨터로 읽을 수 있는 형태로 기록매체(씨디롬, 램, 플로피 디스크, 하드 디스크, 광자기 디스크 등)에 저장될 수 있다.
이상에서 설명한 본 발명은, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 있어 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치환, 변형 및 변경이 가능하므로 전술한 실시예 및 첨부된 도면에 의해 한정되는 것이 아니다.
상기와 같이 본 발명은, 기존의 개방형 정산 프로토콜(OSP)을 지원하지 않는 게이트웨이, 게이트키퍼, SIP 프락시 서버 등의 통신 장비에 있어서, OSP 클라이언트 기능을 수행하여 OSP 서버와 정합할 수 있도록 하는 시스템 및 그 방법을 제공함으로써, 별도의 통신 장비의 교체없이 인터넷 서비스 사업자 간의 인증 및 요금 정산을 위한 개방형 정산 프로토콜(OSP) 서비스를 이용할 수 있도록 하는 효과가 있다.
또한, 본 발명은, 기존에 사용되던 OSP 비지원 장비에 대한 OSP 서비스를 지원함으로 해서, 서비스 제공자가 OSP 서비스 제어를 보다 수월하게 가져갈 수 있는 효과가 있다.
즉, 본 발명은, OSP 기능이 없는 VoIP 사업자망에서 OSP 서비스를 제공할 수 있도록 커넥트 프록시(Connect Proxy)를 제시할 뿐만 아니라, OSP 기능을 제공하기 위한 VoIP 게이트웨이 또는 VoIP 게이트키퍼와 커넥트 프록시 사이에 의미전달을 위한 메시지 포맷을 제시하고, 커넥트 프록시에서의 OSP 서비스 플로우와 커넥트 프록시에서의 상태전이 및 해당 상태의 구현에 대해 제시하고 설명하고 있어, OSP 기능을 이용하지 못하던 VoIP 사업자망에서 용이하게 이를 이용할 수 있도록 하는 효과가 있다.

Claims (11)

  1. 개방형 정산 프로토콜(OSP : Open Settlement Protocol)을 활용하는 통신 시스템에 있어서,
    개방형 정산 프로토콜(OSP)에 대한 처리 기능을 탑재하지 않은 상태에서 소속된 단말기들에 인터넷 서비스를 제공하기 위한 제1 인터넷 서비스 제공수단;
    네트워크를 통해 연결된 클라이언트들에게 개방형 정산 프로토콜(OSP)을 통한 서비스를 제공하기 위한 OSP 처리 서버;
    상기 네트워크 상에 위치하여 상기 제1 인터넷 서비스 제공수단에서의 요청에 따라 상기 OSP 처리 서버의 클라이언트로서 동작하여 상기 제1 인터넷 서비스 제공수단을 통해 개방형 정산 프로토콜(OSP)을 이용하는 서비스를 제공할 수 있도록 하기 위한 정합수단; 및
    개방형 정산 프로토콜(OSP)에 대한 처리 기능을 탑재하여 개방형 정산 프로토콜(OSP)을 통한 서비스를 이용하고자 하는 소속된 단말기들에게 상기 OSP 처리 서버와 연계하여 서비스를 제공하기 위한 제2 인터넷 서비스 제공수단
    을 포함하는 개방형 정산 프로토콜 정합 시스템.
  2. 제 1 항에 있어서,
    상기 정합수단은,
    OSP 처리 기능을 탑재하여 주어진 요청에 따라 상기 OSP 처리 서버에 대해 OSP 클라이언트로 동작하는 OSP 클라이언트 처리수단;
    OSP 처리 기능이 없는 상기 제1 인터넷 서비스 제공수단을 상기 OSP 처리 서버와 연계시켜 OSP 서비스를 제공하기 위해 상기 제1 인터넷 서비스 제공수단으로부터 주어진 요청에 대해 트랜잭션 관리 및 이벤트 전이의 처리를 수행하기 위한 레코드 라우팅 처리수단; 및
    상기 OSP 클라이언트 처리수단과 상기 레코드 라우팅 처리수단에서 발생하는 이벤트에 대한 진행 결정을 수행하여 상기 레코드 라우팅 처리수단과 상기 OSP 클라이언트 처리수단이 상기 제1 인터넷 서비스 제공수단과 상기 OSP 처리 서버에 대한 정합을 처리하도록 제어하는 정합처리수단
    을 포함하는 개방형 정산 프로토콜 정합 시스템.
  3. 개방형 정산 프로토콜(OSP)에 대한 처리 기능이 없는 인터넷 서비스 제공자(ISP : Internet Service Provider)와 개방형 정산 프로토콜(OSP) 처리 서버를 활용하는 통신 시스템에 있어서,
    OSP 서비스를 이용하고자 하는 상기 인터넷 서비스 제공자(ISP)로부터 주어진 요청을 받아 트랜잭션 관리 및 이벤트 전이의 처리를 수행하고 상기 인터넷 서비스 제공자(ISP)에게 전달할 정보를 받아 메시지로 구성하여 전달하기 위한 레코드 라우팅 처리수단;
    탑재된 OSP 처리 기능을 바탕으로 상기 인터넷 서비스 제공자(ISP)와 관련하여 주어진 요청에 따라 상기 OSP 처리 서버에 대해 OSP 클라이언트로 동작하여 OSP 서비스를 이용할 수 있도록 하는 OSP 클라이언트 처리수단; 및
    상기 레코드 라우팅 처리수단과 상기 OSP 클라이언트 처리수단을 통해 상기 제1 인터넷 서비스 제공수단과 상기 OSP 처리 서버에 대한 정합을 처리하도록 하기 위해 상기 OSP 클라이언트 처리수단과 상기 레코드 라우팅 처리수단에서 발생하는 이벤트에 대한 진행 결정을 수행하는 정합처리수단
    을 포함하는 개방형 정산 프로토콜 정합 시스템.
  4. 제 3 항에 있어서,
    상기 레코드 라우팅 처리수단은,
    상기 인터넷 서비스 제공자(ISP)로부터 네트워크를 통해 소정의 통신 프로토콜을 통해 전달된 라우팅 요청 메시지에 대해 해석하여 상기 정합처리수단으로 해석된 내용을 전달하고, 상기 OSP 처리 서버 또는 상기 정합처리수단으로부터 받은 응답 결과를 메시지로 구성하여 상기 인터넷 서비스 제공자(ISP)로 제공하는 것을 특징으로 하는 개방형 정산 프로토콜 정합 시스템.
  5. 개방형 정산 프로토콜(OSP) 정합 시스템에 적용되는 개방형 정산프로토콜(OSP) 정합 방법에 있어서,
    개방형 정산 프로토콜(OSP)에 대한 클라이언트 기능을 보유하지 않은 인터넷 서비스 제공자(ISP)로부터 네트워크를 통해 근원지(source), 목적지(Destination) 및 연결 요청된 호(call)에 대한 정보를 포함하는 라우팅 요청(request) 메시지를 전달받아 확인하는 제 1 단계;
    전달받은 상기 라우팅 요청(request) 메시지에 대해 주어진 정보를 바탕으로 점검을 수행하고 인증 요청(AuthorizationRequest) 메시지를 생성하여 OSP 처리 서버로 발송하는 제 2 단계;
    상기 인증 요청(AuthorizationRequest) 메시지를 전달받아 포함된 정보를 정보를 바탕으로 가입자 인증을 수행하고 라우팅 정보를 연산한 상기 OSP 처리 서버로부터 인증 결과 및 라우팅 정보를 인증 응답(Authorizationresponse) 메시지로 전달받는 제 3 단계;
    상기 인증 응답(Authorizationresponse) 메시지에 담긴 정보를 파악하여 상기 라우팅 요청(request) 메시지에 대한 응답(RoutingResponse) 메시지로 구성하여 상기 인터넷 서비스 제공자(ISP)로 전달하는 제 4 단계
    를 포함하는 개방형 정산 프로토콜(OSP) 정합 방법.
  6. 제 5 항에 있어서,
    상기 인터넷 서비스 제공자(ISP)가 전달받은 상기 라우팅응답(RoutingResponse) 메시지를 통해 획득한 라우팅 정보를 바탕으로 셋업 메시지를 구성하여 목적 단말기가 소속된 목적지 인터넷 서비스 제공자(ISP)로 전달하는 제 5 단계;
    상기 셋업 메시지를 전달받은 상기 목적지 인터넷 서비스 제공자(ISP)가 상기 OSP 처리 서버에 인증 요청(AuthorizationRequest) 메시지를 전달하여 인증을 의뢰하고 그에 따른 인증 응답(Authorizationresponse) 메시지를 받아 인증을 확인하는 제 6 단계;
    상기 목적지 인터넷 서비스 제공자(ISP)가 확인된 인증 정보를 바탕으로 소속된 수신 단말기로 호출 신호(Ring Signal)를 전송하고, 상기 인터넷 서비스 제공자(ISP)에게는 연결(Connect) 메시지를 전달하는 제 7 단계;
    상기 인터넷 서비스 제공자(ISP)는 상기 목적지 인터넷 서비스 제공자(ISP)로부터 연결(Connect) 메시지를 전달받아 확인하고 이에 대해 소속된 발신 단말기로 통보하는 제 8 단계;
    상기 발신 단말기와 상기 수신 단말기 사이에 이루어진 호 연결의 종료를 확인한 상기 목적지 인터넷 서비스 제공자(ISP)가 사용안내(UsageIndication) 메시지를 구성하여 상기 OSP 처리 서버로 전달하는 제 9 단계;
    상기 통화에 대한 사용상세(UsageDetail) 정보를 데이터베이스에 기록한 상기 OSP 처리 서버로부터 확인(UsageConfirm) 메시지를 받은 상기 목적지 인터넷 서비스 제공자(ISP)가 호 연결 완료(Release Complete) 메시지를 생성하여 상기 인터넷 서비스 제공자(ISP)에게 전달하는 제 10 단계; 및
    상기 목적지 인터넷 서비스 제공자(ISP)로부터 호 연결 완료(Release Complete) 메시지를 전달받은 상기 인터넷 서비스 제공자(ISP)가 상기 발신 단말기에 대한 호 연결 해제를 완료하는 제 11 단계
    를 더 포함하는 개방형 정산 프로토콜(OSP) 정합 방법.
  7. 개방형 정산 프로토콜(OSP) 정합 시스템에 적용되는 개방형 정산 프로토콜(OSP) 정합 방법에 있어서,
    정합을 처리하기 위한 커넥트 프록시(Connect proxy)가 인터넷 서비스 제공자(ISP)로부터 라우팅 요청(Request) 메시지를 전달받아 요청 큐(Request Queue)의 비어있는지의 여부와 요청 트랜잭션(Request Transaction)의 처리(Processing)가 보류(pending) 중인지의 여부를 체크하여 유휴상태(Idle State) 또는 보류 처리 상태(No Pending TRANS State)로 상태 전이시키거나 요청 큐(Request Queue)에 적재하여 관리하는 제 1 단계;
    유휴상태(Idle State)의 메시지에 대해 상기 커넥트 프록시(Connect proxy)의 정합처리수단에서의 처리 진행에 관한 승인 여부를 점검하여 승인된 경우에는 상기 메시지에 대해 승인된 요청(Approved Request) 상태로 전이시켜 관리하고, 승인 거부된 경우에는 미승인된 요청(Disapproved Request) 상태로 전이시켜 관리하는 제 2 단계;
    상기 승인된 요청(Approved Request) 상태의 메시지 및 상기 미승인된요청(Disapproved Request) 상태의 메시지에 대해 요청 해제(RequestRelease)의 여부를 파악하여, 요청 해제(RequestRelease)된 경우에는 상기 보류 처리 상태(No Pending TRANS State)로 상태를 전이시켜 관리하고, 요청 해제(RequestRelease)되지 않은 경우에는 메시지 전송 상태(Sending Message State)로 전이시키는 제 3 단계;
    상기 보류 처리 상태(No Pending TRANS State)의 메시지에 대해 같은 요청의 새 메시지가 있는지의 여부, 요청 해제(RequestRelease)를 이유로 상태가 전이되었는지의 여부, 처리중인 요청프로세스에 대한 시간 경과(time out)가 발생한 상황에서 이의 처리 절차에 대한 상기 정합처리수단에서의 응답 내용에 따라 상기 메시지의 상태를 전이시키고 이에 따른 처리를 수행하는 제 4 단계;
    상기 메시지 전송 상태(Sending Message State)의 메시지에 대해 이전의 상태를 감안하여, OSP 처리 서버로 인증요청(AuthorizationRequest) 메시지를 발송하여 서비스 요청한 후 상기 메시지에 대해 응답 대기하거나, 상기 인터넷 서비스 제공자(ISP)로 요청거부(RequestReject)의 메시지를 구성하여 전송하는 제 5 단계; 및
    상기 OSP 처리 서버로부터 상기 인증요청(AuthorizationRequest) 메시지에 대한 응답을 받아 상기 OSP 처리 서버로부터의 응답 결과를 확인하고 이에 따라 라우팅응답(Routing Response) 메시지를 구성하여 상기 인터넷 서비스 제공자(ISP)로 발송하고 는 제 6 단계
    를 포함하는 개방형 정산 프로토콜(OSP) 정합 방법.
  8. 제 7 항에 있어서,
    상기 제 1 단계는,
    상기 커넥트 프록시(Connect proxy)가 상기 인터넷 서비스 제공자(ISP)로부터 라우팅 요청(Request) 메시지를 전달받아 상기 요청 큐(Request Queue)가 비어있는지의 여부를 체크하는 제 7 단계;
    상기 제 7 단계의 체크 결과, 상기 요청 큐(Request Queue)가 비어있으면 유휴상태(Idle State)로 상기 메시지에 대한 상태를 처리하는 제 8 단계;
    상기 제 7 단계의 체크 결과, 상기 요청 큐(Request Queue)가 비어있지 않으면, 같은 요청이 처리 보류 중인지를 확인하는 제 9 단계;
    상기 제 9 단계의 확인 결과, 같은 요청이 처리 보류 중이면 보류 처리 상태(No Pending TRANS State)로 상태 처리하는 제 10 단계; 및
    상기 제 10 단계의 확인 결과, 같은 요청이 보류 중이지 않으면 상기 요청 큐(Request Queue)에 적재하고 적재 순서에 따라 상기 유휴상태(Idle State)로 상태를 전이시키는 제 11 단계
    를 포함하는 개방형 정산 프로토콜(OSP) 정합 방법.
  9. 제 7 항 또는 제 8 항에 있어서,
    상기 제 3 단계는,
    상기 보류 처리 상태(No Pending TRANS State)의 메시지가 어떠한 상황에 있는지를 검사하는 제 12 단계;
    상기 제 12 단계의 검사 결과, 상기 메시지와 새롭게 도착된 요청 메시지가 같은 요청의 메시지라면, 상기 새로운 요청 메시지를 상기 보류 처리 상태(No Pending TRANS State)를 거쳐 상기 요청 큐(Request Queue)에 적재하거나 상기 유휴상태(Idle State)로 상태를 전이시키고, 보류중인 상기 메시지에 대해서는 상기 정합처리수단으로의 처리승인을 확인하는 제 13 단계;
    상기 제 13 단계의 확인 결과, 상기 메시지에 대한 처리승인이 났으면 승인된 요청(Approved Request) 상태로 전이시켜 관리하는 제 14 단계;
    상기 제 13 단계의 확인 결과, 상기 메시지에 대한 처리승인이 나지 않고 승인 거부된 경우에는 미승인된 요청(Disapproved Request) 상태로 전이시켜 관리하는 제 15 단계;
    상기 제 12 단계의 검사 결과, 승인된 요청(Approved Request) 상태에서 요청 해제(RequestRelease)로 응답받았으면, 상기 인터넷 서비스 제공자(ISP)에 대해 상기 요청거부(RequestReject) 메시지를 발송해야 하는지를 점검하여 발송해야 하면 상기 메시지 전송 상태(Sending Message State)로 상태를 전이시키고 그렇지 않으면 보류중이었던 상기 메시지에 대한 상태를 상기 유휴상태(Idle State)로 전이시키는 제 16 단계;
    상기 제 12 단계의 검사 결과, 미승인된 요청(Disapproved Request) 상태에서 요청 해제(RequestRelease)로 응답받았으면, 상기 메시지에 대한 상태를 상기유휴상태(Idle State)로 전이시키는 제 17 단계; 및
    상기 제 12 단계의 검사 결과, 처리중인 요청 프로세스에 대해 시간 초과(Time out)가 발생하였으면, 상기 정합처리수단으로 상기 시간 초과(Time out)로 인한 요청 불처리 결과에 대한 응답 여부를 판단하도록 문의하고 그 답변에 따라 상기 요청거부(RequestReject) 메시지의 전송 또는 상기 유휴상태(Idle State)로의 전이를 수행하는 제 18 단계
    를 포함하는 개방형 정산 프로토콜(OSP) 정합 방법.
  10. 프로세서를 구비한 개방형 정산 프로토콜(OSP) 정합 시스템에,
    개방형 정산 프로토콜(OSP)에 대한 클라이언트 기능을 보유하지 않은 인터넷 서비스 제공자(ISP)로부터 네트워크를 통해 근원지(source), 목적지(Destination) 및 연결 요청된 호(call)에 대한 정보를 포함하는 라우팅 요청(request) 메시지를 전달받아 확인하는 제 1 기능;
    전달받은 상기 라우팅 요청(request) 메시지에 대해 주어진 정보를 바탕으로 점검하고 인증 요청(AuthorizationRequest) 메시지를 생성하여 OSP 처리 서버로 발송하는 제 2 기능;
    상기 인증 요청(AuthorizationRequest) 메시지를 전달받아 포함된 정보를 정보를 바탕으로 가입자 인증을 수행하고 라우팅 정보를 연산한 상기 OSP 처리 서버로부터 인증 결과 및 라우팅 정보를 인증 응답(Authorizationresponse) 메시지로전달받는 제 3 기능;
    상기 인증 응답(Authorizationresponse) 메시지에 담긴 정보를 파악하여 상기 라우팅 요청(request) 메시지에 대한 응답(RoutingResponse) 메시지로 구성하여 상기 인터넷 서비스 제공자(ISP)로 전달하는 제 4 기능
    을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
  11. 프로세서를 구비한 개방형 정산 프로토콜(OSP) 정합 시스템에,
    인터넷 서비스 제공자(ISP)로부터 라우팅 요청(Request) 메시지를 전달받아 요청 큐(Request Queue)의 비어있는지의 여부와 요청 트랜잭션(Request Transaction)의 처리(Processing)가 보류(pending) 중인지의 여부를 체크하여 유휴상태(Idle State) 또는 보류 처리 상태(No Pending TRANS State)로 상태 전이시키거나 요청 큐(Request Queue)에 적재하여 관리하는 제 1 기능;
    유휴상태(Idle State)의 메시지에 대해 처리 진행에 대한 승인 여부를 점검하여 승인된 경우에는 상기 메시지에 대해 승인된 요청(Approved Request) 상태로 전이시켜 관리하고, 승인 거부된 경우에는 미승인된 요청(Disapproved Request) 상태로 전이시켜 관리하는 제 2 기능;
    상기 승인된 요청(Approved Request) 상태의 메시지 및 상기 미승인된 요청(Disapproved Request) 상태의 메시지에 대해 요청 해제(RequestRelease)의 여부를 파악하여, 요청 해제(RequestRelease)된 경우에는 상기 보류 처리 상태(NoPending TRANS State)로 상태를 전이시켜 관리하고, 요청 해제(RequestRelease)되지 않은 경우에는 메시지 전송 상태(Sending Message State)로 전이시키는 제 3 단계;
    상기 보류 처리 상태(No Pending TRANS State)의 메시지에 대해 같은 요청의 새 메시지가 있는지의 여부, 요청 해제(RequestRelease)를 이유로 상태가 전이되었는지의 여부, 처리중인 요청프로세스에 대한 시간 경과(time out)가 발생한 상황에서 이의 처리 절차에 대한 판단 내용에 따라 상기 메시지의 상태를 전이시키고 이에 따른 처리를 수행하는 제 4 기능;
    상기 메시지 전송 상태(Sending Message State)의 메시지에 대해 이전의 상태를 감안하여, OSP 처리 서버로 인증요청(AuthorizationRequest) 메시지를 발송하여 서비스 요청한 후 상기 메시지에 대해 응답 대기하거나, 상기 인터넷 서비스 제공자(ISP)로 요청거부(RequestReject)의 메시지를 구성하여 전송하는 제 5 기능; 및
    상기 OSP 처리 서버로부터 상기 인증요청(AuthorizationRequest) 메시지에 대한 응답을 받아 상기 OSP 처리 서버로부터의 응답 결과를 확인하고 이에 따라 라우팅응답(Routing Response) 메시지를 구성하여 상기 인터넷 서비스 제공자(ISP)로 발송하는 제 6 기능
    을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
KR1020030039165A 2003-06-17 2003-06-17 개방형 정산 프로토콜 정합 시스템 및 그 방법 KR20040108248A (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020030039165A KR20040108248A (ko) 2003-06-17 2003-06-17 개방형 정산 프로토콜 정합 시스템 및 그 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020030039165A KR20040108248A (ko) 2003-06-17 2003-06-17 개방형 정산 프로토콜 정합 시스템 및 그 방법

Publications (1)

Publication Number Publication Date
KR20040108248A true KR20040108248A (ko) 2004-12-23

Family

ID=37382212

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020030039165A KR20040108248A (ko) 2003-06-17 2003-06-17 개방형 정산 프로토콜 정합 시스템 및 그 방법

Country Status (1)

Country Link
KR (1) KR20040108248A (ko)

Similar Documents

Publication Publication Date Title
US8634412B2 (en) Session initiation protocol (SIP) message incorporating a multi-purpose internet mail extension (MIME) media type for describing the content and format of information included in the SIP message
US7773585B2 (en) Internet protocol telephony voice/video message deposit and retrieval
KR101224254B1 (ko) 통신 네트워크 통합 방법 및 통신 시스템
US7099301B1 (en) Voice over internet protocol proxy gateway
US7664102B1 (en) System and method for providing a plurality of multi-media services using a number of media servers to form a preliminary interactive communication relationship with a calling communication device
US8139746B2 (en) Caller treatment in a SIP network
US8040873B2 (en) Distributed integration of legacy PBX system with SIP networks
MXPA03008506A (es) Bloqueo selectivo de caracteristicas en una red de comunicaciones.
US7738445B2 (en) Combined H.450.2 and SIP call transfer
EP2299647B1 (en) Next generation integration between different domains, such as, enterprise and service provider using sequencing applications and IMS peering
KR100382862B1 (ko) 에스아이피 프로토콜을 기반으로 한 분산형 호처리방식의인터넷 전화시스템 및 그 동작방법
KR100415117B1 (ko) 인터넷프로토콜 전화시스템에서 인터넷프로토콜단말기들간의 다중통화 시 강제 착신장치 및 방법
JP4677350B2 (ja) 呼制御信号転送装置、呼制御信号転送方法および呼制御信号転送プログラム
Lu et al. Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations
KR20040108248A (ko) 개방형 정산 프로토콜 정합 시스템 및 그 방법
JP7414215B1 (ja) 電話番号の調査装置、調査方法、調査プログラム、及び情報提供システム
JP7498920B1 (ja) 電話番号の調査装置、調査方法、調査プログラム、及び情報提供システム
Sterman Real-time billing in sip
Al-Saadoon Asterisk open source to implement voice over internet protocol
Lu et al. RFC2458: Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations
Conroy et al. Netowrk Working Group H. Lu Request for Comments: 2458 Editor Category: Informational M. Krishnaswamy Lucent Technologies
Krishnaswamy et al. Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations
Aye et al. Implementation and Analysis of VoIP application
WO2006131448A1 (fr) Procede de communication entre un point de commande de services d'un reseau intelligent et un serveur externe, point de commande, serveur externe, systeme et programmes d'ordinateur associes

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid