Subject: [sipcore] RFC 3261 Section 5

From: Jon Anderson <[email-masked]>
Date: Thu, 8 Feb 2018 12:54:54 -0600

There is some confusing verbage in paragraph 5 of section 5 in RFC 3261.
The original reads:

 A transaction is a request sent by a
   client transaction (using the transport layer) to a server
   transaction, along with all responses to that request sent from the
   server transaction back to the client.

I'm new to this protocol, but it seems like "A transaction is a request
sent by a client transaction to a server transaction" would lead one down
an infinite rabbit hole of definitional looping. Should this read something
close to:

 A transaction is a request sent by a
   client (using the transport layer) to a server,
   along with all responses to that request sent from the
   server back to the client.

Thanks,
Jon

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 08 Feb 2018 21:54:32 -0500

>    server transaction back to the client.

I'm not sure that all these terms are properly defined in RFC 3261.  But
a "client transaction" is the state machine that handles the transaction
at the client end, and a "server transaction" is the state machine that
handles the transaction at the server end, and a "transaction" is the
system comprising the server transaction, the client transaction, and
the messges between them (in turn, comprising a request and zero or more
responses).

In addition, sometimes larger groupings are called "transactions":

- An "end-to-end" transaction follows a request from the UAC which
  originates it, through zero or more proxies, to the UAS that consumes
  it (and the reverse for the responses).  A "hop-by-hop" transaction
  considers only one link in chain, between two devices that immediately
  communicate with each other (which have the roles of client and
  server).

- Grouping an ACK transaction with the INVITE transaction that it
  follows.  (There are specific rules in RFC 3261 causing ACKs of
  failure responses to be handled differently than ACKs of success
  responses.)

- Grouping a CANCEL transaction with the INVITE transaction that it is
  canceling.

- If an initial INVITE (or other outside-of-dialog request) forks, the
  messages from the UAC to each destination UAS can be considered one
  (end-to-end) transaction, or all the forks can be grouped together as
  a larger transaction.

Dale