SIP扩展：事件通知框架

需积分: 9 129 浏览量更新于2024-07-26 收藏 52KB PDF 举报

"RFC3265 - Session Initiation Protocol (SIP)-Specific Event Notification" 本文档RFC3265详细阐述了对Session Initiation Protocol (SIP)的一个扩展，其目的是建立一个可扩展的框架，使得SIP节点能够请求远程节点发送特定事件发生的通知。这个扩展机制对于实时通信和会话管理具有重要意义，它允许SIP系统中的参与者订阅并接收与会话相关的事件更新。 SIP是一种基于文本的应用层控制协议，主要用于发起、修改和终止多媒体通信会话，如语音通话、视频会议等。在SIP协议中，事件通知的引入是为了增强系统的交互性和实时性，使得用户或应用程序可以即时了解会话状态的变化。例如，当电话振铃、会话被挂断或者有新消息时，接收方可以通过SIP事件通知机制得到这些信息。 RFC3265中定义的事件通知机制并不是一种通用的事件订阅基础设施，而是专门针对SIP环境设计的。这并不意味着它适用于所有类型的事件订阅和通知，而是专注于满足SIP协议中的特定需求。未来可能会有具体的应用场景或标准基于此文档进行标准化。文档首先明确了其作为互联网标准草案的地位，并且指出该文档可能需要持续讨论和完善。同时，文档强调了知识产权的保护，声明由互联网学会（The Internet Society）在2002年发布，所有权利保留。文档的抽象部分再次重申了扩展的目标，即为SIP提供一个灵活的结构，使得节点间可以请求并传递特定事件的通知。这种机制可以用于各种具体的场景，但不覆盖所有类型的事件订阅。 RFC3265的主体部分详细描述了事件通知的语法、语义以及实现细节，包括事件订阅的流程、事件包的构造、事件状态的维护以及错误处理等。它还涵盖了如何使用SIP的"SUBSCRIBE"方法来发起订阅请求，以及"NOTIFY"方法来发送事件通知。此外，还讨论了与安全、隐私和资源管理等相关问题。 RFC3265为SIP提供了一种强大而灵活的工具，使得网络中的设备和服务能够更加智能化地响应会话状态的变化，提升了通信的效率和用户体验。这一标准的制定对于推动SIP在VoIP（Voice over IP）和其他多媒体通信领域的应用具有重要作用。

RFC 3265 SIP-Specific Event Notification June 2002

The Request URI of a SUBSCRIBE request, most importantly, contains

enough information to route the request to the appropriate entity per

the request routing procedures outlined in SIP [1]. It also contains

enough information to identify the resource for which event

notification is desired, but not necessarily enough information to

uniquely identify the nature of the event (e.g.,

"sip:adam@dynamicsoft.com" would be an appropriate URI to subscribe

to for my presence state; it would also be an appropriate URI to

subscribe to the state of my voice mailbox).

Subscribers MUST include exactly one "Event" header in SUBSCRIBE

requests, indicating to which event or class of events they are

subscribing. The "Event" header will contain a token which indicates

the type of state for which a subscription is being requested. This

token will be registered with the IANA and will correspond to an

event package which further describes the semantics of the event or

event class. The "Event" header MAY also contain an "id" parameter.

This "id" parameter, if present, contains an opaque token which

identifies the specific subscription within a dialog. An "id"

parameter is only valid within the scope of a single dialog.

If the event package to which the event token corresponds defines

behavior associated with the body of its SUBSCRIBE requests, those

semantics apply.

Event packages may also define parameters for the Event header; if

they do so, they must define the semantics for such parameters.

3.1.3. Additional SUBSCRIBE Header Values

Because SUBSCRIBE requests create a dialog as defined in SIP [1],

they MAY contain an "Accept" header. This header, if present,

indicates the body formats allowed in subsequent NOTIFY requests.

Event packages MUST define the behavior for SUBSCRIBE requests

without "Accept" headers; usually, this will connote a single,

default body type.

Header values not described in this document are to be interpreted as

described in SIP [1].

3.1.4. Subscriber SUBSCRIBE Behavior

3.1.4.1. Requesting a Subscription

SUBSCRIBE is a dialog-creating method, as described in SIP [1].

When a subscriber wishes to subscribe to a particular state for a

resource, it forms a SUBSCRIBE message. If the initial SUBSCRIBE

Roach Standards Track [Page 7]

RFC 3265 SIP-Specific Event Notification June 2002

represents a request outside of a dialog (as it typically will), its

construction follows the procedures outlined in SIP [1] for UAC

request generation outside of a dialog.

This SUBSCRIBE request will be confirmed with a final response.

200-class responses indicate that the subscription has been accepted,

and that a NOTIFY will be sent immediately. A 200 response indicates

that the subscription has been accepted and that the user is

authorized to subscribe to the requested resource. A 202 response

merely indicates that the subscription has been understood, and that

authorization may or may not have been granted.

The "Expires" header in a 200-class response to SUBSCRIBE indicates

the actual duration for which the subscription will remain active

(unless refreshed).

Non-200 class final responses indicate that no subscription or dialog

has been created, and no subsequent NOTIFY message will be sent. All

non-200 class responses (with the exception of "489", described

herein) have the same meanings and handling as described in SIP [1].

A SUBSCRIBE request MAY include an "id" parameter in its "Event"

header to allow differentiation between multiple subscriptions in the

same dialog.

3.1.4.2. Refreshing of Subscriptions

At any time before a subscription expires, the subscriber may refresh

the timer on such a subscription by sending another SUBSCRIBE request

on the same dialog as the existing subscription, and with the same

"Event" header "id" parameter (if one was present in the initial

subscription). The handling for such a request is the same as for

the initial creation of a subscription except as described below.

If the initial SUBSCRIBE message contained an "id" parameter on

the "Event" header, then refreshes of the subscription must also

contain an identical "id" parameter; they will otherwise be

considered new subscriptions in an existing dialog.

If a SUBSCRIBE request to refresh a subscription receives a "481"

response, this indicates that the subscription has been terminated

and that the subscriber did not receive notification of this fact.

In this case, the subscriber should consider the subscription

invalid. If the subscriber wishes to re-subscribe to the state, he

does so by composing an unrelated initial SUBSCRIBE request with a

freshly-generated Call-ID and a new, unique "From" tag (see section

3.1.4.1.)

Roach Standards Track [Page 8]

剩余37页未读，继续阅读

硅与神经元

粉丝: 2
资源: 4

SIP扩展：事件通知框架

RFC-2543---SIP Session Initiation Protocol.doc

SIP(Session Initiation Protocol )详解

RFC3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP).docx

rfc1305-1992

rfc3261中文版 pdf 下载

letf rfc 3261

rfc全部文档离线下载rfc1-rfc8505

上述中，info与rfc2833的包差异在哪儿

keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem

详细解释dtmf协商的数据包中关于info与rfc2833还有inband协商包的差异

最新资源