1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Internet Engineering Task Force (IETF) P. Martinsen
Request for Comments: 7982 T. Reddy
Category: Standards Track Cisco
ISSN: 2070-1721 D. Wing
V. Singh
callstats.io
September 2016
<span class="h1">Measurement of Round-Trip Time and Fractional Loss</span>
<span class="h1">Using Session Traversal Utilities for NAT (STUN)</span>
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 measure the
path characteristics fractional loss and RTT using Session Traversal
Utilities for NAT (STUN) messages.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7982">http://www.rfc-editor.org/info/rfc7982</a>.
<span class="grey">Martinsen, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7982">RFC 7982</a> RTT and Fractional Loss September 2016</span>
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Notational Conventions . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Measuring RTT and Fractional Loss . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. TRANSACTION_TRANSMIT_COUNTER Attribute . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Usage in Requests . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Usage in Responses . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.4">3.4</a>. Example Operation . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6.1">6.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6.2">6.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<span class="grey">Martinsen, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7982">RFC 7982</a> RTT and Fractional Loss September 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document extends STUN [<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>] to make it possible to correlate
STUN responses to specific requests when retransmits 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 <a href="#section-3.1">Section 3.1</a>
can be used in Interactive Connectivity Establishment (ICE) [<a href="./rfc5245" title=""Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols"">RFC5245</a>]
connectivity checks (STUN Binding request and response). It can also
be used with Traversal Using Relays around NAT (TURN) [<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>] by
adding this attribute to Allocate requests and responses to measure
loss and RTT between the client and the respective TURN server.
ICE is a mechanism commonly used in Voice over IP (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 then further connectivity tests are stopped.
When multiple paths are available for communication, the endpoint
sends ICE connectivity checks across each path (candidate pair).
Choosing the path with the lowest round-trip time is a reasonable
approach, but retransmits can cause an otherwise good path to appear
flawed. However, STUN's retransmission algorithm [<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>] cannot
determine the round-trip time (RTT) if a STUN request packet is
retransmitted because each request and retransmission packet is
identical. Further, several STUN requests may be sent before the
connectivity between candidate pairs are ascertained (see <a href="./rfc5245#section-16">Section 16
of [RFC5245]</a>). To resolve the issue of identical request and
response packets in a STUN transaction, this document changes the
retransmission behavior for idempotent packets. Using the mechanism
described herein, a client can determine RTT as well as get a hint
regarding which path direction caused packet loss. This is achieved
by defining a new STUN attribute and requires compliant STUN (TURN
and 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 will actually use this information to improve the active
candidate pair selection is outside the scope of this document.
<span class="grey">Martinsen, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7982">RFC 7982</a> RTT and Fractional Loss September 2016</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Notational Conventions</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
This specification uses terminology defined in ICE [<a href="./rfc5245" title=""Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols"">RFC5245</a>] and STUN
[<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Measuring RTT and Fractional Loss</span>
This document defines a new comprehension-optional STUN attribute
TRANSACTION_TRANSMIT_COUNTER with a STUN Type 0x8025. This type is
in the comprehension-optional range, which means that STUN agents can
safely ignore the attribute. If ICE is in use, it will fall back to
normal procedures.
If a client wishes to measure RTT, it inserts the
TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request. In this
attribute, the client sends the number of times the STUN request is
transmitted with the same transaction ID. The server would echo back
the transmission count in the response so that the client can
distinguish between STUN responses coming from retransmitted
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 get a
hint regarding in which direction the packet loss 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.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. TRANSACTION_TRANSMIT_COUNTER Attribute</span>
The TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request takes a
32-bit value. This document updates one of the STUN message
structuring rules explained in <a href="./rfc5389#section-6">Section 6 of [RFC5389]</a> wherein
retransmission of the same request reuses the same transaction ID and
is bit-wise identical to the previous request. For idempotent
packets, the Req and Resp fields in the TRANSACTION_TRANSMIT_COUNTER
attribute will be incremented by 1 by the client or server for every
transmission with the same transaction ID. Any retransmitted STUN
request MUST be bit-wise identical to the previous request except for
the values in the TRANSACTION_TRANSMIT_COUNTER attribute.
The IANA-assigned STUN type for the new attribute is 0x8025.
<span class="grey">Martinsen, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7982">RFC 7982</a> RTT and Fractional Loss September 2016</span>
The format of the value in the 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 (Padding) | Req | Resp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: TRANSACTION_TRANSMIT_COUNTER Attribute in Request
The fields are described below:
Req: Number of times the request is transmitted with the same
transaction ID to the server.
Resp: Number of times a response with the same transaction ID is
sent from the server. MUST be set to zero in 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 zero.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Usage in Requests</span>
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 about 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. Therefore, the
initial value for the first request sent is 1. The first retransmit
will set the value to 2 and so on.
The Resp field in the attribute MUST be set to zero in the request.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Usage in Responses</span>
When a server receives a STUN request that includes a
TRANSACTION_TRANSMIT_COUNTER attribute, it processes the request as
per the STUN protocol [<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>] plus the specific rules mentioned
here. The server checks the following:
<span class="grey">Martinsen, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7982">RFC 7982</a> RTT and Fractional Loss September 2016</span>
o If the 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 <a href="./rfc5389#section-7.3">Section 7.3 of [RFC5389]</a>.
o The server that supports the TRANSACTION_TRANSMIT_COUNTER
attribute MUST echo back the Req field in the response using a
TRANSACTION_TRANSMIT_COUNTER attribute.
o If the server is stateless or does not want to remember the
transaction ID, then it populates value 0 for the Resp field in
the TRANSACTION_TRANSMIT_COUNTER attribute sent in the response.
If the server is stateful, then it populates the Resp field with
the number of responses it has sent for the STUN request.
A client 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 requests with that same transaction ID, the value
will reflect how many packets the server has seen and responded to.
This gives the client a hint about in which direction loss occurred.
See <a href="#section-3.4">Section 3.4</a> for more details.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Example Operation</span>
An example operation, when a server is stateful, is described in
Figure 2. In the first case, all the requests and responses are
received correctly.
In the case of upstream loss, the first request is lost, but the
second one is received correctly. The client, upon receiving the
response, notes that while two requests were sent, only one was
received by the server. The server also realizes that the value in
the Req field does not match the number of received requests,
therefore one request was lost. This may also occur at startup in
the presence of firewalls or NATs that block unsolicited incoming
traffic.
In the case of downstream loss, the responses get lost, the client
expecting multiple responses notes that, while the server responded
to three requests, only one response was received.
<span class="grey">Martinsen, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7982">RFC 7982</a> RTT and Fractional Loss September 2016</span>
In the case of loss in both directions, requests and responses get
lost in tandem, the server notes that one request packet was not
received, while the client expecting three responses received only
one, and then it notes that one request and response packet were
lost.
| Normal | Upstream loss | Downstream loss | Both upstream &|
| | | | downstream loss|
| Client Server | Client Server | Client Server | Client Server |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
| 1 1,1 | 1 x | 1 1,1 | 1 x |
| 1,1 | | x | |
| | 2 2,1 | 2 2,2 | 2 2,1 |
| | 2,1 | x | x |
| | | 3 3,3 | 3 3,2 |
| | | 3,3 | 3,2 |
Figure 2: Retransmit Operation between Client and Server
Another example is when 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 Resp field in the TRANSACTION_TRANSMIT_COUNTER
attribute sent in response to the second request and value 2 for the
Resp field in the TRANSACTION_TRANSMIT_COUNTER attribute sent in
response to the first request.
The intention with this mechanism is not to carry out comprehensive
and accurate measurements regarding in what direction loss is
occurring. In some cases, it might not be able to distinguish the
difference between downstream loss and packet reordering.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
This document defines the TRANSACTION_TRANSMIT_COUNTER STUN
attribute, described in <a href="#section-3">Section 3</a>. IANA has allocated the
comprehension-optional codepoint 0x8025 for this attribute.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
Security considerations discussed in [<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>] are to be taken into
account. STUN requires that the 96-bit transaction ID 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 the TRANSACTION_TRANSMIT_COUNTER
attribute to mislead the client and server. This attack can be
mitigated using STUN authentication. As the
<span class="grey">Martinsen, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7982">RFC 7982</a> RTT and Fractional Loss September 2016</span>
TRANSACTION_TRANSMIT_COUNTER is expected to be used between peers
using ICE, and ICE uses a STUN short-term credential mechanism, the
risk of an on-path attack influencing the messages is minimal. If
the TRANSACTION_TRANSMIT_COUNTER is used with an Allocate request,
one of the following mechanisms can be used to prevent attackers from
trying to impersonate a TURN server and sending a bogus
TRANSACTION_TRANSMIT_COUNTER attribute in the Allocate response:
1) the STUN long-term credential mechanism, 2) the STUN Extension for
Third-Party Authorization [<a href="./rfc7635" title=""Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization"">RFC7635</a>], or 3) a TLS or DTLS connection
between the TURN client and the TURN server. However, an attacker
could corrupt, remove, or delay an ICE request or response, in order
to discourage that path from being used.
If not encrypted, the information sent in any STUN packet can
potentially be observed passively and used for reconnaissance and
later attacks.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5245">RFC5245</a>] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", <a href="./rfc5245">RFC 5245</a>,
DOI 10.17487/RFC5245, April 2010,
<<a href="http://www.rfc-editor.org/info/rfc5245">http://www.rfc-editor.org/info/rfc5245</a>>.
[<a id="ref-RFC5389">RFC5389</a>] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", <a href="./rfc5389">RFC 5389</a>,
DOI 10.17487/RFC5389, October 2008,
<<a href="http://www.rfc-editor.org/info/rfc5389">http://www.rfc-editor.org/info/rfc5389</a>>.
[<a id="ref-RFC5766">RFC5766</a>] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", <a href="./rfc5766">RFC 5766</a>,
DOI 10.17487/RFC5766, April 2010,
<<a href="http://www.rfc-editor.org/info/rfc5766">http://www.rfc-editor.org/info/rfc5766</a>>.
<span class="grey">Martinsen, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7982">RFC 7982</a> RTT and Fractional Loss September 2016</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-RFC7635">RFC7635</a>] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti,
"Session Traversal Utilities for NAT (STUN) Extension for
Third-Party Authorization", <a href="./rfc7635">RFC 7635</a>,
DOI 10.17487/RFC7635, August 2015,
<<a href="http://www.rfc-editor.org/info/rfc7635">http://www.rfc-editor.org/info/rfc7635</a>>.
Acknowledgements
Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin
Thomson, Oleg Moskalenko, Ram Mohan Ravindranath, Spencer Dawkins,
Suresh Krishnan, Ben Campbell, Mirja Kuehlewind, Lionel Morand,
Kathleen Moriarty, and Alissa Cooper for their valuable input and
comments.
<span class="grey">Martinsen, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7982">RFC 7982</a> RTT and Fractional Loss September 2016</span>
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
Email: dwing-ietf@fuggles.com
Varun Singh
CALLSTATS I/O Oy
Runeberginkatu 4c A 4
Helsinki 00100
Finland
Email: varun@callstats.io
URI: <a href="https://www.callstats.io/about">https://www.callstats.io/about</a>
Martinsen, et al. Standards Track [Page 10]
</pre>
|
