KR20080099237A

KR20080099237A - 세션 개시 프로토콜(ｓｉｐ) 멀티캐스트 운영 방법

Info

Publication number: KR20080099237A
Application number: KR1020087016563A
Authority: KR
Inventors: 쉥 선; 웬 빙; 에릭 우
Original assignee: 노오텔 네트웍스 리미티드
Priority date: 2005-12-08
Filing date: 2005-12-08
Publication date: 2008-11-12
Anticipated expiration: 2025-12-08
Also published as: CN101443749B; WO2007067176A3; KR101215683B1; EP1958080A2; WO2007067176A2; CN101443749A; US20080288458A1; EP1958080A4

Abstract

인터넷 프로토콜 네트워크를 통해 실시간 미디어 컨텐트를 얻기 위한 방법 및 시스템이 설명된다. 프록시 서버는 미디어 컨텐트의 스트림을 얻기 위해 미디어 서버와 통신이 확립되기를 요청하는 클라이언트 장치로부터의 메시지를 수신한다. 프록시 서버는, 요청된 미디어 컨텐트가 로컬 응답 포인트로부터 이용가능하다면, 클라이언트 장치에 대한 응답으로 재지정 메시지를 클라이언트 장치에 보낸다. 재지정 메시지는 미디어 컨텐트의 스트림을 얻기 위해 로컬 응답 포인트와 통신하도록 클라이언트 장치에 명령한다.

인터넷 프로토콜 네트워크, 실시간 미디어 컨텐트, 프록시 서버, 재지정 메시지, 로컬 응답 포인트

Description

세션 개시 프로토콜(ＳＩＰ) 멀티캐스트 운영 방법{SESSION INITIATION PROTOCOL (SIP) MULTICAST MANAGEMENT METHOD}

본 발명은 일반적으로 멀티미디어 컨텐트를 인터넷 프로토콜(IP) 네트워크를 통해 가입자들에게 배포하는 것에 관한 것이다. 더 구체적으로, 본 발명은 점대점(point-to-point) 제어 시그널링 프로토콜을 이용하는 멀티캐스트 멀티미디어 애플리케이션들의 배포에 관한 것이다.

인터넷 프로토콜 텔레비젼(IPTV)과 같은, 광대역 오락 서비스들에 대한 가입자들의 수가 활발히 증가할 것으로 현재 예상된다. IPTV는 광대역 서비스 공급자들이 인터넷 프로토콜(IP)을 이용하여 광대역 접속들을 통해 디지털 방송 텔레비젼을 배포하는 시스템이다. 현재, IP 멀티캐스팅은 서비스 공급자들이 네트워크를 통해 IPTV 스트림들(즉, 채널들)을 전송하는 전형적인 메커니즘이다. 채널들을 스위칭하기 위해 통상적으로 이용되는 멀티캐스팅 프로토콜은 IGMP(Internet Group Management Protocol)이다.

멀티미디어 애플리케이션들과 이용하기 위해 인기를 얻고 있는 다른 프로토콜은 세션 개시 프로토콜(Session Initiation Protocol: SIP)이다. 많은 서비스 공급자들은 SIP를 그의 융통성과 확장성 때문에 멀티미디어 애플리케이션들을 위해 정선된 제어 시그널링 프로토콜로 여긴다. 현재의 추세는 채널 변경을 실행하기 위해 SIP 세션들과 IGMP 프로세스들을 결합하는 것이다.

그러나, IPTV 가입자들 중에는, 경험의 질(quality of experience: QoE)에 대한 기대가 높다. 그러므로, SIP와 관련되는 임의의 솔루션은 정규의 케이블 및 위성 텔레비전의 가입자들에 의해 현재 즐겨지는 경험의 질과 경쟁할 필요가 있다. IPTV가 그러한 기존의 텔레비전 서비스들과 경쟁하기 위해서는, 채널 변경 동안 경험되는 임의의 지연이 최소일 필요가 있다. 그러나, SIP의 점대점 성질과, 잠재적으로 가입자들로부터의 많은 양의 동시적인 채널 변경 요청들은, 특히 각각의 채널 변경이 SIP 세션들과 IGMP 프로세스들의 체인을 해체하고 편제하는 것을 초래한다면, IPTV 시스템의 성능에 심각하게 영향을 미칠 수 있다. 그러므로, 멀티캐스트 기반 멀티미디어 애플리케이션들을 위해서 광대역 접속을 통해 SIP를 이용하기 위한 장려(incentives)가 있지만, 이 프로토콜의 특정 양상들은 그의 대규모의 채택을 방해한다.

일 양상에 있어서, 본 발명은 실시간 미디어 컨텐트를 인터넷 프로토콜 네트워크를 통해 얻는 방법의 특징을 이룬다. 프록시 서버(proxy server)는 미디어 컨텐트의 스트림을 얻기 위해 미디어 서버와 통신이 확립되기를 요청하는 클라이언트 장치로부터의 메시지를 수신한다. 프록시 서버는 요청된 미디어 컨텐트가 로컬 응답 포인트로부터 이용가능(available)하면 클라이언트 장치로부터의 메시지에 대한 응답으로 재지정(redirection) 메시지를 클라이언트 장치에 보낸다. 재지정 메시지는 미디어 컨텐트의 스트림을 얻기 위해 로컬 응답 포인트와 통신하도록 클라이언트 장치에 명령한다.

다른 양상에 있어서, 본 발명은 실시간 미디어 컨텐트를 배포하기 위한 네트워크의 특징을 이룬다. 네트워크는 미디어 서버, 상기 미디어 서버와 통신하는 로컬 응답 포인트, 클라이언트 장치와 통신하는 프록시 서버를 포함한다. 프록시 서버는 미디어 컨텐트의 특정 스트림을 얻기 위해 미디어 서버와 통신이 확립되기를 요청하는 클라이언트 장치로부터의 메시지를 수신한다. 프록시 서버는 요청된 미디어 컨텐트가 로컬 응답 포인트에서 이용가능(available)하면 클라이언트 장치로부터의 메시지에 대한 응답으로 재지정(redirection) 메시지를 클라이언트 장치에 보낸다. 재지정 메시지는 미디어 컨텐트의 특정 스트림을 얻기 위해 로컬 응답 포인트와 통신을 확립하도록 클라이언트 장치에 명령한다.

또 다른 양상에 있어서, 본 발명은 액세스 네트워크를 통해 클라이언트 장치와 통신하는 프록시 에이전트를 갖는 네트워크 장치의 특징을 이룬다. 프록시 에이전트는 미디어 컨텐트의 스트림을 얻기 위해 미디어 서버와 통신이 확립되기를 요청하는 클라이언트 장치로부터의 메시지를 수신한다. 프록시 에이전트는 미디어 컨텐트가 캐시(cache) 서버로부터 이용가능하면 클라이언트 장치로부터의 메시지에 대한 응답으로 재지정(redirection) 메시지를 클라이언트 장치에 보낸다. 재지정 메시지는 미디어 컨텐트의 요청된 스트림을 얻기 위해 캐시 서버와 통신하도록 클라이언트 장치에 명령한다.

본 발명의 상기의 그리고 그 이상의 이점들은, 다양한 도면들에 있어서 유사한 구성 요소들 및 특징들에 유사한 참조 번호들이 병기되는, 첨부 도면들과 함께 다음의 설명을 참조함으로써 더 잘 이해될 수 있다. 도면들은 본 발명의 원리들을 도시할 때 반드시 축척에 따라 도시될 필요는 없고 대신 강조된다.

도 1은 본 발명의 양상들이 실시될 수 있는 예시적인 네트워킹 환경의 블럭도이다.

도 2는 클라이언트 장치, 프록시 서버, 로컬 응답 포인트, 위치 서버, 및 미디어 서버를 포함하는, 도 1의 네트워킹 환경의 일부의 블럭도이다.

도 3은 본 발명에 따라 미디어 컨텐트를 얻기 위해 클라이언트 장치로부터의 요청을 미디어 서버에 전달하는 프로세스의 실시예의 순서도이다.

도 4는 미디어 서버가 클라이언트 장치로부터의 요청에 응답하는, 도 2에 도시된 네트워킹 환경의 일부의 블럭도이다.

도 5는 본 발명에 따라 클라이언트 장치로부터의 요청에 응답하는 프로세스의 실시예의 순서도이다.

도 6은 프록시 서버가 이전에 요청되어 로컬 응답 포인트에 저장된 동일한 미디어 컨텐트를 얻기 위해 제2 클라이언트 장치를 로컬 응답 포인트로 방향을 고쳐 지향시키는(redirect), 도 1에 도시된 네트워킹 환경의 일부의 블럭도이다.

도 7은 본 발명에 따라 제2 클라이언트 장치로부터(도 6)의 요청을 로컬 응답 포인트로 방향을 고쳐 지향시키는 프로세스의 실시예의 순서도이다.

본 발명을 실시하는 시스템들 및 방법들은 IGMP(Internet Group Management Protocol)와 같은 멀티캐스팅 프로토콜을 이용하지 않고서 인터넷 프로토콜(IP) 네트워크를 통해 다수의 동시적인 가입자들에 대한 멀티미디어 컨텐트의 실시간 배포를 달성할 수 있다. 본 명세서에서 설명되는 바와 같이, 클라이언트 장치들과 서버들은 IP 네트워크를 통해 멀티미디어 컨텐트를 요청하고, 찾고, 배송(deliver)하고, 수신하기 위해, 세션 개시 프로토콜(SIP)에 의해 예시되는, 점대점 시그널링 프로토콜을 이용하여 통신한다. 인터넷 프로토콜 텔레비젼(IPTV)은 본 발명의 실시로부터 이익을 얻을 수 있는 실시간 멀티미디어 애플리케이션의 예로서, 본 명세서에서 본 발명의 원리들을 설명하기 위해 이용된다.

IPTV 시스템은 많은 동시적인 시청자들을 가질 것으로 예상할 수 있으며, 각각의 시청자는 선택할 많은 방송 TV 채널들을 갖는다. 어떤 IPTV 시스템들에 있어서는, 시청자에 의해 선택된 채널들만이 고객 구내(premises)에 배포된다. 많은 TV 채널들은 다수의 동시적인 시청자들을 가지고 있다(enjoy). 따라서, 그러한 채널들은 다수의 고객 구내에 배포된다. 본 발명에 따르면, 임의의 가입자가 주어진 채널을 처음으로 선택할 때, 채널 컨텐트에 대한 요청이 그 가입자(즉, 클라이언트 장치)로부터 미디어 소스(media source)로 건너간다. 응답으로, 미디어 소스는 대응하는 컨텐트를 캐시 서버(또한, 이하에서 응답 포인트로서 일컬어짐)에 배송하거나 또는 배송을 야기하는데, 가입자는 캐시 서버로부터 컨텐트를 얻는다.

제2 가입자에 의한 그 채널의 후속적인 선택 시에, 프록시는 제2 가입자를 응답 포인트에서부터 컨텐트를 얻도록 방향을 고쳐 지향시킨다. 제1 가입자에 의 한 최초의 요청 때문에, 응답 포인트는 이미 요망되는 컨텐트를 수신하고 있다. 그 결과, 제2 가입자(즉, 그의 클라이언트 장치)는 채널 컨텐트를 수신하기 위해 미디어 소스와 통신을 확립할 필요가 없다. 재지정 메커니즘을 지원하기 위해, 본 발명의 일 실시예는 RFC 3261에 정의된 세션 개시 프로토콜을 새로운 재지정 방법을 이용하여 향상시킨다. "SIP: 세션 개시 프로토콜"이란 제목의 RFC 3261의 전체가 본 명세서에 참고로 포괄된다. 새로운 재지정 방법은, 타입 넘버를 포함하고(그 넘버가 기존의 재지정 타입들의 중복이 아니라면, 300에서 400까지 범위 내의 임의의 넘버(예를 들어, 310)), 요청된 컨텐트를 얻기 위해 제2 가입자에 의해 이용될 응답 포인트의 어드레스를(예, 컨택트 필드 혹은 메시지 본문 내에) 포함한다.

재지정 메커니즘 때문에, 본래의 멀티캐스트 프로토콜의 이용은 불필요해지고, 그 대신 방향을 고쳐 지향시켜진 각각의 가입자는 "캐시된(cached)" 컨텐트를 얻기 위해 응답 포인트와 점대점 통신 경로를 확립할 수 있다. 재지정을 통한 컨텐트의 배포는 동시적인 가입자들의 수의 증가로써 평가하고, 미디어 소스에서 네트워크 트래픽을 줄이고, 실패의 싱글 포인트로서의 미디어 소스를 제거한다. 또한, 재지정 메커니즘은, 아래에 더 상세히 설명되는 바와 같이, 사용자 경험을 불쾌하게 하지 않도록 충분히 빠른 채널 변경들을 달성할 수 있다.

도 1은 본 발명이 실시될 수 있는 네트워킹 환경(10)의 실시예를 도시한다. 네트워킹 환경(10)은 홈 네트워크들(12, 12'), 액세스 네트워크(14), 코어 IP 네트워크(16), 관리 네트워크(18), 비디오 전파중계(head-end) 네트워크(20), 및 중앙 오피스(22)를 포함한다. 네트워킹 환경(10)의 다양한 네트워크들은 실시간 멀티미디어 컨텐트를 가입자들에게 배포하기 위해 협동한다. 이 설명은 디지털 방송 텔레비젼 서비스(즉, IPTV)의 가입자들에 대한 TV 채널들의 배송에 적용된 본 발명의 원리를 예시한다. 본 발명의 원리들은 다른 미디어-배송 애플리케이션들, 예를 들면, 보이스 오버 IP(voice over IP: VoIP), 주문형 비디오(video-on-demand: VoD)로 확장할 수 있다.

홈 네트워크들(12, 12')은 고객 구내 상에 상주하고, 셋-탑 박스들, 퍼스널 컴퓨터들, 라우터들, 모뎀들, 기타 등등과 같은 고객 장비를 포함한다. 일반적으로, 홈 네트워크들은 다양한 토폴로지들과 고객 장비를 가질 수 있다. 설명을 간편하게 하기 위해, 각각의 홈 네트워크(12, 12')는 하나의 셋-탑 박스(4, 4')를 각각 갖는 것으로 도시되고, 그 각각은 디지털 텔레비전 세트에 연결된다.

셋-탑 박스들(4, 4')은 일반적으로 클라이언트 장치들을 일컫는데, IPTV 트래픽을 끝내는 엔드포인트들(endpoints)(즉, 광대역 네트워크 말단)로서 동작한다. 세션 개시 프로토콜(SIP) 사용자 에이전트(UA)는 본 명세서에서 설명되는 바와 같이, 실시간 멀티미디어 컨텐트를 요청할 때 프록시 서버(24)와 통신하기 위해 각각의 셋-탑 박스(4, 4') 상에서 실행한다. 셋-탑 박스들(4, 4')을 통해 텔레비전 시청자들은 채널들을 선택하고 변경하는 요청들을 송신한다. 채널 변경들은 SIP 메시지들로서 셋-탑 박스들(4, 4')로부터 발행된다.

액세스 네트워크(14)는 홈 네트워크들(12, 12')을 코어 IP 네트워크(16)와 링크한다. 또한, "최후 마일(last miles)"로서 일컬어지기도 하는데, 액세스 네트 워크(14)는 홈 네트워크들(12, 12')이 멀티미디어 컨텐트를 구하기 위해 원격 미디어(혹은 컨텐트) 서버들과 통신할 수 있는 광대역 접속을 제공한다. 클라이언트 장치들은 다양한 기술들 중 임의의 하나를 통해 광대역 접속을 확립할 수 있는데, 그러한 기술들 중 하나는 디지털 가입자 라인(Digital Subscriber Line: DSL)이다. DSL을 지원하기 위해, 예를 들면, 액세스 네트워크(14)는 다수의 고객들로부터의 DSL 접속들을 싱글 백본(backbone) 라인에 모으기 위해 하나 이상의 디지털 가입자 라인 액세스 멀티플렉서들(Digital Subscriber Line Access Multiplexers: DSLAMs)을 포함한다.

운영되는 IP 코어 네트워크(16)는, 일반적으로, 미디어 및 컨텐트 서버들로부터 고객 구내로 신뢰할 수 있고 적시의 IPTV 데이터 스트림들의 배포를 제공한다. 코어 네트워크(16)는 광 배포 백본 네트워크(optical distribution backbone network)를 포함할 수 있다. 코어 네트워크(16) 내의 프록시 서버(24)는 클라이언트 장치들(4, 4')의 도메인(또는 도메인들)을 서비스한다. 프록시 콜 세션 제어 함수(Proxy Call Session Control Function) 혹은 P-CSCF를 제공하는 SIP 서버로서 동작하면서, 프록시 서버(24)는 클라이언트 장치들(4, 4')로부터 SIP 메시지들을 수신하고, 이 메시지들을 그들 대신 전달한다. 각각의 클라이언트 장치(4, 4')는 프록시 서버(24)와의 통신을 용이하게 하기 위해 프록시 서버(24)의 어드레스로 사전-구성(pre-configured)(즉, 사전-프로그래밍(pre-programmed))될 수 있다. 대안적으로, 클라이언트 장치들(4, 4')은, 예를 들면, DHCP(Dynamic Host Configuration Protocol)에 의해 프록시 서버(24)의 어드레스를 발견할 수 있다.

관리 네트워크(18)는 SIP 서버들(26, 28), 홈 가입자 서버(HSS)(29), 및 미디어 서버(30)(애플리케이션 서버들의 클러스터)를 포함한다. 비록 도 1에는 분리된 노드들로서 도시되었지만, HSS와 SIP 서버들은 싱글 노드 내에 구현될 수 있다. HSS(29)는 사용자 프로파일들을 포함하는 마스터 사용자 데이터베이스(master user database)를 보유한다. HSS(29)는 인증과 허가를 수행할 수 있고, 사용자의 물리적 위치에 관한 정보를 제공할 수 있다.

SIP 서버들(26, 28)은 사용자 위치 정보(사용자 프로파일들)를 얻기 위해 HSS(29)와 통신한다. 일반적으로, SIP 서버(26)는 응답지령 콜 세션 제어 함수(Interrogating Call Session Control Function) (혹은 I-CSCF)를 제공하고, SIP 서버(28)는 서빙 콜 세션 제어 함수(Serving Call Session Control Function)(혹은 S-CSCF)를 제공한다. 프록시 서버(24)는 주어진 SIP 메시지를 전달하기 위한 타겟 S-CSCF 서버를 식별하기 위해 I-CSCF 서버와 통신한다. S-CSCF 서버(28)는 사용자들의 서비스 특권들을 식별하고 주어진 SIP 메시지를 미디어 서버(30)의 어느 애플리케이션 서버에 전달할지를 결정한다. 미디어 서버(30)는 홈 네트워크들(12, 12')에 배송될 멀티미디어 컨텐트(즉, 방송 IPTV 채널들)의 공급원이다. 전형적으로, 하나의 IPTV 데이터 스트림이 프로그래밍의 각각의 채널을 위해 코어 IP 네트워크(16)를 횡단한다. 중앙 오피스(22)는 아래에 더 상세히 설명되는 바와 같이, IPTV 데이터 스트림들을 수신하기 위한 로컬 응답 포인트(34)를 포함한다. (응답 포인트를 로컬이라고 일컫는 것은 응답 포인트의 바람직한 지리적 배치가 고객 구내 장비의 부근 이내임을 예시한다. 일반적으로, 응답 포인트들 - 하나보다 많을 수 있음 - 은 프록시 서버와 함께 로컬 중앙 오피스에 배치된다.)

비디오 전파중계 네트워크(20)는, 예를 들면 방송자(broadcaster)(또는 프로그래머)로부터 또는 수집기(aggregator)로부터 직접 위성을 통해, 프로그래밍의 스트림들을 수신하는 컨텐트 서버(32)를 포함한다. 컨텐트 서버(32)는 프로그래밍의 각각의 개별 채널을 얻고, 그의 멀티미디어 컨텐트를 디지털 비디오 포맷으로 인코드하고, 컨텐트를 데이터베이스에 저장한다. 미디어 서버(30)는 컨텐트 서버(32)로부터 중앙 오피스에 있는 응답 포인트로 멀티미디어 컨텐트의 배송을 지령하기 위해 컨텐트 서버(32)와 통신한다.

도 2는 클라이언트 장치들 중 하나(4), 프록시 서버(24), 로컬 응답 포인트(34), 위치 서버(26, 28), 및 미디어 서버(30)를 포함하는, 도 1의 네트워킹 환경의 일부를 도시한다. 클라이언트 장치(4)는 사용자 에이전트 클라이언트(UAC) 소프트웨어(50)와, IP 네트워크를 통해 오디오 및 비디오 데이터를 수신하기 위한 통신 경로를 확립하는 RTP(Real-Time Transport Protocol), RTCP(Real-Time Transport Control Protocol), RTSP(Real-Time Transport Streaming Protocol) 프로시저들을 갖는 프로토콜 스택(52)을 포함한다.

미디어 서버(30)는 사용자 에이전트 서버(UAS) 소프트웨어(62)와, IP 네트워크를 통해 컨텐트를 방송하기 위한 RTP, RTCP, 및 RTSP 프로시져들을 갖는 프로토콜 스택(64)을 포함한다. 일반적으로, 컨텐트 서버(32)는 프로토콜 스택(64)을 포함하고, 미디어 서버(30)는 컨텐트 서버(32)에게 응답 포인트(34)와 RTP를 확립하도록 명령한다 - 여기서는, 설명을 간편하게 하기 위해 프로토콜 스택(64)이 미디 어 서버(30)의 일부로서 도시된다. 미디어 서버(30)는 URI(Uniform Resource Identifier), 예를 들면, mediaserver@domain.com과 연관된다. 데이터베이스(66)는 미디어 서버(30)에서 이용가능한 채널들의 리스트(예, CNN@domain.com, CBS@domain.com, 및 TSN@domain.com)를 보유한다.

프록시 서버(24)는 클라이언트 장치(4)의 UAC(50)와 통신하기 위한 로컬 프록시 코드(54)와, 미디어 서버(30)의 UAS와 통신하기 위한 로컬 프록시 코드(58)를 포함한다. UAC(50)로부터의 요청들을 처리하기 위해, 프록시 서버(24)의 구성(configuration)은 상태적(Stateful)으로 설정되는데, 이는 프록시 서버(24)를 SIP 트랜잭션-처리 엔진으로서 구성한다. 부가적으로, 프록시 서버(24)는 로컬 응답 포인트(34)가 현재 저장하고 있는 컨텐트에 대한 채널들을 나타내는 엔트리들을 기록하기 위한 로컬 프로그램 테이블(60)(즉, 데이터베이스)을 포함한다. 각각의 테이블 엔트리에 대해, 로컬 프로그램 테이블(60)은 또한 그 엔트리가 실효 있는 것(active)인지 만료된 것인지를 지시한다. 실효 있는 상태는 연관되는 채널에 대응하는 IPTV 스트림이 로컬 응답 포인트(34)에서 이용가능하다는 것을 지시한다. 만료된 상태는 연관된 채널의 컨텐트를 보기 위한 시간이 지났고, 따라서 컨텐트가 이용가능하지 않다는 것을 지시한다.

간략한 개관에서, 클라이언트 장치에의 실시간 멀티미디어 컨텐트의 배포는 전달 위상(forwarding phase), 응답 위상(response phase), 및 재지정 위상(redirection phase)으로 발생한다고 고려될 수 있다. 이들 위상들 중 어떤 것이 주어진 요청에 대하여 발생할지는, IPTV 채널을 요청하는 클라이언트 장치가 IPTV 채널의 제1 요청자인지 또는 후속적인 요청자인지에 의존한다.

도 3은 SIP를 이용하여 실시간 멀티미디어 컨텐트를 얻기 위해 클라이언트 장치(4)가 미디어 서버(30)에 요청을 보내는 전달 위상의 실시예를 도시한다. 전달 위상의 설명에서, 도 1 및 도 2를 또한 참조한다. 단계 70에서, 클라이언트 장치(4)의 사용자는 채널(예, CNN)을 선택하고, 클라이언트 장치(4)의 UAC(50)(여기서, 셋-탑 박스)는 SIP 인바이트(INVITE) 요청을 액세스 네트워크(14)를 통해 프록시 서버(24)에 송신한다. SIP 인바이트 요청은 클라이언트 장치(4)가 미디어 서버(30)에 수행하기를 원하는, 즉 지정된 채널의 컨텐트를 얻기 위해, 수행하기를 원하는, 특별한 동작을 지정하는 SIP 방법의 한 타입이다. SIP 인바이트 요청은 복수의 헤더 필드들, 요청 라인, 및 타임스탬프를 포함한다. 헤더 필드들은 To, From, 및 Cseq(Command Sequence)를 포함한다. 수신자 필드(To field)는 요청이 원래 지향되는(directed) SIP URI를 포함하고, 송신자 필드(From field)는 발신하는 클라이언트 장치의 SIP URI를 포함하고, CSeq은 SIP 다이얼로그(dialog) 내에서 각각의 요청에 대해 증분되는 정수 값을 포함한다.

요청 라인은 SIP 방법(예, 인바이트(INVITE)) 및 요청-URI을 포함한다. 요청-URI는 요청을 처리할 UAS를 식별한다. SIP 인바이트 요청에서, 요청-URI는 타겟 채널의 URI, 또는, 바람직하게, 미디어 서버(30)의 URI일 수 있다. 요청-URI로서 미디어 서버(30)의 URI를 지정하는 것은 타겟 채널의 URI를 지정하는 것보다 더 유리하다.

예를 들어 클라이언트 장치(4)가 SIP 세션을 타겟 채널과 확립하면, 채널을 변경하기 위한 요청은 타겟 채널과의 이 세션을 중단하고 새로운 타겟 채널로 새로운 세션을 확립할 것이 필요하다. 이 중단 및 재확립은 채널 변경 프로세스를 지연시킬 수 있다. 이와 반대로, 클라이언트 장치(4)가 SIP 세션을 미디어 서버(30)와 확립하면, 채널을 변경하기 위한 요청은 기존의 세션의 다이얼로그 내에서 통신된다. 미디어 서버(30)와의 세션은 채널 변경에 걸쳐 지속된다 - 기존의 세션의 중단이 없다. 그 결과, 채널 변경은 세션들의 중단 및 재확립과 연관된 지연을 발생시키지 않는다.

미디어 서버(30)와의 통신을 용이하게 하기 위해, 클라이언트 장치(4)의 UAC(50)는 인바이트 요청의 요청-URI 내에 미디어 서버(30)의 SIP URI를 포함하도록 사전-프로그램될 수 있다. 요청-URI가 미디어 서버(30)의 URI를 지정할 때, SIP 인바이트의 패이로드(payload)는 타겟 채널의 URI를 반송한다.

단계 72에서, 로컬 프록시(54)는 SIP 인바이트 요청을 수신하여 파스(parse)하고, 위치 서버들(26, 28)과 통신함에 의해 요청자가 유효한지(인증 및 허가)를 결정한다. 단계 74에서, 프록시 서버(24)는 로컬 프로그램 테이블(60)을 검색하여 요청된 채널에 대한 엔트리가 존재하는지를 결정한다. 엔트리가 발견되지 않는다면(즉, 이것이 이 특정 채널에 대한 최초의 요청이라면), 프록시 서버(24)는 그 자신을 SIP 인바이트 요청의 레코드-라우트 헤더(Record-Route header)에 추가한다(단계 76). 그의 어드레스를 레코드-라우트 헤더에 삽입함으로써, 프록시 서버(24)는 다이얼로그에서 미래의 요청들의 라우팅이 프록시 서버(24)를 통과하도록 야기한다.

부가적으로, 프록시 서버(24)는 요청된 컨텐트를 미디어 서버(30)로부터 수신하는 프록시로서 동작하기 위한 로컬 응답 포인트(34)를 선택한다(단계 78). (다수의 로컬 응답 포인트들(34)이 프록시 서버(24)에 이용가능할 수 있으며, 그 중에서 프록시 서버(24)는 컨텐트를 수신할 하나의 로컬 응답 포인트(34)를 선택한다. 프록시 서버(24)는 이 로컬 응답 포인트들(34)을 나타내는 엔트리들을 갖는 데이터베이스를 보유할 수 있다.) 선택은 임의적이거나 미리 결정될 수 있다. 선택된 로컬 응답 포인트(34)의 어드레스는 인바이트 요청의 일부가 된다 - 프록시 서버(24)는 선택된 로컬 응답 포인트(34)의 어드레스를 인바이트 요청에 추가한다 -.

프록시 서버(24)는 또한 요청을 수신할 미디어 서버(30)의 URI를 결정하기 위해 위치 서버들(26, 28)과 통신한다(단계 80). (클라이언트 장치(4)에 의해 이용되는 미디어 서버(30)의 URI는 보편적이다(generic). 보편적인 URI로부터, 위치 서버들(26, 28)은 보편적인 URI를 클러스터 내의 특정 서버로 중재하고(mediate) 결정한다(resolve). 각각의 미디어 서버는 그 자체의 고유 URI를 갖고 있어서, 다수의 채널 변경들에 걸쳐 지속되는 주어진 미디어 서버와의 세션들이 확립될 수 있다. 위치 서버들(26, 28)은 미디어 서버들(30)의 클러스터 내의 어느 서버가 무슨 채널들을 서비스하는지, 그리고 미디어 서버들 중 어떤 것이 요청된 컨텐트를 가장 잘 공급할 수 있는지를 지시하는 최신 정보를 보유한다. 위치 서버들(26, 28)은 이 특정 미디어 서버의 URI로 프록시 서버(24)에 응답한다. 프록시 서버(24)는 원래의 목적지 URI를 결정된 미디어 서버의 URI로 대체한다. 단계 82에서, 프록시 서버(24)는 인바이트 요청을 결정된 미디어 서버(30)에 전달한다.

도 4 및 도 5는 미디어 서버(30)가 클라이언트 장치(4)로부터의 인바이트 요청에 대해 응답하는, 응답 위상의 실시예를 도시한다. 단계 100에서, 미디어 서버(30)의 UAS(62)는 인바이트 요청을 수신하고, 요청된 채널이 이용가능한지를 결정한다. 채널이 이용가능하다면, 단계 102에서 미디어 서버(30)는 액크널리지먼트(acknowledgement), 예를 들면 SIP "200 OK" 메시지로 응답하는데, 이는 미디어 서버(30)가 요청을 받아들이고 컨텐트의 스트림을 로컬 응답 포인트(34)에 송신할 준비가 되어 있다는 것을 지시한다. "200 OK" 메시지는 다이얼로그를 확립하기 위해 동작한다. 미디어 서버(30)는 또한 송신될 컨텐트의 타입을 식별하는 세션 설명 프로토콜(Session Description Protocol)(SDP) 메시지를 포함한다.

단계 104에서, 프록시 서버(24)는 이 액크널리지먼트를 수신하고, 로컬 응답 포인트(34)의 어드레스와 함께 클라이언트 장치(4)로 전달한다. 클라이언트 장치(4)의 UAC(50)는 Cseq 값을 검사함으로써(액크널리지먼트가 인바이트 요청에 대응하는 것을 보장하기 위해) 그리고 그의 타임스탬프를 비교함으로써(응답이 적시에 이루어지도록 보장하기 위해) 이 응답을 받아들일 것인지를 결정한다. 그 액크널리지먼트를 받아들일 때, 클라이언트 장치(4)는 액크널리지먼트로 프록시 서버(24)에 응답한다(단계 106). 또한, 결과적으로 클라이언트 장치(4)는 요청된 프로그래밍 컨텐트를 수신하기 위해 로컬 응답 포인트(34)와 통신할 것을 안다.

단계 108에서, 프록시 서버(24)는 클라이언트 장치(4)로부터의 액크널리지먼트를 미디어 서버(30)로 전달한다. 프록시 서버(24)는 또한 미디어 서버(30)로부 터의 컨텐트를 수신하기 위한 로컬 응답 포인트(34)를 준비시키기 위해 선택된 로컬 응답 포인트(34)와 통신한다(단계 110). 이 통신들은, 클라이언트 장치(4)가 로컬 응답 포인트(34)와의 사이에 통신을 확립하려고 시도할 때 로컬 응답 포인트(34)에 의해 사용되기 위해, 서비스를 요청하는 클라이언트 장치(4)의 정체(identity)(즉, URI)를 포함한다.

단계 112에서, 미디어 서버(30)는 하나 이상의 실시간 프로토콜들(즉, RTP, RTSP, RTCP)을 이용하여 로컬 응답 포인트(34)와 통신 경로를 확립한다. 이 통신 경로를 통해, 채널 컨텐트가 미디어 서버(30)로부터 로컬 응답 포인트(34)로 옮겨간다. 단계 114에서, 클라이언트 장치(4)는 하나 이상의 실시간 전송 프로토콜들(즉, RTP, RTSP, RTCP)을 이용하여 로컬 응답 포인트(34)와 통신 경로를 확립한다. 이 통신 경로의 확립 후, 클라이언트 장치(4)는 요청된 채널 컨텐트를 로컬 응답 포인트(34)로부터 수신한다.

도 6 및 도 7은 로컬 응답 포인트(34)에 현재 캐시되어 이용가능한 컨텐트를 위한 인바이트 요청에 응답하여 프록시 서버(24)가 클라이언트 장치(4')에 재지정 메시지를 송신하는, 재지정 위상의 실시예를 도시한다. 단계 120에서, 클라이언트 장치(4')의 사용자는 채널을 선택하는데, 이는 클라이언트 장치(4')의 UAC(50')가 SIP 인바이트 요청을 액세스 네트워크(14)를 통해 프록시 서버(24)에 송신하도록 야기한다. 프록시 서버(24)는 요청을 가로채서 요청자를 유효하게 한다(단계 122). 요청자가 유효화를 통과할 때, 프록시 서버(24)는 클라이언트 장치(4')에 의해 요청된 채널과 연관된 프로그래밍 컨텐트가 로컬 응답 포인트(34)에서 현재 이용가능한지를 로컬 프로그램 테이블(60)로부터 결정한다(단계 124). (예를 들어, 제2 클라이언트 장치(4')는 도 5에서 제1 클라이언트 장치(4)와 동일한 채널을 선택했다.) 또한, 프록시 서버(24)는 로컬 응답 포인트(34)에 있는 컨텐트가 실효 있는지(만료되지 않았는지)를 결정한다.

요청된 컨텐트가 이용가능하다면, 프록시 서버(24)는 로컬 응답 포인트(34)에 있는 데이터베이스를 갱신하기 위해 로컬 응답 포인트(34)와 통신한다(단계 126). 갱신은 요청된 컨텐트의 송신을 위해 클라이언트 장치(4')와 통신하도록 로컬 응답 포인트(34)에 알린다. 그 대신 컨텐트가 만료된 것으로 플래그되었다면(flagged), 또는 요청된 채널에 대한 엔트리가 로컬 프로그램 테이블(60)에 존재하지 않는다면, 프록시 서버(24)는, 도 2 및 도 3에 도시된 바와 같이, 인바이트 요청을 미디어 서버(30)에 전달한다.

컨텐트가 로컬 응답 포인트(34)로부터 얻어질 수 있다고 결정된 후, 프록시 서버(24)는 SIP 재지정 메시지를 클라이언트 장치(4')에 보낸다(단계 128). 재지정 메시지는 클라이언트 장치(4')에게 원하는 프로그래밍 컨텐트를 얻기 위해 로컬 응답 포인트(34)와 통신할 것을 지령한다. 재지정 메시지의 본문 내의 SDP 메시지는, 프록시 서버(24)가 클라이언트 장치(4')를 방향을 고쳐 지향시키고(redirecting) 있는 로컬 응답 포인트(34)를 식별한다.

단계 130에서, 클라이언트 장치(4')의 UAC(50')는 재지정 메시지에 액크널리지한다. 재지정 메시지에 액크널리지하기 전에, UAC(50')는 프록시 서버(24)로부터의 응답이 유효한지 그리고 적시인지를(Cseq와 타임스탬프를 검사함으로써) 확인 한다. 단계 132에서, 클라이언트 장치(4')는 하나 이상의 실시간 전송 프로토콜들을 이용하여 로컬 응답 포인트(34)와 통신 경로를 확립한다. 이 경로를 확립 후, 클라이언트 장치(4')는 로컬 응답 포인트(34)로부터 컨텐트를 수신하기를 시작한다. 프록시 서버(24)는 또한 제2 클라이언트 장치(4')의 정체(즉, 그 채널의 가장 최근의 요청자의 정체)를 포함하도록 그의 로컬 프로그램 테이블(60)을 갱신한다(단계 134). 연관된 타이머(Timer)가 또한 리셋된다. 타이머는 특정 프로그램과 연관된 시청자들이 늘 있음을 보장한다. 비정상적인 중단의 경우에, 프록시 서버(24)는 타이머를 이용하여 프로그램을 만료시킨다.

IPTV 서비스들의 공급자들은 그들의 채널 리스팅 중의 채널들을 동시적으로 요청하는 수많은 가입자들을 가질 것을 기대할 수 있다. 결국, 주어진 공급자에 의해 제공되는, 모두는 아니어도, 많은 IPTV 채널들(주어진 시간 슬롯 동안 - 예를 들어 8PM부터 9PM까지)은 하나 이상의 로컬 응답 포인트들에 캐시될 수 있는데, 왜냐하면 이 채널들을 통해 네비게이트하는(navigating) 가입자들의 수에 비해 공급자에 의해 제공되는 채널들의 수가 작기 때문이다. 로컬 응답 포인트들이 다양한 채널들로 파퓰레이트된(populated) 후, 이 시간 슬롯 동안 많은 후속의 인바이트 요청들은 로컬 응답 포인트로 재지정될 것으로 기대된다.

비록 본 발명은 바람직한 특정 실시예들을 참조하여 도시되고 설명되었지만, 당업자는 형태 및 상세한 사항들에 있어서 다양한 변경들이 다음의 청구항들에 정의된 본 발명의 사상 및 범위로부터 벗어나지 않고서 이루어질 수 있다는 것을 이해할 것이다. 예를 들어, 앞서 설명된 실시예들에서, 미디어 컨텐트가 로컬 응답 포인트에 캐시되는 것은, 제1 요청자를 필요로 하는데, 즉 한 명의 가입자가 채널에 대한 요청을 발행하고, 그 요청이 미디어 서버에 전달되고, 그런 다음 그 채널의 컨텐트가 로컬 응답 포인트에 캐시될 것이 필요하다. 대안적인 실시예에서, 로컬 응답 포인트는 미디어 컨텐트로 사전에(proactively) 채워진다. 즉, 제1 요청자를 기다리지 않고, 로컬 응답 포인트는 기대되는 요구를 예상하여 사전에 채널들을 다운로드하기 위해 미디어 서버와 통신할 수 있다. 따라서, 특정 채널에 대한 제1 요청자가 요청을 발행할 때, 프록시 서버는 제1 요청자를 로컬 응답 서버에 지향시키기 위해 위에서 설명한 재지정 메커니즘을 즉각 채택할 수 있다.

Claims

인터넷 프로토콜 네트워크를 통해 실시간 미디어 컨텐트를 얻는 방법으로서,

프록시 서버에서 클라이언트 장치로부터, 미디어 컨텐트의 스트림을 얻기 위해서는 미디어 서버와 통신이 확립되어야 함을 요청하는 메시지를 수신하는 단계; 및

요청된 미디어 컨텐트가 로컬 응답 포인트로부터 이용가능하다면 상기 클라이언트 장치로부터의 메시지에 응답하여, 미디어 컨텐트의 상기 스트림을 얻기 위해 상기 로컬 응답 포인트와 통신하도록 상기 클라이언트 장치에 명령하는, 재지정 메시지(redirection message)를 상기 프록시 서버로부터 상기 클라이언트 장치에 송신하는 단계

를 포함하는 방법.
제1항에 있어서,

상기 미디어 컨텐트가 상기 로컬 응답 포인트로부터 이용가능하지 않다면, 상기 클라이언트 장치로부터의 메시지를 상기 프록시 서버에 의해 상기 미디어 서버에 전달하는 단계;

미디어 컨텐트의 상기 스트림을 상기 로컬 응답 포인트에 송신하도록 상기 미디어 서버에 명령하는 단계; 및

미디어 컨텐트의 상기 스트림을 얻기 위해 상기 로컬 응답 포인트와 통신하 도록 상기 클라이언트 장치에 명령하는 단계를 더 포함하는 방법.
제1항에 있어서,

상기 요청된 미디어 컨텐트가 상기 로컬 응답 포인트에 저장되어 있는지를 결정하기 위해 상기 프록시 서버에 의해 데이터베이스를 검색하는 단계를 더 포함하는 방법.
제3항에 있어서,

상기 로컬 응답 포인트에 저장된 상기 요청된 미디어 컨텐트가 만료되었는지를 결정하는 단계를 더 포함하는 방법.
제1항에 있어서,

상기 클라이언트 장치와 상기 프록시 서버 사이, 및 상기 프록시 서버와 상기 미디어 서버 사이에 교환되는 메시지들은 세션 개시 프로토콜(Session Initiation Protocol: SIP) 메시지들인 방법.
제1항에 있어서,

미디어 컨텐트의 다른 스트림들을 얻기 위한 상기 클라이언트 장치로부터의 다수의 요청들에 걸쳐 지속하는 상기 클라이언트 장치와 상기 미디어 서버 사이의 SIP 세션을 확립하는 단계를 더 포함하는 방법.
실시간 미디어 컨텐트를 배포하는 네트워크로서,

미디어 서버;

상기 미디어 서버와 통신하는 로컬 응답 포인트; 및

클라이언트 장치와 통신하는 프록시 서버 - 상기 프록시 서버는 상기 클라이언트 장치로부터, 미디어 컨텐트의 특정 스트림을 얻기 위해서는 미디어 서버와 통신이 확립되어야 함을 요청하는 메시지를 수신하고, 상기 프록시 서버는 요청된 미디어 컨텐트가 상기 로컬 응답 포인트로부터 이용가능하다면 상기 클라이언트 장치로부터의 메시지에 응답하여, 재지정 메시지를 상기 클라이언트 장치에 송신하고, 상기 재지정 메시지는 미디어 컨텐트의 상기 특정 스트림을 얻기 위해 상기 로컬 응답 포인트와 통신을 확립하도록 상기 클라이언트 장치에 명령함 -

를 포함하는 네트워크.
제7항에 있어서,

상기 미디어 컨텐트가 상기 로컬 응답 포인트로부터 이용가능하지 않다면, 상기 프록시 서버는 상기 클라이언트 장치로부터의 메시지를 전달하기 위해 상기 미디어 서버와 통신하고;

상기 미디어 서버는 상기 전달된 클라이언트 장치로부터의 메시지에 응답하여 미디어 컨텐트의 상기 특정 스트림을 상기 로컬 응답 포인트에 송신하기 위해 상기 로컬 응답 포인트와 통신하고;

상기 로컬 응답 포인트는 미디어 컨텐트의 상기 특정 스트림을 상기 클라이언트 장치에 배송하기 위해 상기 클라이언트 장치와 통신하는 네트워크.
제7항에 있어서,

상기 프록시 서버는 하나 이상의 엔트리들을 갖는 데이터베이스를 포함하고, 각각의 엔트리는 상기 로컬 응답 포인트에 저장된 미디어 컨텐트의 상이한 스트림을 식별하는 네트워크.
제9항에 있어서,

상기 데이터베이스의 각각의 엔트리는 그 엔트리에 의해 식별된 상기 미디어 컨텐트가 만료되었는지를 나타내는 네트워크.
제7항에 있어서,

상기 클라이언트 장치와 상기 프록시 서버 사이, 및 상기 프록시 서버와 미디어 서버 사이에 교환되는 메시지들은 세션 개시 프로토콜(SIP) 메시지들인 네트워크.
제7항에 있어서,

상기 클라이언트 장치는 미디어 컨텐트의 상이한 스트림들을 얻기 위한 상기 클라이언트 장치로부터의 다수의 요청들에 걸쳐 지속하는 상기 미디어 서버와의 SIP 세션을 확립하는 네트워크.
제7항에 있어서,

미디어 컨텐트의 상이한 스트림에 대한 상기 클라이언트 장치로부터의 요청은 상기 SIP 세션의 다이얼로그 부분 내에서 발생하는 네트워크.
제7항에 있어서,

상기 클라이언트 장치로부터의 메시지는 상기 미디어 서버의 URI(Universal Resource Identifier) 및 미디어 컨텐트의 상기 요청된 스트림의 URI를 포함하는 네트워크.
네트워크 장치로서,

액세스 네트워크를 통해 클라이언트 장치와 통신하는 프록시 에이전트를 포함하고,

상기 프록시 에이전트는 상기 클라이언트 장치로부터, 미디어 컨텐트의 스트림을 얻기 위해서는 미디어 서버와 통신이 확립되어야 함을 요청하는 메시지를 수신하고, 상기 프록시 에이전트는 상기 미디어 컨텐트가 캐시 서버로부터 이용가능하다면 상기 클라이언트 장치로부터의 메시지에 응답하여 재지정 메시지를 상기 클라이언트 장치에 송신하고, 상기 재지정 메시지는 미디어 컨텐트의 요청된 스트림을 얻기 위해 상기 캐시 서버와 통신하도록 상기 클라이언트 장치에 명령하는 네트 워크 장치.
제15항에 있어서,

하나 이상의 엔트리들을 갖는 데이터베이스를 더 포함하고, 각각의 엔트리는 상기 캐시 서버에 저장된 미디어 컨텐트를 식별하는 네트워크 장치.
제16항에 있어서,

상기 데이터베이스의 각각의 엔트리는 그 엔트리에 의해 식별된 상기 미디어 컨텐트가 만료되었는지를 나타내는 네트워크 장치.
제15항에 있어서,

상기 프록시 에이전트는 (1) 요청된 미디어 컨텐트가 상기 캐시 서버에서 이용가능하지 않다면 상기 클라이언트 장치로부터의 메시지를 상기 미디어 서버에 전달하고, (2) 미디어 컨텐트의 요청된 스트림을 상기 캐시 서버에 송신하도록 상기 미디어 서버에 명령하는 네트워크 장치.
제15항에 있어서,

상기 클라이언트 장치와 상기 프록시 에이전트 사이에 교환되는 메시지들은 세션 개시 프로토콜(SIP) 메시지들인 네트워크 장치.
제15항에 있어서,

상기 클라이언트 장치에 송신된 재지정 메시지는 상기 캐시 서버의 어드레스를 지정하는 네트워크 장치.