KR101451478B1 - 백-투-백 사용자 에이전트(ｂ2ｂｕａ) 환경에서의 ｓｉｐ 전환 - Google Patents

Abstract

시스템은 호 전환 동안 SIP INVITE 메세지에서의 변경을 발생시킨다. 여기서, 호에 수반된 사용자 연관 요소는 전환 파티의 엔드포인트 뷰을 포함하도록 메세지에서의 해더 정보를 변경할 수 있다. 따라서, INVITE 메세지는 전환 파티의 사용자 연관 요소로 다시 보내지며, 이것은 수신된 메세지를 해석하고 실재하는 호 경로에서의 B2BUA들을 언래블링할 수 있다. 시스템은 메세지 변경에 영향을 미치고 한번 수신된 메세지를 해석하기 위해 사용자 연관 요소에서의 변경들을 포함한다. 사용자 연관 요소로의 변경들은 통신 엔드포인트들을 변경할 필요를 없게 한다.

Description

백-투-백 사용자 에이전트(Ｂ2ＢＵＡ) 환경에서의 ＳＩＰ 전환{SIP TRANSFER IN A BACK-TO-BACK USER AGENT(B2BUA) ENVIRONMENT}

본 발명은 백-투-백(back-to-back) 사용자 에이전트(agent) 환경에서의 SIP 전환에 관한 것이다.

일반적으로, 디지털 호 시스템들은 사용자들 또는 시스템 관리자들이 통신 세션(session)들에서 애플리케이션(application)들을 포함하는 것을 허용한다. 이러한 애플리케이션들은 타양한 태스크(task)들, 예컨대 호를 기록하는 것, 정보를 획득하는 것, 발신자 정보를 제공하는 것 등을 완료할 수 있다. 몇몇 통신 시스템들에 있어서, 애플리케이션들은 시퀀스(sequence)화될 수 있으며, 이것은 호 토폴로지(topology)에서 애플리케이션들이 "백-투-백(back-to-back)"으로 배치되는 것을 통상적으로 필요로 한다. 이에 따라, 호에서의 통신들이, 호 데이터 및 관리 메세지들을 포함하여, 시퀀스로 각 애플리케이션을 통해 전송된다. 많은 경우에서, 시퀀스에서의 애플리케이션들은 백-투-백 사용자 에이전트(agent)들(B2BUAs)로 언급된다.

공교롭게도, B2BUA들을 이용하는 것에 문제들이 있다. 3개 이상의 통신 엔드포인트(endpoint)들을 갖는 호에 있어서 그리고 호 전환 동안, 호 전환에 관련된 B2BUA들은 코멘트(comment) 요청(RFC) 5589에서 기술된 전환 호 흐름들을 동작 불가능하게 할 수 있다. 세션 개시 프로토콜(protocol)(SIP) 표준은 통상적으로 엔드포인트에서 엔드포인트까지의 다이얼로그(dialog) 정보의 완벽한 가시성을 기대한다. 호 전환 같이 많은 복잡한 호 특질들은, 다이얼로그 정보의 가시성에 의존한다. 공교롭게도, B2BUA들은 다이얼로그 정보가 가시적이다는 추정에 기반한 호 흐름들을 손상시킨다. 예컨대, B2BUA들은 메세지에서의 다이얼로그 ID들 및 콘택트(Contact) 유니폼 리소스 식별자(URI)를 다음의 B2BUA 또는 다른 시스템 구성 요소로 그들을 전송하는 것 이전에 변경할 수 있다. 이러한 동작은 전환된 엔드포인트에 의해 Refer-To: URI/dialog ID를 이용 불가능하게 한다.

원거리 말단 아이덴티티(identity) 정보가 고유 INVITE 메세지의 요청 URI, 투(To), P-어설티드(asserted)-아이덴티티, 및 프롬(From) 헤더(header)들에서 유지된다는 것이 사실인 반면에, 이들 헤더들은 특정 디바이스를 어드레스(address)하는데 충분하지 않다. RFC 5589는 전환들이 콘택트 URI 및 주 다이얼로그 ID를 이용한다고 구술한다. 이러한 정보는 B2BUA들에 의해 바뀌기 때문에, 전환은 문제가 된다.

이전의 해결책은 주 B2BUA(때때로 호 관리자로 언급됨)가 REFER를 차단하게 하고 전환된/전환 타겟(target) UA들을 Re-INVITING에 의해 전환 자체에 영향을 주어 그들이 결국 서로 통신하게 되도록 시도한다. 이것은: 전환하는 파티(party)가 호로부터 드롭(drop)한 후 시그널링(signaling) 경로에서 전환하는 파티에 대해 시퀀스화된 B2BUA들을 남기는 것; 그리고 다른 시퀀스화된 B2BUA들로부터 전환 호 흐름을 모호하게 하는 것의 유감스러운 부작용들을 가져, 전환이 발생하였다는 것을 인지하는 것이 용이하지 않다.

상기 이슈들 및 다른 문제들에 대해서 본 명세서에 실재하는 실시형태들이 고려되었다. 몇몇 실시형태들에 있어서, 시스템은 전환 동안 INVITE 메세지에서의 변경을 포함한다. 여기서, 호에 관련된 사용자 연관 요소는 전환하는 파티의 엔드포인트 뷰을 포함하도록 메세지에서의 헤더 정보를 변경할 수 있다. 따라서, INVITE 메세지는 수신된 메세지를 해석하고 실재하는 호 경로(예컨대, 전환이 요청되기 전에 수립된 호 경로)에서 B2BUA들을 "언래블링(unraveling)"할 수 있는 전환하는 파티의 사용자 연관 요소로 다시 보내진다. 시스템은 메세지 변경에 영향을 미치고 한번 수신된 메세지를 해석하기 위해 사용자 연관 요소에서의 변경을 포함한다. 사용자 연관 요소에의 변경은 엔드포인트 UA들을 변경할 필요를 없게 한다.

실시형태들에 있어서, 시스템은 콘택트 URI에 유니폼 리소스 식별자(URI) 파라미터(parameter)가 부여된 프록시(proxy)/등록/위치 서버(server)/특성 시퀀서("사용자 연관 요소"로 언급되는)를 가짐으로써 RFC 5589에서 한정된 표준에 따라 호 흐름에 표준 UA들이 참여하는 것을 허용한다. 콘택트 URI에서의 URI 파라미터는 요청이 B2BUA들을 거쳐서 트래버스(traverse)했더라도 콘택트 어드레스가 피어(peer) 사용자의 핸들(handle)을 캡쳐(capture)하는 것을 확실히 한다. 이러한 파라미터는 그 후 INVITE-리플레이스(replace)에서 B2BUA들을 적절히 시퀀스화하고 정전환 타겟 UA로 INVITE-리플레이스를 전송하도록 사용자 연관 요소에 의해 이용된다.

상세하게는, 사용자 연관 요소는 하기의 규칙들 중 하나 이상을 구현할 수 있다: 1) UA로부터의 요청 또는 응답의 수신시에, 고유 식별자[기록의 어드레스(AOR)-기반 전체적 라우팅 가능(routable) UA URI(GRUU) 또는 그 동등물을 포함할 수 있는]를 생성하지만, 엔드포인트 콘택트 URI가 이미 AOR-기반 GRUU이면 AOR-GRUU를 생성하는 것은 필요하지 않을 것이다; 2) AOR-기반 GRUU, 호-ID, 및 로컬(local)/원격 태그(tag)를 포함하는 엔드포인트-뷰(epv) 헤더를 생성한다; 3) 컨택트 URI의 호스트(host)부가 사용자에 대한 등록된 컨택트와 부합하는지 여부를 체크한다; 4) 부합하는 것이 있으면(요청 또는 응답이 원거리 말단 UA로 전송되고 있는 것을 나타냄), epv 헤더로부터 콘택트 URI에서의 epv 파라미터로 정보를 부여한다; 그리고 5) 이미 실재하는 등록된 콘택트 데이터베이스(database)를 제외하고, 무상태 환경으로 이들 태스크를 완료한다.

전환하는 그리고 전환된 UA가 인지하지 않은 사이에, Refer-To URI는 그 후 epv 파라미터를 포함하고, 이것은 다음의 INVITE-리플레이스에서 URI 파라미터로서 마찬가지로 포함된다. epv 파라미터는 그 후 전환 동안 애플리케이션을 정확하게 시퀀스화하는데 이용된다(INVITE-리플레이스를 이용하여). 이제 전환하는 파티에 대한 시퀀스화된 B2BUA들은 전환하는 파티가 호를 드롭한 후 시그널링 경로로부터 제거될 수 있다. 이것은 전환이 발생한 경우 인지하는데 또한 훨씬 더 용이하게 된다.

본 명세서에 이용된 바와 같이 용어 "사용자 에이전트" 또는 "UA"는 통신 세션에서의 기능 또는 특성을 구현하는 클라이언트(client) 애플리케이션을 실행하는 임의의 하드웨어 및/또는 소프트웨어를 언급할 수 있다. 사용자 에이전트는 통신 세션과 연관된 또는 통신 세션을 수립할 수 있는 하나의 또는 다중의 통신 엔드포인트일 수 있다.

본 명세서에 이용된 바와 같이 용어 "사용자 연관 요소" 또는 "URE"는 서비스들 및 애플리케이션들에 온디맨드식의(on-demand) 액세스(access)를 생성하는 임의의 하드웨어 및/또는 소프트웨어, 디바이스, 애플리케이션, 인프라스트럭쳐(infrastructure)를 언급할 수 있다. 사용자 연관 요소는 UA들로의 그리고 UA들로부터의 세션들에 적용될 수 있는 사용자들에 대한 애플리케이션들의 인스턴스(instance)들을 인스턴스화(instantiate)할 수 있다. 사용자 연관 요소는 사용자 선호도에 기반하여 호들을 차단하는 것, 사용자들이 회사를 가로질러 이동하는 경우 사용자들에게 호들을 보내는 것, 그리고 착신 및 발신 호들에 대한 발신자 번호 표시 정보를 늘리는 것과 같은 일들을 하기 위해 제 3 파티 사용자들에 대한 프로파일(profile)을 생성하고 사용자들에 적용될 애플리케이션들을 추가할 능력을 제공한다. 실시형태들에 있어서, URE는 사용자 정의 및/또는 관리상의 정의인 선호도를 위하여 또는 선호도에 따라 애플리케이션들을 초기에 시퀀스화하는 엔티티(entity)이다.

본 명세서에 이용된 바와 같이 용어 "호 관리자"는 2개 이상의 통신 엔드포인트들간의 통신 세션들을 수립하는 것을 조력하도록 동작 가능한 임의의 하드웨어 및/또는 소프트웨어, 디바이스, 애플리케이션, 또는 인프라스트럭쳐를 언급할 수 있다. 실시형태들에 있어서, 호 관리자는 또 다른 B2BUA이다.

본 명세서에 이용된 바와 같이 용어 "전체적 라우팅 가능 UA URI(GRUU)"는 구체적 UA에 호를 라우팅하기 위해 시스템의 임의의 구성 요소에 의해 이용될 수 있는 임의의 고유 식별자(예컨대, URI)를 언급할 수 있다.

본 명세서에 이용된 바와 같이 용어 "기록의 어드레스(AOR)"는 구체적 사용자 또는 시스템의 구성 요소에 호를 맵핑(mapping)하거나 보내는데 이용될 수 있는 임의의 어드레스를 언급할 수 있다. 따라서, AOR은 사용자 또는 구성 요소의 "퍼블릭(public) 어드레스"일 수 있다. 단일 AOR은 다중 UA들과 접속될 수 있다. 일반적으로, AOR은 사용자를 식별하고 GRUU는 그 사용자에 대한 디바이스를 식별한다.

본 명세서에 이용된 바와 같이 용어 "컴퓨터 판독 가능 매체"는 실행을 위해 프로세서에 명령을 제공하는 것에 참여하는 임의의 유형의 저장 장치를 언급한다. 이러한 매체는 비휘발성 매체, 휘발성 매체, 및 전송 매체를 포함하지만 이에 한정되지 않는 많은 형태들을 취할 수 있다. 비휘발성 매체는, 예컨대 NVRAM, 또는 자기 또는 광 디스크들을 포함한다. 휘발성 매체는 메인(main) 메모리와 같은 동적 메모리를 포함한다. 공통의 형태의 컴퓨터 판독 가능 매체는, 예컨대 플로피 디스크, 가요성 디스크, 하드 디스크, 자기 테이프, 임의의 다른 자기 매체, 광자기 매체, CD-ROM, 임의의 다른 광 매체, 펀치 카드(punch card), 종이 테이프, 구멍들의 패턴들을 갖는 임의의 다른 물리적 매체, RAM, PROM, 및 EPROM, FLASH-EPROM, 메모리 카드와 같은 고체 상태 매체, 임의의 다른 메모리 칩 또는 카트리지(cartridge), 또는 컴퓨터가 판독할 수 있는 임의의 다른 매체를 포함한다. 컴퓨터 판독 가능 매체가 데이터베이스로서 구성되는 경우, 데이터베이스는 관계형, 계층형, 및/또는 객체 지향형, 등과 같은 임의의 타입의 데이터베이스일 수 있다는 것이 이해되어야 한다. 따라서, 실시형태들은 본 실시형태들의 소프트웨어 구현들이 저장되는 유형의 저장 매체, 종래 기술에 인지된 동등물들 및 계승자 매체를 포함하도록 고려된다.

본 명세서에 이용된 바와 같이 용어 "통신 세션"은 음향, 영상, 텍스트, 또는 다른 멀티미디어 데이터를 포함하든지, 통신 디바이스들간의 임의의 통신 또는 통신들의 세트를 언급한다. 통상적으로, 통신 세션은 2개 이상의 통신 엔드포인트들, UA들, 및/또는 하나 이상의 통신 서버들(예컨대, SIP 서버)을 포함한다.

본 명세서에 이용된 바와 같이 용어 "통신 디바이스" 또는 "통신 엔드포인트"는 통신 세션에 관여하도록 동작 가능한 임의의 하드웨어 디바이스 및/또는 소프트웨어를 언급한다. 예컨대, 통신 디바이스는 IP-가능폰, 데스크탑(desktop)폰, 셀룰러(cellular)폰, 개인 휴대 정보 단말기, 컴퓨터 시스템에서 실행하는 소프트-클라이언트 전화 프로그램, 등일 수 있다. 실시형태에 있어서, 통신 엔드포인트는 도 5 및 6과 함께 설명하는 바와 같은 컴퓨터 시스템이다.

본 명세서에 이용된 바와 같이 용어 "세션 개시 프로토콜"(SIP)은 인터넷 프로토콜(IP)을 통한 음성 및 영상 통화들과 같은 멀티미디어 통신 세션을 제어하기 위해 널리 이용되는 IEFT-정의 시그널링 프로토콜을 언급한다. 프로토콜은 하나 또는 수개의 매체 스트림(stream)들로 구성되는 2-파티[유니캐스트(unicast)] 또는 멀티파티[멀티캐스트(multicast)] 세션들을 생성하고, 수정하고, 종료하기 위해 이용될 수 있다. 수정은 어드레스들 또는 포트(port)들을 변경하는 것, 더 많은 참여자들을 초대하는 것, 그리고 매체 스트림들을 추가하거나 삭제하는 것을 수반할 수 있다. 다른 실현 가능한 애플리케이션 실시예들은 영상 회의, 멀티미디어 분배를 스트리밍하는 것, 즉각적 메세지 보내는 것, 정보 실재, 파일(file) 전송 및 온라인 게임들을 포함할 수 있다. SIP는 RFC 3261에서 설명한 바와 같이, 인터넷 국제 표준화 기구(IETF) 네트워크 워킹(working) 그룹, 2000년 11월로부터 이용 가능하고; 상기 문서 및 SIP를 설명하는 모든 다른 문서들은 그들이 교시하는 모두를 위해 전체적으로 참조에 의해 여기에 통합된다.

본 명세서에 이용된 바와 같이 용어 "네트워크"는 통신 엔드포인트들간에 통신들을 제공하도록 통신 플랫폼(platform)에 의해 이용되는 시스템을 언급한다. 네트워크는 2개의 사용자들간에, 음성이든 데이터이든, 통신들을 허용하는 하나 이상의 사용자 연관 요소들, 특성 서버들, 통신 엔드포인트들, 등으로 구성될 수 있다. 네트워크는 도 6 및 7과 함께 설명하는 바와 같이 임의의 네트워크 또는 통신 시스템일 수 있다. 일반적으로, 네트워크는 통신 플랫폼 활동들을 용이하게 하기 위해 디바이스들간에 메세지들 또는 데이터를 수신하고 전송하는 로컬 영역 네트워크(LAN), 광역 네트워크(WAN), 무선 LAN, 무선 WAN, 인터넷, 등일 수 있다. 네트워크는 전송 제어 프로토콜/인터넷 프로토콜(TCP/IP), 802.11g, 802.11n, Bluetooth와 같은 관련 분야에 공지된 임의의 형식 또는 프로토콜, 또는 다른 형식들 또는 프로토콜들로 통신할 수 있다.

본 명세서에 이용된 바와 같이 용어 "데이터베이스", "아카이브(archive)", 또는 "데이터 구조체"는 데이터를 저장하는 임의의 시스템, 하드웨어, 소프트웨어, 메모리, 저장 디바이스, 펌웨어(firmware), 구성 요소, 등을 언급한다. 데이터 모델은 임의의 타입의 비일시적인, 유형의 컴퓨터 판독 가능 매체에 저장되는 도 6 및 7과 함께 설명하는 임의의 타입의 데이터베이스 또는 저장 프레임워크(framework)일 수 있다. 데이터베이스는 데이터의 아이템(item)을 저장하는 하나 이상의 구획들 또는 부분들을 구비할 수 있는 하나 이상의 데이터 구조체들을 포함할 수 있다. 구획은 데이터 구조체의 타입에 의존하여, 객체의 속성, 데이터 필드(field), 또는 하나 이상의 타입들의 데이터 구조체들에 포함되는 다른 타입의 구획들을 포함할 수 있다. 데이터 구조체는 텍스트 스트링(string)을 나타낼 수 있거나 임의의 타입의 데이터베이스, 예컨대 관계형 데이터베이스, 플랫(flat) 파일 데이터베이스, 객체 지향형 데이터베이스, 또는 다른 타입들의 데이터베이스들의 구성 요소가 될 수 있다. 또한, 데이터 구조체들은 런타임(run-time) 애플리케이션들에서 또는 통신을 초기화하는 것에서 중 하나에 이용될 수 있는 메모리 구조체들 또는 메모리에 저장될 수 있다.

문구들 "적어도 하나의", "하나 이상의", 및 "및/또는"은 기능에서 접속적인 그리고 이접적인 양자인 제한을 두지 않은 표현들이다. 예컨대, 각각의 표현들 "A, B 및 C 중 적어도 하나", "A, B, 또는 C 중 적어도 하나", "A, B, 및 C 중 하나 이상", "A, B, 또는 C 중 하나 이상", 및 "A, B, 및/또는 C"는 A 단독으로, B 단독으로, C 단독으로, A 및 B 함께, A 및 C 함께, B 및 C 함께, 또는 A, B 및 C 함께를 의미한다.

용어 "한" 또는 "하나의" 실체는 하나 이상의 그 실체를 언급한다. 이에 따라, 용어 "한"(또는 "하나의"), "하나 이상의" 및 "적어도 하나의"는 본 명세서에서 상호 교환 가능하게 이용될 수 있다. 용어 "구비하는", "포함하는", 및 "갖는"이 상호 교환 가능하게 이용될 수 있다는 것이 또한 주목되어야 한다.

본 명세서에 이용된 바와 같이, 용어 "자동적인" 및 이것의 변형은 프로세스 또는 동작이 수행되는 경우 물질적 사람의 외력없이 행해진 임의의 프로세스 또는 동작을 언급한다. 그러나, 프로세스 또는 동작의 수행이 물질적 또는 비물질적 사람의 외력을 이용할지라도, 외력을 프로세스 또는 동작의 수행 이전에 받게 된다면, 프로세스 또는 동작은 자동적일 수 있다. 이러한 외력이 프로세스 또는 동작이 어떻게 수행될지에 영향을 미친다면 사람의 외력은 물질적인 것으로 간주된다. 프로세스 또는 동작의 수행에 일치하는 사람의 외력은 "물질적인" 것으로 간주되지 않는다.

본 명세서에 이용된 바와 같이, 용어들 "판정하다", "계산하다" 및 "컴퓨팅하다", 및 이것의 변형은 상호 교환 가능하게 이용되고 임의의 타입의 방법론, 프로세스, 수학적 동작 또는 기술을 포함한다.

용어 "모듈(module)"은 임의의 공지된 또는 이후에 개발되는 하드웨어, 소프트웨어, 펌웨어, 인공 지능, 퍼지(fuzzy) 논리, 또는 요소와 연관되는 기능성을 수행할 수 있는 하드웨어와 소프트웨어의 조합을 언급한다. 또한, 다양한 개념들을 전형적인 실시형태들의 관점에서 설명하는 동안, 양태들이 개별적으로 청구될 수 있다는 것을 인식하여야 한다.

이하에, "통신에서의"는 2개 이상의 시스템들, 구성 요소들, 모듈들, 디바이스들, 등이 임의의 프로토콜 또는 형식을 이용한 데이터, 신호들, 또는 다른 정보를 교환하는 것을 허용하는 무선이든, 또는 유선이든 임의의 전기 접속을 의미할 것이다.

전술한 것은 실시형태들의 몇몇 양태들의 이해를 제공하기 위한 간략화된 요약이다. 상기 요약은 다양한 실시형태들의 광범위한 그리고 완전한 개관이 아니다. 이것은 중요한 또는 결정적인 요소들을 확인하고 실시형태들의 범주를 기술하도록 의도되지 않고 하기에 제공되는 보다 상세한 설명으로의 도입으로서 간략화된 형태로 선택된 개념들을 제공하도록 의도된다. 인식될 것인 바와 같이, 다른 실시형태들은 전술한 또는 하기에 상세히 설명하는 하나 이상의 특질들을 단독으로 또는 조합으로 활용하는 가능한 것이다.

본 명세서를 첨부된 도면들과 함께 설명한다.

도 1A-1C는 UA들간의 통신 세션을 전환하기 위한 시스템의 실시형태들의 블록도들이며;
도 2는 사용자 연관 요소의 실시형태의 블록도이며;
도 3A 및 3B는 통신 세션의 전환에 영향을 미칠 수 있는 데이터 패킷(packet)의 실시형태들의 논리 블록도들이며;
도 4A 및 4B는 UA들간의 통신 세션을 전환하기 위한 프로세스의 실시형태의 흐름도이며;
도 5는 컴퓨팅 환경의 실시형태의 블록도이고;
도 6은 컴퓨터의 실시형태의 블록도이다.

첨부된 도면들에 있어서, 유사한 구성 요소들 및/또는 특질들은 동일한 참조 레이블(label)을 가질 수 있다. 또한, 동일한 타입의 다양한 구성 요소들이 유사한 구성 요소들 중에서 구별하는 문자를 뒤따르는 참조 레이블에 의해 구별될 수 있다. 제 1 참조 레이블만이 명세서에서 이용된다면, 설명은 제 2 참조 레이블과 관계없이 동일한 제 1 참조 레이블을 갖는 유사한 구성 요소들 중 임의의 하나에 적용 가능하다.

하기의 설명은 단지 실시형태들을 제공하고, 실시형태들의 범주, 적용 가능성, 또는 구성을 한정하도록 의도되지 않는다. 오히려, 하기의 설명은 당업자에게 실시형태들을 구현하는데 가능하게 하는 설명을 제공할 것이다. 다양한 변경들이 첨부된 청구항들에서 진술하는 바에 따라 실시형태들의 정신 및 범주로부터 벗어남이 없이 요소들의 기능 또는 배열에 행해질 수 있다.

호 환경(100)을 도 1A 내지 1C에 나타낸다. 호 환경(100)은 서로 통신하는 하나 이상의 구성 요소들을 포함할 수 있다. 실시형태들에 있어서, 호 환경(100)은 통신 세션 동안 서로 통신하는 적어도 2개의 UA들(102a, 102b, 및/또는 102c)을 포함한다. 통신 세션은 임의의 타입의 매체 또는 매체의 조합에서의 실시간 또는 근 실시간 통신들의 음성 호, 영상 호, 또는 다른 교환을 포함할 수 있다. 통신 세션들은 모두 네트워크(104)로 나타낸 광역 네트워크(WAN), 로컬 영역 네트워크(LAN), 또는 다른 시스템과 같은 임의의 네트워크(104) 또는 시스템에 걸쳐 실시될 수 있다. 실시형태들에 있어서, 통신 세션은 디지털 전송들을 이용하여 실시되고 여기서 디지털 전송들의 적어도 몇몇은 호를 실행하거나 수립하기 위한 제어 신호들이다. 제어 신호들은 하나 이상의 프로토콜들, 예컨대 SIP하에서 전송될 수 있다.

호 환경(100)은 2개 이상의 UA들(102a, 102b, 및/또는 102c)을 포함할 수 있다. 통신 세션이 생성된 경우, UA들(102a, 102b, 및 102c)은 선호도에 따라 통신 세션에 포함되는 애플리케이션들을 가질 수 있다. 애플리케이션들은 UA들(102a, 102b, 및/또는 102c)간의 통신 경로에서 B2BUA들(106 또는 108)에 의해 실행되는 구체적 호 특성들을 포함할 수 있다. 애플리케이션들은 호 관리자를 또한 포함할 수 있으며, 이것은 통신 세션을 수립하는 것 그리고 통신 세션으로의 포함을 위하여 애플리케이션들을 시퀀스화하는 것에 기능성을 제공할 수 있다. B2BUA(106/108)는 UA(102)의 사용자를 위한 기능 또는 특성을 실시하도록 동작 가능한 애플리케이션 또는 소프트웨어 모듈일 수 있다. 예컨대, B2BUA(106/108)는 통신 세션의 매체를 기록하는 것, 통신 세션으로부터 메타데이터(metadata)를 추출하는 것, 또는 다른 기능들과 같은 기능들을 완료할 수 있다. B2BUA들(106/108)은 통신 세션의 통신 경로에 의해 시퀀스로 그리고 인라인(in-line)으로 불러오게 되거나 수립되도록 동작 가능하다. 따라서, 통신 세션이 생성된 경우, 사용자 연관 요소(110)는 B2BUA들(106 및 108)의 인스턴스들을 시퀀스로 불러오거나 인스턴스화할 수 있어 다른 UA(102)로부터 수신된 임의의 통신 데이터가 그 UA의 B2BUA들(106/108)을 통해 전송되거나 라우팅된다. 따라서, 모든 B2BUA들(106/108)은 통신 세션의 시그널링 경로에서 인라인이고 백-투-백이다.

사용자 연관 요소(110)는 서버상의 프로세서에 의해 실행되는 소프트웨어 기능일 수 있다. 실시형태들에 있어서, 사용자 연관 요소(110)는 인터넷 프로토콜(IP) 멀티미디어 서브시스템(subsystem)(IMS) 서빙-콜(serving-call) 세션 제어 기능(S-CSCF)/ 스마트(smart) 공통 입력 방법(SCIM) 기능일 수 있다. 사용자 연관 요소(110)는 하나 이상의 UA들(102) 중에서 그리고 하나 이상의 UA들(102)에 대해 통신 세션들을 수립하고 실시하도록 동작 가능하다. 예컨대, 사용자 연관 요소 1(110a)은 UA 1(102a)에 대한 통신 세션들을 수립하고 실시할 수 있다. 마찬가지로, 사용자 연관 요소 2(110b)는 UA 2(102b)에 대한 통신 세션들을 수립하고 실시할 수 있다. 대안의 실시형태들에 있어서, 사용자 연관 요소 1(110a) 및 사용자 연관 요소 2(110b)는 사용자 연관 요소(110)의 동일한 인스턴스이고 양 UA들(102)에 대해 통신 세션을 실시할 수 있다. 사용자 연관 요소(110)는 B2BUA들(106/108)을 수립하고 통신 세션에 관련된 UA들(102)간의 B2BUA들(106/108)의 시퀀스를 접속함으로써 통신 세션들을 제어하고 실시하도록 동작 가능하다

도 1A에서, UA 1(102a)가 UA 2(102b)와 통신 세션을 수립하였다. 이에 따라, B2BUA 1a(106a); B2BUA 2a(108a)가 UA 1(102a)에 대해 시퀀스화되었다. 도 1A에서 볼 수 있는 바와 같이, B2BUA들은 인라인이고 네트워크(104)와 UA 1(102a) 사이에 시퀀스로 접속된다. 마찬가지로, B2BUA 3a(106c); B2BUA 4a(108c)는 사용자 연관 요소 2(110b)에 의해 UA 2(102b)에 대해 인라인으로 그리고 시퀀스로 불러오게 되고 수립되었다. 도 1A에 나타낸 통신 세션은 UA 1(102a)과 UA 2(102b) 사이의 포인트 대 포인트(point-to-point) 통신 세션을 나타낸다.

UA 1(102a)은, 도 1A에 나타낸 바와 같이, UA 2(102b)와 제 1 통신 세션의 수립을 개시할 수 있거나 UA 2(102b)가 개시 UA가 될 수 있다. 도 1B에서, UA 1(102a)은 UA 3(102c)과 제 2 통신 세션을 수립한다. 한번 더, UA 1(102a) 또는 UA 3(102c) 중 하나는 개시 UA에 부합할 수 있다. 묘사된 실시예에 있어서, B2BUA들(108b 및 106b)의 신규의 인스턴스화들이 UA 1(102a)에 대해 생성된다. 물론, 신규의 B2BUA들(106b 및 108b)을 수반하는 것보다는 오히려 제 2 통신 세션에 대해 B2BUA 1a(106a) 및/또는 B2BUA 2a(108a)를 활용하는 것이 또한 가능할 수 있다. 본 명세서에서 설명한 임의의 통신 세션에 수반된 모든 UA들이 동일한 사용자 연관 요소(110) 및 가능하게는, 동일한 B2BUA들에 의해 서빙될 수 있다는 것이 또한 가능할 수 있다.

통신 세션의 대향하는 측상에서, 사용자 연관 요소 3(110c)는 UA 3(102c)에 대해 B2BUA 5a(106d) 및 B2BUA 6a(108d)를 수립한다. 따라서, 도 1B에 나타낸 바와 같이, UA 1(102a)은 UA 2(102b)에 의한 하나 그리고 UA 3(102c)에 의한 하나인, 2개의 통신 세션들에 동시에 수반된다.

이제 도 1C를 언급하면, UA 1(102a)은 전환을 완료하였고, 이로써 UA 2(102b)와 UA 3(102c) 사이에 제 3 통신 세션을 수립한다. 제 3 통신 세션에 있어서, UA 1(102a)은 제 1 및 제 2 통신 세션들 양자를 중단하였고 UA 2(102b) 및 UA 3(102c)을 수반하는 제 3 통신 세션은 UA들이 포인트 대 포인트 그리고 직접 통신으로 배치되는 것을 야기한다. 제 3 통신 세션의 수립은 다수의 방법들로 완료될 수 있다. 하기에 설명할 실시예에 있어서, 제 3 통신 세션의 수립은 전환하는 엔티티로서 작용하는 UA 1(102a), 전환되는 엔티티로서 작용하는 UA 2(102b), 그리고 UA 1(102a)에 의해 전환의 타겟으로서 작용하는 UA 3(102c)에 의해 발생한다. 그러나, UA 2(102b)가 실제로 전환의 타겟일 수 있고 UA 3(102c)가 전환된 엔티티일 수 있다는 것을 인식해야 한다. 이들 다른 통신 세션들이 어떻게 수립되는지 그리고 엔티티들이 어떻게 전환되는지의 단계들 및 고유성을 도 4A 및 4B와 함께 논의한다.

사용자 연관 요소(110)의 실시형태를 도 2에 나타낸다. 사용자 연관 요소(110)는 UA들(102)에 대한 통신 세션들을 수립하고 관리하도록 동작 가능한 임의의 타입의 하드웨어 및/또는 소프트웨어일 수 있다. 실시형태들에 있어서, 사용자 연관 요소(110)는 하나 이상의 소프트웨어 모듈들을 포함한다. 이들 소프트웨어 모듈들은 GRUU 삽입 모듈(202), GRUU 해석 모듈(204), 엔드포인트 뷰 삽입 모듈(206), 및/또는 엔드포인트 뷰 해석 모듈(208)을 포함할 수 있다. GRUU 삽입 모듈(202)은 메세지 또는 이전의 메세지들의 타입과 같은 소정의 트리거(trigger)들에 의존하여 SIP 메세지로 GRUU 또는 AOR을 삽입하도록 동작 가능하다. 예컨대, 메세지가 하나의 발신자로부터 다른 자로의 전환이면, GRUU 삽입 모듈(202)은 도 3A에 설명하는 바와 같이, 호의 전환에 영향을 미치도록 적절한 메세지에 GRUU 또는 AOR을 삽입할 수 있다. 따라서, GRUU 삽입 모듈(202)은 메세지 또는 다른 정보의 타입에 기반하여 SIP 메세지들을 변경하도록 동작 가능하다.

GRUU 해석 모듈(204)은 메세지 또는 다른 정보의 타입을 해석하고 하나 이상의 SIP 메세지들을 변경하도록 GRUU 삽입 모듈(202)에 명령들을 내릴 수 있다. 따라서, GRUU 해석 모듈(204)은 일정한 메세지들, 예컨대 SIP INVITE 메세지를 검색하고 전환에 영향을 미치기 위해 INVITE 메세지에서의 또는 이후의 메세지에서의 정보를 변경하도록 GRUU 삽입 모듈(202)에 명령할 수 있다. GRUU 해석 모듈(204)은 도 4A 및 4B와 함께 설명하는 바와 같이 호 전환에 영향을 미치도록 사용자 연관 요소(110)에 스캐닝(scanning) 능력을 제공한다.

또한, GRUU 해석 모듈(204)은 INVITE 메세지들을 수신할 수 있고, 여기서 INVITE 메세지들은 로컬 사용자 연관 요소(110)와 관련되지 않는 UA(102)를 위한 것이다. 그러나, INVITE 메세지는 로컬 UA와 다른 UA 사이의 통신 경로로 B2BUA(106, 108)에 전송될 수 있다. GRUU 해석 모듈(204)은 B2BUA를 언래블링한 것을 의미하도록 이들 수신된 INVITE 메세지를 해석할 수 있다. 따라서, GRUU 해석 모듈(204)은 도 4A 및 4B와 함께 설명하는 바와 같이, 통신 경로를 분해하거나 언래블링하기 위해 사용자 연관 요소(110)에 언래블링하는 능력을 제공한다.

엔드포인트 뷰(epv) 삽입 모듈(206)은 SIP 메세지들과 같은 임의의 메시지의 엔드포인트 뷰 헤더에 AOR-기반 GRUU를 삽입하도록 동작 가능하다. 예컨대, 메세지가 하나의 발신자로부터 다른 자로의 전환이면, 도 3A에 설명한 바와 같이, epv 삽입 모듈(206)은 적절한 메세지에 AOR-기반 GRUU를 삽입할 수 있다. 따라서, epv 삽입 모듈(206)은 메세지 또는 다른 정보의 타입에 기반하여 SIP 메세지들을 변경하도록 동작 가능하다.

epv 해석 모듈(208)은 메세지 또는 다른 정보의 타입을 해석하고 하나 이상의 SIP 메세지들을 변경하도록 epv 삽입 모듈(206)에 명령들을 내릴 수 있다. 따라서, epv 해석 모듈(208)은 일정한 메세지들, 예컨대 SIP INVITE 메세지를 검색하고 전환에 영향을 미치기 위해 INVITE 메세지에서의 또는 이후의 메세지에서의 정보를 변경하도록 epv 삽입 모듈(206)에 명령할 수 있다. epv 해석 모듈(208)은 도 4A 및 4B와 함께 설명하는 바와 같이 호 전환에 영향을 미치도록 사용자 연관 요소(110)에 스캐닝 능력을 제공한다.

SIP 메세지(300)의 실시형태들을, 호 환경(100)에서의 다른 통신 세션들을 실시하는데 이용되는 바와 같이, 도 3A 및 3B에 나타낸다. SIP 메세지들(300)은 필드들 또는 다른 메세지 구성 요소들일 수 있는 하나 이상의 부분들을 포함할 수 있다. SIP 메세지(300)는, 생략 부호들(314)에 의해 나타낸 바와 같이, 도 3A에 나타낸 것들보다 더 많은 또는 더 적은 필드들을 포함할 수 있다. 실시형태들에 있어서, 메세지(300)의 부분들은 요청-URI(R-URI)[전환 타겟으로서 원거리 말단 엔드포인트를 식별하는 URI일 수 있는 그리고 다이얼로그 식별자, 맵-URI, 등을 또한 포함할 수 있는 방법, 타겟, epv 중 하나 이상을 포함할 수 있는](302), 투 필드(304), 프롬 필드(306), 호 식별자 필드(308), 콘택트 필드(310), 및 엔드포인트 뷰 필드(312)를 포함할 수 있다. 이들 필드들을 이하에 보다 상세히 설명할 것이다.

SIP 메세지(300)의 제 1 부분(302)[이하에 R-URI 필드(302)로 언급됨]은 SIP 방법을 갖는 요청 라인 및 요청-URI를 포함할 수 있다. SIP 방법은 INVITE 커맨드(command), REFER 메세지, ACK 메세지, 또는 다른 타입들의 SIP 메세지들을 포함할 수 있다. 방법은 많은 SIP 메세지들의 메세지 타입을 나타내고, 누구에게 커맨드가 보내질 지와 같은, 커맨드 또는 메세지에 필요로 되는 임의의 다른 데이터를 포함할 수 있다. 200 OK 응답 메세지를 본 명세서에 또한 설명한다. 실시형태들에 있어서, INVITE-리플레이스 메세지는, R-URI 필드(302)에서, 메세지가 타겟이 된 파티에 대한 정보를 요청자 URI에 제공하는 엔드포인트-뷰(epv) 파라미터를 포함할 수 있다. 메세지(300)의 R-URI 필드(302)는 그것의 또는 다른 메세지의 R-URI 필드(302)에서의 인바이티(invitee)를 조정할지 또는 다른 지정을 조정할지 여부를 판정하도록 GRUU 해석 모듈(204)에 의해 해석된다. 이러한 메세지의 예를 하기에 나타낸다:

상술한 바와 같이, “INVITEsip:Called-User@appW; epv=“<sip:Called-User@Avaya;gr=1234”를 포함하는 메세지의 부분은 R-URI 필드(302)이다. 나타낸 바와 같이, 방법은 “INVITE”이다. 타겟은 “Called-User@appW”이다. epv 파라미터는 “<sip:Called-User@Avaya;gr=1234>”이다. 다이얼로그 식별자는 “Call-ID: AW”이다. 이들 필드들이 어떻게 통신 프로세싱에서 이용되는지는 도 4A-4B와 함께 보다 상세히 설명한다.

본 명세서의 상기 SIP 메세지의 예시적인 실시예뿐만 아니라 SIP 메세지들의 다른 실시예들이 'epv' 파라미터를 큰 따옴표에 있는 것으로서 나타낸다는 것을 주목해야 한다. 그러나, 임의의 타입의 SIP 메세지 형식이 본 명세서의 범주로부터 벗어남이 없이 가능하다는 것이 인식된다. 예컨대, 몇몇 SIP 메세지들에 있어서, 'epv' 파라미터는 RFC 3261에 따라 %16진숫자를 이용하여 벗어나게 될 수 있다. 본 명세서에 나타낸 큰 따옴표는 논의 및 예시적인 목적들을 위해 메세지의 읽기 쉬움을 유지하는데 이용된다.

투 필드(304)는 메세지(300)를 위한 어드레스에 대한 정보를 저장할 수 있다. 투 필드(304)는 사람이나 엔티티의 이름, 어드레스, 또는 어떤 엔티티로 메세지(300)가 전송되고 있는지를 식별하는 몇몇 다른 정보를 포함할 수 있다. 실시형태들에 있어서, 투 필드(304)는 메세지(300)의 수신지에 대한 기록의 어드레스를 포함할 수 있다. 마찬가지로, 프롬 필드(306)는 메세지(300)를 전송해온 엔티티에 대한 정보를 포함할 수 있다. 프롬 필드(306)는 메세지(300)를 전송했던 시스템 또는 사람에 대한 다른 정보 또는 기록의 어드레스를 포함할 수 있다. 투 필드(304) 및 프롬 필드(306)는 통신에 대한 다이얼로그 식별자를 투 필드 및/또는 프롬 필드에서의 호 식별자와 함께 구비하는 태그들을 또한 포함할 수 있다.

호 식별자 필드(308)는, 명칭이 제시하는 바와 같이, 통신에 수반된 하나의 또는 양자의 파티 또는 통신 세션에 수반된 파티들에 의해 이용되는 디바이스를 식별하는 정보를 포함할 수 있다. 몇몇 실시형태들에 있어서, 호 식별자 필드(308)는 통신 세션을 실시하는 2개 이상의 파티들에 대한 정보 또는 호를 고유하게 식별하는 다른 정보를 포함할 수 있다. 실시형태들에 있어서, 호 식별자(308)는 모든 다른 통신 세션들에 대하여 고유하게 통신 세션을 식별하는 정보를 포함할 수 있다. 따라서, 호 식별자(308)는 호에 대해 전역 고유 식별자(GUID) 또는 몇몇 다른 숫자로 된, 알파벳으로 된, 알파벳과 숫자로 된 식별자를 포함할 수 있다.

콘택트 필드(310)는 통신 세션을 설명하는 정보를 포함할 수 있다. 예컨대, 콘택트 필드(310)는 전송, 포트 어드레스, 또는 통신 세션과 관련된 다른 정보의 타입에 대한 정보를 포함할 수 있다. 콘택트 필드(310)는 메세지에 대한 전송 디바이스의 아이덴티티를 판정하는데 이용될 수 있다.

엔드포인트 뷰 필드(312)는 본 명세서에 설명한 실시형태들에 신규로 추가된 필드이다. 엔드포인트 뷰 필드(312)는 세션의 UA의 로컬 뷰에 관하여 정보를 저장할 수 있다. 엔드포인트 뷰 헤더(312)는 메세지의 초기 전송자의 고유 식별자(예컨대, AOR-기반 GRUU 또는 그 동등물)를 포함할 수 있어, 이러한 정보는 콘택트 URI에서의 epv 파라미터에 이주될 수 있다. 예컨대, 도 1B에서, 엔드포인트 뷰 필드(312)는 UA(102b)를 통해 엔드포인트(102a)의 GRUU를 이송하는데 이용된다(그것이 UA로 전송되기 바로 전에 그것이 콘택트 URI에서의 epv 파라미터에 이주됨).

epv 필드(312)에 대한 정보(316)는 도 3B에 나타낸 바와 같다. epv 정보(316)는 생략 부호(324)에 의해 나타낸 바와 같이 도 3B에 나타낸 것들보다 더 많은 또는 더 적은 필드를 포함할 수 있다. epv 필드(312)는 AOR/GRUU(318), 로컬 태그/원격 태그(320), 및/또는 호 식별자(322)를 포함할 수 있다. AOR/GRUU(318)는 UA들(102a/b/c)에 대해 식별 및 어드레싱 정보와 같은 정보를 포함할 수 있다. 이들 UA들(102a/b/c)은 하나 이상의 통신 세션들에 포함될 수 있다. 따라서, AOR/GRUU(318)는, 도 4A 내지 4C와 함께 설명하는 바와 같이, 호가 셋업(set-up)되는 것을 허용하는 전환에 대한 정보를 제공한다. 호 식별자(322)는 도 3A와 함께 설명한 호 식별자(308)와 동일하거나 유사할 수 있다. 로컬 태그/원격 태그(320)의 로컬 태그 부분은 구체적 세션에 대한 로컬 B2BUA에 의해 생성되는 세미-랜덤(semi-random), 세미-고유 식별자를 포함할 수 있다. 로컬 태그/원격 태그(320)의 원격 태그 부분은 구체적 호에 대한 원격 B2BUA에 의해 생성되는 세미-랜덤(semi-random), 세미-고유 식별자를 포함할 수 있다. epv 필드(312)는 커맨드 필드(302)에서의 커맨드 인바이티 또는 투 필드(304)에서 지정된 엔티티가 언제 변경되게 될지를 식별하기 위해 GRUU 해석 모듈(204)에 의해 이용될 수 있고, GRUU 삽입 모듈(202)은 epv 필드(312)로부터 투 필드(304) 또는 커맨드 필드(302)로 AOR/GRUU를 삽입할 수 있다.

호 전환을 실시하기 위한 방법을 도 4A 및 4B에 나타낸다. 방법(400)의 단계들에 대한 일반적인 순서를 도 4A 및 4B에 나타낸 반면에, 단계들이 그것들을 설명하고 묘사한 순서로 정확하게 수행될 필요가 없다는 것을 실시형태들이 숙고한다는 것이 인식되어야 한다. 일반적으로 방법(400)은 개시 동작과 함께 개시하고 종료 동작과 함께 종료한다. 방법(400)은 도 4A 및 4B에 나타낸 것들과는 달리 더 많은 또는 더 적은 단계들을 포함할 수 있고 단계들의 순서를 배열할 수 있다. 방법(400)은 컴퓨터 시스템에 의해 실행되는 컴퓨터-실행 가능 명령들의 세트로서 실행되고 컴퓨터 판독 가능 매체상에 인코딩(incoding)되거나 저장될 수 있다. 이하에, 방법(400)을 도 1-3과 함께 설명한 시스템들, 구성 요소들, 모듈들, 소프트웨어, 데이터 구조체들, 사용자 인터페이스(interface)들, 등을 참조하여 설명할 것이다.

UA 1(102a)은, 단계(402)에서, UA 2(102b)와 함께 호를 수립하는 것을 개시하기 위해 사용자 연관 요소 1(110a)에 SIP INVITE를 전송한다. INVITE 메세지의 실시예를 하기와 같이 볼 수 있다[여기서 “Alice”는 동작하는 UA 1(102a)이고, “Bob”은 동작하는 UA 2(102b)임]:

상기 시점에서, Alice에 대해 권위있는 사용자 연관 요소(110a)는 B2BUA들(106a 및 108a)을 불러오거나 시퀀스화하는 것을 개시할 수 있다. 따라서, 사용자 연관 요소(110a)는 B2BUA 1a(106a)로 INVITE 메세지[단계 (402)에서 전송된 고유 INVITE 메세지의 수정된 버전에 부합하는]를 전송함으로써 B2BUA 1a(106a)를 개시한다. 사용자 연관 요소 1(110a)로부터 B2BUA 1a(106a)로 전송된 INVITE 메세지의 실시예는 하기와 같이 보여지도록 수정될 수 있다:

여기서, 메세지는 UA 2(102b)를 초청하기 위해 B2BUA 1a(106a)로 보내지고 epv 헤더는 Alice-“Endpoint-View: <sip:Alice@Avaya;gr=1234>; localtag=A;call-id=AW”의 엔드포인트 뷰에 대한 정보를 포함한다. epv 헤더는 UA 1(102a)에 대한 GRUU 및 다이얼로그 식별자 “call-id=AW”를 포함한다.

B2BUA 1a(106a)는 사용자 연관 요소 1(110a)로 INVITE 메세지를 리턴한다. 그 후, 추가의 애플리케이션들이 Alice를 대신하여 시퀀스화될 필요가 있으면, 사용자 연관 요소 1(110a)은 이들 추가의 애플리케이션들[예컨대, B2BUA 2a(108a)]로 INVITE 메세지를 전송한다. B2BUA 2a(108a)가 INVITE 메세지를 프로세싱하고 그것의 지정된 기능들을 실행한 후, B2BUA 2a(108a)는 사용자 연관 요소 1(110a)로 INVITE 메세지를 리턴한다. B2BUA 2a(108a)로부터 INVITE 메세지를 되수신할 때, 사용자 연관 요소 1(110a)은 어떤 추가의 애플리케이션들도 Alice에 대해 시퀀스화될 필요가 없다고 판정할 수 있고 상기 판정에 기반하여 단계(404)에서 사용자 연관 요소(110b)로 INVITE 메세지를 전송한다.

사용자 연관 요소 2(110b)는 UA 2(102b)와 관련된 사용자(예컨대, Bob)에 대해 B2BUA들(106c/108c)을 시퀀스화한다. 애플리케이션들이 시퀀스화되는 방식 및 순서는 Bob에 의해 또는 디폴트(default)/관리자 선호도에 의해 한정된 선호도에 의존할 수 있다. 몇몇 실시형태들에 있어서, 사용자 연관 요소 2(110b)는 B2BUA 3a(106c)로 INVITE 메세지를 전송하고, B2BUA 3a(106c)로부터 INVITE 메세지를 되수신하고, 그 후 B2BUA 4a(108c)로 INVITE 메세지를 전송함으로써 B2BUA 3a(106c)를 시퀀스화한다. B2BUA 4a(108c)가 INVITE 메세지를 프로세싱하는 것을 완료한 후에, 사용자 연관 요소 2(110b)는 B2BUA 4a(108c)로부터 INVITE 메세지를 되수신하고 그 후 단계(406)에서, 착신 파티와 관련된 UA[예컨대, UA 2(102b)]로 INVITE 메세지를 전송한다.

UA 2(102b)로 전송되는 실시예 INVITE 메세지를 하기와 같이 나타낼 수 있다:

여기서, “AppX”는 착신 파티(예컨대, Bob)에 대한 시퀀스화된 애플리케이션들의 세트에서의 마지막 B2BUA 4a(108c)일 수 있다. epv 헤더가 사용자 연관 요소들(110)에 의해 시퀀스화하는 동안 내내 유지되었고 epv 헤더 내에 포함되는 정보는 UA 2(102b)로 전송된다는 것을 주목해야 한다. 그러나, UA 2(102b)로의 INVITE를 제공하는 것 이전에, 사용자 연관 요소 2(110b)는 메세지 라우팅 동안 epv 헤더에서 유지되었던 정보를 INVITE 메세지의 콘택트 URI에서의 파라미터로 삽입할 수 있다. 따라서, 사용자 연관 요소(110)는 콘택트 URI, 호-ID, 투, 및 프롬 태그들을 수정할 수 있는 반면에 사용자 연관 요소 1(110a)에 의해 본래 생성되었던 epv 헤더를 유지할 수 있다.

UA 2(102b)는 단계(408)에서, 사용자 연관 요소 2(100b)로 200 OK 메세지를 전송함으로써 INVITE 요청의 수신을 수락할 수 있다. 사용자 연관 요소 2(110b)는 B2BUA 4a(108c) 및 B2BUA 3a(106c)를 통해 200 OK 메세지를 라우팅하고 그 후 단계 410에서 사용자 연관 요소 1(110a)로 그것을 전송한다. 응답 메세지의 실시예는 하기와 같이 나타난다:

여기서, UA 2(102b)의 엔드포인트 뷰은 epv 헤더에 포함되며, 이것은 UA 1(102a)로의 시퀀스화 및 전송을 통해 변경되지 않은 대로 남을 수 있다.

사용자 연관 요소 1(110a)는 B2BUA 2a(108a) 및 B2BUA 1a(106a)를 통해 200 OK 메세지를 라우팅한다. 결국, 사용자 연관 요소 1(110a)는 200 OK 메세지를 수신하고 단계(412)에서 UA 1(102a)로 200 OK 메세지를 보낸다. 실시형태들에 있어서, epv 파라미터는 UA 1(102a)로 메세지를 제공하는 것 이전에 200 OK 메세지의 콘택트 헤더에 사용자 연관 요소 1(110a)에 의해 삽입된다. 일련의 SIP ACK 메세지는 그 후 SIP INVITE 메세지들과 마찬가지의 방식으로 UA 1(102a)로부터 UA 2(102b)로 전송될 수 있다. 상기 시점에서, 도 1A에 나타낸 바와 같이, 제 1 통신 세션이 UA 1(102a)과 UA 2(102b) 사이에 생성된다.

그 후에 어느 시점에서 UA 1(102a)의 사용자(예컨대, Alice)는 UA 2(102b)를 UA 3(102c)로 전환하는 것을 판정할 수 있다. 이것은 Alice가 UA 3(102c)의 사용자(예컨대, “Carol”)로부터 호를 수신하거나 Alice가 UA 3(102c)의 사용자에게 호를 개시한 후에 발생할 수 있다. 전환을 완수하기 위하여, UA 1(102a)은 UA 2(102b)를 소프트하게 보류한다. UA 1(102a)로부터 UA 2(102b)로의 홀드(hold) 메세지의 라우팅은 홀드 메세지가 인-다이얼로그(in-dialog) 메세지로서 콘택트/기록-라우트 헤더들을 추종하는 상술한 INVITE 메세지/200 OK 메세지/ACK 메세지의 것과 마찬가지의 절차를 추종한다. 홀드 메세지의 라우팅은 이하에 설명하지 않을 것이다. 제 1 통신 세션이 보류되는 동안, UA 1(102a)은 UA 3(102c)과 신규의 통신 세션(예컨대, 제 2 통신 세션)을 수립한다. 제 2 통신 세션은 Alice 또는 Carol에 의해 개시될 수 있다. Alice에 의해 개시된 제 2 통신 세션을 수립하기 위한 메세지의 실시예를 하기와 같이 나타낼 수 있다:

이에 따라, 사용자 연관 요소(110a 및 110c)는 B2BUA들(106b, 108b, 106d, 및 108d)을 실행하거나 인스턴스화한다. 제 2 통신 세션을 수립하기 위한 절차는 단계(414)에서, UA 1(102a)로부터 사용자 연관 요소 1(110a)로 INVITE 메세지를 전송하는 것을 포함한다. 사용자 연관 요소 1(110a)은 그 후 B2BUA들(106b 및 108b)을 시퀀스화한다. 그 후, 사용자 연관 요소 1(110a)은 단계(416)에서, 사용자 연관 요소 3(110c)으로 INVITE 메세지를 전송한다. INVITE 메세지를 수신하는 것에 응답하여, 사용자 연관 요소 3(110c)은 UA 3(102c)의 사용자(예컨대, Carol)에 의해 또는 UA 3(102c)의 사용자에 대해 한정된 선호도를 시퀀스화하는 애플리케이션에 따라 B2BUA들(106d 및 108d)을 시퀀스화할 수 있다. 적절한 애플리케이션들이 B2BUA들로서 한 번 시퀀스화되면, INVITE 메세지는 단계(418)에서, 사용자 연관 요소 3(110c)로부터 UA 3(102c)로 보내진다. UA 3(102c)로 전송된 INVITE 메세지의 실시예를 하기와 같이 나타낼 수 있다:

실시예 메세지로부터 볼 수 있는 바와 같이, epv 파라미터는 UA 1(102a)에 대해 엔드포인트 뷰에 대한 정보를 포함한다. UA 3(102c)은 그 후 단계(420)에서, 사용자 연관 요소 3(110c)으로 200 OK 메세지를 되전송한다. 사용자 연관 요소 3(110c)은 그 후 B2BUA들(108d 및 106d)을 통해 200 OK 메세지를 라우팅하고 단계(422)에서 사용자 연관 요소 1(110a)로 그것을 전송한다. 단계(424)에서, 사용자 연관 요소 1(110a)은 그 후에 B2BUA들(108b 및 106b)을 통하여 UA 1(102a)로, epv 파라미터와 함께, 200 OK 메세지를 전송한다. 일련의 SIP ACK 메세지들은 그 후, 마찬가지의 방식으로, UA 1(102a)로부터 사용자 연관 요소 1(110a)로, 그 후 사용자 연관 요소 3(110c)으로, 그리고 그 후 UA 3(102c)으로 되전송할 수 있다. 이때, 제 2 통신 세션은 수립된다. 제 2 통신 세션을 수립한 후, 통신 환경(100)의 구성은 도 1B에 나타낸 바와 같다. 이하에 UA 1(102a)은 Bob 대 Carol의 전환에 영향을 미칠 REFER 메세지를 전송할 수 있다.

전환 프로세스는 UA 1(102a)이 UA 2(102b)로 향하는 REFER 메세지를 전송할 때 개시한다. REFER 메세지는 단계(426)에서, 우선 사용자 연관 요소 1(110a)로 전송된다. REFER 메세지의 실시예를 하기와 같이 나타낼 수 있다:

REFER 메세지는 도 3A 및 3B에 나타낸 메세지들과 마찬가지일 수 있다. REFER 메세지는 전환 타겟[예컨대, UA 3(102c)]에 대한 정보를 제공하는 epv 파라미터를 포함하는 REFER-To 헤더, 예컨대 “Refer-To:Carol <sip:AppY@appyIP; epv=“<sip:Carol@Avaya;gr=9012>; localtag=C;remotetag=Z;call-id=ZC”; Replaces=AW>,”를 포함할 수 있다. 이러한 정보는 REFER 메세지가 메세지의 수신지에 도달할 때까지 REFER 메세지에 보존된다.

사용자 연관 요소 1 및 2(110a 및 110b)는 호 구조체가 도 1B에 나타낸 것으로부터 도 1C에 나타낸 것으로 변경할 것들을 통지하기 위해 제 1 통신 세션에 관련된 모든 시퀀스화된 B2BUA들(106/108)을 통해 REFER 메세지를 전송한다. 사용자 연관 요소 1(110a)은 단계(428)에서, B2BUA 1a(106a), B2BUA 2a(108a)을 통해 그리고 사용자 연관 요소 2(110b)로 이 REFER 메세지를 라우팅한다. 사용자 연관 요소 2(110b)는 단계(430)에서, B2BUA 3a(106c), B2BUA 4a(108c)로, 그리고 그 후 UA 2(102b)로 REFER 메세지를 전송한다. UA 2(102b)에 의해 수신된 REFER 메세지는 하기와 같이 나타낼 수 있다:

제 3 통신 세션에 UA 3(102c)을 관여시키기 위해, UA 2(102b)는 Refer-To 헤더로부터 다이얼로그 식별자, 예컨대 “Replaces=AY”를 포함하는 리플레이스 헤더와 함께 INVITE 메세지를 전송한다. UA 2(102b)에 의해 전송되는 INVITE 메세지의 실시예를 하기와 같이 나타낼 수 있다:

INVITE 메세지에서의 요청 URI는 B2BUA 1b(106b)에서, 예컨대 “sip:AppY@appyIP”에서 타겟이 되지만 epv 파라미터는 UA 3(102c)의 AOR/GRUU, 예컨대 “epv=“<sip:Carol@Avaya;gr=9012>;localtag=C;remotetag=Z;call-id=ZC”>”를 포함한다. 따라서, INVITE 메세지는 그것이 UA 1(102a)에 매우 근접한 B2BUA 1b(106b)의 URI이기 때문에 통상적으로 B2BUA 1b(106b)를 통해 통신 세션을 다시 보낼 것이다. 그러나, 본 실시형태들에 있어서, INVITE 메세지는 단계(432)에서, UA 2(102b)로부터 사용자 연관 요소 2(110b)로 전송된다. 사용자 연관 요소 2(110b)는 이러한 INVITE 메세지를 수신하는 경우, 사용자 연관 요소 2(110b)가 INVITE 메세지의 기점 프로세싱을 엔터링하기 전에 또는 엔터링할 때 수개의 단계들을 완료한다. 우선, 사용자 연관 요소 2(110b)는 epv 정보가 INVITE 메세지에 실재하는지 여부를 판정한다. 실재하는 epv 정보가 있다면, 사용자 연관 요소 2(110b)는 “map-URI” 헤더 또는 파라미터에 현재의 R-URI를 저장한다. 또한, 사용자 연관 요소 2(110b)는 INVITE 메세지의 epv로부터 AOR/GRUU를 이용하고, 따라서 애플리케이션들은 INVITE 메세지가 누구에게로 향하는지를 이해한다. 이러한 프로세싱 동안 생성되는 메세지의 실시예는 하기와 같다:

여기서, 사용자 연관 요소 2(110b)가 메세지의 “map-URI=appY@appyIP; SIP/2.0 >” 부분을 생성하고 epv 헤더로부터 AOR/GRUU (Carol@Avaya;gr=9012)과 함께 R-URI를 이주시킨다는 것을 볼 수 있다. 사용자 연관 요소 2(110b)는 그 후 이러한 통신 경로에 대해 기점 애플리케이션들 B2BUA 3b(106e) 및 B2BUA 4b(108e)을 개시하며, 이것은 종료 애플리케이션들(106c 및 108c)과 다를 수 있다.

사용자 연관 요소 2(110b)는 그 후 맵-URI 필드로부터 R-URI를 재저장할 수 있다. 사용자 연관 요소 2(110b)는 그 후 하기에 나타낸 실시예의 언래블링 프로세스를 개시하기 위해, 단계(434)에서, 사용자 연관 요소 1(110a)로 신규로 변경된 INVITE 메세지를 보낸다:

사용자 연관 요소 1(110a)는 이제 언래블링을 위해 B2BUA 1b(106b) 및 B2BUA 2b(108b)를 통해 INVITE 메세지를 전송한다. 언래블링하는 동안, B2BUA들(106b 및 108b)은 리플레이스 다이얼로그 ID를 조사하고 R-URI 및 리플레이스 다이얼로그 ID를 그들의 “next-door neighbor”가 되도록 맵핑하는데 그 다이얼로그 ID를 이용한다. 예컨대, B2BUA(106b)가 INVITE를 언래블링한 후 그것을 하기에 도시된 바와 같이 나타낼 수 있다:

B2BUA 1b(106b), 및 B2BUA 2b(108b)를 언래블링한 후, 사용자 연관 요소 1(110a)는 단계(440)에서, 사용자 연관 요소 3(110c)로 INVITE를 전송할 수 있다. INVITE 메세지의 수신에 응답하여, 사용자 연관 요소 3(110c)는 그 후 B2BUA 5a(106d) 및 B2BUA 6a(108d)를 언래블링할 수 있다. 사용자 연관 요소들(110)은 언래블링 프로세스를 언제 중단할지를 또한 판정할 수 있다. 각 사용자 연관 요소(110)는 epv 헤더에서의 사용자의 디바이스(들)에 대해 등록된 콘택트 URI와 R-URI를 비교할 수 있다. 따라서, 사용자 연관 요소 3(110c)이 UA 3(102c)에 대해 부합한 것을 찾는 경우, 사용자 연관 요소 3(110c)은 그 후 용어 시퀀싱(예컨대, 상기 실시예에서는 Carol인 착신 파티에 대해 애플리케이션 시퀀싱)으로 진행할 수 있다.

언래블링으로부터 용어 시퀀싱으로 이동하는 경우, 사용자 연관 요소 3(110c)는 일부 URI 맵핑을 실시할 수 있다. UA 3(102c)가 GRUU를 감지하지 않으면, UA 3(102c)의 콘택트 URI(지금 R-URI인)는 그것에서 AOR을 가질 수 없다. 따라서, 사용자 연관 요소 3(110c)은 다시 맵-URI 헤더 또는 파라미터에 R-URI를 저장하고, epv 파라미터로부터 URI를 조장하고, 용어 시퀀싱을 개시할 수 있다. 이러한 프로세스에 대한 실시예 메세지를 하기에 나타낸다:

상기 시점에서 사용자 연관 요소 3(110c)는 종료 애플리케이션들(106d 및 108d)과는 다를 수 있는 B2BUA 5b(106f) 및 B2BUA 6b(108f)를 통해 INVITE를 시퀀스화할 것이다.

사용자 연관 요소 3(110c)가 이 프로세스를 완료하는 경우, 고유 R-URI를 재저장하고 마지막으로 그 후 UA 3(102c)로 메세지를 전송할 것이다. 이러한 프로세스에 있어서, 사용자 연관 요소 3(110c)은 맵-URI로부터 고유 R-URI를 재저장하고 그 후 단계(442)에서, UA 3(102c)로 INVITE 메세지를 전송할 수 있으며, 이것은 그 후 단계(444)에서, 사용자 연관 요소 3(110c)로 200 OK 메세지를 되전송할 수 있다. 사용자 연관 요소 3(110c)은 단계(446)에서, B2BUA 6b(108f), B2BUA 5b(106f)를 통해, 그리고 그 후 사용자 연관 요소 2(110b)로 200 OK 메세지를 라우팅할 수 있다. 단계(448)에서, 사용자 연관 요소 2(110b)는 그 후 B2BUA 4b(108e) 및 B2BUA 3b(106e)를 통해 그 후 마지막으로 UA 2(102b)로 200 OK 메세지를 라우팅한다. 200 OK 메세지를 수신하는 중에, UA 2(102b)는 단계(448)에서, 200 OK 메세지의 라우팅에 반대의 방식으로 UA 3(102c)으로 되라우팅된 ACK 메세지에 의해 수신을 수락한다.

200 OK 메세지 및 임의의 ACK 메세지들의 라우팅 후, 호 구조체를 도 1C에서와 같이 나타낼 수 있다. 따라서, INVITE-리플레이스가 완료한 후, UA 3(102c)은 UA 1(102a)로 BYE 메세지를 전송할 것이며, 이것은 제 2 통신 세션에 대해 수립된 통신 경로에서 시퀀스화된 B2BUA들(106/108)의 모두를 클리어(clear)한다. 또한, UA 2(102b)는 INVITE-리플레이스의 상태를 UA 1(102a)에게 계속 알리면서 UA 1(102a)로 sip-프래그(frag) NOTIFY 메세지를 되전송할 수 있다. 신규의 다이얼로그가 수립되었다는 것을 UA 1(102a)이 한번 인식하면, UA 1(102a)은 이들 2개의 UA들(102a/102b)간의 B2BUA들(106/108)의 모두를 클리어할 수 있는 UA 2(102b)로 BYE 메세지를 전송할 수 있다. 실재한 변경들은, 필요하지 않은 B2BUA들이 전환된 호에서 파티들과 시퀀스로 있지 않음에 따라, 전환 후 호들을 핸들링하는 것이 필요한 프로세싱의 양을 낮추는 이점을 제공한다. 이러한 전환은 이것이 전환된 호의 파티들을 해체하거나 언래블링하기 위해 호 환경의 수개의 브랜치(branch)들을 통해 라우팅됨에 따라 한 명 이상의 사람과 함께 행해질 수 있다.

도 5는 시스템들, 디바이스들, 서버들, 소프트웨어 모듈들, 등이 실행할 수 있는 컴퓨팅 환경(500)의 블록도를 예시한다. 이에 따라, 도 5와 함께 설명하는 시스템 또는 구성 요소들은 상품 하드웨어일 수 있다. 컴퓨팅 환경(500)은 하나 이상의 사용자 컴퓨터들(505, 510, 및 515)을 포함한다. 사용자 컴퓨터들(505, 510, 및 515)은 일반 목적 개인용 컴퓨터들[단지 예로서, Microsoft Corp.의 Windows™ 및/또는 Apple Corp.의 Macintosh™ 동작 시스템들의 다양한 버젼들을 실행하는 개인용 컴퓨터들, 및/또는 랩탑(laptop) 컴퓨터들] 및/또는 임의의 다양한 상업적으로 이용 가능한 UNIX™ 또는 UNIX형 동작 시스템들을 실행하는 워크스테이션(workstation) 컴퓨터들일 수 있다. 이들 사용자 컴퓨터들(505, 510, 515)은, 예컨대 데이터베이스 클라이언트 및/또는 서버 애플리케이션들을 포함하는 임의의 다양한 애플리케이션들, 및 웹 브라우저(web browser) 애플리케이션들을 또한 가질 수 있다. 대안으로, 사용자 컴퓨터들(505, 510, 및 515)은 네트워크[예컨대, 하기에 설명하는 네트워크(520)]를 통하여 통신하고/하거나 웹 페이지들 또는 다른 타입들의 전자 서류들을 디스플레이(display)하고 탐색할 수 있는 신-클라이언트(thin-client) 컴퓨터, 인터넷-가능 모바일(mobile) 전화, 및/또는 개인 휴대 정보 단말기와 같은 임의의 다른 전자 디바이스일 수 있다. 전형적인 컴퓨팅 환경(500)을 3개의 사용자 컴퓨터들로 나타내지만, 임의의 수의 사용자 컴퓨터들이 지원될 수 있다.

컴퓨팅 환경(500)은 또한 네트워크(520)를 포함한다. 네트워크(520)는 SIP, TCP/IP, SNA, IPX, AppleTalk, 등을 제한 없이 포함하는 임의의 다양한 상업적으로 이용 가능한 프로토콜들을 이용하는 데이터 통신들을 지원할 수 있는 당업자에게 익숙한 임의의 타입의 네트워크일 수 있다. 단지 예로서, 네트워크(520)는 이더넷(Ethernet) 네트워크, 토큰-링(Token-Ring) 네트워크, 등과 같은 로컬 영역 네트워크("LAN"); 광역 네트워크; 가상 사설 네트워크("VPN")를 제한 없이 포함하는 가상 네트워크; 인터넷; 인트라넷(intranet); 엑스트라넷(extranet); 일반 전화 교환망("PSTN"); 적외선 네트워크; 무선 네트워크[예컨대, 프로토콜들의 임의의 IEEE 502.11 슈트(suite), 관련 분야에 공지된 Bluetooth™ 프로토콜, 및/또는 임의의 다른 무선 프로토콜 하에서 동작하는 네트워크]; 및/또는 이들 및/또는 다른 네트워크들의 임의의 조합일 수 있다. 네트워크(520)는 네트워크(104)와 동일하거나 유사할 수 있다.

시스템은 하나 이상의 서버 컴퓨터들(525, 530)을 또한 포함할 수 있다. 하나의 서버는 웹 서버(525)일 수 있으며, 이것은 사용자 컴퓨터들(505, 510, 및 515)로부터의 웹 페이지들 또는 다른 전자 서류들에 대한 요청을 프로세스하는데 이용될 수 있다. 웹 서버는 상기 논의된 임의의 것들을 포함하는 동작 시스템뿐만 아니라 상업적으로 이용 가능한 서버 동작 시스템들을 실행하고 있을 수 있다. 웹서버(525)는 SIP 서버들, HTTP 서버들, FTP 서버들, CGI 서버들, 데이터베이스 서버들, 자바(Java) 서버들, 등을 포함하는 다양한 서버 애플리케이션들을 또한 실행할 수 있다. 몇몇 경우들에 있어서, 웹 서버(525)는 하나 이상의 웹 서비스들로서 이용 가능한 동작들을 공개할 수 있다.

컴퓨팅 환경(500)은 서버(530)에 하나 이상의 파일들 및/또는 애플리케이션들을 또한 포함할 수 있으며, 이것은, 동작 시스템에 추가하여, 하나 이상의 사용자 컴퓨터들(505, 510, 515)에서 실행하는 클라이언트에 의해 엑세스 가능한 하나 이상의 애플리케이션들을 포함할 수 있다. 서버(들)(530)은 사용자 컴퓨터들(505, 510 및 515)에 응답하여 프로그램들 및 스크립트(script)들을 실행할 수 있는 하나 이상의 일반 목적 컴퓨터들일 수 있다. 일례로서, 서버는 하나 이상의 웹 애플리케이션들을 실행할 수 있다. 웹 애플리케이션은 Java™ , C, C#™, 또는 C++와 같은 임의의 프로그래밍 언어, 및/또는 Perl, Python, 또는 TCL과 같은 임의의 스크립팅 언어뿐만 아니라 임의의 프로그래밍/스크립팅 언어들의 조합들에 기록된 하나 이상의 스크립트들 또는 프로그램들로서 구현될 수 있다. 애플리케이션 서버(들)(530)은 Oracle, Microsoft, Sybase™, IBM™ 등으로부터 상업적으로 이용 가능한 것들을 제한 없이 포함하는 데이터 베이스 서버들을 또한 포함할 수 있으며, 이것은 사용자 컴퓨터(505)에서 실행하는 데이터베이스 클라이언트들로부터의 요청들을 프로세스할 수 있다.

웹 애플리케이션 서버(530)에 의해 생성되는 웹 페이지들은 웹 서버(525)를 통하여 사용자 컴퓨터(505)로 보내질 수 있다. 마찬가지로, 웹 서버(525)는 사용자 컴퓨터(505)로부터 웹 페이지 요청들, 웹 서비스 호출들, 및/또는 입력 데이터를 수신할 수 있고 웹 애플리케이션 서버(530)로 웹 페이지 요청들 및/또는 입력 데이터를 보낼 수 있다. 추가의 실시형태들에 있어서, 서버(530)는 파일 서버로서 기능할 수 있다. 설명의 용이함을 위해, 도 5는 개별의 웹 서버(525) 및 파일/애플리케이션 서버(530)를 예시하지만, 당업자는 서버들(525, 530)에 대하여 설명한 기능들이, 구현-구체적 요구 및 파라미터들에 의존하여, 단일 서버 및/또는 복수의 특정화된 서버들에 의해 수행될 수 있다는 것을 인식할 것이다.

컴퓨팅 환경(500)은 데이터베이스(535) 또는 다중의 데이터베이스들을 또한 포함할 수 있다. 데이터베이스(535)는 다양한 위치들에 상주할 수 있다. 예로서, 데이터베이스(535)는 하나 이상의 컴퓨터들(505, 510, 515, 525, 530)에 가까운(그리고/또는 상주하는) 저장 매체에 상주할 수 있다. 대안으로, 이것은 임의의 또는 모든 컴퓨터들(505, 510, 515, 525, 530)로부터 멀리 있고 그들 중 하나 이상과 통신할 수 있다[예컨대, 네트워크(520)를 통하여]. 특정 집합의 실시형태들에 있어서, 데이터베이스(535)는 당업자에게 익숙한 저장-영역 네트워크("SAN")에 상주할 수 있다. 마찬가지로, 컴퓨터들(505, 510, 515, 525, 530)에 귀속된 기능들을 수행하기 위한 임의의 필요한 파일들이, 적절한 바에 따라, 각각의 컴퓨터에 가까이 그리고/또는 멀리 저장될 수 있다. 하나의 집합의 실시형태들에 있어서, 데이터베이스(535)는 SQL-형식화된 커맨드들에 응답하여 데이터를 저장하고, 업데이트하고, 복구하도록 적용되는 Oracle 10i™과 같은 관계형 데이터베이스일 수 있다.

도 6은 본 명세서에 설명한 시스템들, 디바이스들, 서버들, 소프트웨어 모듈들, 등이 배치되거나 실행될 수 있는 컴퓨터 시스템(600)의 일실시형태를 예시한다. 컴퓨터 시스템(600)은 버스(bus)(655)를 통하여 전기 접속될 수 있는 하드웨어 요소들을 구비하는 것으로서 나타내어진다. 하드웨어 요소들은 하나 이상의 중앙 처리 장치들(CPUs)(605); 하나 이상의 입력 디바이스들(610)(예컨대, 마우스, 키보드, 등); 및 하나 이상의 출력 디바이스들(615)(예컨대, 디스플레이 디바이스, 프린터, 등)을 포함할 수 있다. 컴퓨터 시스템(600)은 하나 이상의 저장 디바이스들(620)을 또한 포함할 수 있다. 예로서, 저장 디바이스(들)(620)은 디스크 드라이브들, 광 저장 디바이스들, 랜덤(random) 액세스 메모리("RAM") 및/또는 읽기-전용 메모리("ROM")와 같은 고체-상태 저장 디바이스들일 수 있으며, 이것은 프로그램 가능하고/하거나 플래시-업데이트(flash-update) 가능하고/하거나 등일 수 있다.

컴퓨터 시스템(600)은 컴퓨터-판독 가능 저장 매체 판독기(625); 통신 시스템(630)[예컨대, 모뎀(modem), 네트워크 카드(무선의 또는 유선의), 적외선 통신 디바이스, 등]; 및 워킹 메모리(640)를 추가로 포함할 수 있으며, 이것은 상술한 바와 같이 RAM 및 ROM 디바이스들을 포함할 수 있다. 몇몇 실시형태들에 있어서, 컴퓨터 시스템(600)은 프로세싱 가속화 유닛(unit)(635)을 또한 포함할 수 있으며, 이것은 DSP, 특수-목적 프로세서, 등을 포함할 수 있다.

컴퓨터-판독 가능 저장 매체 판독기(625)는 일시적으로 및/또는 보다 영구적으로 컴퓨터-판독 가능 정보를 포함하기 위해 원격의, 근거리의, 고정된, 그리고/또는 제거 가능한 저장 디바이스들에 저장 매체를 더한 것을 포괄적으로 나타내는 컴퓨터-판독 가능 저장 매체에 또한 함께[그리고, 선택적으로 저장 디바이스(들)(620)과의 조합으로] 접속될 수 있다. 통신 시스템(630)은 네트워크 및/또는 컴퓨터 시스템(600)에 대하여 상술한 임의의 다른 컴퓨터와 데이터가 상호 교환되는 것을 허용할 수 있다. 또한, 본 명세서에 개시된 바와 같이, 용어 "저장 매체"는 읽기 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 자기 RAM, 코어(core) 메모리, 자기 디스크 저장 매체들, 광 저장 매체들, 플래시 메모리 디바이스들 및/또는 정보를 저장하기 위한 다른 기계 판독 가능 매체들을 포함하는 데이터를 저장하기 위한 하나 이상의 디바이스들을 나타낼 수 있다.

컴퓨터 시스템(600)은 동작 시스템(645) 및/또는 다른 코드(code)(660)를 포함하는 워킹 메모리(640) 내에 현재 위치한 것으로 나타낸 소프트웨어 요소들을 또한 구비할 수 있다. 컴퓨터 시스템(600)의 대안의 실시형태들이 상술한 것으로부터 많은 변형들을 가질 수 있다는 것이 인식되어야 한다. 예컨대, 맞춤형 하드웨어가 또한 이용될 수 있고/있거나 특정 요소들이 하드웨어, 소프트웨어[애플릿(applets)과 같은 휴대용 소프트웨어를 포함하는], 또는 양자로 구현될 수 있다. 또한, 네트워크 입력/출력 디바이스들과 같은 다른 컴퓨팅 디바이스들로의 접속이 채용될 수 있다.

전술한 설명에 있어서, 예시의 목적들을 위하여, 방법들을 특정 순서로 설명하였다. 대안의 실시형태들에 있어서, 방법들이 설명한 것과 다른 순서로 수행될 수 있다는 것이 인식되어야 한다. 상술한 방법들이 하드웨어 구성 요소들에 의해 수행될 수 있거나 일반-목적 또는 특수-목적 프로세서 또는 방법들을 수행하도록 명령들로 프로그래밍된 로직 회로들과 같은, 기계를 야기시키는데 이용될 수 있는 기계-실행 가능 명령들의 시퀀스들로 내재될 수 있다는 것이 또한 인식되어야 한다. 이들 기계-실행 가능 명령들은 CD-ROM들 또는 다른 타입의 광 디스크들, 플로피 디스켓들, ROM들, RAM들, EPROM들, EEPROM들, 자기 또는 광 카드들, 플래시 메모리, 또는 전자 명령들을 저장하기에 적합한 다른 타입들의 기계-판독 가능 매체들과 같은 하나 이상의 기계 판독 가능 매체들에 저장될 수 있다. 대안으로, 방법들은 하드웨어와 소프트웨어의 조합에 의해 수행될 수 있다.

실시형태들의 완전한 이해를 제공하기 위해 설명에 구체적 상세를 부여하였다. 그러나, 실시형태들이 이들 구체적 상세 없이 실시될 수 있다는 것이 당업자에 의해 이해될 것이다. 예컨대, 불필요한 상세로 실시형태들을 모호하게 하지 않기 위하여 회로들을 블록도들로 나타낼 수 있다. 다른 경우들에 있어서, 실시형태들을 모호하게 하는 것을 회피하기 위하여 널리 공지된 회로들, 프로세스들, 알고리즘(algorithm)들, 구조체들, 및 기술들을 불필요한 상세 없이 나타낼 수 있다.

또한, 플로우챠트(flowchart), 흐름도, 데이터 흐름도, 구조체 도면, 또는 블록도로서 묘사된 프로세스로서 실시형태들을 설명하였다는 것이 주목된다. 플로우챠트가 동작들을 순차적인 프로세스로서 설명할 수 있지만, 많은 동작들이 병행하여 또는 동시에 수행될 수 있다. 또한, 동작들의 순서는 재배열될 수 있다. 프로세스는 그 동작들이 완료되는 경우 종료되지만, 도면들에 포함되지 않은 추가의 단계들을 가질 수 있다. 프로세스는 방법, 함수, 절차, 서브루틴(subroutine), 서브프로그램, 등에 부합할 수 있다. 프로세스가 함수에 부합하는 경우, 그 종료는 호출하는 함수 또는 메인 함수로의 함수의 복귀에 부합한다.

또한, 실시형태들은 하드웨어, 소프트웨어, 펌웨어, 미들웨어(middleware), 마이크로코드(microcode), 하드웨어 설명 언어, 또는 그것이 임의의 조합에 의해 구현될 수 있다. 소프트웨어, 펌웨어, 미들웨어 또는 마이크로코드로 구현되는 경우, 필요한 태스크들을 수행할 프로그램 코드 또는 코드 세그먼트(segment)들이 저장 매체와 같은 기계 판독 가능 매체에 저장될 수 있다. 프로세서(들)은 필요한 태스크들을 수행할 수 있다. 코드 세그먼트는 절차, 함수, 서브프로그램, 프로그램, 루틴, 서브루틴, 모듈, 소프트웨어 패키지(package), 클래스(class), 또는 명령들, 데이터 구조체들, 또는 프로그램 세그먼트들의 임의의 조합을 나타낼 수 있다. 코드 세그먼트는 정보, 데이터, 독립 변수들, 파라미터들, 또는 메모리 콘텐츠(contents)를 통과시키고/거나 수신함으로써 다른 코드 세그먼트 또는 하드웨어 회로에 접속될 수 있다. 정보, 독립 변수들, 파라미터들, 데이터, 등이 메모리 공유, 메세지 통과, 토큰 통과, 네트워크 전송, 등을 포함하는 임의의 적합한 수단들을 통하여 통과되거나, 보내지거나, 전송될 수 있다.

본 명세서에 예시적인 실시형태들을 상세히 설명하였지만, 개념들이 달리 다양하게 포함되고 채용될 수 있다는 것, 그리고 첨부된 청구항들이 종래 기술에 의해 한정되는 바를 제외하고 상기 변형들을 포함하도록 이해되는 것으로 의도된다는 것이 이해되어야 한다.

Claims (10)

1. 제 1 통신 세션에 관련된 사용자 에이전트(UA)의 다른 통신 세션으로의 전환을 가능하게 하기 위한 방법으로서,
   제 1 메세지의 적어도 하나의 부분으로 삽입된 고유 식별자를 포함하는 상기 제 1 메세지를 수신하는 단계 - 상기 적어도 하나의 부분은 상기 제 1 메세지의 헤더 및 파라미터 중 적어도 하나를 포함하고, 상기 제 1 메세지는 적어도 하나의 백-투-백 UA(B2BUA)를 트래버스함 - 와,
   상기 제 1 메세지의 상기 적어도 하나의 부분으로부터 상기 고유 식별자를 추출하는 단계와,
   상기 제 1 메세지의 콘택트 유니폼 리소스 식별자(URI: Uniform Resourse Identifier)로 상기 추출된 고유 식별자를 삽입하는 단계를 포함하는
   방법.
   
2. 제 1 항에 있어서,
   상기 고유 식별자는 상기 제 1 통신 세션에 관련된 엔드포인트를 식별하는 전체적 라우팅 가능 UA URI(GRUU: Globally Routable UA URI) 및 제 1 통신 디바이스의 사용자에 대한 기록의 어드레스(AOR: Address of Record)를 포함하고, 상기 제 1 메세지의 상기 적어도 하나의 부분은 하나 이상의 엔드포인트 뷰 헤더 (endpoint view header) 또는 엔드포인트 뷰 파라미터(endpoint view parameter)인
   방법.
   
3. 제 1 항에 있어서,
   다이얼로그-외 INVITE-리플레이스 메세지(out-of-dialog INVITE-Replaces message)에 대응하는 제 2 메세지를 수신하는 단계와,
   상기 제 2 메세지가 상기 제 2 메세지의 요청-URI(R-URI: Request-URI)에 내장된 엔드포인트 뷰 정보를 포함한다는 것을 판정하는 단계와,
   상기 고유 식별자를 상기 제 2 메세지의 상기 R-URI 내의 주 URI가 되도록 조장하는 단계를 더 포함하는
   방법.
   
4. 제 3 항에 있어서,
   상기 고유 식별자를 상기 제 2 메세지의 상기 주 URI가 되도록 조장하는 단계 이전에, 상기 제 2 메세지의 배치-유지 헤더 또는 파라미터(place-holding header or parameter)에 본래 R-URI값을 저장하는 단계와,
   상기 제 2 메세지를 라우팅하고 상기 다른 통신 세션에 대한 기점 애플리케이션들을 시퀀스화(sequence)하도록 상기 고유 식별자를 이용하는 단계와,
   상기 기점 애플리케이션들이 상기 다른 통신 세션에 대해 시퀀스화된 후, 상기 배치-유지 헤더 또는 파라미터로부터 다시 상기 제 2 메세지의 상기 주 R-URI로 상기 본래 R-URI값을 재저장하는 단계를 더 포함하는
   방법.
   
5. 제 4 항에 있어서,
   상기 기점 애플리케이션들이 상기 다른 통신 세션에 대해 시퀀스화된 후 상기 제 2 메세지를 수신하는 단계와,
   상기 제 1 통신 세션에 대해 시퀀스화된 각 애플리케이션을 언래블링(unraveling)하는 단계를 더 포함하고,
   상기 각 애플리케이션을 언래블링하는 단계는 상기 제 1 통신 세션에 대해 시퀀스화된 각 애플리케이션으로 하여금, 그 자신을 상기 다른 통신 세션의 통신 경로로부터 제거하게 하는 단계를 더 포함하는
   방법.
   
6. 제 5 항에 있어서,
   상기 제 1 통신 세션에 대해 시퀀스화된 각 애플리케이션은 기록 라우트(route) 기능을 수행하는 것 없이 상기 제 2 메세지를 전송하고, 상기 제 1 통신 세션에 대해 시퀀스화된 각 애플리케이션은 상기 제 2 메세지를 프록싱하기 전에 다이얼로그 맵(dialog map)을 이용하여 상기 제 2 메세지의 R-URI 및 리플레이스 헤더를 수정하는
   방법.
   
7. 제 5 항에 있어서,
   상기 제 1 통신 세션에 대해 시퀀스화된 각 애플리케이션은 상기 제 2 메세지의 상기 R-URI를 상기 고유 식별자와 관련된 디바이스들에 대한 등록된 콘택트 URI와 비교하는
   방법.
   
8. 제 4 항에 있어서,
   상기 기점 애플리케이션들이 상기 다른 통신 세션에 대해 시퀀스화된 후 상기 제 2 메세지를 수신하는 단계와,
   전환 타겟과 관련된 사용자 연관 요소(user relation element)에 상기 제 2 메세지를 직접 전송하는 단계를 더 포함하는
   방법.
   
9. 사용자 에이전트(UA)의 제 1 통신 세션으로부터 다른 통신 세션으로의 전환을 용이하게 하도록 구성된 서버로서,
   프로세서에 의해 실행되고, 상기 제 1 통신 세션 동안 또는 상기 제 1 통신 세션의 수립 동안 제 1 메세지를 수신하도록 구성되는 사용자 연관 요소를 포함하되, 상기 제 1 메세지는 적어도 하나의 백-투-백 UA(B2BUA)를 트래버스하고, 상기 사용자 연관 요소는 상기 제 1 메세지의 일부분으로부터 고유 식별자를 추출하고 상기 제 1 메세지의 콘택트 유니폼 리소스 식별자(URI)로 상기 추출된 고유 식별자를 삽입하도록 더 구성되는
   서버.
   
10. 제 9 항에 있어서,
    상기 고유 식별자는 상기 제 1 메세지의 헤더 및 파라미터 중 적어도 하나로부터 추출되고, 상기 고유 식별자는 전체적 라우팅 가능 UA URI(GRUU)를 포함하고, 상기 제 1 메세지는 INVITE 메세지이고, 상기 GRUU는 상기 INVITE 메세지를 전송한 제 1 UA 및 상기 제 1 UA의 사용자에 대한 기록의 어드레스(AOR)를 식별하고,
    상기 사용자 연관 요소는, 상기 INVITE 메세지에 대한 200 OK 응답을 수신하고 상기 200 OK 응답으로부터 제 2 고유 식별자를 추출하고 상기 200 OK 응답의 콘택트 URI에 상기 추출된 제 2 고유 식별자를 삽입하도록 더 구성되고,
    상기 제 2 고유 식별자는 상기 INVITE 메세지를 수신하고 상기 200 OK 응답을 전송한 제 2 UA뿐만 아니라 상기 제 2 UA의 사용자에 대한 AOR을 식별하는 GRUU를 포함하는
    서버.

Images