TRAM                                                        P. Martinsen
Internet-Draft                                                  T. Reddy
Internet-Draft                                                   D. Wing
Intended status: Standards Track                            P. Martinsen                                 D. Wing
Expires: July 30, December 22, 2016                                         Cisco
                                                                V. Singh
                                                            callstats.io
                                                        January 27,
                                                           June 20, 2016

              Discovery

     Measurement of path characteristics using Round Trip Time and Fractional Loss Using STUN
                   draft-ietf-tram-stun-path-data-03
                   draft-ietf-tram-stun-path-data-04

Abstract

   A host with multiple interfaces needs to choose the best interface
   for communication.  Oftentimes, this decision is based on a static
   configuration and does not consider the path characteristics, which
   may affect the user experience.

   This document describes a mechanism for an endpoint to discover measure the
   path characteristics fractional loss and RTT using Session Traversal
   Utilities for NAT (STUN) messages.  The measurement information can then be used to influence
   the endpoint's Interactive Connectivity Establishment (ICE) candidate
   pair selection algorithm.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 30, December 22, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   3
   3.  Path characteristics determination mechanism  Measuring RTT and Fractional Loss . . . . . . . . . . . . . .   3
     3.1.  The PATH-CHARACTERISTIC  TRANSACTION_TRANSMIT_COUNTER attribute in request  . . . . . . . . .   4
     3.2.  The PATH-CHARACTERISTIC attribute  Usage in response Requests . . . . . . . . .   5
     3.3.  Example Operation . . . . . . . . . . .   5
     3.3.  Usage in Responses  . . . . . . . . . . . .   6
   4.  Usecases . . . . . . .   5
     3.4.  Example Operation . . . . . . . . . . . . . . . . . . . .   6
   5.
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9   8

1.  Introduction

   This document extends STUN [RFC5389] to make it possible to correlate
   STUN responses to specific request when re-transmits occur.  This
   assists the client in determining path characteristics like round-
   trip time (RTT) and fractional packet loss.

   The TRANSACTION_TRANSMIT_COUNTER attribute introduced in section
   Section 3.1 can be used in ICE [RFC5245] connectivity checks (STUN
   Binding request and response).  It can also be used with TURN
   [RFC5766] by adding this attribute to Allocate requests and responses
   to measure loss and RTT between the client and respective TURN
   server.

   ICE is a mechanism commonly used in VoIP applications to traverse
   NATs, and it uses a static prioritization formula to order the
   candidate pairs and perform connectivity checks, in which the most
   preferred address pairs are tested first and when a sufficiently good
   pair is discovered, that pair is used for communications and further
   connectivity tests are stopped.  This approach works well

   When multiple paths are available for
   an communication, the endpoint with a single interface, but is too simplistic for
   endpoints with multiple interfaces, wherein a candidate pair with a
   lower priority might in fact have better path characteristics (e.g.,
   round-trip time, loss, etc.).  The
   sends ICE connectivity checks can assist
   in measuring across each path (candidate pair).
   Choosing the path characteristics, but as currently defined, with the
   STUN responses lowest round trip time is a reasonable
   approach, but re-transmits can cause an otherwise good path to re-transmitted requests are indistinguishable from
   each other.

   This draft extends STUN appear
   flawed.  However, STUN's retransmission algorithm [RFC5389] to distinguish STUN responses to
   re-transmitted requests and this assists the client in determining
   the path characteristics like round-trip time (RTT) and packet loss
   in each direction between endpoints.  These metrics can then be used
   by the controlling agent to influence the ICE candidate pair
   selection.

   The PATH-CHARACTERISTICS attribute introduced in this document can be
   used in ICE connectivity checks (STUN Binding request and response).
   When multiple TURN servers are discovered then this new attribute can
   also be used with Allocate request to determine the priority amongst
   the relayed candidates.

   The technique described in this document can be used with the regular
   nomination procedure defined in ICE [RFC5245], wherein ICE
   connectivity checks need to be performed on all or subset of the
   chosen candidate pairs.  Finalizing an appropriate candidate pair
   based on the path characteristics depends on the number of candidate
   pairs, time interval for pacing ICE connectivity checks and the
   corresponding RTO values.  By picking appropriate values, the
   endpoints will not observe any noticeable impact in the media setup
   time.

   The technique described in this document can also be used with the
   ICE continuous nomination procedure explained in
   [I-D.uberti-mmusic-nombis] which allows the application to pick
   better candidate pairs as and when they appear.  Hence, ICE endpoints
   will be capable of switching the application data to a candidate pair
   that becomes available later and offers better path characteristics.

2.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This specification uses terminology defined in ICE [RFC5245] and STUN
   [RFC5389].

3.  Path characteristics determination mechanism

   When multiple paths are available for communication, the endpoint
   sends ICE connectivity checks across each path (candidate pair) and
   perhaps chooses the path with the lowest round trip time.  Choosing
   the path with the lowest round trip time is a reasonable approach,
   but re-transmits can cause an otherwise-good path to appear flawed.
   However, STUN's retransmission algorithm [RFC5389] cannot determine cannot
   determine the round-trip time (RTT) if a STUN request packet is re-transmitted, re-
   transmitted, because each request and retransmission packet is
   identical.  Further, several STUN requests may be sent before the
   connectivity between candidate pairs is are ascertained (see Section 16
   of [RFC5245]).  To resolve the issue of identical request and
   response packets in a STUN transaction, this document changes the
   retransmission behavior for idempotent packets.  In addition to
   determining RTT, it is also
   desirable possible to detect get a hint regarding which
   path direction caused packet loss,
   described as "bi-directional path characteristics," below. loss.  This is achieved by defining a
   new STUN attribute and requires compliant STUN (TURN, ICE) endpoints
   to count request packets.

   The mechanisms described in this document can be used by the
   controlling agent to influence the ICE candidate pair selection.  How
   ICE actually will use this information to improve the active
   candidate pair selection is outside the scope of this document.

2.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This specification uses terminology defined in ICE [RFC5245] and STUN
   [RFC5389].

3.  Measuring RTT and Fractional Loss

   This document defines a new comprehension-optional STUN attribute
   PATH-CHARACTERISTIC.  PATH-CHARACTERISTIC will have
   TRANSACTION_TRANSMIT_COUNTER with a STUN Type TBD-
   CA. TBD-CA.  This type is
   in the comprehension-optional range, which means that STUN agents can
   safely ignore the attribute if they do not
   understand it. attribute.  If ICE is in use it will fallback to
   normal procedures.

   If a client wishes to determine the path characteristics, measure RTT, it inserts the PATH-CHARACTERISTIC
   TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request.  In the PATH-
   CHARACTERISTIC this
   attribute the client sends the number of times the STUN request is retransmitted
   transmitted with the same Transaction ID.  The server would echo back
   the retransmission transmission count in the response so that client can distinguish
   STUN responses from the re-transmitted requests.  Hence, the endpoint
   can use the STUN requests and responses to determine the round-trip
   time (RTT).  The server may also convey the number of responses it
   has sent for the STUN request to the client.  Further, this
   information enables the client to
   determine get a hint regarding what direction
   the packet loss in each direction. occurred.  In some cases, it is impossible to
   distinguish between packet reordering and packet loss.  However if
   this information is collected as network metrics from several clients
   over a longer time period it will be easier to detect a pattern that
   can provide useful information.

3.1.  The PATH-CHARACTERISTIC  TRANSACTION_TRANSMIT_COUNTER attribute in request

   The PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request takes a 4-byte
   Value.  When sending a STUN request, the PATH-CHARACTERISTIC
   attribute allows a client to indicate to the server that it wants to
   determine path characteristics.
   32-bit value.  This document updates one of the STUN message
   structuring rules explained in Section 6 of [RFC5389] wherein resends
   of the same request reuse the same transaction ID and are bit-wise
   identical to the previous request.  For idempotent packets packets, the ReTransCnt Req
   and Resp fields in the PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER attribute will be
   incremented by 1 by the client or server for every re-transmission and transmission with
   the same transaction id.  Any re-transmitted STUN request MUST be
   bit-wise identical to the previous request except for the ReTransCnt value. values in
   the TRANSACTION_TRANSMIT_COUNTER attribute.

   The IANA assigned STUN type for the new attribute is TBD-CA.

   The format of the value in PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER attribute in
   the request is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Reserved, should be 0        Reserved (Padding)     |  ReTransCnt    Req        |  RespTransCnt     Resp      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 1: PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER attribute in request

   The field fields is described below:

   ReTransCnt:

   Req:  Number of times request is re-transmitted transmitted with the same
      transaction ID to the server.

   RespTransCnt:  RespTransCnt

   Resp:  Number of times a response with the same transaction ID is
      sent from the server.  MUST be set to zero in request requests and ignored
      by the receiver.

   The padding is necessary to hit the 32-bit boundary needed for STUN
   attributes.  The padding bits are ignored, but to allow for future
   reuse of these bits they MUST be set to 0.

3.2.  Usage in Requests

   When sending a STUN request, the TRANSACTION_TRANSMIT_COUNTER
   Attribute allows a client to indicate to the server that it wants to
   measure RTT and get a hint of the direction of any packet loss.

   The client MUST populate the Req value in the
   TRANSACTION_TRANSMIT_COUNTER.  This value MUST reflect the number of
   requests that have been transmitted to the server.  Initial value for
   the first request sent is therefore 1.  The first re-transmit will
   set the value to 2 and so on.

   The PATH-CHARACTERISTIC Resp filed in the attribute MUST be set to zero in response the request.

3.3.  Usage in Responses

   When a server receives a STUN request that includes a PATH-
   CHARACTERISTIC
   TRANSACTION_TRANSMIT_COUNTER attribute, it processes the request as
   per the STUN protocol [RFC5389] plus the specific rules mentioned
   here.  The server checks the following:

   o  If the PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER attribute is not recognized,
      ignore the attribute because its type indicates that it is
      comprehension- optional.  This should be the existing behavior as
      explained in section 3.1 of [RFC5389].

   o  The server that supports PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER attribute
      MUST echo back ReTransCnt the Req field in the response. response using a
      TRANSACTION_TRANSMIT_COUNTER attribute.

   o  If the server is stateless or does not want to remember the
      transaction ID then it would populate value 0 for the RespTransCnt Resp field
      in PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER attribute sent in the response.  If
      the server is stateful then it populates RespTransCnt with the
      number of responses it has sent for the STUN request.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Reserved, should be 0  |  ReTransCnt   |  RespTransCnt |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: PATH-CHARACTERISTIC attribute in response

   The fields are described below:

   ReTransCnt:  Copied from request.

   RespTransCnt:  Number the response.
      If the server is stateful then it populates the Resp field with
      the number of responses it has sent to for the STUN request.

   A client for that receives a STUN response with a
   TRANSACTION_TRANSMIT_COUNTER can check the values in the Req field to
   accurately calculate the RTT if retransmits are occurring.

   If the server sending the STUN response is stateless the value of the
   Resp field will always be 0.  If the server keeps state of the
   numbers of STUN request with that same transaction ID.

3.3. id the value will
   reflect how many packets the server have seen and responded to.  This
   gives the client a hint of which direction loss occurred.  See
   section Section 3.4 for more details.

3.4.  Example Operation

   The example operation

   Example operation, when a server is stateful, is described in
   Figure 3. 2.  In the first case, all the requests and responses are
   received correctly.

   In the upstream loss case, the first request is lost, but the second
   one is received correctly, the client on receiving the response notes
   that while 2 requests were sent, only one was received by the server, also
   the server.
   The server also realizes that the RespTransCnt value in the Req field does not
   match the
   ReTransCnt, number of received requests, therefore 1 request was lost.
   This may also occur at startup in the presence firewalls or NATs that
   block unsolicited incoming traffic.

   In the downstream loss case, the responses get lost, client expecting
   multiple response responses, notes that while the server responded to 3
   requests but only 1 response was received.

   In the both loss case, requests and responses get lost in tandem, the
   server notes one request packet was not received, while the client
   expecting 3 responses received only one, it notes that one request
   and response packets were lost.

   |     Normal    |  Upstream loss | Downstream loss| loss |     Both loss |
   | Client Server |  Client Server |  Client  Server | Client Server |
  -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   | 1        1,1  |  1        x    |  1         1,1  |  1        x   |
   |   1,1         |                |    x            |               |
  2         2,2
   |               |  2        2,1  |  2         2,2  |  2        2,1 |
    2,2
   |               |    2,1         |    x            |    x          |
  3         3,3
   |  3         3,2               |                |  3         3,3  |  3        3,2 |
    3,3
   |    3,2               |                |    3,3          |    3,2        |

         Figure 3: 2: Retransmit Operation between client and Server

   Another example could be the client sends two requests but the second
   request arrives at the server before the first request because of out
   of order delivery.  In this case the stateful server populates value
   1 for the RespTransCnt field in PATH-CHARACTERISTIC attribute sent in
   response to the second request and value 2 for the RespTransCnt field
   in PATH-CHARACTERISTIC attribute sent in response to the first
   request.

4.  Usecases

   The STUN attribute defined in this document can be used by
   applications in the following scenarios:

   o  When an endpoint has multiple interfaces (for example 3G, 4G,
      WiFi, VPN, etc.), an ICE agent can choose the interfaces for
      application data according to the path characteristics.  After
      STUN responses to STUN checks are received, the ICE agent using
      regular nomination can sort the ICE candidate pairs according to
      the path characteristics (loss and RTT) discovered using STUN.
      The controlling agent can then assign client sends two requests but the highest priority to
      candidate pair which best fulfills second
   request arrives at the desired path
      characteristics.  However, it should be noted that server before the path
      capacity or throughput is not determined by these STUN checks.  If
      an endpoint needs to pick paths based on capacity, it would have
      to send application data on those paths.

   o  When a host has multiple interfaces available an MPRTP
      [I-D.ietf-avtcore-mprtp] application can choose first request because of out
   of order delivery.  In this case, the interfaces stateful server populates value
   1 for the corresponding subflows according Resp field in TRANSACTION_TRANSMIT_COUNTER attribute sent
   in response to the path characteristics
      (loss second request and RTT) discovered using STUN.  For example, value 2 for the scheduling
      algorithm described Resp field in [ACM-MPRTP] uses path capacity, latency,
      and loss rate for choosing
   TRANSACTION_TRANSMIT_COUNTER attribute sent in response to the most suitable subset of paths.

   o first
   request.

   The STUN extension proposed in intention with this document can also mechanism is not to carry out comprehensive
   and accurate measurements regarding in what direction loss is
   occurring.  In some cases, it might not be used able to
      choose a TURN server that provides distinguish the best user experience
      (section 3.1 of [I-D.patil-tram-turn-serv-selection]).

5.
   difference between downstream loss and packet reordering.

4.  IANA Considerations

   [Paragraphs in braces should be removed by the RFC Editor upon
   publication]

   [The PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER attribute requires that IANA
   allocate a value in the "STUN attributes Registry" from the comprehension-
   optional
   comprehension-optional range (0x8000-0xFFFF), (0x8000-0xBFFF), to be replaced for TBD-CA TBD-
   CA throughout this document]

   This document defines the PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER STUN
   attribute, described in Section 3.  IANA has allocated the comprehension-
   optional
   comprehension-optional codepoint TBD-CA for this attribute.

6.

5.  Security Considerations

   Security considerations discussed in [RFC5389] are to be taken into
   account.  STUN requires the 96 bits transaction ID to be uniformly
   and randomly chosen from the interval 0 .. 2**96-1, and be
   cryptographically strong.  This is good enough security against an
   off-path attacker.  An on-path attacker can either inject a fake
   response or modify the values in PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER
   attribute to mislead the client and server.  This attack can be
   mitigated using STUN authentication.  As PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER
   is expected to be used between peers using ICE, and ICE uses STUN
   short-term credential mechanism the risk of on-path attack
   influencing the messages is minimal.  If PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER
   is used with Allocate request then STUN long-term credential
   mechanism or STUN Extension for Third-Party Authorization [RFC7635]
   or (D)TLS connection can be used between the TURN client and the TURN
   server to prevent attackers from trying to impersonate a TURN server
   and sending bogus PATH-CHARACTERISTIC TRANSACTION_TRANSMIT_COUNTER attribute in the
   Allocate response.  However, an attacker could corrupt, remove, or
   delay an ICE request or response, in order to discourage that path
   from being used.  Unauthenticated STUN message
   MUST NOT include the PATH-CHARACTERISTIC attribute

   The information sent in order to
   prevent on-path attacker from influencing decision-making.

7. any STUN packet if not encrypted can
   potentially be observed passively and used for reconnaissance and
   later attacks.

6.  Acknowledgements

   Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin
   Thomson, Oleg Moskalenko, Ram Mohan R and R, Spencer Dawkins Dawkins, Suresh
   Krishnan, Ben Campbell, Mirja Kuhlewind, Lionel Morand, Kathleen
   Moriarty and Alissa Cooper for valuable inputs and comments.

8.

7.  References

8.1.

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, DOI
              10.17487/RFC5245, April 2010,
              <http://www.rfc-editor.org/info/rfc5245>.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              DOI 10.17487/RFC5389, October 2008,
              <http://www.rfc-editor.org/info/rfc5389>.

8.2.  Informative References

   [ACM-MPRTP]
              Singh, V., Ahsan, S., and J. Ott, "MPRTP: multipath
              considerations for real-time media", in Proc. of ACM
              Multimedia Systems, MMSys, 2013.

   [I-D.ietf-avtcore-mprtp]
              Varun, V., Karkkainen, T., Ott, J., Ahsan, S., and L.
              Eggert, "Multipath RTP (MPRTP)", draft-ietf-avtcore-
              mprtp-01 (work in progress), July 2015.

   [I-D.patil-tram-turn-serv-selection]
              Patil,

   [RFC5766]  Mahy, R., Matthews, P., Reddy, T., and G. Salgueiro, J. Rosenberg, "Traversal Using
              Relays around NAT (TURN) Server Selection", draft-patil-
              tram-turn-serv-selection-00 (work in progress), October
              2014.

   [I-D.uberti-mmusic-nombis]
              Uberti, J. and J. Lennox, "Improvements (TURN): Relay Extensions to ICE Candidate
              Nomination", draft-uberti-mmusic-nombis-00 (work in
              progress), March 2015. Session
              Traversal Utilities for NAT (STUN)", RFC 5766, DOI
              10.17487/RFC5766, April 2010,
              <http://www.rfc-editor.org/info/rfc5766>.

7.2.  Informative References

   [RFC7635]  Reddy, T., Patil, P., Ravindranath, R., and J. Uberti,
              "Session Traversal Utilities for NAT (STUN) Extension for
              Third-Party Authorization", RFC 7635, DOI 10.17487/RFC7635, 10.17487/
              RFC7635, August 2015,
              <http://www.rfc-editor.org/info/rfc7635>.

Authors' Addresses

   Paal-Erik Martinsen
   Cisco Systems, Inc.
   Philip Pedersens vei 22
   Lysaker, Akershus  1325
   Norway

   Email: palmarti@cisco.com
   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: dwing@cisco.com

   Paal-Erik Martinsen
   Cisco Systems, Inc.
   Philip Pedersens vei 22
   Lysaker, Akershus  1325
   Norway

   Email: palmarti@cisco.com

   Varun Singh
   Nemu Dialogue System Oy
   Itaemerenkatu 5
   Helsinki  00150
   Finland

   Email: varun@callstats.io