RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 14 records.

Status: Verified (5)

RFC 4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005

Note: This RFC has been updated by RFC 7463, RFC 8996

Source of RFC: sipping (rai)

Errata ID: 771
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28

Section 6.2 says: 

direction="receiver">

It should say:

direction="recipient">

Notes:

Occurs on pages 28, 29 (2 times), and 30.

The proposed version of text is consistent with the rest of the document,
including the schema in section 4.4.

from pending

Errata ID: 774
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28

Section 4.4 says: 

<xs:attribute name="display-name" type="xs:string"

It should say:

<xs:attribute name="display" type="xs:string"

Notes:

The proposed version of text is consistent with the rest of the document,
especially with all examples and has been implemented by several
manufacturers this way.

from pending

Errata ID: 781
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28

Section 6.2 says: 

          <local>
            <target uri="sip:alice@pc33.example.com"/>
              <param pname="+sip.rendering" pval="yes"/>
          </local>

It should say:

           <local>
            <target uri="sip:alice@pc33.example.com">
              <param pname="+sip.rendering" pval="yes"/>
            </target>
          </local>

Notes:

The <param> element must be enclosed by the <target> element.

from pending

Errata ID: 788
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-15
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28

Section 6.2 says: 

          <state reason="cancelled">terminated</state>
 
          <state reason="replaced">terminated</state>
 
          <state reason="replaced">confirmed</state>
 
          <state reason="remote-bye">terminated</state>

It should say:

          <state event="cancelled">terminated</state>
 
          <state event="replaced">terminated</state>
 
          <state event="replaced">confirmed</state>
 
          <state event="remote-bye">terminated</state>

Notes:

The "state" element does not have a "reason" attribute. It is called "event"
by definition in section 4.1.2. and the schema in 4.4.

from pending

Errata ID: 158
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Procter
Date Reported: 2006-10-24

Section 4.1 says: 

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="0" notify-state="full"
                   entity="sip:alice@example.com">
      </dialog-info>

It should say:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="0" state="full"
                   entity="sip:alice@example.com">
      </dialog-info>

Notes:

The proposed version of text is consistent with the rest of the document,
including the schema in section 4.4.

Status: Reported (1)

RFC 4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005

Note: This RFC has been updated by RFC 7463, RFC 8996

Source of RFC: sipping (rai)

Errata ID: 4237
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiaofeng Xu
Date Reported: 2015-01-19

Section 4.4 says: 

<xs:complexType name="participant">
          <xs:sequence>
            <xs:element name="identity" type="tns:nameaddr"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="target" minOccurs="0" maxOccurs="1">
              <xs:complexType>
                <xs:sequence>
                  <xs:element name="param" minOccurs="0"
                    maxOccurs="unbounded">
                    <xs:complexType>
                      <xs:attribute name="pname" type="xs:string"
                        use="required"/>
                      <xs:attribute name="pval" type="xs:string"
                        use="required"/>
                    </xs:complexType>
                  </xs:element>
                </xs:sequence>
                <xs:attribute name="uri" type="xs:string"
                                           use="required"/>
              </xs:complexType>
            </xs:element>
            <xs:element name="session-description" type="tns:sessd"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="cseq" type="xs:nonNegativeInteger"
              minOccurs="0" maxOccurs="1"/>
            <xs:any namespace="##other" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>

It should say:

<xs:complexType name="participant">
          <xs:sequence>
            <xs:element name="identity" type="tns:nameaddr"
              minOccurs="0" maxOccurs="unbounded"/>
            <xs:element name="target" minOccurs="0" maxOccurs="1">
              <xs:complexType>
                <xs:sequence>
                  <xs:element name="param" minOccurs="0"
                    maxOccurs="unbounded">
                    <xs:complexType>
                      <xs:attribute name="pname" type="xs:string"
                        use="required"/>
                      <xs:attribute name="pval" type="xs:string"
                        use="required"/>
                    </xs:complexType>
                  </xs:element>
                </xs:sequence>
                <xs:attribute name="uri" type="xs:string"
                                           use="required"/>
              </xs:complexType>
            </xs:element>
            <xs:element name="session-description" type="tns:sessd"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="cseq" type="xs:nonNegativeInteger"
              minOccurs="0" maxOccurs="1"/>
            <xs:any namespace="##other" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>

Notes:

The identity element is defined as maxOccurs="1" in the XML schema. However, in the section 4.1.6 of RFC4235, it says "Note that multiple identities (for example a sip: URI and a tel: URI) could be included if they all correspond to the participant". This seems to contradict with the XML schema.

Status: Held for Document Update (7)

RFC 4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005

Note: This RFC has been updated by RFC 7463, RFC 8996

Source of RFC: sipping (rai)

Errata ID: 780
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Held for Document Update by: Robert Sparks

Section 4.2 says: 

   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
     version="1" state="full">

It should say:

   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
    xmlns:xsi=" <http://www.w3.org/2001/XMLSchema-instance>
http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
     version="1" state="full" entity="sip:alice@example.com">

Notes:

According to the schema in section 4.4 the attribute "entity" must appear on
element "dialog-info".

from pending

Errata ID: 785
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-15
Held for Document Update by: Robert Sparks

Section 6.1 says: 

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="2"
                   state="full"
                   entity="sip:alice@example.com">
        <dialog id="as7d900as8" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="456887766"
                direction="initiator">
          <state>early</state>
        </dialog>
        <dialog id="as7d900as8" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="hh76a"
                direction="initiator">
          <state>early</state>
        </dialog>
      </dialog-info>

It should say:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="2"
                   state="full"
                   entity="sip:alice@example.com">
        <dialog id="1000" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="456887766"
                direction="initiator">
          <state>early</state>
        </dialog>
        <dialog id="1001" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="hh76a"
                direction="initiator">
          <state>early</state>
        </dialog>
      </dialog-info>

[[or something similar with the id values differing]]

Rationale:
 
Quote from RFC 4235:
 
"4.1.1.  Dialog Element
 
    ...
 
   For a caller, the id is created when an INVITE request is sent.  When
   a 1xx response with a tag, or a 2xx response is received, the dialog
   is formally created.  The id remains unchanged.  However, if an
   additional 1xx or 2xx is received, resulting in the creation of
   another dialog (and resulting FSM), that dialog is allocated a new
   id.

    ..."
 
The id of the dialog is a hash value of the call-id, local-tag and
remote-tag of the dialog. Therefore, the values of the ids in the example MUST not be identical.

Notes:

from pending

Errata ID: 1495
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2008-08-26
Held for Document Update by: Robert Sparks

Section 3.7.1 says: 

[...]
non-2xx response for any other reason, all FSMs spawned from that
INVITE transition to the Terminated state with the event "rejected".

--------------

[...]
If the UAS receives a CANCEL
request and then generates a 487 response to the INVITE (which can
occur in the Proceeding and Early states), the FSM transitions to the
Terminated state with the event "cancelled".

It should say:

[...]
non-2xx response for any other reason, all FSMs spawned from that
INVITE transition to the Terminated state with the event "rejected".
During Early state the FSM transitions to the Terminate state if the UAC sends a BYE (corresponding to "local-bye" event).

-------------

[...]
If the UAS receives a CANCEL
request and then generates a 487 response to the INVITE (which can
occur in the Proceeding and Early states), the FSM transitions to the
Terminated state with the event "cancelled".
If the UAS receives a BYE request during the Early state the FSM transitions to the Terminated state with the event "remote-bye".

Notes:

Section 3.7.1 (The Dialog State Machine) and the Figure 3 forget the case in which a UAC sends a BYE during an early-dialog as RFC3261 allows:

RFC 3261:
----------------
15 Terminating a Session
When a BYE is received on a dialog, any session
associated with that dialog SHOULD terminate. A UA MUST NOT send a
BYE outside of a dialog. The caller's UA MAY send a BYE for either
confirmed or early dialogs, and the callee's UA MAY send a BYE on
confirmed dialogs, but MUST NOT send a BYE on early dialogs.
----------------

So it should be a new row in Figure 3 from "Early" to "Terminate" labeled "local-bye/remote-bye". It would be "local-bye" in case of UAC and "remote-bye" in case of UAS.

Errata ID: 1517
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Klaus Darilion
Date Reported: 2008-09-17
Held for Document Update by: Robert Sparks

Section 6.1 says: 

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="4"
                   state="partial"
                   entity="sip:alice@example.com">
        <dialog id="as7d900as8" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="hh76a"
                direction="initiator">
          <state event="cancelled">terminated</state>
        </dialog>
      </dialog-info>

It should say:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="4"
                   state="partial"
                   entity="sip:alice@example.com">
        <dialog id="as7d900as8" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="456887766"
                direction="initiator">
          <state event="cancelled">terminated</state>
        </dialog>
      </dialog-info>

Notes:

The dialog which was cancelled was the first dialog and its remote tag is 456887766 instead of hh76a

Errata ID: 2266
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Grant
Date Reported: 2010-05-18
Held for Document Update by: Robert Sparks

Section 4.4 says: 

...
<xs:element name="route-set" minOccurs="0" maxOccurs="1">
   <xs:complexType>
      <xs:sequence>
         <xs:element name="hop" type="xs:string" minOccurs="1" maxOccurs="unbounded"/>
      </xs:sequence>
   </xs:complexType>
</xs:element>
...

It should say:

** Remove Element **

Notes:

The route-set element was removed between draft-ietf-sipping-dialog-package-03 and draft-ietf-sipping-dialog-package-04

Errata ID: 2267
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Grant
Date Reported: 2010-05-18
Held for Document Update by: Robert Sparks

Section 4.4 says: 

<xs:element name="cseq" type="xs:nonNegativeInteger" 
minOccurs="0" maxOccurs="1"/>

It should say:

** Remove Element **

Notes:

The participant/cseq element was removed between draft-ietf-sipping-dialog-package-03 and draft-ietf-sipping-dialog-package-04

Errata ID: 2861
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2011-07-13
Held for Document Update by: Gonzalo Camarillo

Section 4.4 says: 

  <xs:element name="state">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:string">

It should say:

  <xs:element name="state">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="tns:dialog-state">
...

  <xs:simpleType name="dialog-state">
    <xs:restriction base="xs:string">
      <xs:enumeration value="trying"/>
      <xs:enumeration value="proceeding"/>
      <xs:enumeration value="early"/>
      <xs:enumeration value="confirmed"/>
      <xs:enumeration value="terminated"/>
    </xs:restriction>
  </xs:simpleType>

Notes:

The RFC is rather coy about defining the exact syntax for the state element. The schema permits any content. It's fairly clear from the description in Section 3.7.1 what the permitted values are, but the case of the values is never explicitly stated. The text and diagram use title case consistently, and all the examples use lower case exclusively.

This is bad for interoperability. In practice, this is probably moot, since most implementations will use the lowercase form. Arguably, it would be valid to produce a value of "Early". An implementation seeking maximum interoperability would have to use case insensitive comparison to avoid a misinterpretation of the value.

Status: Rejected (1)

RFC 4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005

Note: This RFC has been updated by RFC 7463, RFC 8996

Source of RFC: sipping (rai)

Errata ID: 2268
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Grant
Date Reported: 2010-05-18
Rejected by: Robert Sparks
Date Rejected: 2010-10-07

Section 4.2 says: 

<xs:complexType name="sessd">
   <xs:simpleContent>
      <xs:extension base="xs:string">
         <xs:attribute name="type" type="xs:string" use="required"/>
      </xs:extension>
   </xs:simpleContent>
</xs:complexType>

It should say:

<xs:complexType name="sessd">
  <xs:attribute name="type" type="xs:string"/>
</xs:complexType>

Notes:

The sessd type is a simple type, which allows text content, yet the RFC does not describe what content it should have, so it should be an empty type instead.
--VERIFIER NOTES--
(From reviewer Dale Worley):

The description of the session-description element in section 4.1.6.3
is not particularly clear, but it is unambiguous:

4.1.6.3. Session Description Element

The session-description element contains the session description used
by the observed user for its end of the dialog. This element should
generally NOT be included in the notifications, unless it was
explicitly requested by the subscriber. It has a single attribute,
"type", which indicates the MIME media type of the session
description. To avoid repeating session description information in
each request, the subscriber can assume that the session description
is the same as in previous notifications if no session description
element is present in the corresponding local or remote element.

Therefore, a typical usage would be:

<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
<dialog id="123456">
<state>confirmed</state>
<duration>274</duration>
<local>
<identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="personal"/>
</target>
<session-description type="application/sdp">v=0
o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com
s=Session SDP
t=0 0
c=IN IP4 pc33.atlanta.com
m=audio 3456 RTP/AVP 0 1 3 99
a=rtpmap:0 PCMU/8000
</session-description>
</local>
<remote>
<identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
<session-description type="application/sdp">[SDP sent by remote UA]</se\
ssion-description>
</dialog>
</dialog-info>

That is, <session-description> has a "type" attribute whose value is
the MIME type of the session description, and it has content which is
the session description.

(Note that both the <local> and <remote> elements have their own
<session-description>, as SDP is sent by both UAs. Presumably the
<session-description> of a participant is the SDP that was *sent* by
that participant.)

Within this understanding, the XML schema language in the RFC is
correct. The '<xs:extension base="xs:string">' specifies that the
content of <session-description> is a string, and the '<xs:attribute
name="type" type="xs:string" use="required"/>' specifies that
<session-description> must have an attribute 'type'.

(The situation could have been made much clearer if the RFC included
an example of the use of <session-description>.)

Report New Errata



Advanced Search