Network Working Group E. Burger
Request for Comments: 4730 Cantata Technology, Inc.
Category: Standards Track M. Dolly
AT&T Labs
November 2006
Network Working Group E. Burger
Request for Comments: 4730 Cantata Technology, Inc.
Category: Standards Track M. Dolly
AT&T Labs
November 2006
A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)
用于按键刺激（KPML）的会话启动协议（SIP）事件包
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（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).
本文档描述了一个SIP事件包“kpml”，它支持双音多频（DTMF）信号的监控，并使用称为按键标记语言（kpml）的可扩展标记语言（XML）文档。kpml事件包可用于支持符合标题为“会话启动协议（SIP）中应用程序交互框架”的文件中定义的原则的应用程序。事件包使用SUBSCRIBE消息，并允许XML文档定义和描述用于捕获在无演示用户界面SIP用户代理（UA）中输入的按键（DTMF音调）的过滤器规范。事件包使用NOTIFY消息，并允许XML文档根据过滤器规范向应用程序服务器报告捕获的按键（DTMF音）。此软件包的范围用于收集补充按键或通话中按键（触发器）。
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. 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
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. 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
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.
本文档描述了一个SIP事件包“kpml”，它支持对按键进行监控，并利用称为按键标记语言（kpml）的XML文档。KPML是一种标记[14]，它支持应用程序交互框架[15]中描述的无表示用户界面。按键刺激包是一个SIP事件通知包[5]，它使用SIP的SUBSCRIBE和NOTIFY方法。订阅筛选器和通知报告主体使用键盘标记语言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请求和kpml响应定义两个新的MIME类型、两个新的URN子名称空间和两个模式。此软件包的范围用于收集补充按键或通话中按键（触发器）。此功能允许应用服务器服务提供商在位于最终用户设备或网关中的SIP用户代理上监视（过滤）一组DTMF模式。
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”事件包支持从哑电话接收信号的“哑电话”和“网关”报告用户按键事件。通俗地说，该机制提供“数字报告”或“双音多频（DTMF）报告”。该功能消除了通过媒体服务器“头发固定”（将媒体路由到同一设备中，然后再从同一设备中传出）或复制所有DTMF事件的需要，当应用服务器需要触发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.
XML文档的名称KPML反映了它的遗留支持角色。公共交换电话网（PSTN）通过在承载信道（带内信令）中将DTMF音调从用户终端传输到本地交换机来完成信令。
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.
IP语音网络使用实际DTMF波形或RFC 2833[10]数据包传输带内信号。在RFC 2833中，信令应用程序在媒体路径中插入RFC 2833命名的信号分组以及或者代替生成音调。接收应用程序接收媒体流中的信号信息。
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.
RFC 2833音非常适合在实时传输协议（RTP）流中以点对点的方式传输电话事件，如在直接会话（如两方通话或简单的中央混合会议）中。但是，在其他环境中，还需要附加或替代需求。这些其他环境包括协议转换和复杂的呼叫控制。
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.
感兴趣的应用程序可以请求每个按键的通知。然而，这种信令的许多用例表明，大多数应用程序只对一次或几次击键感兴趣。因此，需要一种机制来向用户界面指定应用程序需要什么样的刺激。
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.
RFC 2119[1]对本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”进行了解释。
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".
应用程序交互框架文件[15]对术语“用户设备”、“SIP应用程序”和“用户输入”进行了解释。本文件将术语“应用程序”和“请求应用程序”与“SIP应用程序”互换使用。
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.
此外，应用程序交互框架文档讨论了用户设备代理。用户设备代理的常见实例是公共交换电话网（PSTN）网关。由于无演示文稿的SIP用户代理和无演示文稿的用户设备代理的无演示文稿用户界面的规范行为是相同的，因此本文档对这两种情况都使用“用户设备”。
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方法使用显式订阅通知请求。想要收集数字的应用程序创建一个应用程序/kpml请求+xml文档，其中包含应用程序感兴趣的数字模式，并将此文档放置在其订阅请求中。使用标准SIP请求路由将SIP订阅消息路由到用户界面。KPML订阅不会分叉。SUBSCRIBE消息中包含的KPML请求通过引用与负责媒体流的会话对应的对话框标识符来标识目标媒体流。一旦建立订阅，当收集到数字或发生超时或错误时，用户界面将在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订阅可以是持久订阅，也可以是一次性订阅。持续请求一直处于活动状态，直到订阅终止、应用程序替换请求、应用程序通过在对话框上发送空文档删除请求，或者应用程序通过发送过期值为零（0）的订阅来显式删除订阅。
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.
一次性请求在收到提供匹配的DTMF值后终止订阅。“persist”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.
通知消息可以包含XML文档。如果用户界面与digitmap匹配，则通知消息（响应）包含一个XML文档，该文档指示检测到的用户输入以及用户界面是否抑制了来自媒体流的用户输入的表示，例如音调或RFC 2833。如果用户界面遇到错误情况，例如超时，也将报告此情况。
KPML recognizes two types of subscriptions: one-shot and persistent. Persistent subscriptions have two sub-types: continuous notify and single-notify.
KPML识别两种类型的订阅：一次性订阅和持久订阅。持久订阅有两个子类型：连续通知和单一通知。
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消息中发出报告后，一次性订阅终止。如果用户界面检测到触发一次性KPML事件的按键刺激，则用户界面（通知程序）必须将通知消息中的“订阅状态”设置为“已终止”。此时，用户界面必须考虑订阅过期。
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.
持久订阅在用户界面上保持活动状态，即使在匹配之后也是如此。对于连续通知持久订阅，每当用户输入与订阅模式匹配时，用户界面将发出通知消息。对于单通知持久订阅，用户设备将在第一次匹配时发出通知消息，但在应用程序在“订阅”对话框上发出新的订阅请求之前，不会发出进一步的通知消息。
NOTE: The single-notify persistent subscription enables lock-step (race-free) quarantining of User Input between different digit maps.
注意：单个notify持久订阅可在不同数字映射之间对用户输入进行锁定步骤（无竞争）隔离。
The "persist" attribute to the <pattern> tag in the KPML subscription body affects the lifetime of the subscription.
KPML订阅正文中<pattern>标记的“persist”属性会影响订阅的生存期。
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.
如果“persist”属性为“one shot”，则一旦存在匹配（或不可能存在匹配），订阅将在用户界面通知应用程序后结束。
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.
如果“persist”属性为“persist”或“single notify”，则当应用程序显式结束订阅或用户界面终止订阅时，订阅结束。
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.
如果用户界面不支持持久订阅，它将返回一条通知消息，其中KPML状态代码设置为531。如果缓冲区中有数字，并且这些数字与订阅筛选器中的表达式匹配，则用户界面将准备相应的NOTIFY响应消息。
The values of the "persist" attribute are case sensitive.
“persist”属性的值区分大小写。
To address the various key press collection scenarios, three timers are defined. They are the extra, critical, and inter-digit timers.
为了解决各种按键采集场景，定义了三个计时器。它们是额外的、关键的和数字间的计时器。
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 位数间计时器是位数之间等待的最长时间。注意：与媒体网关控制协议（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 如果收集的数字可以匹配多个潜在模式，则关键计时器是等待另一个数字的时间。
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 如果收集到的数字只能匹配一个潜在模式，但该模式的匹配时间可能更长，则额外计时器是等待另一个数字的时间。
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.
用户界面可支持位间超时值。这是用户界面在返回部分匹配模式的超时错误结果之前等待用户输入的时间量。应用程序可以通过使用<pattern>标记的“interdigittimer”属性将位间超时指定为整数毫秒。默认值为4000毫秒。如果用户界面不支持数字间超时的规范，则用户界面必须以静默方式忽略该规范。如果用户界面支持位间超时的指定，但不支持所提供的值指定的粒度，则用户界面必须将请求的值舍入到它可以支持的最接近的值。
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,
位间超时的目的是防止应用程序开始匹配模式，但永远不会返回结果。例如，如果用户意外输入一个开始匹配模式的密钥，则可能会发生这种情况。但是，由于用户意外地输入了密钥，因此该模式的其余部分永远不会出现。此外，当用户输入模式时，由于他们已经输入了密钥，
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.
模式可能不匹配，也可能不符合预期。同样，考虑用户认为他们输入了按键的情况，但是用户界面没有检测到密钥。这可能发生在采集10位数字时，但设备实际上只接收9位数字。在这种情况下，用户界面将永远等待第十次按键，而用户会沮丧地想知道为什么应用程序没有响应。
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.
用户界面可能支持关键数字超时值。这是当用户界面已经有一个匹配的<regex>但还有另一个更长的<regex>也可能匹配该模式时，用户界面将等待另一次按键的时间量。应用程序可以使用<pattern>标记的“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]不同，后者返回最短的匹配。例如，如果应用程序注册模式“0011”、“011”、“00”和“0”，则关键数字超时使用户界面能够区分“0”、“00”、“011”和“0011”。如果没有此功能，用户界面可以检测到的唯一值是“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.
用户界面可能支持额外的数字超时值。这是当用户界面已匹配最长的<regex>时，用户界面将等待另一次按键的时间量。应用程序可以通过使用<pattern>标记的“extradigittimer”属性将额外数字超时指定为整数毫秒。默认值为500毫秒。如果未指定enterkey，则用户界面可能会将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.
额外数字超时的目的是允许用户界面收集enterkey。如果没有此功能，用户界面将与模式匹配，enterkey将被缓冲并作为下一个模式返回。
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.
在订阅生存期内，用户界面可能检测到触发KPML事件的按键刺激。在这种情况下，用户界面（通知程序）必须返回相应的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用户界面必须遵循本节中介绍的逻辑，以便在给定相同用户输入的情况下，不同的实现将在相同的KPML文档上决定性地执行。
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>标记的<pattern>元素。每个<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.
模式匹配算法匹配最长的正则表达式。这是与H.248.1[12]相同的模式，而不是MGCP[11]提出的模式。模式匹配算法的选择对确定模式匹配的时间有影响。考虑下面的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 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>
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中，如果我们要匹配第一个找到的模式，字符串“011”将永远不会匹配。发生这种情况是因为“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>x{7}</regex>
<regex>x{10}</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秒）。相反，用户不希望系统将他们的10位数字截断为7位数字，因为他们输入数字的速度不够快。
One approach to this problem is to have an explicit dial string terminator. Often, it is the pound key (#). Now, consider the following snippet.
解决此问题的一种方法是使用显式拨号字符串终止符。通常，它是磅键（#）。现在，考虑下面的代码片段。
<regex>x{7}#</regex>
<regex>x{10}#</regex>
<regex>x{7}#</regex>
<regex>x{10}#</regex>
Figure 3: Timeout Matching with Enter
图3：与Enter匹配的超时
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中的方法的问题是“#”将出现在返回的拨号字符串中。此外，人们通常希望允许用户在不使用拨号字符串终止键的情况下输入字符串。此外，在键上使用显式匹配意味着必须将模式的数量增加一倍，例如，“x{7}”、“x{7}#”、“x{10}”和“x{10}”。
The approach used in KPML is to have an explicit "Enter Key", as shown in the following snippet.
KPML中使用的方法是使用一个显式的“Enter键”，如下面的代码段所示。
<pattern enterkey="#">
<regex>x{7}</regex>
<regex>x{10}</regex>
</pattern>
<pattern enterkey="#">
<regex>x{7}</regex>
<regex>x{10}</regex>
</pattern>
Figure 4: Timeout Matching with Enter Key
图4：与Enter键匹配的超时
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中，<pattern>标记的enterkey属性指定了一个终止模式的字符串。在这种情况下，如果用户输入七位数字，后跟“#”键，则模式立即匹配（或失败）。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使用“L”修饰符<regex>字符来表示长时间按键。下面的KPML文档查找至少3秒的长磅。
<?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 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>
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属性设置为<pattern>来指定构成“long”的内容。此属性是一个整数，表示毫秒数。如果用户按下某个键的时间超过“long”毫秒，则long修饰符为true。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文档在文档中同时指定长输入和短输入时，用户界面必须区分长输入和短输入。但是，如果文档中没有相应的长按键模式，则无论用户按键的时间长短，用户界面都必须与按键模式匹配。
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中的以下代码片段中，用户界面区分长“*”和普通“*”，但任何长度“#”都将匹配该模式。
<pattern>
<regex tag="short_star">*</regex>
<regex tag="long_star">L*</regex>
<regex>#</regex>
</pattern>
<pattern>
<regex tag="short_star">*</regex>
<regex tag="long_star">L*</regex>
<regex>#</regex>
</pattern>
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".
某些用户界面无法显示长时间按键。一个例子是旧的专用交换机（PBX）电话，当用户按键时会发出固定长度的铃声。为了解决这个问题，用户界面可以将单个按键的连续按下解释为等同于相同按键的长按键按下。应用程序通过将<pattern>的“longrepeat”属性设置为“true”来表示它想要这种行为。
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文档通过将<pattern>标记的“persist”属性设置为“persist”或“singlenotify”来指定模式是否要持久化。任何其他值，包括“一次性”表示
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.
该请求是一次性订阅。如果用户界面不支持持久订阅，它将返回KPML状态代码设置为531的KPML文档。如果缓冲区中有数字，并且这些数字与KPML文档中的表达式匹配，则用户界面将发出相应的KPML通知。
Note the values of the "persist" attribute are case sensitive.
注意，“persist”属性的值区分大小写。
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.
某些用户界面可能支持给定模式请求中的多个正则表达式。在这种情况下，应用程序可能希望知道触发事件的模式。
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>标记提供了一个“tag”属性。“标记”是一个不透明字符串，用户界面在数字映射中匹配后在通知报告中发回该字符串。如果有多个匹配项，用户界面必须选择KPML文档中最长的匹配项。如果多个匹配项匹配相同的长度，则用户界面必须根据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.
如果用户界面不能支持模式请求中的多个正则表达式，则用户界面必须返回KPML状态代码设置为532的KPML文档。如果用户界面无法支持模式请求中的正则表达式数量，则用户界面必须返回KPML状态代码设置为534的KPML文档。
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.
注意：我们可以强制每个订阅请求和全局用户界面必须支持的正则表达式的最小数量。然而，这样的最小值往往被设计成硬编码的限制。作为指导，每个订阅应该能够轻松处理数十个表达式，并在全球范围内处理数千个表达式。一个好的实现应该没有限制。这就是说，为了对付可能的拒绝服务攻击，用户界面的实现者应该知道534和501状态码，并且可以随意使用它们。
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用户界面将与用户输入报告并行传输带内音调（RFC 2833[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的用户界面很容易破坏被调用的应用程序。例如，以一个使用“*9”表示注意的私人助理为例。如果用户按下“*”键，KPML将保持数字，查找“9”。如果用户可能只是输入了一个“*”键，该怎么办
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系统没有听到按键声。此时，用户界面将发送两个“*”条目，因为“*”与“*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将抑制标记“pre”添加到<regex>标记中。任何给定的<regex>标记中不得有多个<pre>标记。
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.
如果只有一个<pattern>和一个<regex>，则抑制处理非常简单。端点传递用户输入，直到流匹配正则表达式<pre>。此时，用户界面将继续收集用户输入，但将抑制任何带内用户输入的生成或传递。
If the User Interface suppressed stimulus, it MUST indicate this by including the attribute "suppressed" with a value of "true" in the notification.
如果用户界面抑制了刺激，则必须通过在通知中包含值为“true”的属性“抑制”来指示这一点。
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".
显然，如果用户界面正在根据缓冲用户输入处理KPML文档，那么抑制用户输入的传输为时已晚，因为用户界面早就发送了刺激。这种情况下，存在<pre>规范，但通知中的“抑制”属性将不为“真”。如果存在用户界面匹配的<pre>标记且用户界面无法抑制用户输入，则必须将“抑制”属性设置为“false”。
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用户界面可以执行抑制。如果无法抑制，则忽略抑制属性。它必须将“抑制”属性设置为“false”。在这种情况下，要匹配的模式是pre+value的串联模式。
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.
在某个时间点，用户界面将收集足够的用户输入，以匹配<pre>模式。interdigittimer属性指示用户在报告超时错误之前等待输入刺激的时间。如果interdigittimer过期，用户界面必须发出超时报告，在媒体流上传输被抑制的用户输入，并停止抑制。
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.
一旦用户界面检测到匹配并发送通知请求以报告用户输入，用户界面必须停止抑制。显然，如果后续用户输入与另一个<pre>表达式匹配，则用户界面必须开始抑制。
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><pre>*8</pre>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.
当用户界面接收到“*8”时，它将停止转发刺激。让我们假设接下来的三位数字是“408”。如果下一个数字是零或一，则模式将不匹配。
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.
注意：对于用户界面来说，有一个合理的数字间计时器是至关重要的。这是因为错误的点（“.”）可能永远抑制数字发送。
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 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.
用户界面必须在收到经过身份验证和接受的订阅时缓冲用户输入。随后的KPML文档将其模式应用于缓冲用户输入。一些应用程序使用模式界面，其中前几次按键决定了以下按键的含义。对于新手用户，应用程序可能会播放一个提示，说明应用程序处于何种模式。然而，“超级用户”经常会在提示中打岔。
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.
用户界面不得向订阅服务器提供在该订阅服务器的身份验证和授权之前检测到的数字。在没有禁止的情况下，用户可能能够访问电话卡或用户参与呼叫之前的其他信息。请注意，此禁令必须在每次订阅的基础上适用。
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在<pattern>元素中提供了一个<flush>标记。默认情况下不刷新用户输入。刷新用户输入会忽略在安装KPML订阅之前输入的按键。要刷新用户输入，请包含标记
<flush>yes</flush> in the KPML subscription document. Note that this directive affects only the current subscription dialog/id combination.
KPML订阅文档中的<flush>是</flush>。请注意，此指令仅影响当前订阅对话框/id组合。
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".
用户输入的锁定步骤处理是指用户界面发出通知，应用程序在用户界面缓冲其他用户输入时处理通知，应用程序请求更多用户输入，然后用户界面才根据收集的用户输入通知应用程序。要指示用户界面在锁定步骤模式下操作，请设置<pattern>属性persist=“single notify”。
The User Interface MUST be able to process <flush>no</flush>. This directive is effectively a no-op.
用户界面必须能够处理<flush>否</flush>。该指令实际上是禁止操作的。
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.
将来可能会定义<flush>的其他字符串值。如果用户界面收到一个它不理解的字符串，它必须将该字符串视为no-op。
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>标记内的任何模式都不匹配，则用户界面必须根据给定对话框上的当前或未来KPML文档放弃所有缓冲按键（包括当前按键）。然而，如上所述，一旦存在匹配，用户界面将缓冲用户在匹配之后输入的任何按键。
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.
注意：此行为允许应用程序只接收他们感兴趣的用户输入。例如，预付费应用程序只希望监控长磅。如果用户输入其他刺激，可能是针对其他应用程序，预付费应用程序不希望收到该用户输入的通知。此功能与基于时分多路复用器（TDM）的设备的行为有着根本的不同，在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.
要将报告限制为仅完成匹配，请将<pattern>标记的“nopartial”属性设置为“true”。在这种情况下，用户界面尝试在收集的用户输入上匹配滚动窗口。
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订阅是独立的。因此，当前文档不可能知道以下文档是否将启用驳船或希望刷新用户输入。因此，用户界面必须缓冲所有用户输入，并遵守下面描述的强制刷新警告。
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.
在具有给定id的给定订阅对话框上，用户界面必须缓冲在报告时间和接收下一个文档（如果有）之间检测到的所有用户输入。如果下一个文档指示缓冲区刷新，则解释器必须使用给定的事件id刷新从该对话框上接收的KPML文档中收集的所有用户输入。如果下一个文档未指示刷新缓冲区用户输入，则解释器必须应用收集的用户输入（如果可能）根据脚本的<regex>标记显示的数字映射。如果存在匹配项，口译员必须遵循第5.3节中的程序。如果没有匹配项，解释器必须刷新所有收集的用户输入。
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".
考虑到用户输入可能需要无限缓冲区，用户界面可能会丢弃缓冲区中最旧的用户输入。如果用户界面丢弃数字，当用户界面发出KPML通知时，它必须将<response>标记的强制刷新属性设置为“true”。为了将来使用，应用程序必须考虑除“false”以外的任何非空值，它不理解与“true”相同。
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.
注意：在正常操作下，在整个会话期间缓冲所有用户输入的要求并不繁重。例如，如果一个网关具有8000个会话，并且网关在每个会话上缓冲50次按键，那么假设每个按键一个字节，则要求仅为400000字节。
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.
除非数字映射中有抑制指示符，否则无法知道用户输入是用于本地KPML处理还是用于媒体流的其他收件人。因此，在没有抑制指示符的情况下，用户界面使用RFC 2833（生成适当的音调）或两者之一实时地将用户输入发送到远端。
This subsection is informative in nature.
本小节内容丰富。
The Digit REGular EXpression (DRegex) syntax is a telephony-oriented mapping of POSIX Extended Regular Expressions (ERE) [13].
数字正则表达式（DRegex）语法是POSIX扩展正则表达式（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通常在高密度或极低功耗和内存占用的设备上运行。
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 电话应用程序约定使用星形符号（“*”）作为星形键，使用“x”作为任何数字0-9。要求开发人员转义星号（\*”）并展开“x”（“[0-9]”）容易出错。这也导致DRegex使用点（“.”）来表示重复，这是POSIX ERE中未修饰恒星的功能。
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]的实施经验是，实施者和用户很难理解交替运算符（“|”）的优先级。这是由于这些文件中操作员的规格不足以及用户的概念问题造成的。因此，啜饮工作组得出结论，DRegex不应支持替代。也就是说，每个KPML<pattern>元素可能包含多个正则表达式（<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和*，规范应为“[0-9A-D*]”，而不是“[^#R]”。
The following table shows the mapping from DRegex to POSIX ERE.
下表显示了从DRegex到POSIX的映射。
+--------+-----------+
| DRegex | POSIX ERE |
+--------+-----------+
| * | \* |
| . | * |
| x | [0-9] |
| [xc] | [0-9c] |
+--------+-----------+
+--------+-----------+
| DRegex | POSIX ERE |
+--------+-----------+
| * | \* |
| . | * |
| x | [0-9] |
| [xc] | [0-9c] |
+--------+-----------+
Table 1: DRegex to POSIX ERE Mapping
表1:DRegex到POSIX ERE映射
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的常用指示符。我们在这里使用它，延续传统。显然，在“[xc]”的情况下，c是任意字符，替换不是盲目地将“[0-9]”替换为“x”，因为这将导致“[[0-9]c]”，这不是一个合法的POSIX。相反，对“[xc]”的替换是“[0-9c]”。
NOTE: "x" does not include the characters *, #, R, or A through D.
注：“x”不包括字符*、#、R或A到D。
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 ERE混淆。它们并不完全相同。特别是，DRegex不支持POSIX ERE的许多功能。
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.
作为实现说明，如果进行上表中描述的替换，则标准POSIX ERE引擎可以解析数字字符串。但是，映射在相反方向（POSIX ERE到DRegex）不起作用。DRegex仅实现以下描述的规范行为。
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。
+---------+---------------------------------------------------------+
| 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 *. |
+---------+---------------------------------------------------------+
+---------+---------------------------------------------------------+
| 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 *. |
+---------+---------------------------------------------------------+
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 |
+--------------+--------------------------------------------+
+--------------+--------------------------------------------+
| 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 |
+--------------+--------------------------------------------+
DRegex Examples
DRegex示例
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通过对话框标识符标识对话框。对话框标识符是RFC 3261[4]中定义的远程标记、本地标记和调用ID实体。
One method of determining the dialog identifier, particularly for third-party applications, is the SIP Dialog Package [17].
确定对话标识符的一种方法，特别是对于第三方应用程序，是SIP对话包[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.
对于大多数情况，例如使用单个编解码器的单耳点对点呼叫，要监视的流是显而易见的。在这种情况下，应用程序不需要指定要监视的流。
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流。例如，一个对话框可能有多个音频流。在可能的情况下，用户界面可以应用本地策略来消除要监视的一个或多个流的歧义。为了具有用于识别流的可扩展机制，用于指定流的机制作为<stream>标记的元素内容。今天定义的唯一内容是<stream>reverse</stream>标记。
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.
默认情况下，用户界面监视从用户界面发出的按键。给定调用ID、本地标记和远程标记的对话框标识符，用户界面将监视与本地标记关联的按键。
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.
在媒体代理和其他可能的情况下，需要监控来自远程用户代理的按键。<request>标记的可选<stream>元素指定要监视的流。唯一合法的值是“reverse”，这意味着监视与远程标记关联的流。用户界面必须忽略其他值。
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.
注意：这是一个标记的原因是，如果需要，可以以向后兼容的方式处理单个流选择。要监控的流的进一步规范是未来标准化的主题。
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
应用程序可以在单个KPML订阅中注册多个用户输入模式。如果用户界面支持多个同时的KPML订阅，则应用程序将在新的“订阅启动”对话框或具有新事件id标记的现有“订阅启动”对话框中安装订阅。如果用户界面不支持多个同时KPML
subscriptions, the User Interface MUST respond with an appropriate KPML status code.
订阅时，用户界面必须使用适当的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.
某些用户界面可能同时支持多个按键事件通知订阅。在这种情况下，用户界面会单独和独立地接受每个订阅。
A SIP user agent may request multiple subscriptions on the same SUBSCRIBE dialog, using the id parameter to the kpml event request.
SIP用户代理可以使用kpml事件请求的id参数在同一个订阅对话框上请求多个订阅。
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.
一个或多个SIP用户代理可以在不同的SIP对话框上请求独立订阅，但不建议对多个订阅重复使用同一对话框。
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.
如果用户界面不支持多个同时订阅，则用户界面必须在请求第二次订阅的对话框上返回KPML状态代码设置为533的KPML文档。用户界面不得因第二次订阅尝试而修改第一次订阅的状态。
This document defines a SIP Event Package as defined in RFC 3265 [5]. The event-package token name for this package is:
本文档定义了RFC 3265[5]中定义的SIP事件包。此包的事件包令牌名称为：
"kpml"
“kpml”
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.
此包定义三个事件包参数：调用id、远程标记和本地标记。这些参数必须存在，以标识订阅对话框。用户界面将本地标记与to标记匹配，远程标记与from标记匹配，调用id与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如下所示。它引用了RFC3261的ABNF中的许多构造，例如EQUAL、DQUOTE和token。
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
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
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.
如果任何调用ID包含嵌入的双引号，则必须使用反斜杠引用机制对这些双引号进行转义。请注意，调用id参数可能需要表示为带引号的字符串。这是因为callid生产的ABNF和callid（均来自RFC 3261[1]）使用的单词production允许标记中不允许的某些字符（如“@”、“[”和“：”）。
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.
使用此事件包的应用程序在SUBSCRIBE请求中包含application/kpml request+xml正文，以指示它们感兴趣的数字模式。第5.2节正式描述了该主体类型的语法。
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.
订阅生存期应长于预期的调用时间。对此事件包的订阅可能在几分钟到几周之间。以小时或天为单位的订阅更为典型，建议使用。此事件包的默认订阅持续时间为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值小于请求值的用户界面。根据RFC 3265[5]，订阅持续时间是通知程序在200 OK Expires标头中返回的值。
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.
通知请求可以包含应用程序/kpml响应+xml（kpml响应）主体。第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.
通知程序可以使用订阅者可接受的任何格式发送通知（基于订阅者在Accept标头中包含这些格式）。将来的扩展可能会定义其他通知机构。如果订阅中没有“Accept”标题，则必须采用本文档中定义的正文类型。
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>标记的<pattern>元素。每个<regex>元素指定用户界面要匹配的潜在模式。第5.1节描述了DRegex或数字正则表达式语言。
KPML specifies key press event notification filters. The MIME type for KPML requests is application/kpml-request+xml.
KPML指定按键事件通知筛选器。KPML请求的MIME类型是application/KPML request+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请求文档必须格式正确且有效。KPML文档必须符合XML 1.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报告的信息具有潜在的敏感性，订阅者应该使用sips:并且可以在内容上使用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.
订阅者必须准备好让通知者坚持对订阅请求进行身份验证。订阅者必须为通知者坚持使用安全通信通道做好准备。
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 Interfaces MUST implement SIP Digest authentication as required by RFC 3261 [4] and MUST implement the sips: scheme and TLS.
用户界面必须按照RFC 3261[4]的要求实施SIP摘要认证，并且必须实施sips:scheme和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.
在认证请求方之后，用户界面确定请求方是否具有监视用户按键的授权。默认的授权策略是允许能够使用特定身份进行身份验证的KPML订阅者从SIP会话中监控按键操作，其中相同或等效的身份验证是参与者。此外，KPML通常会在由同一域或域联盟操作的“应用程序服务器”（订阅者）和PSTN网关（通知者）之间使用。在这种情况下，通知程序可以配置有订阅者列表，订阅者被特别信任并授权订阅与特定上下文中的所有会话相关的按键信息。
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.
用户界面返回一个联系人URI，该URI在SIP INVITE、1xx或2xx响应的联系人标头中可能具有GRUU[9]属性。
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.
授权请求后，用户界面将检查请求是否要终止订阅。如果请求将终止订阅，则用户界面将进行适当的处理，包括第5.2节所述的过程。
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正文，则在该对话框上运行并由事件id（如果存在）寻址的任何KPML文档立即终止。这是一种卸载KPML文档的机制，同时保持“订阅启动”对话框处于活动状态。这对于会话建立成本较高的安全会话来说非常重要。用户界面遵循第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订阅引用的对话框不存在，则用户界面将遵循第5.3节中的步骤。注意，用户界面必须在发出通知之前向订阅请求发出200OK，因为订阅本身格式良好。
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正文，则用户界面将解析KPML文档。用户界面应根据第5.2节中给出的模式验证XML文档。如果文档无效，用户界面将拒绝订阅请求，并给出相应的错误响应，并终止订阅。如果订阅上有已加载的KPML文档，则用户界面将卸载该文档。
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.
按照SUBSCRIBE的语义，如果用户界面收到重新订阅，则用户界面必须终止现有的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使用可能会终止。这里列举的情况包括显式订阅终止、自动订阅终止和底层（邀请启动）对话框终止。
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".
如果订阅请求的过期时间为零（显式订阅终止），包含KPML文档，并且存在缓冲用户输入，则用户界面将尝试针对文档处理缓冲数字。如果存在匹配项，则用户界面必须生成KPML状态代码为200的适当KPML报告。SIP NOTIFY body通过将订阅状态设置为“已终止”和“超时”的原因来终止订阅。
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正文或订阅启动对话框上的过期计时器，则用户界面必须发出KPML报告，其中KPML状态代码为487，订阅已过期。该报告还包括在expires计时器过期或处理expires等于零的订阅之前收集的用户输入。这可能是空字符串。
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".
根据RFC 3265[5]的机制，用户界面必须终止SIP订阅对话框。用户界面通过传输前段所述最终报告的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".
如果订阅请求引用了用户界面上不存在的对话框，则用户界面必须生成一个KPML报告，该报告的KPML状态代码为481，dialog not Found。用户界面通过将订阅状态设置为“已终止”来终止订阅。
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文档无效，则用户界面将生成一个KPML报告，其中KPML状态代码为501，错误文档。用户界面通过将订阅状态设置为“已终止”来终止订阅。
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.
如果文档有效，但用户界面不支持文档中的命名空间，则用户界面必须使用KPML状态代码502“命名空间不受支持”进行响应。
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.
接受订阅后，通知程序必须立即根据订户的身份发送包含当前位置信息的通知。这允许订阅服务器重新同步其状态。
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.
用户界面（SUBSCRIBE/NOTIFY术语中的通知程序）根据RFC 3265[5]的要求生成通知请求。具体来说，如果订阅请求有效且经过授权，则会立即发出通知。
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有效负载区分初始通知和按键通知。如果订阅时没有缓冲的用户输入（见下文），或者缓冲的用户输入与新的KPML文档不匹配，则立即通知不得包含KPML正文。如果用户界面缓冲了用户输入，从而使用新的KPML文档进行匹配，则通知必须返回相应的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.
如果没有匹配的缓冲数字，则响应订阅请求的NOTIFY没有KPML。图10给出了一个例子。
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 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
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类型是application/KPML response+xml。kpml事件包的默认MIME类型是application/kpml response+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.
如果请求者没有为每个跃点使用安全传输协议，如TLS（例如，通过使用sips:URI），则用户界面应使用S/MIME来保护响应中的用户信息。
When the user enters key presses that match a <regex> tag, the User Interface will issue a report.
当用户输入与<regex>标记匹配的按键时，用户界面将发出报告。
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会话，除非订阅具有持久性指示符。如果订阅没有持久性指示符，则用户界面必须在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的“一次性”特性，反映了特性的平衡和实现解释器的容易程度。
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报告有两个必需属性：代码和文本。这些属性描述用户界面上KPML解释器的状态。注意KPML状态代码不一定与SIP结果代码相关。这方面的一个重要示例是，合法的SIP订阅请求获得正常的SIP 200 OK，然后是NOTIFY，但KPML请求有问题。在这个
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.
在这种情况下，通知将在KPML报告中包含KPML状态代码。注意，从SIP的角度来看，SUBSCRIBE和NOTIFY是成功的。此外，如果KPML故障无法恢复，则用户界面很可能会将订阅状态设置为“已终止”。这使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".
如果模式匹配，用户界面将发出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报告包括数字属性中匹配的实际数字。数字字符串分别使用星号和八达通号的常规字符“*”和“#”。如果匹配数字的正则表达式具有标记属性，则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".
如果订阅请求数字抑制，并且用户界面抑制了数字，则抑制属性指示“true”。抑制的默认值为“false”。
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不包括时间戳。原因有很多。首先，它将包括什么时间戳？是否是第一次检测到按键的时间？解释器收集整个字符串的时间？射程？第二，如果RTP时间戳是一个有趣的数据，为什么不首先简单地获取RTP呢？综上所述，如果在响应中具有时间戳真的很有吸引力，那么它可能是<response>标记的一个属性。
Note that if the monitored (INVITE-initiated) dialog terminates, the notifier still MUST explicitly terminate the KPML subscriptions monitoring that dialog.
请注意，如果受监视（邀请启动）对话框终止，通知程序仍必须显式终止监视该对话框的KPML订阅。
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正文，则表示订阅成功。如果没有要报告的缓冲用户输入，则会建立对话框。
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文档，且KPML状态代码介于400和499之间，则用户输入集合发生错误。最可能的原因是超时情况。
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文档，且KPML状态代码介于500和599之间，则订阅发生错误。有关KPML状态代码含义的更多信息，请参见第6节。
The subscriber MUST be mindful of the subscription state. The User Interface may terminate the subscription at any time.
订户必须注意订阅状态。用户界面可随时终止订阅。
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.
此事件类型不允许分叉请求。如果将对此事件包的订阅发送到具有GRUU属性的SIPURI，则可以确保这一点。
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".
用户界面生成消息的速度不得超过每秒25条消息，或每40毫秒生成一条消息。这是MF数字溢出的最短时间段。即使是30毫秒的DTMF，正如人们有时在日本发现的那样，也有20毫秒的关闭时间，导致50毫秒的交指时间。本文档强烈建议不要将KPML用于逐位消息传递，例如，如果唯一的<regex>是“x”，则会出现这种情况。
The sustained rate of notification shall be no more than 100 Notifies per minute.
持续通知率不得超过每分钟100次通知。
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.
用户界面必须可靠地传递通知。由于没有有效的限制请求的指标，用户界面应该通过拥塞控制传输（如TCP）发送NOTIFY消息。
Note that all SIP implementations are already required to implement SIP over TCP.
请注意，通过TCP实现SIP已经需要所有SIP实现。
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请求被发送到特定的SIPURI，该URI可能具有GRUU属性，并且它们尝试监视与特定目标对话框对应的特定流。因此，实现者不得定义此事件包的状态代理，也不得允许使用事件列表扩展将此事件包订阅到资源列表[18]。
There are no additional requirements on a SIP Proxy, other than to transparently forward the SUBSCRIBE and NOTIFY methods as required in SIP.
除了按照SIP中的要求透明地转发SUBSCRIBE和NOTIFY方法外，SIP代理没有其他要求。
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.
以下定义遵循RFC 4234[2]。数字的定义来自RFC 4234，即字符“0”到“9”。注意，DRegexCharacter不是来自RFC 4234的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
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
ABNF for DRegex
德雷杰克斯银行
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.
请注意，本文档的未来扩展可能会在H.248.1[12]的方案中为DRegexCharacter引入其他字符，或者可能作为命名字符串或XML名称空间。
The following syntax for KPML requests uses the XML Schema [8].
KPML请求的以下语法使用XML模式[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 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>
<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">
<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
图12:KPML请求的XML模式
The following syntax for KPML responses uses the XML Schema [8].
KPML响应的以下语法使用XML模式[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
KPML响应的XML模式
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状态代码大致遵循其SIP对应项。以2开头的代码表示成功。以4开头的代码表示故障。以5开头的代码表示服务器故障，通常是无法解释文档或支持请求的功能。
KPML clients MUST be able to handle arbitrary status codes by examining the first digit only.
KPML客户端必须能够通过仅检查第一位数字来处理任意状态代码。
Any text can be in a KPML report document. KPML clients MUST NOT interpret the text field.
任何文本都可以在KPML报告文档中。KPML客户端不能解释文本字段。
+------+--------------------------------------------------+
| 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
表4:KPML状态代码
This document registers a new SIP Event Package, two new MIME types, and two new XML namespaces.
本文档注册了一个新的SIP事件包、两个新的MIME类型和两个新的XML名称空间。
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
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媒体类型名称：应用程序MIME子类型名称：kpml请求+xml必需参数：无可选参数：与xml媒体类型[3]中指定的字符集参数application/xml相同编码注意事项：请参阅RFC 3023[3]。安全注意事项：参见RFC 3023[3]第10节和RFC 4730第8节互操作性注意事项：参见RFC 2023[3]和RFC 4730发布的规范：使用此媒体类型的RFC 4730应用程序：具有原始用户界面的面向会话的应用程序。变更控制员：从IESG个人和电子邮件地址授权的啜饮工作组获取更多信息：Eric Burger<e。burger@ieee.org>预期用途：普通
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媒体类型名称：应用程序MIME子类型名称：kpml响应+xml必需参数：无可选参数：与xml媒体类型[3]中指定的字符集参数application/xml相同编码注意事项：请参阅RFC 3023[3]。安全注意事项：参见RFC 3023[3]第10节和RFC 4730第8节互操作性注意事项：参见RFC 2023[3]和RFC 4730发布的规范：使用此媒体类型的RFC 4730应用程序：具有原始用户界面的面向会话的应用程序。变更控制员：从IESG个人和电子邮件地址授权的啜饮工作组获取更多信息：Eric Burger<e。burger@ieee.org>预期用途：普通
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>
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>
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>
Per RFC 3688 [7], IANA registered the XML Schema for KPML as referenced in Section 5.2 of RFC 4730.
根据RFC 3688[7]，IANA注册了RFC 4730第5.2节中引用的KPML的XML模式。
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>
Per RFC 3688 [7], IANA registered the XML Schema for KPML as referenced in Section 5.3 of RFC 4730.
根据RFC 3688[7]，IANA注册了RFC 4730第5.3节中引用的KPML的XML模式。
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>.
注册人联系人：IETF，啜饮工作组<sipping@ietf.org>，埃里克·伯格。burger@ieee.org>.
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.
KPML传输的用户信息可能是敏感的。例如，它可以包括电话卡或信用卡号码。如果通知程序未正确验证或授权订阅，则可能会意外提供此潜在的私有信息。类似地，如果会话中先前缓冲的数字被无意地提供给新订户，则私人信息（如信用卡号或电话卡号）可能会泄露给其他合法订户（操作IVR的订户）。
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.
同样，窃听者可以查看未加密的KPML数字信息，或者攻击者可以插入欺诈性通知，除非消息或它们所经过的SIP路径受到完整性保护。
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.
作为XML标记，必须满足RFC 3023[3]和RFC 3406[6]的所有安全注意事项。请特别注意解析XML的健壮性要求。
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.
按键信息可能很敏感。例如，它可以表示信用卡、电话卡或其他个人信息。劫持会话允许未经授权的实体访问此敏感信息。因此，信号应是安全的，例如，应使用TLS和sips。此外，信息本身是敏感的，因此应使用S/MIME或其他适当的机制。
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.
订阅必须以某种方式进行身份验证。按照核心SIP[4]规范的要求，所有SIP实现都必须支持摘要认证。此外，用户界面必须实现对sips:scheme和SIP over TLS的支持。订阅者必须期望用户界面要求使用身份验证方案。如果用户界面的本地策略是使用身份验证或安全通信通道，则用户界面必须拒绝不符合该策略的订阅请求。
User Interfaces MUST begin buffering User Input upon receipt of an authenticated and accepted subscription. This buffering is done on a per-subscription basis.
用户界面必须在收到经过身份验证和接受的订阅后开始缓冲用户输入。此缓冲是在每个订阅的基础上完成的。
This section is informative in nature. If there is a discrepancy between this section and the normative sections above, the normative sections take precedence.
本节内容丰富。如果本节与上述规范性章节之间存在差异，则以规范性章节为准。
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.
预付费和个人助理应用程序的一个常见需求是监视对话，以获取一个信号，该信号指示用户焦点从他们通过应用程序呼叫的一方到应用程序本身的变化。例如，如果您使用预付费电话卡呼叫一方，而您呼叫的另一方会将您重定向到语音邮件，则您按下的数字代表语音邮件系统。但是，许多应用程序都有一个特殊的键序列，例如octothorpe（#，或pound符号）或*9，用于终止被叫方会话并将用户的注意力转移到应用程序上。
Figure 16 shows the KPML for long octothorpe.
图16显示了长OctorThorpe的KPML。
<?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
长图16：长索普
The regex value L indicates the following digit needs to be a long-duration key press.
正则表达式值L表示以下数字需要长时间按键。
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.
在本例中，用户界面收集拨号字符串。应用程序使用KPML快速确定用户何时输入目标号码。此外，KPML指示用户输入的号码类型。
<?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
图17：拨号字符串KPML示例代码
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
注意使用“tag”属性来指示哪个正则表达式与拨号字符串匹配。这里有趣的例子是，如果用户输入“94015551212”。此字符串与“9401xxxxxxx”和
"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.
“9xxxxxxxxx”正则表达式。两个表达式的长度相同。因此，KPML解释器将选择“9401xxxxxxx”字符串，因为它在文档顺序中首先出现。图18显示了响应。
<?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
图18：拨号字符串KPML响应
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.
本节给出了收集补充数字的应用程序的非规范性示例。补充数字收集是在呼叫者输入目标地址后，网络请求额外数字的地方。典型的补充拨号串长度为四位数。
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
图19：补充数字呼叫流
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.
在消息（1-3）中，入口网关与出口网关建立对话。应用程序通过带外机制学习对话ID，例如对话包或与出口网关共存。下面是ACK消息的一部分，以说明对话框标识符。
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 ...
确认sip：gw@subA.example.comSIP/2.0通过：。。。最大前锋：。。。路线：。。。发件人：<sip:phn@example.com>;标签=jfh21至：<sip:gw@subA.example.com>;tag=onjwe2调用ID:12345592@subA.example.com ...
In message (4), the application the requests that gateway collect a string of four key presses.
在消息（4）中，应用程序请求网关收集四次按键的字符串。
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>
Message (5) is the acknowledgement of the subscription request.
消息（5）是对订阅请求的确认。
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.
消息（6）是订阅的即时通知。
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.
消息（7）是对通知消息的确认。
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).
一段时间过去了（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".
用户输入输入。设备在消息（9）中提供收集的数字的通知。由于这是一次性订阅，请注意订阅状态为“已终止”。
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.
消息（10）是对通知的确认。
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
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.
为清楚起见，我们不显示邀请对话框。
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) |
|--------------------->| |
| | |
| | |
|(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) | |
|.............................................|
| | |
| | |
|(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
图27：多应用程序调用流
Message (1) is the subscription request for the card number.
消息（1）是卡号的订阅请求。
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
<?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.
为简洁起见，未显示消息（2-4）。消息（6）是卡号的通知。
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"/>
Message (7) is the acknowledgement of the notification. Time goes by in (8). Message (9) is the notification of the dialed number.
消息（7）是对通知的确认。时光流逝。消息（9）是所拨号码的通知。
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.
消息（11）是长磅监控的请求。
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
<?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.
消息（13）是来自个人助理应用程序的数字和磅符号监控请求。
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>
Message (18) is the notification of the number collected.
消息（18）是所收集号码的通知。
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.
消息（21）是检测到磅符号的通知。
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="#"/>
Message (27) is the notification of long pound to the card application.
消息（27）是向卡应用程序发出的长磅通知。
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="#"/>
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[3] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[3] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[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.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[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.，和P.Faltstrom，“统一资源名（URN）命名空间定义机制”，BCP 66，RFC 3406，2002年10月。
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[7] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[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.，和N.Mendelsohn，“XML模式第1部分：结构”，W3C REC-xmlschema-1-20010502，2001年5月。
[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.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理（UA）URI（GRUU）”，正在进行的工作，2006年6月。
[10] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[10] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
[11] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[11] Andreasen，F.和B.Foster，“媒体网关控制协议（MGCP）1.0版”，RFC 3435，2003年1月。
[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.，和T.Taylor，“网关控制协议版本1”，RFC 35252003年6月。
[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] 电气和电子工程师协会，“信息技术-便携式操作系统接口（POSIX）-第1部分：基本定义，第9章”，IEEE标准1003.12001年6月。
[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.，和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C REC-XML-20001006，2000年10月。
[15] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work in Progress, July 2005.
[15] Rosenberg，J.，“会话启动协议（SIP）中的应用程序交互框架”，正在进行的工作，2005年7月。
[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.，和A.Spitzer，“媒体服务器控制标记语言（MSCML）和协议”，RFC 4722，2006年11月。
[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.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 42352005年11月。
[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.，和J.Rosenberg，“资源列表的会话启动协议（SIP）事件通知扩展”，RFC 4662，2006年8月。
Ophir Frieder of the Illinois Institute of Technology collaborated on the development of the buffer algorithm.
伊利诺伊理工学院的Ophir Frieder合作开发了缓冲区算法。
Jeff Van Dyke worked enough hours and wrote enough text to be considered an author under the old rules.
杰夫·范·戴克（Jeff Van Dyke）工作了足够多的时间，写了足够多的文字，在旧规则下可以被视为作家。
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和我们是应用程序刺激信号设计团队的成员。团队的所有成员都为这项工作做出了贡献。此外，乔纳森·罗森博格（Jonathan Rosenberg）在其“SIP中使用标记的刺激信号框架”草案中假设了DML。
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.
此版本的KPML受到MSCML[16]的重大影响，MSCML是SnowShore媒体服务器控制标记语言。杰夫·范·戴克和安迪·斯皮策是这项工作的主要贡献者。
Rohan Mahy did a significant reorganization of the content, as well as providing considerable moral support in the production of this document.
Rohan Mahy对内容进行了重大重组，并在该文件的制作过程中提供了相当多的道义支持。
That said, any errors, misinterpretation, or fouls in this document are our own.
也就是说，本文件中的任何错误、误解或犯规都是我们自己的。
Hal Purdy and Eric Cheung of AT&T Laboratories helped immensely through many conversations and challenges.
AT&T实验室的Hal Purdy和Eric Cheung在许多对话和挑战中提供了巨大帮助。
Steve Fisher of AT&T Laboratories suggested the digit suppression syntax and provided excellent review of the document.
AT&T实验室的Steve Fisher提出了数字抑制语法，并对文档进行了出色的审查。
Terence Lobo of SnowShore Networks made it all work.
SnowShore Networks的特伦斯·洛博（Terence Lobo）让这一切都得以实现。
Jerry Kamitses, Swati Dhuleshia, Shaun Bharrat, Sunil Menon, and Bryan Hill helped with clarifying the buffer behavior and DRegex syntax.
Jerry Kamitses、Swati Dhuleshia、Shaun Bharrat、Sunil Menon和Bryan Hill帮助澄清了缓冲区行为和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实验室的Silvano Brewster和Bill Fenner以及北电的Joe Zebarth在使文本清晰和紧凑方面起了相当大的作用。
Bert Culpepper and Allison Mankin gave an early version of this document a good scouring.
Bert Culpeper和Allison Mankin对该文件的早期版本进行了很好的梳理。
Scott Hollenbeck provided XML and MIME review. Tim Bray pointed out the general issue of UTF-8 versus UTF-16 with XML.
Scott Hollenbeck提供了XML和MIME评论。Tim Bray指出了使用XML的UTF-8和UTF-16的一般问题。
Authors' Addresses
作者地址
Eric Burger Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
Eric Burger Cantata Technology，Inc.18 Keewaydin Dr.Salem，NH 03079美国
EMail: eburger@cantata.com
EMail: eburger@cantata.com
Martin Dolly AT&T Labs
马丁多利AT&T实验室
EMail: mdolly@att.com
EMail: mdolly@att.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。