Network Working Group R. Mahy
Request for Comments: 3842 Cisco Systems, Inc.
Category: Standards Track August 2004
A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）のためのメッセージサマリとメッセージ待機表示イベントパッケージ
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent.
この文書では、興味のあるユーザエージェントにメッセージングシステムからのステータスとメッセージの要約を待っているメッセージを運ぶためにセッション開始プロトコル（SIP）イベントパッケージについて説明します。
Table of Contents
目次
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background and Appropriateness . . . . . . . . . . . . . . . 3
3. Event Package Formal Definition . . . . . . . . . . . . . . 4
3.1. Event Package Name . . . . . . . . . . . . . . . . . . 4
3.2. Event Package Parameters . . . . . . . . . . . . . . . 4
3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 4
3.4. Subscription Duration. . . . . . . . . . . . . . . . . 4
3.5. NOTIFY Bodies. . . . . . . . . . . . . . . . . . . . . 4
3.6. Subscriber Generation of SUBSCRIBE Requests. . . . . . 6
3.7. Notifier Processing of SUBSCRIBE Requests. . . . . . . 6
3.8. Notifier Generation of NOTIFY Requests . . . . . . . . 7
3.9. Subscriber Processing of NOTIFY Requests . . . . . . . 7
3.10. Handling of Forked Requests. . . . . . . . . . . . . . 7
3.11. Rate of Notifications. . . . . . . . . . . . . . . . . 7
3.12. State Agents and Lists . . . . . . . . . . . . . . . . 8
3.13. Behavior of a Proxy Server . . . . . . . . . . . . . . 8
4. Examples of Usage . . . . . . . . . . . . . . . . . . . . . 8
4.1. Example Message Flow . . . . . . . . . . . . . . . . . 8
4.2. Example Usage with Callee Capabilities and Caller
Preferences. . . . . . . . . . . . . . . . . . . . . . 14
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. New Event-Package Definition . . . . . . . . . . . . . 15
5.2. Body Format Syntax . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
7.1. SIP Event Package Registration for message-summary . . 16
7.2. MIME Registration for application/
simple-message-summary . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . 17
10.2. Informational References . . . . . . . . . . . . . . . 18
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[3]。
Message Waiting Indication is a common feature of telephone networks. It typically involves an audible or visible indication that messages are waiting, such as playing a special dial tone (which in telephone networks is called message-waiting dial tone), lighting a light or indicator on the phone, displaying icons or text, or some combination.
メッセージ待機の指示は、電話網の共通の特徴です。それは、典型的には、メッセージは、例えば、（電話網にメッセージ待ちダイヤルトーンと呼ばれる）特殊なダイヤルトーンを再生する携帯電話に光またはインジケータを点灯、アイコンを表示またはテキストとして、待機していることを可聴又は可視表示を含む、またはいくつか組み合わせ。
Message-waiting dial tone is similar to but distinct from stutter dial tone. Both are defined in GR-506 [11].
メッセージ受信のダイヤルトーンがに似ていますが、スタッターダイヤルトーンとは区別されます。双方は、GR-506 [11]で定義されています。
The methods in the SIP [1] base specification were only designed to solve the problem of session initiation for multimedia sessions, and rendezvous. Since Message Waiting Indication is really status information orthogonal to a session, it was not clear how an IP telephone acting as a SIP User Agent would implement comparable functionality. Members of the telephony community viewed this as a shortcoming of SIP.
SIP [1]基本仕様のメソッドのみが、セッション、マルチメディアセッションの開始、およびランデブーの問題を解決するために設計しました。メッセージ待機表示が実際のセッションに直交するステータス情報であるので、SIPユーザーエージェントとして動作するIP電話は、同等の機能を実装する方法を明確ではありませんでした。テレフォニーコミュニティのメンバーは、SIPの欠点としてこれを見ました。
Users want the useful parts of the functionality they have using traditional analog, mobile, and PBX telephones. It is also desirable to provide comparable functionality in a flexible way that allows for more customization and new features. SIP Specific Event Notification (RFC 3265 -- SIP Events) [2] is an appropriate mechanism to use in this environment, as it preserves the user mobility and rendezvous features which SIP provides.
ユーザーは、従来のアナログ、モバイル、およびPBX電話を使用している機能の便利なパーツが欲しいです。より多くのカスタマイズや新機能を可能柔軟な方法で同等の機能を提供することが望ましいです。 SIP固有のイベント通知（RFC 3265 - SIPイベント）は、ユーザの移動性及びSIPが提供するランデブ機能を保存する[2]、この環境で使用するための適切な機構です。
Using SIP-Specific Event Notification, a Subscriber User Agent (typically an IP phone or SIP software User Agent) subscribes to the status of their messages. A SIP User Agent acting on behalf of the user's messaging system then notifies the Subscriber each time the messaging account's messages have changed. (This Notifier could be composed with a User Agent that provides a real-time media interface to send or receive messages, or it could be a stand-alone entity.) The Notifier sends a message summary in the body of a NOTIFY, encoded in a new MIME type defined later in this document. A User Agent can also explicitly fetch the current status.
SIP固有のイベント通知を使用して、加入者のユーザーエージェント（通常はIP電話やSIPソフトウェアユーザエージェント）は、それらのメッセージの状態にサブスクライブします。ユーザーのメッセージングシステムに代わって動作するSIPユーザエージェントは、サブスクライバーにメッセージングアカウントのメッセージが変更されているたびに通知します。 （このNotifierは、メッセージを送信または受信するリアルタイムメディア・インターフェースを提供し、ユーザーエージェントで構成することができ、またはそれは、スタンドアロンのエンティティである可能性があります。）Notifierはでエンコードされ、NOTIFYのボディにメッセージの要約を送信します本書の後半で定義された新しいMIMEタイプ。ユーザーエージェントはまた、明示的に現在の状態を取得することができます。
A SIP User Agent MAY subscribe to multiple accounts (distinguished by the Request URI). Multiple SIP User Agents MAY subscribe to the same account.
SIPユーザーエージェントは、複数のアカウント（リクエストURIによって区別される）に加入することができます。複数のSIPユーザエージェントは、同じアカウントに加入することができます。
Before any subscriptions or notifications are sent, each interested User Agent must be made aware of its messaging notifier(s). This MAY be manually configured on interested User Agents, manually configured on an appropriate SIP Proxy, or dynamically discovered based on requested caller preferences [4] and registered callee capabilities [5]. (For more information on usage with callee capabilities, see Section 4.2)
任意のサブスクリプションまたは通知が送信される前に、それぞれの興味ユーザーエージェントは、そのメッセージの通知（複数可）を認識しなければなりません。これは、手動で手動で適切なSIPプロキシで構成される、または動的に要求された発信者の好みに基づいて発見され、興味のユーザエージェント上に設定されるかもしれません[4]と登録着信機能[5]。 （呼び出し先機能を備えた使用方法の詳細については、4.2節を参照してください）
This document defines a SIP Event Package as defined in RFC 3265 [2]. The event-package token name for this package is:
この文書は、RFC 3265で定義されているSIPイベントパッケージを定義する[2]。このパッケージのイベント・パッケージトークン名は次のようになります。
"message-summary"
「メッセージ要約」
This package does not define any event package parameters.
このパッケージには、任意のイベントパッケージのパラメータを定義しません。
This package does not define any SUBSCRIBE bodies.
このパッケージには、任意の本体をSUBSCRIBE定義されていません。
Subscriptions to this event package MAY range from minutes to weeks. Subscriptions in hours or days are more typical and are RECOMMENDED. The default subscription duration for this event package is one hour.
このイベントパッケージへのサブスクリプションは、数分から数週間の範囲とすることができます。数時間または数日中にサブスクリプションは、より一般的であると推奨されています。このイベントパッケージのデフォルトのサブスクリプション期間は1時間です。
A simple text-based format is proposed to prevent an undue burden on low-end user agents, for example, inexpensive IP phones with no display. Although this format is text-based, it is intended for machine consumption only.
単純なテキストベースのフォーマットは非表示で、例えば、ローエンド・ユーザー・エージェントに過度の負担を防ぐために、安価なIP電話を提案しています。この形式はテキストベースですが、それが唯一のマシンの消費のために意図されます。
A future extension MAY define other NOTIFY bodies. If no "Accept" header is present in the SUBSCRIBE, the body type defined in this document MUST be assumed.
将来の拡張は、他の遺体をNOTIFY定義するかもしれません。いかなる「同意」ヘッダがSUBSCRIBEに存在しない場合、本文書で定義されたボディタイプが想定されなければなりません。
The format specified in this proposal attempts to separate orthogonal attributes of messages as much as possible. Messages are separated by message-context-class (for example: voice-message, fax-message, pager-message, multimedia-message, text-message, and none), by message status (new and old), and urgent and non-urgent type.
この提案で指定されたフォーマットは、できるだけメッセージの直交属性を分離しようとします。 （新旧）メッセージの状態によって、：（音声メッセージ、ファックスメッセージ、ポケットベルメッセージ、マルチメディア・メッセージ、テキスト・メッセージ、およびなしなど）、および緊急かつ非メッセージは、メッセージ・コンテキスト・クラスによって分離されています-urgentタイプ。
The text format begins with a simple status line, and optionally a summary line per message-context-class. Message-context-classes are defined in [7]. For each message-context-class, the total number of new and old messages is reported in the new and old fields.
テキスト形式は、単純なステータス行で始まり、メッセージ・コンテキストクラスごとの要約行を任意。メッセージコンテキストクラスは、[7]で定義されています。各メッセージ・コンテキスト・クラスの場合、新旧のメッセージの合計数は、新旧の分野で報告されます。
In some cases, detailed message summaries are not available. The status line allows messaging systems or messaging gateways to provide the traditional boolean message waiting notification.
いくつかのケースでは、詳細なメッセージ要約は利用できません。ステータス行は、メッセージング・システムまたはメッセージングゲートウェイは通知を待っている伝統的なブールメッセージを提供することができます。
Messages-Waiting: yes
メッセージウェイティング：はい
If the Request-URI or To header in a message-summary subscription corresponds to a group or collection of individual messaging accounts, the notifier MUST specify to which account the message-summary body corresponds. Note that the account URI MUST NOT be delimited with angle brackets ("<" and ">").
Request-URIまたはメッセージ・サマリーサブスクリプションにToヘッダは、個々のメッセージングアカウントのグループまたはコレクションに対応している場合、通知は、メッセージの要約ボディ対応を考慮してかを指定しなければなりません。アカウントURIは、角括弧（「<」と「>」）で区切られてはならないことに注意してください。
Message-Account: sip:alice@example.com
メッセージアカウント：SIP：alice@example.com
In the example that follows, more than boolean message summary information is available to the User Agent. There are two new and four old fax messages.
次の例では、ブールメッセージサマリ情報よりも多くのユーザーエージェントに提供されています。新しい2および4古いファックスメッセージがあります。
Fax-Message: 2/4
ファックス・メッセージ：2/4
After the summary, the format can optionally list a summary count of urgent messages. In the next example there are one new and three old voice messages, none of the new messages are urgent, but one of the old messages is. All counters have a maximum value of 4,294,967,295 ((2^32) - 1). Notifiers MUST NOT generate a request with a larger value. Subscribers MUST treat a larger value as 2^32-1.
要約した後、フォーマットは、必要に応じて緊急メッセージの要約数を一覧表示することができます。次の例では、新しいものと古い3つの音声メッセージ、新しいメッセージのどれが緊急ではないが、古いメッセージの一つであるがあります。すべてのカウンタが4,294,967,295の最大値を持っている（^ 32（2） - 1）。通知機能は、より大きな価値を持つ要求を生成してはなりません。加入者は2 ^ 32-1として大きな値を扱わなければなりません。
Voice-Message: 1/3 (0/1)
音声メッセージ：1/3（0/1）
Optionally, after the summary counts, the messaging systems MAY append RFC 2822 style message headers [9], which further describe newly added messages. Message headers MUST NOT be included in an initial NOTIFY, as new messages could be essentially unbounded in size. Message headers included in subsequent notifications MUST only correspond to messages added since the previous notification for that subscription. A messaging system which includes message headers in a NOTIFY MUST provide an administrator configurable mechanism to select which headers are sent. Headers likely for inclusion are To, From, Date, Subject, and Message-ID. Note that the formatting of these headers in this body is identical to that of SIP extension-headers, not the (similar) format defined in RFC 2822.
必要に応じて、要約カウントした後、メッセージングシステムは、さらに、新たに追加されたメッセージを記述している、[9] RFC 2822形式のメッセージヘッダを追加するかもしれません。新しいメッセージのサイズは、本質的に無制限可能性としてメッセージヘッダーは、最初のNOTIFYに含んではいけません。メッセージヘッダは、そのサブスクリプションのために前の通知以降に追加されたメッセージに対応している必要があり、後続の通知に含まれます。 NOTIFYのメッセージヘッダーを含むメッセージングシステムは、送信されるヘッダを選択するには、管理者設定可能な機構を提供しなければなりません。包含のための可能性のヘッダがあるには、日付、件名、およびメッセージID、から。この本体でこれらのヘッダのフォーマットはSIP拡張子-ヘッダはなく、RFC 2822で定義されている（同様の）形式のものと同一であることに留意されたいです。
Implementations which generate large notifications are reminded to follow the message size restrictions for unreliable transports articulated in Section 18.1.1 of SIP [1].
大規模な通知を生成する実装は、SIPのセクション18.1.1での関節信頼性の低いトランスポートのメッセージサイズの制限に従うことを思い出している[1]。
Mapping local message state to new/old message status and urgency is an implementation issue of the messaging system. However, the messaging notifier MUST NOT consider a message "old" merely because it generated a notification, as this could prevent another subscription from accurately receiving message-summary notifications. Likewise, the messaging system MAY use any suitable algorithm to determine that a message is "urgent".
新しい/古いメッセージステータスと緊急性にローカルメッセージ状態をマッピングすると、メッセージングシステムの実装の問題です。これは正確にメッセージサマリ通知を受けたから、別のサブスクリプションを防ぐことができるとして、それは、通知を生成しているためしかし、メッセージング通知は、単に「古い」メッセージを検討してはなりません。同様に、メッセージングシステムは、メッセージが「緊急」であることを判断するために、任意の適切なアルゴリズムを使用するかもしれません。
Messaging systems MAY use any algorithm for determining the appropriate message-context-class for a specific message. Systems which use Internet Mail SHOULD use the contents of the Message-Context header [7] (defined in RFC 3458) if present as a hint to make a context determination. Note that a composed messaging system does not need to support a given context in order to generate notifications identified with that context.
メッセージングシステムは、特定のメッセージのために適切なメッセージコンテキストクラスを決定するための任意のアルゴリズムを使用することができます。存在する場合、インターネットメールコンテキスト決意を作るためのヒントとして[7]（RFC 3458で定義された）メッセージコンテキストヘッダの内容を使用すべきで使用するシステム。合成メッセージングシステムは、そのコンテキストで識別通知を生成するために、指定されたコンテキストをサポートする必要がないことに注意してください。
Subscriber User Agents will typically SUBSCRIBE to message summary information for a period of hours or days, and automatically attempt to re-SUBSCRIBE well before the subscription is completely expired. If re-subscription fails, the Subscriber SHOULD periodically retry again until a subscription is successful, taking care to backoff to avoid network congestion. If a subscription has expired, new re-subscriptions MUST use a new Call-ID.
加入者のユーザエージェントは、通常、数時間または数日の期間、メッセージの要約情報を購読し、自動的にサブスクリプションが完全に有効期限が切れているだけでなく前に再加入することを試みます。再サブスクリプションが失敗した場合、サブスクリプションが成功するまで、加入者は、定期的にネットワークの混雑を避けるために、バックオフに世話をして、もう一度再試行する必要があります。サブスクリプションの有効期限が切れている場合は、新たに再サブスクリプションは、新しいコール-IDを使用しなければなりません。
The Subscriber SHOULD SUBSCRIBE to that user's message summaries whenever a new user becomes associated with the device (a new login). The Subscriber MAY also explicitly fetch the current status at any time. The subscriber SHOULD renew its subscription immediately after a reboot, or when the subscriber's network connectivity has just been re-established.
新しいユーザがデバイス（新しいログイン）に関連なるたびに加入者には、そのユーザのメッセージ要約を購読するべきです。また、加入者は、明示的に任意の時点で現在の状態を取得するかもしれません。加入者は、すぐに再起動後にそのサブスクリプションを更新すべきである、または加入者のネットワーク接続は、ちょうど再確立されたとき。
The Subscriber MUST be prepared to receive and process a NOTIFY with new state immediately after sending a new SUBSCRIBE, a SUBSCRIBE renewal, an unsubscribe, a fetch, or at any other time during the subscription.
加入者は、SUBSCRIBEリニューアル、退会、フェッチ、またはサブスクリプション中の他の時点で受信して、すぐに新しいSUBSCRIBEを送信した後に新しい状態をNOTIFY処理するために、準備しなければなりません。
When a user de-registers from a device (logoff, power down of a mobile device, etc.), subscribers SHOULD unsubscribe by sending a SUBSCRIBE message with an Expires header of zero.
場合デバイスからユーザデレジスタ（ログオフ、モバイルデバイス、等のパワーダウン）、加入者は、ゼロのExpiresヘッダとSUBSCRIBEメッセージを送信することによって解除すべきです。
When a SIP Messaging System receives SUBSCRIBE messages with the message-summary event-type, it SHOULD authenticate the subscription request. If authentication is successful, the Notifier MAY limit the duration of the subscription to an administrator defined amount of time as described in SIP Events [2].
SIPメッセージングシステムは、メッセージ要約イベント型でメッセージをSUBSCRIBE受信すると、サブスクリプション要求を認証する必要があります。認証が成功した場合、SIPイベント[2]に記載のように、通知は、時間の管理者が定義した量に、サブスクリプションの持続時間を制限することができます。
Immediately after a subscription is accepted, the Notifier MUST send a NOTIFY with the current message summary information. This allows the Subscriber to resynchronize its state. This initial synchronization NOTIFY MUST NOT include the optional RFC 2822 style message headers [8].
サブスクリプションが受け入れられた直後、Notifierは現在のメッセージの要約情報とNOTIFYを送らなければなりません。これは、加入者がその状態を再同期することができます。この初期同期オプションRFC 2822形式のメッセージヘッダを含んではいけませんNOTIFY [8]。
When the status of the messages changes sufficiently for a messaging account to change the number of new or old messages, the Notifier SHOULD send a NOTIFY message to all active subscribers of that account. NOTIFY messages sent to subscribers of a group or alias, MUST contain the message account name in the notification body.
十分メッセージングのためのメッセージの変更のステータスが新しいか古いメッセージの数を変更するにはアカウントた場合、Notifierはそのアカウントのすべてのアクティブな加入者にNOTIFYメッセージを送信する必要があります。グループまたはエイリアスの加入者に送信されたメッセージをNOTIFY、通知本文にメッセージのアカウント名を含まなければなりません。
A Messaging System MAY send a NOTIFY with an "Expires" header of "0" and a "Subscription-State" header of "terminated" before a graceful shutdown.
メッセージングシステムは、「0」のヘッダとグレースフルシャットダウンの前に「終了」の「サブスクリプション・ステート」ヘッダを「有効期限」とNOTIFYを送信することができます。
Upon receipt of a valid NOTIFY request, the subscriber SHOULD immediately render the message status and summary information to the end user in an implementation specific way.
有効なNOTIFYリクエストを受信すると、加入者は、すぐに実装固有の方法で、エンドユーザーへのメッセージのステータスと要約情報をレンダリングするべきです。
The Subscriber MUST be prepared to receive NOTIFYs from different Contacts corresponding to the same SUBSCRIBE. (The SUBSCRIBE may have been forked).
加入者は、同じSUBSCRIBEに対応する異なる連絡先からのNOTIFYを受信する準備をしなければなりません。 （forkされていてもよいSUBSCRIBE）。
Forked requests are allowed for this event type and may install multiple subscriptions. The Subscriber MAY render multiple summaries corresponding to the same account directly to the user, or MAY merge them as described below.
フォークされたリクエストは、このイベントタイプのために許可され、複数のサブスクリプションをインストールすることができます。加入者は、ユーザに直接同じアカウントに対応する複数の要約をレンダリングすることができる、または以下に説明するように、それらを統合し得ます。
If any of the "Messages-Waiting" status lines report "yes", then the merged state is "yes"; otherwise the merged state is "no".
「メッセージウェイティング」ステータスラインのいずれかが報告した場合は「はい」、そしてマージされた状態が「はい」です。それ以外の場合はマージされた状態が「ノー」です。
The Subscriber MAY merge summary lines in an implementation-specific way if all notifications contain at least one msg-summary line.
すべての通知は、少なくとも一つのMSG-要約行が含まれている場合、加入者は、実装固有の方法でサマリー行をマージするかもしれません。
A Notifier MAY choose to hold NOTIFY requests in "quarantine" for a short administrator-defined period (seconds or minutes) when the message status is changing rapidly. Requests in the quarantine which become invalid are replaced by newer notifications, thus reducing the total volume of notifications. This behavior is encouraged for implementations with heavy interactive use. Note that timely notification resulting in a change of overall state (messages waiting or not) and notification of newly added messages is probably more significant to the end user than a notification of newly deleted messages which do not affect the overall message waiting state (e.g., there are still new messages).
Notifierは、メッセージの状態が急速に変化しているの短い管理者が定義した期間（秒または分）のための「検疫」のNOTIFYリクエストを保持するために選ぶかもしれません。無効になっ検疫中の要求は、このように、通知の総量を削減する、新しい通知によって置き換えられます。この動作は重い対話的に使用して実装するために奨励されます。タイムリーな通知は、全体的な状態の変化を生じることに注意してください（メッセージが待機しているかどうか）と、新たに追加されたメッセージの通知は、おそらく全体的なメッセージ待ち状態に影響を与えることはありません新しく削除されたメッセージ（例えば、通知よりも、エンドユーザにとってより重要です）まだ新しいメッセージがあります。
Notifiers SHOULD NOT generate NOTIFY requests more frequently than once per second.
通知機能は、1秒に1回よりも頻繁にNOTIFYリクエストを生成するべきではありません。
A Subscriber MAY use an "alias" or "group" in the Request-URI of a subscription if that name is significant to the messaging system. Implementers MAY create a service which consolidates and summarizes NOTIFYs from many Contacts. This document does not preclude implementations from building state agents which support this event package. One way to implement such a service is with the event list extension [10].
その名前は、メッセージングシステムに有意である場合、加入者は、Request-URIのサブスクリプションの中で「エイリアス」または「グループ」を使用するかもしれません。実装者は統合し、多くの連絡先からのNOTIFYをまとめたサービスを作成することもできます。この文書では、このイベントパッケージをサポートする状態エージェントの構築から実装を妨げるものではありません。そのようなサービスを実現するための一つの方法は、イベントリストの拡張子[10]です。
There are no additional requirements on a SIP Proxy, other than to transparently forward the SUBSCRIBE and NOTIFY methods as required in SIP. However, Proxies SHOULD allow non-SIP URLs. Proxies and Redirect servers SHOULD be able to direct the SUBSCRIBE request to an appropriate messaging notifier User Agent.
SIPに必要に応じて透過的にSUBSCRIBEとNOTIFYメソッドを転送するよりも、他のSIPプロキシには追加の要件は、ありません。しかし、プロキシは非SIP URLを許可する必要があります。プロキシとリダイレクトサーバーは、適切なメッセージング通知ユーザーエージェントへのSUBSCRIBE要求を指示することができるべきです。
The examples shown below are for informational purposes only. For a normative description of the event package, please see sections 3 and 5 of this document.
以下に示す例は、情報提供のみを目的としています。イベントパッケージの規範的な説明については、セクション3と、この文書の5を参照してください。
In the example call flow below, Alice's IP phone subscribes to the status of Alice's messages. Via headers are omitted for clarity.
例の呼び出しでは、以下のアリスのメッセージの状態にアリスのIP電話が加入を流れ。ヘッダを経由して明確にするために省略されています。
Subscriber Notifier
| |
| A1: SUBSCRIBE (new) |
|---------------------->|
| A2: 200 OK |
|<----------------------|
| |
| A3: NOTIFY (sync) |
|<----------------------|
| A4: 200 OK |
|---------------------->|
| |
| |
| A5: NOTIFY (change) |
|<----------------------|
| A6: 200 OK |
|---------------------->|
| |
| |
| A7: (re)SUBSCRIBE |
|---------------------->|
| A8: 200 OK |
|<----------------------|
| |
| A9: NOTIFY (sync) |
|<----------------------|
| A10: 200 OK |
|---------------------->|
| |
| |
| A11: (un)SUBSCRIBE |
|---------------------->|
| A12: 200 OK |
|<----------------------|
| |
| A13: NOTIFY (sync) |
|<----------------------|
| A14: 200 OK |
|---------------------->|
A1: Subscriber (Alice's phone) -> Notifier (Alice's voicemail gateway) Subscribe to Alice's message summary status for 1 day.
A1：加入者（アリスの電話） - >通知（アリスのボイスメールゲートウェイ）は1日、アリスのメッセージサマリステータスを購読します。
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 To: <sip:alice@example.com> From: <sip:alice@example.com>;tag=78923 Date: Mon, 10 Jul 2000 03:55:06 GMT
alice@vmail.example.com SIP / 2.0：SIPをSUBSCRIBE <一口：alice@example.com>から<SIP：alice@example.com>;タグ= 78923日：月、2000年7月10日午前3時55分： 06 GMT
Call-Id: 1349882@alice-phone.example.com CSeq: 4 SUBSCRIBE Contact: <sip:alice@alice-phone.example.com> Event: message-summary Expires: 86400 Accept: application/simple-message-summary Content-Length: 0
コールID：1349882@alice-phone.example.comのCSeq：連絡先をSUBSCRIBE 4：<SIP：alice@alice-phone.example.com>イベント：メッセージの要約が有効期限：86400受け入れ：アプリケーション/シンプル・メッセージ・サマリコンテンツ-length：0
A2: Notifier -> Subscriber
A2：通知 - >購読者
SIP/2.0 200 OK To: <sip:alice@example.com>;tag=4442 From: <sip:alice@example.com>;tag=78923 Date: Mon, 10 Jul 2000 03:55:07 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 4 SUBSCRIBE Expires: 86400 Content-Length: 0
SIP / 2.0 200 OKに：<SIP：alice@example.com>;タグ= 4442から：<SIP：alice@example.com>;タグ= 78923日：月、2000年7月10日午前三時55分07秒GMT Call- ID：1349882@alice-phone.example.comのCSeq：4 SUBSCRIBE有効期限：86400のContent-Length：0
A3: Notifier -> Subscriber
(immediate synchronization of current state:
2 new and 8 old [2 urgent] messages)
NOTIFY sip:alice@alice-phone.example.com SIP/2.0 To: <sip:alice@example.com>;tag=78923 From: <sip:alice@example.com>;tag=4442 Date: Mon, 10 Jul 2000 03:55:07 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 20 NOTIFY Contact: <sip:alice@vmail.example.com> Event: message-summary Subscription-State: active Content-Type: application/simple-message-summary Content-Length: 99
タグ= 78923から、<alice@example.com SIP：>：<SIP：alice@example.com>;タグ= 4442日：月、10 alice@alice-phone.example.com SIP / 2.0：SIPのNOTIFY 2000年7月午前三時55分07秒GMTコールID：1349882@alice-phone.example.comのCSeq：20 NOTIFY連絡先：<SIP：alice@vmail.example.com>イベント：メッセージサマリーサブスクリプション・ステート：アクティブのContentタイプ：application /シンプル・メッセージ・サマリーのContent-Length：99
Messages-Waiting: yes Message-Account: sip:alice@vmail.example.com Voice-Message: 2/8 (0/2)
メッセージウェイティング：はいメッセージアカウント：SIP：alice@vmail.example.com音声メッセージ：2/8（0/2）
A4: Subscriber -> Notifier
A4：加入者 - >通知
SIP/2.0 200 OK To: <sip:alice@example.com>;tag=78923 From: <sip:alice@example.com>;tag=4442 Date: Mon, 10 Jul 2000 03:55:08 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 20 NOTIFY Content-Length: 0
SIP / 2.0 200 OKに：<SIP：alice@example.com>;タグ= 78923から：<SIP：alice@example.com>;タグ= 4442日：月、2000年7月10日3時55分08秒GMT Call- ID：1349882@alice-phone.example.comのCSeq：20は、コンテンツの長さをNOTIFY：0
A5: Notifier -> Subscriber
This is a notification of new messages.
Some headers from each of the new messages are appended.
NOTIFY sip:alice@alice-phone.example.com SIP/2.0 To: <sip:alice@example.com>;tag=78923 From: <sip:alice@example.com>;tag=4442 Date: Mon, 10 Jul 2000 04:28:53 GMT Contact: <sip:alice@vmail.example.com> Call-ID: 1349882@alice-phone.example.com CSeq: 31 NOTIFY Event: message-summary Subscription-State: active Content-Type: application/simple-message-summary Content-Length: 503
タグ= 78923から、<alice@example.com SIP：>：<SIP：alice@example.com>;タグ= 4442日：月、10 alice@alice-phone.example.com SIP / 2.0：SIPのNOTIFY 2000年7月4時28分53秒GMT連絡先：<SIP：alice@vmail.example.com>コールID：1349882@alice-phone.example.comのCSeq：31イベントをNOTIFY：メッセージ要約購読-状態：アクティブのContentタイプ：application /シンプル・メッセージ・サマリーのContent-Length：503
Messages-Waiting: yes Message-Account: sip:alice@vmail.example.com Voice-Message: 4/8 (1/2)
メッセージウェイティング：はいメッセージアカウント：SIP：alice@vmail.example.com音声メッセージ：4/8（1/2）
To: <alice@atlanta.example.com> From: <bob@biloxi.example.com> Subject: carpool tomorrow? Date: Sun, 09 Jul 2000 21:23:01 -0700 Priority: normal Message-ID: 13784434989@vmail.example.com
宛先：<alice@atlanta.example.com>から<bob@biloxi.example.com>件名：明日相乗り？日付：日、2000年7月9日夜九時23分01秒-0700優先度：通常のMessage-ID：13784434989@vmail.example.com
To: <alice@example.com> From: <cathy-the-bob@example.com> Subject: HELP! at home ill, present for me please Date: Sun, 09 Jul 2000 21:25:12 -0700 Priority: urgent Message-ID: 13684434990@vmail.example.com
宛先：<alice@example.com>から<cathy-the-bob@example.com>件名：HELP！自宅でください、病気は私のために本日付：日、2000年7月9日21時25分12秒-0700優先度：緊急メッセージID：13684434990@vmail.example.com
A6: Subscriber -> Notifier
A6：加入者 - >通知
SIP/2.0 200 OK To: <sip:alice@example.com>;tag=78923 From: <sip:alice@example.com>;tag=4442 Date: Mon, 10 Jul 2000 04:28:53 GMT Call-ID: 1349882@alice-phone.example.com CSeq: 31 NOTIFY Content-Length: 0
SIP / 2.0 200 OKに：<SIP：alice@example.com>;タグ= 78923から：<SIP：alice@example.com>;タグ= 4442日：月、2000年7月10日4時28分53秒GMT Call- ID：1349882@alice-phone.example.comのCSeq：31は、コンテンツの長さをNOTIFY：0
A7: Subscriber -> Notifier
Refresh subscription.
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 To: <sip:alice@example.com>;tag=4442 From: <sip:alice@example.com>;tag=78923 Date: Mon, 10 Jul 2000 15:55:06 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 8 SUBSCRIBE Contact: <sip:alice@alice-phone.example.com> Event: message-summary Expires: 86400 Accept: application/simple-message-summary Content-Length: 0
SUBSCRIBE SIP：alice@vmail.example.com SIP / 2.0に：<SIP：alice@example.com>;タグ= 4442から：<SIP：alice@example.com>;タグ= 78923日：月、2000年7月10日午後3時55分06秒GMTのコールID：1349882@alice-phone.example.comのCSeq：連絡先をSUBSCRIBE 8：<SIP：alice@alice-phone.example.com>イベント：メッセージ - 要約は有効期限：86400受け入れ：アプリケーション/シンプルなメッセージ - 要約のContent-Length：0
A8: Notifier -> Subscriber
A8：通知 - >購読者
SIP/2.0 200 OK To: <sip:alice@example.com>;tag=4442 From: <sip:alice@example.com>;tag=78923 Date: Mon, 10 Jul 2000 15:55:07 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 8 SUBSCRIBE Contact: <sip:alice@alice-phone.example.com> Expires: 86400 Content-Length: 0
SIP / 2.0 200 OKに：<SIP：alice@example.com>;タグ= 4442から：<SIP：alice@example.com>;タグ= 78923日：月、2000年7月10日午後三時55分07秒GMT Call- ID：1349882@alice-phone.example.comのCSeq：連絡先をSUBSCRIBE 8：<SIP：alice@alice-phone.example.com>は有効期限：86400のContent-Length：0
A9: Notifier -> Subscriber
(immediate synchronization of current state)
NOTIFY sip:alice@alice-phone.example.com SIP/2.0 To: <sip:alice@example.com>;tag=78923 From: <sip:alice@example.com>;tag=4442 Date: Mon, 10 Jul 2000 15:55:07 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 47 NOTIFY Contact: <sip:alice@vmail.example.com> Event: message-summary Subscription-State: active Content-Type: application/simple-message-summary Content-Length: 99
タグ= 78923から、<alice@example.com SIP：>：<SIP：alice@example.com>;タグ= 4442日：月、10 alice@alice-phone.example.com SIP / 2.0：SIPのNOTIFY 2000年7月午後03時55分07秒GMTコールID：1349882@alice-phone.example.comのCSeq：47 NOTIFY連絡先：<SIP：alice@vmail.example.com>イベント：メッセージサマリーサブスクリプション・ステート：アクティブのContentタイプ：application /シンプル・メッセージ・サマリーのContent-Length：99
Messages-Waiting: yes Message-Account: sip:alice@vmail.example.com Voice-Message: 4/8 (1/2)
メッセージウェイティング：はいメッセージアカウント：SIP：alice@vmail.example.com音声メッセージ：4/8（1/2）
A10: Subscriber -> Notifier
A10：加入者 - >通知
SIP/2.0 200 OK To: <sip:alice@example.com>;tag=78923 From: <sip:alice@example.com>;tag=4442
SIP / 2.0 200 OK <SIP：alice@example.com>;タグ= 78923から<SIP：alice@example.com>;タグ= 4442
Date: Mon, 10 Jul 2000 15:55:08 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 47 NOTIFY Contact: <sip:alice@vmail.example.com>
日付：月、2000年7月10日午後三時55分08秒GMTコールID：1349882@alice-phone.example.comのCSeq：47連絡先をNOTIFY：<SIP：alice@vmail.example.com>
A11: Subscriber -> Notifier
Un-subscribe after "alice" logs out.
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 To: <sip:alice@example.com>;tag=4442 From: <sip:alice@example.com>;tag=78923 Date: Mon, 10 Jul 2000 19:35:06 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 17 SUBSCRIBE Contact: <sip:alice@alice-phone.example.com> Event: message-summary Expires: 0 Accept: application/simple-message-summary Content-Length: 0
SUBSCRIBE SIP：alice@vmail.example.com SIP / 2.0に：<SIP：alice@example.com>;タグ= 4442から：<SIP：alice@example.com>;タグ= 78923日：月、2000年7月10日午前19時35分06秒GMTのコールID：1349882@alice-phone.example.comのCSeq：17連絡先をSUBSCRIBE：<SIP：alice@alice-phone.example.com>イベント：メッセージ - 要約は有効期限：0受け入れ：アプリケーション/シンプルなメッセージ - 要約のContent-Length：0
A12: Notifier -> Subscriber
A12：通知 - >購読者
SIP/2.0 200 OK To: <sip:alice@example.com>;tag=4442 From: <sip:alice@example.com>;tag=78923 Date: Mon, 10 Jul 2000 19:35:07 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 17 SUBSCRIBE Contact: <sip:alice@alice-phone.example.com> Expires: 0 Content-Length: 0
SIP / 2.0 200 OKに：<SIP：alice@example.com>;タグ= 4442から：<SIP：alice@example.com>;タグ= 78923日：月、2000年7月10日19時35分07秒GMT Call- ID：1349882@alice-phone.example.comのCSeq：17連絡先をSUBSCRIBE：<SIP：alice@alice-phone.example.com>有効期限：0のContent-Length：0
A13: Notifier -> Subscriber (immediate synchronization of current state, which the subscriber can now ignore)
A13：通知 - >加入者（加入者が現在無視することができ、現在の状態の即時同期）
NOTIFY sip:alice@alice-phone.example.com SIP/2.0 To: <sip:alice@example.com>;tag=78923 From: <sip:alice@example.com>;tag=4442 Date: Mon, 10 Jul 2000 19:35:07 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 56 NOTIFY Contact: <sip:alice@vmail.example.com> Event: message-summary Subscription-State: terminated;reason=timeout Content-Type: application/simple-message-summary Content-Length: 99
タグ= 78923から、<alice@example.com SIP：>：<SIP：alice@example.com>;タグ= 4442日：月、10 alice@alice-phone.example.com SIP / 2.0：SIPのNOTIFY 2000年7月夜07時35分07秒GMTコールID：1349882@alice-phone.example.comのCSeq：56 NOTIFY連絡先：<SIP：alice@vmail.example.com>イベント：メッセージサマリーサブスクリ - 状態：終了;理由=タイムアウトのContent-Type：アプリケーション/シンプル・メッセージ・サマリーのContent-Length：99
Messages-Waiting: yes Message-Account: sip:alice@vmail.example.com Voice-Message: 4/8 (1/2)
メッセージウェイティング：はいメッセージアカウント：SIP：alice@vmail.example.com音声メッセージ：4/8（1/2）
A14: Subscriber -> Notifier
A14：加入者 - >通知
SIP/2.0 200 OK To: <sip:alice@example.com>;tag=78923 From: <sip:alice@example.com>;tag=4442 Date: Mon, 10 Jul 2000 19:35:08 GMT Call-Id: 1349882@alice-phone.example.com CSeq: 56 NOTIFY Event: message-summary Content-Length: 0
SIP / 2.0 200 OKに：<SIP：alice@example.com>;タグ= 78923から：<SIP：alice@example.com>;タグ= 4442日：月、2000年7月10日19時35分08秒GMT Call- ID：1349882@alice-phone.example.comのCSeq：56イベントをNOTIFY：メッセージ要約のContent-Length：0
The use of callee capabilities is optional but encouraged. If callee capabilities are used, a messaging notifier MAY REGISTER a Contact with an appropriate methods and events tag as shown in the example below. To further distinguish itself, the messaging notifier MAY also REGISTER as a Contact with the actor="msg-taker" tag. An example of this kind of registration follows below.
呼び出し先機能の使用はオプションですが、奨励あります。呼び出し先の機能を使用する場合は、以下の例に示すように、メッセージング通知は、適切なメソッドやイベントタグと連絡先を登録することもできます。さらに自分自身を区別するために、メッセージングの通知も俳優=「MSG-係」タグと連絡先として登録することもできます。登録のこの種の例を以下に続きます。
REGISTER sip:sip3-sj.example.com SIP/2.0
To: <sip:alice@example.com>
From: <sip:alice@example.com>;tag=4442
...
Contact: <sip:alice@vm13-sj.example.com>
;actor="msg-taker";methods="SUBSCRIBE"
;automata;events="message-summary"
The following SUBSCRIBE message would find the Contact which registered in the example above.
次SUBSCRIBEメッセージは、上記の例では、登録連絡先を見つけるだろう。
SUBSCRIBE sip:alice@example.com SIP/2.0
...
Accept: application/simple-message-summary
Event: message-summary
Accept-Contact: *;automata;actor="msg-taker"
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 [6].
以下の構文仕様はRFC 2234に記載されているように拡張バッカスナウア記法（BNF）を使用する[6]。
This document defines a new event-package with the package name:
この文書では、パッケージ名で新しいイベントパッケージを定義します。
message-summary
メッセージの要約
The formal syntax for the application/simple-message-summary MIME type is described below. The message-context-class production is defined in Section 6.2 of RFC 3458 [7]. Note that all productions described here are case insensitive.
アプリケーション/簡易メッセージの要約MIMEタイプのための正式な構文は以下の通りです。メッセージコンテキストクラスの生産は、RFC 3458のセクション6.2で定義されている[7]。ここに記載されているすべての作品は大文字小文字を区別しないことに注意してください。
message-summary = msg-status-line CRLF [msg-account CRLF] [*(msg-summary-line CRLF)] [ *opt-msg-headers ]
メッセージ要約= MSG-ステータスラインCRLF [MSG-アカウントCRLF] [*（MSG-要約ラインCRLF）] [* OPT-MSG-ヘッダー]
msg-status-line = "Messages-Waiting" HCOLON msg-status msg-status = "yes" / "no" msg-account = "Message-Account" HCOLON Account-URI Account-URI = SIP-URI / SIPS-URI / absoluteURI
MSG-ステータスライン= "メッセージウェイティング" HCOLON MSG-ステータスMSG-状態= "はい" / "いいえ" MSG-アカウント= "メッセージ・アカウント" がHCOLONアカウント-URIアカウント-URI = SIP-URI / SIPS-URI / absoluteURIで
msg-summary-line = message-context-class HCOLON newmsgs SLASH oldmsgs [ LPAREN new-urgentmsgs SLASH old-urgentmsgs RPAREN ]
MSG-要約行は、メッセージ・コンテキスト・クラスHCOLONのnewmsgsがoldmsgsをSLASH = [LPAREN新しい-urgentmsgsはRPAREN古いurgentmsgsをSLASH]
opt-msg-headers = CRLF 1*(extension-header CRLF)
OPT-MSG-ヘッダー= CRLF 1 *（拡張ヘッダCRLF）
newmsgs = msgcount oldmsgs = msgcount new-urgentmsgs = msgcount old-urgentmsgs = msgcount msgcount = 1*DIGIT ; MUST NOT exceed 2^32-1
newmsgs = msgcount oldmsgs = msgcount新しい-urgentmsgs = msgcount古いurgentmsgs = msgcount msgcount = 1 * DIGIT。 2 ^ 32-1を超えてはなりません
Message summaries and optional message bodies contain information which is typically very privacy sensitive. At a minimum, subscriptions to this event package SHOULD be authenticated and properly authorized. Furthermore, notifications SHOULD be encrypted and integrity protected using either end-to-end mechanisms, or the hop-by-hop protection afforded messages sent to SIPS URIs.
メッセージ要約およびオプションのメッセージ本文は、一般的に非常にプライバシーの機密情報が含まれています。最低でも、このイベントパッケージへのサブスクリプションは、認証され、適切承認されるべきです。さらに、通知は暗号化と整合性は、エンドツーエンドのメカニズム、またはSIPS URIに送信されたホップバイホップ保護与えたメッセージのいずれかを使用して保護する必要があります。
Additional and privacy security considerations are discussed in detail in SIP [1] and SIP Events [2].
追加やプライバシー、セキュリティの考慮事項は、SIPで詳しく説明されている[1]、SIPイベント[2]。
Package name: message-summary
パッケージ名：メッセージ - 要約
Type: package
タイプ：パッケージ
Contact: [Mahy]
連絡先：[マーイ]
Published Specification: This document.
公開された仕様：このドキュメント。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: simple-message-summary
MIMEサブタイプ名：簡単なメッセージ - 要約
Required parameters: none.
必須パラメータ：なし。
Optional parameters: none.
オプションのパラメータ：なし。
Encoding considerations: This MIME type was designed for use with protocols which can carry binary-encoded data. Although the format of this MIME type is similar to RFC 2822, it is not identical. (Specifically, line folding rules are SIP-specific and included URIs can contain non-ASCII characters.) Protocols which do not carry binary data (which have line length or character-set restrictions for example) MUST use a reversible transfer encoding (such as base64) to carry this MIME type.
符号化の考慮事項：このMIMEタイプは、バイナリエンコードされたデータを運ぶことができるプロトコルで使用するために設計しました。このMIMEタイプのフォーマットは、RFC 2822に類似しているが、同一ではありません。 （具体的には、ライン折りたたみ規則はSIP固有であり、URIは、非ASCII文字を含むことができる含まれていた。）（例えば、線の長さや文字セットの制約を有する）は、バイナリデータを搬送しないプロトコルのような可逆転送エンコーディングを（使用しなければなりませんこのMIMEタイプを運ぶためにBASE64）。
Security considerations: See the "Security Considerations" section in this document.
セキュリティの考慮事項：このドキュメントの「セキュリティの考慮事項」を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: This document.
公開された仕様：このドキュメント。
Applications which use this media: The simple-message-summary application subtype supports the exchange of message waiting and message summary information in SIP networks.
シンプルなメッセージ - 要約アプリケーションのサブタイプは、SIPネットワークで待機しているメッセージとメッセージサマリ情報の交換をサポートしています。このメディアを使用するアプリケーション。
Additional information:
追加情報：
Ilya Slain came up with the initial format of the text body contained in this document. He was previously listed as a co-author, however, he is no longer reachable.
イリヤ殺害されたが、この文書に含まれるテキスト本文の初期フォーマットを思い付きました。彼は以前に共著者として記載されていた、しかし、彼はもはや到達可能ではありません。
Thanks to Dan Wing, Dave Oran, Bill Foster, Steve Levy, Denise Caballero-McCann, Jeff Michel, Priti Patil, Satyender Khatter, Bich Nguyen, Manoj Bhatia, David Williams, and Bryan Byerly of Cisco, Jonathan Rosenberg and Adam Roach of Dynamicsoft, Eric Burger of Snowshore, Nir Chen of Comverse, and Eric Tremblay of Mediatrix.
ダン・ウィング、デイブ・オラン、ビル・フォスター、スティーブ・レヴィ、デニス・キャバレロ・マッキャン、ジェフ・ミシェル、Pritiパティル、Satyender Khatter、ビックグエン、ManojさんBhatiaは、デビッド・ウィリアムズ、およびCisco、ジョナサン・ローゼンバーグとDynamicsoftのアダムローチのブライアンByerlyのおかげで、Snowshoreのエリック・バーガー、コンバースのニール・チェン、および仲介者のエリック・トレンブレイ。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[4]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivatを、RFC 3841 "セッション開始プロトコル（SIP）のための発呼側プリファレンス"、2004年8月。
[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[5]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivatを、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[6]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[7] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.
[7]バーガー、E.、Candell、E.、エリオット、C.、およびG. Klyne、 "インターネットメールのメッセージコンテキスト"、RFC 3458、2003年1月。
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[8]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[9] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[9]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[10] Rosenberg, J., Roach, A.B., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", Work in Progress, June 2003.
[10]ローゼンバーグ、J.、ローチ、A.B.、およびB.キャンベル、 "Aセッション開始プロトコル（SIP）リソースリストのイベント通知拡張"、進歩、2003年6月に働いています。
[11] Telcordia, "GR-506: Signaling for Analog Interfaces, Issue 1, Revision 1", Nov 1996.
[11]のTelcordia、 "GR-506：アナログ・インターフェイス、1号、リビジョン1のシグナリング"、1996年11月。
Rohan Mahy Cisco Systems, Inc. 5617 Scotts Valley Drive, Suite 200 Scotts Valley, CA 95066 USA
ロハンマーイシスコシステムズ株式会社5617スコッツバレードライブ、スイート200スコッツバレー、CA 95066 USA
EMail: rohan@cisco.com
メールアドレス：rohan@cisco.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。