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
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Internet Engineering Task Force (IETF) M. Munakata
Request for Comments: 5767 S. Schubert
Category: Informational T. Ohba
ISSN: 2070-1721 NTT
April 2010
<span class="h1">User-Agent-Driven Privacy Mechanism for SIP</span>
Abstract
This document defines a guideline for a User Agent (UA) to generate
an anonymous Session Initiation Protocol (SIP) message by utilizing
mechanisms such as Globally Routable User Agent URIs (GRUUs) and
Traversal Using Relays around NAT (TURN) without the need for a
privacy service defined in <a href="./rfc3323">RFC 3323</a>.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</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/rfc5767">http://www.rfc-editor.org/info/rfc5767</a>.
Copyright Notice
Copyright (c) 2010 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.
<span class="grey">Munakata, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5767">RFC 5767</a> UA-Driven Privacy Mechanism for SIP April 2010</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Concept of Privacy ..............................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Treatment of Privacy-Sensitive Information ......................<a href="#page-3">3</a>
4.1. Obtaining a Functional Anonymous URI Using the GRUU
Mechanism ..................................................<a href="#page-4">4</a>
4.2. Obtaining a Functional Anonymous IP Address Using
the TURN Mechanism .........................................<a href="#page-5">5</a>
<a href="#section-5">5</a>. UA Behavior .....................................................<a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Critical Privacy-Sensitive Information .....................<a href="#page-6">6</a>
<a href="#section-5.1.1">5.1.1</a>. Contact Header Field ................................<a href="#page-6">6</a>
<a href="#section-5.1.2">5.1.2</a>. From Header Field in Requests .......................<a href="#page-7">7</a>
<a href="#section-5.1.3">5.1.3</a>. Via Header Field in Requests ........................<a href="#page-8">8</a>
<a href="#section-5.1.4">5.1.4</a>. IP Addresses in SDP .................................<a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. Non-Critical Privacy-Sensitive Information .................<a href="#page-8">8</a>
<a href="#section-5.2.1">5.2.1</a>. Host Names in Other SIP Header Fields ...............<a href="#page-8">8</a>
<a href="#section-5.2.2">5.2.2</a>. Optional SIP Header Fields ..........................<a href="#page-9">9</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. References ......................................................<a href="#page-9">9</a>
<a href="#section-7.1">7.1</a>. Normative References .......................................<a href="#page-9">9</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-10">10</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
[<a id="ref-RFC3323">RFC3323</a>] defines a privacy mechanism for the Session Initiation
Protocol (SIP) [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>], based on techniques available at the time
of its publication. This mechanism relies on the use of a separate
privacy service to remove privacy-sensitive information from SIP
messages sent by a User Agent (UA) before forwarding those messages
to the final destination. Since then, numerous SIP extensions have
been proposed and standardized. Some of those enable a UA to
withhold its user's identity and related information without the need
for privacy services, which was not possible when <a href="./rfc3323">RFC 3323</a> was
defined.
The purpose of this document is not to obsolete <a href="./rfc3323">RFC 3323</a>, but to
enhance the overall privacy mechanism in SIP by allowing a UA to take
control of its privacy, rather than being completely dependent on an
external privacy service.
The UA-driven privacy mechanism defined in this document will not
eliminate the need for the <a href="./rfc3323">RFC 3323</a> usage defined in [<a href="./rfc3325" title=""Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks"">RFC3325</a>], which
instructs a privacy service not to forward a P-Asserted-Identity
header field outside the Trust Domain. In order to prevent
forwarding a P-Asserted-Identity header field outside the Trust
Domain, a UA needs to include the Privacy header field with value
<span class="grey">Munakata, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5767">RFC 5767</a> UA-Driven Privacy Mechanism for SIP April 2010</span>
'id' (Privacy:id) in the request, even when the UA is utilizing this
specification.
This document defines a guideline in which a UA controls all the
privacy functions on its own utilizing SIP extensions such as
Globally Routable User Agent URIs (GRUUs) [<a href="./rfc5627" title=""Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)"">RFC5627</a>] and 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>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</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>].
privacy-sensitive information:
The information that identifies a
user who sends the SIP message, as
well as other information that can be
used to guess the user's identity.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Concept of Privacy</span>
The concept of privacy in this document is the act of concealing
privacy-sensitive information. The protection of network privacy
(e.g., topology hiding) is outside the scope of this document.
Privacy-sensitive information includes display-name and Uniform
Resource Identifier (URI) in a From header field that can reveal the
user's name and affiliation (e.g., company name), and IP addresses or
host names in a Contact header field, a Via header field, a Call-ID
header field, or a Session Description Protocol (SDP) [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] body
that might reveal the location of a UA.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Treatment of Privacy-Sensitive Information</span>
Some fields of a SIP message potentially contain privacy-sensitive
information but are not essential for achieving the intended purpose
of the message and can be omitted without any side effects. Other
fields are essential for achieving the intended purpose of the
message and need to contain anonymized values in order to avoid
disclosing privacy-sensitive information. Of the privacy-sensitive
information listed in <a href="#section-3">Section 3</a>, URIs, host names, and IP addresses
in Contact, Via, and SDP are required to be functional (i.e.,
suitable for purpose) even when they are anonymized.
With the use of GRUU [<a href="./rfc5627" title=""Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)"">RFC5627</a>] and TURN [<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>], a UA can obtain
URIs and IP addresses for media and signaling that are functional yet
anonymous, and do not identify either the UA or the user.
<span class="grey">Munakata, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5767">RFC 5767</a> UA-Driven Privacy Mechanism for SIP April 2010</span>
Instructions on how to obtain a functional anonymous URI and IP
address are given in <a href="#section-4.1">Section 4.1</a> and 4.2, respectively.
Host names need to be concealed because the user's identity can be
guessed from them, but they are not always regarded as critical
privacy-sensitive information.
In addition, a UA needs to be careful not to include any information
that identifies the user in optional SIP header fields such as
Subject and User-Agent.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Obtaining a Functional Anonymous URI Using the GRUU Mechanism</span>
A UA wanting to obtain a functional anonymous URI MUST support and
utilize the GRUU mechanism unless it is able to obtain a functional
anonymous URI through other means outside the scope for this
document. By sending a REGISTER request requesting GRUU, the UA can
obtain an anonymous URI, which can later be used for the Contact
header field.
The detailed process on how a UA obtains a GRUU is described in
[<a href="./rfc5627" title=""Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)"">RFC5627</a>].
In order to use the GRUU mechanism to obtain a functional anonymous
URI, the UA MUST request GRUU in the REGISTER request. If a "temp-
gruu" SIP URI parameter and value are present in the REGISTER
response, the user agent MUST use the value of the "temp-gruu" as an
anonymous URI representing the UA. This means that the UA MUST use
this URI as its local target and that the UA MUST place this URI in
the Contact header field of subsequent requests and responses that
require the local target to be sent.
If there is no "temp-gruu" SIP URI parameter in the 200 (OK) response
to the REGISTER request, a UA SHOULD NOT proceed with its
anonymization process, unless something equivalent to "temp-gruu" is
provided through some administrative means.
It is RECOMMENDED that the UA consult the user before sending a
request without a functional anonymous URI when privacy is requested
from the user.
Due to the nature of how GRUU works, the domain name is always
revealed when GRUU is used. If revealing the domain name in the
Contact header field is a concern, use of a third-party GRUU server
is a possible solution, but this is outside the scope of this
document. Refer to the Security Considerations section for details.
<span class="grey">Munakata, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5767">RFC 5767</a> UA-Driven Privacy Mechanism for SIP April 2010</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Obtaining a Functional Anonymous IP Address Using the TURN</span>
<span class="h3"> Mechanism</span>
A UA that is not provided with a functional anonymous IP address
through some administrative means MUST obtain a relayed address (IP
address of a relay) if anonymity is desired for use in SDP and in the
Via header field. Such an IP address is to be derived from a Session
Traversal Utilities of NAT (STUN) relay server through the TURN
mechanism, which allows a STUN server to act as a relay.
Anonymous IP addresses are needed for two purposes. The first is for
use in the Via header field of a SIP request. By obtaining an IP
address from a STUN relay server, using that address in the Via
header field of the SIP request, and sending the SIP request to the
STUN relay server, the IP address of the UA will not be revealed
beyond the relay server.
The second is for use in SDP as an address for receiving media. By
obtaining an IP address from a STUN relay server and using that
address in SDP, media will be received via the relay server. Also,
media can be sent via the relay server. In this way, neither SDP nor
media packets reveal the IP address of the UA.
It is assumed that a UA is either manually or automatically
configured through means such as the configuration framework
[<a href="#ref-SIPPING-CONFIG" title=""A Framework for Session Initiation Protocol User Agent Profile Delivery"">SIPPING-CONFIG</a>] with the address of one or more STUN (Session
Traversal Utilities for NAT) [<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>] relay servers to obtain
anonymous IP address.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. UA Behavior</span>
This section describes how to generate an anonymous SIP message at a
UA.
A UA fully compliant with this document MUST obscure or conceal all
the critical UA-inserted privacy-sensitive information in SIP
requests and responses as shown in <a href="#section-5.1">Section 5.1</a> when user privacy is
requested. In addition, the UA SHOULD conceal the non-critical
privacy-sensitive information as shown in <a href="#section-5.2">Section 5.2</a>.
Furthermore, when a UA uses a relay server to conceal its identity,
the UA MUST send requests to the relay server to ensure request and
response follow the same signaling path.
<span class="grey">Munakata, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5767">RFC 5767</a> UA-Driven Privacy Mechanism for SIP April 2010</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Critical Privacy-Sensitive Information</span>
<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>. Contact Header Field</span>
When using this header field in a dialog-forming request or response
or in a mid-dialog request or response, this field contains the local
target, i.e., a URI used to reach the UA for mid-dialog requests and
possibly out-of-dialog requests, such as a REFER request [<a href="./rfc3515" title=""The Session Initiation Protocol (SIP) Refer Method"">RFC3515</a>].
The Contact header field can also contain a display-name. Since the
Contact header field is used for routing further requests to the UA,
the UA MUST include a functional URI even when it is anonymized.
When using this header field in a dialog-forming request or response
or in a mid-dialog request or response, the UA MUST anonymize the
Contact header field using an anonymous URI ("temp-gruu") obtained
through the GRUU mechanism, unless an equivalent functional anonymous
URI is provided by some other means. For other requests and
responses, with the exception of 3xx responses, REGISTER requests and
200 (OK) responses to a REGISTER request, the UA MUST either omit the
Contact header field or use an anonymous URI.
Refer to <a href="#section-4.1">Section 4.1</a> for details on how to obtain an anonymous URI
through GRUU.
The UA MUST omit the display-name in a Contact header field or set
the display-name to "Anonymous".
<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>. From Header Field in Requests</span>
Without privacy considerations, this field contains the identity of
the user, such as display-name and URI.
RFCs 3261 and 3323 recommend setting
"sip:anonymous@anonymous.invalid" as a SIP URI in a From header field
when user privacy is requested. This raises an issue when the SIP-
Identity mechanism [<a href="./rfc4474" title=""Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)"">RFC4474</a>] is applied to the message, because SIP-
Identity requires an actual domain name in the From header field.
A UA generating an anonymous SIP message supporting this
specification MUST anonymize the From header field in one of the two
ways described below.
Option 1:
A UA anonymizes a From header field using an anonymous display-name
and an anonymous URI following the procedure noted in <a href="./rfc3323#section-4.1.1.3">Section 4.1.1.3
of RFC 3323</a>.
<span class="grey">Munakata, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5767">RFC 5767</a> UA-Driven Privacy Mechanism for SIP April 2010</span>
The example form of the From header field of option 1 is as follows:
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
Option 2:
A UA anonymizes a From header field using an anonymous display-name
and an anonymous URI with user's valid domain name instead of
"anonymous.invalid".
The example form of the From header field of option 2 is as follows:
From: "Anonymous" <sip:anonymous@example.com>;tag=1928301774
A UA SHOULD go with option 1 to conceal its domain name in the From
header field. However, SIP-Identity cannot be used with a From
header field in accordance with option 1, because the SIP-Identity
mechanism uses authentication based on the domain name.
If a UA expects the SIP-Identity mechanism to be applied to the
request, it is RECOMMENDED to go with option 2. However, the user's
domain name will be revealed from the From header field of option 2.
If the user wants both anonymity and strong identity, a solution
would be to use a third-party anonymization service that issues an
Address of Record (AoR) for use in the From header field of a request
and that also provides a SIP-Identity Authentication Service. Third-
party anonymization service is out of scope for this document.
<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>. Via Header Field in Requests</span>
Without privacy considerations, the bottommost Via header field added
to a request by a UA contains the IP address and port or hostname
that are used to reach the UA for responses.
A UA generating an anonymous SIP request supporting this
specification MUST anonymize the IP address in the Via header field
using an anonymous IP address obtained through the TURN mechanism,
unless an equivalent functional anonymous IP address is provided by
some other means.
The UA SHOULD NOT include a host name in a Via header field.
<span class="grey">Munakata, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5767">RFC 5767</a> UA-Driven Privacy Mechanism for SIP April 2010</span>
<span class="h4"><a class="selflink" id="section-5.1.4" href="#section-5.1.4">5.1.4</a>. IP Addresses in SDP</span>
A UA generating an anonymous SIP message supporting this
specification MUST anonymize IP addresses in SDP, if present, using
an anonymous IP address obtained through the TURN mechanism, unless
an equivalent functional anonymous IP address is provided by some
other means.
Refer to <a href="#section-4.2">Section 4.2</a> for details on how to obtain an IP address
through TURN.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Non-Critical Privacy-Sensitive Information</span>
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Host Names in Other SIP Header Fields</span>
A UA generating an anonymous SIP message supporting this
specification SHOULD conceal host names in any SIP header fields,
such as Call-ID and Warning header fields, if considered privacy-
sensitive.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Optional SIP Header Fields</span>
Other optional SIP header fields (such as Call-Info, In-Reply-To,
Organization, Referred-By, Reply-To, Server, Subject, User-Agent, and
Warning) can contain privacy-sensitive information.
A UA generating an anonymous SIP message supporting this
specification SHOULD NOT include any information that identifies the
user in such optional header fields.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This specification uses GRUU and TURN and inherits any security
considerations described in these documents.
Furthermore, if the provider of the caller intending to obscure its
identity consists of a small number of people (e.g., small
enterprise, Small Office, Home Office (SOHO)), the domain name alone
can reveal the identity of the caller.
The same can be true when the provider is large but the receiver of
the call only knows a few people from the source of call.
There are mainly two places in the message, the From header field and
Contact header field, where the domain name is expected to be
functional.
<span class="grey">Munakata, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5767">RFC 5767</a> UA-Driven Privacy Mechanism for SIP April 2010</span>
The domain name in the From header field can be obscured as described
in <a href="#section-5.1.2">Section 5.1.2</a>, whereas the Contact header field needs to contain a
valid domain name at all times in order to function properly.
Note: Generally, a device will not show the contact address to the
receiver, but this does not mean that one cannot find the domain name
in a message. In fact, as long as this specification is used to
obscure identity, the message will always contain a valid domain name
as it inherits key characteristics of GRUU.
Note: For UAs that use a temporary GRUU, confidentiality does not
extend to parties that are permitted to register to the same AoR or
are permitted to obtain temporary GRUUs when subscribed to the 'reg'
event package [<a href="./rfc3680" title=""A Session Initiation Protocol (SIP) Event Package for Registrations"">RFC3680</a>] for the AoR. To limit this, it is suggested
that the authorization policy for the 'reg' event package permit only
those subscribers authorized to register to the AoR to receive
temporary GRUUs. With this policy, the confidentiality of the
temporary GRUU will be the same whether or not the 'reg' event
package is used.
If one wants to assure anonymization, it is suggested that the user
seek and rely on a third-party anonymization service, which is
outside the scope of this document.
A third-party anonymization service provides registrar and TURN
service that have no affiliation with the caller's provider, allowing
caller to completely withhold its identity.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.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>, March 1997.
[<a id="ref-RFC3261">RFC3261</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley,
M., and E. Schooler, "SIP: Session Initiation
Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.
[<a id="ref-RFC4566">RFC4566</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
[<a id="ref-RFC5627">RFC5627</a>] Rosenberg, J., "Obtaining and Using Globally
Routable User Agent URIs (GRUUs) in the Session
Initiation Protocol (SIP)", <a href="./rfc5627">RFC 5627</a>, October 2009.
<span class="grey">Munakata, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5767">RFC 5767</a> UA-Driven Privacy Mechanism for SIP April 2010</span>
[<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>, April 2010.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC3323">RFC3323</a>] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", <a href="./rfc3323">RFC 3323</a>,
November 2002.
[<a id="ref-RFC3325">RFC3325</a>] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP)
for Asserted Identity within Trusted Networks",
<a href="./rfc3325">RFC 3325</a>, November 2002.
[<a id="ref-RFC3515">RFC3515</a>] Sparks, R., "The Session Initiation Protocol (SIP)
Refer Method", <a href="./rfc3515">RFC 3515</a>, April 2003.
[<a id="ref-RFC3680">RFC3680</a>] Rosenberg, J., "A Session Initiation Protocol (SIP)
Event Package for Registrations", <a href="./rfc3680">RFC 3680</a>,
March 2004.
[<a id="ref-RFC4474">RFC4474</a>] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", <a href="./rfc4474">RFC 4474</a>, August 2006.
[<a id="ref-SIPPING-CONFIG">SIPPING-CONFIG</a>] Channabasappa, S., "A Framework for Session
Initiation Protocol User Agent Profile Delivery",
Work in Progress, September 2009.
<span class="grey">Munakata, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5767">RFC 5767</a> UA-Driven Privacy Mechanism for SIP April 2010</span>
Authors' Addresses
Mayumi Munakata
NTT Corporation
EMail: munakata.mayumi@lab.ntt.co.jp
Shida Schubert
NTT Corporation
EMail: shida@ntt-at.com
Takumi Ohba
NTT Corporation
9-11, Midori-cho 3-Chome
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 7748
EMail: ohba.takumi@lab.ntt.co.jp
URI: <a href="http://www.ntt.co.jp">http://www.ntt.co.jp</a>
Munakata, et al. Informational [Page 11]
</pre>
|
