Internet DRAFT - draft-cooke-sip-rfc3261bis
draft-cooke-sip-rfc3261bis
draft-cooke-sip-rfc3261bis-02
Internet-Draft R. Cooke
Intended status: Informational June 2, 2023
Expires: December 4, 2023
Note on Usage of Phone Number in the From Field of SIP
Messaging V
<draft-cooke-sip-rfc3261bis-02.txt>
Abstract
This document proposes adding a note to the current SIP messaging
standards to clarify the usage of the phone number within the From
field. The note advises against duplicating the phone number inside
the double quotation marks (" ") when it is already included within
the double angle brackets (<>). This recommendation aims to avoid the
display of unknown numbers caused by devices prioritizing SIP
signaling information over locally stored contact information.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
https://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html
Note on Copyright
Copyright (c) 2023 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
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction......................................................3
2. Terminology.......................................................3
3. The From Header Field.............................................4
4. Examples..........................................................4
5. Rationale.........................................................5
6. Compatibility and Impact..........................................5
7. Security Considerations...........................................6
8. References........................................................6
9. Author's Address.................................................10
1. Introduction
The From header field in Session Initiation Protocol (SIP) messaging
is used to indicate the initiator of a SIP request. It typically
includes a display name and a SIP or tel URI. The display name is
enclosed within double quotation marks (" ") and the URI is enclosed
within double angle brackets (<>).
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The From Header Field
Update to 8.1.1.3 From in RFC 3261.
The From header field indicates the logical identity of the initiator
of the request, potentially the user's address-of-record. It comprises
a URI and an optional display name. The From field is used by SIP
elements to determine the applicable processing rules for a request,
such as automatic call rejection. Therefore, it is crucial to avoid
including IP addresses or the fully qualified domain name (FQDN) of
the User Agent (UA) host in the From URI, as these are not logical
names.
The From header field permits the inclusion of a display name. It is
recommended that a User Agent Client (UAC) refrain from using the
user's phone number as the display name within the From field, as
this is not a logical name and it is already included. This practice
eliminates the possibility of duplication and potential confusion.
Instead, if the identity of the client is intended to remain hidden,
the UAC SHOULD use the display name "Anonymous" along with a
syntactically correct, but otherwise meaningless URI
(e.g., sip:thisis@anonymous.invalid).
Typically, the value in the From header field of requests generated by
a specific UA is pre-provisioned by the user or the administrators of
the user's local domain. In cases where a UA is utilized by multiple
users, it may support switchable profiles that incorporate a URI
corresponding to the profiled user's identity. Recipients of requests
can authenticate the originator by verifying that the information in
the From header field matches the claimed identity (see Section 22
for more details on authentication).
The From field MUST include a new "tag" parameter chosen by the UAC.
For detailed instructions on selecting a tag, refer to Section 19.3
(RFC 3261).
Additional information about the From header field can be found in
Section 20.20 (RFC 3261).
4.Examples:
From: "Bob" sips:bob@biloxi.com;tag=a48s
From: sip:+12125551212@phone2net.com;tag=887s
From: Anonymous sip:c8oqz84zk7z@privacy.org;tag=hyh8
Bad Example:
From: "5551234567" sip:5551234567@example.com;tag=12345
Explanation:
In this example, the From header field includes the user's phone
number within the display name. This practice can lead to confusion
and display issues on certain devices that prioritize SIP signaling
information over locally stored contact information. Consequently, the
recipient may perceive the call as originating from an unknown number,
even though the user's name is displayed. It is strongly discouraged
to include the phone number within the display name, as it undermines
meaningful caller identification and can create a negative user
experience. The From header field is defined in Section 8.1.1.3 of RFC
3261 [RFC3261]. It is used to indicate the initiator of a SIP request
and contains a display name and a SIP or tel URI.
The display name is typically used to convey the caller's name or a
recognizable identifier. It is enclosed within double quotation marks
(" "). The URI includes the SIP or tel scheme followed by the user's
address, enclosed within double angle brackets (<>) to indicate a URI.
In some cases, the display name includes the phone number in addition
to the caller's name. However, it is important to note that including
the phone number within the display name can lead to confusion and
display issues on certain devices that prioritize SIP signaling
information over locally stored contact information. Consequently, the
recipient may perceive the call as originating from an unknown number,
even though the user's name is displayed.
5. Rationale
Including the phone number within the display name of the From header
field is unnecessary and can lead to display issues on certain
devices. The display name is primarily used to convey the caller's
name or a recognizable identifier, while the URI contains the
necessary contact information.
By avoiding the duplication of the phone number within the display
name, we ensure that devices prioritize the locally stored contact
information and display the caller's name instead of an unknown
number.
6. Compatibility and Impact
This note on the usage of the From header field has no impact on the
interoperability between SIP implementations. It is intended to
provide clarification and best practices to improve the user
experience.
7. Security Considerations
This document does not introduce any new security considerations
beyond those already discussed in the SIP specifications [RFC3261].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo,
G., Johnston, A., Peterson, J., Sparks, R., Handley,
M., and E. Schooler, "SIP: Session Initiation Protocol"
, RFC 3261, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/rfc/rfc3261>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
9. Author's Address
Raymond Cooke
BT
Email: raymondcooke@hotmail.co.uk
