5.7. SIP Mediation¶
SIP Mediation features of the ABC SBC allow administrators to introduce massive changes to the signaling protocol. This is often necessiated by devices with imperfect SIP support, differing practices such as dialing plans between peering providers, or need to implement network-based services such as Private Asserted Identity (RFC 3325).
The actual mediation rules are placed in inbound and outbound rules. The inbound rules are used to modify incoming traffic coming from a Realm or a Call Agent to comply to local policies. For example, the inbound rules may transform telephone numbers from a local PBX’s dialling plan to the global E.164 standard. All subsequent actions already work with modified SIP messages. The outbound rules are used to modify outgoing traffic to a form that the receiving Call Agent can or shall process. For example the outbound rules can remove all but low-bandwidth codecs for the target known to be on a low-speed link.
It needs to be understood that mediation is a double-edged sword: massive changes to the signaling protocol can, if not configured properly, cause substantial harm to interoperability. If the ABC SBC encounters, that a SIP message modified by mediation rules breaks standard too far (such as if it generates an empty header-field), it discontinues processing of the message and sends a 500 response back. Still many changes may be syntactically legitimate, remain undetected and result in impaired interoperability.
This section discusses mediation of the signaling protocol, SIP. Mediation of media, that includes codec negotiation and transcoding, is documented in the section Media Handling.
5.7.1. Why is SIP Mediation Needed?¶
There are multifold root causes why SIP devices have often troubles communicating with each other. There are different standardization groups working on SIP. Different developers often interpret the same specifications differently. Operators deploy different operational and naming practices.
The ABC SBC has the capability to overcome some of these interoperability problems by manipulating the content of SIP messages so that they better fit the expectations of the receiving side. One can distinguish between several frequent interoperability issues: compatibility between various SIP protocol extensions, dealing with deviations from the specification and best current practices caused by non-compliant devices and operating procedures, and incompatibility between different transport protocols used for conveying SIP signaling.
SIP Standard Extensions:
There are various flavors of the SIP protocol. Even the basic SIP IETF standard is extended by tens of accompanying specifications, some of them are deployed, some of them not. Several other standardization bodies have chosen to add even more extensions specific to their use of SIP. In the fixed environment, the TISPAN specifications <http://www.etsi.org/tispan/> are used. In the mobile network environment the 3GPP IMS specifications <http://www.3gpp.org/> are the most favoured. SIP-I <http://www.itu.int/rec/T-REC-Q.1912.5-200403-I/en> is proposed for trunking scenarios in which SIP is used as the signalling protocol used to connect SS7 based networks over an IP core network.
The differences between the SIP specifications from IMS, IETF and TISPAN are mainly restricted to the addition of certain headers, authentication mechanisms and usage of certain SIP extensions such as NOTIFY/SUBSCRIBE or certain XML body formats.
In the context of interoperability of SIP flavours, the ABC SBC can provide the following services:
- Stateless SIP header manipulation: The ABC SBC can be configured to remove certain headers and add others. This way, The ABC SBC can for example delete headers that are useful in an IMS or TISPAN but not in an IETF SIP environment.
- Message blocking: Certain SIP messages might be useful in one network as they provide a certain service. However, if this service is not provided across the interconnection points then exchanging them across the networks does not make sense. SBCs can be configured to reject certain messages such as NOTIFY if presence services are not provided across the network for example.
Deviations from the SIP Standard and Best Practices:
The experience from various interoperability events shows that different vendors interpret the SIP specifications slightly differently. Especially parts that are specified with the strength of “SHOULD” or “MAY” are often implemented as a “MUST” or ignored completely. This makes the communication between two components from different vendors sometimes impossible. Sometimes even if the SIP equipment implements the standard correctly, operators practices for deploying SIP differ to the extent that the protocol needs to be fixed.
The ABC SBC can be configured to overcome some of these issues and to fix certain issues that cause these interoperability problems by offering the following features:
- Existence of certain headers: Some SIP components expect to see certain SIP headers with certain information, for example a Route header pointing to them. Others might not bother to add this header. The ABC SBC can be configured to take these special interpretations of the implementers into account before forwarding a request and add or remove problematic headers.
- Location of information: Some SIP components expect to see their address in the Request-URI whereas others want to see it in the Route header or both. This might not always be how the location information is included in the SIP request especially if a request was redirected from one component to another.
- Tags and additional information: Again some SIP components might expect to see certain tags and parameters attached to certain headers such as rport with a Via header whereas other SIP components might not add them.
SIP can be transported over UDP, TCP and TLS. The capabilities of different SIP implementations might vary with this regard. That is, some components could support UDP but not TCP and others prefer to use TLS. Therefore, the ABC SBC can be used to convert the transport protocol used by the source to the transport protocol preferred by the destination.
5.7.2. Request-URI Modifications¶
The most common manipulation is that of request-URI. Request URI describes who should receive the SIP request. It may include an E.164 telephone number (like sip:+firstname.lastname@example.org), a PBX number (sip:email@example.com) or be formed as an email-like address (sip:firstname.lastname@example.org). A typical reason for changing the request URI is normalisation of different dialling plans. As an example you may translate a local extension number (768) for a PBX with prefix (+1-404-1234) into a globally routable E.164-based URI sip:+email@example.com. You can use several types of modifications to the request-URI, all of them are applied only to the first session’s request. The most important request-URI actions are the following:
- Strip RURI user: strips the specified number of leading characters from the user part of request URI. For example strip-RURI-user(1) applied to the PBX URI firstname.lastname@example.org yields the extension sip:email@example.com without the local “8” prefix. The action is applied as many times as it is callled.
- Prefix RURI user: inserts a prefix to the user part of request URI. For example, prefix-URI(“+1-404-1234-”) applied to the URI from the previous step yields sip:+firstname.lastname@example.org. The result is accumulated if the action is applied several times.
- Append to RURI user: appends a suffix to the user part of request URI. The parameter takes suffix value. It may include replacement expressions. The result is accumulated if the action is applied several times.
- set RURI: entirely replaces the request URI with a new value.
Also note that the resulting URI not only describes the recipient, but its host part is used to determine the next hop IP address if a route is used with the Route via R-URI option.
It is also worthwhile mentioning that URIs often represent additional services a caller gets. For example if a caller prefixes number of an O2 subscriber in Germany with 33, his call will be directly routed to the recipient’s voicemail. However administrators would be ill advised to overload request URI with more than routing functionality. An infamous example is using a plain-text password as phone number prefix for authentication. The fraudster Edwin Pena <http://www.fbi.gov/newark/press-releases/2010/nk020310a.htm> found that out, yielded more than 10 million minutes of VoIP service and in 2009 eventually two years in federal prison.
Several other mediation actions can process sub-parts of request-URI. They include:
Set RURI host
- Replace host(:port) part of Request-URI with a new value specified in the GUI.
- Parameters: new host or host:port
Set RURI parameter
- Add or replace parameter of Request-URI.
- Parameters: RURI parameter name, RURI parameter value
Set RURI user
- Replace user part of Request-URI with a new value.
- Parameters: new user part.
Set RURI user parameter
- Add or replace parameter of user part of Request-URI.
- Parameters: parameter name, parameter value.
5.7.3. Changing Identity¶
Identity of SIP session participants is also described in many other SIP header fields that sometimes need to be changed.
Every SIP request must include URIs of session initiator in the From header-field and URI of intended recipient in the To header field. The SIP standard has intended to use the From and To header field only as informational description of how a session was started . URI of the originator in the From header field has limitied identity value as the plain-text URI is not covered by a message integrity check and can be easily changed by elements in the SIP-path. Even a user client is quite free to put anything in the URI unless there is a client’s outbound SIP proxy enforcing specific address for a digest-verified caller.
The URI in To header-field may have little relation to the actual recipient of a SIP request as the actual next hop is stored in the request URI.
Notwithstanding how “light-weight” information From and To header fields convey, some operators deploy policies based on them. They may only accept requests with From and To URIs that comply to their local convention. There were even cases when To URI was used for routing. Therefore it is often useful to modify To and From header fields. These modification rules apply to the first request of a SIP dialog. From and To in all subsequent messages of a session are transformed transparently in compliance with the SIP protocol specification. The most important To and From changing actions are the following:
Set From / Set To :replaces the whole From/To header field with a new value, for example “Jasmine Blue” sip:email@example.com. Only “tags” in the From/To header-fields remain unchanged to guarantee unique identification of SIP dialogs.
Set From User / Set To User: replaces the user part of the From/To URI.
Set From Host / Set To host: replaces the host(:port) part of URI with a new value
Set From / To display name
- Set only the display name of the From / To header.
- Parameter: new display name.
Additionally, the SIP protocol is using digest authentication identity (RFC 2617) to verify who is initiating a request. If the digest identity of a request originator needs to be changed, the action UAC auth is used. It takes the following paramters needed for the authentication procedure: username, password and realm. A request forwarded downstream and challenged to authenticate by a downstream server is then resubmitted by the ABC SBC using these credentials.
188.8.131.52. Substitution Expressions¶
SIP message modifications typically “glue” pieces of the original messages and intended changes. For example, a new To URI is to be formed using destination’s hostname (say “target-gw.com”) and telephone number in request URI (say “+1-404-1234-567”). The corresponding set-To action needs to access the telephone number in the original request. To address cases like this, the mediation parameters may refer to elements of the original message by so called Replacement expressions. These always begin with a $ character. In our example, the user part of the request URI is referred to as “$rU” and the action has the form:
Set To (“sip:$rU@targetgw.com”).
Other important replacement expressions are $fu for From URI, $tu for To URI, $si for source IP address, $H(headername) for value of a header field.
If you need to access some sub-parts of the original SIP message without an addressable name, simple substitution expression are not enough. Then regular expressions have to be used to select them. This is called „regexp backreferences. The backreference expressions refer to parts of SIP messages that were matched in rules’ conditions. For example, to access the protocol discriminator in a URI, you need to create a rule condition matching it using regular expression, and then refer to the matched expression. You would be forming a rule like this:
Figure 1: Example of a Condition Being Referred to by a Backreference Expression
the second condition’s first sub-part (i.e. matched by the expression in the first parenthesses) of the regular expression would identify the protocol discriminator and yield “sip” for SIP URIs. The expression would be formed as this
5.7.5. Early Media, Ring Back Tone and Forking¶
In SIP, so called “early media” and “forking” are quite complex SIP features which make interoperability sometimes a challenge, especially when occuring together.
Early media appeared in the SIP protocol as a PSTN backwards-compatibility feature. In PSTN the difference between early media like “please wait your call is important to us” and the actual call is simple: the latter is charged for, the former is not. This is by the way the reason, why “early media” is sometimes humorously refered to as “late charging”. Early media appear often when the called party is a PSTN gateway. The same protocol vehicle is often also used to implement “ring back tone”. The protocol flow is rather simple: The callee sends a provisional response with a reply code equal to 180 or 183 including an SDP answer and starts sending RTP with the ring back tone to the caller. Usually, the caller User Agent only starts rendering the ring back tone to the user when this response is received. The protocol usage examples and details are well described in the RFC 3960.
Forking is a feature anchored in the SIP specification RFC 3261. It permits SIP proxy servers to forward one incoming requests to multiple different destinations. For example, one can setup this way all his phones to ring in parallel: soft-phone, hard-phone, smart-phone and even a PSTN phone behind a PSTN gateway. Forking can occur in parallel or in series. If serial forking is used, a forking proxy following best current practices sends a 181 inbetween. The “forked” INVITE requests may look almost identical but each of them always must have a unique “branch” identifier in the topmost Via header field.
Various unpredictable situations appear when forking and early media appears at the same time. For example two PSTN gateways send both early media to the caller. To deal with such situations the ABC SBC does only accept the first early media stream and discards the subsequently received ones.
The actions described in this Section help to customize the behaviour of the ABC SBC to some special cases.
The action Drop SDP from 1xx replies drops SDP payload from all listed 1xx SIP answers. The action takes as parameter a comma-separated list of reply codes. SDP payloads are dropped from all responses with any of these codes. This action is especially useful if specific replies should be handled, for example a locally generated ring back tone should be preferred to a ring back tone from the far end. Note that the RTP relay is not started if all provisional response are dropped, i.e. a provisional response needs to be processed for the RTP relay to be initialised, also for relaying early media.
Figure 3: Drop SDP from reply
Another action Drop early media drops the RTP packets of early media, that is until the call is established. Note that if early media shall be dropped from signaling entirely, the actions “Drop SDP from 1xx replies” in combination with “Translate reply code” 183->180 must be used.
Figure 4: Drop early media
- Support serial-forking proxy: This action allows to reset early media when a downstream SIP proxy server indicates by a 181 reponse that
- it has chosen to try some other destination for the call. By default, only the first early media arriving to the SBC is permitted, all other early media is dropped. This strict policy assures that downstream SIP forking cannot create multiple early media streams mutually interfering with each other. With this option, one can make an exception to the rule and permit early media coming later to override the previously established early dialog. It works safely as long as there is no parallel early media and 181 indicates that a later early media stream legitimately replaces the previous stream.
The following SIP flow-chart from Section 2.9 of RFC 5359 show a situation in which a SIP proxy generates a 181
The action Fork allows to add a new branch to a processed request and start forking. Multiple occurences of the action result in multiple branches of the request. The action takes only one parameter, the request URI of the forked request. The parameter can use replacement expressions, however if an invalid SIP URI is formed the call will fail.
Figure 5: Forking
5.7.6. Call transfers¶
Using the action Call transfer handling it can be configured how in-dialog REFER requests are handled in the ABC SBC. The configuration is per call leg, i.e. if used in inbound (A) rules REFER handling is set for the A leg, if used in outbound (C) rules it is set for the B leg.
Following methods of REFER handling can be used:
Pass REFER through the ABC SBC to the remote peer (default).
Reject the REFER request with a reply.
In case of an attended call transfer to another call established through the ABC SBC (REFER with in pointing to a local call) the call legs are connected locally. Only offer-answer exchanges (re-INVITEs) that synchronize session description on both ends are generated.
In case of an unattended call transfer (no in ) the ABC SBC generates a new INVITE to the requested destination. This INVITE can be handled in routing (B) rules and outbound (C) rules similarly to regular calls. For detection of such locally generated calls the condition Request source can be used.
In case of an attended call transfer to a non-local call ( in refers to a non-existent call leg) the ABC SBC generates a new INVITE with to the requested destination. This INVITE can be handled the same way as an INVITE generated for an unattended call transfer mentioned above.
- only in-dialog REFER requests are handled
- attended call transfer is not possible with transparent call IDs
5.7.7. INVITE with Replaces handling¶
ABC SBC is able to handle INVITE with Replaces header locally, if the Replaces header points to a call established on the SBC.
The action Handle INVITE with Replaces header is used for this purpose - it activates local INVITE with Replaces handling.
- INVITE with Replaces can not be handled when replacing call with transparent call IDs
5.7.8. Mapping Dialog-IDs in INVITEs with Replaces¶
If an INVITE with Replaces passes the ABC SBC, and the call to be replaced is also traversing the SBC, with transparent call IDs not enabled the Dialog Identifiers in the Replaces header refer to the call leg on the side before the SBC, but do not have a meaning after the SBC.
Using the Map Replaces header action, the dialog identifiers are replaced with the corresponding ones on the other side of the SBC so that the Replaces still is valid.
Independent Submission M. Munakata Request for Comments: 5379 S. Schubert Category: Informational T. Ohba ISSN: 2070-1721 NTT February 2010 Guidelines for Using the Privacy Mechanism for SIP Abstract This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values). Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5379. Copyright Notice Copyright (c) 2010 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. Munakata Informational [Page 1]
RFC 5379 SIP Privacy Guidelines February 2010 Table of Contents 1. Introduction ....................................................32. Terminology .....................................................33. Semantics of Existing priv-values ...............................44. Target for Each priv-value ......................................54.1. Target SIP Headers for Each priv-value .....................54.2. Target SDP Parameters for Each priv-value ..................6 4.3. Treatment of priv-value Not Supported by the Privacy Service ............................................75. Recommended Treatment of User-Privacy-Sensitive Information .....75.1. Target SIP Headers .........................................75.1.1. Call-ID .............................................75.1.2. Call-Info ...........................................85.1.3. Contact .............................................85.1.4. From ................................................95.1.5. History-Info .......................................105.1.6. In-Reply-To ........................................105.1.7. Organization .......................................115.1.8. P-Asserted-Identity ................................115.1.9. Record-Route .......................................125.1.10. Referred-By .......................................135.1.11. Reply-To ..........................................145.1.12. Server ............................................145.1.13. Subject ...........................................155.1.14. User-Agent ........................................155.1.15. Via ...............................................155.1.16. Warning ...........................................165.2. Target SDP Parameters .....................................165.2.1. c/m Lines ..........................................165.2.2. o Line .............................................175.2.3. i/u/e/p Lines ......................................175.3. Considerations for Non-Target SIP Headers/Parameters ......175.3.1. Identity/Identity-Info .............................175.3.2. Path ...............................................185.3.3. Replaces Header/Parameter ..........................185.3.4. Route ..............................................215.3.5. Service-Route ......................................215.3.6. Target-Dialog ......................................216. Security Considerations ........................................217. Acknowledgements ...............................................228. References .....................................................228.1. Normative References ......................................228.2. Informative References ....................................22Munakata Informational [Page 2]
RFC 5379 SIP Privacy Guidelines February 20101. Introduction This document clarifies the privacy mechanism for the Session Initiation Protocol (SIP) [RFC3261] defined in [RFC3323], which was later extended in [RFC3325] and [RFC4244]. This document describes the practical manner of operations of the privacy mechanism as a guideline and does not change the existing privacy mechanism. In RFC 3323, the semantics of the basic set of priv-values (header, session, user, none, and critical) is defined, but there are some ambiguities in regards to the target information to be obscured per priv-value, which are not explicitly specified. An ambiguity such as this could result in different interpretations of privacy handling for each of the priv-values defined, both at an entity setting a Privacy header and at an entity processing a Privacy header, which could have an adverse impact on interoperability. Additional priv-values "id" and "history" are defined in RFCs 3325 and 4244, respectively. In RFC 4244, the priv-value "history" is defined in order to request privacy for History-Info headers, and the target to be obscured for "history" priv-value is specified as only the History-Info headers. In addition, the RFC clearly describes that History-Info headers are also the target when "header"- and "session"-level privacy are requested. On the other hand, RFC 3325 defines the P-Asserted-Identity header and a priv-value "id", which is used to request privacy for only the P-Asserted-Identity header, but it does not specify how other priv- values may impact the privacy handling of the P-Asserted-Identity header. Because of this lack of specification, it has been observed that some implementations are suffering from the inability to achieve the intended privacy due to discrepancies in interpretations. This document tries to clarify the SIP headers and SDP parameters to be obscured for each of the priv-values to alleviate the potential interoperability issues already seen due to a lack of explicit text. 2. Terminology 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]. Munakata Informational [Page 3]
RFC 5379 SIP Privacy Guidelines February 2010 Note: This document is informational; therefore, it does not specify any new normative behaviors of privacy mechanism. All the RFC2119 language in this document is derived from the normative text in the existing RFCs, such as RFC 3323. priv-value: Values registered with IANA to be used in the Privacy header. Registered priv-values are "header", "session", "user", "none", and "critical" defined in [RFC3323]; "id" defined in [RFC3325]; and "history" defined in [RFC4244]. privacy service: A network entity that executes privacy functions before forwarding messages to the next hop. It is sometimes abbreviated to PS in this document. user-level privacy: Privacy for user-inserted information that can be anonymized by the user agent itself. 3. Semantics of Existing priv-values This section provides the semantics of each priv-value defined in RFCs 3323, 3325, and 4244. The descriptions are taken from the IANA registration. Privacy Type Description Reference ------------- ---------------------------------- ---------- user Request that privacy services [RFC3323] provide a user-level privacy function header Request that privacy services modify [RFC3323] headers that cannot be set arbitrarily by the user (Contact/Via). session Request that privacy services provide [RFC3323] privacy for session media none Privacy services must not perform any [RFC3323] privacy function critical Privacy service must perform the [RFC3323] specified services or fail the request id Privacy requested for Third-Party [RFC3325] Asserted Identity Munakata Informational [Page 4]
RFC 5379 SIP Privacy Guidelines February 2010 history Privacy requested for [RFC4244] History-Info header(s) 4. Target for Each priv-value Tables in this section show the recommended treatment of SIP headers and SDP parameters per priv-value. SIP headers and SDP parameters not shown in the tables are regarded as non-targets of these priv- values. Some non-target SIP headers/SDP parameters may carry privacy-sensitive information that may need privacy treatment regardless of the privacy level requested. This is further described in 5.3. The way in which SIP headers and SDP parameters listed here are obscured may depend on the implementation and network policy. This document does not prevent different variations that may exist based on local policy but tries to provide recommendations for how a privacy service treats SIP headers and SDP parameters. Note: The scope of these tables is SIP headers and related parameters specified in RFCs. 4.1. Target SIP Headers for Each priv-value Table 1 below shows a recommended treatment of each SIP header for each priv-value. Detailed descriptions of the recommended treatment per SIP header are covered in Section 5. The "where" column describes the request and response types in which the header needs the treatment to maintain privacy. Values in this column are: R: The header needs the treatment when it appears in a request. r: The header needs the treatment when it appears in a response. The next five columns show the recommended treatment for each priv- value: delete: The header is recommended to be deleted at a privacy service. not add: The header is recommended not to be added at a privacy service. anonymize: The header is recommended to be anonymized at a privacy service. How to anonymize the header depends on the header. Details are given in Section 5. Munakata Informational [Page 5]
RFC 5379 SIP Privacy Guidelines February 2010 anonymize*: An asterisk indicates that the involvement of a privacy service and treatment of the relevant header depend on the circumstance. Details are given in Section 5. Target headers where user header session id history -------------------------------------------------------------------- Call-ID (Note) R anonymize - - - - Call-Info Rr delete not add - - - Contact R - anonymize - - - From R anonymize - - - - History-Info Rr - delete delete - delete In-Reply-To R delete - - - - Organization Rr delete not add - - - P-Asserted-Identity Rr - delete - delete - Record-Route Rr - anonymize - - - Referred-By R anonymize* - - - - Reply-To Rr delete - - - - Server r delete not add - - - Subject R delete - - - - User-Agent R delete - - - - Via R - anonymize - - - Warning r anonymize - - - - Table 1: Recommended PS behavior for each SIP header Note: Any time a privacy service modifies a Call-ID, it MUST retain the former and modified values as indicated in Section 5.3 in RFC 3323. It MUST then restore the former value in a Call-ID header and other corresponding headers and parameters (such as In-Reply-To, Replaces, and Target-Dialog) in any messages that are sent using the modified Call-ID to the originating user agent. It should also modify a Call-ID header and other corresponding headers/parameters (such as Target-Dialog and "replaces" parameter) in any further relevant messages that are sent by the originating user agent. Refer to Section 5.1.1 (Call-ID) for the detailed behavior. Identity/Identity-Info, Path, Replaces, Route, Service-Route, and Target-Dialog headers are not targets of these priv-values (and should not be anonymized or modified by a privacy service based on a priv-value in a Privacy header). Refer to Section 5.3 for details. 4.2. Target SDP Parameters for Each priv-value The recommended PS behaviors for each SDP parameters are simple. The c, m, o, i, u, e, and p lines in SIP request/response are recommended to be anonymized when user privacy is requested with Privacy:session. Munakata Informational [Page 6]
RFC 5379 SIP Privacy Guidelines February 20104.3. Treatment of priv-value Not Supported by the Privacy Service As specified in RFC 3323, if the priv-value of "critical" is present in the Privacy header of a request, and if the privacy service is incapable of performing all of the levels of privacy specified in the Privacy header, it MUST fail the request with a 500 (Server Error) response code as indicated in Section 5 in RFC 3323. Since the protection of privacy is important, even if the priv-value "critical" is not present in the Privacy header, the privacy service should fail the request with a 500 response code when it is incapable of performing all of the levels of privacy specified in the Privacy header. 5. Recommended Treatment of User-Privacy-Sensitive Information The following SIP headers and related parameters may concern privacy. This section describes what kind of user-privacy-sensitive information may be included in each SIP header/parameter, and how to maintain privacy for such information at a user agent or a privacy service when the information is indeed privacy-sensitive. 5.1. Target SIP Headers This section describes privacy considerations and recommended treatment for each SIP header that may reveal user-privacy-sensitive information. This section goes into details about how each header affects privacy, the desired treatment of the value by the user agent and privacy service, and other instructions/additional notes necessary to provide privacy. 5.1.1. Call-ID This field frequently contains an IP address or hostname of a UAC (User Agent Client) appended to the Call-ID value. A user agent executing a user-level privacy function on its own SHOULD substitute for the IP address or hostname that is frequently appended to the Call-ID value a suitably long random value (the value used as the 'tag' for the From header of the request might even be reused) as indicated in Section 4.1 in RFC 3323. A privacy service MAY anonymize the Call-ID header when the request contains Privacy:user by substituting for the IP address or hostname in the Call-ID a suitably long random value (such as a From tag value) so that it is sufficiently unique as indicated in Section 5.3 in RFC 3323. Munakata Informational [Page 7]
RFC 5379 SIP Privacy Guidelines February 2010 Call-ID is essential to dialog matching, so any time a privacy service modifies this field, it MUST retain the former value and restore it in a Call-ID header in any messages that are sent to/by the originating user agent inside the dialog as indicated in Section5.3 in RFC 3323. A privacy service should be prepared to receive a request outside the dialog containing the value of the Call-ID set by the PS in other SIP headers (e.g., In-Reply-To/Replaces/ Target-Dialog), at least while the dialog state is active for the dialog whose Call-ID was modified by that PS. When such a request is received, the Call-ID value contained in the relevant headers indicated above should be replaced by the retained value. Note: This is possible only if the privacy service maintains the state and retains all the information it modified to provide privacy. Some PSs are known to encrypt information prior to obfuscation in the Via header, etc. In this case, the PS cannot correlate the modified Call-ID value with the original Call-ID. Further challenges are imposed when the PS needs to stay on a signaling path to ensure that it receives all the messages targeted towards the caller for which a PS provides privacy, especially when the request is out-of-dialog. Refer to the corresponding sections, 5.1.6 (In-Reply-To), 5.3.3 (Replaces Header/Parameter), and 5.3.6 (Target-Dialog), for detailed discussion. 5.1.2. Call-Info This field contains additional information about the user. A user agent executing a user-level privacy function on its own SHOULD NOT add a Call-Info header as indicated in Section 4.1 in RFC3323. A privacy service MUST delete a Call-Info header if one exists when user privacy is requested with Privacy:user as indicated in Section5.3 in RFC 3323. A privacy service SHOULD NOT add a Call-Info header when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323. 5.1.3. Contact This field contains a URI used to reach the user agent for mid-dialog requests and possibly out-of-dialog requests, such as REFER [RFC3315]. Since the Contact header is essential for routing further requests to the user agent, it must include a functional URI even when it is anonymized. Munakata Informational [Page 8]
RFC 5379 SIP Privacy Guidelines February 2010 A user agent MUST NOT anonymize a Contact header, unless it can obtain an IP address or contact address that is functional yet has a characteristic of anonymity as indicated in Section 184.108.40.206 in RFC3323. Since RFC 3323 was published, there have been proposals that allow UAs to obtain an IP address or contact address with a characteristic of anonymity. The mechanisms that are discussed at the time of this writing are Globally Routable User Agent URIs (GRUU) [SIPGRUU], which provides a functional Contact address with a short life span, making it ideal for privacy sensitive calls, and Traversal Using Relays around NAT (TURN) [TURN], through which an IP address of a relay can be obtained for use in a Contact header. A privacy service SHOULD anonymize a Contact header by replacing the existing Contact header field value with the URI that dereferences to the privacy service when user privacy is requested with Privacy:header, as indicated in Section 5.1 in RFC 3323. This is generally done by replacing the IP address or hostname with that of the privacy service. 5.1.4. From This field contains the identity of the user, such as display-name and URI. A user agent executing a user-level privacy function on its own SHOULD anonymize a From header using an anonymous display-name and an anonymous URI as indicated in Section 4.1 in RFC 3323. A privacy service should anonymize a From header when user privacy is requested with Privacy:user. Note: This does not prevent a privacy service from anonymizing the From header based on local policy. The anonymous display-name and anonymous URI mentioned in this section use display-name "Anonymous", a URI with "anonymous" in the user portion of the From header, and the hostname value "anonymous.invalid" as indicated in Section 220.127.116.11 in RFC 3323. The recommended form of the From header for anonymity is: From: "Anonymous" <sip:firstname.lastname@example.org>;tag=1928301774 Munakata Informational [Page 9]
RFC 5379 SIP Privacy Guidelines February 2010 The tag value varies from dialog to dialog, but the rest of this header form is recommended as shown. 5.1.5. History-Info History-Info [RFC4244] header URIs to which the request was forwarded or retargeted can reveal general routing information. A user agent executing a user-level privacy function on its own SHOULD NOT add a History-Info header as indicated in Section 3.3 in RFC 4244. A privacy service SHOULD delete the History-Info headers when user privacy is requested with Privacy:header, Privacy:session, or Privacy:history as indicated in Section 3.3 in RFC 4244. The privacy could be also expressed for a specific History-Info entry by inserting "privacy=history" in the History-Info header. In such a case, a privacy service SHOULD delete the History-Info entry as indicated in Section 18.104.22.168.1 in RFC 4244. Refer to [RFC4244] for detailed behavior for dealing with History- Info headers. 5.1.6. In-Reply-To The In-Reply-To header contains a Call-ID of the referenced dialog. The replying user may be identified by the Call-ID in an In-Reply-To header. Alice > INV(Call-ID:C1) > Bob Bob > INV(In-Reply-To:C1) > Alice In this case, unless the In-Reply-To header is deleted, Alice might notice that the replying user is Bob because Alice's UA knows that the Call-ID relates to Bob. A user agent executing a user-level privacy function on its own should not add an In-Reply-To header as implied in Section 4.1 in RFC3323. A privacy service MUST delete the In-Reply-To header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323. In addition, since an In-Reply-To header contains the Call-ID of the dialog to which it is replying, special attention is required, as described in Section 5.1.1 (Call-ID), regardless of the priv-value or Munakata Informational [Page 10]
RFC 5379 SIP Privacy Guidelines February 2010 presence of a Privacy header. Once a privacy service modifies a Call-ID in the request, a privacy service should restore the former value in an In-Reply-To header, if present in the INVITE request replying to the original request, as long as the privacy service maintains the dialog state. Example: Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob Bob > INV(In-Reply-To:C2, Privacy:none) > PS > INV(In-Reply-To:C1) > Alice Note: This is possible only if the privacy service maintains the state and retains all the information that it modified to provide privacy even after the dialog has been terminated, which is unlikely. Call-back is difficult to achieve when a privacy service is involved in forming the dialog to be referenced. 5.1.7. Organization This field contains additional information about the user. A user agent executing a user-level privacy function on its own should not add an Organization header as implied in Section 4.1 in RFC 3323. A privacy service MUST delete the Organization header if one exists when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323. A privacy service SHOULD NOT add an Organization header when user privacy is requested with Privacy: header as indicated in Section 5.1 in RFC 3323. 5.1.8. P-Asserted-Identity This header contains a network-verified and network-asserted identity of the user sending a SIP message. A privacy service MUST delete the P-Asserted-Identity headers when user privacy is requested with Privacy:id as indicated in Section 7 in RFC 3325 and should delete the P-Asserted-Identity headers when user privacy is requested with Privacy:header before it forwards the message to an entity that is not trusted. It is recommended for a privacy service to remove the P-Asserted- Identity header if user privacy is requested with Privacy:id or Privacy:header even when forwarding to a trusted entity, unless it can be confident that the message will not be routed to an untrusted entity without going through another privacy service. Munakata Informational [Page 11]
RFC 5379 SIP Privacy Guidelines February 20105.1.9. Record-Route This field may reveal information about the administrative domain of the user. In order to hide Record-Route headers while keeping routability to the sender, privacy services can execute a practice referred to as "stripping". Stripping means removing all the Record-Route headers that have been added to the request prior to its arrival at the privacy service and then adding a single Record-Route header representing itself. In this case, the privacy service needs to retain the removed headers and restore them in a response. Alternatively, privacy services can remove the Record-Route headers and encrypt them into a single Record-Route header field. In this case, the privacy service needs to decrypt the header and restore the former values in a response. A privacy service SHOULD strip or encrypt any Record-Route headers that have been added to a message before it reaches the privacy service when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323. As in the case of a Call-ID, if a privacy service modifies the Record-Route headers, it MUST be able to restore Route headers with retained values as indicated in Section 5.1 in RFC 3323. Some examples where the restoration of the Route headers is necessary and unnecessary are given below. When a UAC (Alice) requires privacy for a request, a privacy service does not have to restore the Route headers in the subsequent request (see Example 1). On the other hand, when a UAS (User Agent Server) (Bob) requires privacy for a response, a privacy service has to restore the Route headers in the subsequent request (see Example 2). Example 1: Restoration of Route header is UNNECESSARY when UAC requires privacy Alice > INV(Privacy:header) > P1 > INV(Record-Route:P1, Privacy:header) > PS > INV(Record-Route:PS) > P2 > INV(Record-Route:P2,PS) > Bob Bob > 200(Record-Route:P2,PS) > P2 > PS > 200(Record-Route:P2,PS,P1) > P1 > Alice Alice > re-INV(Route:P2,PS,P1, Privacy:header) > P1 > re-INV(Route:P2,PS, Privacy:header) > PS > re-INV(Route:P2) > P2 > re-INV > Bob Munakata Informational [Page 12]
RFC 5379 SIP Privacy Guidelines February 2010 Alice P1 PS P2 Bob | | | | | | INV Priv |INV Priv RR:P1 | INV RR:PS | INV RR:P2,PS | |---------------->|---------------->|---------------->|-------------->| | | | | | | 200 RR:P2,PS,P1 | 200 RR:P2,PS,P1 | 200 RR:P2,PS | 200 RR:P2,PS | |<----------------|<----------------|<----------------|<--------------| | | | | | | INV R:P2,PS,P1 | INV R:P2,PS | INV R:P2 | INV | |---------------->|---------------->|---------------->|-------------->| | | | | | Figure 1: Example when restoration of Route header is UNNECESSARY Example 2: Restoration of Route header is NECESSARY when UAS requires privacy Alice > INV > P1 > INV(Record-Route:P1) > P2 > INV(Record-Route:P2,P1) > Bob Bob > 200(Record-Route:P2,P1, Privacy:header) > P2 > PS' > 200(Record-Route:PS',P1) > P1 > Alice Alice > re-INV(Route:PS',P1) > P1 > re-INV(Route:PS') > PS' > re-INV(Route:P2) > P2 > Bob Alice P1 PS' P2 Bob | | | | | | INV |INV RR:P1 | | INV RR:P2,P1 | |-------------->|---------------------------------->|---------------->| | | | | | | 200 RR:PS',P1 | 200 RR:PS',P1 |200 Priv RR:P2,P1|200 Priv RR:P2,P1| |<--------------|<----------------|<----------------|<----------------| | | | | | | INV R:PS',P1 | INV R:PS' | INV R:P2 | INV | |-------------->|---------------->|---------------->|---------------->| | | | (Restored) | | Figure 2: Example when restoration of Route header is NECESSARY Note: In Figures 1 and 2, Priv means Privacy:header, RR means Record- Route header, and R means Route header. 5.1.10. Referred-By The Referred-By [RFC3892] header carries a SIP URI representing the identity of the referrer. The Referred-By header is an anonymization target when the REFER request with the Referred-By header is sent by the user (referrer) whose privacy is requested to be processed in the privacy service. Munakata Informational [Page 13]
RFC 5379 SIP Privacy Guidelines February 2010 A user agent that constructs REFER requests executing a user-level privacy function on its own should anonymize a Referred-By header by using an anonymous URI. A privacy service should anonymize a Referred-By header in a REFER request by using an anonymous URI when user privacy is requested with Privacy:user. On the other hand, the Referred-By header is not an anonymization target when it appears in a request other than REFER (e.g., INVITE) because the URI in the Referred-By header does not represent the sender of the request. Example 1: Referrer requests no privacy and referee requests privacy Alice > REF(Referred-By:Alice) > Bob Bob > INV(Referred-By:Alice, Privacy:user) > PS > INV(Referred-By:Alice) > Carol Example 2: Referrer requests privacy and referee requests privacy Alice > REF(Referred-By:Alice, Privacy:user) > PS > REF(Referred-By:X) > Bob Bob > INV(Referred-By:X, Privacy:user) > PS > INV(Referred-By:X) > Carol 5.1.11. Reply-To This field contains a URI that can be used to reach the user on subsequent call-backs. A user agent executing a user-level privacy function on its own should not add a Reply-To header in the message as implied in Section4.1 in RFC 3323. A privacy service MUST delete a Reply-To header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323. 5.1.12. Server This field contains information about the software used by the UAS to handle the request. A user agent executing a user-level privacy function on its own should not add a Server header in the response as implied in Section4.1 in RFC 3323. Munakata Informational [Page 14]
RFC 5379 SIP Privacy Guidelines February 2010 A privacy service must delete a Server header in a response when user privacy is requested with Privacy:user. A privacy service SHOULD NOT add a Server header in a response when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323. 5.1.13. Subject This field contains free-form text about the subject of the call. It may include text describing something about the user. A user agent executing a user-level privacy function on its own should not include any information identifying the caller in a Subject header. A privacy service MUST delete a Subject header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323. 5.1.14. User-Agent This field contains the UAC's information. A user agent executing a user-level privacy function on its own should not add a User-Agent header as implied in Section 4.1 in RFC3323. A privacy service MUST delete a User-Agent header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC3323. 5.1.15. Via The bottommost Via header added by a user agent contains the IP address and port or hostname that are used to reach the user agent for responses. Via headers added by proxies may reveal information about the administrative domain of the user. A user agent MUST NOT anonymize a Via header as indicated in Section22.214.171.124 in RFC 3323, unless it can obtain an IP address that is functional yet has a characteristic of anonymity. This may be possible by obtaining an IP address specifically for this purpose either from the service provider or through features such as TURN. A privacy service SHOULD strip or encrypt any Via headers that have been added prior to reaching the privacy service when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC3323. Refer to Section 5.1.9 (Record-Route) for details of stripping and encryption. Munakata Informational [Page 15]
RFC 5379 SIP Privacy Guidelines February 2010 A privacy service MUST restore the original values of Via headers when handling a response in order to route the response to the originator as indicated in Section 5.1 in RFC 3323. No Via stripping is required when handling responses. 5.1.16. Warning This field may contain the hostname of the UAS. A user agent executing a user-level privacy function on its own should not include the hostname representing its identity in a Warning header. A privacy service should anonymize a Warning header by deleting the hostname portion (if it represents a UAS's identity) from the header when user privacy is requested with Privacy:user. 5.2. Target SDP Parameters This section describes privacy considerations for each SDP [RFC4566] parameter that may reveal information about the user. When privacy functions for user-inserted information are requested to be executed at a privacy service, user agents MUST NOT encrypt SDP bodies in messages as indicated in Section 4.2 in RFC 3323. 5.2.1. c/m Lines The c and m lines in the SDP body convey the IP address and port for receiving media. A user agent must not anonymize the IP address and port in the c and m lines, unless it can obtain an IP address that is functional yet has a characteristic of anonymity as implied in Section 126.96.36.199 in RFC 3323. This may be possible by obtaining an IP address specifically for this purpose either from the service provider or through features such as TURN. A privacy service must anonymize the IP address and port in c and m lines using a functional anonymous IP address and port when user privacy is requested with Privacy:session. This is generally done by replacing the IP address and port present in the SDP with that of a relay server. Munakata Informational [Page 16]
RFC 5379 SIP Privacy Guidelines February 20105.2.2. o Line The username and IP address in this parameter may reveal information about the user. A user agent may anonymize the username in an o line by setting username to "-" and anonymize the IP address in the o line by replacing it with a value so that it is sufficiently unique. A privacy service must anonymize the username and IP address in the o line by setting the username to "-" and replacing the IP address with a value so that it is sufficiently unique when user privacy is requested with Privacy:session. 5.2.3. i/u/e/p Lines These lines may contain information about the user. A user agent executing a session-level privacy function on its own should not include user's information in the i, u, e, and p lines. A privacy service should modify the i, u, e, and p lines to delete the user's identity information when user privacy is requested with Privacy:session. 5.3. Considerations for Non-Target SIP Headers/Parameters5.3.1. Identity/Identity-Info The Identity [RFC4474] header field contains a signature used for validating the identity. The Identity-Info header field contains a reference to the certificate of the signer of Identity headers. An Identity-Info header may reveal information about the administrative domain of the user. The signature in an Identity header provides integrity protection over the From, To, Call-ID, Cseq, Date, and Contact headers and over the message body. The integrity protection is violated if a privacy service modifies these headers and/or the message body for the purpose of user privacy protection. Once those integrity-protected headers (such as From and Call-ID) are modified, the Identity/Identity-Info header fields are not valid any more. Thus, a privacy service acting on a request for Privacy:user, Privacy:header, or Privacy:session can invalidate integrity protection provided by an upstream authentication service that has inserted Identity/Identity-Info header fields. The use of such a privacy service should be avoided if integrity protect needs to be Munakata Informational [Page 17]
RFC 5379 SIP Privacy Guidelines February 2010 retained. Otherwise, if the privacy service invalidates the integrity protection, it should remove the Identity/Identity-Info header fields. An authentication service downstream of the privacy service may add Identity/Identity-Info header fields if the domain name of the From header field URI has not been anonymized (e.g., 'sip:email@example.com'), which makes it possible for the service to authenticate the UAC. This authenticated yet anonymous From header means "this is a known user in my domain that I have authenticated, but I am keeping its identity private" as indicated in Section 12 in RFC 4474. The desired deployment will have a privacy service located before or co-located with the identity service; thus, integrity and privacy can both be provided seamlessly. 5.3.2. Path This field may contain information about the administrative domain and/or the visited domain of the user agent. However, the Path header is not the target of any priv-values. Given that the Path header [RFC3327] only appears in REGISTER requests/responses and is essential for a call to reach the registered UA in the visited domain, it serves no purpose to withhold or hide the information contained in the Path header; rather, it is harmful. The only reason privacy may be considered desirable is if the visited domain wants to withhold its topology from the home domain of the user. In doing so, the domain withholding the topology needs to ensure that it provides sufficient information so that the home domain can route the call to the visited domain, thus reaching the UA. However, anonymization of network-privacy-sensitive information is out of scope. 5.3.3. Replaces Header/Parameter The Replaces [RFC3891] header and the "replaces" parameter contain identifiers of a dialog to be replaced, which are composed of Call- ID, local tag, and remote tag. Munakata Informational [Page 18]
RFC 5379 SIP Privacy Guidelines February 2010 The sender of the INVITE with a Replaces header is usually not the originating user agent or terminating user agent of the target dialog to be replaced. Therefore, the Call-ID within the Replaces header is unlikely to be generated by the sender, and thus this header is outside the anonymization target per priv-value. The "replaces" parameter, which appears in a Refer-To header in a REFER request, is not the target of any particular priv-values either. As described in Section 5.1.1 (Call-ID), regardless of the priv-value or the presence of a Privacy header, once a privacy service modifies a Call-ID in the request, it should monitor headers that may contain Call-ID and restore the portion of the value representing the modified Call-ID to the original Call-ID value in a Replaces header received. The main challenge for this to function properly is that a privacy service has to be on a signaling path to the originator for every dialog. This is generally not possible and results in REFER requests not functioning at all times. This is a trade-off that is anticipated when privacy is imposed. The privacy requirements mentioned in Section 5.1.1 will cause the Replaces header and "replaces" parameter to contain values that will fail the resulting dialog establishment in some situations. This loss of functionality is allowed and/or intended as illustrated above (i.e., it is not the responsibility of a privacy service to ensure that these features always work). The functionality of the Replaces header/parameter when anonymized depends on the circumstances in which it is used. REFER may work or may not work depending on the following three criteria. 1. Who generated the Call-ID. 2. Where the privacy service is on the signaling path. 3. Who initiates the REFER with the "replaces" parameter. A few examples that explore when the Replaces header/parameter works or fails are given below. Example 1: Transfer initiated by the originator, PS added for first INV and REF Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS > REF(Refer-To:Bob?Replaces=C2) > Carol Carol > INV(Replaces:C2) > Bob (SUCCEED) Munakata Informational [Page 19]
RFC 5379 SIP Privacy Guidelines February 2010 Example 2: Transfer initiated by the originator, PS added only for first INV Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob Alice > REF(Refer-To:Bob?Replaces=C1) > Carol Carol > INV(Replaces:C1) > Bob (FAIL) Note: Example 2 would succeed if the same PS (that modifies the Call- ID in the INVITE from Alice) is also added for REFER and modifies the value in the "replaces" parameter from C1 to C2 even if there is no Privacy header in the REFER. Example 3: Transfer initiated by the originator, PS added only for REF Alice > INV(Call-ID:C1) > INV(Call-ID:C1) > Bob Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS > REF(Refer-To:Bob?Replaces=C1) > Carol Carol > INV(Replaces:C1, Privacy:user) > PS' > INV(Replaces:C1) > Bob (SUCCEED) Example 4: Transfer initiated by the terminating party, PS added for both INV Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob Bob > REF(Refer-To:Alice?Replaces=C2) > Carol Carol > INV(Replaces:C2) > PS > INV(Replaces:C1) > Alice (SUCCEED) Note: Example 4 succeeds because the same PS (that modifies the Call- ID in the INVITE from Alice) checks the incoming requests and modifies the value in a Replaces header in the INVITE from Carol to the former value of Call-ID (C1). Example 5: Hold, PS added only for first INV Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob Alice > REF(Refer-To:Bob?Replaces=C1) > Music-Server Music-Server > INV(Replaces:C1) > Bob (FAIL) Note: Example 5 would succeed if the same PS (that modifies the Call- ID in the INVITE from Alice) is added for the INVITE from the Music-Server and modifies the value in a Replaces header from C1 to C2. As the above examples show, in some scenarios, information carried in the Replaces header/parameter would result in failure of the REFER. This will not happen if the Call-ID is not modified at a privacy service. Munakata Informational [Page 20]
RFC 5379 SIP Privacy Guidelines February 20105.3.4. Route This field may contain information about the administrative domain of the user agent, but the Route header is not the target of any priv- values. Route headers appear only in SIP requests to force routing through the listed set of proxies. If a privacy service anonymizes the Route header, the routing does not function. Furthermore, there is no risk in revealing the information in the Route headers to further network entities, including the terminating user agent, because a proxy removes the value from the Route header when it replaces the value in the Request-URI as defined in RFC 3261. A privacy service that modifies Record-Route headers may need to restore the values in Route headers as necessary. As indicated in Section 5.1 in RFC 3323, if a privacy service modifies the Record- Route headers, it MUST be able to restore Route headers with retained values. Please refer to Section 5.1.9 (Record-Route) for further detail and examples. 5.3.5. Service-Route Service-Route headers [RFC3608] appear only in 200 OK responses to REGISTER requests and contain information about the registrar. The purpose of the privacy mechanism defined in RFC 3323 is to secure the user's privacy, so the case where a registrar sets a Privacy header is not considered here. Therefore, the Service-Route header is not the target of any priv-values. 5.3.6. Target-Dialog The Target-Dialog [RFC4538] header faces exactly the same issues as seen for the Replaces header. Please refer to Section 5.3.3 (Replaces Header/Parameter) for why this is not a target for any particular priv-values and how a privacy service still needs to evaluate and modify the value contained, even if no privacy is requested. 6. Security Considerations This guideline document adds no new security considerations to those discussed in [RFC3323], [RFC3325], and [RFC4244]. Munakata Informational [Page 21]
RFC 5379 SIP Privacy Guidelines February 20107. Acknowledgements The authors would like to thank John Elwell, Jon Peterson, Jonathan Rosenberg, Mary Barnes, Paul Kyzivat, and Roland Jesske for their reviews and comments. 8. References8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. 8.2. Informative References [TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, July 2008. [SIPGRUU] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009. [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. Munakata Informational [Page 22]
RFC 5379 SIP Privacy Guidelines February 2010 [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003. [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. Authors' Addresses Mayumi Munakata NTT Corporation Phone: +81 422 36 7502 EMail: firstname.lastname@example.org Shida Schubert NTT Corporation EMail: email@example.com Takumi Ohba NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 7748 EMail: firstname.lastname@example.org Munakata Informational [Page 23]
Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/