< draft-ietf-sip-ua-privacy-00.txt   draft-ietf-sip-ua-privacy-01.txt >
SIP M. Munakata SIP M. Munakata
Internet-Draft S. Schubert Internet-Draft S. Schubert
Intended status: Standards Track T. Ohba Intended status: Standards Track T. Ohba
Expires: May 15, 2008 NTT Expires: August 22, 2007 NTT
November 12, 2007 February 18, 2008
UA-Driven Privacy Mechanism for SIP UA-Driven Privacy Mechanism for SIP
draft-ietf-sip-ua-privacy-00 draft-ietf-sip-ua-privacy-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 15, 2008. This Internet-Draft will expire on August 22, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
To withhold a user's identity and related information, RFC 3323 To withhold a user's identity and related information, RFC 3323
defines a Privacy mechanism for SIP, which requires the use of an defines a Privacy mechanism for SIP, which requires the use of an
privacy service. This document proposes a new privacy mechanism that privacy service. This document proposes a new privacy mechanism that
a user agent can facilitate to conceal privacy-sensitive information a user agent can facilitate to conceal privacy-sensitive information
without the need for aid from a privacy service. without the need for aid from a privacy service.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 4 3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Treatment of Privacy-Sensitive Information . . . . . . . . . . 5
6. Treatment of User Privacy Related Information . . . . . . . . 5 5.1. Anonymous URI and Display-Name . . . . . . . . . . . . . . 5
6.1. Anonymous URI . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Anonymous IP Address . . . . . . . . . . . . . . . . . . . 6
6.2. Anonymous IP Address . . . . . . . . . . . . . . . . . . . 6 6. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7
7. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7 6.1. Generating Anonymous Message . . . . . . . . . . . . . . . 7
7.1. Generating Anonymous Message . . . . . . . . . . . . . . . 7 6.2. Indication to Maintain Privacy . . . . . . . . . . . . . . 7
7.2. Indication to maintain Privacy . . . . . . . . . . . . . . 7 7. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
Privacy is defined in this document as the withholding of the Privacy is defined in [RFC3323] as the withholding of the identity of
identity of a person (and related personal information) from a person (and related personal information) from destination(s) of
destination(s) of messages and/or intermediaries handling these messages and/or intermediaries handling these messages in an exchange
messages in a SIP (Session Initiation Protocol) [RFC3261] dialog. of SIP (Session Initiation Protocol) [RFC3261] communications.
In SIP, identity is most commonly carried in the form of a SIP URI In SIP, identity is most commonly carried in the form of a SIP URI
and an optional display name, which commonly appear in the To, From and an optional display-name, which commonly appear in the To, From
and other header fields of SIP requests and responses. and other header fields of SIP requests and responses.
There are numerous other places in SIP messages in which identity- There are numerous other places in SIP messages in which identity-
related information can be revealed. For example, the Contact header related information can be revealed. For example, the Contact header
field contains a SIP URI. Moreover, information in the Record-Route field contains a SIP URI. Moreover, information in the Record-Route
and Via headers could inadvertently reveal something about the and Via headers could inadvertently reveal something about the
originator of a message. originator of a message.
To provide privacy, [RFC3323] defines a privacy mechanism for SIP, RFC 3323 defines privacy mechanisms for SIP, based on techniques
which was then the best current practice to maintain privacy. Since available at the time of publication. Some of these mechanisms rely
then, numerous SIP extensions have been proposed and standardized. on the use of a separate privacy service to remove sensitive
Some of those seem to enable a user agent to withhold its user's information from messages sent by a user agent before forwarding
identity and related information without dependency on privacy those messages to the final destination. Since then, numerous SIP
services, which was not possible when RFC3323 was defined. extensions have been proposed and standardized. Some of those seem
to enable a user agent to withhold its user's identity and related
Some aspect of RFC 3323, especially its dependency on a privacy information without dependency on privacy services, which was not
service to provide privacy, seems to cause some issues, which we hope possible when RFC 3323 was defined.
that we can resolve with this specification.
Some of the issues identified with the RFC 3323 are shown below. A number of issues have been identified with the mechanisms defined
in RFC 3323, especially with mechanisms that depend on a privacy
service.
1. There is no assurance that a privacy service exists in the 1. There is no assurance that a privacy service exists in the
signaling path. signaling path.
2. There is no way that the user requesting the privacy can figure 2. There is no way that the user requesting the privacy can figure
out that the privacy function was properly executed. out that the privacy function was properly executed.
3. A privacy service that modifies a Call-ID in the establishment of 3. A privacy service that modifies a Call-ID must be present in the
the original dialog must be in the signaling path of the signaling path of any subsequent requests that carry that
subsequent request such as REFER. If a privacy service Call-ID. For requests within the same dialog this can be
anonymizes a Call-ID and the anonymized Call-ID is referenced in achieved using the record-route mechanism. For requests outside
a subsequent SIP message for the purpose of a call-back or a call the dialog that carry the Call-ID in a Replaces, Join or Target-
replacement, the privacy service needs to be in a signaling path Dialog header field, for example, there is no defined mechanism.
to replace the anonymized Call-ID with the original Call-ID
appropriately, regardless of being inside/outside the dialog.
4. To map the referenced dialog to a dialog attempt invoked by 4. To map the referenced dialog to a dialog attempt invoked by
REFER, for example, the privacy service needs to retain the REFER, for example, the privacy service needs to retain the
correspondence relation between original information and modified correspondence relation between original information and modified
information beyond the actual dialog duration of the referenced information beyond the actual dialog duration of the referenced
dialog. dialog.
To solve the problems, this document proposes a new privacy mechanism To solve the problems, this document proposes a new privacy mechanism
in which a user agent executes all the privacy functions on its own in which a user agent controls all the privacy functions on its own
utilizing SIP extensions such as GRUU (Globally Routable User Agent utilizing SIP extensions such as GRUU (Globally Routable User Agent
URIs)[I-D.ietf-sip-gruu] and TURN (Traversal Using Relay URIs)[I-D.ietf-sip-gruu] and TURN (Traversal Using Relay
NAT)[I-D.rosenberg-midcom-turn]. NAT)[I-D.ietf-behave-turn].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Concept of Privacy privacy-sensitive information:
The information that identifies a user who sends the SIP
The concept of privacy in this document means the concealing of message, as well as the supplementary information that
information that relates to a user, identifies a user, and belongs to can be used to guess the user's identity.
a user, as well as the supplementary information that can be used to
guess the user's identity. The scope of this document is to withhold
the identity of a user and supplementary information from other users
and intermediaries handling the message. The protection of network
privacy (e.g., topology hiding) is outside the scope of this
document.
User-privacy-related information includes display name and URI in a
From header that can reveal the user's name and affiliation (e.g.,
company name), contact information in a Contact header that is used
to communicate with the user, an IP address in an SDP (Session
Description Protocol)[RFC4566] that tells the location of a user's
terminal and can be used to establish a connection. A host name in
Call-ID is also regarded as user-privacy-related information because
it may reveal the user's domain name.
Privacy-sensitive information is divided into two types, user-
inserted information and network-inserted information. A user agent
can maintain privacy of the user-inserted information by itself. On
the other hand, regarding the network-inserted information, a user
agent can insert a privacy flag and request intermediaries not to add
the user-privacy-related information.
4. Use Cases
The following are the use cases from the viewpoint of privacy.
Case 1: User privacy is required and a user agent can anonymize all 3. Concept of Privacy
of the user-inserted privacy-related information by itself.
Case 2: User privacy is required but a user agent cannot anonymize The concept of privacy in this document means the concealing of the
the user-inserted privacy-related information all by itself. identity of a user and supplementary information. The scope of this
document is to withhold the privacy-sensitive information of the user
who sends the SIP message from other users and intermediaries
handling the message. The protection of network privacy (e.g.,
topology hiding) is outside the scope of this document.
Case 3: User privacy is not required. The user does not want Privacy-sensitive information includes display-name and URI in a From
privacy at all and would like to reveal his/her identity. header that can reveal the user's name and affiliation (e.g., company
name), contact information in a Contact header that is used to
communicate with the user's UA, an IP address in an SDP (Session
Description Protocol)[RFC4566] that tells the location of a user's UA
and can be used to establish a connection. A host name in Call-ID is
also regarded as privacy-sensitive information because it may reveal
the user's domain name.
Note that Case 2 is based on the premise that the user agent has Privacy-sensitive information is divided into two types, information
limited capabilities and it cannot find a GRUU or TURN server. Case inserted by the user's UA and information inserted by other SIP
2 is outside the scope of this document. entities (e.g., proxies, B2BUAs). A user agent can maintain privacy
of the UA-inserted information by itself. On the other hand,
regarding the information inserted by other entities, a user agent
can insert a privacy flag and request intermediaries not to add the
privacy-sensitve information.
5. Requirements 4. Requirements
The following are requirements to cover the use cases in the previous The requirements for the UA-driven privacy mechanism are as follows:
section.
Req 1: A user agent MUST be able to send a SIP request that is fully Req 1: A user agent MUST be able to send a SIP request that is fully
anonymized. This is, any headers and body inserted by the UA anonymized. This is, any headers and body inserted by the
does not jeopardize user privacy. user agent does not jeopardize user privacy.
Req 2: It MUST be possible for a user agent to indicate to Req 2: It MUST be possible for a user agent to indicate to
downstream entities that a user is requesting privacy. downstream entities that a user is requesting privacy.
Req 3: When privacy is requested, a proxy SHOULD honor the request Req 3: When privacy is requested, a proxy SHOULD honor the request
and only add information necessary to route the call while and only add information necessary to route the call while
withholding any sensitive information that may reveal withholding any sensitive information that may reveal
anything about the user if possible. anything about the user if possible.
Req 4: Mechanism defined here MUST be backward compatible with the Req 4: Mechanism defined here MUST be backward compatible with the
pre-existing privacy mechanism already in place. pre-existing privacy mechanism already in place.
6. Treatment of User Privacy Related Information 5. Treatment of Privacy-Sensitive Information
RFC 3323 does not provide means to obscure two important pieces of Except by means of a privacy service, RFC 3323 does not provide means
information about the user agent, which are a URI used to exchange to obscure two important pieces of information about the user agent,
signaling (Contact, From, for example), and an IP address used to which are a URI used to exchange signaling (Contact, From, for
exchange media. example), and IP address(es) used to exchange media.
RFC 3323 recommends to set sip:anonymous@anonymous.invalid as a SIP
URI in a From header when user privacy is required. Although, the
From header field URI may need to be an anonymous but functional URI.
For example, a mechanism of SIP-Identity [RFC4474] requires a
functional From header even if it is anonymous.
With the use of GRUU [I-D.ietf-sip-gruu] and TURN With the use of GRUU [I-D.ietf-sip-gruu] and TURN
[I-D.rosenberg-midcom-turn], UA can now obtain URI and IP address [I-D.ietf-behave-turn], a user agent can now obtain URI(s) and IP
that are functional, which are usable to exchange either signaling or address(es) for media that are functional yet anonymous, in that they
media while providing privacy. do not identify the user agent.
6.1. Anonymous URI 5.1. Anonymous URI and Display-Name
A user agent wanting to obtain functional anonymous URI SHOULD A user agent wanting to obtain functional anonymous URI SHOULD
support and SHOULD utilize the Global Routable User Agent URI (GRUU) support and SHOULD utilize the GRUU mechanism. By sending a REGISTER
mechanism. By sending a REGISTER request requesting GRUU, the UA can request requesting GRUU, the UA can obtain an anonymous URI, which
obtain an anonymous URI, which can later be used for From, Contact can later be used for Contact header.
and other headers where the URI of the originator is needed.
The detailed process on how a user agent obtains a GRUU is described The detailed process on how a user agent obtains a GRUU is described
in [I-D.ietf-sip-gruu]. If the Registrar supports GRUU and returns a in [I-D.ietf-sip-gruu]. If the Registrar supports GRUU and returns a
REGISTER response, the user agent SHOULD search within the REGISTER REGISTER response, the user agent SHOULD search within the REGISTER
response for a "temp-gruu" URI parameter, which provides the desired response for a "temp-gruu" URI parameter, which provides the desired
privacy property. privacy property.
If the "temp-gruu" URI parameter and value exist within the REGISTER If the "temp-gruu" URI parameter and value exist within the REGISTER
response, the user agent SHOULD use the value of the "temp-gruu" as response, the user agent SHOULD use the value of the "temp-gruu" as
an anonymous URI representing the originator. This URI SHOULD be an anonymous URI representing the user agent. This URI SHOULD be
used for Contact and From, for example, wherever the originator of used for Contact header.
the URI is required.
The user agent setting the "temp-gruu" as a GRUU SHOULD set The user agent using the "temp-gruu" as a contact URI is RECOMMENDED
"Anonymous" as a display name in any header where the display name of to set "Anonymous" as a display-name in any header where the display-
the originator is set. That indicates the anonymity of the request name of the originator is set. That indicates the anonymity of the
to intermediaries that may invoke some services based on the request to intermediaries that may invoke some services based on the
anonymity of the call. The temp-gruu alone is not sufficient to anonymity of the call. The temp-gruu alone is not sufficient to
invoke such service because GRUU is merely a URI that is a sequence invoke such service because GRUU is merely a URI that is a sequence
of strings and digits with no explicit semantics to indicate that it of strings and digits with no explicit semantics to indicate that it
is an anonymous URI. is an anonymous URI.
If there is no "temp-gruu" URI parameter in the 200 response to the If there is no "temp-gruu" URI parameter in the 200 response to the
REGISTER request, a user agent SHOULD NOT proceed with its REGISTER request, a user agent SHOULD NOT proceed with its
anonymization process, unless something equivalent to "temp-gruu" is anonymization process, unless something equivalent to "temp-gruu" is
provided through some administrative means. provided through some administrative means.
Note: How to obtain an anonymous URI for From and any headers other
than the Contact is FFS.
It is RECOMMENDED that user agent consult the user before sending a It is RECOMMENDED that user agent consult the user before sending a
request without a functional anonymous URI when privacy is request request without a functional anonymous URI when privacy is request
from the user. from the user.
6.2. Anonymous IP Address 5.2. Anonymous IP Address
It is assumed that a user agent is either manually or automatically It is assumed that a user agent is either manually or automatically
configured through means such as a configuration framework with one configured through means such as a configuration framework
or more STUN relay servers. [I-D.ietf-sipping-config-framework] with the address of one or more
STUN relay servers.
Two IP addresses are needed to maintain privacy, one to be used in Two IP addresses are needed to maintain privacy, one to be used in
signaling such as in a Via header, another to be used in SDP for signaling such as in a Via header, another to be used in SDP for
media. media.
A user agent that is not provided with a functional anonymous IP A user agent that is not provided with a functional anonymous IP
address through some administrative means, SHOULD obtain a relayed address through some administrative means, SHOULD obtain a relayed
address (IP address of the media relay) for use in SDP, derived from address (IP address of the media relay) for use in SDP, derived from
a STUN relay server using the STUN Relay a STUN [I-D.ietf-behave-turn] relay server using the STUN relay
Usage[I-D.rosenberg-midcom-turn], which allows a STUN server to act usage, which allows a STUN server to act as a media relay.
as a media relay.
Note: A relayed IP address may be used for a Via header, but some Note: A relayed IP address may be used for a Via header, but some
commented that is not an appropriate to be used for signaling. commented that is not an appropriate to be used for signaling.
There was a comment about the IP address in Via being stripped There was a comment about the IP address in Via being stripped
by the proxy, but that would require that a proxy compliant to by the proxy, but that would require that a proxy compliant to
this specification is in the signaling path. this specification is in the signaling path.
7. User Agent Behavior 6. User Agent Behavior
A user agent fully compliant with this document SHOULD obscure or A user agent fully compliant with this document SHOULD obscure or
conceal all the user-inserted privacy-related information in SIP conceal all the UA-inserted privacy-sensitive information in SIP
requests and responses when user privacy is requested. Section 7.1 requests and responses when user privacy is requested. Section 6.1
describes how to generate an anonymous message at a user agent. describes how to generate an anonymous message at a user agent.
When a user agent generates an anonymous message based on this When a user agent generates an anonymous message based on this
specification, it SHOULD set an indication to tell intermediaries not specification, it SHOULD set an indication to tell intermediaries not
to add or modify user-privacy-related information. Section 7.2 to add privacy-sensitive information. Section 6.2 describes more
describes more about this. about this.
7.1. Generating Anonymous Message 6.1. Generating Anonymous Message
The two pieces of information that a user agent needs to obscure The two pieces of information that a user agent needs to obscure
while sustaining its purpose and functionality are the URI and IP while sustaining its purpose and functionality are the URI and IP
address used for establishing a media/signaling session. address used for establishing a media/signaling session.
Instructions on how to obtain an functional anonymous URI and IP Instructions on how to obtain an functional anonymous URI and IP
address are given in Section 6.1 and 6.2, respectively. address are given in Section 5.1 and 5.2, respectively.
For anonymizing any headers and information in a SIP message, the For anonymizing any headers and information in a SIP message, the
user agent SHOULD follow the instructions in this document. user agent SHOULD follow the instructions in this document.
Note: Instructions to treat each SIP header/parameter in generating Note: Instructions to treat each SIP header/parameter in generating
an anonymous SIP message SIP message will be given in a future. an anonymous SIP message will be given in a future version of
this draft.
7.2. Indication to maintain Privacy 6.2. Indication to Maintain Privacy
This document defines a privacy flag, which indicates that the user This document defines a privacy flag, which indicates that the user
requires privacy for the SIP message. Without a privacy flag, requires privacy for the SIP message. Without a privacy flag,
intermediaries might add some user-privacy-related information in the intermediaries might add some privacy-sensitive information in the
message, even if a user agent had anonymized the message as perfectly message, even if a user agent had anonymized the message as perfectly
as possible. as possible.
When a user agent generates an anonymous message by itself according When a user agent generates an anonymous message by itself according
to the guidelines in Section 7.1, it SHOULD set a flag to request to the guidelines in Section 6.1, it SHOULD set a flag to request
intermediaries not to add user-privacy-related information. intermediaries not to add privacy-sensitive information.
Note: The mechanism of the flag is FFS. Note: The mechanism of the flag is FFS.
8. Proxy Behavior 7. Proxy Behavior
When a proxy receives a SIP message containing a privacy flag, the When a proxy receives a SIP message containing a privacy flag, the
proxy compliant with this specification MUST NOT add any information proxy compliant with this specification MUST NOT add any information
that may reveal something about the sender that is irrelevant to that may reveal something about the sender that is irrelevant to
routing unless the proxy knows that such information will be deleted routing unless the proxy knows that such information will be deleted
before it leaves the boundary of the Trust Domain[RFC3324]. before it leaves the boundary of the Trust Domain[RFC3324].
A proxy MUST NOT modify the privacy flag, if present. A proxy MUST NOT modify the privacy flag, if present.
9. Security Considerations 8. Security Considerations
TBD TBD
10. IANA Considerations 9. IANA Considerations
TBD TBD
11. References 10. References
11.1. Normative References 10.1. Normative References
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-06 (work in progress),
January 2008.
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007. October 2007.
[I-D.rosenberg-midcom-turn]
Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-08 (work in progress),
September 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
10.2. Informative References
[I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-15 (work in progress),
February 2008.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002. Initiation Protocol (SIP)", RFC 3323, November 2002.
11.2. Informative References
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted [RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002. Identity", RFC 3324, November 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Description Protocol", RFC 4566, July 2006. Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
Authors' Addresses Authors' Addresses
Mayumi Munakata Mayumi Munakata
NTT Corporation NTT Corporation
Phone: +81 422 36 7565 Phone: +81 422 36 7565
Email: munakata.mayumi@lab.ntt.co.jp Email: munakata.mayumi@lab.ntt.co.jp
Shida Schubert Shida Schubert
 End of changes. 48 change blocks. 
140 lines changed or deleted 144 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/