Subject: RFC 4235 Erata

From: "Nicolas-Peter Pohland" <[email-masked]>
Date: Mon, 15 Jan 2007 11:47:08 +0100

In section 6.1. is says on page 25:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="2"
                   state="full"
                   entity="sip:[email-masked]">
        <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 be (or something similar with the id values differing):
 
      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="2"
                   state="full"
                   entity="sip:[email-masked]">
        <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>

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.

Regards,
Nicolas-Peter Pohland
 
Covote GmbH & Co KG
Ritterhufen 30
14165 Berlin
Germany