RFC4730 日本語訳
4730 A Session Initiation Protocol (SIP) Event Package for Key PressStimulus (KPML). E. Burger, M. Dolly. November 2006. (Format: TXT=120186 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Burger
Request for Comments: 4730 Cantata Technology, Inc.
Category: Standards Track M. Dolly
AT&T Labs
November 2006
コメントを求めるワーキンググループE.バーガー要求をネットワークでつないでください: 4730年のカンタータ技術Inc.カテゴリ: 標準化過程M.台車AT&T研究室2006年11月
A Session Initiation Protocol (SIP) Event Package
for Key Press Stimulus (KPML)
主要なプレス刺激のためのセッション開始プロトコル(一口)イベントパッケージ(KPML)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
This document describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in the Session Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers).
このドキュメントは、モニターを可能にするDual利根Multi-頻度(DTMF)信号のSIP Eventパッケージ"kpml"について説明して、Key Press Markup Language(KPML)と呼ばれた拡張マークアップ言語(XML)ドキュメントを使用します。 kpml Eventパッケージは、「セッション開始プロトコル(一口)におけるアプリケーション間連携のためのフレームワーク」と題をつけられたドキュメントで定義される原則と一致したアプリケーションをサポートするのに使用されるかもしれません。 イベントパッケージが使用する、登録、主要なプレスが無プレゼンテーションのUser Interface SIP Userエージェント(UA)で入られた(DTMF Tones)であるとキャプチャするためのフィルタ仕様を定義して、説明するXMLドキュメントのために、通信して、許容します。 イベントパッケージは、NOTIFYメッセージを使用して、XMLのためにドキュメントがフィルタ仕様と一致した捕らわれている主要なプレス(DTMFトーン)を報告するのを許容します、Application Serverに。このパッケージの範囲は、補足の主要なプレスか中間の呼び出しの主要なプレス(引き金)を集めるものです。
Burger & Dolly Standards Track [Page 1] RFC 4730 KPML November 2006
バーガーと台車標準化過程[1ページ]RFC4730KPML2006年11月
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. Protocol Overview ...............................................5
3. Key Concepts ....................................................6
3.1. Subscription Duration ......................................6
3.2. Timers .....................................................7
3.3. Pattern Matches ............................................8
3.4. Digit Suppression .........................................12
3.5. User Input Buffer Behavior ................................14
3.6. DRegex ....................................................16
3.6.1. Overview ...........................................16
3.6.2. Operation ..........................................18
3.7. Monitoring Direction ......................................20
3.8. Multiple Simultaneous Subscriptions .......................20
4. Event Package Formal Definition ................................21
4.1. Event Package Name ........................................21
4.2. Event Package Parameters ..................................21
4.3. SUBSCRIBE Bodies ..........................................22
4.4. Subscription Duration .....................................22
4.5. NOTIFY Bodies .............................................22
4.6. Subscriber Generation of SUBSCRIBE Requests ...............22
4.7. Notifier Processing of SUBSCRIBE Requests .................23
4.8. Notifier Generation of NOTIFY Requests ....................25
4.9. Subscriber Processing of NOTIFY Requests ..................27
4.10. Handling of Forked Requests ..............................28
4.11. Rate of Notifications ....................................28
4.12. State Agents and Lists ...................................28
4.13. Behavior of a Proxy Server ...............................29
5. Formal Syntax ..................................................29
5.1. DRegex ....................................................29
5.2. KPML Request ..............................................30
5.3. KPML Response .............................................33
6. Enumeration of KPML Status Codes ...............................34
7. IANA Considerations ............................................34
7.1. SIP Event Package Registration ............................34
7.2. MIME Media Type application/kpml-request+xml ..............35
7.3. MIME Media Type application/kpml-response+xml .............35
7.4. URN Sub-Namespace Registration for
urn:ietf:xml:ns:kpml-request ..............................35
7.5. URN Sub-Namespace Registration for
urn:ietf:xml:ns:kpml-response .............................36
7.6. KPML Request Schema Registration ..........................37
7.7. KPML Response Schema Registration .........................37
8. Security Considerations ........................................37
9. Examples .......................................................38
9.1. Monitoring for Octothorpe .................................38
1. 序論…4 1.1. このドキュメントで中古のコンベンション…5 2. 概要について議定書の中で述べてください…5 3. 重要概念…6 3.1. 購読持続時間…6 3.2. タイマ…7 3.3. マッチを型に基づいて作ってください…8 3.4. ケタ抑圧…12 3.5. ユーザはバッファの振舞いを入力しました…14 3.6. DRegex…16 3.6.1. 概要…16 3.6.2. 操作…18 3.7. 方向をモニターします…20 3.8. 複数の同時の購読…20 4. イベントパッケージ公式の定義…21 4.1. イベントパッケージ名…21 4.2. イベントパッケージパラメタ…21 4.3. ボディーを申し込んでください…22 4.4. 購読持続時間…22 4.5. ボディーに通知してください…22 4.6. 加入者世代、要求を申し込んでください…22 4.7. より多くのNotifierに処理する、要求を申し込んでください…23 4.8. Notifier世代、要求に通知してください…25 4.9. 加入者、処理する、要求に通知してください…27 4.10. 股状の要求の取り扱い…28 4.11. 通知の速度…28 4.12. エージェントとリストを述べてください…28 4.13. Proxyサーバの振舞い…29 5. 正式な構文…29 5.1. DRegex…29 5.2. KPML要求…30 5.3. KPML応答…33 6. KPMLステータスコードの列挙…34 7. IANA問題…34 7.1. イベントパッケージ登録をちびちび飲んでください…34 7.2. MIMEメディアTypeアプリケーション/kpml-要求+xml…35 7.3. MIMEメディアTypeアプリケーション/kpml-応答+xml…35 7.4. つぼ:ietf:xmlのためのURN Sub-名前空間Registration: ナノ秒: kpml-要求…35 7.5. つぼ:ietf:xmlのためのURN Sub-名前空間Registration: ナノ秒: kpml-応答…36 7.6. KPMLは図式登録を要求します…37 7.7. KPML応答図式登録…37 8. セキュリティ問題…37 9. 例…38 9.1. シャープ記号のために、モニターします。38
Burger & Dolly Standards Track [Page 2] RFC 4730 KPML November 2006
バーガーと台車標準化過程[2ページ]RFC4730KPML2006年11月
9.2. Dial String Collection ....................................39
10. Call Flow Examples ............................................40
10.1. Supplemental Digits ......................................40
10.2. Multiple Applications ....................................45
11. References ....................................................52
11.1. Normative References .....................................52
11.2. Informative References ...................................53
Appendix A. Contributors .........................................54
Appendix B. Acknowledgements .....................................54
9.2. ストリング収集にダイヤルしてください…39 10. 例に流れに電話をしてください…40 10.1. 補足のケタ…40 10.2. 複数のアプリケーション…45 11. 参照…52 11.1. 標準の参照…52 11.2. 有益な参照…53 付録A.貢献者…54 付録B.承認…54
Burger & Dolly Standards Track [Page 3] RFC 4730 KPML November 2006
バーガーと台車標準化過程[3ページ]RFC4730KPML2006年11月
1. Introduction
1. 序論
This document describes a SIP Event Package "kpml" that enables monitoring of key presses and utilizes XML documents referred to as Key Press Markup Language (KPML). KPML is a markup [14] that enables presentation-free User Interfaces as described in the Application Interaction Framework [15]. The Key Press Stimulus Package is a SIP Event Notification Package [5] that uses the SUBSCRIBE and NOTIFY methods of SIP. The subscription filter and notification report bodies use the Keypad Markup Language, KPML.
このドキュメントは主要なプレスのモニターを可能にして、Key Press Markup Language(KPML)と呼ばれたXMLドキュメントを利用するSIP Eventパッケージ"kpml"について説明します。 KPMLはApplication Interaction Framework[15]で説明されるように無プレゼンテーションのUser Interfacesを有効にするマークアップ[14]です。 Key Press Stimulusパッケージがそれが使用するSIP Event Notificationパッケージ[5]である、登録、そして、SIPのNOTIFYメソッド。 購読フィルタと通知レポート本文はKeypad Markup Language、KPMLを使用します。
The "kpml" event package requires the definition of two new MIME types, two new URN sub-namespaces, and two schemas for the KPML Request and the KPML Response. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). This capability allows an Application Server service provider to monitor (filter) for a set of DTMF patterns at a SIP User Agent located in either an end-user device or a gateway.
"kpml"イベントパッケージはKPML RequestとKPML Responseのために2つの新しいMIMEの種類、2つの新しいURNサブ名前空間、および2schemasの定義を必要とします。 このパッケージの範囲は、補足の主要なプレスか中間の呼び出しの主要なプレス(引き金)を集めるものです。 この能力で、Application ServerサービスプロバイダーはDTMFの1セットのためにエンドユーザデバイスかゲートウェイのどちらかに位置するSIP Userエージェントでパターンをモニターできます(フィルターにかけます)。
In particular, the "kpml" event package enables "dumb phones" and "gateways" that receive signals from dumb phones to report user key- press events. Colloquially, this mechanism provides for "digit reporting" or "Dual Tone Multi-Frequency (DTMF) reporting." The capability eliminates the need for "hair-pinning" (routing media into and then out of the same device) through a Media Server or duplicating all the DTMF events, when an Application Server needs to trigger mid-call service processing on DTMF digit patterns.
特に、"kpml"イベントパッケージは「馬鹿な電話」を可能にします、そして、受信される「ゲートウェイ」は馬鹿な電話からユーザの主要な報道機関向けのイベントを報告すると合図します。 口語的に、このメカニズムは「ケタ報告」か「二元的な利根Multi-頻度(DTMF)報告」に備えます。 能力はメディアServerかすべてのDTMFイベントをコピーすることで「髪ピンで止めること」の必要性(デバイスとそして、同じデバイスからのルーティングメディア)を排除します、Application Serverが、DTMFケタパターンで中間の呼び出しサービス処理の引き金となる必要があると。
A goal of KPML is to fit in an extremely small memory and processing footprint.
KPMLの目標は非常に小さいメモリと処理足跡をうまくはめ込むことです。
The name of the XML document, KPML, reflects its legacy support role. The public switched telephony network (PSTN) accomplished signaling by transporting DTMF tones in the bearer channel (in-band signaling) from the user terminal to the local exchange.
KPMLというXMLドキュメントの名前はレガシーサポートの役割を反映します。 公衆は運搬人チャンネル(バンドにおけるシグナリング)でユーザ端末から市内交換までDTMFトーンを輸送することによって合図しながら達成された電話ネットワーク(PSTN)を切り換えました。
Voice-over-IP networks transport in-band signals with actual DTMF waveforms or RFC 2833 [10] packets. In RFC 2833, the signaling application inserts RFC 2833 named signal packets as well as, or instead of, generating tones in the media path. The receiving application receives the signal information in the media stream.
Voice-over-IPネットワークは実際のDTMF波形かRFC2833[10]パケットでバンドにおける信号を輸送します。 RFC2833では、RFC2833が命名したシグナリングアプリケーション差し込みは生成するか、またはメディア経路でトーンを生成するところのパケットに合図します。 受信アプリケーションはメディアストリームにおける信号情報を受け取ります。
RFC 2833 tones are ideal for conveying telephone-events point-to- point in a Real-time Transport Protocol (RTP) stream, as in the context of straightforward sessions like a 2-party call or a simple, centrally mixed conference. However, there are other environments where additional or alternative requirements are needed. These other environments include protocol translation and complex call control.
レアル-時間Transportプロトコル(RTP)ストリームで電話イベントポイントからポイントを伝えるのに、RFC2833トーンは理想的です、2パーティーの呼び出し、または簡単で、中心に複雑な会議のような簡単なセッションの文脈のように。 しかしながら、他の環境が追加しているか代替の要件が必要であるところにあります。 これらの他の環境はプロトコル変換と複雑な呼び出しコントロールを含んでいます。
Burger & Dolly Standards Track [Page 4] RFC 4730 KPML November 2006
バーガーと台車標準化過程[4ページ]RFC4730KPML2006年11月
An interested application could request notifications of every key press. However, many of the use cases for such signaling show that most applications are interested in only one or a few keystrokes. Thus a mechanism is needed for specifying to the user's interface what stimuli the application requires.
関心があるアプリケーションは、あらゆるキーの通知が押されるよう要求するかもしれません。 しかしながら、使用の多くがそのようなもののためにほとんどのアプリケーションが1つだけに興味を持っているとショーに合図するか、いくつかのキーストロークをケースに入れます。 したがって、アプリケーションがどんな刺激を必要とするかをユーザのインタフェースに指定するのにメカニズムが必要です。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
RFC 2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
RFC2119[1]は“MUST"、「必須NOT」が「必要である」というキーワードのための解釈を提供します、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが中にこのドキュメントを設立するべきであるかをさせましょう。
The Application Interaction Framework document [15] provides the interpretations for the terms "User Device", "SIP Application", and "User Input". This document uses the term "Application" and "Requesting Application" interchangeably with "SIP Application".
Application Interaction Frameworkドキュメント[15]は用語「ユーザデバイス」、「一口アプリケーション」、および「ユーザ入力」に解釈を提供します。 このドキュメントは「一口アプリケーション」と共に用語「アプリケーション」と互換性を持って「申込み書を要求します」を使用します。
Additionally, the Application Interaction Framework document discusses User Device Proxies. A common instantiation of a User Device Proxy is a Public Switched Telephone Network (PSTN) gateway. Because the normative behavior of a presentation-free User Interface is identical for a presentation-free SIP User Agent and a presentation-free User Device Proxy, this document uses "User Device" for both cases.
さらに、Application Interaction FrameworkドキュメントはUser Device Proxiesについて議論します。 User Device Proxyの一般的な具体化はPublic Switched Telephone Network(PSTN)ゲートウェイです。 無プレゼンテーションのSIP Userエージェントと無プレゼンテーションのUser Device Proxyに、無プレゼンテーションのUser Interfaceの標準の動きが同じであるので、このドキュメントは両方のケースに「ユーザデバイス」を使用します。
2. Protocol Overview
2. プロトコル概要
The "kpml" event package uses explicit subscription notification requests using the SIP SUBSCRIBE and NOTIFY methods. An Application that wants to collect digits creates an application/kpml-request+xml document with the digit patterns of interest to the Application and places this document in its SUBSCRIBE request. SIP SUBSCRIBE messages are routed to the User Interface using standard SIP request routing. KPML Subscriptions do not fork. The KPML request contained in the SUBSCRIBE message identifies the target media stream by referencing the dialog identifiers corresponding to the session responsible for the media stream. Once a subscription is established, the User Interface sends application/kpml-response+xml documents in NOTIFY requests when digits are collected or when timeouts or errors occur.
"kpml"イベントパッケージは、SIP SUBSCRIBEとNOTIFYメソッドを使用することで明白な購読通知要求を使用します。 ケタを集めたがっているApplicationが+ xmlドキュメントがケタでApplicationに興味があった状態で型に基づいて作って、このドキュメントを置くアプリケーション/kpml-要求を作成する、それ、登録、要求。 SIP SUBSCRIBEメッセージは、標準のSIP要求ルーティングを使用することでUser Interfaceに発送されます。 KPML Subscriptionsは分岐しません。 KPML要求が中に含んだ、登録、メッセージは、メディアストリームに原因となるセッションに対応する対話識別子に参照をつけることによって、目標メディアストリームを特定します。 購読がいったん確立されると、ケタが集められるか、またはタイムアウトか誤りが発生すると、User InterfaceはNOTIFY要求におけるアプリケーション/kpml-応答+xmlドキュメントを送ります。
A KPML subscription can be persistent or one-shot. Persistent requests are active until the subscription terminates, the Application replaces the request, the Application deletes the request by sending a null document on the dialog, or the Application explicitly deletes the subscription by sending a SUBSCRIBE with an expires value of zero (0).
KPML購読は、永続的であるか、または1回限りである場合があります。 購読が終わるまで永続的な要求が活発である、Applicationが要求を置き換えるか、Applicationがヌルドキュメントを対話に送ることによって要求を削除するか、またはApplicationが登録を送ることによって明らかに購読を削除する、(0)がない値を吐き出します。
Burger & Dolly Standards Track [Page 5] RFC 4730 KPML November 2006
バーガーと台車標準化過程[5ページ]RFC4730KPML2006年11月
One-shot requests terminate the subscription upon the receipt of DTMF values that provide a match. The "persist" KPML element specifies whether the subscription remains active for the duration specified in the SUBSCRIBE message or if it automatically terminates upon a pattern match.
1回限りの要求はマッチを提供するDTMF値の領収書で購読を終えます。 「固執してください」KPML要素が、購読が指定された持続時間にアクティブなままで残っているかどうか指定する、登録、通信してください。さもないと、自動的に終わるなら、パターンは合っています。
NOTIFY messages can contain XML documents. If the User Interface matches a digitmap, the NOTIFY message (response) contains an XML document that indicates the User Input detected and whether the User Interface suppressed the representation of User Input, such as tones, or RFC 2833, from the media streams. If the User Interface encountered an error condition, such as a timeout, this will also be reported.
NOTIFYメッセージはXMLドキュメントを含むことができます。 User Interfaceがdigitmapに合っているなら、NOTIFYメッセージ(応答)はUser Inputが検出したのを示すXMLドキュメントを含んでいます、そして、トーン、またはRFC2833などのように、User InterfaceがUser Inputの表現を抑圧したかどうかがメディアから流れます。また、User Interfaceがタイムアウトなどのエラー条件に遭遇したなら、これは報告されるでしょう。
3. Key Concepts
3. 重要な考え
3.1. Subscription Duration
3.1. 購読持続時間
KPML recognizes two types of subscriptions: one-shot and persistent. Persistent subscriptions have two sub-types: continuous notify and single-notify.
KPMLは2つのタイプの購読を認識します: 1回限りであって永続的です。 永続的な購読はサブタイプであるのに2を持っています: 連続、通知してください、そして、シングル通知してください。
One-shot subscriptions terminate after a pattern match occurs and a report is issued in a NOTIFY message. If the User Interface detects a key press stimulus that triggers a one-shot KPML event, then the User Interface (notifier) MUST set the "Subscription-State" in the NOTIFY message to "terminated". At this point, the User Interface MUST consider the subscription expired.
パターンマッチが現れて、NOTIFYメッセージでレポートを発行した後に1回限りの購読は終わります。 User Interfaceが1回限りのKPMLイベントの引き金となる主要なプレス刺激を検出するなら、User Interface(notifier)は「終えられること」へのNOTIFYメッセージに「購読状態」をはめ込まなければなりません。 ここに、User Interfaceは、購読が期限が切れたと考えなければなりません。
Persistent subscriptions remain active at the User Interface, even after a match. For continuous-notify persistent subscriptions, the User Interface will emit a NOTIFY message whenever the User Input matches a subscribed pattern. For single-notify persistent subscriptions, the user device will emit a NOTIFY message at the first match, but will not emit further NOTIFY messages until the Application issues a new subscription request on the subscription dialog.
永続的な購読はUser Interfaceにおいて、試合の後にさえアクティブなままで残っています。 連続、-通知してください、永続的な購読であり、User Inputが申し込まれたパターンに合っているときはいつも、User InterfaceはNOTIFYメッセージを放つでしょう。 シングル通知している永続的な購読のために、ユーザデバイスは、初戦のときにNOTIFYメッセージを放ちますが、Applicationが購読対話に関する新規申込み要求を出すまで、さらなるNOTIFYメッセージは放たないでしょう。
NOTE: The single-notify persistent subscription enables lock-step
(race-free) quarantining of User Input between different digit
maps.
以下に注意してください。 シングル通知している永続的な購読は異なったケタ地図の間でUser Inputの堅苦しい(レースなしの)検疫を可能にします。
The "persist" attribute to the <pattern> tag in the KPML subscription body affects the lifetime of the subscription.
KPML購読ボディーの<パターン>タグへの「固執してください」という属性は購読の生涯に影響します。
If the "persist" attribute is "one-shot", then once there is a match (or no match is possible), the subscription ends after the User Interface notifies the Application.
「固執してください」という属性が「1回限りである」なら、マッチがいったんあると(どんなマッチも可能ではありません)、User InterfaceがApplicationに通知した後に購読は終わります。
Burger & Dolly Standards Track [Page 6] RFC 4730 KPML November 2006
バーガーと台車標準化過程[6ページ]RFC4730KPML2006年11月
If the "persist" attribute is "persist" or "single-notify", then the subscription ends when the Application explicitly ends it or the User Interface terminates the subscription.
「固執してください」という属性が「固執してください」か「シングル通知してください」であるなら、Applicationがそれを明らかに終わらせると、購読が終わるか、またはUser Interfaceは購読を終えます。
If the User Interface does not support persistent subscriptions, it returns a NOTIFY message with the KPML status code set to 531. If there are digits in the buffer and the digits match an expression in the SUBSCRIBE filter, the User Interface prepares the appropriate NOTIFY response message.
User Interfaceが永続的な購読をサポートしないなら、それはKPML状態コードセットがあるNOTIFYメッセージを531に返します。 バッファでケタがあるか、そして、ケタが式に合っている、登録、フィルタ、User Interfaceは適切なNOTIFY応答メッセージを準備します。
The values of the "persist" attribute are case sensitive.
「固執してください」という属性の値は大文字と小文字を区別しています。
3.2. Timers
3.2. タイマ
To address the various key press collection scenarios, three timers are defined. They are the extra, critical, and inter-digit timers.
様々な主要なプレス収集シナリオを扱うために、3個のタイマが定義されます。 それらは重要なエキストラであり、趾間部はタイマです。
o The inter-digit timer is the maximum time to wait between digits.
Note: unlike Media Gateway Control Protocol (MGCP) [11] or H.248
[12], there is no start timer, as that concept does not apply in
the KPML context.
o 趾間部タイマはケタの間で待つ最大の時間です。 以下に注意してください。 メディアゲートウェイControlプロトコル(MGCP)[11]かH.248[12]と異なって、スタートタイマが全くありません、その概念がKPML文脈で適用されないとき。
o The critical timer is the time to wait for another digit if the
collected digits can match more than one potential pattern.
o 集まっているケタが1つ以上の潜在的パターンに合うことができるなら、重要なタイマはもう1ケタを待つ時間です。
o The extra timer is the time to wait for another digit if the
collected digits can only match one potential pattern, but a
longer match for this pattern is possible.
o 集まっているケタが1つの潜在的パターンしか合うことができないなら、付加的なタイマはもう1ケタを待つ時間ですが、このパターンのための、より長いマッチは可能です。
The User Interface MAY support an inter-digit timeout value. This is the amount of time the User Interface will wait for User Input before returning a timeout error result on a partially matched pattern. The application can specify the inter-digit timeout as an integer number of milliseconds by using the "interdigittimer" attribute to the <pattern> tag. The default is 4000 milliseconds. If the User Interface does not support the specification of an inter-digit timeout, the User Interface MUST silently ignore the specification. If the User Interface supports the specification of an inter-digit timeout, but not to the granularity specified by the value presented, the User Interface MUST round up the requested value to the closest value it can support.
User Interfaceは、趾間部タイムアウトが値であるとサポートするかもしれません。 これは部分的に取り組んでいるパターンのタイムアウト誤り結果を返す前にUser InterfaceがUser Inputを待っている時間です。 アプリケーションは、ミリセカンドの整数として<パターン>タグに"interdigittimer"属性を使用することによって、趾間部タイムアウトを指定できます。 デフォルトは4000ミリセカンドです。 User Interfaceが趾間部タイムアウトの仕様をサポートしないなら、User Interfaceは静かに仕様を無視しなければなりません。 User Interfaceが趾間部タイムアウトの仕様をサポートしますが、提示された値によって指定された粒状にサポートするというわけではないなら、User Interfaceは要求でサポートすることができる中で最も近い値に値を四捨五入しなければなりません。
The purpose of the inter-digit timeout is to protect applications from starting to match a pattern, yet never returning a result. This can occur, for example, if the user accidentally enters a key that begins to match a pattern. However, since the user accidentally entered the key, the rest of the pattern never comes. Moreover, when the user does enter a pattern, since they have already entered a key,
趾間部タイムアウトの目的はパターンを合わせ始めるのからアプリケーションを保護することです、まだ結果を決して返していなくて。 例えば、ユーザが偶然パターンに合い始めるキーを入れるなら、これは起こることができます。 しかしながら、ユーザが偶然キーを入れたので、パターンの残りは決して来ません。 そのうえ、ユーザが入るときには、彼らが既にキーを入れたので、パターンに入ってください。
Burger & Dolly Standards Track [Page 7] RFC 4730 KPML November 2006
バーガーと台車標準化過程[7ページ]RFC4730KPML2006年11月
the pattern may not match or may not match as expected. Likewise, consider the case where the user thinks they entered a key press, but the User Interface does not detect the key. This could occur when collecting ten digits, but the device actually only receives 9. In this case, the User Interface will wait forever for the tenth key press, while the user becomes frustrated wondering why the application is not responding.
パターンは、合っていないか、予想されるように合わないかもしれません。 同様に、ユーザが、彼らが主要なプレスに入ったと考えますが、User Interfaceがキーを検出しないケースを考えてください。 10ケタを集めるとき、これは起こることができましたが、デバイスは実際に9しか受け取りません。 この場合、User Interfaceはいつまでも10番目の主要なプレスを待っています、アプリケーションがなぜ反応していないかと思いながら、ユーザはだめにされるようになりますが。
The User Interface MAY support a critical-digit timeout value. This is the amount of time the User Interface will wait for another key press when it already has a matched <regex> but there is another, longer <regex> that may also match the pattern. The application can specify the critical-digit timeout as an integer number of milliseconds by using the "criticaldigittimer" attribute to the <pattern> tag. The default is 1000 milliseconds.
User Interfaceは、重要なケタがタイムアウト値であるとサポートするかもしれません。 これは既に取り組んでいる<regex>を持つUser Interfaceが別の主要なプレスを待っている時間ですが、別のもの(また、パターンに合うかもしれないより長い<regex>)があります。 アプリケーションは、ミリセカンドの整数として<パターン>タグに"criticaldigittimer"属性を使用することによって、重要なケタタイムアウトを指定できます。 デフォルトは1000ミリセカンドです。
The purpose of the critical-digit timeout is to allow the application to collect longer matches than the shortest presented. This is unlike MGCP [11], where the shortest match gets returned. For example, if the application registers for the patterns "0011", "011", "00", and "0", the critical-digit timeout enables the User Interface to distinguish between "0", "00", "011", and "0011". Without this feature, the only value that the User Interface can detect is "0".
重要なケタタイムアウトの目的はアプリケーションが最も短いのが提示したより長いマッチを集めるのを許容することです。 これはMGCP[11]と異なっています。そこでは、返されます中でマッチ最も短い。 アプリケーションが例えばパターンに登録する、「11インチ、「11インチ、「0インチ、「何0インチも、重要なケタタイムアウトが、ユーザーインタフェースが見分けるのを可能にする、「0インチ、「0インチ、「11インチ、および「11インチ。」 この特徴がなければ、User Interfaceが検出できる唯一の値が「0インチ」です。
The User Interface MAY support an extra-digit timeout value. This is the amount of time the User Interface will wait for another key press when it already has matched the longest <regex>. The application can specify the extra-digit timeout as an integer number of milliseconds by using the "extradigittimer" attribute to the <pattern> tag. The default is 500 milliseconds. If there is no enterkey specified, then the User Interface MAY default the exteradigittimer to zero.
User Interfaceは、付加的なケタがタイムアウト値であるとサポートするかもしれません。 これは既に最も長い<regex>を合わせたUser Interfaceが別の主要なプレスを待っている時間です。 アプリケーションは、ミリセカンドの整数として<パターン>タグに"extradigittimer"属性を使用することによって、付加的なケタタイムアウトを指定できます。 デフォルトは500ミリセカンドです。 あれば、enterkeyは全く指定しないで、次に、User Interface5月のデフォルトはゼロへのexteradigittimerです。
The purpose of the extra-digit timeout is to allow the User Interface to collect the enterkey. Without this feature, the User Interface would match the pattern, and the enterkey would be buffered and returned as the next pattern.
付加的なケタタイムアウトの目的はUser Interfaceがenterkeyを集めるのを許容することです。 この特徴がなければ、User Interfaceがパターンに合っていて、次のパターンとしてenterkeyをバッファリングして、返すでしょう。
3.3. Pattern Matches
3.3. パターンマッチ
During the subscription lifetime, the User Interface may detect a key press stimulus that triggers a KPML event. In this case, the User Interface (notifier) MUST return the appropriate KPML document.
購読生涯、User InterfaceはKPMLイベントの引き金となる主要なプレス刺激を検出するかもしれません。 この場合、User Interface(notifier)は適切なKPMLドキュメントを返さなければなりません。
The pattern matching logic works as follows. KPML User Interfaces MUST follow the logic presented in this section so that different implementations will perform deterministically on the same KPML document given the same User Input.
パターン・マッチング論理は以下の通り働いています。 KPML User Interfacesは同じUser Inputを考えて、異なった実装が決定論的に同じKPMLドキュメントに働くようにこのセクションに提示された論理に従わなければなりません。
Burger & Dolly Standards Track [Page 8] RFC 4730 KPML November 2006
バーガーと台車標準化過程[8ページ]RFC4730KPML2006年11月
A kpml request document contains a <pattern> element with a series of <regex> tags. Each <regex> element specifies a potential pattern for the User Interface to match. The Section 5.1 describes the DRegex, or digit regular expression, language.
kpml要求ドキュメントは一連の<regex>タグがある<パターン>要素を含んでいます。 User Interfaceが合うように、それぞれの<regex>要素は潜在的パターンを指定します。 セクション5.1はDRegex、またはケタ正規表現、言語を説明します。
The pattern match algorithm matches the longest regular expression. This is the same mode as H.248.1 [12] and not the mode presented by MGCP [11]. The pattern match algorithm choice has an impact on determining when a pattern matches. Consider the following KPML document.
パターンマッチアルゴリズムは最も長い正規表現に合っています。 これはMGCP[11]によって提示されたモードではなく、H.248.1[12]と同じモードです。 パターンマッチアルゴリズム選択には、パターンがいつ合っているかを決定するとき、影響力があります。 以下のKPMLドキュメントを考えてください。
<?xml version="1.0" encoding="UTF-8"?>
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
version="1.0">
<pattern>
<regex>0</regex>
<regex>011</regex>
</pattern>
</kpml-request>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><kpml-要求xmlnsは「つぼ:ietf:params:xml:ナノ秒: kpml要求」xmlnsと等しいです: xsiは" http://www.w3.org/2001/XMLSchema-instance "xsiと等しいです: schemaLocationは「1インチの><パターン><regex>0</regex><regex>011</regex></パターン></kpml-要求>」という「つぼ:ietf:params:xml:ナノ秒: kpml-要求kpml-request.xsd」バージョン=と等しいです。
Figure 1: Greedy Matching
図1: 貪欲なマッチング
In Figure 1, if we were to match on the first found pattern, the string "011" would never match. This happens because the "0" rule would match first.
図1 ストリングでは、私たちがパターンが見つけられた1日に合わせるつもりであったなら「11インチは決して合っていません」。 これが起こる、「規則が最初に合っている0インチ。」
While this behavior is what most applications desire, it does come at a cost. Consider the following KPML document snippet.
この振舞いはほとんどのアプリケーションが望んでいることですが、それは費用で来ます。 以下のKPMLドキュメント切れ端を考えてください。
<regex>x{7}</regex>
<regex>x{10}</regex>
<regex>x7</regex><regex>x10</regex>。
Figure 2: Timeout Matching
図2: タイムアウトマッチング
Figure 2 shows a typical North American dial plan. From an application perspective, users expect a seven-digit number to respond quickly, not waiting the typical inter-digit critical timer (usually four seconds). Conversely, the user does not want the system to cut off their ten-digit number at seven digits because they did not enter the number fast enough.
図2は典型的な北米のダイヤルプランを示しています。 アプリケーション見解から、ユーザは典型的な趾間部を待っているのではなく、すばやく応じるためには7桁数の重要なタイマ(通常4秒)を予想します。 逆に、それらが十分速く数を入れなかったので、ユーザは、システムに7ケタでそれらの10桁数を断ち切って欲しくはありません。
One approach to this problem is to have an explicit dial string terminator. Often, it is the pound key (#). Now, consider the following snippet.
この問題への1つのアプローチは明白なダイヤルストリングターミネータを持つことです。 しばしば、それはポンドキー(#)です。 今度は、以下の切れ端を考えてください。
Burger & Dolly Standards Track [Page 9] RFC 4730 KPML November 2006
バーガーと台車標準化過程[9ページ]RFC4730KPML2006年11月
<regex>x{7}#</regex>
<regex>x{10}#</regex>
<regex>x7#</regex><regex>x10#</regex>。
Figure 3: Timeout Matching with Enter
図3: タイムアウト、合う、入る。
The problem with the approach in Figure 3 is that the "#" will appear
in the returned dial string. Moreover, one often wants to allow the
user to enter the string without the dial string termination key. In
addition, using explicit matching on the key means one has to double
the number of patterns, e.g., "x{7}", "x{7}#", "x{10}", and "x{10}#".
図3におけるアプローチに関する問題は「#」が返されたダイヤルストリングに現れるということです。 そのうえ、人は、しばしばユーザがダイヤルストリング終了キーなしでストリングに入るのを許可したがっています。 さらに、キーの上に明白なマッチングを使用するのは、1つがパターンの数、例えば、「x7」、「x7#」、「x10」、および「x10#」を倍にしなければならないことを意味します。
The approach used in KPML is to have an explicit "Enter Key", as shown in the following snippet.
KPMLで使用されるアプローチは以下の切れ端に示されるように明白な「エンターキー」を持つことです。
<pattern enterkey="#">
<regex>x{7}</regex>
<regex>x{10}</regex>
</pattern>
「<パターンenterkey=」#「><regex>x7</regex><regex>x10</regex></パターン>」
Figure 4: Timeout Matching with Enter Key
図4: エンターキーに合わせるタイムアウト
In Figure 4, the enterkey attribute to the <pattern> tag specifies a string that terminates a pattern. In this situation, if the user enters seven digits followed by the "#" key, the pattern matches (or fails) immediately. KPML indicates a terminated nomatch with a KPML status code 402.
図4では、<パターン>タグへのenterkey属性はパターンを終えるストリングを指定します。 この状況で、ユーザが「#」キーが支えた7ケタを入れるなら、パターンはすぐに、合っています(または、失敗します)。 KPMLはKPMLステータスコード402で終えられたnomatchを示します。
NOTE: The enterkey is a string. The enterkey can be a sequence of
key presses, such as "**".
以下に注意してください。 enterkeyはストリングです。 「enterkeyは」 **などの主要なプレスの系列であるかもしれません。」
Some patterns look for long-duration key presses. For example, some applications look for long "#" or long "*".
いくつかのパターンが長い持続時間の主要なプレスを探します。 例えば、いくつかのアプリケーションが長い「#」か長い「*」を探します。
KPML uses the "L" modifier to <regex> characters to indicate long key presses. The following KPML document looks for a long pound of at least 3 seconds.
KPMLは、長い主要なプレスを示すのに<regex>キャラクタに「L」修飾語を使用します。 以下のKPMLドキュメントは少なくとも3秒の長いポンドを探します。
Burger & Dolly Standards Track [Page 10] RFC 4730 KPML November 2006
バーガーと台車標準化過程[10ページ]RFC4730KPML2006年11月
<?xml version="1.0" encoding="UTF-8"?>
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
version="1.0">
<pattern long="3000">
<regex>L#</regex>
</pattern>
</kpml-request>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><kpml-要求xmlnsは「つぼ:ietf:params:xml:ナノ秒: kpml要求」xmlnsと等しいです: xsiは" http://www.w3.org/2001/XMLSchema-instance "xsiと等しいです: schemaLocationは「1インチの>の<のパターンの長い=」3000「><regex>L#</regex>パターン></kpml</要求>」という「つぼ:ietf:params:xml:ナノ秒: kpml-要求kpml-request.xsd」バージョン=と等しいです。
Long Pound
長い間、ついてください。
The request can specify what constitutes "long" by setting the long attribute to the <pattern>. This attribute is an integer representing the number of milliseconds. If the user presses a key for longer than "long" milliseconds, the Long modifier is true. The default length of the long attribute is 2500 milliseconds.
要求は「長い間に」設定で<パターン>に長い属性を構成することを指定できます。 この属性はミリセカンドの数を表す整数です。 ユーザが「長い」ミリセカンドより長い間キーを押すなら、Long修飾語は正しいです。 長い属性の省略時の長さは2500ミリセカンドです。
User Interfaces MUST distinguish between long and short input when the KPML document specifies both in a document. However, if there is not a corresponding long key press pattern in a document, the User Interface MUST match the key press pattern irrespective of the length of time the user presses the key.
KPMLドキュメントがドキュメントで両方を指定するとき、ユーザInterfacesは長くて短い入力を見分けなければなりません。 しかしながら、ドキュメントに対応する長い主要なプレスパターンがなければ、User Interfaceはユーザがキーを押す時の長さの如何にかかわらず主要なプレスパターンに合わなければなりません。
As an example, in the following snippet in Figure 6, the User Interface discriminates between a long "*" and a normal "*", but any length "#" will match the pattern.
例として、図6の以下の切れ端では、User Interfaceは長い「*」と正常な「*」を区別しますが、どんな長さの「#」もパターンに合うでしょう。
<pattern>
<regex tag="short_star">*</regex>
<regex tag="long_star">L*</regex>
<regex>#</regex>
</pattern>
<パターン><regexタグ=、「_星の「>*</regex><regexタグ=」長い_星の「>L*</regex><regex>#</regex></パターン>」をショートしてください。
Figure 6: Long and Short Matching
図6: 長くて短いマッチング
Some User Interfaces are unable to present long key presses. An example is an old private branch exchange (PBX) phone set that emits fixed-length tones when the user presses a key. To address this issue, the User Interface MAY interpret a succession of presses of a single key to be equivalent to a long key press of the same key. The Application indicates it wants this behavior by setting the "longrepeat" attribute to the <pattern> to "true".
いくつかのUser Interfacesは長い主要なプレスを贈ることができません。 例はユーザがキーを押すとき固定長トーンを放つ古い構内交換機(PBX)電話セットです。 この問題を扱うなら、User Interfaceは、同じキーの長い主要なプレスに相当しているように単一のキーのプレスの流れを解釈するかもしれません。 Applicationは、"longrepeat"属性を<パターン>に設定することによって「本当に」この振舞いが欲しいのを示します。
The KPML document specifies if the patterns are to be persistent by setting the "persist" attribute to the <pattern> tag to "persist" or "single-notify". Any other value, including "one-shot", indicates
KPMLドキュメントは、パターンが「固執している」か、または「シングル通知する」ために<パターン>タグに「固執してください」という属性を設定することによって永続的であるかどうかことであると指定します。 「1回限り包含すること」の値が示すいかなる他のも
Burger & Dolly Standards Track [Page 11] RFC 4730 KPML November 2006
バーガーと台車標準化過程[11ページ]RFC4730KPML2006年11月
the request is a one-shot subscription. If the User Interface does not support persistent subscriptions, it returns a KPML document with the KPML status code set to 531. If there are digits in the buffer and the digits match an expression in the KPML document, the User Interface emits the appropriate kpml notification.
要求は1回限りの購読です。 User Interfaceが永続的な購読をサポートしないなら、それはKPML状態コードセットがあるKPMLドキュメントを531に返します。 バッファにはケタがあって、ケタがKPMLドキュメントの式に合っているなら、User Interfaceは適切なkpml通知を放ちます。
Note the values of the "persist" attribute are case sensitive.
「固執してください」という属性の値が大文字と小文字を区別していることに注意してください。
Some User Interfaces may support multiple regular expressions in a given pattern request. In this situation, the application may wish to know which pattern triggered the event.
いくつかのUser Interfacesが与えられたパターン要求における複数の正規表現をサポートするかもしれません。 この状況で、アプリケーションは、どのパターンがイベントの引き金となったかを知りたがっているかもしれません。
KPML provides a "tag" attribute to the <regex> tag. The "tag" is an opaque string that the User Interface sends back in the notification report upon a match in the digit map. In the case of multiple matches, the User Interface MUST choose the longest match in the KPML document. If multiple matches match the same length, the User Interface MUST choose the first expression listed in the subscription KPML document based on KPML document order.
KPMLは「タグ」属性を<regex>タグに供給します。 「タグ」はUser Interfaceがケタ地図のマッチに関する通知レポートで返送する不透明なストリングです。 複数のマッチの場合では、User InterfaceはKPMLドキュメントで最も長いマッチを選ばなければなりません。 複数のマッチが同じ長さに合っているなら、User InterfaceはKPMLドキュメントオーダーに基づく購読KPMLドキュメントに記載された最初の式を選ばなければなりません。
If the User Interface cannot support multiple regular expressions in a pattern request, the User Interface MUST return a KPML document with the KPML status code set to 532. If the User Interface cannot support the number of regular expressions in the pattern request, the User Interface MUST return a KPML document with the KPML status code set to 534.
User Interfaceがパターン要求における複数の正規表現をサポートすることができないなら、User InterfaceはKPML状態コードセットがあるKPMLドキュメントを532に返さなければなりません。 User Interfaceがパターン要求における、正規表現の数をサポートすることができないなら、User InterfaceはKPML状態コードセットがあるKPMLドキュメントを534に返さなければなりません。
NOTE: We could mandate a minimum number of regular expressions
that a User Interface must support per subscription request and
globally. However, such minimums tend to become designed-in,
hard-coded limits. For guidance, one should be able to easily
handle tens of expressions per subscription and thousands
globally. A good implementation should have effectively no
limits. That said, to counter possible denial-of-service attacks,
implementers of User Interfaces should be aware of the 534 and 501
status codes and feel free to use them.
以下に注意してください。 私たちはUser Interfaceがサポートするのと購読要求あたりグローバルにそうしなければならない最小の数の正規表現を強制できました。 しかしながら、そのような最小限は、設計されたコネの、そして、一生懸命コード化された限界になる傾向があります。 指導において、1購読あたりの式と10の数千をグローバルに容易に扱うことができるべきです。 事実上、良い実装は際限があるべきではありません。 それが可能なサービス不能攻撃に対抗するために言って、User Interfacesのimplementersは534と501のステータスコードを意識していて、遠慮なくそれらを使用するはずです。
3.4. Digit Suppression
3.4. ケタ抑圧
Under basic operation, a KPML User Interface will transmit in-band tones (RFC 2833 [10] or actual tone) in parallel with User Input reporting.
基本的な操作で、KPML User InterfaceはUser Input報告と平行してバンドにおけるトーン(RFC2833[10]か実際のトーン)を伝えるでしょう。
NOTE: If KPML did not have this behavior, then a User Interface
executing KPML could easily break called applications. For
example, take a personal assistant that uses "*9" for attention.
If the user presses the "*" key, KPML will hold the digit, looking
for the "9". What if the user just enters a "*" key, possibly
以下に注意してください。 KPMLにこの振舞いがないなら、KPMLを実行するUser Interfaceは容易に呼ばれたアプリケーションを破ることができるでしょうに。 注意のための「例えば、それが使用する個人秘書を連れて行ってください」という*9インチ。 ユーザが「*」キーを押すと、「9インチ」を探して、KPMLはケタを保持するでしょう。 ユーザがことによるとただ「*」キーを入れると、どうなるでしょうか?
Burger & Dolly Standards Track [Page 12] RFC 4730 KPML November 2006
バーガーと台車標準化過程[12ページ]RFC4730KPML2006年11月
because they accessed an interactive voice response (IVR) system
that looks for "*"? In this case, the "*" would get held by the
User Interface, because it is looking for the "*9" pattern. The
user would probably press the "*" key again, hoping that the
called IVR system just did not hear the key press. At that point,
the User Interface would send both "*" entries, as "**" does not
match "*9". However, that would not have the effect the user
intended when they pressed "*".
彼らが「*」を探す対話的な声の応答(IVR)システムにアクセスしたので? 「」 *9インチのパターンを探しているので、この場合、「*」はユーザーインタフェースによって保持されるでしょう。 ユーザはたぶん再び「*」キーを押すでしょう、呼ばれたIVRシステムが、キーが押されるのをただ聞かなかったことを望んでいて。 「その時、User Interfaceは」 **として両方の「*」エントリーを送るだろうこと」は」 *9インチに合っていません。 しかしながら、それには、彼らが「*」を押したとき、ユーザが意図した効果がないでしょう。
On the other hand, there are situations where passing through tones in-band is not desirable. Such situations include call centers that use in-band tone spills to initiate a transfer.
他方では、状況がバンドでトーンを通り抜けるのが望ましくないところにあります。 そのような状況は転送を起こすのにバンドのトーン流出を使用するコールセンターを含んでいます。
For those situations, KPML adds a suppression tag, "pre", to the <regex> tag. There MUST NOT be more than one <pre> tag in any given <regex> tag.
それらの状況のために、KPMLが抑圧タグを加える、「前、」、<regex>タグに。 1個以上の<の前>のタグがどんな与えられた<regex>タグにもあるはずがありません。
If there is only a single <pattern> and a single <regex>, suppression processing is straightforward. The end-point passes User Input until the stream matches the regular expression <pre>. At that point, the User Interface will continue collecting User Input, but will suppress the generation or pass-through of any in-band User Input.
単一の<パターン>と単一の<regex>しかなければ、抑圧処理は簡単です。 ストリームが正規表現<前>に合うまで、エンドポイントはUser Inputを渡します。 その時、User Interfaceは、User Inputを集め続けますが、バンドにおけるどんなUser Inputについても世代か通じて通るのを抑圧するでしょう。
If the User Interface suppressed stimulus, it MUST indicate this by including the attribute "suppressed" with a value of "true" in the notification.
User Interfaceが刺激を抑圧したなら、それは、通知で「本当」の値で「抑圧された」属性を含んでいることによって、これを示さなければなりません。
Clearly, if the User Interface is processing the KPML document against buffered User Input, it is too late to suppress the transmission of the User Input, as the User Interface has long sent the stimulus. This is a situation where there is a <pre> specification, but the "suppressed" attribute will not be "true" in the notification. If there is a <pre> tag that the User Interface matched and the User Interface is unable to suppress the User Input, it MUST set the "suppressed" attribute to "false".
明確に、User InterfaceがバッファリングされたUser Inputに対してKPML文書を処理しているなら、User Inputのトランスミッションを抑圧するのは遅過ぎます、User Interfaceが長い間刺激を送るとき。 これは<の前>の仕様がある状況ですが、「抑圧された」属性は通知で「本当でないでしょう」。 User Interfaceが合っていた<の前>のタグがあって、User InterfaceがUser Inputを抑圧できないなら、それは「抑圧された」属性を「誤っていること」に設定しなければなりません。
A KPML User Interface MAY perform suppression. If it is not capable of suppression, it ignores the suppression attribute. It MUST set the "suppressed" attribute to "false". In this case, the pattern to match is the concatenated pattern of pre+value.
KPML User Interfaceは抑圧を実行するかもしれません。 抑圧ができないなら、それは抑圧属性を無視します。 それは「抑圧された」属性を「誤っていること」に設定しなければなりません。 この場合、合わせるパターンは前+の価値の連結されたパターンです。
At some point in time, the User Interface will collect enough User Input to the point it matches a <pre> pattern. The interdigittimer attribute indicates how long to wait for the user to enter stimulus before reporting a time-out error. If the interdigittimer expires, the User Interface MUST issue a time-out report, transmit the suppressed User Input on the media stream, and stop suppression.
時間内にUser Interfaceが料金先方払いに肝心の十分なUser Inputを望んでいる何らかのポイントでは、それは<の前>のパターンに合っています。 interdigittimer属性はタイムアウト誤りを報告する前にユーザが刺激に入るのを長く待つ方法を示します。 interdigittimerが期限が切れるなら、User Interfaceはタイムアウトレポートを発行して、メディアストリームで抑圧されたUser Inputを伝えて、抑圧を止めなければなりません。
Burger & Dolly Standards Track [Page 13] RFC 4730 KPML November 2006
バーガーと台車標準化過程[13ページ]RFC4730KPML2006年11月
Once the User Interface detects a match and it sends a NOTIFY request to report the User Input, the User Interface MUST stop suppression. Clearly, if subsequent User Input matches another <pre> expression, then the User Interface MUST start suppression.
いったん、User Interfaceがマッチを検出して、それがUser Inputを報告するというNOTIFY要求を送ると、User Interfaceは抑圧を止めなければなりません。 明確に、その後のUser Inputが別の<の前>の式に合っているなら、User Interfaceは抑圧を始めなければなりません。
After suppression begins, it may become clear that a match will not occur. For example, take the expression
抑圧が始まった後に、マッチが現れないのは明確になるかもしれません。 例えば、式を取ってください。
<regex><pre>*8</pre>xxx[2-9]xxxxxx</regex>
<のregexの>の<の前>の*前8</>のxxx[2-9]xxxxxx</regex>。
At the point the User Interface receives "*8", it will stop forwarding stimulus. Let us say that the next three digits are "408". If the next digit is a zero or one, the pattern will not match.
「User Interfaceが受けるポイント」*8インチ、それは、刺激を進めるのを止めるでしょう。 次の3ケタが「408」であると言いましょう。 次のケタがゼロか1つであるなら、パターンは合わないでしょう。
NOTE: It is critically important for the User Interface to have a
sensible inter-digit timer. This is because an errant dot (".")
may suppress digit sending forever.
以下に注意してください。 User Interfaceには分別がある趾間部タイマがあるのは、批判的に重要です。 これがそうである、誤ったドット、(「」、)、いつまでも、ケタ発信を抑圧するかもしれません。
Applications should be very careful to indicate suppression only when they are fairly sure the user will enter a digit string that will match the regular expression. In addition, applications should deal with situations such as no-match or time-out. This is because the User Interface will hold digits, which will have obvious User Interface issues in the case of a failure.
アプリケーションはそれらがユーザが正規表現に合っているケタストリングに入るのをかなり確信しているときだけ、抑圧を示すのに非常に慎重であるはずです。 さらに、アプリケーションはいいえマッチかタイムアウトなどの状況に対処するべきです。 これはUser Interfaceがケタ(失敗の場合で明白なUser Interface問題を持つ)を保持するからです。
3.5. User Input Buffer Behavior
3.5. ユーザ入力バッファの振舞い
User Interfaces MUST buffer User Input upon receipt of an authenticated and accepted subscription. Subsequent KPML documents apply their patterns against the buffered User Input. Some applications use modal interfaces where the first few key presses determine what the following key presses mean. For a novice user, the application may play a prompt describing what mode the application is in. However, "power users" often barge through the prompt.
ユーザInterfacesは認証されて受け入れられた購読を受け取り次第User Inputをバッファリングしなければなりません。 その後のKPMLドキュメントはバッファリングされたUser Inputに対してそれらのパターンを当てはまります。 いくつかのアプリケーションがわずかな最初の主要なプレスが、以下の主要なプレスが何を意味するかを決定する様式のインタフェースを使用します。 初心者ユーザに関しては、アプリケーションはどんなモードにアプリケーションがあるかを説明するプロンプトをプレーするかもしれません。 しかしながら、「パワーユーザー」はプロンプトでしばしばはしけで運びます。
User Interfaces MUST NOT provide a subscriber with digits that were detected prior to the authentication and authorization of that subscriber. Without prohibition, a subscriber might be able to gain access to calling card or other information that predated the subscriber's participation in the call. Note that this prohibition MUST be applied on a per-subscription basis.
ユーザInterfacesはその加入者の認証と承認の前に検出されたケタを加入者に提供してはいけません。 禁止がなければ、加入者は呼び出しへの加入者の参加より前に起こったテレホンカードへのアクセスか他の情報を得ることができるかもしれません。 1購読あたり1個のベースでこの禁止を適用しなければならないことに注意してください。
KPML provides a <flush> tag in the <pattern> element. The default is not to flush User Input. Flushing User Input has the effect of ignoring key presses entered before the installation of the KPML subscription. To flush User Input, include the tag
KPMLは<の豊富な>タグを<パターン>要素に供給します。 デフォルトはUser Inputを洗い流さないことです。 User Inputを洗い流すのはKPML購読のインストールの前に主要なプレスを無視するという効果を入らせます。 User Inputを洗い流すには、タグを含めてください。
Burger & Dolly Standards Track [Page 14] RFC 4730 KPML November 2006
バーガーと台車標準化過程[14ページ]RFC4730KPML2006年11月
<flush>yes</flush> in the KPML subscription document. Note that this directive affects only the current subscription dialog/id combination.
KPML購読ドキュメントの<の豊富な>はい</水洗>。 この指示が現在の購読対話/イド組み合わせだけに影響することに注意してください。
Lock-step processing of User Input is where the User Interface issues a notification, the Application processes the notification while the User Interface buffers additional User Input, the Application requests more User Input, and only then does the User Interface notify the Application based on the collected User Input. To direct the User Interface to operate in lock-step mode, set the <pattern> attribute persist="single-notify".
User Inputの堅苦しい処理はUser Interfaceが通知書を発行するところです、そして、User Interfaceは追加User Inputをバッファリングしますが、Applicationは通知を処理します、そして、Applicationは、より多くのUser Inputを要求します、そして、次に、User Interfaceは集まっているUser Inputに基づくApplicationに通知するだけです。 堅苦しいモードで作動するようUser Interfaceに指示するには、>属性が固持する<パターン=「シングル通知してください」を設定してください。
The User Interface MUST be able to process <flush>no</flush>. This directive is effectively a no-op.
User Interfaceは</水洗の<の豊富な>ノー>を処理できなければなりません。 事実上、この指示はオプアートではありません。
Other string values for <flush> may be defined in the future. If the User Interface receives a string it does not understand, it MUST treat the string as a no-op.
<の豊富な>のための他のストリング値は将来、定義されるかもしれません。 User Interfaceがストリングを受けるなら、分からないで、どんなオプアートとしてもストリングを扱ってはいけません。
If the user presses a key that cannot match any pattern within a <regex> tag, the User Interface MUST discard all buffered key presses up to and including the current key press from consideration against the current or future KPML documents on a given dialog. However, as described above, once there is a match, the User Interface buffers any key presses the user entered subsequent to the match.
ユーザが<regex>タグの中のどんなパターンにも合うことができないキーを押すなら、User Interfaceは考慮からの現在の主要なプレスを含めて与えられた対話の現在の、または、将来のKPMLドキュメントに対してすべてのバッファリングされた主要なプレスを捨てなければなりません。 しかしながら、上で説明されるように、マッチがいったんあると、User Interfaceはマッチにその後でユーザが入れたどんな主要なプレスもバッファリングします。
NOTE: This behavior allows applications to receive only User Input
that is of interest to them. For example, a pre-paid application
only wishes to monitor for a long pound. If the user enters other
stimulus, presumably for other applications, the pre-paid
application does not want notification of that User Input. This
feature is fundamentally different than the behavior of Time
Division Multiplexer (TDM)-based equipment where every application
receives every key press.
以下に注意してください。 この振舞いで、アプリケーションはそれらに、興味深いUser Inputしか受け取ることができません。 例えば、あらかじめ支払われたアプリケーションはモニターに長いポンドを願っているだけです。 ユーザがおそらく他のアプリケーションのために他の刺激に入るなら、あらかじめ支払われたアプリケーションはそのUser Inputの通知を必要としません。 この特徴はあらゆるアプリケーションがあらゆる主要なプレスを受けるTimeの事業部のMultiplexerの(TDM)ベースの設備の動きと基本的に異なっています。
To limit reports to only complete matches, set the "nopartial" attribute to the <pattern> tag to "true". In this case, the User Interface attempts to match a rolling window over the collected User input.
レポートを完全なマッチだけに制限するには、「本当」への<パターン>タグに"nopartial"属性を設定してください。 この場合、User Interfaceは、集まっているUser入力の上に回転している窓を合わせるのを試みます。
KPML subscriptions are independent. Thus, it is not possible for the current document to know if a following document will enable barging or want User Input flushed. Therefore, the User Interface MUST buffer all User Input, subject to the forced_flush caveat described below.
KPML購読は独立しています。 したがって、現在のドキュメントには、次のドキュメントがはしけを可能にするか、またはUser Inputを洗い流して欲しくなるかを知るのは可能ではありません。 したがって、User Interfaceは以下で説明された_の無理矢理の水洗警告を条件としてすべてのUser Inputをバッファリングしなければなりません。
Burger & Dolly Standards Track [Page 15] RFC 4730 KPML November 2006
バーガーと台車標準化過程[15ページ]RFC4730KPML2006年11月
On a given SUBSCRIBE dialog with a given id, the User Interface MUST buffer all User Input detected between the time of the report and the receipt of the next document, if any. If the next document indicates a buffer flush, then the interpreter MUST flush all collected User Input from consideration from KPML documents received on that dialog with the given event id. If the next document does not indicate flushing the buffered User Input, then the interpreter MUST apply the collected User Input (if possible) against the digit maps presented by the script's <regex> tags. If there is a match, the interpreter MUST follow the procedures in Section 5.3. If there is no match, the interpreter MUST flush all of the collected User Input.
登録、当然のことのイドがある対話、User Interfaceがそうしなければならない当然のことでは、レポートの時間と次のドキュメントの領収書の間にもしあれば検出されたすべてのUser Inputをバッファリングしてください。 次のドキュメントが平らにバッファを示すなら、インタプリタは考慮からその対話に与えられたイベントイドで受け取られたKPMLドキュメントからすべての集まっているUser Inputを洗い流さなければなりません。 次のドキュメントが、バッファリングされたUser Inputを洗い流して、次に、インタプリタがスクリプトの<regex>タグによって提示されたケタ地図に対して集まっているUser Input(できれば)を適用しなければならないのを示さないなら。 マッチがあれば、インタプリタはセクション5.3で手順に従わなければなりません。 マッチが全くなければ、インタプリタは集まっているUser Inputのすべてを洗い流さなければなりません。
Given the potential for needing an infinite buffer for User Input, the User Interface MAY discard the oldest User Input from the buffer. If the User Interface discards digits, when the User Interface issues a KPML notification, it MUST set the forced_flush attribute of the <response> tag to "true". For future use, the Application MUST consider any non-null value, other than "false", that it does not understand to be the same as "true".
User Inputにおける無限のバッファを必要とする可能性を考えて、User Interfaceはバッファから最も古いUser Inputを捨てるかもしれません。 User InterfaceがKPML通知を発行するとき、User Interfaceがケタを捨てるなら、それは<応答>タグの_の無理矢理の水洗属性を「本当に」設定しなければなりません。 今後の使用のために、Applicationは「誤ること」を除いたそれが「本当」と同じであることを理解していない少しの非ヌル値も考えなければなりません。
NOTE: The requirement to buffer all User Input for the entire
length of the session is not onerous under normal operation. For
example, if one has a gateway with 8,000 sessions, and the gateway
buffers 50 key presses on each session, the requirement is only
400,000 bytes, assuming one byte per key press.
以下に注意してください。 セッションの全長のためのすべてのUser Inputをバッファリングするという要件は通常の操作で煩わしくはありません。 例えば、1つに8,000のセッションがあるゲートウェイ、および各セッションでのゲートウェイバッファ50キープレスがある場合にだけ、要件は40万バイトです、主要なプレスあたり1バイトを仮定して。
Unless there is a suppress indicator in the digit map, it is not possible to know if the User Input is for local KPML processing or for other recipients of the media stream. Thus, in the absence of a suppression indicator, the User Interface transmits the User Input to the far end in real time, using either RFC 2833, generating the appropriate tones, or both.
aがない場合、ケタ地図のインディケータを抑圧してください、そして、User Inputが地方のKPML処理か他の受取人のためのものであるかをメディアストリームを知るのは可能ではありません。 したがって、抑圧インディケータがないときUser InterfaceはリアルタイムでUser Inputを遠端に伝えます、RFC2833を使用して、適切なトーン、または両方を生成して。
3.6. DRegex
3.6. DRegex
3.6.1. Overview
3.6.1. 概要
This subsection is informative in nature.
この小区分は現実に有益です。
The Digit REGular EXpression (DRegex) syntax is a telephony-oriented mapping of POSIX Extended Regular Expressions (ERE) [13].
Digit REGular EXpression(DRegex)構文はPOSIX Extended Regular Expressions(ERE)[13]の電話指向のマッピングです。
KPML does not use full POSIX ERE for the following reasons.
KPMLは以下の理由に完全なPOSIX EREを使用しません。
o KPML will often run on high density or extremely low power and
memory footprint devices.
o KPMLはしばしば高密度の、または、非常に低いパワーとメモリーフットプリントデバイスで稼働するでしょう。
Burger & Dolly Standards Track [Page 16] RFC 4730 KPML November 2006
バーガーと台車標準化過程[16ページ]RFC4730KPML2006年11月
o Telephony application convention uses the star symbol ("*") for
the star key and "x" for any digit 0-9. Requiring the developer
to escape the star ("\*") and expand the "x" ("[0-9]") is error
prone. This also leads DRegex to use the dot (".") to indicate
repetition, which was the function of the unadorned star in POSIX
ERE.
o 電話アプリケーションコンベンションはどんなケタ0-9にも、星のキーと「x」の星のシンボル(「*」)を使用します。 開発者が星(「\*」)から逃げて、「x」("[0-9]")を広げるのが必要であることで、誤りは傾向がありますか? また、これが、DRegexがドットを使用するように導く、(「」、)、反復を示すために、どれに、POSIXでの簡素な星の機能はありましたか?
o Implementation experience with MGCP [11] and H.248.1 [12] has been
that implementers and users have a hard time understanding the
precedence of the alternation operator ("|"). This is due both to
an under-specification of the operator in those documents and
conceptual problems for users. Thus, the SIPPING Working Group
concluded that DRegex should not support alternation. That said,
each KPML <pattern> element may contain multiple regular
expressions (<regex> elements). Thus, it is straightforward to
have pattern alternatives (use multiple <regex> elements) without
the problems associated with the alternation operator ("|").
Thus, DRegex does not support the POSIX alternation operator.
o MGCP[11]とH.248.1[12]の実装経験がimplementersとユーザが、交互オペレータの先行を理解しているのに苦労するということである、(「|」、) ユーザにとってこれはそれらのオペレータの仕様のドキュメントと概念的な問題のためです。 したがって、SIPPING作業部会は、DRegexが交互をサポートするはずがないと結論を下しました。 それは言って、それぞれのKPML<パターン>要素は複数の正規表現(<regex>要素)を含むかもしれません。 したがって、交互オペレータに関連している問題なしでパターン代替手段(複数の<regex>要素を使用する)を持っているのが簡単である、(「|」、) したがって、DRegexはPOSIX交互オペレータをサポートしません。
o DRegex includes character classes (characters enclosed in square
brackets). However, the negation operator inside a character
class only operates on numbers. That is, a negation class
implicitly includes A-D, *, and #. Including A-D, *, and # in a
negation operator is a no-op. Those familiar with POSIX would
expect negation of the digits 4 and 5 (e.g., "[^45]") to include
all other characters (including A-D, R, *, and #), while those
familiar with telephony digit maps would expect negation to
implicitly exclude non-digit characters. Since the complete
character set of DRegex is very small, constructing a negation
class using A-D, R, *, and # requires the user to specify the
positive inverse mapping. For example, to specify all key
presses, including A-D and *, except #, the specification would be
"[0-9A-D*]" instead of "[^#R]".
o DRegexは文字クラス(角括弧で同封されたキャラクタ)を含んでいます。 しかしながら、文字クラスにおける否定オペレータは数を作動させるだけです。 すなわち、否定のクラスはそれとなくA-D、*、および#、を含んでいます。否定オペレータにA-D、*、および#、を含むのは、オプアートではありません。 POSIXになじみ深いものは、ケタ4と5(例えば、「[^45]」)の否定が他のすべてのキャラクタ(A-D、R、*、および#、を含んでいる)を含んでいると予想するでしょう、電話ケタ地図に詳しいものは、否定がそれとなく非ケタキャラクタを除くと予想するでしょうが。 DRegexの完全な文字集合が非常に小さいので、A-D、R、*、および#、を使用することで否定のクラスを構成するのは、ユーザが積極的な逆マッピング変換を指定するのを必要とします。 例えば、#、を除いて、A-Dと*を含むすべての主要なプレスを指定するために、仕様は「[^#R]」の代わりにあるでしょう「[0-9 1Dの*]」という。
The following table shows the mapping from DRegex to POSIX ERE.
以下のテーブルはDRegexからPOSIX EREまでマッピングを示しています。
+--------+-----------+
| DRegex | POSIX ERE |
+--------+-----------+
| * | \* |
| . | * |
| x | [0-9] |
| [xc] | [0-9c] |
+--------+-----------+
+--------+-----------+ | DRegex| POSIX| +--------+-----------+ | * | \* | | . | * | | x| [0-9] | | [xc]| [0-9c]| +--------+-----------+
Table 1: DRegex to POSIX ERE Mapping
テーブル1: マッピングの前のPOSIXへのDRegex
Burger & Dolly Standards Track [Page 17] RFC 4730 KPML November 2006
バーガーと台車標準化過程[17ページ]RFC4730KPML2006年11月
The first substitution, which replaces a star for an escaped star, is because telephony application designers are used to using the star for the (very common) star key. Requiring an escape sequence for this common pattern would be error prone. In addition, the usage found in DRegex is the same as found in MGCP [11] and H.248.1 [12].
最初の代替(逃げられた星のために星に取って代わる)は電話アプリケーション設計者が(非常に一般的)の星のキーに星を使用するのに慣れているからです。 この共通パターンのためにエスケープシーケンスを必要とするのは誤り傾向があるでしょう。 さらに、DRegexで見つけられた用法はMGCP[11]とH.248.1[12]で見つけられるのと同じです。
Likewise, the use of the dot instead of star is common usage from MGCP and H.248.1, and reusing the star in this context would also be confusing and error prone.
同様に、星の代わりにドットの使用はMGCPとH.248.1からの一般的な用法です、そして、また、混乱させるのと誤りは傾向があるなら、星を再利用するのはこのような関係においてはそのような用法でしょうに。
The "x" character is a common indicator of the digits 0 through 9. We use it here, continuing the convention. Clearly, for the case "[xc]", where c is any character, the substitution is not a blind replacement of "[0-9]" for "x", as that would result in "[[0-9]c]", which is not a legal POSIX ERE. Rather, the substitution for "[xc]" is "[0-9c]".
「x」キャラクタは0〜9にケタの一般的なインディケータです。 コンベンションを続けていて、私たちはここでそれを使用します。 明確に、どれに法的なPOSIXはそれが「[[0-9]c]」をもたらすように「[xc]」というケースのための、ものではありませんか?cがあらゆるキャラクタである、そこでは、代替は「x」のための"[0-9]"の盲目の交換ではありません。 むしろ、「[xc]」への代替は"[0-9c]"です。
NOTE: "x" does not include the characters *, #, R, or A through D.
以下に注意してください。 「x」はDを通してキャラクタ*、#、R、またはAを含んでいません。
Users need to take care not to confuse the DRegex syntax with POSIX EREs. They are NOT identical. In particular, there are many features of POSIX EREs that DRegex does not support.
ユーザは、DRegex構文をPOSIX EREsに間違えないように注意する必要があります。 それらは同じではありません。 特に、DRegexがサポートしないPOSIX EREsの多くの特徴があります。
As an implementation note, if one makes the substitutions described in the above table, then a standard POSIX ERE engine can parse the digit string. However, the mapping does not work in the reverse (POSIX ERE to DRegex) direction. DRegex only implements the normative behavior described below.
実装注意として、1つが上のテーブルで説明された代替をするなら、標準のPOSIX EREエンジンはケタストリングを分析できます。 しかしながら、マッピングは反対(DRegexへのPOSIX ERE)の方向に取り組みません。 DRegexは以下で説明された標準の振舞いを実装するだけです。
3.6.2. Operation
3.6.2. 操作
White space is removed before parsing DRegex. This enables sensible pretty printing in XML without affecting the meaning of the DRegex string.
DRegexを分析する前に、余白を取り除きます。 DRegexストリングの意味に影響しないで、これはXMLでの分別があるきれいな印刷を可能にします。
The following rules demonstrate the use of DRegex in KPML.
以下の規則はKPMLにおけるDRegexの使用を示します。
Burger & Dolly Standards Track [Page 18] RFC 4730 KPML November 2006
バーガーと台車標準化過程[18ページ]RFC4730KPML2006年11月
+---------+---------------------------------------------------------+
| Entity | Matches |
+---------+---------------------------------------------------------+
| c | digits 0-9, *, #, R, and A-D (case insensitive) |
| * | the * character |
| # | the # character |
| R | The R (Register Recall) key |
| [c] | Any character in selector |
| [^d] | Any digit (0-9) not in selector |
| [r1-r2] | Any character in range from r1 to r2, inclusive |
| x | Any digit 0-9 |
| {m} | m repetitions of previous pattern |
| {m,} | m or more repetitions of previous pattern |
| {,n} | At most n (including zero) repetitions of previous |
| | pattern |
| {m,n} | At least m and at most n repetitions of previous |
| | pattern |
| Lc | Match the character c if it is "long"; c is a digit 0-9 |
| | and A-D, #, or *. |
+---------+---------------------------------------------------------+
+---------+---------------------------------------------------------+ | 実体| マッチ| +---------+---------------------------------------------------------+ | c| ケタ0-9、*、#、R、およびA-D(大文字と小文字を区別しない)| | * | *キャラクタ| | # | #キャラクタ| | R| R(Recallを登録する)キー| | [c]| セレクタのどんなキャラクタ| | [^d]| セレクタでないところのどんなケタ(0-9)| | [r1-r2]| どんなキャラクタも中でr1からr2まで包括的に及びます。| | x| どんなケタ0-9| | m| 前の反復が型に基づいて作るm| | m| 前のパターンのmか、より多くの複写| | n| 高々前のn(ゼロを含んでいる)反復| | | パターン| | m、n| 前の少なくともmと高々n反復| | | パターン| | Lc| それが「長い」なら、キャラクタcを合わせてください。 cはケタ0-9です。| | | A-D、#、または*。| +---------+---------------------------------------------------------+
DRegex Entities
DRegex実体
For ranges, the A-D characters are disjoint from the 0-9 characters. If the device does not have an "R" key, the device MAY report a hook flash as an R character.
範囲に、A-Dキャラクタはそうです。0-9のキャラクタから、ばらばらになってください。 デバイスに「R」キーがないなら、デバイスはRキャラクタとしてフックフラッシュを報告するかもしれません。
+--------------+--------------------------------------------+
| Example | Description |
+--------------+--------------------------------------------+
| 1 | Matches the digit 1 |
| [179] | Matches 1, 7, or 9 |
| [2-9] | Matches 2, 3, 4, 5, 6, 7, 8, 9 |
| [^15] | Matches 0, 2, 3, 4, 6, 7, 8, 9 |
| [02-46-9A-D] | Matches 0, 2, 3, 4, 6, 7, 8, 9, A, B, C, D |
| x | Matches 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 |
| *6[179#] | Matches *61, *67, *69, or *6# |
| x{10} | Ten digits (0-9) |
| 011x{7,15} | 011 followed by seven to fifteen digits |
| L* | Long star |
+--------------+--------------------------------------------+
+--------------+--------------------------------------------+ | 例| 記述| +--------------+--------------------------------------------+ | 1 | ケタ1を合わせます。| | [179] | マッチ1、7、または9| | [2-9] | マッチ2、3、4、5、6、7、8、9| | [^15] | マッチ0、2、3、4、6、7、8、9| | [02-46-9A D]| マッチ0、2、3、4、6、7、8、9、A、B C、D| | x| マッチ0、1、2、3、4、5、6、7、8、9| | *6[179#] | マッチ*61、*67、*69、または*6#| | x10| 10ケタ(0-9)| | 011x7、15| 7〜15ケタに従って、011は続きました。| | L*| 長い間、主演してください。| +--------------+--------------------------------------------+
DRegex Examples
DRegexの例
Burger & Dolly Standards Track [Page 19] RFC 4730 KPML November 2006
バーガーと台車標準化過程[19ページ]RFC4730KPML2006年11月
3.7. Monitoring Direction
3.7. モニターしている方向
SIP identifies dialogs by their dialog identifier. The dialog identifier is the remote-tag, local-tag, and Call-ID entities defined in RFC 3261 [4].
SIPはそれらの対話識別子で対話を特定します。 対話識別子は、RFC3261[4]で定義されたリモートタグと、地方のタグと、Call-ID実体です。
One method of determining the dialog identifier, particularly for third-party applications, is the SIP Dialog Package [17].
特に第三者アプリケーションのために、対話識別子を決定する1つのメソッドがSIP Dialogパッケージ[17]です。
For most situations, such as a monaural point-to-point call with a single codec, the stream to monitor is obvious. In such situations the Application need not specify which stream to monitor.
単一のコーデックがあるモノラルの二地点間呼び出しなどのほとんどの状況において、モニターするストリームは明白です。 そのようなものでは、Applicationが必要とする状況は、どのストリームをモニターしたらよいかを指定しません。
But there may be ambiguity in specifying only the SIP dialog to monitor. The dialog may specify multiple SDP streams that could carry key press events. For example, a dialog may have multiple audio streams. Wherever possible, the User Interface MAY apply local policy to disambiguate which stream or streams to monitor. In order to have an extensible mechanism for identifying streams, the mechanism for specifying streams is as an element content to the <stream> tag. The only content defined today is the <stream>reverse</stream> tag.
しかし、モニターするSIP対話だけを指定するのにおいてあいまいさがあるかもしれません。 対話は主要な報道機関向けのイベントを運ぶことができた複数のSDPストリームを指定するかもしれません。 例えば、対話には、複数のオーディオストリームがあるかもしれません。どこでも、可能であるところに、User Interfaceはどのストリームのあいまいさを除くかローカルの方針かモニターするストリームを適用するかもしれません。 ストリームを特定するための広げることができるメカニズムを持つために、要素含有量として<ストリーム>タグにはストリームを指定するためのメカニズムがあります。 今日定義されている唯一の内容が<ストリーム>の逆の</ストリーム>タグです。
By default, the User Interface monitors key presses emanating from the User Interface. Given a dialog identifier of Call-ID, local-tag, and remote-tag, the User Interface monitors the key presses associated with the local-tag.
デフォルトで、User InterfaceはUser Interfaceから発する主要なプレスをモニターします。 Call-IDに関する対話識別子、地方のタグ、およびリモートタグを考えて、User Interfaceは地方のタグに関連している主要なプレスをモニターします。
In the media proxy case, and potentially other cases, there is a need to monitor the key presses arriving from the remote user agent. The optional <stream> element to the <request> tag specifies which stream to monitor. The only legal value is "reverse", which means to monitor the stream associated with the remote-tag. The User Interface MUST ignore other values.
メディアプロキシ事件と、潜在的に他のケース、リモート・ユーザーエージェントから届く主要なプレスをモニターする必要があります。 <要求>タグへの任意の<ストリーム>要素は、どのストリームをモニターしたらよいかを指定します。 唯一の正当な値が「逆である」(リモートタグに関連しているストリームをモニターすることを意味します)。 User Interfaceは他の値を無視しなければなりません。
NOTE: The reason this is a tag is so individual stream selection,
if needed, can be addressed in a backwards-compatible way.
Further specification of the stream to monitor is the subject of
future standardization.
以下に注意してください。 これがタグである理由は、必要であるなら後方にコンパチブル方法でストリーム選択を扱うことができるようにとても個々です。 モニターするストリームのさらなる仕様は今後の標準化の対象です。
3.8. Multiple Simultaneous Subscriptions
3.8. 複数の同時の購読
An Application MAY register multiple User Input patterns in a single KPML subscription. If the User Interface supports multiple, simultaneous KPML subscriptions, the Application installs the subscriptions either in a new SUBSCRIBE-initiated dialog or on an existing SUBSCRIBE-initiated dialog with a new event id tag. If the User Interface does not support multiple, simultaneous KPML
Applicationはただ一つのKPML購読における複数のUser Inputパターンを登録するかもしれません。 User Interfaceが複数の、そして、同時のKPML購読をサポートするなら、Applicationが購読をaに新しい状態でインストールする、登録、-、開始、対話か存在、登録、-、開始、新しいイベントイドタグがある対話。 User Interfaceが複数の、そして、同時のKPMLをサポートしないなら
Burger & Dolly Standards Track [Page 20] RFC 4730 KPML November 2006
バーガーと台車標準化過程[20ページ]RFC4730KPML2006年11月
subscriptions, the User Interface MUST respond with an appropriate KPML status code.
購読、User Interfaceは適切なKPMLステータスコードで応じなければなりません。
Some User Interfaces may support multiple key press event notification subscriptions at the same time. In this situation, the User Interface honors each subscription individually and independently.
いくつかのUser Interfacesが、同時に、複数の主要な報道機関向けのイベントが通知購読であるとサポートするかもしれません。 この状況をUser Interfaceは個別に独自に各購読を光栄に思います。
A SIP user agent may request multiple subscriptions on the same SUBSCRIBE dialog, using the id parameter to the kpml event request.
SIPユーザエージェントが同じくらいで複数の購読を要求するかもしれない、登録、kpmlイベント要求にイドパラメタを使用する対話。
One or more SIP user agents may request independent subscriptions on different SIP dialogs, although reusing the same dialog for multiple subscriptions is NOT RECOMMENDED.
1人以上のSIPユーザエージェントが異なったSIP対話で独立している購読を要求するかもしれません、複数の購読のために同じ対話を再利用するのは、NOT RECOMMENDEDですが。
If the User Interface does not support multiple, simultaneous subscriptions, the User Interface MUST return a KPML document with the KPML status code set to 533 on the dialog that requested the second subscription. The User Interface MUST NOT modify the state of the first subscription on account of the second subscription attempt.
User Interfaceが複数の、そして、同時の購読をサポートしないなら、User Interfaceは2番目の購読を要求した対話でKPML状態コードセットがあるKPMLドキュメントを533に返さなければなりません。 User Interfaceは2番目の購読試みのために最初の購読の状態を変更してはいけません。
4. Event Package Formal Definition
4. イベントパッケージ公式の定義
4.1. Event Package Name
4.1. イベントパッケージ名
This document defines a SIP Event Package as defined in RFC 3265 [5]. The event-package token name for this package is:
このドキュメントはRFC3265[5]で定義されるSIP Eventパッケージを定義します。 このパッケージのためのイベントパッケージトークン名は以下の通りです。
"kpml"
"kpml"
4.2. Event Package Parameters
4.2. イベントパッケージパラメタ
This package defines three Event Package parameters: call-id, remote- tag, and local-tag. These parameters MUST be present, to identify the subscription dialog. The User Interface matches the local-tag against the to tag, the remote-tag against the from tag, and the call-id against the Call-ID.
このパッケージは3つのEventパッケージパラメタを定義します: 呼び出しイド、リモートタグ、およびローカルのタグ。 これらのパラメタは、購読対話を特定するために存在していなければなりません。 User Interfaceが地方のタグに合っている、タグ、リモートタグ、タグ、およびCall-IDに対する呼び出しイドから。
The ABNF for these parameters is below. It refers to many constructions from the ABNF of RFC 3261, 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!
remote-tag = "remote-tag" EQUAL token
local-tag = "local-tag" EQUAL token
呼び出しイドは「呼び出しイド」EQUALと等しいです(トークン/DQUOTE callid DQUOTE)。 以下に注意してください。 callidの中のどんなDQUOTEsからも逃げなければなりません!リモートタグは「リモートタグ」EQUALトークン地方のタグ=「地方のタグ」EQUALトークンと等しいです。
Burger & Dolly Standards Track [Page 21] RFC 4730 KPML November 2006
バーガーと台車標準化過程[21ページ]RFC4730KPML2006年11月
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])から何人かのキャラクタを許容してください、("@"などのように「[「」、:、」、)、それはトークンの中に許容されていません。
4.3. SUBSCRIBE Bodies
4.3. ボディーを申し込んでください。
Applications using this event package include an application/ kpml-request+xml body in SUBSCRIBE requests to indicate which digit patterns they are interested in. The syntax of this body type is formally described in Section 5.2.
このイベントパッケージを使用するアプリケーションが中にアプリケーション/kpml-要求+xmlボディーを含んでいる、登録、それらがどのケタパターンに興味を持っているかを示すという要求。 このボディータイプの構文はセクション5.2で正式に説明されます。
4.4. Subscription Duration
4.4. 購読持続時間
The subscription lifetime should be longer than the expected call time. 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 7200 seconds.
購読寿命は予想された呼び出し時間より長いはずです。 このイベントパッケージの購読は数分から何週間も及ぶかもしれません。 何時間もの購読か何日も、より典型的であり、RECOMMENDEDです。 このイベントパッケージのためのデフォルト購読持続時間は7200秒です。
Subscribers MUST be able to handle the User Interface returning an
Expires value smaller than the requested value. Per RFC 3265 [5],
the subscription duration is the value returned by the Notifier in
the 200 OK Expires header.
加入者は、要求された値より小さい値をExpiresに返しながら、User Interfaceを扱うことができなければなりません。 RFC3265[5]あたり購読持続時間は200OK ExpiresヘッダーのNotifierによって返された値です。
4.5. NOTIFY Bodies
4.5. ボディーに通知してください。
NOTIFY requests can contain application/kpml-response+xml (KPML Response) bodies. The syntax of this body type is formally described in Section 5.3. NOTIFY requests in immediate response to a SUBSCRIBE request MUST NOT contain a body unless they are notifying the subscriber of an error condition or previously buffered digits.
NOTIFY要求はアプリケーション/kpml-応答+xml(KPML Response)ボディーを含むことができます。 このボディータイプの構文はセクション5.3で正式に説明されます。 NOTIFYは、登録への即時型反応で彼らがエラー条件か以前にバッファリングされたケタについて加入者に通知していない場合要求がボディーを含んではいけないよう要求します。
Notifiers MAY send notifications with any format acceptable to the subscriber (based on the subscriber's inclusion of these formats in an Accept header). 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.
Notifiersは加入者(Acceptヘッダーでの加入者のこれらの形式の包含に基づいている)にとって、許容しているどんな形式と共にも通告を送るかもしれません。 今後の拡大は他のNOTIFYボディーを定義するかもしれません。 いいえなら「受け入れてください」というヘッダーが出席している、登録、本書では定義されたボディータイプを思わなければなりません。
4.6. Subscriber Generation of SUBSCRIBE Requests
4.6. 加入者世代、要求を申し込んでください。
A kpml request document contains a <pattern> element with a series of <regex> tags. Each <regex> element specifies a potential pattern for the User Interface to match. Section 5.1 describes the DRegex, or digit regular expression, language.
kpml要求ドキュメントは一連の<regex>タグがある<パターン>要素を含んでいます。 User Interfaceが合うように、それぞれの<regex>要素は潜在的パターンを指定します。 セクション5.1はDRegex、またはケタ正規表現、言語を説明します。
Burger & Dolly Standards Track [Page 22] RFC 4730 KPML November 2006
バーガーと台車標準化過程[22ページ]RFC4730KPML2006年11月
KPML specifies key press event notification filters. The MIME type for KPML requests is application/kpml-request+xml.
KPMLは主要な報道機関向けのイベント通知フィルタを指定します。 KPML要求のためのMIMEの種類はアプリケーション/kpml-要求+xmlです。
The KPML request document MUST be well formed and SHOULD be valid. KPML documents MUST conform to XML 1.0 [14] and MUST use UTF-8 encoding.
ドキュメントが整形式であるに違いないというKPML要求とSHOULD、有効であってください。 KPMLドキュメントは、XML1.0[14]に従わなければならなくて、UTF-8コード化を使用しなければなりません。
Because of the potentially sensitive nature of the information reported by KPML, subscribers SHOULD use sips: and MAY use S/MIME on the content.
KPMLによって報告された情報の潜在的に敏感な本質のために、加入者SHOULD使用はちびちび飲まれます: そして、内容でS/MIMEを使用するかもしれません。
Subscribers MUST be prepared for the notifier to insist on authentication of the subscription request. Subscribers MUST be prepared for the notifier to insist on using a secure communication channel.
加入者はnotifierが購読要求の認証を主張する用意ができていなければなりません。 加入者はnotifierが、安全な通信チャネルを使用すると主張する用意ができていなければなりません。
4.7. Notifier Processing of SUBSCRIBE Requests
4.7. より多くのNotifierに処理する、要求を申し込んでください。
The user information transported by KPML is potentially sensitive. For example, it could include calling card or credit card numbers. Thus the User Interface (notifier) MUST authenticate the requesting party in some way before accepting the subscription.
KPMLによって輸送されたユーザー情報は潜在的に機密です。 例えば、それはテレホンカードかクレジットカード番号を含むかもしれません。 したがって、購読を受け入れる前に、User Interface(notifier)は何らかの方法で要求パーティーを認証しなければなりません。
User Interfaces MUST implement SIP Digest authentication as required by RFC 3261 [4] and MUST implement the sips: scheme and TLS.
ユーザInterfacesは必要に応じてRFC3261[4]でSIP Digestが認証であると実装しなければならなくて、一口を実装しなければなりません: 体系とTLS。
Upon authenticating the requesting party, the User Interface determines if the requesting party has authorization to monitor the user's key presses. The default authorization policy is to allow a KPML subscriber who can authenticate with a specific identity to monitor key presses from SIP sessions in which the same or equivalent authenticated identity is a participant. In addition, KPML will often be used, for example, between "application servers" (subscribers) and PSTN gateways (notifiers) operated by the same domain or federation of domains. In this situation a notifier MAY be configured with a list of subscribers which are specifically trusted and authorized to subscribe to key press information related to all sessions in a particular context.
要求パーティーを認証すると、User Interfaceは、ユーザの主要なプレスをモニターするために要求パーティーで承認があるかどうか決定します。 デフォルト承認方針は特定のアイデンティティで同じであるか同等な認証されたアイデンティティが関係者であるSIPセッションから監督用鍵機構にプレスを認証できるKPML加入者を許容することです。 さらに、例えば、KPMLは「アプリケーション・サーバー」(加入者)とドメインの同じドメインか連邦によって運用されたPSTNゲートウェイ(notifiers)の間でしばしば使用されるでしょう。 この状況で、notifierは応募者名簿によって構成されるかもしれません(特定の文脈ですべてのセッションに関連する主要な報道資料に加入するのが明確に信じられて、認可されます)。
The User Interface returns a Contact URI that may have GRUU [9] properties in the Contact header of a SIP INVITE, 1xx, or 2xx response.
User InterfaceはSIP INVITE、1xx、または2xx応答のContactヘッダーにGRUU[9]特性を持っているかもしれないContact URIを返します。
After authorizing the request, the User Interface checks to see if the request is to terminate a subscription. If the request will terminate the subscription, the User Interface does the appropriate processing, including the procedures described in Section 5.2.
要求を認可した後に、User Interfaceは、要求が購読を終えるかどうかことであることを確認するためにチェックします。 要求が購読を終えるなら、User Interfaceは適切な処理をします、セクション5.2で説明された手順を含んでいて。
Burger & Dolly Standards Track [Page 23] RFC 4730 KPML November 2006
バーガーと台車標準化過程[23ページ]RFC4730KPML2006年11月
If the request has no KPML body, then any KPML document running on that dialog and addressed by the event id, if present, immediately terminates. This is a mechanism for unloading a KPML document while keeping the SUBSCRIBE-initiated dialog active. This can be important for secure sessions that have high costs for session establishment. The User Interface follows the procedures described in Section 5.2.
要求にKPMLボディーが全くないなら、存在しているなら、その対話で動いて、イベントイドによって扱われたどんなKPMLドキュメントもすぐに、終わります。 これが保っている間、KPMLドキュメントを降ろすためのメカニズムである、登録、-、開始、対話アクティブです。 これはセッション設立に、高いコストを持っている安全なセッションのために重要である場合があります。 User Interfaceはセクション5.2で説明された手順に従います。
If the dialog referenced by the kpml subscription does not exist, the User Interface follows the procedures in Section 5.3. Note the User Interface MUST issue a 200 OK to the SUBSCRIBE request before issuing the NOTIFY, as the SUBSCRIBE itself is well formed.
kpml購読で参照をつけられる対話が存在していないなら、User Interfaceはセクション5.3で手順に従います。 User InterfaceがOKに200に支給しなければならないことに注意してください、登録、NOTIFYを発行する前の要求、登録、それ自体、整形式です。
If the request has a KPML body, the User Interface parses the KPML document. The User Interface SHOULD validate the XML document against the schema presented in Section 5.2. If the document is not valid, the User Interface rejects the SUBSCRIBE request with an appropriate error response and terminates the subscription. If there is a loaded KPML document on the subscription, the User Interface unloads the document.
要求にKPMLボディーがあるなら、User InterfaceはKPMLドキュメントを分析します。 User Interface SHOULDはセクション5.2に提示された図式に対してXMLドキュメントを有効にします。 ドキュメントは有効ではありません、User Interface廃棄物、登録、適切な誤りで応答を要求して、購読を終えます。 購読でのロードされたKPMLドキュメントがあれば、User Interfaceはドキュメントを降ろします。
In addition, if there is a loaded KPML document on the subscription, the end device unloads the document.
さらに、購読でのロードされたKPMLドキュメントがあれば、端末装置はドキュメントを降ろします。
Following the semantics of SUBSCRIBE, if the User Interface receives a resubscription, the User Interface MUST terminate the existing KPML request and replace it with the new request.
登録、User InterfaceのUser Interfaceが再購読を受けるなら意味論に従うと、KPMLが要求する存在が終えられて、それは新しい要求に取り替えられなければなりません。
It is possible for the INVITE usage of the dialog to terminate during key press collection. The cases enumerated here are explicit subscription termination, automatic subscription termination, and underlying (INVITE-initiated) dialog termination.
対話のINVITE用法が主要なプレス収集の間、終わるのは、可能です。 ここに数え上げられたケースは、明白な購読終了と、自動購読終了と、基本的な(INVITEによって開始された)対話終了です。
If a SUBSCRIBE request has an expires of zero (explicit SUBSCRIBE termination), includes a KPML document, and there is buffered User Input, then the User Interface attempts to process the buffered digits against the document. If there is a match, the User Interface MUST generate the appropriate KPML report with the KPML status code of 200. The SIP NOTIFY body terminates the subscription by setting the subscription state to "terminated" and a reason of "timeout".
要求が登録ならそうした、ゼロの期限が切れる、(明白である、登録、終了)、User Input(User Interfaceがドキュメントに対するバッファリングされたケタのプロセスに試みるその時)はKPMLドキュメントを含んで、バッファリングされます。 マッチがあれば、User Interfaceは200のKPMLステータスコードで適切なKPMLレポートを作らなければなりません。 SIP NOTIFYボディーは、「終えられること」への購読状態と「タイムアウト」の理由を設定することによって、購読を終えます。
If the SUBSCRIBE request has an expires of zero and no KPML body or the expires timer on the SUBSCRIBE-initiated dialog fires at the User Interface (notifier), then the User Interface MUST issue a KPML report with the KPML status code 487, Subscription Expired. The report also includes the User Input collected up to the time the expires timer expired or when the subscription with expires equal to zero was processed. This could be the null string.
または、登録、要求がそうした、ゼロの期限が切れますが、どんなKPMLボディーも期限が切れない、タイマを吐き出す、登録、-、開始、User Interface(notifier)の対話炎、次に、User InterfaceがKPMLステータスコード487でKPMLレポートを発行しなければなりません、Subscription Expired。 また、レポートが時間まで集められたUser Inputを含んでいる、タイマを吐き出す、吐き出されるか、購読である、期限が切れる、同輩はゼロに処理されました。 これはヌルストリングであるかもしれません。
Burger & Dolly Standards Track [Page 24] RFC 4730 KPML November 2006
バーガーと台車標準化過程[24ページ]RFC4730KPML2006年11月
Per the mechanisms of RFC 3265 [5], the User Interface MUST terminate the SIP SUBSCRIBE dialog. The User Interface does this via the SIP NOTIFY body transporting the final report described in the preceding paragraph. In particular, the subscription state will be "terminated" and a reason of "timeout".
RFC3265[5]のメカニズムに従って、User InterfaceはSIP SUBSCRIBE対話を終えなければなりません。 User Interfaceは、先行のパラグラフで説明された最終報告書を輸送しながら、SIP NOTIFYボディーを通してこれをします。 購読状態は、特に、「終えられ」て「タイムアウト」の理由になるでしょう。
Terminating the subscription when a dialog terminates ensures reauthorization (if necessary) for attaching to subsequent subscriptions.
対話が終わると購読を終えると、「再-承認」は、(必要なら、)その後の購読に付くために確実にされます。
If a SUBSCRIBE request references a dialog that is not present at the User Interface, the User Interface MUST generate a KPML report with the KPML status code 481, Dialog Not Found. The User Interface terminates the subscription by setting the subscription state to "terminated".
登録がUser Interface、User Interfaceに存在していない対話が要求しなければならない参照を要求するなら、KPMLステータスコード481でKPMLレポートを作ってください、Dialog Not Found。 User Interfaceは、「終えられること」に購読状態を設定することによって、購読を終えます。
If the KPML document is not valid, the User Interface generates a KPML report with the KPML status code 501, Bad Document. The User Interface terminates the subscription by setting the subscription state to "terminated".
KPMLドキュメントが有効でないなら、User InterfaceはKPMLステータスコード501でKPMLレポートを作ります、Bad Document。 User Interfaceは、「終えられること」に購読状態を設定することによって、購読を終えます。
If the document is valid but the User Interface does not support a namespace in the document, the User Interface MUST respond with a KPML status code 502, Namespace Not Supported.
ドキュメントが有効ですが、User Interfaceがドキュメントの名前空間をサポートしないなら、User InterfaceはKPMLステータスコード502で応じなければなりません、Namespace Not Supported。
4.8. Notifier Generation of NOTIFY Requests
4.8. Notifier世代、要求に通知してください。
Immediately after a subscription is accepted, the Notifier MUST send a NOTIFY with the current location information as appropriate based on the identity of the subscriber. This allows the Subscriber to resynchronize its state.
購読を受け入れる直後、Notifierは適宜加入者のアイデンティティに基づく現在の位置情報があるNOTIFYを送らなければなりません。 これで、Subscriberは状態を再連動させることができます。
The User Interface (notifier in SUBSCRIBE/NOTIFY parlance) generates NOTIFY requests based on the requirements of RFC 3265 [5]. Specifically, if a SUBSCRIBE request is valid and authorized, it will result in an immediate NOTIFY.
登録、/NOTIFY。User Interface、(中のnotifier、話法) NOTIFYがRFC3265[5]の要件に基づく要求であると生成します。 要求が登録なら明確に、有効であって、認可されている、それは即座のNOTIFYをもたらすでしょう。
The KPML payload distinguishes between an initial NOTIFY and a NOTIFY informing of key presses. If there is no User Input buffered at the time of the SUBSCRIBE (see below) or the buffered User Input does not match the new KPML document, then the immediate NOTIFY MUST NOT contain a KPML body. If User Interface has User Input buffered that results in a match using the new KPML document, then the NOTIFY MUST return the appropriate KPML document.
KPMLペイロードは初期のNOTIFYと主要なプレスについて知らせるNOTIFYを見分けます。 または、バッファリングされたUser Inputが全くない、時点、登録、(以下を見ます)、バッファリングされたUser Inputは新しいKPMLドキュメントに合っていなくて、次に、即座のNOTIFY MUST NOTはKPMLボディーを含んでいます。 User InterfaceがUser Inputをバッファリングさせるなら、それは新しいKPMLドキュメントを使用することでマッチをもたらして、次に、NOTIFY MUSTは適切なKPMLドキュメントを返します。
The NOTIFY in response to a SUBSCRIBE request has no KPML if there are no matching buffered digits. An example of this is in Figure 10.
合っているバッファリングされたケタが全くなければ、KPMLを全く持っていません登録に対応したNOTIFYが、要求する。 この例は図10にあります。
Burger & Dolly Standards Track [Page 25] RFC 4730 KPML November 2006
バーガーと台車標準化過程[25ページ]RFC4730KPML2006年11月
If there are buffered digits in the SUBSCRIBE request that match a pattern, then the NOTIFY message in response to the SUBSCRIBE request MUST include the appropriate KPML document.
登録、要求はそうしなければなりません。に対応してケタが中でバッファリングされる、登録、パターンを合わせてください、次に、NOTIFYが通信するよう要求してください、適切なKPMLドキュメントを含めてください。
NOTIFY sip:application@example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com Max-Forwards: 70 To: <sip:application@example.com> From: <sip:endpoint@example.net> Call-Id: 439hu409h4h09903fj0ioij Subscription-State: active; expires=7200 CSeq: 49851 NOTIFY Event: kpml
NOTIFY一口: application@example.com SIP/2.0Via: 前方へ2.0/UDP proxy.example.com SIP/マックス: 70 To: <一口: application@example.com 、gt;、From: <一口: endpoint@example.net 、gt;、呼び出しイド: 439hu409h4h09903fj0ioij購読州: アクティブ。 =7200CSeqを吐き出します: 49851 イベントに通知してください: kpml
Figure 10: Immediate NOTIFY Example
図10: 即座である、例に通知してください。
All subscriptions MUST be authenticated, particularly those that match on buffered input.
すべての購読を認証しなければならなくて、特にそれらはバッファリングされた入力でのそのマッチです。
KPML specifies the key press notification report format. The MIME type for KPML reports is application/kpml-response+xml. The default MIME type for the kpml event package is application/ kpml-response+xml.
KPMLは主要なプレス通知レポート形式を指定します。 KPMLレポートのためのMIMEの種類はアプリケーション/kpml-応答+xmlです。 kpmlイベントパッケージのためのデフォルトMIMEの種類はアプリケーション/kpml-応答+xmlです。
If the requestor is not using a secure transport protocol such as TLS for every hop (e.g., by using a sips: URI), the User Interface SHOULD use S/MIME to protect the user information in responses.
要請者があらゆるホップ(例えば、一口: URIを使用するのによる)のためのTLSなどの安全なトランスポート・プロトコルを使用していないなら、User Interface SHOULDは、応答におけるユーザー情報を保護するのにS/MIMEを使用します。
When the user enters key presses that match a <regex> tag, the User Interface will issue a report.
ユーザが<regex>タグに合っている主要なプレスを入れるとき、User Interfaceはレポートを発行するでしょう。
After reporting, the interpreter terminates the KPML session unless the subscription has a persistence indicator. If the subscription does not have a persistence indicator, the User Interface MUST set the state of the subscription to "terminated" in the NOTIFY report.
報告した後に、購読に固執インディケータがない場合、インタプリタはKPMLセッションを終えます。 購読に固執インディケータがないなら、User InterfaceはNOTIFYレポートで「終えられること」の購読の状態を設定しなければなりません。
If the subscription does not have a persistence indicator, to collect more digits, the requestor must issue a new request.
より多くのケタを集めるために購読に固執インディケータがないなら、要請者は新しい要求を出さなければなりません。
NOTE: This highlights the "one shot" nature of KPML, reflecting
the balance of features and ease of implementing an interpreter.
以下に注意してください。 特徴のバランスとインタプリタを実装する容易さを反映して、これはKPMLの「1つのショット」の自然を強調します。
KPML reports have two mandatory attributes, code and text. These attributes describe the state of the KPML interpreter on the User Interface. Note the KPML status code is not necessarily related to the SIP result code. An important example of this is where a legal SIP subscription request gets a normal SIP 200 OK followed by a NOTIFY, but there is something wrong with the KPML request. In this
KPMLレポートには、2つの義務的な属性、コード、およびテキストがあります。 これらの属性はUser InterfaceでKPMLインタプリタの状態について説明します。 KPMLステータスコードが必ずSIP結果コードに関連するというわけではないことに注意してください。 この重要な例はNOTIFYが法的なSIP購読要求で正常なSIP200OKに続いているところですが、KPML要求には不具合があります。 これで
Burger & Dolly Standards Track [Page 26] RFC 4730 KPML November 2006
バーガーと台車標準化過程[26ページ]RFC4730KPML2006年11月
case, the NOTIFY would include the KPML status code in the KPML report. Note that from a SIP perspective, the SUBSCRIBE and NOTIFY were successful. Also, if the KPML failure is not recoverable, the User Interface will most likely set the Subscription-State to "terminated". This lets the SIP machinery know the subscription is no longer active.
ケース、NOTIFYはKPMLレポートにKPMLステータスコードを含んでいるでしょう。 そして、SIP見解からそれに注意してください、登録、NOTIFYはうまくいきます。 また、KPMLの故障が回復可能でないなら、User Interfaceはたぶん「終えられること」にSubscription-状態を設定するでしょう。 これで、SIP機械は、購読がもう活発でないことを知っています。
If a pattern matches, the User Interface will emit a KPML report. Since this is a success report, the code is "200", and the text is "OK".
パターンが合っていると、User InterfaceはKPMLレポートを放つでしょう。 これが成功レポートであるので、コードは「200」です、そして、テキストは「OKです」。
The KPML report includes the actual digits matched in the digit attribute. The digit string uses the conventional characters '*' and '#' for star and octothorpe, respectively. The KPML report also includes the tag attribute if the regex that matched the digits had a tag attribute.
KPMLレポートはケタ属性で合わせられた実際のケタを含んでいます。 ケタストリングは星とシャープ記号にそれぞれ従来のキャラクタ'*'と'#'を使用します。 また、ケタに合っていたregexがタグ属性を持っていたなら、KPMLレポートはタグ属性を含んでいます。
If the subscription requested digit suppression and the User Interface suppressed digits, the suppressed attribute indicates "true". The default value of suppressed is "false".
抑圧された属性は、購読がケタ抑圧を要求したか、そして、User Interfaceがケタを抑圧したのを「本当に」示します。 抑圧されることのデフォルト値は「誤っています」。
NOTE: KPML does not include a timestamp. There are a number of
reasons for this. First, what timestamp would it include? Would
it be the time of the first detected key press? The time the
interpreter collected the entire string? A range? Second, if the
RTP timestamp is a datum of interest, why not simply get RTP in
the first place? That all said, if it is really compelling to
have the timestamp in the response, it could be an attribute to
the <response> tag.
以下に注意してください。 KPMLはタイムスタンプを含んでいません。 この多くの理由があります。 まず最初に、それはどんなタイムスタンプを含んでいるでしょうか? 最初の検出された主要なプレスの時間でしょうか? インタプリタが全体のストリングを集めた時? 範囲? 2番目に、RTPタイムスタンプが興味があるデータであるなら、なぜ第一に、RTPを絶対に手に入れませんか? 応答におけるタイムスタンプを持っているのが本当に無視できないならそれがすべて言われて、それは<応答>タグへの属性であるかもしれません。
Note that if the monitored (INVITE-initiated) dialog terminates, the notifier still MUST explicitly terminate the KPML subscriptions monitoring that dialog.
モニターされた(INVITEによって開始された)対話が終わるなら、notifierスチール写真が明らかにその対話をモニターするKPML購読を終えなければならないことに注意してください。
4.9. Subscriber Processing of NOTIFY Requests
4.9. 加入者、処理する、要求に通知してください。
If there is no KPML body, it means the SUBSCRIBE was successful. This establishes the dialog if there is no buffered User Input to report.
KPMLボディーが全くないことを意味する、登録、うまくいきます。 報告するためにバッファリングされたUser Inputが全くなければ、これは対話を確立します。
If there is a KPML document, and the KPML status code is 200, then a match occurred.
KPMLドキュメントがあって、KPMLステータスコードが200であるなら、マッチは現れました。
If there is a KPML document, and the KPML status code is between 400 and 499, then an error occurred with User Input collection. The most likely cause is a timeout condition.
KPMLステータスコードが400〜KPMLドキュメントがあって、499であるなら、誤りはUser Input収集で発生しました。 最もありそうな原因はタイムアウト状態です。
Burger & Dolly Standards Track [Page 27] RFC 4730 KPML November 2006
バーガーと台車標準化過程[27ページ]RFC4730KPML2006年11月
If there is a KPML document, and the KPML status code is between 500 and 599, then an error occurred with the subscription. See Section 6 for more on the meaning of KPML status codes.
KPMLステータスコードが500〜KPMLドキュメントがあって、599であるなら、誤りは購読で発生しました。 詳しい情報については、KPMLステータスコードの意味でセクション6を見てください。
The subscriber MUST be mindful of the subscription state. The User Interface may terminate the subscription at any time.
加入者は心に購読状態をとどめていなければなりません。 User Interfaceはいつでも、購読を終えるかもしれません。
4.10. Handling of Forked Requests
4.10. 股状の要求の取り扱い
Forked requests are NOT ALLOWED for this event type. This can be ensured if the Subscriptions to this event package are sent to SIP URIs that have GRUU properties.
股状の要求はこのイベントタイプのためのNOT ALLOWEDです。 GRUUの特性を持っているSIP URIにこのイベントパッケージへのSubscriptionsを送るなら、これを確実にすることができます。
4.11. Rate of Notifications
4.11. 通知の速度
The User Interface MUST NOT generate messages faster than 25 messages per second, or one message every 40 milliseconds. This is the minimum time period for MF digit spills. Even 30-millisecond DTMF, as one sometimes finds in Japan, has a 20-millisecond off time, resulting in a 50-millisecond interdigit time. This document strongly RECOMMENDS AGAINST using KPML for digit-by-digit messaging, such as would be the case if the only <regex> is "x".
User Interfaceは1秒あたり25のメッセージより速い、または40ミリセカンドあたり1つのメッセージにメッセージを生成してはいけません。 これはMFケタ流出のための最小の期間です。 50ミリセカンドの趾間部時間でなって、人が日本で時々見つけるように30ミリセカンドのDTMFさえ20ミリセカンドのオフ時間を過します。 強く、唯一の<regex>であるならケースであるだろうケタに従ったケタメッセージングにKPMLを使用するRECOMMENDS AGAINSTはそうです。このドキュメント、「x。」
The sustained rate of notification shall be no more than 100 Notifies per minute.
通知の持続している速度は1分あたり100Notifiesになるでしょう。
The User Interface MUST reliably deliver notifications. Because there is no meaningful metric for throttling requests, the User Interface SHOULD send NOTIFY messages over a congestion-controlled transport, such as TCP.
User Interfaceは通知を確かに提供しなければなりません。 ノーは重要です。そこ、要求を阻止するのにおいてメートル法です、User Interface SHOULDは混雑で制御された輸送の上にNOTIFYメッセージを送ります、TCPなどのように。
Note that all SIP implementations are already required to
implement SIP over TCP.
すべてのSIP実装がTCPの上でSIPを実装するのに既に必要であることに注意してください。
4.12. State Agents and Lists
4.12. 州のエージェントとリスト
KPML requests are sent to a specific SIP URI, which may have GRUU properties, and they attempt to monitor a specific stream that corresponds with a specific target dialog. Consequently, implementers MUST NOT define state agents for this event package or allow subscriptions for this event package to resource lists using the event list extension [18].
KPML要求を特定のSIP URIに送ります、そして、それらは特定の目標対話に対応する特定のストリームをモニターするのを試みます。(SIP URIはGRUUの特性を持っているかもしれません)。 その結果、implementersは、イベントリスト拡張子[18]を使用することでこのイベントパッケージのために州のエージェントを定義してはいけませんし、またこのイベントパッケージのためにリソースリストに購読を許してはいけません。
Burger & Dolly Standards Track [Page 28] RFC 4730 KPML November 2006
バーガーと台車標準化過程[28ページ]RFC4730KPML2006年11月
4.13. Behavior of a Proxy Server
4.13. Proxyサーバの振舞い
There are no additional requirements on a SIP Proxy, other than to transparently forward the SUBSCRIBE and NOTIFY methods as required in SIP.
SIP Proxyに関するどんな追加要件もありません、透過的に進めるのを除いて登録、NOTIFYメソッド、必要に応じて、SIPで。
5. Formal Syntax
5. 正式な構文
5.1. DRegex
5.1. DRegex
The following definition follows RFC 4234 [2]. The definition of DIGIT is from RFC 4234, namely, the characters "0" through "9". Note the DRegexCharacter is not a HEXDIG from RFC 4234. In particular, DRegexCharacter includes neither "E" nor "F". Note that DRegexCharacter is case insensitive.
以下の定義はRFC4234[2]に続きます。 DIGITの定義がすなわち、RFC4234、キャラクタから来ている、「「9インチ」を通した0インチ DRegexCharacterがRFC4234からのHEXDIGでないことに注意してください。 特に、DRegexCharacterは「E」も「F」も含んでいません。 DRegexCharacterが大文字と小文字を区別しないことに注意してください。
DRegex = 1*( DRegexPosition [ RepeatCount ] )
DRegexPosition = DRegexSymbol / DRegexSet
DRegexSymbol = [ "L" ] DRegexCharacter
DRegexSet = "[" 1*DRegexSetList "]"
DRegexSetList = DRegexCharacter [ "-" DRegexCharacter ]
DRegexCharacter = DIGIT / "A" / "B" / "C" / "D" / "R" / "*" / "#" /
"a" / "b" / "c" / "d" / "r"
RepeatCount = "." / "{" RepeatRange "}"
RepeatRange = Count / ( Count "," Count ) /
( Count "," ) / ( "," Count )
Count = 1*DIGIT
「「[「1*DRegexSetList」]」というDRegex=1*(DRegexPosition[RepeatCount])DRegexPosition=DRegexSymbol / DRegexSet DRegexSymbol=[「L」]DRegexCharacter DRegexSet=DRegexSetList=DRegexCharacter[「-」DRegexCharacter]DRegexCharacterは/「B」/「C」/「D」/「R」/「*」/「#」/“a"/「b」/ケタ/「c」/「d」/「r」RepeatCount=」と等しいです。」 「/、「」 RepeatRange=が数える"RepeatRange"、/、(カウント、」、」 カウント) /、(カウント、」、」、)、/、(「」 カウント) カウント=1*ケタ
ABNF for DRegex
DRegexのためのABNF
Note that future extensions to this document may introduce other characters for DRegexCharacter, in the scheme of H.248.1 [12] or possibly as named strings or XML namespaces.
このドキュメントへの今後の拡大がDRegexCharacterのために他のキャラクタを紹介するかもしれないことに注意してください、H.248.1[12]の体系かことによるとストリングかXML名前空間と命名されるように。
Burger & Dolly Standards Track [Page 29] RFC 4730 KPML November 2006
バーガーと台車標準化過程[29ページ]RFC4730KPML2006年11月
5.2. KPML Request
5.2. KPML要求
The following syntax for KPML requests uses the XML Schema [8].
KPML要求のための以下の構文はXML Schema[8]を使用します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:kpml-request"
xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="kpml-request">
<xs:annotation>
<xs:documentation>IETF Keypad Markup Language Request
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="stream" minOccurs="0">
<xs:complexType>
<xs:choice>
<xs:element name="reverse" minOccurs="0"/>
<xs:any namespace="##other"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="pattern">
<xs:complexType>
<xs:sequence>
<xs:element name="flush" minOccurs="0">
<xs:annotation>
<xs:documentation>
Default is to not flush buffer
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string"/>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="regex" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
Key press notation is a string to allow
for future extension of non-16 digit
keypads or named keys
</xs:documentation>
</xs:annotation>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><xs: 図式targetNamespace=「つぼ:ietf:params:xml:ナノ秒: kpml要求」xmlnsは「つぼ:ietf:params:xml:ナノ秒: kpml要求」xmlnsと等しいです: " http://www.w3.org/2001/XMLSchema "xs=elementFormDefaultが「適切な」attributeFormDefault=と等しい、「資格のなさ、「><xs: 要素名=、「「><はxsされます: 注釈><は: ドキュメンテーション>IETF Keypad Markup Language Request</xsをxsします。」ようkpmlに要求してください; 「ドキュメンテーション」 ></xs: 注釈><xs: complexType><xs: 系列><xs: 要素名=の「ストリーム」minOccurs=「0インチの><xs: complexType><xs: 選択><xs: 要素名=」逆minOccurs=「0インチ/>の<xs: どんな名前空間=も」##他」の/></xs:; 選択></xs: complexType></xs: 要素><はxsされます: 「平らに「><はxsされます: complexType><はxsされます: ><xs: 要素名=を配列してください」を型に基づいて作ってください」という要素名=のminOccurs=「0インチの><はxsされます: 注釈><はxsされます: ドキュメンテーション>Defaultはバッファ</xsを洗い流すことになっていません: ドキュメンテーション></は以下をxsします」; 注釈><xs: complexType><xs: simpleContent><xs: 拡大ベース=の「xs: ストリング」/></xs: simpleContent></xs: complexType></xs: 要素の><xs: 要素名=の「regexな」maxOccursが等しい、「限りなさ、「><xs: 注釈><xs: ドキュメンテーション>Keyプレス記法はすべてへのストリングです」。非16ケタキーパッドか命名されたキー</xsの今後の拡大のために痛い: ドキュメンテーション></xs: 注釈>。
Burger & Dolly Standards Track [Page 30] RFC 4730 KPML November 2006
バーガーと台車標準化過程[30ページ]RFC4730KPML2006年11月
<xs:complexType mixed="true">
<xs:choice>
<xs:element name="pre" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string"/>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##other"/>
</xs:choice>
<xs:attribute name="tag" type="xs:string"
use="optional"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="persist" use="optional">
<xs:annotation>
<xs:documentation>Default is "one-shot"
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="one-shot"/>
<xs:enumeration value="persist"/>
<xs:enumeration value="single-notify"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="interdigittimer"
type="xs:integer"
use="optional">
<xs:annotation>
<xs:documentation>Default is 4000 (ms)
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="criticaldigittimer"
type="xs:integer"
use="optional">
<xs:annotation>
<xs:documentation>Default is 1000 (ms)
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="extradigittimer"
type="xs:integer"
use="optional">
<xs:complexType mixed="true"> <xs:choice> <xs:element name="pre" minOccurs="0"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"/> </xs:simpleContent> </xs:complexType> </xs:element> <xs:any namespace="##other"/> </xs:choice> <xs:attribute name="tag" type="xs:string" use="optional"/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="persist" use="optional"> <xs:annotation> <xs:documentation>Default is "one-shot" </xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="one-shot"/> <xs:enumeration value="persist"/> <xs:enumeration value="single-notify"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="interdigittimer" type="xs:integer" use="optional"> <xs:annotation> <xs:documentation>Default is 4000 (ms) </xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="criticaldigittimer" type="xs:integer" use="optional"> <xs:annotation> <xs:documentation>Default is 1000 (ms) </xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="extradigittimer" type="xs:integer" use="optional">
Burger & Dolly Standards Track [Page 31] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 31] RFC 4730 KPML November 2006
<xs:annotation>
<xs:documentation>Default is 500 (ms)
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="long" type="xs:integer"
use="optional"/>
<xs:attribute name="longrepeat" type="xs:boolean"
use="optional"/>
<xs:attribute name="nopartial" type="xs:boolean"
use="optional">
<xs:annotation>
<xs:documentation>Default is false
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="enterkey" type="xs:string"
use="optional">
<xs:annotation>
<xs:documentation>No default enterkey
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="version" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:annotation> <xs:documentation>Default is 500 (ms) </xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="long" type="xs:integer" use="optional"/> <xs:attribute name="longrepeat" type="xs:boolean" use="optional"/> <xs:attribute name="nopartial" type="xs:boolean" use="optional"> <xs:annotation> <xs:documentation>Default is false </xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="enterkey" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>No default enterkey </xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="version" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:schema>
Figure 12: XML Schema for KPML Requests
Figure 12: XML Schema for KPML Requests
Burger & Dolly Standards Track [Page 32] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 32] RFC 4730 KPML November 2006
5.3. KPML Response
5.3. KPML Response
The following syntax for KPML responses uses the XML Schema [8].
The following syntax for KPML responses uses the XML Schema [8].
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:kpml-response"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:kpml-response"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="kpml-response">
<xs:annotation>
<xs:documentation>IETF Keypad Markup Language Response
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="version" type="xs:string"
use="required"/>
<xs:attribute name="code" type="xs:string"
use="required"/>
<xs:attribute name="text" type="xs:string"
use="required"/>
<xs:attribute name="suppressed" type="xs:boolean"
use="optional"/>
<xs:attribute name="forced_flush" type="xs:string"
use="optional">
<xs:annotation>
<xs:documentation>
String for future use for e.g., number of digits lost.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="digits" type="xs:string"
use="optional"/>
<xs:attribute name="tag" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Matches tag from regex in request
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:kpml-response" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:kpml-response" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="kpml-response"> <xs:annotation> <xs:documentation>IETF Keypad Markup Language Response </xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="version" type="xs:string" use="required"/> <xs:attribute name="code" type="xs:string" use="required"/> <xs:attribute name="text" type="xs:string" use="required"/> <xs:attribute name="suppressed" type="xs:boolean" use="optional"/> <xs:attribute name="forced_flush" type="xs:string" use="optional"> <xs:annotation> <xs:documentation> String for future use for e.g., number of digits lost. </xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="digits" type="xs:string" use="optional"/> <xs:attribute name="tag" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Matches tag from regex in request </xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> </xs:schema>
XML Schema for KPML Responses
XML Schema for KPML Responses
Burger & Dolly Standards Track [Page 33] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 33] RFC 4730 KPML November 2006
6. Enumeration of KPML Status Codes
6. Enumeration of KPML Status Codes
KPML status codes broadly follow their SIP counterparts. Codes that start with a 2 indicate success. Codes that start with a 4 indicate failure. Codes that start with a 5 indicate a server failure, usually a failure to interpret the document or to support a requested feature.
KPML status codes broadly follow their SIP counterparts. Codes that start with a 2 indicate success. Codes that start with a 4 indicate failure. Codes that start with a 5 indicate a server failure, usually a failure to interpret the document or to support a requested feature.
KPML clients MUST be able to handle arbitrary status codes by examining the first digit only.
KPML clients MUST be able to handle arbitrary status codes by examining the first digit only.
Any text can be in a KPML report document. KPML clients MUST NOT interpret the text field.
Any text can be in a KPML report document. KPML clients MUST NOT interpret the text field.
+------+--------------------------------------------------+
| Code | Text |
+------+--------------------------------------------------+
| 200 | Success |
| 402 | User Terminated without Match |
| 423 | Timer Expired |
| 481 | Dialog Not Found |
| 487 | Subscription Expired |
| 501 | Bad Document |
| 502 | Namespace Not Supported |
| 531 | Persistent Subscriptions Not Supported |
| 532 | Multiple Regular Expressions Not Supported |
| 533 | Multiple Subscriptions on a Dialog Not Supported |
| 534 | Too Many Regular Expressions |
+------+--------------------------------------------------+
+------+--------------------------------------------------+ | Code | Text | +------+--------------------------------------------------+ | 200 | Success | | 402 | User Terminated without Match | | 423 | Timer Expired | | 481 | Dialog Not Found | | 487 | Subscription Expired | | 501 | Bad Document | | 502 | Namespace Not Supported | | 531 | Persistent Subscriptions Not Supported | | 532 | Multiple Regular Expressions Not Supported | | 533 | Multiple Subscriptions on a Dialog Not Supported | | 534 | Too Many Regular Expressions | +------+--------------------------------------------------+
Table 4: KPML Status Codes
Table 4: KPML Status Codes
7. IANA Considerations
7. IANA Considerations
This document registers a new SIP Event Package, two new MIME types, and two new XML namespaces.
This document registers a new SIP Event Package, two new MIME types, and two new XML namespaces.
7.1. SIP Event Package Registration
7.1. SIP Event Package Registration
Package name: kpml Type: package Contact: Eric Burger, <e.burger@ieee.org> Change Controller: SIPPING Working Group delegated from the IESG Published Specification: RFC 4730
Package name: kpml Type: package Contact: Eric Burger, <e.burger@ieee.org> Change Controller: SIPPING Working Group delegated from the IESG Published Specification: RFC 4730
Burger & Dolly Standards Track [Page 34] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 34] RFC 4730 KPML November 2006
7.2. MIME Media Type application/kpml-request+xml
7.2. MIME Media Type application/kpml-request+xml
MIME media type name: application
MIME subtype name: kpml-request+xml
Required parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in XML Media Types [3]
Encoding considerations: See RFC 3023 [3].
Security considerations: See Section 10 of RFC 3023 [3] and
Section 8 of RFC 4730
Interoperability considerations: See RFC 2023 [3] and RFC 4730
Published specification: RFC 4730
Applications which use this media type: Session-oriented
applications that have primitive User Interfaces.
Change controller: SIPPING Working Group delegated from the IESG
Personal and email address for further information: Eric Burger
<e.burger@ieee.org>
Intended usage: COMMON
MIME media type name: application MIME subtype name: kpml-request+xml Required parameters: none Optional parameters: Same as charset parameter application/xml as specified in XML Media Types [3] Encoding considerations: See RFC 3023 [3]. Security considerations: See Section 10 of RFC 3023 [3] and Section 8 of RFC 4730 Interoperability considerations: See RFC 2023 [3] and RFC 4730 Published specification: RFC 4730 Applications which use this media type: Session-oriented applications that have primitive User Interfaces. Change controller: SIPPING Working Group delegated from the IESG Personal and email address for further information: Eric Burger <e.burger@ieee.org> Intended usage: COMMON
7.3. MIME Media Type application/kpml-response+xml
7.3. MIME Media Type application/kpml-response+xml
MIME media type name: application
MIME subtype name: kpml-response+xml
Required parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in XML Media Types [3]
Encoding considerations: See RFC 3023 [3].
Security considerations: See Section 10 of RFC 3023 [3] and
Section 8 of RFC 4730
Interoperability considerations: See RFC 2023 [3] and RFC 4730
Published specification: RFC 4730
Applications which use this media type: Session-oriented
applications that have primitive User Interfaces.
Change controller: SIPPING Working Group delegated from the IESG
Personal and email address for further information: Eric Burger
<e.burger@ieee.org>
Intended usage: COMMON
MIME media type name: application MIME subtype name: kpml-response+xml Required parameters: none Optional parameters: Same as charset parameter application/xml as specified in XML Media Types [3] Encoding considerations: See RFC 3023 [3]. Security considerations: See Section 10 of RFC 3023 [3] and Section 8 of RFC 4730 Interoperability considerations: See RFC 2023 [3] and RFC 4730 Published specification: RFC 4730 Applications which use this media type: Session-oriented applications that have primitive User Interfaces. Change controller: SIPPING Working Group delegated from the IESG Personal and email address for further information: Eric Burger <e.burger@ieee.org> Intended usage: COMMON
7.4. URN Sub-Namespace Registration for urn:ietf:xml:ns:kpml-request
7.4. URN Sub-Namespace Registration for urn:ietf:xml:ns:kpml-request
URI: urn:ietf:params:xml:ns:kpml-request
URI: urn:ietf:params:xml:ns:kpml-request
Registrant Contact: The IESG <iesg@ietf.org>
Registrant Contact: The IESG <iesg@ietf.org>
Burger & Dolly Standards Track [Page 35] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 35] RFC 4730 KPML November 2006
XML:
XML:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Key Press Markup Language Request</title>
</head>
<body>
<h1>Namespace for Key Press Markup Language Request</h1>
<h2>urn:ietf:params:xml:ns:kpml-request</h2>
<p>
<a href="ftp://ftp.rfc-editor.org/in-notes/RFC4730.txt">RFC 4730</a>.
</p>
</body>
</html>
<?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Key Press Markup Language Request</title> </head> <body> <h1>Namespace for Key Press Markup Language Request</h1> <h2>urn:ietf:params:xml:ns:kpml-request</h2> <p> <a href="ftp://ftp.rfc-editor.org/in-notes/RFC4730.txt">RFC 4730</a>. </p> </body> </html>
7.5. URN Sub-Namespace Registration for urn:ietf:xml:ns:kpml-response
7.5. URN Sub-Namespace Registration for urn:ietf:xml:ns:kpml-response
URI: urn:ietf:params:xml:ns:kpml-response
URI: urn:ietf:params:xml:ns:kpml-response
Registrant Contact: The IESG <iesg@ietf.org>
Registrant Contact: The IESG <iesg@ietf.org>
XML:
XML:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Key Press Markup Language Response</title>
</head>
<body>
<h1>Namespace for Key Press Markup Language Response</h1>
<h2>urn:ietf:params:xml:ns:kpml-response</h2>
<p>
<a href="ftp://ftp.rfc-editor.org/in-notes/rfc4730.txt">RFC 4730</a>.
</p>
</body>
</html>
<?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Key Press Markup Language Response</title> </head> <body> <h1>Namespace for Key Press Markup Language Response</h1> <h2>urn:ietf:params:xml:ns:kpml-response</h2> <p> <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4730.txt">RFC 4730</a>. </p> </body> </html>
Burger & Dolly Standards Track [Page 36] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 36] RFC 4730 KPML November 2006
7.6. KPML Request Schema Registration
7.6. KPML Request Schema Registration
Per RFC 3688 [7], IANA registered the XML Schema for KPML as referenced in Section 5.2 of RFC 4730.
Per RFC 3688 [7], IANA registered the XML Schema for KPML as referenced in Section 5.2 of RFC 4730.
URI: urn:ietf:params:xml:schema:kpml-request
URI: urn:ietf:params:xml:schema:kpml-request
Registrant Contact: <iesg@ietf.org>
Registrant Contact: <iesg@ietf.org>
7.7. KPML Response Schema Registration
7.7. KPML Response Schema Registration
Per RFC 3688 [7], IANA registered the XML Schema for KPML as referenced in Section 5.3 of RFC 4730.
Per RFC 3688 [7], IANA registered the XML Schema for KPML as referenced in Section 5.3 of RFC 4730.
URI: urn:ietf:params:xml:schema:kpml-response
URI: urn:ietf:params:xml:schema:kpml-response
Registrant Contact: IETF, SIPPING Work Group <sipping@ietf.org>, Eric Burger <e.burger@ieee.org>.
Registrant Contact: IETF, SIPPING Work Group <sipping@ietf.org>, Eric Burger <e.burger@ieee.org>.
8. Security Considerations
8. Security Considerations
The user information transported by KPML is potentially sensitive. For example, it could include calling card or credit card numbers. This potentially private information could be provided accidentally if the notifier does not properly authenticate or authorize a subscription. Similarly private information (such as a credit card number or calling card number) could be revealed to an otherwise legitimate subscriber (one operating an IVR) if digits buffered earlier in the session are provided unintentionally to the new subscriber.
The user information transported by KPML is potentially sensitive. For example, it could include calling card or credit card numbers. This potentially private information could be provided accidentally if the notifier does not properly authenticate or authorize a subscription. Similarly private information (such as a credit card number or calling card number) could be revealed to an otherwise legitimate subscriber (one operating an IVR) if digits buffered earlier in the session are provided unintentionally to the new subscriber.
Likewise, an eavesdropper could view KPML digit information if it is not encrypted, or an attacker could inject fraudulent notifications unless the messages or the SIP path over which they travel are integrity protected.
Likewise, an eavesdropper could view KPML digit information if it is not encrypted, or an attacker could inject fraudulent notifications unless the messages or the SIP path over which they travel are integrity protected.
Therefore, User Interfaces MUST NOT downgrade their own security policy. That is, if a User Interface policy is to restrict notifications to authenticated and authorized subscribers over secure communications, then the User Interface must not accept an unauthenticated, unauthorized subscription over an insecure communication channel.
Therefore, User Interfaces MUST NOT downgrade their own security policy. That is, if a User Interface policy is to restrict notifications to authenticated and authorized subscribers over secure communications, then the User Interface must not accept an unauthenticated, unauthorized subscription over an insecure communication channel.
As an XML markup, all of the security considerations of RFC 3023 [3] and RFC 3406 [6] MUST be met. Pay particular attention to the robustness requirements of parsing XML.
As an XML markup, all of the security considerations of RFC 3023 [3] and RFC 3406 [6] MUST be met. Pay particular attention to the robustness requirements of parsing XML.
Burger & Dolly Standards Track [Page 37] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 37] RFC 4730 KPML November 2006
Key press information is potentially sensitive. For example, it can represent credit card, calling card, or other personal information. Hijacking sessions allow unauthorized entities access to this sensitive information. Therefore, signaling SHOULD be secure, e.g., use of TLS and sips: SHOULD be used. Moreover, the information itself is sensitive so S/MIME or other appropriate mechanisms SHOULD be used.
Key press information is potentially sensitive. For example, it can represent credit card, calling card, or other personal information. Hijacking sessions allow unauthorized entities access to this sensitive information. Therefore, signaling SHOULD be secure, e.g., use of TLS and sips: SHOULD be used. Moreover, the information itself is sensitive so S/MIME or other appropriate mechanisms SHOULD be used.
Subscriptions MUST be authenticated in some manner. As required by the core SIP [4] specification, all SIP implementations MUST support digest authentication. In addition, User Interfaces MUST implement support for the sips: scheme and SIP over TLS. Subscribers MUST expect the User Interface to demand the use of an authentication scheme. If the local policy of a User Interface is to use authentication or secure communication channels, the User Interface MUST reject subscription requests that do not meet that policy.
Subscriptions MUST be authenticated in some manner. As required by the core SIP [4] specification, all SIP implementations MUST support digest authentication. In addition, User Interfaces MUST implement support for the sips: scheme and SIP over TLS. Subscribers MUST expect the User Interface to demand the use of an authentication scheme. If the local policy of a User Interface is to use authentication or secure communication channels, the User Interface MUST reject subscription requests that do not meet that policy.
User Interfaces MUST begin buffering User Input upon receipt of an authenticated and accepted subscription. This buffering is done on a per-subscription basis.
User Interfaces MUST begin buffering User Input upon receipt of an authenticated and accepted subscription. This buffering is done on a per-subscription basis.
9. Examples
9. Examples
This section is informative in nature. If there is a discrepancy between this section and the normative sections above, the normative sections take precedence.
This section is informative in nature. If there is a discrepancy between this section and the normative sections above, the normative sections take precedence.
9.1. Monitoring for Octothorpe
9.1. Monitoring for Octothorpe
A common need for pre-paid and personal assistant applications is to monitor a conversation for a signal indicating a change in user focus from the party they called through the application to the application itself. For example, if you call a party using a pre-paid calling card, and the party you call redirects you to voice mail, digits you press are for the voice mail system. However, many applications have a special key sequence, such as the octothorpe (#, or pound sign) or *9, that terminate the called party session and shift the user's focus to the application.
A common need for pre-paid and personal assistant applications is to monitor a conversation for a signal indicating a change in user focus from the party they called through the application to the application itself. For example, if you call a party using a pre-paid calling card, and the party you call redirects you to voice mail, digits you press are for the voice mail system. However, many applications have a special key sequence, such as the octothorpe (#, or pound sign) or *9, that terminate the called party session and shift the user's focus to the application.
Burger & Dolly Standards Track [Page 38] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 38] RFC 4730 KPML November 2006
Figure 16 shows the KPML for long octothorpe.
Figure 16 shows the KPML for long octothorpe.
<?xml version="1.0"?>
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
version="1.0">
<pattern>
<regex>L#</regex>
</pattern>
</kpml-request>
<?xml version="1.0"?> <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"> <pattern> <regex>L#</regex> </pattern> </kpml-request>
Figure 16: Long Octothorpe Example
Figure 16: Long Octothorpe Example
The regex value L indicates the following digit needs to be a long- duration key press.
The regex value L indicates the following digit needs to be a long- duration key press.
9.2. Dial String Collection
9.2. Dial String Collection
In this example, the User Interface collects a dial string. The application uses KPML to quickly determine when the user enters a target number. In addition, KPML indicates what type of number the user entered.
In this example, the User Interface collects a dial string. The application uses KPML to quickly determine when the user enters a target number. In addition, KPML indicates what type of number the user entered.
<?xml version="1.0"?>
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
version="1.0">
<pattern>
<regex tag="local-operator">0</regex>
<regex tag="ld-operator">00</regex>
<regex tag="vpn">7[x][x][x]</regex>
<regex tag="local-number7">9xxxxxxx</regex>
<regex tag="RI-number">9401xxxxxxx</regex>
<regex tag="local-number10">9xxxxxxxxxx</regex>
<regex tag="ddd">91xxxxxxxxxx</regex>
<regex tag="iddd">011x.</regex>
</pattern>
</kpml-request>
<?xml version="1.0"?> <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"> <pattern> <regex tag="local-operator">0</regex> <regex tag="ld-operator">00</regex> <regex tag="vpn">7[x][x][x]</regex> <regex tag="local-number7">9xxxxxxx</regex> <regex tag="RI-number">9401xxxxxxx</regex> <regex tag="local-number10">9xxxxxxxxxx</regex> <regex tag="ddd">91xxxxxxxxxx</regex> <regex tag="iddd">011x.</regex> </pattern> </kpml-request>
Figure 17: Dial String KPML Example Code
Figure 17: Dial String KPML Example Code
Note the use of the "tag" attribute to indicate which regex matched the dialed string. The interesting case here is if the user entered "94015551212". This string matches both the "9401xxxxxxx" and
Note the use of the "tag" attribute to indicate which regex matched the dialed string. The interesting case here is if the user entered "94015551212". This string matches both the "9401xxxxxxx" and
Burger & Dolly Standards Track [Page 39] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 39] RFC 4730 KPML November 2006
"9xxxxxxxxxx" regular expressions. Both expressions are the same length. Thus the KPML interpreter will pick the "9401xxxxxxx" string, as it occurs first in document order. Figure 18 shows the response.
"9xxxxxxxxxx" regular expressions. Both expressions are the same length. Thus the KPML interpreter will pick the "9401xxxxxxx" string, as it occurs first in document order. Figure 18 shows the response.
<?xml version="1.0"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-resposne"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
version="1.0"
code="200" text="OK"
digits="94015551212" tag="RI-number"/>
<?xml version="1.0"?> <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-resposne" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd" version="1.0" code="200" text="OK" digits="94015551212" tag="RI-number"/>
Figure 18: Dial String KPML Response
Figure 18: Dial String KPML Response
10. Call Flow Examples
10. Call Flow Examples
10.1. Supplemental Digits
10.1. Supplemental Digits
This section gives a non-normative example of an application that collects supplemental digits. Supplemental digit collection is where the network requests additional digits after the caller enters the destination address. A typical supplemental dial string is four digits in length.
This section gives a non-normative example of an application that collects supplemental digits. Supplemental digit collection is where the network requests additional digits after the caller enters the destination address. A typical supplemental dial string is four digits in length.
Burger & Dolly Standards Track [Page 40] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 40] RFC 4730 KPML November 2006
Ingress Gateway Application Server Egress Gateway
| | |
| | |
| | |
|(1) INVITE | |
|-------------------------------------------->|
| | |
| | |
|(2) 200 OK | |
|<--------------------------------------------|
| | |
| | |
|(3) ACK | |
|-------------------------------------------->|
| | |
| | |
|(4) SUBSCRIBE (one-shot) |
|<---------------------| |
| | |
| | |
|(5) 200 OK | |
|--------------------->| |
| | |
| | |
|(6) NOTIFY | |
|--------------------->| |
| | |
| | |
|(7) 200 OK | |
|<---------------------| |
| | |
| | |
|(8) | |
|......................| |
| | |
| | |
|(9) NOTIFY (digits) | |
|--------------------->| |
| | |
| | |
|(10) 200 OK | |
|<---------------------| |
| | |
| | |
| | |
| | |
Ingress Gateway Application Server Egress Gateway | | | | | | | | | |(1) INVITE | | |-------------------------------------------->| | | | | | | |(2) 200 OK | | |<--------------------------------------------| | | | | | | |(3) ACK | | |-------------------------------------------->| | | | | | | |(4) SUBSCRIBE (one-shot) | |<---------------------| | | | | | | | |(5) 200 OK | | |--------------------->| | | | | | | | |(6) NOTIFY | | |--------------------->| | | | | | | | |(7) 200 OK | | |<---------------------| | | | | | | | |(8) | | |......................| | | | | | | | |(9) NOTIFY (digits) | | |--------------------->| | | | | | | | |(10) 200 OK | | |<---------------------| | | | | | | | | | | | | |
Figure 19: Supplemental Digits Call Flow
Figure 19: Supplemental Digits Call Flow
Burger & Dolly Standards Track [Page 41] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 41] RFC 4730 KPML November 2006
In messages (1-3), the ingress gateway establishes a dialog with an egress gateway. The application learns the dialog ID through out-of- band mechanisms, such as the Dialog Package or being co-resident with the egress gateway. Part of the ACK message is below, to illustrate the dialog identifiers.
In messages (1-3), the ingress gateway establishes a dialog with an egress gateway. The application learns the dialog ID through out-of- band mechanisms, such as the Dialog Package or being co-resident with the egress gateway. Part of the ACK message is below, to illustrate the dialog identifiers.
ACK sip:gw@subA.example.com SIP/2.0 Via: ... Max-Forwards: ... Route: ... From: <sip:phn@example.com>;tag=jfh21 To: <sip:gw@subA.example.com>;tag=onjwe2 Call-ID: 12345592@subA.example.com ...
ACK sip:gw@subA.example.com SIP/2.0 Via: ... Max-Forwards: ... Route: ... From: <sip:phn@example.com>;tag=jfh21 To: <sip:gw@subA.example.com>;tag=onjwe2 Call-ID: 12345592@subA.example.com ...
In message (4), the application the requests that gateway collect a string of four key presses.
In message (4), the application the requests that gateway collect a string of four key presses.
SUBSCRIBE sip:gw@subA.example.com SIP/2.0
Via: SIP/2.0/TCP client.subB.example.com;branch=q4i9ufr4ui3
From: <sip:ap@subB.example.com>;tag=567890
To: <sip:gw@subA.example.com>
Call-ID: 12345601@subA.example.com
CSeq: 1 SUBSCRIBE
Contact: <sip:ap@client.subB.example.com>
Max-Forwards: 70
Event: kpml ;remote-tag="sip:phn@example.com;tag=jfh21"
;local-tag="sip:gw@subA.example.com;tag=onjwe2"
;call-id="12345592@subA.example.com"
Expires: 7200
Accept: application/kpml-response+xml
Content-Type: application/kpml-request+xml
Content-Length: 292
SUBSCRIBE sip:gw@subA.example.com SIP/2.0 Via: SIP/2.0/TCP client.subB.example.com;branch=q4i9ufr4ui3 From: <sip:ap@subB.example.com>;tag=567890 To: <sip:gw@subA.example.com> Call-ID: 12345601@subA.example.com CSeq: 1 SUBSCRIBE Contact: <sip:ap@client.subB.example.com> Max-Forwards: 70 Event: kpml ;remote-tag="sip:phn@example.com;tag=jfh21" ;local-tag="sip:gw@subA.example.com;tag=onjwe2" ;call-id="12345592@subA.example.com" Expires: 7200 Accept: application/kpml-response+xml Content-Type: application/kpml-request+xml Content-Length: 292
<?xml version="1.0" encoding="UTF-8"?>
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
version="1.0">
<pattern persist="one-shot">
<regex>xxxx</regex>
</pattern>
</kpml-request>
<?xml version="1.0" encoding="UTF-8"?> <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"> <pattern persist="one-shot"> <regex>xxxx</regex> </pattern> </kpml-request>
Burger & Dolly Standards Track [Page 42] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 42] RFC 4730 KPML November 2006
Message (5) is the acknowledgement of the subscription request.
Message (5) is the acknowledgement of the subscription request.
SIP/2.0 200 OK
Via: SIP/2.0/TCP subB.example.com;branch=q4i9ufr4ui3;
received=192.168.125.12
From: <sip:ap@subB.example.com>;tag=567890
To: <sip:gw@subA.example.com>;tag=1234567
Call-ID: 12345601@subA.example.com
CSeq: 1 SUBSCRIBE
Contact: <sip:gw27@subA.example.com>
Expires: 3600
Event: kpml
SIP/2.0 200 OK Via: SIP/2.0/TCP subB.example.com;branch=q4i9ufr4ui3; received=192.168.125.12 From: <sip:ap@subB.example.com>;tag=567890 To: <sip:gw@subA.example.com>;tag=1234567 Call-ID: 12345601@subA.example.com CSeq: 1 SUBSCRIBE Contact: <sip:gw27@subA.example.com> Expires: 3600 Event: kpml
Message (6) is the immediate notification of the subscription.
Message (6) is the immediate notification of the subscription.
NOTIFY sip:ap@client.subB.example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=gw27id4993 To: <sip:ap@subB.example.com>;tag=567890 From: <sip:gw@subA.example.com>;tag=1234567 Call-ID: 12345601@subA.example.com CSeq: 1000 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3599 Max-Forwards: 70 Content-Length: 0
NOTIFY sip:ap@client.subB.example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=gw27id4993 To: <sip:ap@subB.example.com>;tag=567890 From: <sip:gw@subA.example.com>;tag=1234567 Call-ID: 12345601@subA.example.com CSeq: 1000 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3599 Max-Forwards: 70 Content-Length: 0
Message (7) is the acknowledgement of the notification message.
Message (7) is the acknowledgement of the notification message.
SIP/2.0 200 OK Via: SIP/2.0/TCP subA.example.com;branch=gw27id4993 To: <sip:ap@subB.example.com>;tag=567890 From: <sip:gw@subA.example.com>;tag=1234567 Call-ID: 12345601@subA.example.com CSeq: 1000 NOTIFY
SIP/2.0 200 OK Via: SIP/2.0/TCP subA.example.com;branch=gw27id4993 To: <sip:ap@subB.example.com>;tag=567890 From: <sip:gw@subA.example.com>;tag=1234567 Call-ID: 12345601@subA.example.com CSeq: 1000 NOTIFY
Some time elapses (8).
Some time elapses (8).
The user enters the input. The device provides the notification of the collected digits in message (9). Since this was a one-shot subscription, note the Subscription-State is "terminated".
The user enters the input. The device provides the notification of the collected digits in message (9). Since this was a one-shot subscription, note the Subscription-State is "terminated".
Burger & Dolly Standards Track [Page 43] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 43] RFC 4730 KPML November 2006
NOTIFY sip:ap@client.subB.example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=gw27id4993 To: <sip:ap@subB.example.com>;tag=567890 From: <sip:gw@subA.example.com>;tag=1234567 Call-ID: 12345601@subA.example.com CSeq: 1001 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: terminated Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 258
NOTIFY sip:ap@client.subB.example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=gw27id4993 To: <sip:ap@subB.example.com>;tag=567890 From: <sip:gw@subA.example.com>;tag=1234567 Call-ID: 12345601@subA.example.com CSeq: 1001 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: terminated Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 258
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
version="1.0"
code="200" text="OK"
digits="4336"/>
<?xml version="1.0" encoding="UTF-8"?> <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd" version="1.0" code="200" text="OK" digits="4336"/>
Message (10) is the acknowledgement of the notification.
Message (10) is the acknowledgement of the notification.
SIP/2.0 200 OK Via: SIP/2.0/TCP subA.example.com;branch=gw27id4993 To: <sip:ap@subB.example.com>;tag=567890 From: <sip:gw@subA.example.com>;tag=1234567 Call-ID: 12345601@subA.example.com CSeq: 1001 NOTIFY
SIP/2.0 200 OK Via: SIP/2.0/TCP subA.example.com;branch=gw27id4993 To: <sip:ap@subB.example.com>;tag=567890 From: <sip:gw@subA.example.com>;tag=1234567 Call-ID: 12345601@subA.example.com CSeq: 1001 NOTIFY
Burger & Dolly Standards Track [Page 44] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 44] RFC 4730 KPML November 2006
10.2. Multiple Applications
10.2. Multiple Applications
This section gives a non-normative example of multiple applications. One application collects a destination number to call. That application then waits for a "long pound." During the call, the call goes to a personal assistant application, which interacts with the user. In addition, the personal assistant application looks for a "short pound."
This section gives a non-normative example of multiple applications. One application collects a destination number to call. That application then waits for a "long pound." During the call, the call goes to a personal assistant application, which interacts with the user. In addition, the personal assistant application looks for a "short pound."
For clarity, we do not show the INVITE dialogs.
For clarity, we do not show the INVITE dialogs.
Gateway Card Application Personal Assistant
| | |
| | |
| | |
|(1) SUBSCRIBE (persistent) |
|<---------------------| |
| | |
| | |
|(2) 200 OK | |
|--------------------->| |
| | |
| | |
|(3) NOTIFY | |
|--------------------->| |
| | |
| | |
|(4) 200 OK | |
|<---------------------| |
| | |
| | |
|(5) | |
|......................| |
| | |
| | |
|(6) NOTIFY (tag=card) | |
|--------------------->| |
| | |
| | |
|(7) 200 OK | |
|<---------------------| |
| | |
| | |
|(8) | |
|......................| |
| | |
| | |
|(9) NOTIFY (tag=number) |
Gateway Card Application Personal Assistant | | | | | | | | | |(1) SUBSCRIBE (persistent) | |<---------------------| | | | | | | | |(2) 200 OK | | |--------------------->| | | | | | | | |(3) NOTIFY | | |--------------------->| | | | | | | | |(4) 200 OK | | |<---------------------| | | | | | | | |(5) | | |......................| | | | | | | | |(6) NOTIFY (tag=card) | | |--------------------->| | | | | | | | |(7) 200 OK | | |<---------------------| | | | | | | | |(8) | | |......................| | | | | | | | |(9) NOTIFY (tag=number) |
Burger & Dolly Standards Track [Page 45] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 45] RFC 4730 KPML November 2006
|--------------------->| |
| | |
| | |
|(10) 200 OK | |
|<---------------------| |
| | |
| | |
|(11) SUBSCRIBE | |
|<--------------------------------------------|
| | |
| | |
|(12) 200 OK | |
|-------------------------------------------->|
| | |
| | |
|(13) NOTIFY | |
|-------------------------------------------->|
| | |
| | |
|(14) 200 OK | |
|<--------------------------------------------|
| | |
| | |
|(15) | |
|.............................................|
| | |
| | |
|(16) NOTIFY (tag=number) |
|-------------------------------------------->|
| | |
| | |
|(17) 200 OK | |
|<--------------------------------------------|
| | |
| | |
|(18) | |
|.............................................|
| | |
| | |
|(19) NOTIFY (tag=#) | |
|-------------------------------------------->|
| | |
| | |
|(20) 200 OK | |
|<--------------------------------------------|
| | |
| | |
|(21) | |
|--------------------->| | | | | | | | |(10) 200 OK | | |<---------------------| | | | | | | | |(11) SUBSCRIBE | | |<--------------------------------------------| | | | | | | |(12) 200 OK | | |-------------------------------------------->| | | | | | | |(13) NOTIFY | | |-------------------------------------------->| | | | | | | |(14) 200 OK | | |<--------------------------------------------| | | | | | | |(15) | | |.............................................| | | | | | | |(16) NOTIFY (tag=number) | |-------------------------------------------->| | | | | | | |(17) 200 OK | | |<--------------------------------------------| | | | | | | |(18) | | |.............................................| | | | | | | |(19) NOTIFY (tag=#) | | |-------------------------------------------->| | | | | | | |(20) 200 OK | | |<--------------------------------------------| | | | | | | |(21) | |
Burger & Dolly Standards Track [Page 46] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 46] RFC 4730 KPML November 2006
|.............................................|
| | |
| | |
|(22) NOTIFY (tag=number) |
|-------------------------------------------->|
| | |
| | |
|(23) 200 OK | |
|<--------------------------------------------|
| | |
| | |
|(24) | |
|.............................................|
| | |
| | |
|(25) NOTIFY (L#) | |
|--------------------->| |
| | |
| | |
|(26) 200 OK | |
|<---------------------| |
| | |
| | |
| | |
| | |
|.............................................| | | | | | | |(22) NOTIFY (tag=number) | |-------------------------------------------->| | | | | | | |(23) 200 OK | | |<--------------------------------------------| | | | | | | |(24) | | |.............................................| | | | | | | |(25) NOTIFY (L#) | | |--------------------->| | | | | | | | |(26) 200 OK | | |<---------------------| | | | | | | | | | | | | |
Figure 27: Multiple Application Call Flow
Figure 27: Multiple Application Call Flow
Message (1) is the subscription request for the card number.
Message (1) is the subscription request for the card number.
SUBSCRIBE sip:gw@subA.example.com SIP/2.0
Via: SIP/2.0/TCP client.subB.example.com;branch=3qo3j0ouq
From: <sip:ap@subB.example.com>;tag=978675
To: <sip:gw@subA.example.com>
Call-ID: 12345601@subA.example.com
CSeq: 20 SUBSCRIBE
Contact: <sip:ap@client.subB.example.com>
Max-Forwards: 70
Event: kpml ;remote-tag="<sip:phn@example.com;tag=jfi23>"
;local-tag="sip:gw@subA.example.com;tag=oi43jfq"
;call-id="12345598@subA.example.com"
Expires: 7200
Accept: application/kpml-response+xml
Content-Type: application/kpml-request+xml
Content-Length: 339
SUBSCRIBE sip:gw@subA.example.com SIP/2.0 Via: SIP/2.0/TCP client.subB.example.com;branch=3qo3j0ouq From: <sip:ap@subB.example.com>;tag=978675 To: <sip:gw@subA.example.com> Call-ID: 12345601@subA.example.com CSeq: 20 SUBSCRIBE Contact: <sip:ap@client.subB.example.com> Max-Forwards: 70 Event: kpml ;remote-tag="<sip:phn@example.com;tag=jfi23>" ;local-tag="sip:gw@subA.example.com;tag=oi43jfq" ;call-id="12345598@subA.example.com" Expires: 7200 Accept: application/kpml-response+xml Content-Type: application/kpml-request+xml Content-Length: 339
Burger & Dolly Standards Track [Page 47] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 47] RFC 4730 KPML November 2006
<?xml version="1.0" encoding="UTF-8"?>
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
version="1.0">
<pattern persist="persist">
<regex tag="card">x{16}</regex>
<regex tag="number">x{10}</regex>
</pattern>
</kpml-request>
<?xml version="1.0" encoding="UTF-8"?> <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"> <pattern persist="persist"> <regex tag="card">x{16}</regex> <regex tag="number">x{10}</regex> </pattern> </kpml-request>
Messages (2-4) are not shown, for brevity. Message (6) is the notification of the card number.
Messages (2-4) are not shown, for brevity. Message (6) is the notification of the card number.
NOTIFY sip:ap@client.subB.example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq To: <sip:ap@subB.example.com>;tag=978675 From: <sip:gw@subA.example.com>;tag=9783453 Call-ID: 12345601@subA.example.com CSeq: 3001 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3442 Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 271
NOTIFY sip:ap@client.subB.example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq To: <sip:ap@subB.example.com>;tag=978675 From: <sip:gw@subA.example.com>;tag=9783453 Call-ID: 12345601@subA.example.com CSeq: 3001 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3442 Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 271
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
version="1.0"
code="200" text="OK"
digits="9999888877776666"/>
<?xml version="1.0" encoding="UTF-8"?> <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd" version="1.0" code="200" text="OK" digits="9999888877776666"/>
Burger & Dolly Standards Track [Page 48] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 48] RFC 4730 KPML November 2006
Message (7) is the acknowledgement of the notification. Time goes by in (8). Message (9) is the notification of the dialed number.
Message (7) is the acknowledgement of the notification. Time goes by in (8). Message (9) is the notification of the dialed number.
NOTIFY sip:ap@client.subB.example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq To: <sip:ap@subB.example.com>;tag=978675 From: <sip:gw@subA.example.com>;tag=9783453 Call-ID: 12345601@subA.example.com CSeq: 3001 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3542 Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 278
NOTIFY sip:ap@client.subB.example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq To: <sip:ap@subB.example.com>;tag=978675 From: <sip:gw@subA.example.com>;tag=9783453 Call-ID: 12345601@subA.example.com CSeq: 3001 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3542 Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 278
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
version="1.0"
code="200" text="OK"
digits="2225551212" tag="number"/>
<?xml version="1.0" encoding="UTF-8"?> <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd" version="1.0" code="200" text="OK" digits="2225551212" tag="number"/>
Message (11) is the request for long-pound monitoring.
Message (11) is the request for long-pound monitoring.
SUBSCRIBE sip:gw@subA.example.com SIP/2.0
Via: SIP/2.0/TCP client.subB.example.com;branch=3qo3j0ouq
From: <sip:ap@subB.example.com>;tag=978675
To: <sip:gw@subA.example.com>
Call-ID: 12345601@subA.example.com
CSeq: 21 SUBSCRIBE
Contact: <sip:ap@client.subB.example.com>
Max-Forwards: 70
Event: kpml ;remote-tag="<sip:phn@example.com;tag=jfi23>"
;local-tag="sip:gw@subA.example.com;tag=oi43jfq"
;call-id="12345598@subA.example.com"
Expires: 7200
Accept: application/kpml-response+xml
Content-Type: application/kpml-request+xml
Content-Length: 295
SUBSCRIBE sip:gw@subA.example.com SIP/2.0 Via: SIP/2.0/TCP client.subB.example.com;branch=3qo3j0ouq From: <sip:ap@subB.example.com>;tag=978675 To: <sip:gw@subA.example.com> Call-ID: 12345601@subA.example.com CSeq: 21 SUBSCRIBE Contact: <sip:ap@client.subB.example.com> Max-Forwards: 70 Event: kpml ;remote-tag="<sip:phn@example.com;tag=jfi23>" ;local-tag="sip:gw@subA.example.com;tag=oi43jfq" ;call-id="12345598@subA.example.com" Expires: 7200 Accept: application/kpml-response+xml Content-Type: application/kpml-request+xml Content-Length: 295
Burger & Dolly Standards Track [Page 49] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 49] RFC 4730 KPML November 2006
<?xml version="1.0" encoding="UTF-8"?>
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
version="1.0">
<pattern persist="single-notify">
<regex>L#</regex>
</pattern>
</kpml-request>
<?xml version="1.0" encoding="UTF-8"?> <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"> <pattern persist="single-notify"> <regex>L#</regex> </pattern> </kpml-request>
Message (13) is the request from the personal assistant application for number and pound sign monitoring.
Message (13) is the request from the personal assistant application for number and pound sign monitoring.
SUBSCRIBE sip:gw@subA.example.com SIP/2.0
Via: SIP/2.0/TCP pahost.example.com;branch=xzvsadf
From: <sip:pa@example.com>;tag=4rgj0f
To: <sip:gw@subA.example.com>
Call-ID: 93845@pahost.example.com
CSeq: 21 SUBSCRIBE
Contact: <sip:pa12@pahost.example.com>
Max-Forwards: 70
Event: kpml ;remote-tag="<sip:phn@example.com;tag=jfi23>"
;local-tag="sip:gw@subA.example.com;tag=oi43jfq"
;call-id="12345598@subA.example.com"
Expires: 7200
Accept: application/kpml-response+xml
Content-Type: application/kpml-request+xml
Content-Length: 332
SUBSCRIBE sip:gw@subA.example.com SIP/2.0 Via: SIP/2.0/TCP pahost.example.com;branch=xzvsadf From: <sip:pa@example.com>;tag=4rgj0f To: <sip:gw@subA.example.com> Call-ID: 93845@pahost.example.com CSeq: 21 SUBSCRIBE Contact: <sip:pa12@pahost.example.com> Max-Forwards: 70 Event: kpml ;remote-tag="<sip:phn@example.com;tag=jfi23>" ;local-tag="sip:gw@subA.example.com;tag=oi43jfq" ;call-id="12345598@subA.example.com" Expires: 7200 Accept: application/kpml-response+xml Content-Type: application/kpml-request+xml Content-Length: 332
<?xml version="1.0" encoding="UTF-8"?>
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
version="1.0">
<pattern persist="persist">
<regex tag="number">x{10}</regex>
<regex tag="#">#</regex>
</pattern>
</kpml-request>
<?xml version="1.0" encoding="UTF-8"?> <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"> <pattern persist="persist"> <regex tag="number">x{10}</regex> <regex tag="#">#</regex> </pattern> </kpml-request>
Burger & Dolly Standards Track [Page 50] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 50] RFC 4730 KPML November 2006
Message (18) is the notification of the number collected.
Message (18) is the notification of the number collected.
NOTIFY sip:pa@example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=xzvsadf To: <sip:pa@example.com>;tag=4rgj0f From: <sip:gw@subA.example.com>;tag=9788823 Call-ID: 93845@pahost.example.com CSeq: 3021 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3540 Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 278
NOTIFY sip:pa@example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=xzvsadf To: <sip:pa@example.com>;tag=4rgj0f From: <sip:gw@subA.example.com>;tag=9788823 Call-ID: 93845@pahost.example.com CSeq: 3021 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3540 Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 278
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
version="1.0"
code="200" text="OK" digits="3335551212" tag="number"/>
<?xml version="1.0" encoding="UTF-8"?> <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd" version="1.0" code="200" text="OK" digits="3335551212" tag="number"/>
Message (21) is the notification of pound sign detected.
Message (21) is the notification of pound sign detected.
NOTIFY sip:pa@example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=xzvsadf To: <sip:pa@example.com>;tag=4rgj0f From: <sip:gw@subA.example.com>;tag=9788823 Call-ID: 93845@pahost.example.com CSeq: 3022 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3540 Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 264
NOTIFY sip:pa@example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=xzvsadf To: <sip:pa@example.com>;tag=4rgj0f From: <sip:gw@subA.example.com>;tag=9788823 Call-ID: 93845@pahost.example.com CSeq: 3022 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3540 Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 264
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
version="1.0"
code="200" text="OK"
digits="#" tag="#"/>
<?xml version="1.0" encoding="UTF-8"?> <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd" version="1.0" code="200" text="OK" digits="#" tag="#"/>
Burger & Dolly Standards Track [Page 51] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 51] RFC 4730 KPML November 2006
Message (27) is the notification of long pound to the card application.
Message (27) is the notification of long pound to the card application.
NOTIFY sip:ap@client.subB.example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq To: <sip:ap@subB.example.com>;tag=978675 From: <sip:gw@subA.example.com>;tag=9783453 Call-ID: 12345601@subA.example.com CSeq: 3037 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3216 Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 256
NOTIFY sip:ap@client.subB.example.com SIP/2.0 Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq To: <sip:ap@subB.example.com>;tag=978675 From: <sip:gw@subA.example.com>;tag=9783453 Call-ID: 12345601@subA.example.com CSeq: 3037 NOTIFY Contact: <sip:gw27@subA.example.com> Event: kpml Subscription-State: active;expires=3216 Max-Forwards: 70 Content-Type: application/kpml-response+xml Content-Length: 256
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
version="1.0"
code="200" text="OK"
digits="#"/>
<?xml version="1.0" encoding="UTF-8"?> <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd" version="1.0" code="200" text="OK" digits="#"/>
11. References
11. References
11.1. Normative References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[3] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[3] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[4] 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.
[4] 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.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition Mechanisms",
BCP 66, RFC 3406, October 2002.
[6] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
Burger & Dolly Standards Track [Page 52] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 52] RFC 4730 KPML November 2006
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[8] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
May 2001.
[8] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001.
11.2. Informative References
11.2. Informative References
[9] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", Work in Progress, June 2006.
[9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, June 2006.
[10] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[10] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[11] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
(MGCP) Version 1.0", RFC 3435, January 2003.
[11] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[12] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
Control Protocol Version 1", RFC 3525, June 2003.
[12] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[13] Institute of Electrical and Electronics Engineers, "Information
Technology - Portable Operating System Interface (POSIX) - Part
1: Base Definitions, Chapter 9", IEEE Standard 1003.1,
June 2001.
[13] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 1: Base Definitions, Chapter 9", IEEE Standard 1003.1, June 2001.
[14] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC REC-xml-20001006, October 2000.
[14] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC REC-xml-20001006, October 2000.
[15] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)", Work in Progress,
July 2005.
[15] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work in Progress, July 2005.
[16] Burger, E., Van Dyke, J., and A. Spitzer, "Media Server Control
Markup Language (MSCML) and Protocol", RFC 4722, November 2006.
[16] Burger, E., Van Dyke, J., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 4722, November 2006.
[17] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[17] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[18] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
[18] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
Burger & Dolly Standards Track [Page 53] RFC 4730 KPML November 2006
Burger & Dolly Standards Track [Page 53] RFC 4730 KPML November 2006
Appendix A. Contributors
Appendix A. Contributors
Ophir Frieder of the Illinois Institute of Technology collaborated on the development of the buffer algorithm.
Ophir Frieder of the Illinois Institute of Technology collaborated on the development of the buffer algorithm.
Jeff Van Dyke worked enough hours and wrote enough text to be considered an author under the old rules.
Jeff Van Dyke worked enough hours and wrote enough text to be considered an author under the old rules.
Robert Fairlie-Cuninghame, Cullen Jennings, Jonathan Rosenberg, and we were the members of the Application Stimulus Signaling Design Team. All members of the team contributed to this work. In addition, Jonathan Rosenberg postulated DML in his "A Framework for Stimulus Signaling in SIP Using Markup" draft.
Robert Fairlie-Cuninghame, Cullen Jennings, Jonathan Rosenberg, and we were the members of the Application Stimulus Signaling Design Team. All members of the team contributed to this work. In addition, Jonathan Rosenberg postulated DML in his "A Framework for Stimulus Signaling in SIP Using Markup" draft.
This version of KPML has significant influence from MSCML [16], the SnowShore Media Server Control Markup Language. Jeff Van Dyke and Andy Spitzer were the primary contributors to that effort.
This version of KPML has significant influence from MSCML [16], the SnowShore Media Server Control Markup Language. Jeff Van Dyke and Andy Spitzer were the primary contributors to that effort.
Rohan Mahy did a significant reorganization of the content, as well as providing considerable moral support in the production of this document.
Rohanマーイはこのドキュメントの生産におけるかなりの精神的なサポートを提供することと同様に内容の重要な再編成をしました。
That said, any errors, misinterpretation, or fouls in this document are our own.
これでの誤り、誤解、または反則が、記録するそれは言って、いずれは私たち自身のです。
Appendix B. Acknowledgements
付録B.承認
Hal Purdy and Eric Cheung of AT&T Laboratories helped immensely through many conversations and challenges.
AT&T研究所のハルPurdyとエリック・チェンは多くの会話と挑戦で非常に助けました。
Steve Fisher of AT&T Laboratories suggested the digit suppression syntax and provided excellent review of the document.
AT&T研究所のスティーブ・フィッシャーは、ケタ抑圧構文を勧めて、ドキュメントの素晴らしいレビューを提供しました。
Terence Lobo of SnowShore Networks made it all work.
SnowShore NetworksのテレンスLoboはそれを皆、働かせました。
Jerry Kamitses, Swati Dhuleshia, Shaun Bharrat, Sunil Menon, and Bryan Hill helped with clarifying the buffer behavior and DRegex syntax.
ジェリーKamitses、Swati Dhuleshia、ショーンBharrat、Sunilメノン、およびブライアン・ヒルはバッファの振舞いとDRegex構文をはっきりさせるのに助けました。
Silvano Brewster and Bill Fenner of AT&T Laboratories and Joe Zebarth of Nortel helped considerably with making the text clear and DRegex tight.
AT&T研究所のシルヴァーノブリュースターとビル・フェナーとノーテルのジョーZebarthはテキストを明確にして、DRegexをきつくするのにかなり助けました。
Bert Culpepper and Allison Mankin gave an early version of this document a good scouring.
バート・カルペッパーとアリソン・マンキンはこのドキュメントの早めのバージョンに良い白痢を与えました。
Scott Hollenbeck provided XML and MIME review. Tim Bray pointed out the general issue of UTF-8 versus UTF-16 with XML.
スコットHollenbeckはXMLとMIMEであるなら論評します。 ティムBrayはXMLと共にUTF-8対UTF-16の一般答弁を指摘しました。
Burger & Dolly Standards Track [Page 54] RFC 4730 KPML November 2006
バーガーと台車標準化過程[54ページ]RFC4730KPML2006年11月
Authors' Addresses
作者のアドレス
Eric Burger Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
エリックバーガーカンタータ技術Inc.18Keewaydin礼拝堂ニューハンプシャー03079博士(米国)
EMail: eburger@cantata.com
メール: eburger@cantata.com
Martin Dolly AT&T Labs
マーチン台車AT&T研究室
EMail: mdolly@att.com
メール: mdolly@att.com
Burger & Dolly Standards Track [Page 55] RFC 4730 KPML November 2006
バーガーと台車標準化過程[55ページ]RFC4730KPML2006年11月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST, 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信用、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Burger & Dolly Standards Track [Page 56]
バーガーと台車標準化過程[56ページ]
一覧
スポンサーリンク
