tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4730

 
 
 

A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)

Part 3 of 3, p. 37 to 56
Prev RFC Part

 


prevText      Top      Up      ToC       Page 37 
8.  Security Considerations

   The user information transported by KPML is potentially sensitive.
   For example, it could include calling card or credit card numbers.
   This potentially private information could be provided accidentally
   if the notifier does not properly authenticate or authorize a
   subscription.  Similarly private information (such as a credit card
   number or calling card number) could be revealed to an otherwise
   legitimate subscriber (one operating an IVR) if digits buffered
   earlier in the session are provided unintentionally to the new
   subscriber.

   Likewise, an eavesdropper could view KPML digit information if it is
   not encrypted, or an attacker could inject fraudulent notifications
   unless the messages or the SIP path over which they travel are
   integrity protected.

   Therefore, User Interfaces MUST NOT downgrade their own security
   policy.  That is, if a User Interface policy is to restrict
   notifications to authenticated and authorized subscribers over secure
   communications, then the User Interface must not accept an
   unauthenticated, unauthorized subscription over an insecure
   communication channel.

   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.

Top      Up      ToC       Page 38 
   Key press information is potentially sensitive.  For example, it can
   represent credit card, calling card, or other personal information.
   Hijacking sessions allow unauthorized entities access to this
   sensitive information.  Therefore, signaling SHOULD be secure, e.g.,
   use of TLS and sips: SHOULD be used.  Moreover, the information
   itself is sensitive so S/MIME or other appropriate mechanisms SHOULD
   be used.

   Subscriptions MUST be authenticated in some manner.  As required by
   the core SIP [4] specification, all SIP implementations MUST support
   digest authentication.  In addition, User Interfaces MUST implement
   support for the sips: scheme and SIP over TLS.  Subscribers MUST
   expect the User Interface to demand the use of an authentication
   scheme.  If the local policy of a User Interface is to use
   authentication or secure communication channels, the User Interface
   MUST reject subscription requests that do not meet that policy.

   User Interfaces MUST begin buffering User Input upon receipt of an
   authenticated and accepted subscription.  This buffering is done on a
   per-subscription basis.

9.  Examples

   This section is informative in nature.  If there is a discrepancy
   between this section and the normative sections above, the normative
   sections take precedence.

9.1.  Monitoring for Octothorpe

   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.

Top      Up      ToC       Page 39 
   Figure 16 shows the KPML for long octothorpe.

   <?xml version="1.0"?>
   <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
         version="1.0">
     <pattern>
       <regex>L#</regex>
     </pattern>
   </kpml-request>

                    Figure 16: Long Octothorpe Example

   The regex value L indicates the following digit needs to be a long-
   duration key press.

9.2.  Dial String Collection

   In this example, the User Interface collects a dial string.  The
   application uses KPML to quickly determine when the user enters a
   target number.  In addition, KPML indicates what type of number the
   user entered.

   <?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

   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

Top      Up      ToC       Page 40 
   "9xxxxxxxxxx" regular expressions.  Both expressions are the same
   length.  Thus the KPML interpreter will pick the "9401xxxxxxx"
   string, as it occurs first in document order.  Figure 18 shows the
   response.

   <?xml version="1.0"?>
   <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-resposne"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
         version="1.0"
         code="200" text="OK"
         digits="94015551212" tag="RI-number"/>

                   Figure 18: Dial String KPML Response

10.  Call Flow Examples

10.1.  Supplemental Digits

   This section gives a non-normative example of an application that
   collects supplemental digits.  Supplemental digit collection is where
   the network requests additional digits after the caller enters the
   destination address.  A typical supplemental dial string is four
   digits in length.

Top      Up      ToC       Page 41 
   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

Top      Up      ToC       Page 42 
   In messages (1-3), the ingress gateway establishes a dialog with an
   egress gateway.  The application learns the dialog ID through out-of-
   band mechanisms, such as the Dialog Package or being co-resident with
   the egress gateway.  Part of the ACK message is below, to illustrate
   the dialog identifiers.

   ACK sip:gw@subA.example.com SIP/2.0
   Via: ...
   Max-Forwards: ...
   Route: ...
   From: <sip:phn@example.com>;tag=jfh21
   To: <sip:gw@subA.example.com>;tag=onjwe2
   Call-ID: 12345592@subA.example.com
   ...

   In message (4), the application the requests that gateway collect a
   string of four key presses.

   SUBSCRIBE sip:gw@subA.example.com SIP/2.0
   Via: SIP/2.0/TCP client.subB.example.com;branch=q4i9ufr4ui3
   From: <sip:ap@subB.example.com>;tag=567890
   To: <sip:gw@subA.example.com>
   Call-ID: 12345601@subA.example.com
   CSeq: 1 SUBSCRIBE
   Contact: <sip:ap@client.subB.example.com>
   Max-Forwards: 70
   Event: kpml ;remote-tag="sip:phn@example.com;tag=jfh21"
               ;local-tag="sip:gw@subA.example.com;tag=onjwe2"
               ;call-id="12345592@subA.example.com"
   Expires: 7200
   Accept: application/kpml-response+xml
   Content-Type: application/kpml-request+xml
   Content-Length: 292

   <?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>

Top      Up      ToC       Page 43 
   Message (5) is the acknowledgement of the subscription request.

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP subB.example.com;branch=q4i9ufr4ui3;
        received=192.168.125.12
   From: <sip:ap@subB.example.com>;tag=567890
   To: <sip:gw@subA.example.com>;tag=1234567
   Call-ID: 12345601@subA.example.com
   CSeq: 1 SUBSCRIBE
   Contact: <sip:gw27@subA.example.com>
   Expires: 3600
   Event: kpml

   Message (6) is the immediate notification of the subscription.

   NOTIFY sip:ap@client.subB.example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=gw27id4993
   To: <sip:ap@subB.example.com>;tag=567890
   From: <sip:gw@subA.example.com>;tag=1234567
   Call-ID: 12345601@subA.example.com
   CSeq: 1000 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: active;expires=3599
   Max-Forwards: 70
   Content-Length: 0

   Message (7) is the acknowledgement of the notification message.

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP subA.example.com;branch=gw27id4993
   To: <sip:ap@subB.example.com>;tag=567890
   From: <sip:gw@subA.example.com>;tag=1234567
   Call-ID: 12345601@subA.example.com
   CSeq: 1000 NOTIFY

   Some time elapses (8).

   The user enters the input.  The device provides the notification of
   the collected digits in message (9).  Since this was a one-shot
   subscription, note the Subscription-State is "terminated".

Top      Up      ToC       Page 44 
   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"/>

   Message (10) is the acknowledgement of the notification.

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP subA.example.com;branch=gw27id4993
   To: <sip:ap@subB.example.com>;tag=567890
   From: <sip:gw@subA.example.com>;tag=1234567
   Call-ID: 12345601@subA.example.com
   CSeq: 1001 NOTIFY

Top      Up      ToC       Page 45 
10.2.  Multiple Applications

   This section gives a non-normative example of multiple applications.
   One application collects a destination number to call.  That
   application then waits for a "long pound."  During the call, the call
   goes to a personal assistant application, which interacts with the
   user.  In addition, the personal assistant application looks for a
   "short pound."

   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)                      |

Top      Up      ToC       Page 46 
      |--------------------->|                      |
      |                      |                      |
      |                      |                      |
      |(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)                  |                      |

Top      Up      ToC       Page 47 
      |.............................................|
      |                      |                      |
      |                      |                      |
      |(22) NOTIFY (tag=number)                     |
      |-------------------------------------------->|
      |                      |                      |
      |                      |                      |
      |(23) 200 OK           |                      |
      |<--------------------------------------------|
      |                      |                      |
      |                      |                      |
      |(24)                  |                      |
      |.............................................|
      |                      |                      |
      |                      |                      |
      |(25) NOTIFY (L#)      |                      |
      |--------------------->|                      |
      |                      |                      |
      |                      |                      |
      |(26) 200 OK           |                      |
      |<---------------------|                      |
      |                      |                      |
      |                      |                      |
      |                      |                      |
      |                      |                      |

                 Figure 27: Multiple Application Call Flow

   Message (1) is the subscription request for the card number.

   SUBSCRIBE sip:gw@subA.example.com SIP/2.0
   Via: SIP/2.0/TCP client.subB.example.com;branch=3qo3j0ouq
   From: <sip:ap@subB.example.com>;tag=978675
   To: <sip:gw@subA.example.com>
   Call-ID: 12345601@subA.example.com
   CSeq: 20 SUBSCRIBE
   Contact: <sip:ap@client.subB.example.com>
   Max-Forwards: 70
   Event: kpml ;remote-tag="<sip:phn@example.com;tag=jfi23>"
               ;local-tag="sip:gw@subA.example.com;tag=oi43jfq"
               ;call-id="12345598@subA.example.com"
   Expires: 7200
   Accept: application/kpml-response+xml
   Content-Type: application/kpml-request+xml
   Content-Length: 339

Top      Up      ToC       Page 48 
   <?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.

   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"/>

Top      Up      ToC       Page 49 
   Message (7) is the acknowledgement of the notification.  Time goes by
   in (8).  Message (9) is the notification of the dialed number.

   NOTIFY sip:ap@client.subB.example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq
   To: <sip:ap@subB.example.com>;tag=978675
   From: <sip:gw@subA.example.com>;tag=9783453
   Call-ID: 12345601@subA.example.com
   CSeq: 3001 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: active;expires=3542
   Max-Forwards: 70
   Content-Type: application/kpml-response+xml
   Content-Length: 278

   <?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.

   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

Top      Up      ToC       Page 50 
   <?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.

   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>

Top      Up      ToC       Page 51 
   Message (18) is the notification of the number collected.

   NOTIFY sip:pa@example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=xzvsadf
   To: <sip:pa@example.com>;tag=4rgj0f
   From: <sip:gw@subA.example.com>;tag=9788823
   Call-ID: 93845@pahost.example.com
   CSeq: 3021 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: active;expires=3540
   Max-Forwards: 70
   Content-Type: application/kpml-response+xml
   Content-Length: 278

   <?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.

   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="#"/>

Top      Up      ToC       Page 52 
   Message (27) is the notification of long pound to the card
   application.

   NOTIFY sip:ap@client.subB.example.com SIP/2.0
   Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq
   To: <sip:ap@subB.example.com>;tag=978675
   From: <sip:gw@subA.example.com>;tag=9783453
   Call-ID: 12345601@subA.example.com
   CSeq: 3037 NOTIFY
   Contact: <sip:gw27@subA.example.com>
   Event: kpml
   Subscription-State: active;expires=3216
   Max-Forwards: 70
   Content-Type: application/kpml-response+xml
   Content-Length: 256

   <?xml version="1.0" encoding="UTF-8"?>
   <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation=
           "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
         version="1.0"
         code="200" text="OK"
         digits="#"/>

11.  References

11.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

   [3]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
        RFC 3023, January 2001.

   [4]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [5]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [6]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
        "Uniform Resource Names (URN) Namespace Definition Mechanisms",
        BCP 66, RFC 3406, October 2002.

Top      Up      ToC       Page 53 
   [7]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
        January 2004.

   [8]  Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
        Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
        May 2001.

11.2.  Informative References

   [9]   Rosenberg, J., "Obtaining and Using Globally Routable User
         Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
         (SIP)", Work in Progress, June 2006.

   [10]  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
         Telephony Tones and Telephony Signals", RFC 2833, May 2000.

   [11]  Andreasen, F. and B. Foster, "Media Gateway Control Protocol
         (MGCP) Version 1.0", RFC 3435, January 2003.

   [12]  Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
         Control Protocol Version 1", RFC 3525, June 2003.

   [13]  Institute of Electrical and Electronics Engineers, "Information
         Technology - Portable Operating System Interface (POSIX) - Part
         1: Base Definitions, Chapter 9", IEEE Standard 1003.1,
         June 2001.

   [14]  Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
         "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
         REC REC-xml-20001006, October 2000.

   [15]  Rosenberg, J., "A Framework for Application Interaction in the
         Session Initiation Protocol  (SIP)", Work in Progress,
         July 2005.

   [16]  Burger, E., Van Dyke, J., and A. Spitzer, "Media Server Control
         Markup Language (MSCML) and Protocol", RFC 4722, November 2006.

   [17]  Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
         Initiated Dialog Event Package for the Session Initiation
         Protocol (SIP)", RFC 4235, November 2005.

   [18]  Roach, A., Campbell, B., and J. Rosenberg, "A Session
         Initiation Protocol (SIP) Event Notification Extension for
         Resource Lists", RFC 4662, August 2006.

Top      Up      ToC       Page 54 
Appendix A.  Contributors

   Ophir Frieder of the Illinois Institute of Technology collaborated on
   the development of the buffer algorithm.

   Jeff Van Dyke worked enough hours and wrote enough text to be
   considered an author under the old rules.

   Robert Fairlie-Cuninghame, Cullen Jennings, Jonathan Rosenberg, and
   we were the members of the Application Stimulus Signaling Design
   Team.  All members of the team contributed to this work.  In
   addition, Jonathan Rosenberg postulated DML in his "A Framework for
   Stimulus Signaling in SIP Using Markup" draft.

   This version of KPML has significant influence from MSCML [16], the
   SnowShore Media Server Control Markup Language.  Jeff Van Dyke and
   Andy Spitzer were the primary contributors to that effort.

   Rohan Mahy did a significant reorganization of the content, as well
   as providing considerable moral support in the production of this
   document.

   That said, any errors, misinterpretation, or fouls in this document
   are our own.

Appendix B.  Acknowledgements

   Hal Purdy and Eric Cheung of AT&T Laboratories helped immensely
   through many conversations and challenges.

   Steve Fisher of AT&T Laboratories suggested the digit suppression
   syntax and provided excellent review of the document.

   Terence Lobo of SnowShore Networks made it all work.

   Jerry Kamitses, Swati Dhuleshia, Shaun Bharrat, Sunil Menon, and
   Bryan Hill helped with clarifying the buffer behavior and DRegex
   syntax.

   Silvano Brewster and Bill Fenner of AT&T Laboratories and Joe Zebarth
   of Nortel helped considerably with making the text clear and DRegex
   tight.

   Bert Culpepper and Allison Mankin gave an early version of this
   document a good scouring.

   Scott Hollenbeck provided XML and MIME review.  Tim Bray pointed out
   the general issue of UTF-8 versus UTF-16 with XML.

Top      Up      ToC       Page 55 
Authors' Addresses

   Eric Burger
   Cantata Technology, Inc.
   18 Keewaydin Dr.
   Salem, NH  03079
   USA

   EMail: eburger@cantata.com


   Martin Dolly
   AT&T Labs

   EMail: mdolly@att.com

Top      Up      ToC       Page 56 
Full Copyright Statement

   Copyright (C) The IETF Trust (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.

   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.

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.

   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.

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.