RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (1)

RFC 5589, "Session Initiation Protocol (SIP) Call Control - Transfer", June 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 3989
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Procter
Date Reported: 2014-05-15
Verifier Name: Francesca Palombini
Date Verified: 2023-11-09

Section 7.3 says: 

Target-Dialog: 592435881734450904;local-tag=9m2n3wq
 ;remote-tag=763231

It should say:

Target-Dialog: 090459243588173445;local-tag=7553452
 ;remote-tag=31431

Notes:

The ladder diagram states that F5 (REFER) should have Target-Dialog referencing dialog 1 and the embedded Replaces header should reference dialog 2. The complete F5 message references dialog 2 in both places, which is incorrect.

Status: Reported (1)

RFC 5589, "Session Initiation Protocol (SIP) Call Control - Transfer", June 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 8310
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Rousseau
Date Reported: 2025-02-24

Section 7.3 says: 

F5 REFER Transferor -> Transferee

   REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
   Max-Forwards: 70
   To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
   From: <sips:transferor@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 REFER
   Require: tdialog
   <allOneLine>
   Refer-To: <sips:482n4z24kdg@chicago.example.com;gr=8594958?
   Replaces=592435881734450904%3Bto-tag%3D9m2n3wq%3Bfrom-tag3D763231>
   </allOneLine>
   Target-Dialog: 592435881734450904;local-tag=9m2n3wq
    ;remote-tag=763231
   Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
   Content-Length: 0

It should say:

F5 REFER Transferor -> Transferee

   REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
   Max-Forwards: 70
   To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
   From: <sips:transferor@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 REFER
   Require: tdialog
   <allOneLine>
   Refer-To: <sips:482n4z24kdg@chicago.example.com;gr=8594958?
   Replaces=592435881734450904%3Bto-tag%3D9m2n3wq%3Bfrom-tag3D763231>
   </allOneLine>
   Target-Dialog: 090459243588173445;local-tag=7553452
    ;remote-tag=31431
   Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
   Content-Length: 0

Notes:

In 7.3. Attended Transfer, message F5 REFER Transferor -> Transferee has a Target-Dialog header that contains the dialog identifying information from the call to the Transfer Target when it should have the ones from the call from the Transferee.

Status: Held for Document Update (2)

RFC 5589, "Session Initiation Protocol (SIP) Call Control - Transfer", June 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 3273
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor S. Osipov
Date Reported: 2012-06-29
Held for Document Update by: Robert Sparks

Section 5 says: 

3. There were concerns with authorizing out-of-dialog REFERs. The
authorization policy for REFER in most implementations piggybacks
on the authorization policy for INVITE (which is, in most cases,
based simply on "I placed or answered this call").

Globally Routable UA URIs (GRUUs) [SIP-GRUU] can be used to address
problem 1. Problem 2 can be addressed using the Target-Dialog header
field defined in [RFC4538]. In the immediate term, this solution to
problem 2 allows the existing REFER authorization policy to be
reused.

It should say:

3. There were concerns with authorizing out-of-dialog REFERs. The
authorization policy for REFER in most implementations piggybacks
on the authorization policy for INVITE (which is, in most cases,
based simply on "I placed or answered this call").

Globally Routable UA URIs (GRUUs) [SIP-GRUU] can be used to address
problem 1. Problem 2 can be addressed using the Target-Dialog header
field defined in [RFC4538]. In the immediate term, this solution to
problem 2 allows the existing INVITE authorization policy to be
reused by REFER (thus solving problem 3).

Notes:

The phrase 'allows the existing REFER authorization policy to be reused' leads to a misunderstanding and confusion, because in actual fact INVITE authorization policy may be reused by REFER, not inversely.
The correction is proposed in order to clear up confusion.

Errata ID: 1892
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2009-09-23
Held for Document Update by: Robert Sparks

Section 6 says: 

page 10:

   F5 INVITE Transferee -> Transfer Target
...
   CSeq: 521 REFER

page 14:

   F5 INVITE Transferee -> Transfer Target
...
   CSeq: 521 REFER

page 15:

   F6 NOTIFY Transferee -> Transferor
...
   CSeq: 29889 INVITE

It should say:

page 10:

   F5 INVITE Transferee -> Transfer Target
...
   CSeq: 521 INVITE

page 14:

   F5 INVITE Transferee -> Transfer Target
...
   CSeq: 521 INVITE

page 15:

   F6 NOTIFY Transferee -> Transferor
...
   CSeq: 29889 NOTIFY

Report New Errata



Advanced Search