KR101114707B1 - Ｓｉｐ 세션 정책 프레임워크에 대한 확장을 해결하는 시스템 및 방법 - Google Patents

Ｓｉｐ 세션 정책 프레임워크에 대한 확장을 해결하는 시스템 및 방법 Download PDF

Info

Publication number
KR101114707B1
KR101114707B1 KR1020107018802A KR20107018802A KR101114707B1 KR 101114707 B1 KR101114707 B1 KR 101114707B1 KR 1020107018802 A KR1020107018802 A KR 1020107018802A KR 20107018802 A KR20107018802 A KR 20107018802A KR 101114707 B1 KR101114707 B1 KR 101114707B1
Authority
KR
South Korea
Prior art keywords
policy
sip
information
user agent
representations
Prior art date
Application number
KR1020107018802A
Other languages
English (en)
Other versions
KR20100116196A (ko
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 리서치 인 모션 리미티드
Publication of KR20100116196A publication Critical patent/KR20100116196A/ko
Application granted granted Critical
Publication of KR101114707B1 publication Critical patent/KR101114707B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/46—Indexing scheme relating to G06F9/46
    • G06F2209/462—Lookup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

사용자 에이전트에 정책 정보를 제공하는 방법이 제공된다. 이 방법은 사용자 에이전트가 정책 채널을 통한 통신을 위하여 사용자 에이전트가 지원하는 복수의 균일 자원 식별자(URI) 방식들에 관한 정보를 전송하는 것, 및 사용자 에이전트가 지원하는 정책 정보의 복수의 표현에 관한 정보를 전송하는 것을 포함한다. 본 방법은 사용자 에이전트가 복수의 URI 방식들 중 적어도 하나의 선택 및 정책 정보의 복수의 표현들 중 적어도 하나의 선택의 표시를 수신하는 것을 더 포함한다. 본 방법은 사용자 에이전트가 정책 정보의 선택된 표현들 중 적어도 하나를 이용하여 그리고 선택된 URI 방식들 중 적어도 하나를 이용하여 정책 정보를 획득하는 것을 더 포함한다.

Description

ＳＩＰ 세션 정책 프레임워크에 대한 확장을 해결하는 시스템 및 방법{SYSTEM AND METHOD FOR RESOLVING EXTENSIONS FOR THE SIP SESSION POLICY FRAMEWORK}
본 출원은 Andrew Allen 등의, 발명의 명칭이 "System and Method for Resolving Extensions for the SIP Session Policy Framework"인 미국 가특허 출원 번호 제61/029,523호를 우선권으로 주장하며, 그 내용이 복사된다면 전체 내용을 참조로서 포함한다.
본 발명은 인터넷 프로토콜 멀티미디어 서브시스템에 관한 것이다.
인터넷 프로토콜 멀티미디어 서브시스템[IP(Internet Protocol) Multimedia Subsystem; IMS]은 보이스-오버-IP(voice-over-IP) 호들을 포함한 멀티미디어 서비스들을 모바일과 고정된 사용자 에이전트(UA; user agent) 양쪽 모두에 제공하기 위한 표준화된 아키텍쳐이다. 세션 개시 프로토콜(SIP; Session Initiation Protocol)은 IMS 기반 호 또는 세션을 생성, 변경 및 종료하기 위한 시그널링 프로토콜로서 인터넷 엔지니어링 테스크 포스(IETF; Internet Engineering Task Force)에 의해 주로 표준화되어 관리되어 왔다. 여기에 이용된 용어, "사용자 에이전트" 및 "UA"는 어떤 경우에는 모바일 전화기, 개인 휴대정보 단말기, 핸드헬드 또는 랩톱 컴퓨터 및 통신 능력들을 갖는 유사 디바이스들과 같은 모바일 디바이스를 의미할 수 있다. 이러한 UA는 이들에 한정되는 것은 아니지만 가입자 식별 모듈(Subscriber Identity Module; SIM) 애플리케이션, 범용 가입자 식별 모듈(Universal Subscriber Identity Module; USIM) 애플리케이션 또는 탈착가능 사용자 식별 모듈(Removable User Identity Module; R-UIM) 애플리케이션을 포함하는 범용 집적 회로 카드(Universal Integrated Circuit Card; UICC)와 같은 UA와 관련된 탈착가능 메모리 모듈 및 UA로 구성된다. 다른 방식으로, 이러한 UA는 이러한 모듈없이 디바이스 자체로 구성된다. 다른 경우에, 용어, "UA"는 유사한 통신 능력을 갖고 있지만, 고정된 회선 전화기, 데스크톱 컴퓨터, 셋톱 박스, 또는 네트워크 노드들과 같이 이동할 수 없는 디바이스들을 의미할 수 있다. UA가 네트워크 노드일 때, 네트워크 노드는 UA 또는 고정된 회선 디바이스와 같이 다른 기능을 대신하여 동작할 수 있고 UA 또는 고정된 회선 디바이스를 시뮬레이트 또는 에뮬레이트(emulate)할 수 있다. 예를 들어, 일부 UA에서는. 디바이스 상에 일반적으로 상주하는 IMS SIP 클라이언트가 실제적으로 네트워크 내에 상주하며 최적화된 프로토콜을 이용하여 디바이스에 SIP 메시지 정보를 중계한다. 즉, UA에 의해 통상적으로 수행되었던 일부 기능들이 원격 UA의 형태로 분산될 수 있는데 여기서, 원격 UA는 네트워크 내의 UA를 나타낸다. 용어, "UA"는 또한, 이들에 한정되는 것은 아니지만 SIP 세션을 포함할 수 있는 통신 세션을 종료할 수 있는 임의의 하드웨어 또는 소프트웨어 컴포넌트를 의미할 수 있다. 또한, 용어, "사용자 에이전트", "UA", "사용자 장치", "UE" 및 "노드"는 여기에서는 유사어로 이용될 수 있다.
정책 채널을 이용하여 세션 정책들을 획득하기 위해 추가적인 메카니즘을 정의할 수 있도록 정책 채널에 대한 세션 정책 프레임워크 메카니즘이 요구된다.
일 실시예에서, 사용자 에이전트에 정책 정보를 제공하는 방법이 제공된다. 이 방법은 사용자 에이전트가, 정책 채널을 통한 통신을 위하여 사용자 에이전트가 지원하는 복수의 균일 자원 식별자(URI) 방식들에 관한 정보를 전송하는 것, 및 사용자 에이전트가 지원하는 정책 정보의 복수의 표현들에 관한 정보를 전송하는 것을 포함한다. 본 방법은 사용자 에이전트가 복수의 URI 방식들 중 적어도 하나의 선택 및 정책 정보의 복수의 표현들 중 적어도 하나의 선택의 표시를 수신하는 것을 더 포함한다. 본 방법은 사용자 에이전트가 정책 정보의 선택된 표현들 중 적어도 하나를 이용하여 그리고 선택된 URI 방식들 중 적어도 하나를 이용하여 정책 정보를 획득하는 것을 더 포함한다.
여기에 설명된 실시예들이 실시될 때, UA가 정책 문서를 요청하고 수신하는데 필요한 라운드 트립의 메시지들의 수와 크기는 위에서 설명된 SIP-단독 시나리오에서 이용되었던 복수의 SIP 메시지들에 비해 크게 감소될 수 있어, 엔티티들에 대한 부하와 지연이 감소될 수 있다.
이하, 본 발명의 보다 완벽한 이해를 위하여, 첨부된 도면과 상세한 설명과 함께 다음의 간단한 설명에 대한 참조가 이루어지며, 도면에서 동일한 도면 부호는 동일한 부분을 나타낸다.
도 1은 종래 기술에 따른 SIP 세션의 확립을 나타내는 흐름도이다.
도 2는 본 발명의 일 실시예에 따른 정책 아키텍쳐도를 나타낸다.
도 3은 본 발명의 일 실시예에 따라 사용자 에이전트에 정책 정보를 제공하는 방법도를 나타낸다.
도 4는 본 발명의 몇몇 실시예들을 실시하기에 적합한 프로세서 및 관련 컴포넌트를 나타낸다.
본 발명의 하나 이상의 실시예들의 예시적인 구현예가 아래 제공되지만, 본 시스템 및/또는 방법은 현재 알려져 있든 또는 기존의 것이든 간에 임의의 수의 기술을 이용하여 구현될 수 있는 것임을 이해하여야 한다. 본 발명은 여기에 설명되고 예시된 예시적인 설계 및 구현예들을 포함한 아래 설명된 예시적인 구현예, 도면, 및 기술로 제한되는 방식으로 되어서는 안 되며, 첨부된 청구범위 내에서 그 전체 등가 범위와 함께 변경될 수 있다.
SIP 코멘트 요청(RFC; Request for Comment; 3261)은 멀티미디어 세션을 생성, 변경 및 종료하는 시그널링 프로토콜이다. SIP 내의 중심 엘리먼트는 프록시 서버이다. 프록시 서버는 라우팅, 집결(rendezvous), 인증 및 인가, 이동성 및 다른 시그널링 서비스를 요청하는 것을 책임지는 중계자(intermediary)이다. 그러나, 프록시들은 SIP가 확립한 실제 세션들 - 오디오, 비디오 및 세션 모드 메시징 - 로부터 분리된다. 세션의 세부사항은 SIP 메시지들의 페이로드에서 전달되며 세션 디스크립션 프로토콜(SDP; Session Description Protocol)[RFC4566]로 항상 설명된다.
경험은 SIP 중계자가 세션의 양태에 영향을 주는데 필요함을 보여주고 있다. 세션 파라미터들은 통상적으로 세션 정책의 집행을 통해 제어된다. 예를 들어, SIP는 매체 트래픽에 대한 자원들을 제한하였던 무선 네트워크에 이용될 수 있다. 높은 활동 기간 동안, 무선 네트워크 제공자는 각각의 사용자에 대해 이용가능한 대역폭의 크기를 제한하는 것을 원할 수 있다. 세션 정책에서, 무선 네트워크 내의 중계자는 UA가 이용가능한 대역폭을 UA에 알릴 수 있다. 이 정보는 UA로 하여금, UA가 성공적으로 세션에 이용할 수 있는 스트림들의 수, 매체 유형들 및 코덱들에 대하여 알린 결정을 행하게 한다. 유사하게, 네트워크 제공자는 사용자가 이용할 수 있는 매체 유형의 세트를 정의하는, 사용자와의 서비스 레벨 동의(service level agreement)를 가질 수 있다. 네트워크는 사용자 에이전트들에 세션 정책들의 현재 세트를 전달하여, 사용자 에이전트들로 하여금 어떠한 네트워크 정책들도 의도하지 않게 위반함이 없이 세션들을 세트업하게 할 수 있다.
다른 예에서, SIP UA는 방화벽 또는 네트워크 경계 디바이스(network border device)를 통하여 공용 인터넷에 접속된 네트워크를 이용중에 있다. 네트워크 제공자는 자신이 공용 인터넷에 도달하기 위해 방화벽 또는 네트워크 경계 디바이스 상의 고유한 IP 주소 및 포트에 자신의 매체 스트림을 전송할 필요가 있음을 UA에게 말하고 싶어한다. 이러한 정책을 아는 것은, UA로 하여금 방화벽 또는 네트워크 경계 디바이스에 걸쳐 세션들을 세트업하게 한다. 매체 중계자를 삽입하기 위한 다른 방법들과 대조적으로, 세션 정책들의 사용은 SIP 메시지 보디부의 삽입 또는 변경을 필요로 하지 않는다.
도메인들은 종종, 자신들이 적절하게 갖고 있는 세션 정책을 집행할 필요를 갖는다. 예를 들어, 도메인은 비디오 이용을 허용하지 않고 비디오 인코딩을 포함한 모든 패킷들을 드롭시키는 집행 메카니즘(enforcement mechanism)을 가질 수 있는 정책을 가질 수 있다. 불행하게도, 이들 집행 메카니즘은 자신이 집행하고 있는 정책에 대해 사용자에게 일반적으로 알리지 않는다. 그 대신에, 이들은 무언으로, 사용자가 이들 정책에 반대되는 어떠한 것도 하지 않도록 한다. 이는 사용자가 이해할 수 없는 디바이스의 오작동을 야기할 수 있다. 세션 정책들에서, 사용자는 현재의 네트워크 정책들에 대해 알고 있고 정책에 순응하는 세션들을 세트업할 수 있거나 또는 덜 엄격한 정책을 갖는 도메인에 간단히 연결할 수 있다. 따라서, 세션 정책들은 집행과 연결된 허가의 중요한 연합(combination)을 제공한다. 즉, 사용자는 정책을 알게 되고 정책에 따라 동작할 필요가 있으며, 제공자는 여전히 정책을 집행하는 권리를 유지할 것이다.
세션 정책들의 두가지 유형 - 세션 고유의 정책 및 세션 독립형 정책이 존재한다. 세션 고유의 정책은 특정 세션에 대해 생성된 정책이며 예를 들어, 세션의 디스크립션에 기초할 수 있다. 이들은 네트워크 중계자로 하여금 UA가 제안하고 있는 세션 디스크립션을 즉시 검사하게 하고 그 세션 디스크립션에 대하여 정책을 명확하게 반환하게 한다. 예를 들어, 중계자는 제안된 세션 디스크립션에서의 각각의 매체 스트림에 대해 방화벽/네트워크 주소 변환부(NAT; network address translation) 내의 핀홀들을 개방할 수 있다. 그 후, UA의 IP 주소들 및 포트들을, 외부 소스가 도달가능한 방화벽/NAT에서 공개된 것들로 대체하는 세션 디스크립션에 대한 정책을 반환할 수 있다. 세션 고유의 정책이 세션에 대해 조정될 수 있기 때문에 이 정책들은 정책들이 형성된 세션에 대해서만 적용한다. 세션 고유의 정책들은 세션이 확립될 때 세션별로 형성된다.
한편, 세션 독립형 정책은 세션과 독립적으로 생성되는 정책이며 일반적으로 UA에 의해 세트업된 모든 SIP 세션들에 적용한다. 세션 독립형 정책은 예를 들어 기존의 대역폭 한계 또는 매체 유형 제약을 UA들에 알리는데 이용될 수 있다. 이들 정책은 고유한 세션 디스크립션에 기초하지 않기 때문에 정책들은 세션을 세트업하려는 시도와 독립적으로 형성될 수 있고 세션이 초기화할 때(예를 들어 디바이스가 파워온할 때) 그리고 정책들이 변경될 때에만 UA에 전달될 필요가 있다.
아래 설명된 메카니즘들은 세션 독립형 정책과 세션 고유의 정책 양쪽 모두에 대해 이용될 수 있다. 세션 고유의 정책들(즉, SIP 요청 또는 SIP 응답에 응답하여 제공된 정책들)에서는 PolicyOffer 또는 PolicyAnswer 문서가 UA로 반환될 수 있다. 세션 독립형 정책들(즉, 세션 이전에 UA에 제공된 정책들)에서는 세션 정책(Session Policy) 문서가 반환될 수 있다.
매체 정책에 더하여, 여기에 정의된 메카니즘을 이용하여 SDP Offer 또는 Answer시 다른 IP 주소를 이용하거나 또는 방화벽 또는 NAT를 네비게이트하거나 또는 트랜스코더 또는 다른 매체 중계기를 통하여 매체를 라우팅하도록 UA에 알릴 수 있다.
3세대 파트너쉽 프로젝트(3GPP; Third Generation Partnership Project)는 IP 멀티미디어 서브시스템(IMS; IP Multimedia Subsystem)을, 모바일 및 지상통신선 네트워크용 멀티미디어 서비스를 위한 차세대 SIP/IP 기반 네트워크로서 표준화하였다. 3GPP IMS에 대한 네트워크는 3GPP 기술 규격(TS; Technical Specification) 23.228에서 특정된다. 3GPP TS 23.228에서, S-CSCF(Serving Call Session Control Function) 및 P-CSCF(Proxy Call Session Control Function)를 포함한 IMS 엘리먼트의 기능이 특정된다. S-CSCF는 [RFC 3261]에서 정의된 바와 같이 SIP 등록부(Registrar)와 SIP 프록시 양쪽 모두로서 동작한다. P-CSCF는 또한 SIP 프록시로서 동작한다. 3GPP IMS는 세션 시그널링을 위하여 SIP를 이용하고 위에서 설명된 바와 같이 IMS 네트워크 엔티티(P-CSCF 및 S-CSCF)는 (스트림들의 수, 매체 유형, 및 코덱들과 같은) 세션의 양태에 영향을 주는 것이 필요할 수 있다.
3GPP는 IMS 베어러 자원에의 UA 액세스에 대해 필요한 인증 및 계정 기능(Authorization and Accounting function)을 수행하는 정책 및 과금 제어(PCC; Policy and Charging Control)를 위한 아키텍쳐를 정의하였다. PCC 아키텍쳐는 Policy Server인 PCRF(Policy Control and Charging Rules function)를 포함하는데 PCRF는 여러 소스들로부터의 입력에 기초하여, 어느 UA들이 (스트림들의 수, 매체 유형들, 및 코덱들과 같은) 세션의 특징 및 속성에 기초하여 베어러 액세스를 허용받았는지를 결정한다. PCRF는 서브스크립션 기반 정책에 대한 SPR(Subscription Profile Repository) 및 애플리케이션 고유의 입력에 대한 애플리케이션 기능부(AF; Application Function)에 인터페이스한다. IMS가 PCC에 이용될 때, AF는 SIP 세션 시그널링에 기초하여 PCRF에 영향을 줄 수 있는 SIP 프록시인 P-CSCF이다. PCRF는 정책이 집행되는 것을 보장하기 위해 게이팅(gating) 및 필터링 기능을 제공하는 정책 제어 집행 기능(PCEF; Policy Control Enforcement Function)에 인터페이스한다. PCEF는 액세스 네트워크 고유의 게이트웨이(예를 들어, GGSN, PDG, PDSN 또는 CMTS)에 통합된다. 이들 엔티티는 DIAMETER 또는 RADIUS 프로토콜을 이용하여 통신할 수 있고 AAA(Authentication Authorization Accounting) 인프라구조의 일부를 형성할 수 있다.
현재, 3GPP는 TS 24.229에서, 최초의 SIP INVITE 요청이, 네트워크 정책이 허용하지 않는 매체 유형 또는 코덱을 포함한다면, SIP 488 응답을 전송하는 SIP 프록시에 기초하여 IMS에 대한 세션 정책 규제(policing) 메카니즘을 정의하였다. [RFC 3261]에서 특정된 바와 같이, SIP 488 응답은 발신한 UA가 허용되지 않은 SDP로 요청을 재시도할 수 있도록 허용된 매체 유형 및 코덱의 SDP 디스크립션을 포함한다. 그러나, 이 접근 방식은, SIP 요청이 각각의 도메인을 가로지를 때 모든 도메인이 자기 자신의 정책 세트를 가질 수 있다는 문제를 갖는다. 이는 단일의 SIP 요청이 4개와 같은 개수의 서로 다른 IMS 도메인들을 가로지를 수 있고 각각의 도메인에 의해 되전송된 SIP 488 응답을 잠재적으로 가짐으로써, 심하게 지연된 세션 세트업을 가져올 수 있는 로밍 상황에서 가능성이 높다. 또한, 이 메카니즘은 [RFC 3261]에서 허용된 SDP를 포함하지 않는 SIP INVITE에 대해 동작하지 않으며, 이 경우 초기 SIP INVITE가 SDP 없이 전송될 수 있고 그 후 착신된 UA가 응답하여 SDP 제공(offer)을 되전송할 수 있으며 그 후 발신한 당사자가 ACK 요청시 SDP 응답을 반환한다. SIP 응답은 요청에 응답해서만 전송될 수 있기 때문에 응답은 SIP 488 응답으로 거절될 수 없다. 따라서, 3GPP IMS는 비제공(offerless) SIP INVITE 요청들이 오직 (정책을 알고 있는) 네트워크 서버로부터만 그리고 이들이 발생할 수 있는 IMS 네트워크 외부로부터만 오도록 허용함으로써 비제공 SIP INVITE 요청들의 이용을 제한하였으며, 어느 경우에도, 세션이 정책에 반하는 코덱으로 확립되면 BYE 메시지로 세션이 즉시 종료된다. 이 상황은 만족스럽지 못한 것이다.
3GPP에 의해 정의된 현재 세션 정책 메카니즘에서, 각각의 도메인 내의 각각의 프록시는 SIP 488 응답으로 SIP INVITE를 가능하다면 거절해야 하며 이는 SIP INVITE 요청이 착신된 UA에 도달하기 전에 발신한 UA가 5개의 SIP INVITE 요청들을 전송해야 하는 (그리고 4개의 SIP 488 응답을 수신해야 하는) 것을 일으킬 수 있다.
이 시나리오에서 전송될 필요가 있는 대다수의 라운드 트립 SIP 메시지들 및 큰 크기의 메시지들 및 정책 문서는 큰 크기의 오버헤드를 소모할 수 있는, 허용불가능하게 충분치 못한 메카니즘을 가져올 수 있다. 이는 시그널링 대역폭의 낭비일 뿐만 아니라 세션 세트업에서의 상당한 지연을 야기할 수 있다. 추가로, SIP 서버는 복수의 정책 서버들 중 각각의 서버와 접촉하여 정책 정보를 획득하는 것이 필요할 수 있다. 이 추가의 지연들은 세트업을 호출하고 UA의 배터리를 누출시킬 수 있다.
추가적으로, 3GPP PCC 아키텍쳐는 SIP 시그널링으로부터의 SDP를 분석하는 P-CSCF에 의존하여, 세션에 대한 베어러 자원들의 인가를 위한 입력을 PCRF 내에 제공한다. 착신된 UA에서, P-CSCF는 착신된 UA에 의해 수락된 매체 유형들 및 코덱들에 기초하여 베어러 자원들을 인가하기 위해 응답하여 전송된 SDP 응답을 필요로 한다. 이것은 착신된 UA가 SDP 응답을 달리 전송받았던 것보다 더 초기에 SDP 응답을 포함하는 임시적인 (1xx) 응답을 전송하는 것이 종종 필요하다는 것을 의미한다. IMS가 프리컨디션 프레임워크[RFC 3312]를 이용하기 때문에, 이 임시적인 응답은 신뢰성있게 전송될 필요가 있다. 이는 200 OK 응답 및 추가의 SIP PRACK 요청이 또한 교환될 것을 필요로 할 수 있는데, 200 OK 응답은 단대단으로 교환되는 것을 필요로 하는 추가적인 불필요한 메시지들로 인해 상당히 지연된 호 세트업 시간을 가져온다.
IETF는 네트워크로 하여금 SIP UA들에 현재 정책 세트를 전달하게끔 하여, SIP UA들로 하여금 어떠한 네트워크 정책들도 의도하지 않게 위반함이 없이 세션들을 세트업하게 하는 세션 정책 프레임워크를 [draft-sip-session-policy-framework-03]에서 정의하고 있다.
도 1은 세션 정책 프레임워크의 기본 IETF SIP 아키텍쳐를 SIP 세션 확립과 함께 나타내는 [draft-sip-session-policy-framework-03]로부터의 흐름도이다. 이벤트 12에서, 제1 UAA(110A)는 SDP 제공을 포함하는 INVITE 요청을 제1 프록시A(120A)에 전송한다. 이벤트 14에서, 제1 프록시A(120A)는 Policy-Contact 헤더를 포함하는 SIP 488 메시지를 제1 UAA(110A)에 전송한다. (여기에 이용된 용어, "헤더"는 Contact 헤더 필드와 같은 헤더 필드 또는 SIP 메시지의 헤더를 의미할 수 있다.) 그 후, 제1 UAA(110A)는 확인응답 메시지를 제1 프록시A(120A)에 반환한다. 이벤트 16에서, 제1 UAA(110A)는 InfoOffer를 포함하는 PolicyChannel 메시지를 제1 정책 서버A(130A)에 전송한다. 이벤트 18에서, 제1 정책 서버A(130A)는 PolicyOffer를 포함하는 PolicyChannel 메시지를 제1 UAA(110A)에 전송한다.
이벤트 20에서, 제1 UAA(110A)는 INVITE 제공 메시지를 제1 프록시A(120A)와 제2 프록시B(120B)를 통하여 제2 UAB(110B)에 전송한다. 이벤트 22에서, 제2 UAB(110B)는 InfoOffer와 InfoAnswer를 포함하는 PolicyChannel 메시지를 제2 정책 서버B(130B)에 전송한다. 이벤트 24에서, 제2 정책 서버B(130B)는 PolicyOffer와 PolicyAnswer를 포함하는 PolicyChannel 메시지를 제2 UAB(110B)에 전송한다. 이벤트 26에서, 제2 UAB(110B)는 SDP 응답을 포함하는 OK 응답을 제2 프록시B(120B)와 제1 프록시A(120A)를 통하여 제1 UAA(110A)에 전송한다. 그 후, 제1 UAA(110A)는 확인응답 메시지를 제2 UAB(11OB)에 반환한다. 이벤트 28에서, 제1 UAA(110A)는 UAA 110A InfoAnswer를 포함하는 PolicyChannel 메시지를 제1 프록시A(120A)에 전송한다. 이벤트 30에서, 제1 프록시A(120A)는 PolicyAnswer를 포함하는 PolicyChannel 메시지를 제1 UAA(110A)에 전송한다.
다음에 오는 엔티티들 - UA, 프록시, 정책 서버, 및 가능하게는 정책 집행 엔티티 - 가 일반적으로 세션 고유의 정책들을 필요로 한다. 이들 엔티티에 대한 정책 아키텍쳐가 도 2에 나타나 있다. UA(110)는 SIP 시그널링(125)을 통하여 프록시(120)와 통신하며, 정책 채널(135)을 통하여 정책 서버(130)와 통신한다. 매체(145)는 UA(110)와 정책 집행 컴포넌트(140) 사이에 교환될 수 있다.
프록시(120)는, 각각의 UA(110)가 자신의 도메인 내의 정책 서버(130)의 균일 자원 표시자(URI; Uniform Resource Identifier)를 획득하고 어디에서부터 정책을 검색할지를 아는 것을 보장한다. 프록시(120)는 UA들(110)이 (예를 들어, 이전 호에서 또는 구성부와 같은 다른 수단을 통하여) 정책 서버 URI를 아직 수신하지 못하였을 경우에 정책 서버 URI를 UA들(110)에 전달한다. 프록시(120)는 실제 정책들을 UA(110)에 전달하지 못한다. 그 대신에, 프록시(120)는 UA(110)가 정책 문서 또는 다른 정책 정보를 검색할 수 있는 정책 서버(130)에 대한 URI 또는 다른 식별자를 UA(110)에 제공한다.
정책 서버(130)는 프록시(120)와 물리적으로 공동 위치될 수 있는 별도의 논리적 엔티티이다. 정책 서버(130)의 역할은 세션 정책들을 UA(110)에 전달하는 것이다. 정책 서버(130)는 UA(110)로부터 세션 정보를 수신하고, 이 세션 정보를 이용하여 세션에 적용한 정책을 결정하고 이들 정책을 UA(110)에 반환한다.
세션 정책 프레임워크는 UA(110)가 프록시(120)로부터 정책 서버(130)의 URI를 수신하는 메카니즘으로서, (프록시(120)에 의해 SIP 요청 및 응답 내에 포함될 수 있는) SIP Policy-Contact 헤더를 정의한다. 즉, 프록시(120)는 정책 서버(130)의 URI를 Policy-Contact 헤더에 추가할 수 있다. UA(110)는 이 URI를 이용하여, 정책 서버(130)와 접촉하고 현재 세션에 대한 정보를 정책 서버(130)에 제공한다. 그 후, UA(110)는 응답하여 정책 서버(130)로부터 세션 정책들을 수신한다. UA(110)는 또한 세션의 진행 동안에 정책 서버(130)로부터 정책 업데이트들을 수신할 수 있다. UA(110)와 정책 서버(130) 사이의 통신 교환들은 정책 채널(135)로서 정의된다.
현재 세션 정책 프레임워크는 정책 채널(135)을 이용하여 UA(110)에 세션 정책을 전달하기 위하여 SIP 이벤트 프레임워크[RFC 3265]와 [draft-ietf-sipping-policy-package-03]에서 정의된 이벤트 패키지에 기초해서만 SIP-기반 메카니즘을 정의하며, 프록시(120)에 의해 SIP Policy-Contact 헤더 내에 포함될 수 있는 URI로서 SIP 및 SIPS URI만을 현재 정의한다. 세션 정책 프레임워크의 완전한 세부 내용은 [draft-sip-session-policy-framework-03]에서 정의되어 있다.
SIP 이벤트 프레임워크[RFC 3265]는 기본이 되는 정책 및 네트워크 아키텍쳐와는 무관하며 이는 모든 SIP UA들(110)이 모든 정책 서버(130)와의 상호작용을 가능하게 하는 것을 보장한다. 그러나, 배터리를 구비한 모바일 디바이스와 같이 제한된 전원을 갖는 디바이스에서와, GSM(Global System for Mobile Communications), UMTS(Universal Mobile Telecommunications System), CDMA(Code Division Multiple Access), 및 E-UTRAN(Evolved UMTS Terrestrial Radio Access Network)와 같은 제한된 대역폭 네트워크에서는, SIP 이벤트 프레임워크[RFC 3265]가 세션 세트업 동안에 세션 정책을 UA들(110)에 전달하는 것이 극도로 힘들 수 있다. SIP 이벤트 프레임워크는 세션 정책을 획득하기 위해 전송될 다음에 오는 SIP 메시지들 - SUBSCRIBE 메시지, 200 OK 메시지, NOTIFY 메시지, 및 다른 200 OK 메시지 - 을 최소한으로 요구한다. 상호작용 수를 감소시키는 것이 자원들을 해방시키고 자원을 처리할 때 더 적은 에너지를 필요로 하기 때문에 상호작용 수를 감소시키는 것이 바람직하다.
추가로, 이들 메시지, 특히 SUBSCRIBE 메시지 및 NOTIFY 메시지는 IP 및 UDP 헤더들의 오버헤더를 또한 포함하는 대형의 텍스트 기반 메시지들이다. 따라서, 이 메시지들은 크기에 있어 수백 바이트일 수 있다. NOTIFY 메시지가 확장가능 마크업 언어(XML; Extensible Markup Language)로 인코딩되는 정책 문서를 포함하기 때문에 특히 대형일 수 있다. 메시지들의 크기를 감소시키는 것이 자원들을 해방시키고 자원들을 처리할 때 더 적은 에너지를 필요로 하기 때문에 메시지들의 크기를 감소시키는 것이 바람직하다.
따라서, 도 1의 세션 정책 흐름도에 나타나 있는 시나리오에서는, 정책 채널 상에서 SIP 이벤트들을 이용하여 3개의 정책 채널 상호작용에 대해 12개의 SIP 메시지들을 필요로 하며, 이에 더하여, 세션을 확립하기 위해 9개의 SIP 세션 시그널링 메시지들이 필요하게 된다. 따라서 SIP 이벤트 프레임워크를 이용하는 SIP 시그널링 오버헤드는 SIP 세션 확립에 필요한 SIP 시그널링보다 더 크다. 이는 시그널링 대역폭을 낭비할 뿐만 아니라, 초당 수천 킬로바이트만의 시그널링 채널을 갖는 셀룰라와 같은 제한된 대역폭에서 이는 세션 세트업에 있어 상당한 지연을 가져올 수 있다.
또한, SIP 이벤트 프레임워크는 상태적(stateful)인데, 이는 SIP 이벤트 프레임워크가 SIP 다이알로그를 확립함을 의미한다. 이는 네트워크 인프라구조 엔티티들에 상당한 부하를 줄 수 있다. 또한, 정책 서버들(130)은 일반적으로 SIP로 구현되지 않았으며, 정책들을 전달하기 위하여 AAA(RADIUS 및 DIAMETER) 또는 HTTP(hypertext transfer protocol)와 같은 다른 프로토콜들을 이용하였다.
일 실시예에서, 정책 채널을 이용하여 세션 정책들을 획득하기 위해 추가적인 메카니즘을 정의할 수 있도록 정책 채널에 대한 세션 정책 프레임워크 메카니즘이 확장가능하게 형성된다. 여기에 설명된 실시예들이 실시될 때, UA가 정책 문서를 요청하고 수신하는데 필요한 라운드 트립의 메시지들의 수와 크기는 위에서 설명된 SIP-단독 시나리오에서 이용되었던 복수의 SIP 메시지들에 비해 크게 감소될 수 있다. 보다 자세하게는, SIP-기반 또는 SIPS-기반 URI 방식에 더하여 또는 SIP-기반 또는 SIPS-기반 URI 방식 이외의 URI 방식이 정책 채널 상에서 이용될 수 있다. 예를 들어, 다른 액세스 고유의 메카니즘들을 정의하는, HTTP, HTTPS(hypertext transfer protocol secure), FTP(file transfer protocol) 또는 균일 자원 이름(URN; Uniform Resource Name)이, 정책과 관련된 데이터를 전달하기 위한 URI 방식으로서 이용될 수 있다. SIP-기반 또는 SIPS-기반 URI 방식을 이용하기 보다 정책 채널 상에서의 이러한 URI 방식을 이용하는 것은 정책 문서 또는 다른 정책 정보를 UA에 제공하는데 필요한 메시지들의 수와 크기를 감소시킬 수 있다. 이 절차는 UA들과 목표 UA들을 발신하기 위하여 달라질 수 있다. 발신하는 UA의 경우를 첫번째로 고려하여 본다.
일 실시예에서, SIP 헤더 필드의 신텍스(syntax)는 복수의 URI 방식의 규격이 채널을 협상하는데 이용될 수 있게 허용한다. 여기에 이용된, 용어, "채널을 협상하는 것"은 정책 채널의 선택에 관한 이벤트 또는 정책 채널 상에 이용될 통신 프로토콜의 선택에 관한 이벤트들을 의미할 수 있다. 이러한 방식으로 채널들을 지원하는 채널 협상 요청의 개시자(initiator)가 정보를 교환하려 시도할 때, 채널 협상 요청의 개시자는 자신이 지원하는 채널들을 채널 서버에 알릴 수 있다. 그 후, 채널 서버는 채널 협상 요청의 개시자에 대해 적합한 방식을 선택하고, 응답하여 선택된 방식을 포함하고 응답하여 채널 협상 요청의 개시자에게 응답을 전송할 수 있다.
다른 실시예에서, SIP Policy-Contact 헤더의 신텍스는 Policy-Contact 헤더로 하여금 정책 채널을 통하여 세션 정책 문서를 획득하는데 이용될 수 있는 하나 이상의 URI 방식들을 특정하게끔 할 수 있다. 이 방식으로 복수의 URI 방식들을 지원하는 제1 UA가 세션을 세트하려 시도할 때, 제1 UA는 자신이 지원하는 방식들을 제2 SIP UA, SIP 프록시 서버, SIP 등록부 서버 또는 SIP 백 투 백(Back to Back) 사용자 에이전트에 알릴 수 있다. 이하, 용어, "SIP 컴포넌트"는 이러한 임의의 컴포넌트를 의미하는데 이용될 것이다. 그 후, SIP 컴포넌트는 제1 UA에 대해 적합한 하나 이상의 방식을 선택하고, 선택된 방식 또는 방식들을 Policy-Contact 헤더 내에 포함시키며 Policy-Contact 헤더를 제1 UA에 전송할 수 있다. 제2 UA는 중간의 네트워크 노드(예를 들어, B2BUA(Back to Back User Agent))일 수 있거나 엔드포인트일 수 있다.
SIP 컴포넌트가 URI 방식을 포함하고 URI 방식을 SIP Policy-Contact 헤더 내에 포함시키기 위하여, SIP 컴포넌트는 어떤 URI 방식이 제1 UA에 의해 실제로 지원되는지를 첫번째로 결정하는 것이 필요하다. 이 정보를 SIP 컴포넌트에 제공하기 위하여, 제1 UA로 하여금 제1 UA가 정책 채널에 대해 지원하는 URI 방식들을 열거하게 허용하는 새로운 SIP 헤더를 생성할 수 있다. 그 후, 제1 UA는 세션을 세트업하려 시도할 때 SIP 컴포넌트에 이 헤더를 전송할 수 있다. SIP 컴포넌트는 이 헤더 내에서 URI 방식들의 목록을 읽을 수 있고, 목록으로부터 정책 채널에 대해 적합한 하나 이상의 URI 방식을 선택할 수 있고, 선택된 URI 방식 또는 방식들을 Policy-Contact 헤더 내에 포함시킬 수 있으며 Policy-Contact 헤더를 제1 UA에 전송할 수 있다.
보다 자세하게는, 일 실시예에서 UA가 (SIP INVITE와 같은) SIP 요청 또는 SIP 응답을 전송할 때, UA는 지원되는 정책 채널 URI 방식들의 표시부를 SIP 메시지 내에 포함시킨다. 일 실시예에서, 표시부는 이러한 목적으로 정의되고 UA에 의해 지원되는 정책 채널 URI 방식들의 목록을 포함하는 새로운 SIP 헤더(예를 들어, Accept-Policy-Contact 헤더)와 같은 SIP 헤더 내에 있을 수 있다. 예를 들어, Accept-Policy-Contact 헤더는,
Figure 112010054589354-pct00001
일 수 있다.
"발신자(originator)" 파라미터는, 다음에 오는 것이 SIP 메시지(요청 또는 응답)의 발신자에 의해 지원되는 정책 채널 URl 방식들의 목록을 포함하고 있음을 표시한다. 이 경우, UA에 의해 지원되는 정책 채널 URI 방식들은 sip, sips, http, https, 및 urn:gsma:apn이지만, 다른 실시예들에서, 다른 정책 채널 URI 방식들이 지원될 수 있다.
제1 UA는 Accept-Policy-Contact 헤더와 같은 헤더를 SIP 컴포넌트에 전송할 수 있다. SIP 컴포넌트는 제1 UA와 SIP 컴포넌트 양쪽 모두에 의해 지원되고 정책 채널에 대해 제1 UA에 의해 이용될 가장 적합한 방식을, Accept-Policy-Contact 헤더 또는 유사한 헤더 내에 열거된 정책 채널 URI 방식들로부터 선택할 수 있다. SIP 컴포넌트는 제1 UA에 대한 SIP 메시지 내의 Policy-Contact 헤더 내에 선택된 URI를 포함시킬 수 있다. 예를 들어, "urn:gsma:apn"가 SIP 컴포넌트에 의해 선택되면, Policy-Contact 헤더는,
Figure 112010054589354-pct00002
일 수 있다.
그 후, 정책 URI를 포함하는 Policy-Contact 헤더를 수신할 때, 그 후, 제1 UA는 그 URI을 이용하여 그 URI에 대해 정의된 메카니즘을 이용해 정책 서버에 액세스할 수 있다. 이 예시적인 실시예에서, URI는 GPRS에 대한 3GPP TS 23.003에서 정의된 바와 같은 액세스 포인트 이름(APN; Access Point Name)을 포함하는 URN이며,
Figure 112010054589354-pct00003
이다.
이 예시적인 실시예는 정책 서버를 식별하는 APN 네트워크 식별자로서 "pol-serv12345"를 포함한다. 아래 자세히 설명될 바와 같이, 전달될 정책 문서의 버전도 또한 선택적으로 특정될 수 있다. 그 후, UA는 GPRS 메카니즘 또는 GPRS에 대한 다른 프로토콜을 이용하여 정책 채널을 확립하여 정책 문서를 획득할 수 있다. 이는 단지 정의될 수 있는 액세스 특정 정책 URI 방식들 중 가능한 하나에 불과하다.
이 절차의 일 실시예가 도 2에 도시되어 있으며, 도 2에서 UA(110)는 프록시(120)에 지원되는 정책 URI 방식들의 목록(220)을 포함하는 Accept-Policy-Contact 헤더(210)를 전송한다. 프록시(120)는 방식들 중 하나를 선택하고 그 선택된 방식(240)을 포함하는 Policy-Contact 헤더(230)를 UA(110)에 전송한다.
위에서 설명된 절차들은 SIP 요청 또는 SIP 응답의 발신자에 의해 행해질 수 있다. SIP 요청 또는 SIP 응답의 목표 UA가 목표 UA에 의해 이용될 정책 채널 URI 방식을 결정하는 프록시에 전송하기 전에, SIP 요청 또는 SIP 응답의 목표 UA가 일반적으로 SIP 요청 또는 SIP 응답 내에 헤더를 직접 포함시킬 수 없다. 따라서, 상술한 절차들은 목표 UA에 적합하지 않을 수 있다.
일 실시예에서, 이를 해결하기 위해 목표 UA가 SIP Registration 절차를 수행할 때, 목표 UA는 자신이 지원하는 정책 URI 방식들의 목록을 SIP Register 요청 내에 포함시킨다. 다음에 오는 실시예에서, 지원되는 정책 URI 방식들의 목록을 SIP 등록부에 전달하기 위해 새로운 Contact 헤더 필드 파라미터, "+sip.supported-policy-scheme"가 정의된다. 목표 UA는 SIP Register 요청의 SIP Contact 헤더 내에 +sip.supported-policy-scheme Contact 헤더 필드 파라미터를 포함시킬 수 있다. 예를 들어, Contact 헤더는,
Figure 112010054589354-pct00004
일 수 있다.
그 후, SIP 등록부는 등록된 Address of Record로 바인딩된 Contact와 연관된 Contact 헤더 필드 파라미터들을 저장한다. SIP 요청이 등록부(또는 목표로 되는 UA를 서브하는 프록시 서버)에 도달할 때, 등록부 또는 프록시는 목표 UA의 Contact 어드레스와 연관된, 지원되는 정책 URI 방식들의 목록을 획득하며, 이들 목록을 SIP Accept-Policy-Contact 헤더 내에 포함시킨다. 등록부 또는 프록시는 다음에 오는 것이 SIP 메시지의 목표에 의해 지원되는 정책 채널 URI 방식들의 목록을 포함하고 있음을 표시하는 목표 파라미터와 함께 Accept-Policy-Contact 헤더를 SIP 요청 또는 SIP 응답에 추가한다. 예를 들어, Accept-Policy-Contact 헤더는,
Figure 112010054589354-pct00005
일 수 있다.
프록시 서버는 목표 UA와 목표 UA에 의해 이용될 정책 서버 양쪽 모두에 의해 지원되는 가장 적합한 방식을 Accept-Policy-Contact 헤더 내에 열거된 정책 채널 URI 방식들로부터 선택할 수 있다. 프록시 서버는 발신의 경우에서와 유사하게, 목표 UA로의 SIP 메시지 내의 Policy-Contact 헤더 내에 그 선택된 URI를 포함시킬 수 있다. 목표 UA가 Policy-Contact 헤더를 포함하는 SIP 메시지를 수신할 때 그 후, UA는 발신한 UA에 대하여 설명된 방식과 유사하게 Policy-Contact 헤더 내의 정책 URI를 이용하여 정책 서버에 액세스할 수 있다.
다른 실시예들 및 변형예들이 가능함을 알아야 한다. 예를 들어, SIP 파라미터들이 SIP 헤더 대신에 이용될 수 있고 헤더들 또는 파라미터들의 이름이 바뀔 수 있다. 신택스의 세부 내용 및 구조가 또한 변경될 수 있다.
다른 실시예들은 각각의 정책 URI 방식에 대하여 새로운 SIP 옵션 태그 또는 피쳐 태그(feature tag)를 정의하는 것이다. 그 후, 발신한 UA가 Accept-Policy-Contact 헤더를 이용하는 대신에, 지원되는 정책 URI 방식들에 대한 옵션 태그들이 기존의 SIP Supported 헤더 내에 포함될 수 있다. 마찬가지로, 목표 UA는 [RFC 3840]에서 정의된 기존의 sip. 확장자 매체 피쳐 태그 내에서 지원되는 정책 URI 방식들에 대한 옵션 태그를 +sip.supported-policy-scheme Contact 헤더 필드 파라미터 대신에 SIP 레지스터의 Contact 헤더 내에 포함시킬 수 있다. 이 실시예는 옵션 태그가 영숫자 문자만으로 되는 문제를 갖고 있기 때문에 세퍼레이터 문자를 갖는 URN들을 쉽게 표현할 수 없다. 또한, SIP 프록시 서버는 Supported 헤더 내의 현재 옵션 태그들을 변경하지 않기 때문에, Accept-Policy-Contact 헤더가 여전히 요구될 것이다.
다른 실시예에서, 발신한 UA는 Accept-Policy-Contact 헤더를 이용하여 자신의 지원되는 정책 URI 방식들을 표시하지 않는다. 그 대신에, 발신한 UA는 새로운 Contact 헤더 필드 파라미터 "+sip.supported-policy-scheme"를 이용하여 지원되는 정책 URI 방식들의 목록을 세션에 대한 요청의 Contact 헤더에서 전달한다.
정책 채널 내에서, 적합한 문서는 정책 설정값을 전달한다. 예를 들어, draft-ietf-sipping-media-policy-dataset는 URN: "urn:ietf:params:xml:ns:media dataset"와 MIME 유형 application/media-policy- dataset+xml에 의해 식별된 정책 문서를 정의한다. 추가로, draft-ietf-sipping-policy-package는 또한 IETF RFC 3265에 대한 SIP Subscribe/Notify 메카니즘을 이용하여 세션 정책 문서를 전달하기 위해 이벤트 패키지를 정의한다. 달리 어떠한 표시들도 없을 경우, 정책 채널에 대응하는 URN 방식의 선택이 '주어진' 또는 미리 정해진 것으로서 그 정책 채널을 이용하여 교환될 수 있는 정책 문서를 또한 결정한다고 추정할 수 있다.
어떻게 정책 URI 방식이 정책 문서를 전달하는데 이용되는지의 방법을 설명하는 위의 설명이 특정될 수 있다. 이전에 언급한 바와 같이, 전달될 정책 문서도 역시 특정될 수 있다. 즉, 여러가지 정책 문서들, 또는 정책 채널 내에서 허용가능한 정책 문서들의 여러 가지 변경들이 있을 수 있으며 위에서 설명된 기술들은 어느 정책 문서 또는 어느 정책 문서의 변경이 제공되어야 하는지를 특정하도록 확장될 수 있다. 용어, "정책 정보의 표현(representation of policy information)"은 여기에서 정책 문서 또는 정책 문서의 확장 또는 변경을 의미하기 위해 이용될 수 있거나 또는 일부 실시예들에서는 정책 문서의 버전을 의미할 수 있다.
보다 자세하게는, 일 실시예에서, Accept-Policy-Contact 헤더는 특정된 정책 URI 방식들에 대한 정책 채널에 대해 허용된 MIME(Multipurpose Internet Mail Extension) 유형을 포함하는 파라미터를 추가함으로써 추가로 확장된다. 정책 채널에 대하여 허용된 복수의 MIME 유형들이 있을 수 있다. MIME 유형이 XML MIME 유형이라면 XML 스키마 확장자 또는 집행자를 나타내기 위해 스키마 버전 파라미터(아래 예에서 "sv"로 표기됨)를 또한 추가할 수 있다. 예를 들어, Accept-Policy-Contact 헤더는:
Figure 112010054589354-pct00006
일 수 있다.
일 실시예에서, UA가 (SIP INVITE와 같은) SIP 요청 또는 SIP 응답을 전송할 때 UA는 지원되는 정책 채널 URI 방식들의 표시부를 특정된 정책 URI 방식들에 대한 정책 채널에 대하여 허용된 하나 이상의 MIME 유형과 함께 SIP 메시지 내에 포함시킨다. 정책 문서들을 표현하는 허용가능한 XML 문서들의 클래스를 정의하는 선택적 심볼 세트가 또한 포함될 수 있다. 일 실시예에서, 표시부는 이러한 목적으로 정의되고 UA에 의해 지원되는 정책 채널 URI 방식들의 목록 및 특정된 정책 URI 방식들에 대한 정책 채널에 대해 허용된 MIME 유형을 포함하는 파라미터를 포함한 새로운 SIP 헤더(예를 들어, Accept-Policy-Contact 헤더)와 같은 SIP 헤더 내에 있을 수 있다.
XML 스키마 확장자, 집행 또는 변경을 표시하기 위해 스키마 버전 파라미터를 또한 MIME 유형 마다 추가할 수 있다. 스키마 버전 파라미터는 정책 문서를 표현하는 허용가능한 XML 문서의 클래스를 정의하는 선택적 심볼 세트를 포함한다. 스키마 버전 파라미터는 수개의 심볼(콤마(comma-) 또는 하이픈(hyphen-)으로 분리된 것)을 허용한다. 심볼들은 지원되는/허용되는 일련의 XML 스키마들(예를 들어, DTD, NGRelax, XML Schema) 문서를 표현한다. 위의 예에서, MIME 유형 "application/media-policy-dataset+xml"에 대하여 다음에 오는 심볼들은 UA가 XML 문서들을 이해하기 위하여 XML 문서들이 따를 수 있는 XML 스키마 문서의 실제 세트를 표현한다.
Figure 112010054589354-pct00007
Figure 112010054589354-pct00008
Figure 112010054589354-pct00009
"urn:ietf:params:xml:ns:mediadataset"는 MIME 유형(see section 10.1 of [draft-ietf-sipping-media-policy-dataset-05]의 섹션 10.1과 [draft-ietf-sipping-media-policy-dataset-OS]의 섹션 10.2를 참조)의 등록과 함께 IANA(Internet Assigned Numbers Authority)에 대부분 등록된 것이기 때문에 누구나 "urn:ietf:params:xml:ns:mediadataset"가 이미 "주어진 것임"을 주장할 수 있다. 여기서, "urn:ietf:params:xml:ns:mediadataset"은 완전성을 위해 포함되며, "urn:ietf:params:xml:ns:mediadataset:extenstonB" 및 "urn:ietf:params:xml:ns:nnediadataset:extensionZ"는 특정 예의 확장자들을 표현하는 심볼들이다. 이들 심볼은 나노스페이스로서 반드시 포맷될 필요가 있는 것은 아니며, XML 스키마 문서들 또는 심지어 스트링들에 대응하는 간단한 숫자들일 수 있다. 그러나, 나노스페이스들이 이 경우에 더 편리한 실시예이다.
UA는 프록시 서버에 Accept-Policy-Contact 헤더와 같은 헤더를 전송할 수 있다. 프록시 서버는 정책 채널 URI 방식들 및 관련 문서들로부터, Accept-Policy-Contact 헤더 내에 열거된 변경과 함께 가장 적합한 방식, MIME 유형들, 또는 지원되는 MIME 유형 내의 변경들을 선택할 수 있다. 프록시 서버는 UA와 정책 서버 양쪽 모두에 의해 수동으로 이해되어지고 UA에 의해 정책 채널에 이용될 정책 문서에 대한 지원되는 정책 URI들 및 MIME 유형(여기에 정책 문서들을 표현하는 허용가능한 XML 문서들의 클래스를 정의하는 MIME 유형 마다의 선택적 심볼 세트들을 더한 것)에 기초하여 이를 결정한다. 그 후, 프록시 서버는 그 선택된 URI, MIME 유형, 또는 관련 문서 버전을 UA로의 SIP 메시지 내의 Policy-Contact 헤더 내에 포함시킨다. 그 후, 정책 URI 및 관련된 문서 버전을 포함하는 Policy-Contact 헤더를 수신시, UA는 그 URI를 이용하여 그 URI에 대해 정의된 메카니즘을 이용하는 정책 서버에 액세스하고, UA가 지원하는 임의의 변경들 및 확장자들을 포함하는 MIME 유형에 따라 문서 내의 정책 정보를 획득한다.
이 절차의 일 실시예는 도 2에 나타나 있으며, 여기서 UA(110)는 지원되는 정책 URI 방식들의 목록(220), 정책 URI 방식 마다 지원되는 MIME 유형의 목록(245), 및 MIME 유형 마다 지원되는 변경/확장자들의 목록(250)을 포함하는 Accept-Policy-Contact 헤더(210)를 프록시(120)에 전송한다. 프록시(120)는 하나 이상의 방식들, 하나 이상의 MIME 유형들, 및/또는 하나 이상의 변경/확장자들을 선택하고 그 선택된 방식들(240), 선택된 MIME 유형들(255) 및/또는 선택된 변경/확장자들(260)을 포함하는 Policy-Contact 헤더(230)를 UA(110)에 전송한다.
다른 실시예에서, UA(110)는 MIME 유형들 마다 지원되는 변경/확장자들의 목록 또는 정책 URI 방식 마다 지원되는 MIME 유형들의 목록을 포함하는 Accept 헤더와 지원되는 정책 URI 방식들의 목록을 포함하는 Policy-Contact 헤더들 양쪽 모두를 프록시(120)에 전송한다. 프록시(120)는 하나 이상의 방식들, 하나 이상의 MIME 유형들, 또는 하나 이상의 변경/확장자들을 선택하고 그 선택된 방식들을 포함하는 Policy-Contact 헤더와, 선택된 MIME 유형들 또는 선택된 변경/확장자들을 포함하는 Accept 헤더를 UA(110)에 전송한다. 그 후, UA(110)는 Policy-Contact 헤더 내의 항목들과 Accept 헤더 내의 항목들을 상호연관시킬 수 있다. Accept 헤더 필드는 모든 SIP 응답 내에 존재할 수 있는 것이 아님을 알아야 한다.
다른 실시예들 및 변경예들이 가능함을 알아야 한다. 예를 들어, SIP 파라미터들이 SIP 헤더 대신에 이용될 수 있고 헤더 또는 파라미터들의 이름들이 변경될 수 있다. 신택스의 세부 내용 및 구조가 또한 변경될 수 있다.
위에서 설명된 절차들은 SIP 요청 또는 SIP 응답의 발신자에 의해 행해질 수 있다. 일 실시예에서, 요청 또는 응답에 대한 목표인 UA는, UA가 특정된 정책 URI 방식들의 정책 채널에 대해 허용된 MIME 유형들과 함께 지원하는 정책 URI 방식들의 목록을 UA가 SIP 등록 절차 동안에 전송한 SIP Register 요청 내에 포함시킴으로써 UA가 허용한 정책 문서의 MIME 유형 또는 정책 문서의 MIME 유형 마다의 변경/확장자들을 표시한다. 선택적으로, XML 스키마 확장자, 실행자, 또는 변경들을 표시하기 위해 스키마 버전 파라미터를 또한 추가할 수 있다. 다음에 오는 실시예에서, 지원되는 정책 URI 방식들의 목록을 전달하기 위하여 새로운 Contact 헤더 필드 파라미터 "+sip.supported-policy-scheme"가 정의된다. 특정된 정책 URI 방식에 대한 정책 채널에 대해 허용된 MIME 유형을 포함하는 파라미터와, XML 스키마 확장자 또는 실행자 또는 변경을 표시하는 스키마 버전 파라미터가 또한 SIP 등록부에 전달될 수 있다. UA는 SIP Register 요청의 SIP Contact 헤더 내에 +sip.supported-policy-scheme Contact 헤더 필드 파라미터를 포함시킬 수 있다. 예를 들어, Contact 헤더는:
Figure 112010054589354-pct00010
Figure 112010054589354-pct00011
일 수 있다.
RFC 3840의 신텍스에 따르기 위해 특정한 문자들이 누락될 수 있다. 또한, 다른 실시예들 및 변경예들이 가능함을 알아야 한다. 예를 들어, SIP 파라미터들이 SIP 헤더 대신에 이용될 수 있고 헤더 또는 파라미터들의 이름들이 변경될 수 있다. 신택스의 세부 내용 및 구조가 또한 변경될 수 있다.
그 후, SIP 등록부는 등록된 Address of Record로 바인딩된 Contact와 연관된 Contact 헤더 필드 파라미터들을 저장한다. SIP 요청이 등록부(또는 목표로 되는 UA를 서브하는 프록시 서버)에 도착할 때, 등록부 또는 프록시는 목표 UA의 Contact 어드레스와 연관된 MIME 유형(여기에 정책 문서를 표현하는 허용가능한 XML 문서들의 클래스를 정의하는 MIME 유형 마다의 선택적 심볼 세트들을 더한 것)과 함께 지원되는 정책 URI 방식들의 목록을 획득한다. 등록부 또는 프록시는 SIP Accept-Policy-Contact 헤더 내에 이들을 포함시키는데 이는 다음에 오는 것이 MIME 유형 및 정책 채널 URI 방식들의 목록에, SIP 메시지의 목표에 의해 지원되는 정책 문서들을 표현하는 허용가능한 XML 문서들의 클래스를 정의하는 심볼 세트를 더한 것을 포함하고 있음을 나타내는 목표 파라미터와 함께 SIP 요청 또는 SIP 응답에 추가한다. 예를 들어, Accept-Policy-Contact 헤더는:
Figure 112010054589354-pct00012
일 수 있다.
프록시 서버는 지원되는 가장 적합한 방식 및 관련 문서 버전을 Accept-Policy-Contact 헤더 내에 열거된 정책 채널 URI 방식들 및 관련 문서 버전들로부터 선택할 수 있다. 프록시 서버는 UA에 의해 정책 채널에 이용될 정책 서버와 UA 양쪽 모두에 의해 (의미론적으로) 이해되거나 또는 생성될 수 있는 정책 문서에 대한 지원되는 정책 URI들 및 MIME 유형(여기에 정책 문서들을 표현하는 허용가능한 XML 문서들의 클래스를 정의하는 MIME 유형 마다의 선택적 심볼 세트를 더한 것)에 기초하여 이를 결정한다. 프록시 서버는 발신하는 경우와 유사하게, SIP 메시지 내의 Policy-Contact 헤더 내에 선택된 URI와 관련 문서 버전을 포함시킨다. Policy-Contact 헤더를 포함하는 메시지를 수신시, 목표 UA는 발신한 UA에 대하여 설명된 방식과 유사한 방식으로 Policy-Contact 헤더 내에 정책 URI를 이용하여 정책 서버에 액세스할 수 있다. 목표 UA는 또한 자신이 지원하는 MIME 유형의 정책 문서를 획득할 수 있다.
다른 실시예들 및 변경예들이 가능함을 알아야 한다. 예를 들어, SIP 파라미터들이 SIP 헤더 대신에 이용될 수 있고 헤더 또는 파라미터들의 이름들이 변경될 수 있다. 신택스의 세부 내용 및 구조가 또한 변경될 수 있다.
도 3은 사용자 에이전트에 정책 정보를 제공하기 위한 방법(300)을 나타낸다. 블록 310에서, 사용자 에이전트는 사용자 에이전트가 정책 채널을 통한 통신을 지원하는 복수의 URI 방식들에 관련된 정보를 전송하고 사용자 에이전트가 지원하는 정책 정보의 복수의 표현과 관련된 정보를 전송한다. 블록 320에서, 사용자 에이전트는 복수의 URI 방식들 중 적어도 하나의 선택 및 정책 정보의 복수의 표현들 중 적어도 하나의 선택을 수신한다. 블록 330에서, 사용자 에이전트는 선택된 URI 방식들 중 적어도 하나를 이용하여 그리고 정책 정보의 선택된 표현들 중 적어도 하나를 이용하여 정책 정보를 획득한다.
UA(110)와 위에서 설명된 다른 컴포넌트들은 위에서 설명된 동작들과 관련된 명령들을 실행할 수 있는 처리 컴포넌트를 포함할 수 있다. 도 4는 여기에 설명된 하나 이상의 실시예들을 실시하는데 적합한 처리 컴포넌트(1310)를 포함하는 시스템(1300)의 일례를 나타낸다. (중앙 프로세서 유닛 또는 CPU라 부를 수 있는) 프로세서(1310)에 더하여, 시스템(1300)은 네트워크 연결 디바이스(1320), 랜덤 액세스 메모리(RAM; 1330), 읽기 전용 메모리(ROM; 1340), 2차 스토리지(1350) 및 입력/출력(I/O) 디바이스(1360)를 포함할 수 있다. 이들 컴포넌트는 버스(1370)를 통하여 서로 통신할 수 있다. 일부 경우에, 이들 컴포넌트들 중 일부는 존재하지 않을 수 도 있거나, 또는 도시되지 않은 다른 컴포넌트들과 또는 서로와 여러 조합으로 결합될 수도 있다. 이들 컴포넌트는 하나 보다 많은 물리적 엔티티에 또는 단일의 물리적 엔티티에 위치될 수 있다. 여기에 설명된 임의의 동작은 프로세서(1310)에 의해 단독으로 또는 디지털 신호 프로세서(digital signal processor; DSP; 1380)와 같이 도면에 도시된 또는 도시되지 않은 하나 이상의 컴포넌트들과 결합한 프로세서(1310)에 의해 행해질 수 있다. DSP(1380)가 개별 컴포넌트로서 도시되어 있지만 DSP(1380)는 프로세서(1310) 내에 통합될 수도 있다.
프로세서(1310)는 네트워크 연결 디바이스(1320), RAM(1330), ROM(1340) 또는 2차 스토리지(1350; 이는 하드 디스크, 플로피 디스크, 또는 광 디스크와 같이 여러가지 디스크 기반 시스템들을 포함할 수 있음)로부터 액세스할 수 있는 명령어, 코드, 컴퓨터 프로그램, 또는 스크립트들을 실행시킨다. 오직 하나의 CPU(1310)만이 도시되어 있지만, 복수의 프로세서들이 존재할 수 있다. 따라서, 명령들이 하나의 프로세서에 의해 실행되는 것으로서 설명될 수 있지만 명령들은 하나 또는 복수의 프로세스들에 의해 동시에, 연속적으로, 또는 다른 방식으로 실행될 수 있다. 프로세서(1310)는 하나 이상의 CPU 칩으로서 구현될 수 있다.
네트워크 연결 디바이스(1320)는 모뎀, 모뎀 뱅크, 이더넷 디바이스들, 유니버설 시리얼 버스(universal serial bus; USB) 인터페이스 디바이스, 시리얼 인터페이스, 토큰 링 디바이스, 피버 분산 데이터 인터페이스(fiber distributed data interface; FDDI) 디바이스들, 무선 근거리 통신(WLAN) 디바이스, 코드 분할 다중 접속(CDMA) 디바이스, GSM(global system for mobile communications) 무선 트랜시버 디바이스와 같은 무선 트랜시버 디바이스, WiMAX(worldwide interoperability for microwave access) 디바이스, xDSL(digital subscriber line) 디바이스, DOCSIS(data over cable service interface specification) 모뎀들 및/또는 다른 잘 알려진 네트워크 연결용 디바이스의 형태를 취할 수 있다. 이들 네트워크 연결 디바이스(1320)는 프로세서(1310)로 하여금 인터넷 또는 하나 이상의 원격 통신 네트워크 또는 프로세서(1310)가 정보를 수신하거나 또는 프로세서(1310)가 정보를 출력하는 다른 네트워크와 통신하게 할 수 있다.
네트워크 연결 디바이스(1320)는 또한 무선 주파수 신호 또는 마이크로웨이브 주파수 신호들과 같은 전자기파들의 형태로 무선으로 데이터를 송신 및/또는 수신할 수 있는 하나 이상의 트랜시버 컴포넌트들(1325)을 포함할 수 있다. 다른 방식으로, 데이터는 동축 케이블, 도파관, 광섬유와 같은 광학적 매질 또는 다른 매질 내의 전자 도체의 표면 상에서 또는 표면 내에서 전파할 수 있다. 트랜시버 컴포넌트(1325)는 단일의 트랜시버 또는 개별적인 전송 및 수신 유닛들을 포함할 수 있다. 트랜시버 컴포넌트(1325)에 의해 전송 또는 수신되는 정보는 프로세서(1310)에 의해 처리되었던 데이터, 또는 프로세서(1310)에 의해 실행될 명령들을 포함할 수 있다. 이러한 정보는 예를 들어, 컴퓨터 데이터 기저대역 신호 또는 반송파에서 구현된 신호의 형태로 네트워크에 출력 또는 네트워크로부터 수신될 수 있다. 데이터는 데이터를 발생 또는 처리하거나 데이터를 전송 또는 수신하기에 바람직할 수 있는 바와 같은 서로 다른 시퀀스에 따라 순서화될 수 있다. 기저대역 신호, 반송파에서 구현된 신호 또는 현재 이용되거나 이후에 개발될 다른 유형의 신호들은 전송 매체로서 불려질 수 있으며, 당해 기술 분야의 숙련된 자에게 잘 알려진 수개의 방법에 따라 발생될 수 있다.
RAM(1330)은 휘발성 데이터를 저장 또는 가능하다면, 프로세서(1310)에 의해 실행된 명령을 저장하는데 이용될 수 있다. ROM(1340)은 통상적으로 2차 스토리지(1350)의 메모리 용량 보다 더 작은 메모리 용량을 갖는 비휘발성 메모리 디바이스이다. ROM(1340)은 명령들 및, 가능하다면 명령들의 실행 동안에 판독된 데이터를 저장하는데 이용될 수 있다. RAM(1330)과 ROM(1340) 양쪽 모두에의 액세스는 통상적으로 2차 스토리지(1350) 보다 더 빠르다. 2차 스토리지(1350)는 통상적으로 하나 이상의 디스크 드라이브 또는 테이프 드라이브들로 구성되며 RAM(1330)이 모든 작업한 데이터를 유지하기에 충분치 못하다면, 오버-플로우 데이터 스토리지 디바이스로서 또는 데이터의 비휘발성 스토리지에 이용될 수 있다. 2차 스토리지(1350)는 RAM(1330) 내에 로딩되는 프로그램들이 실행을 선택될 때 이러한 프로그램들을 저장하는데 이용될 수 있다.
I/O 디바이스들(1360)은 액정 디스플레이(LCD), 터치 스크린 디스플레이, 키보드, 키패드, 스위치, 다이얼, 마우스, 트랙 볼, 음성 인식기, 카드 판독기, 페이퍼 테이프 판독기, 비디오 모니터, 또는 다른 잘 알려진 입력 디바이스를 포함할 수 있다. 또한, 트랜시버(1325)는 네트워크 연결 디바이스(1320)에 더하여 또는 네트워크 연결 디바이스(1320) 대신에 I/O 디바이스들(1360)의 컴포넌트이도록 구성될 수 있다.
다음에 오는 IETF 인터넷 드래프트가 그 전체 내용에서 복사되는 바와 같이, 여기서는 참조로서 포함된다.
Figure 112010054589354-pct00013
또한, 다음에 오는 SIP RFC들: RFC 3261 , RFC 3265, RFC 3312, RFC 3840, 및 RFC 4566이 그 전체 내용에서 복사되는 바와 같이 여기서는 참조로서 포함된다.
또한, 다음에 오는 3GPP TS들: TS 23.003, TS 23.228, 및 TS 24.229이 그 전체 내용에서 복사되는 바와 같이 여기서는 참조로서 포함된다.
일 실시예에서, 사용자 에이전트에 정책 정보를 제공하는 방법이 제공된다. 이 방법은 사용자 에이전트가, 정책 채널을 통한 통신을 위하여 사용자 에이전트가 지원하는 복수의 균일 자원 식별자(URI) 방식들에 관한 정보를 전송하는 것, 및 사용자 에이전트가 지원하는 정책 정보의 복수의 표현들에 관한 정보를 전송하는 것을 포함한다. 본 방법은 사용자 에이전트가 복수의 URI 방식들 중 적어도 하나의 선택 및 정책 정보의 복수의 표현들 중 적어도 하나의 선택의 표시를 수신하는 것을 더 포함한다. 본 방법은 사용자 에이전트가 정책 정보의 선택된 표현들 중 적어도 하나를 이용하여 그리고 선택된 URI 방식들 중 적어도 하나를 이용하여 정책 정보를 획득하는 것을 더 포함한다.
대안의 실시예에서, 사용자 에이전트가 제공된다. 사용자 에이전트는 정책 채널을 통한 통신을 위하여 사용자 에이전트가 지원하는 복수의 균일 자원 식별자(URI) 방식들에 관한 정보를 전송하고, 사용자 에이전트가 지원하는 정책 정보의 복수의 표현들에 관한 정보를 전송하도록 구성된 프로세서를 포함한다.
대안의 실시예에서, 네트워크 컴포넌트가 구성된다. 네트워크 컴포넌트는 정책 채널을 통한 통신을 위하여 사용자 에이전트가 지원하는 복수의 균일 자원 식별자(URI) 방식들에 관한 정보를 사용자 에이전트로부터 수신하고, 사용자 에이전트가 지원하는 정책 정보의 복수의 표현들에 관한 정보를 사용자 에이전트로부터 수신하도록 구성된 프로세서를 포함한다.
수개의 실시예들이 본 발명의 명세서에 제공되었지만, 개시된 시스템들 및 방법들은 본 발명의 범위 또는 범주를 벗어남이 없이 많은 다른 특정 형태로 구현될 수 있음을 알아야 한다. 본 예들은 예시적인 것으로 간주되어야 하며 제한적인 것으로 간주되어서는 안 되며, 본 발명은 본 명세서에 주어진 세부 내용으로 제한되지 않는다. 예를 들어, 여러 엘리먼트 또는 컴포넌트가 다른 시스템 내에 결합 또는 통합될 수 있거나 또는 특정 특징부들이 생략되거나 또는 실시되지 않을 수 있다.
또한, 여러 실시예들로 설명되어 예시된 기술, 시스템, 서브시스템 및 방법들이 본 발명의 범위에 벗어남이 없이 개별적으로 또는 별개의 것으로 다른 시스템, 모듈, 기술 또는 방법에 결합 또는 통합될 수 있다. 서로 통신 또는 직접 연결된 것으로서 나타내어지거나 설명되어 있는 다른 항목들이 전기적으로, 기계적으로 또는 다른 방식으로 일부 인터페이스, 디바이스 또는 중간 컴포넌트를 통하여 간접적으로 연결 또는 통신할 수 있다. 수정, 대체 및 변경의 다른 예들이 당해 기술 분야의 숙련된 자에게 이해될 수 있으며 본 명세서에 설명된 범위 및 사상에 벗어남이 없이 이루어질 수 있다.
110: 사용자 에이전트
120: 프록시
130: 정책 서버
140: 정책 집행부
210: Accept-Policy-Contact 헤더
230: Policy-Contact 헤더
1310: 프로세서
1320: 네트워크 연결 디바이스
1350: 2차 스토리지

Claims (38)

  1. 세션 개시 프로토콜(SIP: Session Initiation Protocol) 프레임워크에서 확장(extensions)을 해결하는 방법에 있어서,
    사용자 에이전트가, 정책 채널을 통하여 상기 사용자 에이전트가 지원하는 복수의 균일 자원 식별자(URI: Uniform Resource Identifier) 방식들에 관한 정보를 세션 개시 프로토콜(SIP) 컴포넌트에 전송하며, 상기 사용자 에이전트가 지원하는 정책 정보의 복수의 표현들에 관한 정보를 상기 사용자 에이전트가 상기 SIP 컴포넌트에 전송하고,
    상기 사용자 에이전트가, 상기 복수의 URI 방식들 중 적어도 하나의 선택 및 상기 정책 정보의 복수의 표현들 중 적어도 하나의 선택의 표시를 상기 SIP 컴포넌트로부터 수신하고,
    상기 사용자 에이전트가, 정책 정보의 선택된 표현들 중 적어도 하나를 이용하여 그리고 선택된 URI 방식들 중 적어도 하나를 이용하여 정책 정보를 획득하는 것
    을 포함하는 SIP 프레임워크에서 확장을 해결하는 방법.
  2. 제1항에 있어서, 상기 복수의 URI 방식들은,
    http(hypertext transfer protocol);
    https(hypertext transfer protocol secure);
    ftp(file transfer protocol);
    SIP(session initiation protocol);
    SIPS(session initiation protocol secure); 및
    URN(Uniform Resource Name)
    중 적어도 하나를 포함하는 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  3. 제1항에 있어서, 상기 정책 정보의 선택된 표현들 중 적어도 하나를 이용하여 그리고 선택된 URI 방식들 중 적어도 하나를 이용하여 정책 정보를 획득하는 것은, XCAP(XML Configuration Access Protocol)를 이용하여 정책 정보를 획득하는 것을 포함하는 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  4. 제1항에 있어서, 상기 사용자 에이전트는 상기 복수의 URI 방식들에 관한 정보와, 상기 정책 정보의 복수의 표현들에 관한 정보를 SIP 컴포넌트에 제1 SIP 헤더에서 전송하는 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  5. 제4항에 있어서, 상기 제1 SIP 헤더는 SIP Accept-Policy-Contact 헤더인 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  6. 제4항에 있어서, 상기 SIP 컴포넌트는 상기 복수의 URI 방식들 중 적어도 하나의 선택과 상기 정책 정보의 복수의 표현들 중 적어도 하나의 선택의 표시를 상기 사용자 에이전트에 제2 SIP 헤더에서 전송하는 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  7. 제6항에 있어서, 상기 제2 SIP 헤더는 SIP Policy-Contact 헤더인 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  8. 제1항에 있어서, 상기 사용자 에이전트는 상기 복수의 URI 방식들에 관한 정보와, 상기 정책 정보의 복수의 표현들에 관한 정보를 SIP Register 요청의 SIP Contact 헤더에서 파라미터로서 SIP 등록부(registrar) 서버에 전송하는 것을 포함하는 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  9. 제1항에 있어서, 상기 사용자 에이전트는 상기 복수의 URI 방식들에 관한 정보와, 상기 정책 정보의 복수의 표현들에 관한 정보를 SIP 세션에 대한 요청의 SIP Contact 헤더에서 파라미터로서 전송하는 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  10. 제1항에 있어서, 상기 정책 정보의 복수의 표현들에 관한 정보는 MIME(Multipurpose Internet Mail Extension) 유형으로서 명시되는 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  11. 제1항에 있어서, 상기 정책 채널을 통한 통신은,
    Policy Offer 문서;
    Policy Answer 문서;
    Session Policy 문서; 및
    XML(Extensible Markup Language)로 인코딩된 정책 문서
    중 적어도 하나를 반환하는 것을 포함하는 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  12. 제1항에 있어서, 상기 정책 채널을 통한 통신은 상기 정책 채널에 대응하는 미리 결정된 정책 문서를 교환하는 것을 포함하는 것인 SIP 프레임워크에서 확장을 해결하는 방법.
  13. 세션 개시 프로토콜(SIP: Session Initiation Protocol) 프레임워크에 대한 확장(extensions)을 해결하도록 구성된 사용자 에이전트에 있어서,
    정책 채널을 통한 통신을 위하여 상기 사용자 에이전트가 지원하는 복수의 균일 자원 식별자(URI; Uniform Resource Identifier) 방식들에 관한 정보를 전송하고 상기 사용자 에이전트가 지원하는 정책 정보의 복수의 표현들에 관한 정보를 전송하도록 구성된 프로세서를 포함하고,
    상기 프로세서는 또한, 상기 복수의 URI 방식들 중 적어도 하나의 선택 및 상기 정책 정보의 복수의 표현들 중 적어도 하나의 선택의 표시를 수신하고, 정책 정보를 획득하기 위해 선택된 URI 방식들 중 적어도 하나 그리고 상기 정책 정보의 선택된 표현들 중 적어도 하나를 이용하도록 구성되는 것인 사용자 에이전트.
  14. 삭제
  15. 제13항에 있어서, 상기 복수의 URI 방식들은,
    http(hypertext transfer protocol);
    https(hypertext transfer protocol secure);
    ftp(file transfer protocol);
    SIP(session initiation protocol);
    SIPS(session initiation protocol secure); 및
    URN(Uniform Resource Name)
    중 적어도 하나를 포함하는 것인 사용자 에이전트.
  16. 제13항에 있어서, 상기 선택된 URI 방식들 중 적어도 하나를 이용하여 그리고 상기 정책 정보의 선택된 표현들 중 적어도 하나를 이용하여 정책 정보를 획득하는 것은, XCAP(XML Configuration Access Protocol)을 이용하여 정책 정보를 획득하는 것을 포함하는 것인 사용자 에이전트.
  17. 제13항에 있어서, 상기 사용자 에이전트는 상기 복수의 URI 방식들에 관한 정보와, 상기 정책 정보의 복수의 표현들에 관한 정보를 SIP 컴포넌트에 제1 SIP 헤더에서 전송하는 것인 사용자 에이전트.
  18. 제17항에 있어서, 상기 제1 SIP 헤더는 SIP Accept-Policy-Contact 헤더인 것인 사용자 에이전트.
  19. 제13항에 있어서, 상기 사용자 에이전트는 상기 복수의 URI 방식들 중 적어도 하나의 선택과 상기 정책 정보의 복수의 표현들 중 적어도 하나의 선택의 표시를 제2 SIP 헤더에서 수신하는 것인 사용자 에이전트.
  20. 제19항에 있어서, 상기 제2 SIP 헤더는 SIP Policy-Contact 헤더인 것인 사용자 에이전트.
  21. 제13항에 있어서, 상기 사용자 에이전트는 상기 복수의 URI 방식들에 관한 정보와, 상기 정책 정보의 복수의 표현들에 관한 정보를 SIP Register 요청의 SIP Contact 헤더에서 파라미터로서 SIP 등록부(registrar) 서버에 전송하는 것인 사용자 에이전트.
  22. 제13항에 있어서, 상기 사용자 에이전트는 상기 복수의 URI 방식들에 관한 정보와, 상기 정책 정보의 복수의 표현들에 관한 정보를 SIP 세션에 대한 요청의 SIP Contact 헤더에서 파라미터로서 전송하는 것인 사용자 에이전트.
  23. 제13항에 있어서, 상기 정책 정보의 복수의 표현들에 관한 정보는 MIME(Multipurpose Internet Mail Extension) 유형으로서 명시되는 것인 사용자 에이전트.
  24. 제13항에 있어서, 상기 정책 채널을 통한 통신은,
    Policy Offer 문서;
    Policy Answer 문서;
    Session Policy 문서; 및
    XML(Extensible Markup Language)로 인코딩된 정책 문서
    중 적어도 하나를 반환하는 것을 포함하는 것인 사용자 에이전트.
  25. 제13항에 있어서, 상기 정책 채널을 통한 통신은 상기 정책 채널에 대응하는 미리 결정된 정책 문서를 교환하는 것을 포함하는 것인 사용자 에이전트.
  26. 세션 개시 프로토콜(SIP: Session Initiation Protocol) 프레임워크에 대한 확장(extensions)을 해결하도록 구성된 네트워크 컴포넌트에 있어서,
    정책 채널을 통한 통신을 위하여 사용자 에이전트가 지원하는 복수의 균일 자원 식별자(URI; Uniform Resource Identifier) 방식들에 관한 정보를 상기 사용자 에이전트로부터 수신하고, 상기 사용자 에이전트가 지원하는 정책 정보의 복수의 표현들에 관한 정보를 상기 사용자 에이전트로부터 수신하도록 구성된 프로세서를 포함하고,
    상기 프로세서는 또한, 상기 복수의 URI 방식들 중 적어도 하나와, 상기 정책 정보의 복수의 표현들 중 적어도 하나를 선택하고, 적어도 하나의 선택된 URI 방식과 적어도 하나의 선택된 정책 정보의 표현의 표시를 상기 사용자 에이전트에 전송하도록 구성된 것인 네트워크 컴포넌트.
  27. 삭제
  28. 제26항에 있어서, 상기 복수의 URI 방식들은,
    http(hypertext transfer protocol);
    https(hypertext transfer protocol secure);
    ftp(file transfer protocol);
    SIP(session initiation protocol);
    SIPS(session initiation protocol secure); 및
    URN(Uniform Resource Name)
    중 적어도 하나를 포함하는 것인 네트워크 컴포넌트.
  29. 제26항에 있어서, 상기 네트워크 컴포넌트는 제1 SIP 헤더에서 정보를 수신하는 것인 네트워크 컴포넌트.
  30. 제29항에 있어서, 상기 SIP 헤더는 SIP Accept-Policy-Contact 헤더인 것인 네트워크 컴포넌트.
  31. 제26항에 있어서, 상기 네트워크 컴포넌트는 상기 복수의 URI 방식들 중 적어도 하나의 선택과 상기 정책 정보의 표현들 중 적어도 하나의 선택의 표시를 상기 사용자 에이전트에 제2 SIP 헤더에서 전송하는 것인 네트워크 컴포넌트.
  32. 제31항에 있어서, 상기 제2 SIP 헤더는 SIP Policy-Contact 헤더인 것인 네트워크 컴포넌트.
  33. 제26항에 있어서, 상기 네트워크 컴포넌트는 상기 복수의 URI 방식들에 관한 정보와, 상기 정책 정보의 복수의 표현들에 관한 정보를 SIP Register 요청의 SIP Contact 헤더에서 파라미터로서 수신하는 것인 네트워크 컴포넌트.
  34. 제26항에 있어서, 상기 네트워크 컴포넌트는 상기 복수의 URI 방식들에 관한 정보와, 상기 정책 정보의 복수의 표현들에 관한 정보를 SIP 세션에 대한 요청의 SIP Contact 헤더에서 파라미터로서 수신하는 것인 네트워크 컴포넌트.
  35. 제26항에 있어서, 상기 정책 정보의 복수의 표현들에 관한 정보는 MIME(Multipurpose Internet Mail Extension) 유형으로서 명시되는 것인 네트워크 컴포넌트.
  36. 제26항에 있어서, 상기 정책 채널을 통한 통신은,
    Policy Offer 문서;
    Policy Answer 문서;
    Session Policy 문서; 및
    XML(Extensible Markup Language)로 인코딩된 정책 문서
    중 적어도 하나를 반환하는 것을 포함하는 것인 네트워크 컴포넌트.
  37. 제26항에 있어서, 상기 정책 채널을 통한 통신은 상기 정책 채널에 대응하는 미리 결정된 정책 문서를 교환하는 것을 포함하는 것인 네트워크 컴포넌트.
  38. 제26항에 있어서, 상기 네트워크 컴포넌트는,
    SIP 등록부(registrar) 서버;
    SIP 프록시 서버;
    SIP 사용자 에이전트; 및
    SIP 백투백 사용자 에이전트(SIP Back to Back User Agent)
    중 적어도 하나인 것인 네트워크 컴포넌트.
KR1020107018802A 2008-02-18 2009-02-18 Ｓｉｐ 세션 정책 프레임워크에 대한 확장을 해결하는 시스템 및 방법 KR101114707B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US2952308P 2008-02-18 2008-02-18
US61/029,523 2008-02-18

Publications (2)

Publication Number Publication Date
KR20100116196A KR20100116196A (ko) 2010-10-29
KR101114707B1 true KR101114707B1 (ko) 2012-03-02

Family

ID=40521397

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020107018802A KR101114707B1 (ko) 2008-02-18 2009-02-18 Ｓｉｐ 세션 정책 프레임워크에 대한 확장을 해결하는 시스템 및 방법

Country Status (6)

Country Link
US (1) US20090210478A1 (ko)
EP (1) EP2245534B1 (ko)
KR (1) KR101114707B1 (ko)
CN (1) CN102016801B (ko)
CA (1) CA2714628C (ko)
WO (1) WO2009105477A1 (ko)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102210132B (zh) 2008-11-10 2014-09-24 黑莓有限公司 使用现有授权架构和协议来支持sip会话策略的方法和系统
US9641564B2 (en) 2009-05-14 2017-05-02 Qualcomm Incorporated Maintaining controllee information in collaborative sessions
US9641567B2 (en) * 2009-05-14 2017-05-02 Qualcomm Incorporated Controlling media and informing controller status in collaborative sessions
EP2478683B1 (en) * 2009-09-17 2014-07-09 Telefonaktiebolaget LM Ericsson (publ) Method and node in a telecommunications network
CN102494751A (zh) * 2011-11-25 2012-06-13 罗正辉 一种电子秤
KR20130070308A (ko) * 2011-12-19 2013-06-27 삼성전자주식회사 동적 정책 제공을 위한 정책 결정 장치와 주소 변환 장치 사이의 연동을 위한 방법 및 장치
US9954904B2 (en) 2012-06-08 2018-04-24 Intel Deutschland Gmbh Communication devices and methods for operating a communication device
US10440159B2 (en) * 2017-08-03 2019-10-08 T-Mobile Usa, Inc. Header modification for supplementary services

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1117220A1 (en) * 2000-01-14 2001-07-18 Sun Microsystems, Inc. Method and system for protocol conversion
US6970869B1 (en) * 2000-05-09 2005-11-29 Sun Microsystems, Inc. Method and apparatus to discover services and negotiate capabilities
US20040111525A1 (en) * 2002-12-09 2004-06-10 International Business Machines Corporation Dynamic web service implementation discovery and selection apparatus and method
US7028101B2 (en) * 2003-03-25 2006-04-11 Nokia Corporation Optimal location service for managing next hop addressing for messages associated with multiple address schemes
CN1577251B (zh) * 2003-07-28 2012-07-18 国际商业机器公司 小服务器程序的远程协作方法和系统
FI20040577A0 (fi) * 2004-04-23 2004-04-23 Nokia Corp Tiedon toimittaminen tietoliikennejärjestelmän resurssista
US8700729B2 (en) * 2005-01-21 2014-04-15 Robin Dua Method and apparatus for managing credentials through a wireless network
US8542671B2 (en) * 2006-09-29 2013-09-24 Oracle International Corporation Service provider functionality with policy enforcement functional layer bound to SIP
US7788383B2 (en) * 2007-10-30 2010-08-31 Cisco Technology, Inc. Communicating a selection of a potential configuration

Also Published As

Publication number Publication date
CA2714628C (en) 2016-04-12
CN102016801A (zh) 2011-04-13
EP2245534B1 (en) 2015-09-16
EP2245534A1 (en) 2010-11-03
US20090210478A1 (en) 2009-08-20
CA2714628A1 (en) 2009-08-27
WO2009105477A1 (en) 2009-08-27
CN102016801B (zh) 2014-10-15
KR20100116196A (ko) 2010-10-29

Similar Documents

Publication Publication Date Title
US9967348B2 (en) Methods and apparatus for providing session policy during a registration of a device
KR101114707B1 (ko) Ｓｉｐ 세션 정책 프레임워크에 대한 확장을 해결하는 시스템 및 방법
JP5282095B2 (ja) マルチメディア通信セッションの確立
KR101210774B1 (ko) 디바이스 및 서버 능력을 전달하는 방법
US20090210538A1 (en) System and Method for Indicating Supported Session Policy URI Schemes Extensions
AU2004306243B2 (en) Method and system for providing a secure communication between communication networks
US9596270B2 (en) Secure XDM communication between IMS networks
JP2011505084A (ja) 通信ネットワークにおいて使用するための方法および装置
Baba et al. Web-IMS convergence architecture and prototype
Häber et al. Evaluation of frameworks for creating end-to-end mobile services with OMA MMS as a use case

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20150126

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20160122

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20170125

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20180125

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20190123

Year of fee payment: 8