KR101403810B1

KR101403810B1 - Ｕｒｉ 결정 방법, 메시지 라우팅 디바이스 및 전용 네임 서버

Info

Publication number: KR101403810B1
Application number: KR1020097009010A
Authority: KR
Inventors: 에비즈크 아드리아누스 요하네스 반; 브리엔트 요한 안드레 드
Original assignee: 알까뗄 루슨트
Priority date: 2006-10-31
Filing date: 2007-10-30
Publication date: 2014-06-03
Also published as: EP1919155A1; KR20090086392A; WO2008052760A1; CN101175097B; JP2010508682A; JP5249233B2; US20080101358A1; CN101175097A

Abstract

IMS(IP Multimedia Subsystem) 네트워크 내 혹은 그들 네트워크간에 메시지를 라우팅하는데 사용하는 URI(Uniform Resource Identifier)를 결정하기 위해, 쿼리(101, 201)가 디바이스(120, 220)로부터 전용 네임 서버(121, 221)로 상기 URI를 결정하기 위해 전송된다. 전용 네임 서버(121, 221)는 상기 URI의 결정을 시도한다. 본 방법이 실패인 경우에, URI를 결정하기 위한 새로운 쿼리를 공용 네임 서버(122, 222)에 더 전송하여, 공용 DNS 서버(122, 222)가 새로운 쿼리(104, 203) 내의 URI를 결정한다.

Description

ＵＲＩ 결정 방법, 메시지 라우팅 디바이스 및 전용 네임 서버{RESOLUTION OF FLEXIBLE ADDRESS SCHEMES FOR IMS SERVICES}

본 발명은 통상 IP 멀티미디어 서브시스템(IMS) 네트워크에 있어서의 어드레스 결정(address resolution)에 관한 것이다. 어드레스 결정은 이들 노드간의 메시지를 라우팅하기 위해 IMS 네트워크 내의 다양한 노드에서 수행된다. 어드레스 변환(address translation)은, 메시지가 서로 다른 네트워크간에 라우팅될 때와, 로밍 사용자인 경우에 주로 사용된다.

네트워크 내의 사용자와 노드의 식별은, 일반적으로 숫자 표현을 이용하는 것보다는 도메인 네임과 같은 시스템의 문자-숫자(alphanumeric) 표현을 이용하여 행해진다. 그러나 시스템 자체는, 예컨대, IP(Internet Protocol) 어드레스와 같은 숫자 표현을 이용한다. 문자-숫자 표현의 숫자 표현으로의 변환은 네트워크 내에서 이행되어야 한다. IMS(IP Multimedia Subsystem) 네트워크는 이들 네트워크를 통해서, 그리고 다양한 네트워크간에 메시지를 라우팅하기 위해 IP 어드레스를 사용한다. IMS 네트워크 내에서 전송된 모든 메시지는 메시지의 수신 노드를 결정 하는데 사용되는 문자-숫자 표현인 세션 개시 프로토콜{SIP(Session Initiation Protocol)} URI(Uniform Resource Identifier)를 포함한다. 이들 SIP URI는 수신 노드가 위치하는 네트워크를 식별하는 도메인 네임을 포함한다.

문자-숫자 표현으로부터 숫자 표현으로의 변환을 수행하기 위한 전형적인 시스템은 DNS(Domain Name System)이다. DNS는 도메인 네임이 트리 구조에 따라 체계화된 데이터베이스 시스템이다. 이 데이터베이스는 다양한 DNS 서버간에 배포된다. 회사들이 웹사이트나 이메일과 같은 애플리케이션을 위해 그들 자신의 도메인을 체계화하는 것은 일반적이다. 회사들은 이것에 변환을 수행할 수 있는 네임 서버를 제공한다. 도메인 네임 공간의 특정 부분을 책임지는 네임 서버는 권위적 네임 서버(authoritative name server)라 불린다. 모든 변화는 이 네임 서버에서 이루어지고, 다른 네임 서버는 최신 정보를 검색(retrieve)하기 위해 권위적 네임 서버를 조회(query)할 수 있다.

GSM Association(GSMA)이 2006년 8월 14일자로 발표한 Official Document IR.65 버전 3.5에는, 「IMS 로밍 및 연동 지침(IMS Roaming & Interworking quidelines)」을 다루고 있다. 이 문서에는 IMS에 의해 DNS를 사용할 수 있는 두 가지의 해법이 제시되어 있다.

제 1 가능 해법은, 가장 편리한 해법으로도 알려져 있는 것으로서, IMS 네트워크 내에서 노드에 변환을 제공하기 위해 인터넷에서도 사용되는 공용 DNS 서버를 사용하는 것이다. 순수 공용으로 작동되는 DNS 인프라로 스위칭하는데 있어서의 주요 이슈는 보안이다. 모든 정보는 대중이 이용할 수 있고, 다수의 오퍼레이터는 그들 네트워크와 그의 조작과 관련된 임의 정보를 공유하기를 주저한다. 제 2 가능 해법은, 특별한 체계로 관리되는 현존하는 전용 DNS 서버, 예컨대, GPRS(General Packet Radio Service) 로밍을 위해 관리되는 전용 DNS 서버를 이용할 수 있다. IMS 노드에 도메인 네임의 변환을 제공하기 위해 현존하는 전용 DNS 서버를 이용하는 경우 몇 가지의 가능한 실행법이 있다. 그러나, 이들 실행법의 각각은 결점을 가지고 있다.

제 1 가능 실행법은 SIP URI에서의 특정 도메인과, 예컨대, 전용 DNS 서버를 관리하는 기관에 의해 정의된 명명 구조를 사용하는 것이다. 예를 들면, GSMA에 의해 조작되는 GRX(GPRS Roaming eXchange)에 의해 사용되는 3gppnetwork.org 도메인을 들 수 있다. 이 경우에, 오직 GSMA만이 시스템에 새로운 오퍼레이터를 추가할 수 있고, 그로 인해 그들 자신의 IMS 네트워크를 작동하게 하여 다른 IMS 네트워크와 통신을 행한다. 또한 공용 네트워크를 거쳐 라우팅되어야 하는 메시지에 3gppnetwork.org 도메인을 사용할 수는 없다. 공용 DNS 서버는 이 도메인을 결정할 수 없다. 이것은 회사가, 예컨대, 그들의 기업 네트워크 내에서 SIP 가능 디바이스로부터 모바일 사용자에게 발호하는 것을 방지한다.

또 다른 가능 실행법은 GRX와 같은 네트워크에 사용되는 전용 DNS 인프라에 오퍼레이터의 글로벌 DNS 인프라의 서브셋(subset)을 추가하는 것이다. 모든 변화를 복제하는 것은 사람의 책임이기 때문에 이러한 실시는 양 DNS 인프라간의 심각한 충돌을 야기할 수 있다. 그러므로, 이 실행법은, 사람의 수고를 더욱 필요로 하고, 그렇게 때문에 실패하기 쉽다. 사람의 실수로 인해 네트워크에 도달되지 않고 통신이 두절될 수도 있다. 또한 전용 DNS 인프라 내에서 복제된 정보에 대한 책임을 누가 져야 하는가의 문제를 야기한다.

이러한 기능성을 가진 제 3 가능 실행법은 공용 및 전용 DNS 인프라를 혼합하는 것이다. 이 실행법은 몇 가지 장점을 얻을 수 있지만, 공용 DNS 인프라(public DNS infrastructure)의 사용에 관련된 새로운 문제를 야기한다. 그러나 이러한 실행법은 이하에 더욱 상세하게 설명될 것이다.

현재, GRX 내에서 사용되는 전용 DNS 서버와, 인터넷용으로 사용되는 것과 같은 공용 DNS 서버간에는 접속이 되어 있지 않다. 이것은 일반 대중, 특히, 악의적인 사람에 의한 전용 네임 서버로의 액세스를 방지함으로써 보안 레벨을 제공한다. IMS 네트워크의 체계를 발견할 수 없고, 결과적으로 IMS 또는 GPRS 네트워크의 중요한 노드(crucial node)에의 공격을 체계화하기 곤란하거나 불가능하다. 현재의 기능성을 확장하는 경우에도 모든 보안적 측면을 계속 유지할 것이 요망되고 있다.

현재 원격 통신 마켓에 있어서의 주요 플레이어는 고정 및 모바일 브로드밴드 액세스 xDSL 및 GPRS 네트워크를 가동하고 있고, 또한 IMS 서비스를 제공하는 것에 관심을 가질 것이다. 이들 플레이어의 대부분은 GRX나 그와 유사한 전용 관리 네트워크의 멤버로서 그들의 소비자에게 GPRS 로밍 및 상호 작용(interworking)을 제공한다. 그러므로 IMS 네트워크의 상호 접속과 IMS 서비스를 제공하기 위해 GRX에 의해 제공되는 서비스를 사용하는 것은 논리적인 단계이다.

공용 네트워크에서 3gppnetwork.org는 주소로 될 수 없고, 오퍼레이터는 이 도메인의 내용을 제어하지 않기 때문에, 오퍼레이터는, 예컨대, GRX에 의해 제공된 장점으로부터 얻어지는 이익 및 그들 자신의 도메인 명칭을 그대로 사용하는 것이 바람직하다. 이를 달성할 수 있는 방법은, 이들 솔루션을 피해야하는 이유와 함께, Official Document IR.65 문서의 섹션 9.4에 제안되어 있다. 이들 솔루션은 모두 현재 GRX 인프라의 몇 가지 변형(예컨대, 현재 사용되고 있는 3gppnetwork.org 도메인에 프리픽스(prefix)로서 오퍼레이터 도메인을 부가하여 URI 구조를 변형하는 것)을 요구하고, 또는 상기 요구에 상당한 사람의 노력을 필요로 한다(예컨대, 오퍼레이터에서 정적으로 구성된 리스트를 유지함으로써).

GPRS 로밍, GRX(GPRS Roaming eXchange)용으로 사용된 DNS 서버는, 2006년 8월 9일 GSMA(GSM Association)가 발표한, Official Document IR.67 버전 1.4에 기술되어 있다. 이 문서는 DNS 서버의 구조와 도메인 네임을 결정하는데 관련된 단계가 기술되어 있다. 일반적으로 GRX 내의 DNS 서버는 통상 공용으로 이용할 수 있는 DNS 서버와 같은 방법으로 작동한다. 그러나 여기서 알려진 도메인의 세트는 GSMA에 의해 정의된 특정 도메인으로 제한된다.

NGN(Next Generation Network)에 대한 일련의 요구는 ETSI TISPAN contribution 11bTD079 및 ECMA TR/91(ETSI TR 102 478)에서 특정된다. 이들 요구는 기업들이 그들 자신의 NGCN(Next Generation Corporate Network)을 세우기 위한 수단을 제공하고, SIP와 같은 서비스를 제공한다. 만약 NGN이 이들 요구 모두를 실행하면, NGN과 NGCN간 또는 NGN을 거친 몇몇 NGCN간의 상호 작용이 가능해진다. 그러나, 요구 12는, NGN이 NGCN으로 하여금 NGN과 사전 협의 없이 그것의 도메인 내에서 새로운 아이덴티티를 할당하도록 해야한다는 것을 조건으로서 지정한다. 오직 NGN만이 네트워크 중에서 알려졌기 때문에 지금까지 이것은 불가능하였다. 그러므로 모든 요구에 대해 전적으로 자격을 갖춘 NGN을 제공해야 한다는 문제가 생긴다.

본 발명의 목적은 인터넷에서 일반인에 의해 사용되는 DNS 인프라와는 완전히 분리되고, 기관에 의해 관리되는 DNS 인프라와의 결합으로 그들 자신의 도메인 네임을 이용하는 방법을 오퍼레이터에게 제공하는 것이다. 본 발명의 다른 목적은 약간의 변형을 갖는 이런 기능들은 현재 존재하는 시스템에 제공하고, 또한 오퍼레이터 도메인 네임 사용을 달성하기 위해 공용 DNS 인프라 내에서 정보를 사용하는 수단을 제공하는 것이다. 본 발명의 또 다른 목적은 설정하고 유지하는데 사람의 약간의 노력만을 필요로 하는 시스템을 제공하는 것이다. 본 발명의 또 다른 목적은 종래 기술에서 제안된 솔루션보다 에러가 적은 시스템을 마련하는 것이다. 본 발명의 또 다른 목적은 NGN(Next Generation Network)에 발생하는 문제에 대한 솔루션을 제공하고 그들로 하여금 그들 자신의 아이덴티티를 사용하도록 하는 것이다.

본 발명에 따르면, 본원 청구항 1에 기술되어 있는 바와 같이, IMS(IP Multimedia Subsystem) 네트워크 내 또는 IMS 네트워크간에 메시지를 라우팅하는데 사용하는 URI(Uniform Resource Identifier)를 결정하기 위한 방법으로서,

a) 상기 URI를 결정하기 위한 쿼리를, 상기 IMS 네트워크에 메시지를 전송할 수 있는 디바이스로부터 전용 네임 서버에 전송하는 단계와,

b) 상기 전용 네임 서버(private name server)에 의해 상기 URI를 결정하는 단계와,

c) 상기 전용 네임 서버에 의해 상기 URI의 결정이 실패한 경우, 공용 네임 서버에 상기 URI를 결정하기 위한 새로운 쿼리를 전송하는 단계와,

d) 상기 공용 네임 서버(public name server)에 의해 상기 URI를 결정하는 단계, 및

e) 상기 디바이스에 의해 상기 쿼리에 대한 응답을 수신하는 단계

를 포함하는 URI 결정 방법을 통해 상술한 목적을 실현하고, 종래 기술의 솔루션에 대한 결점이 극복된다.

본 발명의 상기 문맥에 있어서, URI를 결정하는 것은, 예컨대, URI의 일부인 도메인 네임을 IP 어드레스나 표준 DNS 과정을 사용하는 다른 도메인 네임으로 변환하기 위한 시도를 수반하는 어떤 단계나 단계의 조합을 의미한다. 표준 DNS 과정(standard DNS procedures)은 DNS 서버의 캐시를 조사하고, 다른 네임 서버와 통신하며, 기지의 도메인 네임으로부터의 정보를 검색(retrieving)하는 것으로 구성된다. 캐싱은 네트워크 내의 네임 서버나 노드에 의해 제공될 수 있고, 그들의 구성에 의존한다. 다른 네임 서버와의 통신은 권위를 가진 네임 서버(authoritative name server)를 결정하거나 권위를 가진 네임 서버로부터의 정보를 검색하기 위해 리퍼럴(referral)할 수 있다. 만약 결정(resolving)이 네임 서버에 의해 수행되면, 이것은 권위가 있는 도메인 네임에 대한 정보를 제공하거나 다른 네임 서버로부터의 정보를 검색할 수 있다.

쿼리는 정보에 대한 요구를 포함하는 DNS 표준에 의해 정의된 메시지이다. 요구된 정보는 도메인 네임과 관련된 IP 어드레스, 임의의 프로토콜을 조정하는 서비스의 위치, 다른 도메인 네임에 대한 리퍼럴일 수 있다. 쿼리는 요구된 정보를 포함하는 응답을 행한다. 결국 쿼리가 전송된 시스템은 이 응답을 수신할 것이고, 거기서 메시지를 라우팅하거나 특정 호스트에 대한 접속을 설정하는 것과 같은 태스크에 관한 정보를 사용할 수 있을 것이다.

모든 도메인이 DNS 서버에 알려져 있는 것은 아니다. 예컨대, 도메인 네임의 타이핑 에러는 존재하지 않는 도메인에 대한 요구를 행할 수도 있다. 네임 서버가 모든 가능한 검색(예컨대, 캐시나 다른 네임 서버)을 수행하고도 쿼리에 대한 응답을 제공할 수 없을 경우, 에러 응답이 전송된다. 이와 같은 에러가 수신되었을 경우에, 네임 서버에 의해 URI를 결정하는 것은 실패로서 고려된다.

공용 및 전용 DNS 서버는 공용이나 비공용으로 이용할 수 있는 것이 고려될 수 있다. 공용 DNS 서버는, 예컨대, 인터넷 상의 여러 서비스를 액세스하도록 일반 대중에 의해 사용되는 DNS 서버이다. 전용 DNS 서버는 회사와 같은 특정 조직에 의해 관리되고, 그 사용은 조직과 계약이 성립된 조직이나 사람으로 그 멤버가 제한된다. 일례로는, GSMA에 의해 작동되는 GRX가 있고, 다른 서비스들 중에서 DNS 서비스를 제공하는데, 이들 서비스는 GSMA의 멤버와 GSMA를 포함하는 오퍼레이터에 의해서만 컨설팅될 수 있다.

본 발명에 따르면, SIP URI를 결정하는 것이 실패일 경우, 이러한 전용 DNS 서버는 다시 공용 DNS 서버를 컨설팅한다. 그러므로, SIP URI를 결정할 수 없는 것을 가리키는 대신, 전용 DNS 서버는 SIP URI를 결정하는 요구를 공용 DNS 서버에 발송한다. 대체 방안으로서 본 발명에 의하면 전용 DNS 서버가 SIP URI를 결정할 수 없다고 표시한 IMS 네트워크의 노드는 공용 DNS 서버와 접속한다.

이들 특별한 단계의 이점은 명백하다. 오퍼레이터는 전용 네임 서버에 의해 알려지거나, 또는 GSMA와 같은 기관에 의해 정의된 도메인 네임에 관계되지 않는다. 전용 오퍼레이팅하여 이용할 수 있는 DNS 서버(private operated and available DNS server)와 공용으로 이용할 수 있는 DNS 서버간의 엄격한 분리가 유지되므로, 분리된 시스템에 의해 제공되는 보안도 계속 유지된다. 양 도메인간의 변환을 제공하는 것은 전용 DNS 서버 내에 존재하는 오퍼레이터와의 계약을 필요로 하는, 그 자체 도메인을 사용하는 오퍼레이터의 책임이다. 그러므로, 이 시스템에 의해 소개된 부가적인 작업은, 몇 가지 부가적인 기록이 오퍼레이터의 공용 DNS 서버에 필요하게 될 뿐, 매우 제한된다.

청구항 6에 따른 디바이스는 본 발명의 모든 목적을 제공하는데 필요한 단계를 수행하도록 적응된다. 이 디바이스는, 통상 IMS 네트워크 내의 노드로서, 청구항 1에 기술된 단계를 수행할 수 있다. 이것은 전용 네임 서버에 쿼리를 전송하고, 응답을 수신할 수 있다. 이러한 응답이 전용 네임 서버가 URI를 결정할 수 없음을 나타내면, 디바이스는 공용 네임 서버에 새로운 쿼리를 전송할 수 있다. 이것은 디바이스로 하여금 전용 네임 서버와 공용 네임 서버의 양쪽을 체킹하도록 할 수 있고, 전용 네임 서버에서 이용할 수 없는 도메인 네임을 포함하는 URI에 대한 응답을 찾을 수 있도록 한다.

청구항 7에 따른 다른 디바이스는 종래 기술에서 발견된 문제를 해결하기 위해 필요한 기능성을 제공한다. 이 디바이스는, 통상 전용 네임 서버로서, 쿼리를 수신하고, 그 쿼리를 결정할 수 있다. 디바이스가 이 쿼리를 결정할 수 없으면, 그 쿼리를 결정하기 위해 또 다른 공용 네임 서버를 쿼리할 수 있다. 이것은, 디바이스가 노드와 공용 네임 서버 사이의 중간 시스템으로서 동작하도록 할 수 있다. 이것은 디바이스에 오리지널 쿼리를 발행했던 노드에 대해 투명한 방법으로 공용 네임 서버를 이용하는 URI의 변환을 가능하게 한다.

부가적으로 메시지를 라우팅할 필요가 있는 노드는, 청구항 2에 기재된 바와 같이, 청구항 1의 단계 c)를 수행할 수 있다.

이 노드는 두 IMS 네트워크 사이에서 메시지를 라우팅할 책임이 있고, 그로 인해 자신의 네트워크 외부에 위치하는 시스템과 통신할 수 있게 된다. 본 발명을 수행하는 이와 같은 실행 방법은 노드에의 침입을 피하기 위해 그 노드에서의 부가적인 보안 대책을 필요로 한다. 이들 노드에 존재하는 보안 때문에, 이들 노드는 공용 DNS 서버와 통신하기 위한 이상적인 후보로 되고, 공용 및 전용 DNS 서버간의 분리를 계속 유지한다.

선택적으로 전용 네임 서버는, 청구항 3에 기재한 바와 같이, 청구항 1의 단계 c)에 기재된 새로운 쿼리를 전송할 수 있다.

공용 DNS 서버와 접속하기 위해 전용 네임 서버를 이용하는 경우, 투명성(transparency)은 메시지를 라우팅하는 노드에 생성된다. 이들 시스템은 변형이 필요없고 단지 그들이 원하는 정보를 얻을 수 있는 단일 쿼리를 수행하기만 한다. 네임 서버는 대량의 요구를 제어하도록 디자인되고, 다른 네임 서버와 접속함으로써 쿼리에 대한 응답을 찾도록 적응될 수 있다. 그러므로, 본 발명의 이와 같은 실행을 지원하기 위해 전용 DNS 서버에 제한된 적응이 요구된다. 한편, 도메인 네임을 제외한 IMS 네트워크에 대한 어떤 정보도 공용 네트워크 상으로 전송되지 않는다. 그러므로 노드의 위치는 통상 대중에 드러나지 않고, 보안이 유지된다.

본 발명의 부가적인 실시예에서, 청구항 4에 기재된 바와 같이, NAPTR 기록은 공개된 도메인 네임을 전용 인프라에 알려진 도메인 네임으로 변환하는데 사용될 수 있다.

NAPTR 기록은 RFC 2915에 기재되어 있다. 이 기록은 일반적으로 현재 존재하는 문자열을 새로운 도메인 네임이나 URI로 재기록하는데 사용된다. 전형적인 NAPTR 기록의 실행은, RFC 2916에 기술된 바와 같이, 전화 번호를 e.164 넘버 변환을 이용하는 URI에 매핑하는 것이다.

본 발명에 따르면, 이러한 NAPTR 기록은 도메인에 대한 권한을 가진 네임 서버의 구성(authoritative name server)에 부가될 수 있다. 이들 기록은 전용 DNS 서버에 의해 알려진 오퍼레이터의 도메인 네임을 제공할 것이다.

NAPTR 기록은 정규 표현을 이용하는 것을 통한 유연성(flexibility)을 제공하고, 그 결과 몇몇 기록은 수 개의 도메인을 전용 네임 서버에 의해 알려진 단일 도메인으로 변경할 수 있다.

본 발명의 다른 부가적인 실시예에 있어서, 청구항 5에 기재된 바와 같이, SRV 기록은 공개된 도메인 네임을 전용 인프라에 알려진 도메인 네임으로 변환하는데 사용될 수 있다.

SRV 기록은 RFC 2782에 기술되어 있다. 이와 같은 형태의 기록은 부하 밸런싱(load balancing)을 제공하는데 사용되고, 솔루션을 백업한다. 일반적으로 몇몇 기록은 단일 서비스를 표시하는데 사용되는데 이러한 단일 서비스에서 각 기록은 우선도와 가중치를 갖는다. 우선도는 백업 서비스를 정의하는데 사용되고, 기록의 가중치는 각 시스템에 얼마나 많은 트래픽이 가해지는지를 명확히 하기 위해 사용될 수 있다.

도 1은 공용 DNS 서버에 사용자 에이전트(User Agent)가 접촉할 수 있는 본 발명의 제 1 실시예를 나타내는 도면이다.

도 2는 전용 DNS 서버와 공용 DNS 서버에 접촉하는데 이용되는 본 발명의 제 2 실시예를 나타내는 도면이다.

도 1은 본 발명의 제 1 실시예의 메시지 흐름을 나타낸다. 본 실시예는 사용자 에이전트(UA)(120), 전용 DNS 서버(121), 공용 DNS 서버(122) 및 외국의 IMS 네트워크 내의 노드(123)를 포함한다.

본 발명의 제 1 실시예에서는, 사용자 에이전트(120)는 IMS 네트워크를 통해 비디오폰 기능을 제공하는 소프트웨어를 가진 고정 디바이스나 PoC(Push to Talk Over Cellular networks) 애플리케이션을 가진 휴대 디바이스일 수 있다. PoC는 휴대 디바이스상의 키를 누름으로써 그 디바이스의 사용자가 서로 대화할 수 있도록 하는 IMS 서비스이다. 이것은 IMS 네트워크에 접속된 GPRS와 같이 영구의 온라인 접속을 사용하고, 대화 내용을 데이터 패킷으로 변환하여 IMS 네트워크로 전송된다. IMS 네트워크는 데이터 패킷의 목적지로 그 패킷을 라우팅하고, 수신 사용자는 대화 내용을 들을 수 있다. PoC 애플리케이션은, SIP 요구에 대한 소스의 예로서 기능하고, PoC 애플리케이션은 여러 가지 작업을 수행하기 위해 다른 여러 가지의 소프트웨어 애플리케이션을 사용한다. 예를 들면, PoC 애플리케이션은 디바이스 내에서 수행된 DNS 해결 프로그램(DNS resolver)을 사용할 수 있는데, 여기에서 PoC 애플리케이션은 요구를 전송하도록 요구받은 DNS 서버로부터의 정보를 정정하도록 구동된다. 또한 PoC 애플리케이션은 다른 노드와 DNS 서버로 데이터를 전송하도록 TCP/IP 프로토콜 스택을 실행한다.

전용 DNS 서버(121)와 공용 DNS 서버(122)는 DNS 서비스를 제공하는 디폴트(default) 소프트웨어 애플리케이션이다. 전용 DNS 서버(121)와 공용 DNS 서버(122)를 구성할 수 있는 가능한 소프트웨어 애플리케이션은, http://www.isc.org/index.pl?/sw/bind/로부터 알려진 BIND와, http://www.powerdns.com/으로부터 알려진 PowerDNS가 있지만, SRV 및/또는 NAPTR 기록을 이용하여 제공되는 다른 어떤 애플리케이션도 사용될 수 있다. 본 제 1 실시예에서는 BIND가 DNS 서비스를 제공하는데 사용된다고 가정한다. 전용과 공용간의 구별은 서버의 위치에 근거하여 이루어진다. 공용 DNS 서버(122)는, 예컨대, 이메일을 보내거나 웹사이트를 브라우징할 때, 일반 대중에 의해 접속될 수 있다. 전용 DNS 서버(121)는 작은 세트의 사용자로 제한된다. 예컨대, 전용 DNS 서버(121)는 GPRS Roaming eXchange(GRX) 네트워크용으로 사용된 DNS 서버이다. 로밍은 계약을 맺은 이동 전화 통신 오퍼레이터에 속하지 않는 네트워크에 사용자가 접속하는 행위이다. 예를 들면, 어떤 사람이 벨기에에서 전화 통신 서비스를 행하는 오퍼레이터 A에게 지불을 행하고 있을 때, 이 사람은, 오퍼레이터 A와 오퍼레이터 B가 로밍 계약 상태에 있으면, 그 사람은 프랑스에서 오퍼레이터 B의 네트워크를 사용할 수 있다. 그러므로, 로밍은 오퍼레이터와의 계약을 사용할 수 있고, 몇몇 다른 나라에서의 서비스를 수신할 수 있다. 로밍의 능력은 사용자가 그들의 IMS 가능 디바이스 및 애플리케이션을 이용하는 동안 자유롭게 이동할 수 있게 한다.

도 1에 도시된 외국의 IMS 네트워크에서의 노드는 I-CSCF(Interrogating Call Session Control Function)(123)이다. 패킷은 IMS 네트워크로 전달되기 위해 이 I-CSCF(123)로 송신되고, 그리하여 I-CSCF는 IMS 네트워크의 경계에서 프록시 서버로서 작동하고, IMS 네트워크에의 입구 포인트(entrance point)로 된다.

본 실시예는 두 네트워크, 즉 전용 네트워크와 공용 네트워크를 참조로 하여 기술된 것인데, 왜냐하면 본 발명의 이하의 문제는 특히 메시지의 목적지가 그 네트워크의 외부에 있을 때 경험되기 때문이다. 제 1 실시예는, 오퍼레이터 A에 속하여 operatora.com 도메인을 사용하고, 오퍼레이터 B에 속하여 operatorb.be 도메인을 사용하는 두 개의 IMS 네트워크가 존재하는 것으로 가정한다. 본 실시예에 있어서, 오퍼레이터 B는 대중에게 이동 전화 통신, GPRS 및 IMS와 같은 여러 가지 통신 서비스를 제공하는 공용 오퍼레이터인 것으로 가정한다. 예컨대, 오퍼레이터 B는 로밍용 GRX의 멤버로서, GRX에 의해 제공된 서비스를 이용할 수 있다.

제 1 실시예에서, 오퍼레이터 B의 네트워크 내에 위치하는 UA(120)의 사용자 B는 PoC 서비스를 사용하는 오퍼레이터 A의 네트워크 내에 위치하는 사용자 A와 대화하기를 원한다. 거기에 사용자 B는 오퍼레이터 A의 네트워크에서 사용자 A를 식별할 수 있는 URI을 알기를 원한다. 여기서 이 URI는 sip:usera@ims.operatora. com이다. 이 접속을 시작하기 위해 사용되는 SIP 요구는 SIP Invite 요구(110)이다.

도 1에 있어서, UA(120)는 I-CSCF(123)로 메시지(110)를 라우팅할 필요가 있다고 가정한다. 이 메시지(110)는 두 사용자간에 PoC 세션을 수립하는데 사용될 수 있는 SIP Invite 요구이다. 사용자 B는 오퍼레이터 B의 소비자로서 오퍼레이터 A에 소속되어 있는 사용자 A와의 대화를 원한다. 그러므로 사용자 B는 사용자 A에게 SIP Invite 요구(110)를 보낼 필요가 있고, 이 요구에서 사용자 A를 식별하는 SIP URI를 사용한다. 전형적으로, 임의 SIP 요구는 헤더(header)와 본체(body)로 구성되는데, 헤더는 소스, 목적지, 루트 및 요구(110)의 내용에 대한 강제 정보(mandatory information)를 포함하고, 본체는 요구(110)의 내용을 포함한다. SIP Invite 요구(110)의 도입부는, (이 요구의 경우에) 제시되는 요구의 타입, 요 구(110)이 가야할 곳을 식별하는 URI(이 경우에 sip:usera@ims.operatora.com) 및 사용되는 SIP의 버전(예컨대, 2.0)을 정의한다.

UA(120)이 오퍼레이터 A의 I-CSCF(123)에 SIP Invite 요구(110)를 전송하기 전에, I-CSCF(123)의 IP 어드레스는 단지 도메인이 SIP URI로부터 기지인 것이 필요하다. 그러므로 UA(120)는 쿼리(101)를 형성하고 전용 DNS 서버(121)에 이것을 전송할 것이다. 이 쿼리(101)는 DNS 프로토콜에 따라 포맷된 패킷이고, SIP 요구(110)를 라우팅할 것이 요구되는 IP 어드레스에 대한 요구를 포함한다. 쿼리(101)에서 UA(120)는 전용 DNS 서버(121)에 도메인 명칭(이 경우에 ims.operatora.com)을 제공하고, 요구에서 특정된 도메인에 관한 I-CSCF(123)의 IP 어드레스를 복귀하도록 요구한다. DNS 서버를 찾아 접촉할 수 있게 하기 위해, UA(120)는 이용 가능한 DNS 서버의 어드레스들로 구성되어야 한다. 이것은 디바이스 상의 정적 구성(static configuration)을 이용할 수도 있고, 또는 DNS 서버의 어드레스는 DHCP(Dynamic Host Configuration Protocol)와 같은 프로토콜을 이용하여 제공될 수 있다.

전용 DNS 서버(121)는, 도 1에서 화살표 102로 나타내는 바와 같이, 로컬 캐시와 DNS 정보를 이용하는 도메인 네임의 결정을 시도할 것이다. 물론, DNS 서버는 전에 수집된 모든 정보의 캐시를 유지하도록 구성될 수 있다. 이것은 모든 요구된 도메인 네임이 IP 어드레스를 따라 저장되고, 이들 기록은 시간의 특정한 양으로 저장되는 것을 의미한다. 캐싱은 효율을 향상시키고 다른 DNS 서버에 의해 생성된 요구의 양을 감소시키는 메커니즘이다. 그 자신의 캐시에 더하여, 전용 DNS 서버(121)는 전용 네트워크 내에 정의된 전체 도메인 네임 공간을 구성하는 DNS 서버의 네트워크 내에 포함되는 DNS 정보를 분석한다. 전용 DNS 서버용의 이 도메인 네임 공간은 전형적으로 작다. 단지 오퍼레이터 B와 같은 특별한 오퍼레이터가 이 도메인 네임 공간에 기록되어 있다. 오퍼레이터 A는 GRX의 일부분이 아니므로 오퍼레이터 A의 도메인은 전용 DNS 서버(121)에 의해 사용된 도메인 네임 공간에서 정의되지 않았다고 추측할 수 있다. 결과로써, 전용 DNS 서버(121)는 오퍼레이터 A의 도메인의 변환을 요구하는 101과 같은 쿼리에 대한 결과를 복귀시킬 수 없다.

만약 UA(120)가 오퍼레이터 B용 IP 어드레스를 요구하면, 전용 DNS 서버(121)는, IP 어드레스와 UA(120)가 다음 노드에 SIP Invite 요구(110)를 라우팅할 수 있게 됨을 응답할 수 있는 것임을 유의하자. 그러나 이 경우, 오퍼레이터 A가 어드레스를 요구하는 곳이 어디인지, 전용 DNS 서버(121)가 누구의 도메인 네임인지 모르는 경우, 쿼리(101)에 대한 응답(103)은 SIP URI를 결정하는데 실패의 통지를 포함해야 한다. 이것은 UA(120)가 전용 DNS 서버의 응답(103)을 받는다고 하여도 아직 I-CSCF(123)에 SIP Invite 요구(110)를 전송할 수 없고, 또 다른 동작을 요구하는 것을 의미한다.

이러한 실패 때문에, UA(120)는 요구된 IP 어드레스를 발견하기 위해 다른 접근법을 시도해야 한다. 본 발명에 따르면, UA(120)는 지금 DNS 서버를 요구하는 새로운 쿼리(104)를 형성하고, 이 경우 공용 DNS 서버(122)는 전용 DNS 서버(121)에 의해 알려진 도메인 네임으로 응답하도록 형성한다.

오퍼레이터 A는 일반적인 공중에 서비스를 제공하는 공용 오퍼레이터가 아니므로 GRX의 일부가 아니다. 오퍼레이터 A가 그 고용인에게 IMS 서비스를 제공하기 때문에, 오퍼레이터 B의 그것과 같이 공용 IMS 네트워크에의 링크를 필요로 한다. 이것은, 예컨대, 오퍼레이터 A와 오퍼레이터 B간의 계약을 통해 성립된다. 이 계약은 오퍼레이터 A가 특별한 서비스를 가진 IMS 네트워크를 갖게 하고, 오퍼레이터 B의 네트워크를 통해 공용 IMS 네트워크에 접속되도록 한다. 그러므로 요구은, 오퍼레이터 A의 IMS 네트워크의 입장 포인트 요구가 응답으로서 오퍼레이터 B의 입장 포인트를 반송하는 것이다. 오퍼레이터 A의 네트워크에서의 사용자 요구는 오퍼레이터 B의 네트워크를 통해 라우팅되는 것이 필요하고, 오퍼레이터 B는 오퍼레이터 A의 네트워크에 이들 메시지를 전달할 것이다. 시스템의 이러한 셋업 때문에, DNS 인프라에서의 특정한 실행이 요구된다. 이 실행에 있어서, 오퍼레이터 B는 GRX의 DNS 서버에 알려져 있다. 오퍼레이터 A는 그의 도메인(예컨대, ims.operatora. com)으로부터 오퍼레이터 B의 도메인(예컨대, ims.operatorb.be)으로의 변환을 제공한다.

공용 DNS 서버(122)는, 도 1에서 화살표 105로 나타내는 바와 같이, 로컬 캐시와 DNS 정보를 사용하는 새로운 쿼리(104)에 대한 응답을 시도할 것이다. 로컬 개시와 DNS 정보는 단계 102에서 사용된 그것과 매우 유사하다. 로컬 캐시는 전에 응답된 모든 요구와 관련하여 공용 DNS 서버(122)에 저장된 정보이다. 도메인 네임 공간에 관한 DNS 정보는 공용 DNS 서버(122)에 알려져 있다. 이 도메인 네임 공간은 전용 DNS 서버(121)에 알려진 도메인 네임 공간보다 상당히 크고, 일반적으로 등록된 모든 도메인을 포함한다. 공용 DNS 서버(122)가 URI를 결정할 수 있으면, 응답(106)은 전용 DNS 서버(121)에 알려져 있는 새로운 도메인 네임을 포함하는 것으로 형성된다. 이러한 상황 하에서의 결정이란, 공용 IMS 오퍼레이터 B의 도메인을 결정하고 오퍼레이터 A를 위해 공용 IMS 네트워크에의 링크를 제공하는 것을 의미한다. 공용 DNS 서버(122)는, 예컨대, UA(120)에 전송되는, 응답(106)으로서의 새로운 도메인인 ims.operatorb.be를 전달할 것이다.

공용 DNS 서버(122)는, DNS 구성에서의 특정 기록을 이용함으로써, ims.operatora.com으로부터 ims.operatorb.be로의 변환을 제공할 수 있다. 본 발명의 제 1 실시예에 있어서, NAPTR 기록은 상기 변환을 행하는데 이용된다. NAPTR 기록은 요구에 URI가 응답하는 적응 수단을 정의한다. 이것은 공용 DNS 서버(122)가 sip:usera@ims.operatora.com에 대한 요구를 수신할 수 있게 하고, sip:usera@ims.operatorb.be로 응답한다. 최종 URI를 결정하기 위해 전용 DNS 서버(121)와 쿼리를 접촉시킬 수 있으므로, UA(120)는 최종 요구 URI를 가진 메시지를 라우팅할 수 있을 것이다. operatorb.be가 전용 DNS 서버(121)에 알려져 있기 때문에, UA(120)에 요구 IP 어드레스를 제공할 수 있다. UA(120)는 쿼리(107)로의 변환을 요구할 것이다. 도 1의 화살표 108로 나타내는 바와 같이, 이 쿼리는 변환된 URI를 포함하고, 로컬 캐시와 DNS 정보의 새로운 체킹 후에, 전용 DNS 서버(121)는 SIP Invite 요구(110)를 라우팅하도록 UA(120)가 필요로 하는 정보를 제공할 수 있고, 이 정보는 응답(109)으로 UA(120)에 전달된다.

공용 DNS 서버(122)가 도메인 네임을 결정할 수 없는 경우에, 전용 DNS 서버(121)와 공용 DNS 서버(122)는 요구 IP 어드레스를 전달할 수 없으므로, 처리는 정지되고, UA(120)는 그 어드레스를 얻을 수 없기 때문에 I-CSCF(123)에 메시지(110)를 라우팅할 수 없을 것이다.

도 2는 본 발명의 다른 실시예에 있어서의 메시지 흐름을 나타낸다. 본 실시예는 IMS 네트워크(220)에서의 노드, 전용 DNS 서버(221), 공용 DNS 서버(222) 및 외국에 IMS 네트워크에 있어서의 노드(223)를 포함한다. 전용 DNS 서버(221) 및 공용 DNS 서버(222)는 기존의 DNS에 따라서 서로 링크되어 있지 않다.

기존 DNS는 서버의 트리형 구조로 형성된다. 최상위에는 TLD(Top Level Domains)에 대한 정보를 가진 DNS 루트 서버가 위치한다. 호스트 네임을 결정하는데 필요한 DNS 서버는 DNS 서버가 특정 TLD에 대한 권한을 가진 것을 찾아내기 위해 루트 DNS 서버와 접속할 수 있다. DNS 서버는 DNS 서버가 특정 도메인에 대한 권한을 가진 것을 찾아내기 위해 TLD에 대한 권한을 가진 DNS 서버와 접속할 수 있다. 다음에 DNS 서버는 호스트 네임을 결정하는데 권한을 가진 DNS 서버와 접속할 것이다.

이러한 시스템에 있어서, DNS 서버는 후반에 요구 정보를 가진 다른 DNS 서버를 참조하거나 가능한 DNS 서버를 참조할 수 있다. 이러한 전체 과정은 화살표 202, 204 및 206으로 도시된 단계에서 일어날 수 있다. 여기서의 차이는 공용 DNS 서버(222)가 기존 DNS 참조를 통해 도달할 수 없는 것이다. 전용 DNS 서버(221)는 그 구성에 있어서 공용 DNS 서버(222)와의 접속 방법에 대한 몇 가지 지식을 갖고, DNS 쿼리를 수행할 수 있는 전형적인 퍼스널 컴퓨터의 구성과 매우 유사하다.

본 발명의 다른 실시예에 있어서, 노드(220)와 노드(223)는 모두 I-CSCF이다. I-CSCF의 작업 중 하나는 IMS 네트워크의 입장 포인트로서 동작하는 것이다. 노드 외부의 특정 IMS 네트워크는 그 네트워크 상으로 메시지를 전송하기 위해 그 IMS 네트워크의 I-CSCF와 접속할 수 있다.

공용 DNS 서버(222)는 DNS 서비스를 제공하는 디폴트 소프트웨어 애플리케이션이다. http://www.powerdns.com/에서 광고된 PowerDNS가 공용 DNS 서버(222)로서 본 발명의 제 2 실시예에서 사용된다고 가정하다. 공용 DNS 서버(222)는 일반 공중에 DNS 서비스를 제공하기 때문에 공용되는 것이 고려된다. 누구라도 특정 DNS 정보에 대한 요구를 가진 공용 DNS 서버(222)와 접속할 수 있다.

전용 DNS 서버(221)와 같은 DNS 서버는 사용자의 수를 제한하여 정보를 제공하기 때문에 전용적인 것으로 고려된다. 본 실시예에 있어서, GRX에 의해 제공된 DNS 서버는 전용 DNS 서버(221)로서, GRX에 접속된 오퍼레이터만이 접속 가능하다. 전용 DNS 서버(221)에 알려진 도메인 네임 공간은 일반적으로 작은데 반해, 공용 DNS 서버(222)에 알려진 도메인 네임 공간은 실질적으로 크다. 공용 DNS 서버(222)는 등록된 모든 도메인 및 인터넷에서 사용되는 모든 도메인에 대하여 지식을 갖거나 그에 대한 지식을 얻을 수도 있다.

본 발명의 제 2 실시예에 있어서, 전용 DNS 서버(221)는 DNS 서비스를 제공하고, 표준 검색의 일부가 아닌 단계를 수행하는 능력에 의해 PowerDNS와 같은 다른 DNS 소프트웨어 애플리케이션과는 다른 소프트웨어 애플리케이션이다. 전용 DNS 서버(221)는, 이하에 더욱 상세하게 설명하는 바와 같이, 특정 DNS 정보를 요구하는 네트워크 내의 다른 디바이스로부터의 쿼리를 수신할 수 있고, 요구 정보를 제공하도록 시도할 수도 있다. 그렇지만 만약 전용 DNS 서버(221)가 도메인에 관한 요구가 공용 DNS 서버(222)에만 알려져 있어 요구 정보를 제공할 수 없는 경우에는, 전용 DNS 서버(221)는 정보에 대한 요구, 도 2에 있어서, 예컨대, 요구(203)을 가진 공용 DNS 서버(222)에 접속할 수 있다.

상술한 쿼리는 정보에 대한 문제를 포함하는 DNS 표준에 따라 포맷된 DNS 서버에 전송된 메시지이다. 쿼리의 예는 특정 서버의 IP 어드레스에 대한 요구이다. 쿼리를 수신하는 DNS 서버는 응답을 찾기 위해 여러 단계에서 실행될 수 있다. 제 1 단계는 DNS 서버에 의해 유지된 로컬 캐시 내를 검색할 수 있다. 캐싱은 이전 쿼리에 대하여 특정 시간의 양으로 정보를 저장하는 것을 의미한다. 그리하여, 만약 DNS 서버가 쿼리에 응답을 제공할 경우, 특정 시간 동안 네임 서버에 형성된 어떤 부수적인 요구에 대한 응답을 저장할 것이다. 이것은 다른 DNS 서버에 DNS 서버에 의해 생성된 트래픽의 양을 감소시키고, DNS 서버에 의해 조정될 수 있는 쿼리의 양을 증가시킨다. 다른 단계는 DNS 서버가 책임을 가진 도메인에 대하여 정보를 컨설팅할 수도 있다. DNS 서버가 쿼리 내에 특정된 도메인에 대하여 책임이 있으면, 그 자신의 데이터베이스로부터 정보를 정정할 수 있고, 응답으로서 제공할 수도 있다. 다른 단계는 특정 도메인에 대한 권한을 가진 네임 서버를 위치시키기 위해 다른 DNS 서버와 접속되고 나서 요구된 정보에 대한 네임 서버를 접속할 수도 있다.

제 2 실시예는 또한 두 개의 다른 IMS 네트워크를 참조하여 기술한다. 한 네트워크는 operatora.com 도메인을 사용하는 오퍼레이터 A에 속하는 네트워크이고, 일반적인 대중에게 서비스를 제공하는 공용 IMS 오퍼레이터이다. 다른 네트워크는 enterpriseb.com 도메인을 사용하는 엔터프라이즈 B에 속하는 네트워크이고, 그 도메인의 고용인에게 IMS 서비스를 제공한다. 본 실시예에 있어서, 오퍼레이터 A의 네트워크 내의 사용자 A가 엔터프라이즈 B의 네트워크 내의 사용자 B에게 메시지를 전송한고 가정한다. 이 메시지는 양 사용자간에 세션을 확립하는데 사용된 SIP Invite 요구(208)이다. I-CSCF(220)은, 예컨대, UA로부터 SIP Invite 요구를 수신하고, I-CSCF(223)에 대하여 특정 SIP Invite 요구에서 특정된 요구 URI sip:userb@enterpriseb.com를 가진 SIP Invite 요구를 라우팅할 것을 요구한다. I-CSCF(220)는 어드레스 변환 후에 SIP Invite 요구(208)으로서 수신된 SIP Invite 요구를 전송할 것이다.

I-CSCF(220)는, I-CSCF(223)에 SIP Invite 요구(208)을 전송하기 전에, I-CSCF(123)에 대한 IP 어드레스를 요구한다. 그러므로 I-CSCF(220)는 sip:userb@enterpriseb.com을 분석하기 위한 요구를 가진 쿼리(201)를 전용 DNS 서버(221)에 보내고, I-CSCF(220)는 전용 DNS 서버(221)로부터의 응답 중에서 I-CSCF(223)의 IP 어드레스를 예측한다. 전용 DNS 서버(221)는, 도 2에 화살표 202로 나타내는 바와 같이, 로컬 캐시와 전용 DNS 정보를 사용하는 URI의 결정을 시도할 것이다. 그러나, 전용 DNS 서버(221)는 enterpriseb.com 도메인에 대하여 모르므로 요구된 정보를 제공할 수 없다. 전용 DNS 서버(221)는 enterpriseb.com과 접속하는데 사용될 수 있는 상응 도메인을 발견하기 위해 쿼리(203)을 가진 공용 DNS 서버(222)와 접속할 수 있다. 공용 DNS 서버(222)는, 도 2의 화살표 204로 나타내는 바와 같이, enterpriseb.com을 포함하는 임의 SIP URI를 operatorc.com을 포함하는 URI로 변환하는 NAPTR 기록을 갖는다. 본 실시예에서, operatorb.com은 다른 공용 IMS 오퍼레이터 C에 속하고, IMS 루팅 서비스를 제공하기 위해 엔터프라이즈 B와 계약을 체결하고 있다. 오퍼레이터 C는 그들이 공용 IMS 오퍼레이터이기 때문에 전용 DNS 서버(221)에 알려져 있다. 하나의 도메인으로부터 다른 도메인으로의 변환은 로컬 캐시나 DNS 정보를 이용하여 행할 수 있고, 이것은 도 2의 화살표 204로 표시되어 있다. 공용 DNS 서버(222)는, 예컨대, sip: userb@operatorc.com과 같은 새로운 URI를 포함하는 공용 DNS 서버(222)에 응답을 전송한다. 다음에 전용 DNS 서버(221)는, 화살표 206으로 나타내는 바와 같이, 로컬 캐시와 DNS 정보를 이용하는 새로운 URI를 결정할 수 있다. operatorc.com 도메인은 전용 DNS 서버(221)에 알려져 있으므로, 전용 DNS 서버(221)는 응답(207)으로 I-CSCF(220)에 IP 어드레스를 제공할 수 있다. 이 IP 어드레스를 이용하면, I-CSCF(220)는 오퍼레이터 C에 SIP Invite 요구를 전송할 수 있고, 차례로 I-CSCF(223)에 메시지를 전달할 수 있다.

도 1의 화살표 107, 108 및 109와 도 2의 화살표 206은 요구되는 것이 아님을 인지하는 것이 중요하다. 이들 화살표는 공용 DNS 서버(122 또는 222)가 전용 DNS 서버(121 또는 221)의 각각에 알려져 있는 도메인 네임을 반송하는 것을 가리키고, 여기서 이들 DNS 서버는 도메인 네임을 결정하기 위해 다른 시도를 수행해야 한다. 공용 DNS 서버(122 또는 222)를 거쳐 요구 디바이스(120 또는 220)에 직접 IP 어드레스를 제공함으로써 몇몇 보안을 포기할 수 있다. 이것은 그들 자신의 공공에 알려진 도메인을 회사가 사용하도록 하여 원하는 적응성을 제공한다.

도면에 나타내는 DNS 서버 블록은 복수의 DNS 서버의 집합체를 나타내는 것임을 유의해야 한다. 몇몇 DNS 서버는 쿼리가 수신된 후 및 응답이 전송되기 전에 서로 통신을 행할 수 있다. 예컨대, DNS 블록으로부터 시작하고 DNS 블록을 향해 가는 화살표는 실제로는 복수의 메시지를 나타낸다. 예컨대, 공용 DNS 서버는 첫째로 로컬 캐시를 체킹하고, 둘째로 루트 네임 서버와 접속하고, 셋째로 최상위 레벨 도메인(예컨대, .com 이나 .be)용 서버와 접속하며, 넷째로 somedomain.com에 대한 권위를 가진 네임 서버와 접속하며, 원하는 정보를 정정하는 것을 나타낼 수 있다. PowerDNS 및 BIND와 같은 상술한 DNS 애플리케이션은 DNS 서비스를 제공하는데 사용 가능한 현존하는 소프트웨어의 일례일 뿐이다. 도메인 네임으로부터 IP 어드레스로의 변환을 제공할 수 있고, NAPTR 실행 및 SRV 기록을 행할 수 있는 어떤 소프트웨어나 디바이스라도 공용 DNS 서버(222)로서 사용될 수 있다.

또한 PoC는 단지 IMS 서비스의 일례일 뿐인 것에 유의해야 한다. 다른 예로서 사용자 서로가 텍스트 메시지를 전송할 수 있게 하는 인스턴트 메시지 서비스가 있고, 이들 메시지는 수신 사용자에게 즉각적으로 표시된다. 일반적으로, IMS 네트워크를 사용하는 애플리케이션은 몇몇 포인트에서 여러 가지 IMS 네트워크간에 통신을 필요로 하는 것이 예측된다.

GRX 인프라는 전용 관리 네트워크의 예로써 사용된다. 이 예는 GPRS 네트워크에 DNS 서비스 및 로밍을 제공한다. IMS 네트워크간에 접속을 제공할 수 있고 어드레스 결정 서비스를 제공할 수 있는 어떤 시스템은 GRX에 대신하여 사용될 수 있다.

NAPTR과 SRV 기록은 상기한 설명에서 예제로써 사용된다. 단지 본 발명에 있어서는 그들의 특징이 중요하고, 상응하는 구성이 요구된 기능성을 제공하도록 사용될 수 있다. 다른 시스템에 재지시를 제공하거나 URI를 다른 URI로 변환할 수 있거나 또는 특정 도메인에 근거하여 다른 도메인을 정정하는데 사용할 수 있는 임의 DNS 기록 타입은 본 발명의 실시에에서 사용될 수 있다.

본 발명은 특정 실시예를 참조하여 설명되어 있지만, 본 발명은, 상술한 실시예의 내용에 제한되지 않을 뿐만 아니라, 본 발명의 정신 및 범주로부터 벗어나지 않는 여러 가지 변경 및 변형을 행할 수 있는 것임을 당업자라면 용이하게 파악하여 실시할 수 있을 것이다. 그러므로 본 실시예는 제한적이 아니라 일례로서 모든 관계가 고려되어야 하고, 상기의 상세한 설명이 아닌 첨부된 청구항에서 지시하는 발명의 범주, 및 청구항의 취지와 동등한 범위 내에서 이루어지는 모든 변경이 여기에 포함되어야 한다. 즉, 본 특허 출원은 그 발명의 주요 기본 원칙의 정신 및 범주에 포함되고, 또한 본 특허 출원에서 청구된 본질적인 특성을 가진 모든 변형물, 변경물이나 등가물이 여기에 포함되어야 한다. 본 특허 출원의 독자는 "포함하는(comprising)"이나 "포함하다(comprise)"라는 단어가 다른 구성 요소나 단계를 배제하는 것은 아니고, "하나(a, an)"의 단어가 복수를 배제하는 것은 아니며, 또한 컴퓨터 시스템이나 집적 유닛과 같은 단일 구성 요소는 청구항에 기재된 몇몇 수단의 기능을 이행할 수도 있는 것임을 이해할 것이다. 청구항에 기재된 참조 기 호는 관련된 각 청구항을 제한하는 것으로 이해해서는 안된다. "첫째", "둘째", "세째", "1", "2", "3"과 같은 항목이 상세한 설명이나 청구항에 사용되었을 경우, 이는 유사 구성 요소나 단계를 구별하여 소개하는 것일 뿐, 이것이 반드시 순서나 시간적 수순을 나타내는 것은 아니다. 상기한 관점은 적절한 환경 하에 호환성을 가지고 사용될 수 있고, 본 발명의 실시예는 다른 수순이나 상기에 설명하거나 예시한 내용과는 다른 방향으로 본 발명에 따라 작동될 수도 있다.

Claims

IMS(IP Multimedia Subsystem) 네트워크 내 또는 IMS 네트워크들 사이에서 메시지를 라우팅하는데 사용되는 URI(Uniform Resource Identifier)를 결정하기 위한 방법으로서,

a) 상기 URI를 결정하기 위한 쿼리(101, 201)를, 상기 IMS 네트워크에 메시지를 전송할 수 있는 디바이스(120, 220)로부터 전용 네임 서버(121, 221)로 전송하는 단계 -상기 전용 네임 서버(121, 221)는 알려진 도메인의 제한된 세트를 포함하며, 기관에 의하여 관리되고, 인터넷에서 일반인이 사용가능한 도메인 네임 서버 인프라와 분리됨-와,

b) 상기 전용 네임 서버(121, 221)에 의해 상기 URI를 결정(102, 202)하는 단계와,

c) 상기 전용 네임 서버(121, 221)에 의한 상기 URI의 결정이 실패한 경우, 상기 URI를 결정하기 위한 새로운 쿼리(104, 203)를 상기 인터넷 상의 공용 네임 서버(122, 222)로 전송하는 단계와,

d) 상기 공용 네임 서버(122, 222)에 의해 상기 URI를 결정(105, 204)하는 단계와,

e) 상기 디바이스(120, 220)에 의해, 상기 쿼리(104, 203)에 대한 응답(106, 205)을 수신하는 단계를 포함하는

URI 결정 방법.
제 1 항에 있어서,

상기 새로운 쿼리(104, 203)를 전송하는 상기 단계 c)는 상기 디바이스(120, 220)에 의해 수행되는

URI 결정 방법.
제 1 항에 있어서,

상기 새로운 쿼리(104, 203)를 전송하는 상기 단계 c)는 상기 전용 네임 서버(121, 221)에 의해 수행되는

URI 결정 방법.
제 1 항에 있어서,

상기 단계 d)는 상기 URI의 도메인을 NAPTR(Naming Authority Pointer) 기록을 사용하는 다른 도메인으로 변환하는 단계를 더 포함하는

URI 결정 방법.
제 1 항에 있어서,

상기 단계 d)는 상기 URI의 도메인을 SRV(Serivce) 기록을 사용하는 다른 도메인으로 변환하는 단계를 포함하는

URI 결정 방법.
IMS(IP Multimedia Subsystem) 네트워크에서 메시지를 라우팅하는 디바이스(120)로서,

URI(Uniform Resource Identifier)를 결정(102)하기 위한 쿼리(101)를 생성할 수 있는(formulate) 수단과,

전용 네임 서버(121)로 상기 쿼리(101)를 전송하는 수단 -상기 전용 네임 서버(121)는 알려진 도메인의 제한된 세트를 포함하며, 기관에 의하여 관리되고, 인터넷에서 일반인이 사용가능한 도메인 네임 서버 인프라와 분리됨-과,

상기 쿼리(101)에 대한 응답(103)을 해석하는 수단을 포함하되,

상기 디바이스(120)는, 상기 전용 네임 서버로부터의 응답이 상기 전용 네임 서버(121)에 의해 상기 URI를 결정(102)하는 것이 실패했음을 나타내는 경우, 상기 URI를 결정(105)하기 위한 새로운 쿼리(104)를 생성하여, 상기 인터넷 상의 공용 네임 서버(122)에 상기 새로운 쿼리(104)를 전송하는

메시지 라우팅 디바이스.
IMS(IP Multimedia Subsystem) 네트워크에서 메시지를 라우팅하는데 사용되는 URI(Uniform Resource Identifier)를 결정하기 위한 전용 네임 서버(221) -상기 전용 네임 서버(121, 221)는 알려진 도메인의 제한된 세트를 포함하며, 기관에 의하여 관리되고, 인터넷에서 일반인이 사용가능한 도메인 네임 서버 인프라와 분리됨- 로서,

URI를 결정하기 위한 쿼리(201)를 수신하는 수단과,

상기 URI를 결정하기 위한 수단과,

상기 쿼리(201)에 대한 응답(207)을 생성하는 수단과,

상기 응답(207)을 전송하는 수단을 구비하되,

상기 전용 네임 서버(221)는, 상기 전용 네임 서버(221)에 의한 상기 URI의 결정(202)이 실패인 경우에, 상기 URI를 결정(204)하기 위한 새로운 쿼리(203)를 생성하여, 상기 인터넷 상의 공용 네임 서버(222)로 상기 새로운 쿼리(203)를 전송하는

전용 네임 서버.