RFC4235 日本語訳
4235 An INVITE-Initiated Dialog Event Package for the SessionInitiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, R. Mahy,Ed.. November 2005. (Format: TXT=83268 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Rosenberg
Request for Comments: 4235 Cisco Systems
Category: Standards Track H. Schulzrinne
Columbia University
R. Mahy, Ed.
SIP Edge LLC
November 2005
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 4235年のシスコシステムズカテゴリ: エド標準化過程H.Schulzrinneコロンビア大学のR.マーイ、一口縁のLLC2005年11月
An INVITE-Initiated Dialog Event Package for the
Session Initiation Protocol (SIP)
セッション開始プロトコルのための招待で開始している対話イベントパッケージ(一口)
Status of this Memo
この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 01) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD01)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE- initiated dialog usages in which the subscribed-to user is involved.
このドキュメントはSIP Eventsアーキテクチャのための対話イベントパッケージを定義します、このパッケージに通知で使用されるデータの形式と共に。 対話パッケージで、ユーザは、別のユーザに加入して、加入しているユーザがかかわるINVITEの開始している対話用法の状態に変化の通知を受け取ります。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Dialog Event Package ............................................4
3.1. Event Package Name .........................................4
3.2. Event Package Parameters ...................................4
3.3. SUBSCRIBE Bodies ...........................................5
3.4. Subscription Duration ......................................6
3.5. NOTIFY Bodies ..............................................6
3.6. Notifier Processing of SUBSCRIBE Requests ..................7
3.7. Notifier Generation of NOTIFY Requests .....................8
3.7.1. The Dialog State Machine ............................8
3.7.2. Applying the State Machine .........................11
1. 序論…3 2. 用語…4 3. 対話イベントパッケージ…4 3.1. イベントパッケージ名…4 3.2. イベントパッケージパラメタ…4 3.3. ボディーを申し込んでください…5 3.4. 購読持続時間…6 3.5. ボディーに通知してください…6 3.6. より多くのNotifierに処理する、要求を申し込んでください…7 3.7. Notifier世代、要求に通知してください…8 3.7.1. 対話州のマシン…8 3.7.2. 州のマシンを適用します…11
Rosenberg, et al. Standards Track [Page 1] RFC 4235 Dialog Package November 2005
ローゼンバーグ、他 規格は対話パッケージ2005年11月にRFC4235を追跡します[1ページ]。
3.8. Subscriber Processing of NOTIFY Requests ..................12
3.9. Handling of Forked Requests ...............................12
3.10. Rate of Notifications ....................................13
3.11. State Agents .............................................13
4. Dialog Information Format ......................................13
4.1. Structure of Dialog Information ...........................13
4.1.1. Dialog Element .....................................14
4.1.2. State Element ......................................15
4.1.3. Duration Element ...................................15
4.1.4. Replaces Element ...................................15
4.1.5. Referred-By Element ................................16
4.1.6. Local and Remote Elements ..........................16
4.2. Sample Notification Body ..................................17
4.3. Constructing Coherent State ...............................18
4.4. Schema ....................................................19
5. Definition of New Media Feature Parameters .....................22
5.1. The "sip.byeless" Parameter ...............................22
5.2. The "sip.rendering" parameter .............................23
6. Examples .......................................................24
6.1. Basic Example .............................................24
6.2. Emulating a Shared-Line Phone System ......................26
6.3. Minimal Dialog Information with Privacy ...................31
7. Security Considerations ........................................32
8. IANA Considerations ............................................32
8.1. application/dialog-info+xml MIME Registration .............33
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info ........................34
8.3. Schema Registration .......................................34
8.4. Media Feature Parameter Registration ......................34
8.4.1. sip.byeless ........................................35
8.4.2. sip.rendering ......................................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
3.8. 加入者、処理する、要求に通知してください…12 3.9. 股状の要求の取り扱い…12 3.10. 通知の速度…13 3.11. エージェントを述べてください…13 4. 対話情報形式…13 4.1. 対話情報の構造…13 4.1.1. 対話要素…14 4.1.2. 要素を述べてください…15 4.1.3. 持続時間要素…15 4.1.4. 要素を置き換えます…15 4.1.5. 参照された要素…16 4.1.6. 地方の、そして、リモートなElements…16 4.2. 通知本体を抽出してください…17 4.3. コヒーレント状態を構成します…18 4.4. 図式…19 5. ニューメディアの定義はパラメタを特徴とします…22 5.1. "sip.byeless"パラメタ…22 5.2. "sip.rendering"パラメタ…23 6. 例…24 6.1. 基本の例…24 6.2. 共有された線を見習って、システムに電話をしてください…26 6.3. プライバシーがある最小量の対話情報…31 7. セキュリティ問題…32 8. IANA問題…32 8.1アプリケーション/対話インフォメーション+xml MIME Registration…33 8.2. つぼ:ietf:params:xml:ナノ秒間のURN Sub-名前空間Registration: 対話インフォメーション…34 8.3. 図式登録…34 8.4. メディアはパラメタ登録を特徴とします…34 8.4.1sip.byeless…35 8.4.2一口レンダリング…35 9. 承認…36 10. 参照…36 10.1. 標準の参照…36 10.2. 有益な参照…37
Rosenberg, et al. Standards Track [Page 2] RFC 4235 Dialog Package November 2005
ローゼンバーグ、他 規格は対話パッケージ2005年11月にRFC4235を追跡します[2ページ]。
1. Introduction
1. 序論
The SIP Events framework [1] defines general mechanisms for subscription to, and notification of, events within SIP networks. It introduces the notion of a package, which is a specific "instantiation" of the events mechanism for a well-defined set of events. Packages have been defined for user presence [16], watcher information [17], and message waiting indicators [18], amongst others. This document defines an event package for INVITE-initiated dialog usages. Dialogs refer to the SIP relationship established between two SIP peers [2]. Dialogs can be created by many methods, although RFC 3261 defines only one: the INVITE method. RFC 3265 [1] defines the SUBSCRIBE and NOTIFY methods, which also create new dialog usages. However, using this package to model state for non- session dialog usages is out of the scope of this specification.
[1]が購読のための一般的機構を定義するSIP Eventsフレームワーク、および通知、SIPネットワークの中のイベント。 それはパッケージの概念を紹介します。(パッケージは明確なセットのイベントのためのイベントメカニズムの特定の「具体化」です)。 パッケージはユーザ存在[16]、ウォッチャー情報[17]、および通話待ち指示器[18]のために他のもので定義されました。 このドキュメントはINVITEによって開始された対話用法のためのイベントパッケージを定義します。 対話は2人のSIP同輩[2]の間で確立されたSIP関係について言及します。 RFC3261は1つだけを定義しますが、多くのメソッドで対話を作成できます: INVITEメソッド。 RFC3265[1]が定義する、登録、そして、NOTIFYメソッド。(また、そのメソッドは新しい対話用法を作成します)。 しかしながら、この仕様の範囲の外に非セッションの対話用法のために状態をモデル化するのにこのパッケージを使用するのがあります。
A variety of applications are enabled through knowledge of INVITE dialog usage state. Some examples include:
さまざまなアプリケーションがINVITE対話用法状態に関する知識を通して可能にされます。 いくつかの例は:
Automatic Callback: In this basic Public Switched Telephone
Network (PSTN) application, user A calls user B but User B is
busy. User A would like to get a callback when user B hangs
up. When B hangs up, user A's phone rings. When A picks up,
they hear ringing, while they are being connected to B. To
implement this with SIP, a mechanism is required for A to
receive a notification when the dialogs at B are complete.
自動コールバック: この基本的なPublic Switched Telephone Network(PSTN)アプリケーションでは、ユーザAは、ユーザBに電話をしますが、User Bは忙しいです。 ユーザBがハングアップするとき、ユーザAはコールバックを得たがっています。 Bがハングアップすると、ユーザAの電話は鳴ります。 Aが回復すると、彼らは、それらがToがSIPと共にこれを実装するB.に接続されている間、鳴って、Bでの対話が完全であるときに、Aが通知を受け取るのにメカニズムが必要であると聞きます。
Presence-Enabled Conferencing: In this application, user A wishes
to set up a conference call with users B and C. Rather than
being scheduled, the call is created automatically when A, B
and C are all available. To do this, the server providing the
application would like to know whether A, B, and C are
"online", not idle, and not in a phone call. Determining
whether or not A, B, and C are in calls can be done in two
ways. In the first, the server acts as a call-stateful proxy
for users A, B, and C, and therefore knows their call state.
This won't always be possible, however, and it introduces
scalability, reliability, and operational complexities. In the
second way, the server subscribes to the dialog state of those
users and receives notifications as this state changes. This
enables the application to be provided in a distributed way;
the server need not reside in the same domain as the users.
会議を存在して可能にします: このアプリケーション、ユーザBと共に電話会議をセットアップするというユーザA願望、およびC.ラザーでは、A、B、およびCがすべて利用可能であるときに、呼び出しは予定されているより自動的に作成されます。 利用を提供するサーバは、これをするために、A、B、およびCが活動していないのではなく「オンラインであるかどうか」を知って、どんな電話でもそうしたくはありません。 A、B、およびCが呼び出し中であるかどうか2つの方法で決定できます。 1番目では、サーバは、ユーザA、B、およびCのための呼び出し-statefulプロキシとして務めて、したがって、彼らの呼び出し状態を知っています。 しかしながら、これはいつも可能になるというわけではないでしょう、そして、それはスケーラビリティ、信頼性、および操作上の複雑さを導入します。 2番目の方法で、サーバは、それらのユーザの対話状態に加入して、この状態が変化するとき、通知を受け取ります。 これは、利用が分配された方法で提供されるのを可能にします。 サーバはユーザと同じドメインにある必要はありません。
IM Conference Alerts: In this application, a user can receive an
Instant Message (IM) on their phone whenever someone joins a
conference that the phone is involved in. The IM alerts are
generated by an application separate from the conference
server.
不-コンファレンス警戒: このアプリケーションでは、だれかが電話がかかわる会議に参加するときはいつも、ユーザはそれらの電話でInstant Message(IM)を受け取ることができます。 IM警戒は会議サーバから別々のアプリケーションで生成されます。
Rosenberg, et al. Standards Track [Page 3] RFC 4235 Dialog Package November 2005
ローゼンバーグ、他 規格は対話パッケージ2005年11月にRFC4235を追跡します[3ページ]。
In general, the dialog package allows for construction of distributed applications, where the application requires information on dialog state but is not co-resident with the end user on which that state resides.
一般に、対話パッケージは、アプリケーションが対話状態の情報を必要とする分配されたアプリケーションの工事を考慮しますが、その状態があるエンドユーザでのコレジデントではありません。
This document also defines two new callee capability [10] feature parameters:
また、このドキュメントは2つの新しい訪問される人能力[10]特徴パラメタを定義します:
o "sip.byeless", which indicates that a SIP user agent (UA) is not
capable of terminating a session itself (for example, in some
announcement or recording services, or in some call centers) in
which the UA is no longer interested in participating; and
o "sip.byeless"、どれがSIPユーザエージェント(UA)がUAがもう参加したがっていないセッション(例えば何らかの発表かサービスを記録するか、またはいくつかのコールセンターで)自体を終えることができないのを示すか。 そして
o "sip.rendering", which positively describes whether the user
agent is rendering any of the media it is receiving. These
feature parameters are useful in many of the same applications
that motivated the dialog package, such as conferencing,
presence, and the shared-line example described in Section 6.2.
o ユーザエージェントがそれが受け取っているメディアのどれかをレンダリングしているかどうか明確に説明する"sip.rendering"。 これらの特徴パラメタは対話パッケージを動機づけた同じアプリケーションの多くで役に立ちます、会議や、存在や、セクション6.2で説明された共有された系列の例などのように。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[9]について説明して、対応する実装のために要件レベルを示すとき解釈されることであるべきですか?
3. Dialog Event Package
3. 対話イベントパッケージ
This section provides the details for defining a SIP Events package, as specified in [1].
このセクションは[1]で指定されるようにSIP Eventsパッケージを定義するための詳細を明らかにします。
3.1. Event Package Name
3.1. イベントパッケージ名
The name of this event package is "dialog". This package name is carried in the Event and Allow-Events header fields, as defined in [1].
このイベントパッケージの名前は「対話」です。 このパッケージ名は[1]で定義されるようにEventとAllow-イベントヘッダーフィールドで運ばれます。
3.2. Event Package Parameters
3.2. イベントパッケージパラメタ
This package defines four Event Package parameters: call-id, to-tag, from-tag, and include-session-description. If a subscription to a specific dialog is requested, the first three of these parameters MUST be present, to identify the dialog that is being subscribed to. The to-tag is matched against the local tag, the from-tag is matched against the remote tag, and the call-id is matched against the Call-ID. The include-session-description parameter indicates whether the subscriber would like to receive the session descriptions associated with the subscribed dialog usage or usages.
このパッケージは4つのEventパッケージパラメタを定義します: タグにタグの、そして、セッション記述を含めている呼び出しイド。 特定の対話の購読が要求されるなら、これらの3つの最初のパラメタが、加入されている対話を特定するために存在していなければなりません。 タグは地方のタグに取り組まされます、そして、タグはリモートタグに取り組まされます、そして、呼び出しイドはCall-IDに取り組まされます。 セッション記述を含んでいるパラメタは、加入者が申し込まれた対話用法か用法に関連しているセッション記述を受けたがっているかどうかを示します。
Rosenberg, et al. Standards Track [Page 4] RFC 4235 Dialog Package November 2005
ローゼンバーグ、他 規格は対話パッケージ2005年11月にRFC4235を追跡します[4ページ]。
It is also possible to subscribe to the set of dialogs created as a result of a single INVITE sent by a UAC (user agent client). In that case, the call-id and to-tag MUST be present. The to-tag is matched against the local tag and the call-id is matched against the Call-ID.
また、UAC(ユーザエージェントのクライアント)によって送られた独身のINVITEの結果、作成された対話のセットに加入するのも可能です。 その場合、呼び出しイドとタグは存在していなければなりません。 タグは地方のタグに取り組まされます、そして、呼び出しイドはCall-IDに取り組まされます。
The ABNF for these parameters is shown below. It refers to many constructions from the ABNF of RFC3261, such as EQUAL, DQUOTE, and token.
これらのパラメタのためのABNFは以下で見せられます。 それはEQUALや、DQUOTEや、トークンなどのRFC3261のABNFから多くの構造について言及します。
call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE )
;; NOTE: any DQUOTEs inside callid MUST be escaped!
from-tag = "from-tag" EQUAL token
to-tag = "to-tag" EQUAL token
with-sessd = "include-session-description"
呼び出しイドは「呼び出しイド」EQUALと等しいです(トークン/DQUOTE callid DQUOTE)。 以下に注意してください。 callidの中のどんなDQUOTEsからも逃げなければなりません!タグからの「タグ」からのタグへの=EQUALトークン=「タグ」EQUALトークンはsessdで「セッション記述を含めてください」と等しいです。
If any call-ids contain embedded double-quotes, those double-quotes MUST be escaped using the backslash-quoting mechanism. Note that the call-id parameter may need to be expressed as a quoted string. This is because the ABNF for the callid production and the word production, which is used by callid (both from RFC 3261 [1]), allow some characters (such as "@", "[", and ":") that are not allowed within a token.
何か呼び出しイドが埋め込まれた二重引用符を含んでいるなら、バックスラッシュを引用するメカニズムを使用して、それらの二重引用符から逃げなければなりません。 呼び出しイドパラメタが、引用文字列として言い表される必要であるかもしれないことに注意してください。 これがそうである、callidによって使用されるcallid生産と単語生産のためのABNF、(ともにRFC3261[1])から何人かのキャラクタを許容してください、("@"などのように「[「」、:、」、)、それはトークンの中に許容されていません。
3.3. SUBSCRIBE Bodies
3.3. ボディーを申し込んでください。
A SUBSCRIBE request for a dialog package MAY contain a body. This body defines a filter to be applied to the subscription. Filter documents are not specified in this document, and at the time of writing, they are expected to be the subject of future standardization activity.
登録は、対話のためにパッケージがボディーを含むかもしれないよう要求します。 このボディーは、購読に適用されるためにフィルタを定義します。 フィルタドキュメントは本書では指定されません、そして、これを書いている時点で、それらは今後の標準化活動の対象であると予想されます。
A SUBSCRIBE request for a dialog package MAY be sent without a body. This implies the default subscription filtering policy. The default policy is:
登録は、対話のためにパッケージがボディーなしで送られるかもしれないよう要求します。 これはデフォルト購読フィルタリング方針を含意します。 デフォルト方針は以下の通りです。
o If the Event header field contained dialog identifiers, a
notification is generated every time there is a change in the
state of any matching dialogs for the user identified in the
request URI of the SUBSCRIBE.
o ヘッダーフィールドが対話識別子、中のユーザのためのどんなマッチング対話の州も要求URIで特定した変化があるときはいつも、生成された通知を含んだEventである、登録。
o If there were no dialog identifiers in the Event header field, a
notification is generated every time there is any change in the
state of any dialogs for the user identified in the request URI of
the SUBSCRIBE with the following exceptions. If the target
(Contact) URI of a subscriber is equivalent to the remote target
URI of a specific dialog, then the dialog element for that dialog
is suppressed for that subscriber. (The subscriber is already a
party in the dialog directly, so these notifications are
o Eventヘッダーフィールドに対話識別子が全くなかったなら、いくらかの変化が要求URIで特定されたユーザのためのどんな対話の状態にもあるときはいつも、通知が発生している、以下の例外で登録。 加入者の目標(接触)URIが特定の対話のリモート目標URIに同等であるなら、その対話のための対話要素はその加入者のために抑圧されます。 (加入者が対話で既に直接パーティーであるので、これらの通知があります。
Rosenberg, et al. Standards Track [Page 5] RFC 4235 Dialog Package November 2005
ローゼンバーグ、他 規格は対話パッケージ2005年11月にRFC4235を追跡します[5ページ]。
superfluous.) If no dialogs remain after suppressing dialogs, the
entire notification to that subscriber is suppressed and the
version number in the dialog-info element is not incremented for
that subscriber. Implicit filtering for one subscriber does not
affect notifications to other subscribers.
余計です。) 対話を抑圧した後に対話が全く残っていないなら、その加入者への全体の通知は抑圧されます、そして、対話インフォメーション要素のバージョン番号はその加入者のために増加されません。 1人の加入者にとっての暗黙のフィルタリングは他の加入者に通知に影響しません。
o Notifications do not normally contain full state; rather, they
only indicate the state of the dialog(s) whose state has changed.
The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a
NOTIFY that contains no dialog elements. These NOTIFYs contain
the complete view of dialog state.
o 通常、通知は完全な状態を含んでいません。 むしろ、彼らは状態が変化した対話の状態を示すだけです。 例外は、登録に対応して送られたNOTIFYと、対話要素を全く含まないNOTIFYです。 これらのNOTIFYsは対話状態の完全な視点を含んでいます。
o The notifications contain the identities of the participants in
the dialog, the target URIs, and the dialog identifiers. Session
descriptions are not included unless explicitly requested and
explicitly authorized.
o 通知は対話、目標URI、および対話識別子の関係者のアイデンティティを含んでいます。 セッション記述は、明らかに要求されない場合含まれていて、明らかに認可されません。
3.4. Subscription Duration
3.4. 購読持続時間
Dialog state changes fairly quickly. Once established, a typical phone call lasts a few minutes (this is different for other session types, of course). However, the interval between new calls is typically long. Clients SHOULD specify an explicit duration.
対話状態はかなり急速に変化します。 いったん設立されると、典型的な電話は数分続きます(他のセッションタイプにおいて、これが異なっている、もちろん)。 しかしながら、新しい呼び出しの間隔は通常長いです。 クライアントSHOULDは明白な持続時間を指定します。
There are two distinct use cases for dialog state. The first is when a subscriber is interested in the state of a specific dialog or dialogs (and they are authorized to find out just the state of those dialogs). In that case, when the dialogs terminate, so too does the subscription. In these cases, the value of the subscription duration is largely irrelevant; it SHOULD be longer than the typical duration of a dialog. We recommend a default duration of two hours, which is likely to cover most dialogs.
対話のためのケースが述べる2の異なった使用があります。 1番目は加入者が特定の対話か対話の状態に興味を持っている(彼らがまさしくそれらの対話の状態を見つけるのが認可されます)時です。 その場合、対話が終わると、そうも購読します。 これらの場合では、購読持続時間の値は主に無関係です。 それ、SHOULD、対話の典型的な持続時間より長くいてください。 私たちは2時間のデフォルト持続時間を推薦します。(時間はほとんどの対話をカバーしそうです)。
In another case, a subscriber is interested in the state of all dialogs for a specific user. In these cases, a shorter interval makes more sense. The default is one hour for these subscriptions.
別の場合では、加入者は特定のユーザのためのすべての対話の状態に興味を持っています。 これらの場合では、より短い間隔は、より多く理解できます。 デフォルトはこれらの購読のための1時間です。
3.5. NOTIFY Bodies
3.5. ボディーに通知してください。
As described in RFC 3265 [1], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE, or in a package-specific default format if the Accept header field was omitted from the SUBSCRIBE.
RFC3265[1]で説明されるように、NOTIFYメッセージは申し込まれたリソースの状態について説明するボディーを含むでしょう。 このボディーが形式がAcceptヘッダーフィールドで記載したコネである、登録、コネがデフォルトがヘッダーフィールドが省略されたAcceptであるならフォーマットするパッケージ詳細をそうする、登録。
In this event package, the body of the notification contains a dialog information document. This document describes the state of one or more dialogs associated with the subscribed resource. All
このイベントパッケージでは、通知のボディーは対話情報ドキュメントを含みます。 このドキュメントは申し込まれたリソースに関連している1つ以上の対話の状態について説明します。 すべて
Rosenberg, et al. Standards Track [Page 6] RFC 4235 Dialog Package November 2005
ローゼンバーグ、他 規格は対話パッケージ2005年11月にRFC4235を追跡します[6ページ]。
subscribers and notifiers MUST support the "application/ dialog-info+xml" data format described in Section 4. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/dialog-info+xml". If the header field is present, it MUST include "application/ dialog-info+xml", and it MAY include any other types capable of representing dialog state.
加入者とnotifiersはセクション4で説明された「+ アプリケーション/対話インフォメーションxml」データの形式を支持しなければなりません。 5月がAcceptヘッダーフィールドを含んでいるという要求を申し込んでください。 そのような何かヘッダーフィールドが存在していないなら、それには、「+ アプリケーション/対話インフォメーションxml」のデフォルト値があります。 ヘッダーフィールドが存在しているなら、「+ アプリケーション/対話インフォメーションxml」を含まなければなりません、そして、対話状態を表すことができるいかなる他のタイプも含むかもしれません。
Of course, the notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request.
もちろん、中でAcceptヘッダーフィールドで指定された形式の1つにはサーバで発生する通知があるに違いない、登録、要求。
3.6. Notifier Processing of SUBSCRIBE Requests
3.6. より多くのNotifierに処理する、要求を申し込んでください。
The dialog information for a user contains sensitive information. Therefore, all subscriptions SHOULD be authenticated and then authorized before approval. All implementors of this package MUST support the digest authentication mechanism as a baseline. The authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made.
ユーザへの対話情報は機密情報を含んでいます。 したがって、認証されて、次に承認の前に認可されたすべての購読SHOULD。 このパッケージのすべての作成者が基線としてダイジェスト認証機構をサポートしなければなりません。 管理者の裁量には認可方針がいつものようにあります。 しかしながら、いくつかの推薦状をすることができます。
It is RECOMMENDED that, if the policy of user B is that user A is allowed to call them, dialog subscriptions from user A be allowed. However, the information provided in the notifications does not contain any dialog identification information, merely an indication of whether the user is in at least one call. Specifically, they should not be able to find out any more information than if they sent an INVITE. (This concept of a "virtual" dialog is discussed more in Section 3.7.2, and an example of such a notification body is shown below).
ユーザAからの対話購読がユーザBの方針がユーザAが、それらと呼ぶことができるということであるなら許されているのは、RECOMMENDEDです。 しかしながら、通知に提供された情報は少しの対話識別情報(単にユーザが少なくとも1つの呼び出し中であるかしるし)も含んでいません。 明確に、彼らがそれ以上の情報を見つけることができないべきである、彼らがINVITEを送ったなら。 (さらにセクション3.7.2で「仮想」の対話のこの概念について議論します、そして、そのような通知本体に関する例は以下に示されます。)
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>confirmed</state>
</dialog>
</dialog-info>
<?xmlバージョン= 「1インチ?」「><対話インフォメーションxmlnsはバージョン=「0インチの状態=」という「つぼ:ietf:params:xml:ナノ秒: 対話インフォメーション」といっぱいに等しく」実体が「一口: alice@example.com 」と等しい、gt;、<対話イド=「as7d900as8"><州の>は</州の></対話></対話-インフォメーション>を確認しました」。
A user agent that registers with the address-of-record X SHOULD authorize subscriptions that come from any entity that can authenticate itself as X. Complete information on the dialog state SHOULD be sent in this case. This authorization behavior allows a group of devices representing a single user to become aware of each other's state. This is useful for applications such as single-line-extension, also known as shared lines.
記録されている住所X SHOULDとともに記名するユーザエージェントは対話のX.Complete情報が、SHOULDがこの場合送られると述べるときそれ自体を認証できるどんな実体からも来る購読を認可します。 この認可の振舞いによって、シングルユーザーの代理をする装置のグループは互いの状態を知るようになります。 これも、ただ一つの製品ライン拡大などの応用の役に立って、また、共有された線として知られています。
Rosenberg, et al. Standards Track [Page 7] RFC 4235 Dialog Package November 2005
ローゼンバーグ、他 規格は対話パッケージ2005年11月にRFC4235を追跡します[7ページ]。
Note that many implementations of "shared-lines" have a feature
that allows details of calls on a shared address-of-record to be
made private. This is a completely reasonable authorization
policy that could result in notifications that contain only the id
attribute of the dialog element and the state element when
shared-line privacy is requested, and notifications with more
complete information when shared-line privacy is not requested.
「共有された線」の多くの実現には共有された記録されている住所における呼び出しの詳細が個人的にする特徴があることに注意してください。 これは共有された線プライバシーがいつ要求されないかというより完全な情報で共有された線プライバシーが要求されているとき対話要素と州の要素のイド属性だけを含む通知、および通知をもたらすことができた完全に合理的な認可方針です。
3.7. Notifier Generation of NOTIFY Requests
3.7. Notifier世代、要求に通知してください。
Notifications are generated for the dialog package when an INVITE request is sent, when a new dialog comes into existence at a UA, or when the state or characteristics of an existing dialog changes. Therefore, a model of dialog state is needed in order to determine precisely when to send notifications, and what their content should be. The SIP specification has a reasonably well defined lifecycle for dialogs. However, it is not explicitly modelled. This specification provides an explicit model of dialog state through a finite state machine.
INVITE要求を送るとき、対話パッケージのために通知を発生させます、新しい対話がUAで生まれるか、または既存の対話の状態か特性が変化すると。 したがって、対話州のモデルが、正確にいつ通告を送るか、そして、それらの内容が何であるべきであるかを決定するのに必要です。 SIP仕様には、対話のための合理的によく定義されたlifecycleがあります。 しかしながら、それは明らかにモデル化されません。 この仕様は有限状態機械を通して対話州の明白なモデルを提供します。
It is RECOMMENDED that NOTIFY requests only contain information on the dialogs whose state or participation information has changed. However, if a notifier receives a SUBSCRIBE request, the triggered NOTIFY SHOULD contain the state of all dialogs that the subscriber is authorized to see.
NOTIFY要求が情報が状態か参加を変えた対話の情報を含むだけであるのは、RECOMMENDEDです。 しかしながら、notifierが受信されるなら、登録、要求、引き起こされたNOTIFY SHOULDは加入者が見るのを権限を与えられるすべての対話の状態を含んでいます。
3.7.1. The Dialog State Machine
3.7.1. 対話州のマシン
Modelling of dialog state is complicated by two factors. The first is forking, which can cause a single INVITE to generate many dialogs at a UAC. The second is the differing views of state at the UAC (user agent client) and UAS (usage agent server). We have chosen to handle the first issue by extending the dialog finite state machine (FSM) to include the states between transmission of the INVITE and the creation of actual dialogs through receipt of 1xx and 2xx responses. As a result, this specification supports the notion of dialog state for dialogs before they are fully instantiated.
対話状態のモデル化は2つの要素によって複雑にされます。 1(独身のINVITEにUACでの多くの対話を発生させることができる)番目は分岐しています。 2番目はUAC(ユーザエージェントのクライアント)とUAS(用法エージェントサーバ)の状態の異なる見解です。 私たちは、1xxと2xx応答の領収書によるINVITEのトランスミッションと実際の対話の創造の間の州を含むように、対話有限状態機械(FSM)を広げることによって創刊号を扱うのを選びました。 その結果、それらが完全に例示される前にこの仕様は対話のために対話状態の概念を支持します。
We have also chosen to use a single FSM for both UAC and UAS.
また、私たちは、UACとUASの両方に独身のFSMを使用するのを選びました。
Rosenberg, et al. Standards Track [Page 8] RFC 4235 Dialog Package November 2005
ローゼンバーグ、他 規格は対話パッケージ2005年11月にRFC4235を追跡します[8ページ]。
+----------+ +----------+
| | 1xx-notag | |
| |----------->| |
| Trying | |Proceeding|-----+
| |---+ +-----| | |
| | | | | | |
+----------+ | | +----------+ |
| | | | | |
| | | | | |
+<--C-----C--+ |1xx-tag |
| | | | |
cancelled| | | V |
rejected| | |1xx-tag +----------+ |
| | +------->| | |2xx
| | | | |
+<--C--------------| Early |-----C---+ 1xx-tag
| | replaced | | | | w/new tag
| | | |<----C---+ (new FSM
| | +----------+ | instance
| | 2xx | | created)
| +----------------+ | |
| | |2xx |
| | | |
V V V |
+----------+ +----------+ |
| | | | |
| | | | |
|Terminated|<-----------| Confirmed|<----+
| | error | |
| | timeout | |
+----------+ replaced +----------+
local-bye | ^
remote-bye | |
| |
+------+
2xx w. new tag
(new FSM instance
created)
+----------+ +----------+ | | 1xx-notag| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、| 試みます。| |進行|-----+ | |---+ +-----| | | | | | | | | | +----------+ | | +----------+ | | | | | | | | | | | | | +<--C-----C--+|1xx-タグ| | | | | | 取り消されます。| | | V| 拒絶されます。| | |1xx-タグ+----------+ | | | +------->|、| |2xx| | | | | +<--C--------------| 早い|-----C---+ 1xx-タグ| | 取り替えます。| | | | 新しいタグで| | | | <、-、-、--C---+、(新しいFSM| | +、-、-、-、-、-、-、-、-、--+| 例| | 2xx|、|、作成、)| +----------------+ | | | | |2xx| | | | | V V V| +----------+ +----------+ | | | | | | | | | | | |終わります。| <、-、-、-、-、-、-、-、-、-、--、| 確認されます。| <、-、-、--+ | | 誤り| | | | タイムアウト| | +----------+は+を取り替えました。----------+ 地方の不戦勝| ^リモート不戦勝| | | | +------+ 2xxのw.の新しいタグ(作成された新しいFSM例)
Figure 3
図3
The FSM for dialog state is shown in Figure 3. The FSM is best understood by considering the UAC and UAS cases separately.
対話状態へのFSMは図3で見せられます。 UACとUASがケースであると考えることによって、FSMは別々に特に理解されています。
Rosenberg, et al. Standards Track [Page 9] RFC 4235 Dialog Package November 2005
ローゼンバーグ、他 規格は対話パッケージ2005年11月にRFC4235を追跡します[9ページ]。
The FSM is created in the Trying state when the UAC sends an INVITE request. Upon receipt of a 1xx without a tag, the FSM transitions to the Proceeding state. Note that there is no actual dialog yet, as defined by the SIP specification. However, there is a "half-dialog", in the sense that two of the three components of the dialog ID (the call identifier and local tag) are known. If a 1xx with a tag is received, the FSM transitions to the Early state. The full dialog identifier is now defined. Had a 2xx been received, the FSM would have transitioned to the Confirmed state.
UACがINVITE要求を送るとき、FSMはTrying状態で作成されます。 タグのない1xxを受け取り次第、FSMはProceeding状態に移行します。 SIP仕様で定義されるようにしかし、どんな実際の対話もないことに注意してください。 しかしながら、「半分対話」があって、意味で、対話ID(呼び出し識別子と地方のタグ)の3つの成分のうちその2は知られています。 タグがある1xxが受け取られているなら、FSMはEarly状態に移行します。 完全な対話識別子は現在、定義されます。 2xxを受け取ったなら、FSMはConfirmed状態に移行したでしょうに。
If, after transitioning to the Early or Confirmed states, the UAC receives another 1xx or 2xx respectively with a different tag, another instance of the FSM is created, initialized into the Early or Confirmed state, respectively. The benefit of this approach is that there will be a single FSM representing the entire state of the invitation and resulting dialog when dealing in the common case of no forking.
UACがEarlyかConfirmed州に移行した後に異なったタグでそれぞれ別の1xxか2xxを受けるなら、EarlyかConfirmed状態に初期化されて、FSMの別の例はそれぞれ作成されます。 このアプローチの恩恵は分岐でないののよくある例を扱うとき招待と結果として起こる対話の全体の州を代表する独身のFSMがあるということです。
If the UAC sends a CANCEL and then subsequently receives a 487 to its INVITE transaction, all FSMs spawned from that INVITE transition to the Terminated state with the event "cancelled". If the UAC receives a new invitation (with a Replaces [13] header) that replaces the current Early or Confirmed dialog, all INVITE transactions spawned from the replaced invitation transition to the Terminated state with the event "replaced". If the INVITE transaction terminates with a non-2xx response for any other reason, all FSMs spawned from that INVITE transition to the Terminated state with the event "rejected".
UACがキャンセルを送って、次に、次にINVITE取引に487を受け取るなら、出来事が「取り消されている」状態で、すべてのFSMsがTerminated状態へのそのINVITE変遷から量産しました。 UACが現在のEarlyかConfirmed対話に取って代わる新しい招待状(Replaces[13]ヘッダーがある)を受けるなら、出来事が「取り替えられている」状態で、すべてのINVITE取引がTerminated状態への取り替えられた招待変遷から量産されました。 INVITE取引がいかなる他の理由のための非2xx応答でも終わるなら、すべてのFSMsが出来事が「拒絶されている」Terminated状態へのそのINVITE変遷から量産しました。
Once in the Confirmed state, the call is active. It can transition to the Terminated state if the UAC sends a BYE or receives a BYE (corresponding to the "local-bye" and "remote-bye" events as appropriate), if a mid-dialog request generates a 481 or 408 response (corresponding to the "error" event), or a mid-dialog request generates no response (corresponding to the "timeout" event).
Confirmed状態でかつて、呼び出しは活発です。 UACがBYEを送るか、または不戦勝を得るなら(適宜「地方の不戦勝」と「リモート不戦勝」出来事に対応している)、それはTerminated状態に移行できます、中間の対話要求が481か408応答(「誤り」出来事に対応する)を発生させるか、または中間の対話要求が応答(「タイムアウト」出来事に対応する)を全く発生させないなら。
From the perspective of the UAS, when an INVITE is received, the FSM is created in the Trying state. If it sends a 1xx without a tag, the FSM transitions to the Proceeding state. If a 1xx is sent with a tag, the FSM transitions to the Early state, and if a 2xx is sent, it transitions to the Confirmed state. If the UAS receives a CANCEL request and then generates a 487 response to the INVITE (which can occur in the Proceeding and Early states), the FSM transitions to the Terminated state with the event "cancelled". If the UAS generates any other non-2xx final response to the INVITE request, the FSM transitions to the Terminated state with the event "rejected". If the UAS receives a new invitation (with a Replaces [13] header field) that replaces the current Confirmed dialog, the replaced invitation transitions to the Terminated state with the event "replaced". Once
INVITEが受け取られているとき、UASの見解から、FSMはTrying状態で作成されます。 タグなしで1xxを送るなら、FSMはProceeding状態に移行します。 タグで1xxを送るなら、FSMはEarly状態に移行します、そして、2xxを送るなら、それはConfirmed状態に移行します。 UASがキャンセル要求を受け取って、次に、INVITEへの487応答を発生させるなら(ProceedingとEarly州に起こることができます)、出来事に伴うTerminated状態へのFSM変遷は「取り消されました」。 UASがINVITE要求への他の非2xxの最終的な応答を発生させるなら、出来事が「拒絶されている」状態で、FSMはTerminated状態に移行します。 UASが現在のConfirmed対話に取って代わる新しい招待状(Replaces[13]ヘッダーフィールドがある)を受けるなら、出来事が「取り替えられている」状態で、取り替えられた招待はTerminated状態に移行します。 一度
Rosenberg, et al. Standards Track [Page 10] RFC 4235 Dialog Package November 2005
ローゼンバーグ、他 規格は対話パッケージ2005年11月にRFC4235を追跡します[10ページ]。
in the Confirmed state, the other transitions to the Terminated state occur for the same reasons they do in the case of UAC.
Confirmed状態では、Terminated状態への他の変遷はそれらがUACの場合でする同じ理由で起こります。
There should never be a transition from the Trying state to the
Terminated state with the event "cancelled", since the SIP
specification prohibits transmission of CANCEL until a provisional
response is received. However, this transition is defined in the
FSM just to unify the transitions from Trying, Proceeding, and
Early states to the Terminated state.
出来事が「取り消されている」Trying状態からTerminated状態までの変遷が決してあるべきではありません、暫定的な応答が受け取られているまでSIP仕様がキャンセルの送信を禁止するので。 しかしながら、この変遷は、ただTrying、Proceeding、およびEarly州からTerminated状態までの変遷を統一するためにFSMで定義されます。
3.7.2. Applying the State Machine
3.7.2. 州のマシンを適用します。
The notifier MAY generate a NOTIFY request on any event transition of the FSM. Whether it does or not is policy dependent. However, some general guidelines are provided.
notifierはFSMのどんなイベント変遷に関するNOTIFY要求も発生させるかもしれません。 それが依存するかどうかが方針に依存しています。 しかしながら、いくつかの一般的ガイドラインを提供します。
When the subscriber is unauthenticated, or it is authenticated but represents a third party with no specific authorization policies, it is RECOMMENDED that subscriptions to an individual dialog or to a specific set of dialogs be forbidden. Only subscriptions to all dialogs (i.e., there are no dialog identifiers in the Event header field) are permitted. In that case, actual dialog states across all dialogs will not be reported. Rather, a single "virtual" dialog FSM will be used, and event transitions on that FSM will be reported.
加入者が非認証されるか、特定の認可方針なしで認証されますが、第三者の代理をするとき、個々の対話か特定のセットの対話の購読が禁じられるのは、RECOMMENDEDです。 すべての対話(すなわち、Eventヘッダーフィールドには対話識別子が全くない)の購読だけが受入れられます。 その場合、すべての対話の向こう側の実際の対話州は報告されないでしょう。 むしろ、FSMがそれにおける中古、そして、イベント変遷がFSMであったならそうするただ一つの「仮想」の対話は報告されるでしょう。
If there is any dialog at the UA whose state is Confirmed, the virtual FSM is in the Confirmed state. If there are no dialogs at the UA in the Confirmed state but there is at least one in the Early state, the virtual FSM is in the Early or Confirmed state. If there are no dialogs in the Confirmed or Early states but there is at least one in the Proceeding state, the virtual FSM is in the Proceeding, Early, or Confirmed state. If there are no dialogs in the Confirmed, Early, or Proceeding states but there is at least one in the Trying state, the virtual FSM is in the Trying, Proceeding, Early or Confirmed state. The choice of state to use depends on whether the UA wishes to let unknown users know that their phone is ringing, as opposed to being in an active call.
何か対話が状態がConfirmedであるUAにあれば、仮想のFSMがConfirmed状態にあります。 対話が全くConfirmed状態のUAにありませんが、少なくとも1つがEarly状態にあれば、仮想のFSMがEarlyかConfirmed状態にあります。 対話が全くConfirmedかEarly州にありませんが、少なくとも1つがProceeding状態にあれば、仮想のFSMがProceeding、Early、またはConfirmed状態にあります。 対話が全くConfirmed、Early、またはProceeding州にありませんが、少なくとも1つがTrying状態にあれば、仮想のFSMがTrying、Proceeding、EarlyまたはConfirmed状態にあります。 使用する状態のこの選択はUAが未知のユーザに彼らの電話が鳴っているのを知らせたがっているかどうか次第です、活発な呼び出しであることと対照的に。
It is RECOMMENDED that, in the absence of any preference, Confirmed is used in all cases as shown in the example in Section 3.6. Furthermore, it is RECOMMENDED that the notifications of changes in the virtual FSM machine not convey any information except the state of the FSM and its event transitions - no dialog identifiers (which are ill-defined in this model in any case). The use of this virtual FSM allows minimal information to be conveyed. A subscriber cannot know how many calls are in progress, or with whom, just that there exists a call. This is the same information they would receive if
It is RECOMMENDED that, in the absence of any preference, Confirmed is used in all cases as shown in the example in Section 3.6. Furthermore, it is RECOMMENDED that the notifications of changes in the virtual FSM machine not convey any information except the state of the FSM and its event transitions - no dialog identifiers (which are ill-defined in this model in any case). The use of this virtual FSM allows minimal information to be conveyed. A subscriber cannot know how many calls are in progress, or with whom, just that there exists a call. This is the same information they would receive if
Rosenberg, et al. Standards Track [Page 11] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 11] RFC 4235 Dialog Package November 2005
they simply sent an INVITE to the user instead; a 486 (Busy Here) response would indicate that they are on a call.
they simply sent an INVITE to the user instead; a 486 (Busy Here) response would indicate that they are on a call.
When the subscriber is authenticated and has authenticated itself with the same address-of-record that the UA itself uses, if no explicit authorization policy is defined, it is RECOMMENDED that all state transitions on dialogs that have been subscribed to be reported, along with complete dialog IDs. This means either all of the dialogs, if no dialog identifiers were present in the Event header field, or the specific set of dialogs identified by the Event header field parameters.
When the subscriber is authenticated and has authenticated itself with the same address-of-record that the UA itself uses, if no explicit authorization policy is defined, it is RECOMMENDED that all state transitions on dialogs that have been subscribed to be reported, along with complete dialog IDs. This means either all of the dialogs, if no dialog identifiers were present in the Event header field, or the specific set of dialogs identified by the Event header field parameters.
The notifier SHOULD generate a NOTIFY request on any change in the characteristics associated with the dialog. Since these include Contact URIs, Contact parameters, and session descriptions, receipt of re-INVITEs and UPDATE requests [3] that modify this information MAY trigger notifications.
The notifier SHOULD generate a NOTIFY request on any change in the characteristics associated with the dialog. Since these include Contact URIs, Contact parameters, and session descriptions, receipt of re-INVITEs and UPDATE requests [3] that modify this information MAY trigger notifications.
3.8. Subscriber Processing of NOTIFY Requests
3.8. Subscriber Processing of NOTIFY Requests
The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in package-specific ways. In particular, a package should specify how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource.
The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in package-specific ways. In particular, a package should specify how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource.
Typically, the NOTIFY for the dialog package will contain information about only those dialogs whose state has changed. To construct a coherent view of the total state of all dialogs, a subscriber to the dialog package will need to combine NOTIFYs received over time.
Typically, the NOTIFY for the dialog package will contain information about only those dialogs whose state has changed. To construct a coherent view of the total state of all dialogs, a subscriber to the dialog package will need to combine NOTIFYs received over time.
Notifications within this package can convey partial information; that is, they can indicate information about a subset of the state associated with the subscription. This means that an explicit algorithm needs to be defined in order to construct coherent and consistent state. The details of this mechanism are specific to the particular document type. See Section 4.3 for information on constructing coherent information from an application/dialog-info+xml document.
Notifications within this package can convey partial information; that is, they can indicate information about a subset of the state associated with the subscription. This means that an explicit algorithm needs to be defined in order to construct coherent and consistent state. The details of this mechanism are specific to the particular document type. See Section 4.3 for information on constructing coherent information from an application/dialog-info+xml document.
3.9. Handling of Forked Requests
3.9. Handling of Forked Requests
Since dialog state is distributed across the UA for a particular user, it is reasonable and useful for a SUBSCRIBE request for dialog state to fork and to reach multiple UAs.
Since dialog state is distributed across the UA for a particular user, it is reasonable and useful for a SUBSCRIBE request for dialog state to fork and to reach multiple UAs.
As a result, a forked SUBSCRIBE request for dialog state can install multiple subscriptions. Subscribers to this package MUST be prepared
As a result, a forked SUBSCRIBE request for dialog state can install multiple subscriptions. Subscribers to this package MUST be prepared
Rosenberg, et al. Standards Track [Page 12] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 12] RFC 4235 Dialog Package November 2005
to install subscription state for each NOTIFY generated as a result of a single SUBSCRIBE.
to install subscription state for each NOTIFY generated as a result of a single SUBSCRIBE.
3.10. Rate of Notifications
3.10. Rate of Notifications
For reasons of congestion control, it is important that the rate of notifications not be excessive. It is RECOMMENDED that the server not generate notifications for a single subscriber faster than once every 1 second.
For reasons of congestion control, it is important that the rate of notifications not be excessive. It is RECOMMENDED that the server not generate notifications for a single subscriber faster than once every 1 second.
3.11. State Agents
3.11. State Agents
Dialog state is ideally maintained in the user agents in which the dialog resides. Therefore, the elements that maintain the dialog are the ones best suited to handle subscriptions to it. However, in some cases, a network agent may also know the state of the dialogs held by a user. Such state agents MAY be used with this package.
Dialog state is ideally maintained in the user agents in which the dialog resides. Therefore, the elements that maintain the dialog are the ones best suited to handle subscriptions to it. However, in some cases, a network agent may also know the state of the dialogs held by a user. Such state agents MAY be used with this package.
4. Dialog Information Format
4. Dialog Information Format
Dialog information is an XML document [4] that MUST be well-formed and SHOULD be valid. Dialog information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying dialog information documents and document fragments. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by [6] and extended by [7]. This URN is:
Dialog information is an XML document [4] that MUST be well-formed and SHOULD be valid. Dialog information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying dialog information documents and document fragments. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by [6] and extended by [7]. This URN is:
urn:ietf:params:xml:ns:dialog-info
urn:ietf:params:xml:ns:dialog-info
A dialog information document begins with the root element tag "dialog-info".
A dialog information document begins with the root element tag "dialog-info".
4.1. Structure of Dialog Information
4.1. Structure of Dialog Information
A dialog information document starts with a dialog-info element. This element has three mandatory attributes:
A dialog information document starts with a dialog-info element. This element has three mandatory attributes:
o version: This attribute allows the recipient of dialog information
documents to properly order them. Versions start at 0, and
increment by one for each new document sent to a subscriber.
Versions are scoped within a subscription. Versions MUST be
representable using a non-negative 32 bit integer.
o version: This attribute allows the recipient of dialog information documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a subscription. Versions MUST be representable using a non-negative 32 bit integer.
o state: This attribute indicates whether the document contains the
full dialog information, or whether it contains only information
on those dialogs that have changed since the previous document
(partial).
o state: This attribute indicates whether the document contains the full dialog information, or whether it contains only information on those dialogs that have changed since the previous document (partial).
Rosenberg, et al. Standards Track [Page 13] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 13] RFC 4235 Dialog Package November 2005
o entity: This attribute contains a URI that identifies the user
whose dialog information is reported in the remainder of the
document. This user is referred to as the "observed user".
o entity: This attribute contains a URI that identifies the user whose dialog information is reported in the remainder of the document. This user is referred to as the "observed user".
The dialog-info element has a series of zero or more dialog sub- elements. Each of those represents a specific dialog. An example:
The dialog-info element has a series of zero or more dialog sub- elements. Each of those represents a specific dialog. An example:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" notify-state="full"
entity="sip:alice@example.com">
</dialog-info>
<?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" notify-state="full" entity="sip:alice@example.com"> </dialog-info>
4.1.1. Dialog Element
4.1.1. Dialog Element
The dialog element reports information about a specific dialog or "half-dialog". It has a single mandatory attribute: id. The id attribute provides a single string that can be used as an identifier for this dialog or "half-dialog". This is a different identifier than the dialog ID defined in RFC 3261 [2], but related to it.
The dialog element reports information about a specific dialog or "half-dialog". It has a single mandatory attribute: id. The id attribute provides a single string that can be used as an identifier for this dialog or "half-dialog". This is a different identifier than the dialog ID defined in RFC 3261 [2], but related to it.
For a caller, the id is created when an INVITE request is sent. When a 1xx response with a tag, or a 2xx response is received, the dialog is formally created. The id remains unchanged. However, if an additional 1xx or 2xx is received, resulting in the creation of another dialog (and resulting FSM), that dialog is allocated a new id.
For a caller, the id is created when an INVITE request is sent. When a 1xx response with a tag, or a 2xx response is received, the dialog is formally created. The id remains unchanged. However, if an additional 1xx or 2xx is received, resulting in the creation of another dialog (and resulting FSM), that dialog is allocated a new id.
For a callee, the id is created when an INVITE outside of an existing dialog is received. When a 2xx or a 1xx with a tag is sent, creating the dialog, the id remains unchanged.
For a callee, the id is created when an INVITE outside of an existing dialog is received. When a 2xx or a 1xx with a tag is sent, creating the dialog, the id remains unchanged.
The id MUST be unique amongst all current dialogs at a UA.
The id MUST be unique amongst all current dialogs at a UA.
There are a number of optional attributes that provide identification information about the dialog:
There are a number of optional attributes that provide identification information about the dialog:
o call-id: This attribute is a string that represents the call-id
component of the dialog identifier. (Note that single and
double quotes inside a call-id must be escaped using "e;
for " and ' for ' .)
o call-id: This attribute is a string that represents the call-id component of the dialog identifier. (Note that single and double quotes inside a call-id must be escaped using "e; for " and ' for ' .)
o local-tag: This attribute is a string that represents the
local-tag component of the dialog identifier.
o local-tag: This attribute is a string that represents the local-tag component of the dialog identifier.
o remote-tag: This attribute is a string that represents the
remote-tag component of the dialog identifier. The remote tag
attribute won't be present if there is only a "half-dialog",
o remote-tag: This attribute is a string that represents the remote-tag component of the dialog identifier. The remote tag attribute won't be present if there is only a "half-dialog",
Rosenberg, et al. Standards Track [Page 14] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 14] RFC 4235 Dialog Package November 2005
resulting from the generation of an INVITE for which no final
responses or provisional responses with tags has been received.
resulting from the generation of an INVITE for which no final responses or provisional responses with tags has been received.
o direction: This attribute is either initiator or recipient, and
indicates whether the observed user was the initiator of the
dialog, or the recipient of the INVITE that created it.
o direction: This attribute is either initiator or recipient, and indicates whether the observed user was the initiator of the dialog, or the recipient of the INVITE that created it.
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
...
</dialog>
</dialog-info>
<?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="partial" entity="sip:alice@example.com"> <dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" direction="initiator"> ... </dialog> </dialog-info>
The sub-elements of the dialog element provide additional information about the dialog. Some of these sub-elements provide more detail about the dialog itself, while the local and remote sub-elements describe characteristics of the participants involved in the dialog. The only mandatory sub-element is the state element.
The sub-elements of the dialog element provide additional information about the dialog. Some of these sub-elements provide more detail about the dialog itself, while the local and remote sub-elements describe characteristics of the participants involved in the dialog. The only mandatory sub-element is the state element.
4.1.2. State Element
4.1.2. State Element
The "state" element indicates the state of the dialog. Its value is an enumerated type describing one of the states in the FSM above. It has an optional event attribute that can be used to indicate the event that caused any transition into the terminated state, and an optional code attribute that indicates the response code associated with any transition caused by a response to the original INVITE.
The "state" element indicates the state of the dialog. Its value is an enumerated type describing one of the states in the FSM above. It has an optional event attribute that can be used to indicate the event that caused any transition into the terminated state, and an optional code attribute that indicates the response code associated with any transition caused by a response to the original INVITE.
<state event="rejected" code="486">terminated</state>
<state event="rejected" code="486">terminated</state>
4.1.3. Duration Element
4.1.3. Duration Element
The "duration" element contains the amount of time, in seconds, since the FSM was created.
The "duration" element contains the amount of time, in seconds, since the FSM was created.
<duration>145</duration>
<duration>145</duration>
4.1.4. Replaces Element
4.1.4. Replaces Element
The "replaces" element is used to correlate a new dialog with one it replaced as a result of an invitation with a Replaces header field. This element is present in the replacement dialog only (the newer dialog) and contains attributes with the call-id, local-tag, and remote-tag of the replaced dialog.
The "replaces" element is used to correlate a new dialog with one it replaced as a result of an invitation with a Replaces header field. This element is present in the replacement dialog only (the newer dialog) and contains attributes with the call-id, local-tag, and remote-tag of the replaced dialog.
Rosenberg, et al. Standards Track [Page 15] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 15] RFC 4235 Dialog Package November 2005
<replaces call-id="hg287s98s89"
local-tag="6762h7" remote-tag="09278hsb"/>
<replaces call-id="hg287s98s89" local-tag="6762h7" remote-tag="09278hsb"/>
4.1.5. Referred-By Element
4.1.5. Referred-By Element
The "referred-by" element is used to correlate a new dialog with a REFER [12] request that triggered it. The element is present in a dialog that was triggered by a REFER request that contained a Referred-By [11] header field and contains the (optional) display name attribute and the Referred-By URI as its value.
The "referred-by" element is used to correlate a new dialog with a REFER [12] request that triggered it. The element is present in a dialog that was triggered by a REFER request that contained a Referred-By [11] header field and contains the (optional) display name attribute and the Referred-By URI as its value.
<referred-by display="Bob">sip:bob@example.com</referred-by>
<referred-by display="Bob">sip:bob@example.com</referred-by>
4.1.6. Local and Remote Elements
4.1.6. Local and Remote Elements
The "local" and "remote" elements are sub-elements of the dialog element that contain information about the local and remote participants, respectively. They both have a number of optional sub-elements that indicate the identity conveyed by the participant, the target URI, the feature-tags of the target, and the session-description of the participant.
The "local" and "remote" elements are sub-elements of the dialog element that contain information about the local and remote participants, respectively. They both have a number of optional sub-elements that indicate the identity conveyed by the participant, the target URI, the feature-tags of the target, and the session-description of the participant.
4.1.6.1. Identity Element
4.1.6.1. Identity Element
The "identity" element indicates a local or remote URI, as defined in [2] as appropriate. It has an optional attribute, display, that contains the display name from the appropriate URI.
The "identity" element indicates a local or remote URI, as defined in [2] as appropriate. It has an optional attribute, display, that contains the display name from the appropriate URI.
Note that multiple identities (for example a sip: URI and a tel:
URI) could be included if they all correspond to the participant.
To avoid repeating identity information in each request, the
subscriber can assume that the identity URIs are the same as in
previous notifications if no identity elements are present in the
corresponding local or remote element. If any identity elements
are present in the local or remote part of a notification, the new
list of identity tags completely supersedes the old list in the
corresponding part.
Note that multiple identities (for example a sip: URI and a tel: URI) could be included if they all correspond to the participant. To avoid repeating identity information in each request, the subscriber can assume that the identity URIs are the same as in previous notifications if no identity elements are present in the corresponding local or remote element. If any identity elements are present in the local or remote part of a notification, the new list of identity tags completely supersedes the old list in the corresponding part.
<identity display="Anonymous">
sip:anonymous@anonymous.invalid</identity>
<identity display="Anonymous"> sip:anonymous@anonymous.invalid</identity>
4.1.6.2. Target Element
4.1.6.2. Target Element
The "target" contains the local or remote target URI constructed by the user agent for this dialog, as defined in RFC 3261 [2] in a "uri" attribute.
The "target" contains the local or remote target URI constructed by the user agent for this dialog, as defined in RFC 3261 [2] in a "uri" attribute.
Rosenberg, et al. Standards Track [Page 16] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 16] RFC 4235 Dialog Package November 2005
It can contain a list of Contact header parameters in param sub- elements (such as those defined in [10]). The param element contains two required attributes, pname and pval. Boolean parameters are represented by the explicit pval values, "true" and "false" (for example, when a feature parameter is explicitly negated). Parameters that have no value at all are represented by the explicit pval value "true". The param element itself has no contents. To avoid repeating Contact information in each request, the subscriber can assume that the target URI and parameters are the same as in previous notifications if no target element is present in the corresponding local or remote element. If a target element is present in the local or remote part of a notification, the new target tag and list of parameter tags completely supersedes the old target and parameter list in the corresponding part. Note that any quoting (including extra angle-bracket quoting used to quote string values in [10]) or backslash escaping MUST be removed before being placed in a pval attribute. Any remaining single quotes, double quotes, and ampersands MUST be properly XML escaped.
It can contain a list of Contact header parameters in param sub- elements (such as those defined in [10]). The param element contains two required attributes, pname and pval. Boolean parameters are represented by the explicit pval values, "true" and "false" (for example, when a feature parameter is explicitly negated). Parameters that have no value at all are represented by the explicit pval value "true". The param element itself has no contents. To avoid repeating Contact information in each request, the subscriber can assume that the target URI and parameters are the same as in previous notifications if no target element is present in the corresponding local or remote element. If a target element is present in the local or remote part of a notification, the new target tag and list of parameter tags completely supersedes the old target and parameter list in the corresponding part. Note that any quoting (including extra angle-bracket quoting used to quote string values in [10]) or backslash escaping MUST be removed before being placed in a pval attribute. Any remaining single quotes, double quotes, and ampersands MUST be properly XML escaped.
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="business"/>
<param pname="description" pval="Alice's desk & office"/>
<param pname="sip.rendering" pval="no"/>
</target>
<target uri="sip:alice@pc33.example.com"> <param pname="isfocus" pval="true"/> <param pname="class" pval="business"/> <param pname="description" pval="Alice's desk & office"/> <param pname="sip.rendering" pval="no"/> </target>
4.1.6.3. Session Description Element
4.1.6.3. Session Description Element
The session-description element contains the session description used by the observed user for its end of the dialog. This element should generally NOT be included in the notifications, unless it was explicitly requested by the subscriber. It has a single attribute, "type", which indicates the MIME media type of the session description. To avoid repeating session description information in each request, the subscriber can assume that the session description is the same as in previous notifications if no session description element is present in the corresponding local or remote element.
The session-description element contains the session description used by the observed user for its end of the dialog. This element should generally NOT be included in the notifications, unless it was explicitly requested by the subscriber. It has a single attribute, "type", which indicates the MIME media type of the session description. To avoid repeating session description information in each request, the subscriber can assume that the session description is the same as in previous notifications if no session description element is present in the corresponding local or remote element.
4.2. Sample Notification Body
4.2. Sample Notification Body
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
<dialog id="123456">
<state>confirmed</state>
<duration>274</duration>
<?xml version="1.0" encoding="UTF-8"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info" version="1" state="full"> <dialog id="123456"> <state>confirmed</state> <duration>274</duration>
Rosenberg, et al. Standards Track [Page 17] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 17] RFC 4235 Dialog Package November 2005
<local>
<identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="personal"/>
</target>
</local>
<remote>
<identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>
<local> <identity display="Alice">sip:alice@example.com</identity> <target uri="sip:alice@pc33.example.com"> <param pname="isfocus" pval="true"/> <param pname="class" pval="personal"/> </target> </local> <remote> <identity display="Bob">sip:bob@example.org</identity> <target uri="sip:bobster@phone21.example.org"/> </remote> </dialog> </dialog-info>
4.3. Constructing Coherent State
4.3. Constructing Coherent State
The dialog information subscriber maintains a table listing the dialogs, with a row for each dialog. Each row is indexed by an ID that is present in the "id" attribute of the "dialog" element. Each row contains the state of that dialog, as conveyed in the document.
The dialog information subscriber maintains a table listing the dialogs, with a row for each dialog. Each row is indexed by an ID that is present in the "id" attribute of the "dialog" element. Each row contains the state of that dialog, as conveyed in the document.
The table is also associated with a version number. The version number MUST be initialized with the value of the "version" attribute from the "dialog-info" element in the first document received. Each time a new document is received, the value of the local version number is compared to the "version" attribute in the new document. If the value in the new document is one higher than the local version number, the local version number is increased by one and the document is processed. If the value in the document is more than one higher than the local version number, the local version number is set to the value in the new document and the document is processed. If the document did not contain full state, the subscriber SHOULD generate a refresh request (SUBSCRIBE) to trigger a full state notification. If the value in the document is less than the local version, the document is discarded without processing.
The table is also associated with a version number. The version number MUST be initialized with the value of the "version" attribute from the "dialog-info" element in the first document received. Each time a new document is received, the value of the local version number is compared to the "version" attribute in the new document. If the value in the new document is one higher than the local version number, the local version number is increased by one and the document is processed. If the value in the document is more than one higher than the local version number, the local version number is set to the value in the new document and the document is processed. If the document did not contain full state, the subscriber SHOULD generate a refresh request (SUBSCRIBE) to trigger a full state notification. If the value in the document is less than the local version, the document is discarded without processing.
The processing of the dialog information document depends on whether it contains full or partial state. If it contains full state, indicated by the value of the "state" attribute in the "dialog-info" element, the contents of the table are flushed and then repopulated from the document. A new row in the table is created for each "dialog" element. If the document contains partial state, as indicated by the value of the "state" attribute in the "dialog-info" element, the document is used to update the table. For each "dialog" element in the document, the subscriber checks to see whether a row exists for that dialog. This check compares the ID in the "id" attribute of the "dialog" element with the ID associated with the row. If the dialog does not exist in the table, a row is added and
The processing of the dialog information document depends on whether it contains full or partial state. If it contains full state, indicated by the value of the "state" attribute in the "dialog-info" element, the contents of the table are flushed and then repopulated from the document. A new row in the table is created for each "dialog" element. If the document contains partial state, as indicated by the value of the "state" attribute in the "dialog-info" element, the document is used to update the table. For each "dialog" element in the document, the subscriber checks to see whether a row exists for that dialog. This check compares the ID in the "id" attribute of the "dialog" element with the ID associated with the row. If the dialog does not exist in the table, a row is added and
Rosenberg, et al. Standards Track [Page 18] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 18] RFC 4235 Dialog Package November 2005
its state is set to the information from that "dialog" element. If the dialog does exist, its state is updated to be the information from that "dialog" element. If a row is updated or created, such that its state is now terminated, that entry MAY be removed from the table at any time.
its state is set to the information from that "dialog" element. If the dialog does exist, its state is updated to be the information from that "dialog" element. If a row is updated or created, such that its state is now terminated, that entry MAY be removed from the table at any time.
4.4. Schema
4.4. Schema
The following is the schema for the application/dialog-info+xml type:
The following is the schema for the application/dialog-info+xml type:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:dialog-info"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language
attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:dialog-info" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn:ietf:params:xml:ns:dialog-info" elementFormDefault="qualified" attributeFormDefault="unqualified"> <!-- This import brings in the XML language attribute xml:lang--> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="dialog-info">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:dialog" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:nonNegativeInteger"
use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="partial"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="entity" type="xs:anyURI"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="dialog-info"> <xs:complexType> <xs:sequence> <xs:element ref="tns:dialog" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="version" type="xs:nonNegativeInteger" use="required"/> <xs:attribute name="state" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="full"/> <xs:enumeration value="partial"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="entity" type="xs:anyURI" use="required"/> </xs:complexType> </xs:element>
Rosenberg, et al. Standards Track [Page 19] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 19] RFC 4235 Dialog Package November 2005
<xs:element name="dialog">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/>
<xs:element name="duration" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:element name="replaces" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="required"/>
<xs:attribute name="local-tag" type="xs:string"
use="required"/>
<xs:attribute name="remote-tag" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="referred-by" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="route-set" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="hop" type="xs:string"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="local" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:element name="remote" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="call-id" type="xs:string"
use="optional"/>
<xs:attribute name="local-tag" type="xs:string"
use="optional"/>
<xs:attribute name="remote-tag" type="xs:string"
use="optional"/>
<xs:attribute name="direction" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="initiator"/>
<xs:enumeration value="recipient"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:element name="dialog"> <xs:complexType> <xs:sequence> <xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/> <xs:element name="duration" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="replaces" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="call-id" type="xs:string" use="required"/> <xs:attribute name="local-tag" type="xs:string" use="required"/> <xs:attribute name="remote-tag" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="referred-by" type="tns:nameaddr" minOccurs="0" maxOccurs="1"/> <xs:element name="route-set" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="hop" type="xs:string" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="local" type="tns:participant" minOccurs="0" maxOccurs="1"/> <xs:element name="remote" type="tns:participant" minOccurs="0" maxOccurs="1"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="call-id" type="xs:string" use="optional"/> <xs:attribute name="local-tag" type="xs:string" use="optional"/> <xs:attribute name="remote-tag" type="xs:string" use="optional"/> <xs:attribute name="direction" use="optional"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="initiator"/> <xs:enumeration value="recipient"/> </xs:restriction> </xs:simpleType> </xs:attribute>
Rosenberg, et al. Standards Track [Page 20] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 20] RFC 4235 Dialog Package November 2005
</xs:complexType>
</xs:element>
</xs:complexType> </xs:element>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="identity" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="target" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="uri" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="session-description" type="tns:sessd"
minOccurs="0" maxOccurs="1"/>
<xs:element name="cseq" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="participant"> <xs:sequence> <xs:element name="identity" type="tns:nameaddr" minOccurs="0" maxOccurs="1"/> <xs:element name="target" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="param" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="pname" type="xs:string" use="required"/> <xs:attribute name="pval" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="uri" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="session-description" type="tns:sessd" minOccurs="0" maxOccurs="1"/> <xs:element name="cseq" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:complexType name="nameaddr">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="display-name" type="xs:string"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="sessd">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string"
use="required"/>
</xs:extension>
</xs:simpleContent>
<xs:complexType name="nameaddr"> <xs:simpleContent> <xs:extension base="xs:anyURI"> <xs:attribute name="display-name" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="sessd"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="type" type="xs:string" use="required"/> </xs:extension> </xs:simpleContent>
Rosenberg, et al. Standards Track [Page 21] RFC 4235 Dialog Package November 2005
Rosenberg, et al. Standards Track [Page 21] RFC 4235 Dialog Package November 2005
</xs:complexType>
</xs:complexType>
<xs:element name="state">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="event" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="cancelled"/>
<xs:enumeration value="rejected"/>
<xs:enumeration value="replaced"/>
<xs:enumeration value="local-bye"/>
<xs:enumeration value="remote-bye"/>
<xs:enumeration value="error"/>
<xs:enumeration value="timeout"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="code" use="optional">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:minInclusive value="100"/>
<xs:maxInclusive value="699"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:element name="state"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="event" use="optional"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="cancelled"/> <xs:enumeration value="rejected"/> <xs:enumeration value="replaced"/> <xs:enumeration value="local-bye"/> <xs:enumeration value="remote-bye"/> <xs:enumeration value="error"/> <xs:enumeration value="timeout"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="code" use="optional"> <xs:simpleType> <xs:restriction base="xs:positiveInteger"> <xs:minInclusive value="100"/> <xs:maxInclusive value="699"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:schema>
5. Definition of New Media Feature Parameters
5. Definition of New Media Feature Parameters
This section defines two new media feature parameters that are useful as input to user presence, in conferencing applications, and in applications like the shared-line example described in Section 6.2. These feature parameters are especially useful in combination with the dialog package, as they allow an authorized third party to become aware of these characteristics.
This section defines two new media feature parameters that are useful as input to user presence, in conferencing applications, and in applications like the shared-line example described in Section 6.2. These feature parameters are especially useful in combination with the dialog package, as they allow an authorized third party to become aware of these characteristics.
5.1. The "sip.byeless" Parameter
5.1. The "sip.byeless" Parameter
一覧
スポンサーリンク
