RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (4)

RFC 3325, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", November 2002

Note: This RFC has been updated by RFC 5876, RFC 8217

Source of RFC: sip (rai)

Errata ID: 3744
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Brett Tate
Date Reported: 2013-10-08
Verifier Name: Richard Barnes
Date Verified: 2014-02-15

Section 9.1 says:

A P-Asserted-Identity header field value MUST consist of exactly one
name-addr or addr-spec.

It should say:

A P-Asserted-Identity header field value MUST consist of exactly one
name-addr or addr-spec.  If the URI contains a comma, the URI MUST
be enclosed in angle brackets (< and >).

Notes:

While the P-Asserted-Identity and P-Preferred-Identity header fields have an ambiguity only for "," (not for ";" and "?"), we note that usage of ";" and "?" also must be enclosed in angle brackets to preserve consistency with the RFC 3261 section 20 bracket rule.

Errata ID: 3894
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Richard Barnes
Date Reported: 2014-02-15
Verifier Name: Richard Barnes
Date Verified: 2014-02-15

Section 9.2 says:

A P-Preferred-Identity header field value MUST consist of exactly one
name-addr or addr-spec.

It should say:

A P-Preferred-Identity header field value MUST consist of exactly one
name-addr or addr-spec.  If the URI contains a comma, the URI MUST
be enclosed in angle brackets (< and >).

Notes:

While the P-Asserted-Identity and P-Preferred-Identity header fields have an ambiguity only for "," (not for ";" and "?"), we note that usage of ";" and "?" also must be enclosed in angle brackets to preserve consistency with the RFC 3261 section 20 bracket rule.

Errata ID: 4202
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Giovanni Signoriello
Date Reported: 2014-12-17
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 10.2 says:

P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org>

It should say:

P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>

Notes:

May be an editorial error in the message F4, section 10.2.
In that message is added the P-Asserted-Identity with the SIP URI sip:fluffy@vovida.org
I suppose it should be cisco.com and not vovida.com.
Thank you.

Errata ID: 5499
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Richard Phernambucq
Date Reported: 2018-09-20
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 10 says:

   * F4   proxy.cisco.com -> proxy.pstn.net (trusted)

   INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
   Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
   Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc

It should say:

   * F4   proxy.cisco.com -> proxy.pstn.net (trusted)

   INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
   Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
   Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124

Notes:

As per RFC 3261, chapter 16.6, step 8:
The proxy MUST insert a Via header field value into the copy before the existing Via header field values.

The order of Via headers should be reversed. This applies to the following message examples:
chapter 10.1: F4, F5
chapter 10.2: F4, F5, F6

Text and examples in RFC3261 Section 20.42 supports the argument that the order is reversed.

Status: Reported (1)

RFC 3325, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", November 2002

Note: This RFC has been updated by RFC 5876, RFC 8217

Source of RFC: sip (rai)

Errata ID: 7794
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Christos Diamantis
Date Reported: 2024-02-02

Section 10.2 says:

The next proxy removes the P-Asserted-Identity 
header field and the request for Privacy before forwarding this 
request onward to the biloxi.com proxy server which it does not trust.

It should say:

The next proxy removes the P-Asserted-Identity 
header field but does not remove the request for Privacy before forwarding this 
request onward to the biloxi.com proxy server which it does not trust.

Notes:

As stated in ETSI TS 124 607 V17.0.0 (2022-04),
section 4.3.3 Requirements on the terminating network side:
NOTE 1: The priv-value "id" in the Privacy header is not expected be removed when removing any P-Asserted-Identity header as described in 3GPP TS 24.229 subclauses 4.4.2 (The priv-value "id" shall not be removed from the Privacy header field when SIP signalling crosses the boundary of the trust domain) and 5.4.3.3.
and also,
section 4.5.2.9 Actions at the AS serving the terminating UE:
The priv-value "id" in the Privacy header will be used by the terminating UE to distinguish the request of OIR by the originating user.

Report New Errata



Advanced Search