errata logo graphic

Found 9 records.

Status: Verified (6)

RFC6044, "Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", October 2010

Source of RFC: INDEPENDENT

Errata ID: 3071

Status: Verified
Type: Technical

Reported By: Marianne MOHALI
Date Reported: 2012-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-01-04

Section 5 says:

"unavailable"-----------------------------404

It should say:

"unavailable"-----------------------------503

Notes:

This correction is done to be consistent with the reverse mapping and the fact that "unavailable" reason is used for unreachability cases.


Errata ID: 2603

Status: Verified
Type: Editorial

Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-01-04

Section 7.1 says:

   INVITE last_diverting_target
   Diversion:
   diverting_user3_address;reason=unconditional;counter=1;privacy=off,
   diverting_user2_address;reason=user-busy;counter=1;privacy=full,
   diverting_user1_address;reason=no-answer;counter=1;privacy=off

It should say:

   INVITE last_diverting_target
   Diversion:
   <sip:diverting_user3_address>;reason=unconditional;counter=1;privacy=off,
   <sip:diverting_user2_address>;reason=user-busy;counter=1;privacy=full,
   <sip:diverting_user1_address>;reason=no-answer;counter=1;privacy=off

Notes:

The examples in section 7.1, 7.2, and 7.3 and also in 3.2 show the Diversion header field using an "address" that is not a SIP (or Tel) URI, and without the "<" ">" delimeters. That is not correct. It is confusing, because the History-Info examples show it correctly, and thus imply the two address formats are not the same and need to be interworked, whereas in fact they are both name-addr fields, and thus both need to have the "<" and ">", etc.


Errata ID: 2604

Status: Verified
Type: Editorial

Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-01-04

Section 7.1 says:

   History-Info:
   <sip: diverting_user1_address; privacy=none >; index=1,

It should say:

   History-Info:
   <sip:diverting_user1_address?Privacy=none>;index=1,

Notes:

The example does not show the "?" embedded URI header indicator for the Privacy header in the URI, but instead shows it as a URI parameter.


Errata ID: 2605

Status: Verified
Type: Editorial

Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-01-04

Section 3.1 says:

   History-Info:
   <sip: diverting_user1_addr?Privacy=none?Reason=SIP%3Bcause%
   3D302>;index=1,

It should say:

   History-Info:
   <sip: diverting_user1_addr?Privacy=none&Reason=SIP%3Bcause%
   3D302>;index=1,

Notes:

The example shows two embedded headers, but using two "?" tokens which is incorrect - there is only one "?" token, and all subsequent embedded headers need to use "&". (as per RFC 3261 ABNF rules)


Errata ID: 3077

Status: Verified
Type: Editorial

Reported By: Marianne Mohali
Date Reported: 2012-01-05
Verifier Name: Nevil Brownlee
Date Verified: 2012-04-11

Section 2.2.1 says:

|       |       |INVITE |       |       |       |     |       |        |
|       |       |------>|       |       |       |     |       |        |
|       |       |History-Info:  |       |       |     |       |        |
|       |       |<sip:proxyP1>; index=1,|       |     |       |        |
|       |       |<sip:userB>; index=1.1 |       |     |       |        |
|       |       |<sip:userC>; cause=302; index=1.1.1  |       |        |

It should say:

|       |       |INVITE |       |       |       |     |       |        |
|       |       |------>|       |       |       |     |       |        |
|       |       |History-Info:  |       |       |     |       |        |
|       |       |<sip:proxyP1>; index=1,|       |     |       |        |
|       |       |<sip:userB>; index=1.1,|       |     |       |        |
|       |       |<sip:userC; cause=302>; index=1.1.1  |       |        |

Notes:

The "cause" parameter is an URI parameter defined in RFC4458. So that, it is included in the SIP-URI which is represented by the name-addr parameter (between <>) of the History-Info header.
There was also a missing COMMA at the end of "index=1.1".


Errata ID: 3176

Status: Verified
Type: Editorial

Reported By: Brett Tate
Date Reported: 2012-04-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-04-11

Section 3.2 says:

Diversion:

diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
diverting_user1_addr; reason="unconditional"; counter=1; privacy=off

It should say:

Diversion:

<sip:diverting_user2_address>; reason=user-busy; counter=1; privacy=full,
<sip:diverting_user1_address>; reason=unconditional; counter=1; privacy=off

Notes:

Errata 2603 already reported that the example did not correctly contain name-addr values. This is to report that the selected reason values should not be within quotes since these values have been explicitly defined to be non quoted. More specifically, the quotes within the example add confusion since RFC 5806 examples had similar quoting issues for values defined without quotes.


Status: Rejected (3)

RFC6044, "Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", October 2010

Source of RFC: INDEPENDENT

Errata ID: 3564

Status: Rejected
Type: Technical

Reported By: Jayaraj Wilson
Date Reported: 2013-03-25
Rejected by: Nevil Brownlee
Date Rejected: 2014-02-12

Section 7.1 says:

Mapped into:
History-Info:
<sip: diverting_user1_address; privacy=none >; index=1,
<sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
<sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
<sip: last_diverting_target; cause=302>;index=1.1.1.1


It should say:

Mapped into:
History-Info:
<sip: diverting_user1_address; privacy=none >; index=1,
<sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
<sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
<sip: last_diverting_target; cause=302?privacy=none>;index=1.1.1.1

Notes:

Section 5 for Diversion to History Info mapping states
A last History-Info entry is created and contains:
- if a privacy parameter is present in the top-most Diversion entry,
then a Privacy header could be escaped in the History-Info header
as described above.

So if this is rule is applied then the last History Info entry must contain a privacy param corresponding to the top most Diversion and in this case it maps to none. On the other hand if this example is to be considered correct then we ought to modify section 5 to have no privacy for the last hi entry.
--VERIFIER NOTES--
In RFC 6044 section 7.1, the last History-Info line does not
correspond to the last diverting user (similar to the top-most
diversion entry), but to the last diversion TARGET. We don't have the
privacy of the last call forwarding destination - that's why there is
no privacy associated to this address.

The privacy info associated to diverting users 1, 2 and 3 are still
associated to these user addresses in the History-Info header.


Errata ID: 2606

Status: Rejected
Type: Editorial

Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Rejected by: Nevil Brownlee
Date Rejected: 2014-03-06

Section 2.2.1 says:

|       |       |INVITE |       |       |       |     |       |        |
|       |       |------>|       |       |       |     |       |        |
|       |       |History-Info:  |       |       |     |       |        |
|       |       |<sip:proxyP1>; index=1,|       |     |       |        |
|       |       |<sip:userB>; index=1.1 |       |     |       |        |
|       |       |<sip:userC>; cause=302; index=1.1.1  |       |        |

It should say:

|       |       |INVITE |       |       |       |     |       |        |
|       |       |------>|       |       |       |     |       |        |
|       |       |History-Info:  |       |       |     |       |        |
|       |       |<sip:proxyP1>; index=1,|       |     |       |        |
|       |       |<sip:userB>; index=1.1 |       |     |       |        |
|       |       |<sip:userC?Reason=SIP%3Bcause%3D302>;index=1.1.1      |

Notes:

The "cause" field is not a Hist-Info header param, it's a param of a Reason header embedded in the URI.
Furthermore, the example shows things like "userC", while obviously it has to be something like "userC@host.com" to be a valid SIP URI.
--VERIFIER NOTES--
See erratum 3077, which corrects this erratum (2606)


Errata ID: 2607

Status: Rejected
Type: Editorial

Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Rejected by: Nevil Brownlee
Date Rejected: 2014-03-06

Section 7 says:

   History-Info:
   <sip: diverting_user1_address; privacy=none >; index=1,
   <sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
   <sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
   <sip: last_diverting_target; cause=302>;index=1.1.1.1

7.2.  Example with History-Info Header Changed into Diversion Header

   History-Info:
   <sip: diverting_user1_address?privacy=history >; index=1,
   <sip: diverting_user2_address; cause=302? privacy=none>;index=1.1,
   <sip: last_diverting_target; cause=486>;index=1.1.1

It should say:

   History-Info:
   <sip:diverting_user1_address?Privacy=none>;index=1,
   <sip:diverting_user2_address?Reason=SIP%3Bcause%3D408?privacy=
      history>; index=1.1,
   <sip:diverting_user3_address?Reason=SIP%3Bcause%3D486?privacy=none>;
     index=1.1.1,
   <sip:last_diverting_target?Reason=SIP%3Bcause%3D302>;index=1.1.1.1

7.2.  Example with History-Info Header Changed into Diversion Header

   History-Info:
   <sip: diverting_user1_address?privacy=history >; index=1,
   <sip: diverting_user2_address?Reason=SIP%3Bcause%3D302&Privacy=none>;
     index=1.1,
   <sip: last_diverting_target?Reason=SIP%3Bcause%3D486>;index=1.1.1

Notes:

I know RFC 4244 makes this error all over the place, but the "cause" field is not a URI parameter. It is a header parameter of the Reason header field, and per the ABNF of RFC4244 Hist-Info, the Reason header is embedded into the URI, including its cause parameter - in other words, the cause field is a parameter of an embedded header inside a URI, as shown in the correction.

This error is made in section 2.2.1, 3.1, 5, 7.1, 7.2, and 7.3 of this RFC 6044.
--VERIFIER NOTES--
RFC author considers this erratum to be incorrect.


Report New Errata