KR20110013516A

KR20110013516A - 디바이스 및 서버 능력을 전달하는 방법

Info

Publication number: KR20110013516A
Application number: KR1020107029026A
Authority: KR
Inventors: 영재 김; 앤드류 알렌
Original assignee: 리서치 인 모션 리미티드
Priority date: 2008-06-23
Filing date: 2009-06-23
Publication date: 2011-02-09
Also published as: EP2291963B1; WO2010008840A2; KR101210774B1; JP2011527534A; US8363643B2; US20090316690A1; EP2291963A2; EP2291963A4; CA2728124A1; WO2010008840A3; CA2728124C

Abstract

사용자 에이전트의 능력들을 전달하는 방법이 제공된다. 본 방법은 적어도 하나의 푸시 자원을 포함하는 푸시 자원 식별자 피쳐 태그를 포함하는 콘택 헤더를 포함한 SIP 메시지를 사용자 에이전트가 전송하는 것을 포함한다.

Description

디바이스 및 서버 능력을 전달하는 방법{METHOD FOR DELIVERING DEVICE AND SERVER CAPABILITIES}

본 발명은 통신 디바이스에 관한 것이다.

인터넷 프로토콜(IP; Internet Protocol) 멀티미디어 서브시스템(IMS; IP Multimedia Subsystem)은 이동식 및 고정식 디바이스 양쪽 모두에게 멀티미디어 서비스 및 보이스 오버 IP(voice-over-IP) 호를 제공하기 위한 표준화된 아키텍쳐이다. 세션 개시 프로토콜(SIP; Session Initiation Protocol)은 IMS-기반 호들 또는 세션들을 생성하고 변경하고 종료하기 위한 시그널링 프로토콜로서 IETF(Internet Engineering Task Force)에 의해 주로 표준화되어 관리되어 왔다. 여기에서 이용되는 용어 "사용자 에이전트" 및 "UA"는 일부 경우에 모바일 전화기, 개인 휴대 정보 단말기, 핸드헬드 또는 랩톱 컴퓨터, 및 원격 통신 능력을 갖는 유사한 디바이스들과 같은 모바일 디바이스를 의미한다. 이러한 UA는 디바이스와, 이들에 한정되는 것은 아니지만, 가입자 식별 모듈(SIM; Subscriber Identity Module) 애플리케이션, 유니버셜 가입자 식별 모듈(USIM; Universal Subscriber Identity Module) 애플리케이션, 또는 탈착가능 사용자 식별 모듈(R-UIM; Removable User Identity Module) 애플리케이션을 포함하는 유니버셜 집적 회로 카드(UICC; Universal Integrated Circuit Card)와 같은 디바이스와 연관된 탈착가능 메모리 모듈로 구성될 수 있다. 대안으로서, 이러한 UA는 이러한 모듈 없이 디바이스 자체로 구성될 수도 있다. 다른 경우에, 용어 "UA"는 고정된 유선 전화기, 데스크톱 컴퓨터, 셋톱 박스, 또는 네트워크 노드들과 같은 이동가능하지 않지만 유사한 능력들을 갖는 디바이스를 의미할 수 있다. 네트워크 노드가 UA로서 기능할 때, 네트워크 노드는 모바일 디바이스 또는 고정된 유선 디바이스와 같은 다른 기능을 대신하여 동작할 수 있고 디바이스를 시뮬레이트 또는 에뮬레이트할 수 있다. 예를 들어, 일부 UA들에 대하여, 일반적으로 디바이스 상에서 상주하는 IMS SIP 클라이언트는 실제로 네트워크에도 역시 상주할 수 있고 최적화된 프로토콜들을 이용하여 디바이스에 SIP 메시지 정보를 중계할 수 있다. 즉, UA에 의해 통상적으로 수행되었던 일부 기능들은 원격 UA의 형태로 분산될 수 있고 이 경우 원격 UA는 네트워크 내의 UA를 나타낸다. 용어 "UA"는 또한이들에 한정되는 것은 아니지만 SIP 세션도 포함할 수 있는 통신 세션을 종료할 수 있는 임의의 하드웨어 또는 소프트웨어 컴포넌트를 의미할 수 있다. 또한, 용어, "사용자 에이전트", "UA", "사용자 장치", "UE" 및 "노드"는 여기서는 동의어로서 이용될 수 있다.

본 발명은 사용자 에이전트의 능력들을 전달하는 방법을 제공하기 위한 것이다.

본 방법은 적어도 하나의 푸시 자원을 포함하는 푸시 자원 식별자 피쳐 태그를 포함하는 콘택 헤더를 포함한 SIP 메시지를 사용자 에이전트가 전송하는 것을 포함한다.

본 발명에 따르면, 사용자 에이전트의 능력들을 효과적으로 전달할 수 있다.

본 발명의 보다 완벽한 이해를 위하여, 이하 첨부된 도면 및 상세한 설명과 관련하여 다음의 간략한 설명에 대한 참조가 이루어지며, 여기서는 동일한 도면 부호는 동일한 부분을 나타낸다.
도 1은 본 발명의 일 실시예에 따른 메시지 흐름도이다.
도 2는 본 발명의 일 실시예에 따른 다른 메시지 흐름도이다.
도 3은 본 발명의 몇몇 실시예를 구현하기에 적합한 프로세서 및 관련 컴포넌트를 나타낸다.

본 발명의 하나 이상의 실시예들의 예시적인 구현예가 아래 제공되지만, 본 시스템 및/또는 방법은 현재 알려져 있든 또는 기존의 것이든 간에 임의의 수의 기술을 이용하여 구현될 수 있는 것임을 이해하여야 한다. 본 발명은 여기에 설명되고 예시된 예시적인 설계 및 구현예들을 포함한 아래 설명된 예시적인 구현예, 도면, 및 기술로 제한되는 방식으로 되어서는 안 되며, 첨부된 청구범위 내에서 그 전체 등가 범위와 함께 변경될 수 있다.

통신 시스템용 기술은 오직 단일의 라인 또는 디바이스에만 고유하게 매핑하는 오직 단일의 아이덴티티(예를들어, 전화 번호)만의 전화기 기반 개념으로부터 벗어나고 있다. SIP 및 기타 인터넷 기반 통신 기술들은 (공개 사용자 아이덴티티(Public User Identity, 즉 PUI와 같은) 동일한 사용자 아이덴티티에 등록된 복수의 디바이스들을 갖는 개념을 지원한다. 각각의 디바이스는 서로 다른 미디어 유형 및 코덱을 지원하는 것과 같이 자체 능력을 가질 수 있다. SIP는 하나의 SIP UA가 다른 UA의 능력(예를 들어, 동일한 세션 또는 복수의 세션 내에서 오디오 및 비디오 모두와 함께, 텍스트를 포함한 여러 매체 유형 및 기타 메시징 유형에 대한 지원 능력)을 질의(query)하여 통지받는 방법을 제공한다.

이들 능력은 사용자가 홈 폰, 개인 모바일 폰, 워크 폰, 베케이션 홈 폰, 랩톱 컴퓨터VoIP 클라이언트, 팩스 머신 등에 대하여 서로 다른 아이덴티티를 가져야 하는 필요성을 제거할 수 있고, 사용자로 하여금 사용자가 당시에 이용중일 수 있는 디바이스가 무엇이든간에 연락가능할 수 있게 허용할 수 있다. 이는 또한, 주소록 내의 사용자 마다 대규모 리스트의 디바이스 지향 콘택들을 갖는다는 문제점과, 통신을 확립하여 시도할 때 어느 디바이스가 사용자에게 연락하기에 최상의 것인지를 결정해야 하는 문제를 해결할 수 있다.

종종, IP-기반 및 SIP-기반 통신에서, 네트워크 기반 서버는 서비스 및 컨텐츠를 UA들(종종 클라이언트라 함)에 제공한다. OMA(Open Mobile Alliance) SIP 푸시 인에이블러(Push Enabler)는, SIP 푸시 클라이언트(Push client; 푸시 수신자 에이전트(Push Receiver Agent)로서 알려짐)가 네트워크 기반 서버(SIP 푸시 송신자 에이전트(Push Sender Agent)로서 알려짐)로부터의 제1 요청 컨텐츠를 필요로 함이 없이 네트워크 기반 서버가 SIP 푸시 클라이언트에 컨텐츠를 직접 효과적으로 전달하는 효과적인 방법을 제공하는 시스템의 일례이다.

SIP 네트워크 기반 서버가 이용될 때, SIP 네트워크 기반 서버는 SIP 푸시 수신자 에이전트와 같은 UA가 SIP 푸시 송신자 에이전트와 같은 서버에 의해 지원되는 능력들을 얻는 것을 필요로 할 수 있다. IETF(Internet Engineering Task Force) RFC(Request for Comments) 3261에서 정의된 SIP OPTIONS 메소드는 서버의 능력을 질의하여 얻는데 이용될 수 있다.

이와 유사하게, SIP 푸시 송신자 에이전트와 같은 SIP 네트워크 기반 서버는 SIP 푸시 수신자 에이전트와 같은 UA에 의해 지원되는 능력을 얻는 것을 필요로 할 수 있다. 또한, SIP OPTIONS 메소드는 UA의 능력을 질의하고 얻는데 이용될 수 있다. SIP OPTIONS 요청에 대한 SIP 200 OK 응답은 UA의 능력에 대한 정보를 포함하는 바디부(body containing information)를 포함할 수 있다. 이 정보는 IETF RFC 3261에서 규정된 능력 정보에 더하여, SIP OPTIONS 요청에 대한 200 OK 응답의 SIP 헤더들에서 전송될 수 있다. 이 바디부는 OMA UA 프로파일 문서와 같은 능력 정보, 또는 균일 자원 식별자(URI; Uniform Resource Identifier) 또는 OMA UA 프로파일 문서와 같은 능력 정보를 포함하는 문서를 가르키는 유사한 식별자를 포함할 수 있다.

UA는 (예를 들어, 무선 디바이스의 경우 파워 오프와 파워 온 또는 무선 커버리지의 손실 및 회복으로 인하여) 이용가능할 수 없기 때문에, UA는 시스템에 등록하는 것이 필요할 수 있다. 서버는 UA가 이용가능하게 되고 하나 이상의 메카니즘을 통하여 이를 행할 수 있음을 발견하는 것이 필요할 수 있다. 한 메카니즘에서, 서버는 UA로부터 SIP OPTIONS 요청을 수신함으로써 UA가 이용가능한지 여부를 결정할 수 있다. 다른 메카니즘에서, 서버는 IETF RFC 3680에서 정의된 바와 같이, 등록 이벤트 패키지(Registration Event package)에 가입하여, UA가 등록하였음을 나타내는 통지(SIP NOTIFY 요청)를 수신할 수 있다. 또 다른 메카니즘에서, 서버는 3GPP(3rd Generation Partnership Project) TS(Technical Specification) 23.218 및 3GPP TS 24.229에서 정의된 바와 같이, UA가 등록하였음을 나타내는 제3자 등록으로 알려진 SIP REGISTER 요청을 수신할 수 있다.

UA가 등록하였음을 서버가 검출하였다면 서버는 SIP OPTIONS 요청을 이용하여 서버 자신의 능력에 대하여 UA에 질의할 수 있다. OMA SIP 푸시 인에이블러의 경우에, 서버는 UA에 대한 OMA UA 프로파일 문서를 얻을 수 있다. 그러나, SIP OPTIONS 요청은 통상적으로 사용자의 등록된 AoR(Address of Record) 또는 PUI에 대하여 어드레스 지정되기 때문에 동일한 사용자에 대하여 복수의 UA가 등록되었다면 문제가 일어날 수 있다. 이러한 경우, 등록된 UA들 중 어느 것이 서버로부터 SIP OPTIONS 요청을 수신하여 자신의 능력을 반환할 것인지를 결정하는 것이 가능하지 않을 수 있다.

SIP OPTIONS 요청이 IETF RFC 3261에 따라 포크(fork)되지 않기 때문에, 서버는 막 발견하여 등록하였던 UA에 SIP OPTIONS 요청을 라우팅하는 것을 보장하는 것이 필요할 수 있다. SIP OPTIONS 요청은 다이알로그를 확립하지 않으며, 심지어 서버가, UA로부터 SIP OPTIONS 요청을 수신하는 것을 통하여 UA가 이용가능하다고 결정한 경우에도, 서버는 SIP 다이알로그를 이용하여 SIP OPTIONS 요청을 되전송할 수 없다. SIP 다이알로그를 이용하여 SIP OPTIONS 요청을 반환하는 것은 최초의 SIP OPTIONS 요청을 전송하였던 UA에 SIP OPTIONS 요청이 도달하는 것을 보장할 수 있다. 따라서, SIP 푸시 송신자 에이전트는, 동일한 사용자에 의해 이용된 복수의 UA와 연관된 PUI 또는 AoR를 이용하여 SIP 푸시 클라이언트(푸시 수신자 에이전트)에 SIP OPTIONS 요청을 전송할 때, 요청이 전송되어야 할 UA가 어느 것인지를 명확히 할 수 없다.

일 실시예에서, 푸시 송신자 에이전트와 같은 서버는 GRUU(Globally Routable UA URI)를 이용하여 푸시 수신자 에이전트와 같은 UA에 SIP OPTIONS 요청을 어드레스 지정한다. GRUU는 UA 및 UA와 연관된 PUI 또는 AoR 양쪽 모두를 식별하는 URI이다. GRUU는 IETF 문서[draft-ietf-sip-gruu]에서 규정된 바와 같은 등록 프로세스 동안에 UA에 의해 얻어질 수 있다. SIP OPTIONS 요청을 올바른 UA에 전송하기 위하여, 푸시 송신자 에이전트와 같은 서버는 서버가 발견하여 등록하였던 UA의 GRUU를 획득하는 것이 필요할 수 있다.

일 실시예에서, SIP 푸시 송신자 에이전트가 공개 GRUU를 발견하기 위한 3가지 방법이 있을 수 있는데, SIP OPTIONS 메소드를 이용하는 것, IETF RFC 3680에서 기술된 등록 이벤트 패키지 및 IETF 문서 [draft-ietf-sipping-gruu-reg-events]에서 정의된 확장을 이용하여 IETF RFC 3265에 기술된 SIP SUBSCRIBE/NOTIFY 메카니즘을 이용하는 것, 또는 최초의 SIP REGISTER 요청의 컨텐츠를 포함하는 바디부를 포함하는 제3자 등록 메카니즘을 이용하는 것이 있다. 이들 메카니즘 각각을 아래 자세히 설명한다. SIP 푸시 송신자 에이전트가 SIP 푸시 수신자 에이전트의 공개 GRUU 값을 결정할 때, SIP 푸시 전송 에이전트는 SIP 푸시 수신자 에이전트의 공개 GRUU를 포함하는 Request-URI 부분과 함께 SIP OPTIONS 요청을 전송한다. 이 요청을 수신시, SIP 푸시 수신자 에이전트는 자신의 UAProfile의 URI를 SIP 200 OK 메시지의 바디부에 포함시킨다(또는 대안적으로, UAProfile 문서를 바디부에 직접 포함시킨다). SIP 푸시 수신자 에이전트는 그 후 SIP 200 OK를 SIP 푸시 송신자 에이전트에 전송하고 따라서, SIP 푸시 수신자 에이전트 자신의 능력을 SIP 푸시 송신자 에이전트에 제공한다.

일 실시예에서, UA(또는 푸시 수신자 에이전트)는 서버(또는 푸시 송신자 에이전트)에 푸시 수신자 에이전트의 GRUU를 포함하는 SIP OPTIONS 요청을 전송한다. GRUU는 SIP OPTIONS 요청의 콘택 헤더 내에 포함될 수 있다. 그 후 푸시 송신자 에이전트는 푸시 송신자 에이전트에 대한 정보를 포함하는 200 OK 메시지를 푸시 수신자 에이전트에 전송한다. 그 후, 푸시 송신자 에이전트는, 푸시 수신자 에이전트가 이전의 SIP OPTIONS 요청에 제공하였던 GRUU에 SIP OPTIONS 요청을 전송함으로써 푸시 수신자 에이전트의 능력을 요청한다. 그 후, 푸시 수신자 에이전트는 푸시 수신자 에이전트의 능력에 대한 정보를 포함하는 200 OK 메시지를 반환할 수 있다. 일부 경우, 200 OK 메시지는 푸시 수신자 에이전트의 OMA UA 프로파일 문서와 같은 푸시 수신자 에이전트의 능력 정보를 포함하며, 다른 경우, 200 OK 메시지는 푸시 수신자 에이전트의 OMA UA 프로파일 문서와 같은 푸시 수신자 에이전트의 능력 정보를 가르키는 URI를 포함한다.

대안으로서 푸시 송신자 에이전트는 푸시 수신자 에이전트로부터의 SIP OPTIONS 요청에 대한 200 OK 응답으로 푸시 송신자 에이전트 자신의 능력들을 포함할 수 있지만, 푸시 수신자 에이전트의 능력을 요청하기 위해 푸시 수신자 에이전트의 GRUU에 SIP OPTIONS 요청을 전송할 수 없다.

이들 실시예 하에서 푸시 수신자 에이전트와 푸시 송신자 에이전트에서 이용될 수 있는 절차들의 예가 아래 제공된다.

푸시 수신자 에이전트에서의 절차

[RFC 3261]에 따라 SIP OPTIONS 요청을 발생시킬 때 푸시 수신자 에이전트는:

1. SIP OPTIONS 요청을 발생시켜야 한다.

2. 푸시 송신자 에이전트의 URI에 대한 SIP OPTIONS 요청의 Request-URI를 설정해야 한다.

3. [RFC 3325]의 절차와 규칙에 따라 P-Preferred-Identity 헤더에 푸시 수신자 에이전트의 URI를 삽입할 수 있다.

4. 푸시 수신자 에이전트가 [draft-ietf-sip-gruu]의 규칙 및 절차에 따라 등록 동안에 공개 GRUU를 획득하였다면, 콘택 헤더에 공개 GRUU를 포함시켜야 한다.

5. 섹션 9.1에서 정의된 바와 같이, 푸시 수신자 에이전트에 의해 지원되는 모든 푸시 자원의 값을 포함한 푸시 자원 식별자 피쳐 태그(Push Resource Identifier feature tag)를 콘택 헤더에 포함시켜야 한다.

6. 푸시 수신자 에이전트가 [draft-ietf-sip-gruu]의 규칙 및 절차에 따라 등록 동안에 공개 GRUU를 획득하였다면, 지원 헤더(Supported header)에 GRUU를 삽입해야 한다.

7. MIME 유형, 메시지/외부 바디부(message/external-body) 및 애플리케이션/oma_PushOptions을 포함한 수락 헤더(Accept header)를 [RFC 4483]에서 규정된 바와 같이 포함시켜야 한다.

8. 푸시 수신자 에이전트가 허용 헤더(Allow header)에서 지원하는 모든 SIP 메소드를 포함시켜야 한다.

9. 푸시 수신자 에이전트의 모델, 벤더 및 버전을 포함하는 사용자-에이전트 헤더를 포함시켜야 한다.

10. SIP/IP 코어의 절차에 따라 SIP/IP 코어를 향하여 SIP OPTIONS 요청을 전송해야 한다.

SIP OPTIONS 요청에 대한 SIP 200 "OK" 응답을 수신시, 푸시 수신자 에이전트는:

1. [RFC3840]에 따라 콘택 헤더에 포함된 푸시 송신자 에이전트의 푸시 능력을 푸시 애플리케이션에 제공해야 한다.

2. 허용 헤더에 포함된 푸시 송신자 에이전트에 의해 지원되는 SIP 메소드를 푸시 애플리케이션에 제공해야 한다.

3. SIP 200 "OK" 응답이 바디부를 포함하면, 콘텐츠-디스포지션(Content-Disposition)에 따라 바디부와 프로세스를 검색해야 한다.

MIME 유형, 메시지/외부-바디 및 애플리케이션/Dev-cap을 포함하는 수락 헤더를 포함한 SIP OPTIONS 요청을 수신시, 푸시 수신자 에이전트는:

1. P-Asserted-Identity 헤더가 존재하며 P-Asserted-Identity 헤더에서의 URI가 신뢰성있음을 검증해야 한다. 인가 검사가 실패하면, 푸시 수신자 에이전트는 SIP 403 "Forbidden"응답을 반환해야 한다.

2. [RFC3261]에 따라 SIP 200 "OK" 응답을 발생시켜야 한다.

3. 푸시 수신자 에이전트가 [draft-ietf-sip-gruu]의 규칙 및 절차에 따라 등록 동안에 공개 GRUU를 획득하였다면, 콘택 헤더에 공개 GRUU를 포함시켜야 한다.

4. 푸시 수신자 에이전트가 허용 헤더(Allow header)에서 지원하는 모든 SIP 메소드를 포함시켜야 한다.

5. 푸시 수신자 에이전트가 [draft-ietf-sip-gruu]의 규칙 및 절차에 따라 등록 동안에 공개 GRUU를 획득하였다면, 지원 헤더에 GRUU를 삽입해야 한다.

6. 푸시 수신자 에이전트에 의해 지원되는 모든 푸시 자원의 값을 포함한 푸시 자원 식별자 피쳐 태그를 콘택 헤더에 포함시켜야 한다.

7. 푸시 수신자 에이전트의 모델, 벤더 및 버전을 포함하는 사용자-에이전트 헤더를 포함시켜야 한다.

8. [RFC 4483]의 절차 및 규칙에 따라 다음을 포함하는 컨텐츠-유형 헤더를 포함시켜야 한다.

a. MIME 유형 메시지/외부 바디부,

b. ACCESS_TYPE 파라미터에서의 "URL", 및

c. URL 파라미터 내에서 [OMA_UAProf] 문서의 HTTP URL.

9. 다음을 포함하는 [RFC 4483]의 규칙 및 절차에 따라 보디부를 포함시켜야 한다.

a. 컨텐츠-유형에서의 애플리케이션/Dev-cap,

b. 컨텐츠-디스포지션에서의 "연결(attachment)", 및

다음을 포함하는 [RFC 4483]의 규칙 및 절차에 따른 컨텐츠-ID.

10. SIP/IP 코어의 절차에 따라 SIP/IP 코어를 향하여 SIP OPTIONS "OK"응답을 전송해야 한다.

푸시 송신자 에이전트에서의 절차

SIP OPTIONS 요청을 수신시, 푸시 송신자 에이전트는:

1. P-Asserted-Identity 헤더가 존재하며 P-Asserted-Identity 헤더에서의 URI가 신뢰성있음을 검증해야 한다. 인가 검사가 실패하면, 푸시 송신자 에이전트는 SIP 403 "Forbidden"응답을 반환해야 한다.

2. [RFC3261]에 따라 SIP 200 "OK" 응답을 발생시켜야 한다.

3. 수락된 푸시 자원 값을 포함하는 푸시 자원 식별자 피쳐 태그를 콘택 헤더에 포함시켜야 한다.

4. 푸시 송신자 에이전트가 허용 헤더(Allow header)에서 지원하는 모든 SIP 메소드를 포함시켜야 한다.

5. SIP/IP 코어의 절차에 따라 SIP/IP 코어를 향하여 SIP OPTIONS "OK"응답을 전송해야 한다.

푸시 송신자 에이전트는 푸시 수신자 에이전트의 능력에 대하여 질의해야 하며, 푸시 송신자 에이전트는:

1. [RFC 3261]에 따라 SIP OPTIONS 요청을 발생시켜야 한다.

2. 공개 GRUU가 SIP OPTIONS 요청 내의 콘택 헤더에서 수신되었다면, 수신된 SIP OPTIONS 요청 또는 공개 GRUU에서 SIP OPTIONS 요청의 Request-URI를 P-Asserted-Identity로부터 푸시 수신자 에이전트의 공개 사용자 아이덴티티로 설정해야 한다.

3. [RFC 3325]의 절차와 규칙에 따라 P-Asserted-Identity 헤더에 푸시 송신자 에이전트의 URI를 삽입할 수 있다.

4. 섹션 9.1에서 정의된 바와 같이, 수락가능한 푸시 자원 값을 포함하는 푸시 자원 식별자 피쳐 태그를 콘택 헤더에 포함시켜야 한다.

5. MIME 유형, 메시지/외부바디 및 애플리케이션/Dev-cap을 포함한 수락 헤더를 [RFC 4483]에서 규정된 바와 같이 포함시켜야 한다.

6. 푸시 송신자 에이전트가 허용 헤더(Allow header)에서 지원하는 모든 SIP 메소드를 포함시켜야 한다.

7. SIP/IP 코어의 절차에 따라 SIP/IP 코어를 향하여 SIP OPTIONS 요청을 전송해야 한다.

SIP OPTIONS 요청에 대한 SIP 200 "OK" 응답을 수신시, 푸시 송신자 에이전트는:

1. SIP 200 "OK"가 애플리케이션/Dev-cap의 콘택-유형 및 규정된 문서의 HTTP URL를 포함하는 바디부를 포함한다면, [RFC 4483]의 규칙 및 절차에 따라 URL를 저장하고 연관된 문서를 검색하여 디바이스 능력을 획득해야 한다.

도 1은 이 실시예에 따른 SIP 푸시 수신자 에이전트(10)와, SIP/IP 코어(20)와 SIP 푸시 송신자 에이전트(30) 사이의 예시적인 메시지 흐름을 나타낸다. 이벤트 110에서, SIP 푸시 수신자 에이전트는 푸시 수신자 에이전트에 의해 지원되는 푸시 자원의 값들을 포함한 푸시 자원 식별자 피쳐 태그(+g.oma.pusheventapp)와 함께 콘택 헤더 내에 포함된 SIP OPTIONS 요청, 자신의 공개 GRUU 값 - 이 값은 등록 절차 동안에 획득됨 - 을 SIP/IP 코어에 전송한다. 다음은 이 SIP OPTIONS 요청의 일 실시예이다.

이 SIP OPTIONS 요청의 콘택 헤더 부분은 요청을 전송했던 푸시 수신자 에이전트의 GRUU("gr" 파라미터로 나타내어짐)를 포함하고 있음을 알 수 있다. 이벤트 120에서, SIP/IP 코어는 SIP OPTIONS 요청을 SIP 푸시 송신자 에이전트에 전달한다.

이벤트 130에서, SIP 푸시 송신자 에이전트는 SIP 푸시 송신자 에이전트의 능력에 관련된 정보를 포함한 SIP 200 OK를 전송한다. SIP 200 OK는 또한 추가적인 푸시 옵션 및/또는 추가적인 푸시 옵션이 획득될 수 있는 URI를 포함하는 바디부를 포함할 수 있다. 다음은 이 SIP 200 OK 응답의 일 실시예이다.

이벤트 140에서, SIP/IP 코어는 SIP 200 OK 응답을 SIP 푸시 수신자 에이전트에 전달한다. 이벤트 150에서, SIP 푸시 송신자 에이전트는 SIP를 포함한 SIP OPTIONS 요청, 푸시 수신자 에이전트의 GRUU - 이는 SIP 푸시 수신자 에이전트가 이전의 SIP OPTIONS 요청에서 제공하였던 것임 - 를 SIP/IP 코어에 전송한다. 즉, 푸시 송신자 에이전트는 특정된 GRUU를 갖는 푸시 수신자 에이전트의 능력을 요청한다. 다음은 이 SIP OPTIONS 요청의 일 실시예이다.

SIP 푸시 수신자 에이전트의 GRUU가 SIP OPTIONS 요청의 Request-URI 부분에 포함되어 있음을 알 수 있다. 이벤트 160에서, SIP/IP 코어는 SIP OPTIONS 요청을 SIP 푸시 수신자 에이전트에 전달한다. 이벤트 170에서, SIP 푸시 수신자 에이전트는 SIP 푸시 수신자 에이전트의 능력에 관련된 정보를 포함한 SIP 200 OK를 SIP/IP 코어에 전송한다. SIP 200 OK 응답은 또한 추가적인 푸시 옵션 또는 추가적인 푸시 옵션이 획득될 수 있는 URI를 포함하는 바디부를 포함할 수 있다. 다음은 이 SIP 200 OK 응답의 일 실시예이다.

SIP 200 OK 응답의 컨텐츠-유형 부분은 푸시 수시 에이전트의 능력을 획득할 수 있는 URL를 포함하고 있음을 알 수 있다. 이벤트 180에서, SIP/IP 코어는 SIP 200 OK 응답을 SIP 푸시 송신자 에이전트에 전달한다.

다른 실시예에서, 푸시 수신자 에이전트가 SIP OPTIONS 요청에서 자신의 GRUU를 푸시 송신자 에이전트에 제공하기 보다는, 푸시 송신자 에이전트가 SIP SUBSCRIBE 메시지를 이용하여 SIP/IP 코어에게 푸시 수신자 에이전트의 GRUU를 요청한다. SIP/IP 코어는 SIP NOTIFY 메시지에서 푸시 수신자 에이전트의 GRUU 값을 반환하고, 그 후, 푸시 송신자 에이전트는 이 GRUU를 이용하여 푸시 수신자 에이전트의 능력을 요청하는 SIP OPTIONS 요청을 푸시 수신자 에이전트에 전송한다.

도 2는 이 실시예 하에서 SIP 푸시 클라이언트(또는 SIP 푸시 수신자 에이전트; 10)와, SIP/IP 코어(20)와 SIP 푸시 서버(또는 SIP 푸시 송신자 에이전트; 30) 사이의 예시적인 메시지 흐름을 나타낸다. 이벤트 210에서, SIP 푸시 송신자 에이전트는 SIP/IP 코어에 SIP SUBSCRIBE 요청을 전송한다. 다음은 이 SIP SUBSCRIBE 요청의 일 실시예이다.

이벤트 220에서, SIP/IP 코어는 SIP SUBSCRIBE 요청을 수신하고 SIP 200 OK 응답을 SIP 푸시 송신자 에이전트에 전송한다. 이벤트 230에서, SIP/IP 코어는 등록 프로세스 동안 획득하였던 SIP Push 수신 에이전트의 공개 GRUU 값을 포함하는 SIP NOTIFY를 SIP 푸시 송신자 에이전트에 전송한다. 다음은 이 SIP NOTIFY 요청의 일 실시예이다.

이벤트 240에서, SIP 푸시 송신자 에이전트는 SIP 200 OK를 SIP/IP 코어에 전송한다. 이벤트 250에서, SIP 푸시 송신자 에이전트는 SIP/IP 코어에, Request-URI에서 포함시킨 SIP OPTIONS 요청, SIP 푸시 수신자 에이전트의 공개 GRUU를 전송한다. 즉, SIP OPTIONS 요청은 특정된 GRUU를 갖는 SIP 푸시 수신자 에이전트에 어드레스 지정된다. 다음은 이 SIP OPTIONS 요청의 일 실시예이다.

이벤트 260에서, SIP/IP 코어는 SIP OPTIONS 요청을 특정된 GRUU를 갖는 SIP 푸시 수신자 에이전트에 전달한다. 이벤트 270에서, SIP 푸시 수신자 에이전트는 SIP 푸시 수신자 에이전트의 능력에 관련된 정보를 포함한 SIP 200 OK 응답을 SIP/IP 코어에 전송한다. SIP 200 OK 응답은 또한 추가적인 푸시 옵션 또는 추가적인 푸시 옵션이 획득될 수 있는 URI를 포함하는 바디부를 포함할 수 있다. 다음은 이 SIP 200 OK 응답의 일 실시예이다.

이벤트 280에서, SIP/IP 코어는 SIP 200 OK 응답을 SIP 푸시 송신자 에이전트에 전달한다.

다른 실시예에서, SIP 푸시 송신자 에이전트는 최초 SIP REGISTER 요청의 컨텐츠를 포함하는 보디부를 포함하는 제3자 등록 메카니즘을 이용하여 GRUU를 획득할 수 있다. 최초의 SIP REGISTER 요청은 SIP 푸시 수신자 에이전트에 의해 전송된 최초 SIP REGISTER 요청으로부터의 콘택 헤더 값을 포함할 수 있다. 바디부는 GRUU를 직접 포함할 수 없고 최초의 SIP REGISTER 요청의 콘택 헤더가 sip.instance 피쳐 태그를 포함할 수 있다. SIP/IP 코어의 정책이 최초의 SIP REGISTER 요청의 콘택 헤더에서의 sip.instance 피쳐 태그의 값과 동일하게 설정된 공개 GRUU의 "gr" 파라미터로 등록된 PUI 또는 AoR로부터 공개 GRUU를 유도할 것임을 SIP 푸시 송신자 에이전트가 알고 있다면, SIP 푸시 송신자 에이전트는 또한 방금 등록하였던 SIP 푸시 수신자 에이전트의 GRUU를 유도할 수 있다.

상기에서 설명한 컴포넌트는 상기 설명한 바와 같은 동작과 관련된 명령어를 실행할 수 있는 처리 컴포넌트를 포함할 수도 있다. 도 3은 본원에서 설명된 하나 이상의 실시예를 구현하는 데에 적합한 처리 컴포넌트를 포함하는 시스템(1300)의 한 예를 예시한다. 프로세서(1310)(중앙처리 장치 즉 CPU로도 지칭될 수 있음)외에, 시스템(1300)은 네트워크 연결 디바이스(1320), RAM(random access memory)(1330), ROM(read only memory)(1340), 보조 저장장치(1350), 및 입력/출력(I/O) 디바이스(1360)를 포함할 수 있다. 이 컴포넌트들은 버스(1370)를 통해 서로 통신할 수 있다. 일부 경우에, 이 컴포넌트들의 몇몇은 없을 수 있거나 도시된 다른 컴포넌트들과 또는 도시되지 않은 다른 컴포넌트들과 다양한 조합으로 조합될 수 있다. 이 컴포넌트들은 단일한 물리적 엔티티에 또는 하나 보다 많은 물리적 엔티티에 위치될 수 있다. 프로세서(1310)에 의해 행해지는 것으로서 본원에 설명된 임의의 동작들은 프로세서(1310) 단독으로 또는 DSP(1380)와 같은 도면에 도시된 하나 이상의 다른 컴포넌트들과 또는 도시되지 않은 다른 컴포넌트들과 연계하여 행해질 수 있다. DSP(1380)가 별개의 컴포넌트로서 도시되었을 지라도, DSP(1380)는 프로세서(1310)에 통합될 수 있다.

프로세서(1310)는 프로세서가 네트워크 연결 디바이스(1320), RAM(1330), ROM(1340), 또는 보조 저장장치(1350)(하드 디스크, 플로피 디스크, 또는 광학식 디스크와 같은 다양한 디스크 기반 시스템을 포함할 수 있음)에서 엑세스할 수 있는 명령어, 코드, 컴퓨터 프로그램, 또는 스크립트를 실행한다. 단 하나의 CPU(1310)만이 도시되어 있지만, 다수의 프로세서가 있을 수 있다. 따라서, 명령어가 하나의 프로세서에 의해 실행되는 것으로 기술되었지만, 이 명령어들은 하나 이상의 다수의 프로세서에 의해 동시에 또는 직렬로 그 밖의 방식으로 실행될 수도 있다. 프로세서(1310)는 하나 이상의 CPU 칩으로 구현될 수 있다.

네트워크 연결 디바이스(1320)는 모뎀, 모뎀 뱅크, 이더넷 디바이스, USB(universal serial bus) 인터페이스 디바이스, 직렬 인터페이스, 토큰 링 디바이스, 광섬유 분포 데이터 인터페이스(FDDI;fiber distributed data interface) 디바이스, 무선 근거리 통신망(WLAN;wireless local area network) 디바이스, CDMA(code division multiple access) 디바이스와 같은 무선 트랜시버, GSM(global system for mobile communication) 무선 트랜시버 디바이스, WiMAX(worldwide interoperability for microwave access) 디바이스 및/또는 네트워크에 연결하기 위한 기타 공지된 디바이스의 형태일 수 있다. 이 네트워크 연결 디바이스(1320)들은 프로세서(1310)로 하여금, 프로세서(1310)가 정보를 수신할 수 있거나 프로세서(1310)가 정보를 출력할 수 있는 네트워크들 또는 하나 이상의 원격통신 네트워크 또는 인터넷과 통신하도록 할 수 있다. 네트워크 연결 디바이스(1320)는 데이터를 무선으로 송신 및/또는 수신할 수 있는 하나 이상의 트랜시버 컴포넌트(1325)도 또한 포함할 수 있다.

RAM(1330)은 휘발성 데이터를 저장하거나 프로세서(1310)에 의해 실행되는 명령어를 저장하는 데에 사용될 수도 있다. ROM(1340)은 일반적으로 보조 저장장치(1350)의 메모리 용량 보다 작은 메모리 용량을 갖는 비휘발성 메모리 디바이스이다. ROM(1340)은 명령어를 저장하거나 명령어의 실행 동안 판독되는 데이터를 저장하는 데에 사용될 수 있다. RAM(1330) 및 ROM(1340) 양자 모두에 액세스하는 것은 일반적으로 보조 저장장치(1350)에 액세스하는 것 보다 빠르다. 보조 저장장치(1350)는 일반적으로 하나 이상의 디스크 드라이브 또는 테이프 드라이브로 구성되고 RAM(1330)이 모든 작업 데이터를 유지할 정도로 크지 않다면 오버플로우 데이터 저장 디바이스로서 또는 데이터의 비휘발성 저장을 위해 사용될 수도 있다. 보조 저장장치(1350)는 또한 RAM(1330)에 로딩된 프로그램이 실행을 위해 선택되었을 때 그러한 프로그램을 저장하는 데에 사용될 수 있다.

I/O 디바이스(1360)는 LCD(liquid crystal displays), 터치 스크린 디스플레이, 키보드, 키패드, 스위치, 다이얼, 마우스, 트랙볼, 음성 인식기, 카드 판독기, 종이 테이프 판독기, 프린터, 비디오 모니터, 또는 기타 공지된 입력/출력 디바이스들을 포함할 수 있다. 또한, 트랜시버(1325)는 네트워크 연결 디바이스(1320)의 컴포넌트 대신에 또는 이 컴포넌트에 추가하여 I/O 디바이스(1360)의 컴포넌트인 것으로 고려될 수 있다.

일 실시예에서, 사용자 에이전트의 능력들을 전달하는 방법이 제공된다. 본 방법은 적어도 하나의 푸시 자원을 포함하는 푸시 자원 식별자 피쳐 태그를 포함하는 콘택 헤더를 포함한 SIP 메시지를 사용자 에이전트가 전송하는 것을 포함한다.

대안의 실시예에서, SIP 푸시 수신자 에이전트가 제공된다. 푸시 수신자 에이전트는, 적어도 하나의 푸시 자원을 포함하는 푸시 자원 식별자 피쳐 태그를 포함하는 콘택 헤더를 포함한 SIP 메시지를 푸시 수신자 에이전트가 전송하도록 구성된 컴포넌트를 포함한다.

대안의 실시예에서, SIP 푸시 송신자 에이전트가 제공된다. 푸시 송신자 에이전트는, 적어도 하나의 푸시 자원을 포함하는 푸시 자원 식별자 피쳐 태그를 포함하는 콘택 헤더를 포함한 SIP 메시지를 푸시 송신자 에이전트가 수신하도록 구성된 컴포넌트를 포함한다.

하기의 3GPP(3rd Generation Partnership Project) 기술 규격(TS;Technical Specification) 및 IETF(Internet Engineering Task Force) RFC(Requests For Comments)는 본 명세서에서는 참조로서 포함하는데, 이들로는 [RFC 3261] 세션 개시 프로토콜(Session Initiation Protocol; SIP), [RFC 3265] SIP-특유의 이벤트 통지, [RFC 3680] 등록 이벤트 패키지, SIP에서 GRUU(Globally Routable User Agent (UA) URI)를 획득 및 이용하는 [draft-ietf-sip-gruu], [draft-ietf-sipping-gruu-reg-event] GRUU 등록 이벤트, OMA-TS-SIP_Push-V1_0-20080416-D, 3GPP TS 23.218, 및 3GPP TS 24.229가 있다.

수개의 실시예들이 본 발명의 명세서에 제공되었지만, 개시된 시스템들 및 방법들은 본 발명의 범위 또는 범주를 벗어남이 없이 많은 다른 특정 형태로 구현될 수 있음을 알아야 한다. 본 예들은 예시적인 것으로 간주되어야 하며 제한적인 것으로 간주되어서는 안 되며, 본 발명은 본 명세서에 주어진 세부 내용으로 제한되지 않는다. 예를 들어, 여러 엘리먼트 또는 컴포넌트가 다른 시스템 내에 결합 또는 통합될 수 있거나 또는 특정 특징부들이 생략되거나 또는 실시되지 않을 수 있다.

또한, 여러 실시예들로 설명되어 예시된 기술, 시스템, 서브시스템 및 방법들이 본 발명의 범위에 벗어남이 없이 개별적으로 또는 별개의 것으로 다른 시스템, 모듈, 기술 또는 방법에 결합 또는 통합될 수 있다. 서로 통신 또는 직접 연결된 것으로서 나타내어지거나 설명되어 있는 다른 항목들이 전기적으로, 기계적으로 또는 다른 방식으로 일부 인터페이스, 디바이스 또는 중간 컴포넌트를 통하여 간접적으로 연결 또는 통신할 수 있다. 수정, 대체 및 변경의 다른 예들이 당해 기술 분야의 숙련된 자에게 이해될 수 있으며 본 명세서에 설명된 범위 및 사상에 벗어남이 없이 이루어질 수 있다.

10: SIP 푸시 수신자 에이전트
20: SIP/IP 코어
30: SIP 푸시 송신자 에이전트
1310: 프로세서(CPU)
1320: 네트워크 연결 디바이스
1330: RAM
1340: ROM
1350: 보조 저장장치

Claims

사용자 에이전트(UA; user agent)의 능력을 전달하는 방법에 있어서,
상기 UA가, 적어도 하나의 푸시 자원을 포함하는 푸시 자원 식별자 피쳐 태그(Push Resource Identifier feature tag)를 포함하는 콘택 헤더를 포함한 SIP 메시지를 전송하는 것을 포함하는 UA의 능력 전달 방법.
제1항에 있어서, 상기 콘택 헤더는 GRUU[Globally Routable UA URI(Uniform Resource Identifier)]를 더 포함하는 것인 UA의 능력 전달 방법.
제1항에 있어서, 상기 SIP 메시지는 MIME(Multipurpose Internet Mail Extensions) 유형 "메시지/외부 바디부(message/external-body)"를 포함하는 헤더를 더 포함하는 것인 UA의 능력 전달 방법.
제3항에 있어서, 상기 헤더는 UA의 OMA(Open Mobile Alliance) UA 프로파일 문서를 가르키는 URI를 더 포함하는 것인 UA의 능력 전달 방법.
제3항에 있어서, 상기 헤더는 수락 헤더(Accept Header)인 것인 UA의 능력 전달 방법.
제4항에 있어서, 상기 헤더는 수락 헤더(Accept Header)인 것인 UA의 능력 전달 방법.
제3항에 있어서, 상기 헤더는 컨텐츠-유형 헤더(Content-Type Header)인 것인 UA의 능력 전달 방법.
제4항에 있어서, 상기 헤더는 컨텐츠-유형 헤더(Content-Type Header)인 것인 UA의 능력 전달 방법.
제1항에 있어서, 상기 SIP 메시지는 상기 UA에 의해 지원되는 SIP 메소드(SIP Method)를 포함하는 허용 헤더(Allow header)를 더 포함하는 것인 UA의 능력 전달 방법.
제1항에 있어서, 상기 SIP 메시지는 보디부를 더 포함하는 것인 UA의 능력 전달 방법.
제1항에 있어서, 상기 SIP 메시지는 컨텐츠-디스포지션(Content-Disposition) 내의 "연결(attachment)"을 더 포함하는 것인 UA의 능력 전달 방법.
제1항에 있어서, 상기 SIP 메시지는,
푸시 수신자 에이전트의 모델,
푸시 수신자 에이전트의 벤더(vendor), 및
푸시 수신자 에이전트의 버전 중 적어도 하나를 포함하는 사용자 에이전트 헤더를 더 포함하는 것인 UA의 능력 전달 방법.
제1항에 있어서, 상기 SIP 메시지는 SIP OPTIONS 요청인 것인 UA의 능력 전달 방법.
제1항에 있어서, 상기 SIP 메시지는 SIP 200 OK 응답인 것인 UA의 능력 전달 방법.
세션 개시 프로토콜(SIP; Session Initiation Protocol) 푸시 수신자 에이전트(Push Receiver Agent)에 있어서,
적어도 하나의 푸시 자원을 포함하는 푸시 자원 식별자 피쳐 태그(Push Resource Identifier feature tag)를 포함하는 콘택 헤더를 포함한 SIP 메시지를 상기 푸시 수신자 에이전트가 전송하도록 구성된 컴포넌트를 포함하는 SIP 푸시 수신자 에이전트.
제15항에 있어서, 상기 콘택 헤더는 GRUU[Globally Routable UA URI(Uniform Resource Identifier)]를 더 포함하는 것인 SIP 푸시 수신자 에이전트.
제15항에 있어서, 상기 SIP 메시지는 MIME(Multipurpose Internet Mail Extensions) 유형 "메시지/외부 바디부(message/external-body)"를 포함하는 헤더를 더 포함하는 것인 SIP 푸시 수신자 에이전트.
제17항에 있어서, 상기 헤더는 UA의 OMA(Open Mobile Alliance) UA 프로파일 문서를 가르키는 URI를 더 포함하는 것인 SIP 푸시 수신자 에이전트.
제17항에 있어서, 상기 헤더는 수락 헤더(Accept Header)인 것인 SIP 푸시 수신자 에이전트.
제18항에 있어서, 상기 헤더는 수락 헤더(Accept Header)인 것인 SIP 푸시 수신자 에이전트.
제17항에 있어서, 상기 헤더는 컨텐츠-유형 헤더(Content-Type Header)인 것인 SIP 푸시 수신자 에이전트.
제18항에 있어서, 상기 헤더는 컨텐츠-유형 헤더(Content-Type Header)인 것인 SIP 푸시 수신자 에이전트.
제15항에 있어서, 상기 SIP 메시지는 상기 푸시 수신자 에이전트에 의해 지원되는 SIP 메소드(SIP Method)를 포함하는 허용 헤더(Allow header)를 더 포함하는 것인 SIP 푸시 수신자 에이전트.
제15항에 있어서, 상기 SIP 메시지는 보디부를 더 포함하는 것인 SIP 푸시 수신자 에이전트.
제24항에 있어서, 상기 SIP 메시지는 컨텐츠-디스포지션(Content-Disposition) 내의 "연결(attachment)"을 더 포함하는 것인 SIP 푸시 수신자 에이전트.
제15항에 있어서, 상기 SIP 메시지는,
푸시 수신자 에이전트의 모델,
푸시 수신자 에이전트의 벤더(vendor), 및
푸시 수신자 에이전트의 버전 중 적어도 하나를 포함하는 사용자 에이전트 헤더를 더 포함하는 것인 SIP 푸시 수신자 에이전트.
제15항에 있어서, 상기 SIP 메시지는 SIP OPTIONS 요청인 것인 SIP 푸시 수신자 에이전트.
제15항에 있어서, SIP OPTIONS 요청의 수신시, 송신자의 능력에 관한 정보를 포함하는 SIP 200 OK 응답이 전송되는 것인 SIP 푸시 수신자 에이전트.
제15항에 있어서, 상기 SIP 메시지는 SIP 200 OK 응답인 것인 SIP 푸시 수신자 에이전트.
세션 개시 프로토콜(SIP; Session Initiation Protocol) 푸시 송신자 에이전트(Push Sender Agent)에 있어서,
적어도 하나의 푸시 자원을 포함하는 푸시 자원 식별자 피쳐 태그(Push Resource Identifier feature tag)를 포함하는 콘택 헤더를 포함한 SIP 메시지를 상기 푸시 송신자 에이전트가 수신하도록 구성된 컴포넌트를 포함하는 SIP 푸시 송신자 에이전트.
제30항에 있어서, 상기 콘택 헤더는 GRUU[Globally Routable UA URI(Uniform Resource Identifier)]를 더 포함하는 것인 SIP 푸시 송신자 에이전트.
제30항에 있어서, 상기 SIP 메시지는 MIME(Multipurpose Internet Mail Extensions) 유형 "메시지/외부 바디부(message/external-body)"를 포함하는 헤더를 더 포함하는 것인 SIP 푸시 송신자 에이전트.
제32항에 있어서, 상기 헤더는 UA의 OMA(Open Mobile Alliance) UA 프로파일 문서를 가르키는 URI를 더 포함하는 것인 SIP 푸시 송신자 에이전트.
제32항에 있어서, 상기 헤더는 수락 헤더(Accept Header)인 것인 SIP 푸시 송신자 에이전트.
제33항에 있어서, 상기 헤더는 수락 헤더(Accept Header)인 것인 SIP 푸시 송신자 에이전트.
제32항에 있어서, 상기 헤더는 컨텐츠-유형 헤더(Content-Type Header)인 것인 SIP 푸시 송신자 에이전트.
제33항에 있어서, 상기 헤더는 컨텐츠-유형 헤더(Content-Type Header)인 것인 SIP 푸시 송신자 에이전트.
제30항에 있어서, 상기 SIP 메시지는 메시지를 전송하였던 푸시 수신자 에이전트(Push Receiver Agent)에 의해 지원되는 SIP 메소드(SIP Method)를 포함하는 허용 헤더(Allow header)를 더 포함하는 것인 SIP 푸시 송신자 에이전트.
제30항에 있어서, 상기 SIP 메시지는 보디부를 더 포함하는 것인 SIP 푸시 송신자 에이전트.
제39항에 있어서, 상기 SIP 메시지는 컨텐츠-디스포지션(Content-Disposition) 내의 "연결(attachment)"을 더 포함하는 것인 SIP 푸시 송신자 에이전트.
제30항에 있어서, 상기 SIP 메시지는,
메시지를 전송하였던 푸시 수신자 에이전트의 모델,
메시지를 전송하였던 푸시 수신자 에이전트의 벤더(vendor), 및
메시지를 전송하였던 푸시 수신자 에이전트의 버전 중 적어도 하나를 포함하는 사용자 에이전트 헤더를 더 포함하는 것인 SIP 푸시 송신자 에이전트.
제30항에 있어서, 상기 SIP 메시지는 SIP OPTIONS 요청인 것인 SIP 푸시 송신자 에이전트.
제42항에 있어서, SIP OPTIONS 요청의 수신시, 송신자의 능력에 관한 정보를 포함하는 SIP 200 OK 응답이 전송되는 것인 SIP 푸시 송신자 에이전트.
제30항에 있어서, 상기 SIP 메시지는 SIP 200 OK 응답인 것인 SIP 푸시 송신자 에이전트.