RFC 3261, "SIP: Session Initiation Protocol", June 2002

Note: This RFC has been updated by RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996

Errata ID: 4385
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Krisztian Sinka
Date Reported: 2015-06-02
Held for Document Update by: Ben Campbell
Date Held: 2015-06-05

Section 17.2.1 says:

                               |INVITE
                               |pass INV to TU
            INVITE             V send 100 if TU won't in 200ms
            send response+-----------+
                +--------|           |--------+101-199 from TU
                |        | Proceeding|        |send response
                +------->|           |<-------+
                         |           |          Transport Err.
                         |           |          Inform TU
                         |           |--------------->+
                         +-----------+                |

It should say:

                               |INVITE
                               |-
            INVITE             V send 100 if TU won't in 200ms
            send response+-----------+
                +--------|           |--------+101-199 from TU
                |        | Proceeding|        |send response
                +------->|           |<-------+
                         |           |          Transport Err.
                         |           |          Inform TU
                         |           |--------------->+
                         +-----------+                |

Notes:

The standard states about lifetime of the server transaction:

"Server transactions are created by the
core when a request is received, and transaction handling is desired
for that request (this is not always the case)."(17.2)

So this means that the server transaction is created by the TU (the core). This also means that it is useless to *pass INV to TU* due to that TU itself already has the request.

The same logic should apply to Figure 8. as well.

Report New Errata