| Article Index |
|---|
| Transaction layer operations in SIP |
| Page 2 |
| Page 3 |
| Page 4 |
| Page 5 |
| Page 6 |
| Page 7 |
| Page 8 |
| All Pages |
Page 4 of 8
When in either the "Calling" or "Proceeding" states, reception of a
2xx response MUST cause the client transaction to enter the
"Terminated" state, and the response MUST be passed up to the TU.
The handling of this response depends on whether the TU is a proxy
core or a UAC core. A UAC core will handle generation of the ACK for
this response, while a proxy core will always forward the 200 (OK)
upstream. The differing treatment of 200 (OK) between proxy and UAC
is the reason that handling of it does not take place in the
transaction layer.
The client transaction MUST be destroyed the instant it enters the
"Terminated" state. This is actually necessary to guarantee correct
operation. The reason is that 2xx responses to an INVITE are treated
differently; each one is forwarded by proxies, and the ACK handling
in a UAC is different. Thus, each 2xx needs to be passed to a proxy
core (so that it can be forwarded) and to a UAC core (so it can be
acknowledged). No transaction layer processing takes place.
Whenever a response is received by the transport, if the transport
layer finds no matching client transaction (using the rules of
Section 17.1.3), the response is passed directly to the core. Since
the matching client transaction is destroyed by the first 2xx,
subsequent 2xx will find no match and therefore be passed to the
core.
17.1.1.3 Construction of the ACK Request
This section specifies the construction of ACK requests sent within
the client transaction. A UAC core that generates an ACK for 2xx
MUST instead follow the rules described in Section 13.
The ACK request constructed by the client transaction MUST contain
values for the Call-ID, From, and Request-URI that are equal to the
values of those header fields in the request passed to the transport
by the client transaction (call this the "original request"). The To
header field in the ACK MUST equal the To header field in the
response being acknowledged, and therefore will usually differ from
the To header field in the original request by the addition of the
tag parameter. The ACK MUST contain a single Via header field, and
this MUST be equal to the top Via header field of the original
request. The CSeq header field in the ACK MUST contain the same
value for the sequence number as was present in the original request,
but the method parameter MUST be equal to "ACK".
If the INVITE request whose response is being acknowledged had Route
header fields, those header fields MUST appear in the ACK. This is
to ensure that the ACK can be routed properly through any downstream
stateless proxies.
Although any request MAY contain a body, a body in an ACK is special
since the request cannot be rejected if the body is not understood.
Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED,
but if done, the body types are restricted to any that appeared in
the INVITE, assuming that the response to the INVITE was not 415. If
it was, the body in the ACK MAY be any type listed in the Accept
header field in the 415.
For example, consider the following request:
INVITE sip: This e-mail address is being protected from spambots. You need JavaScript enabled to view it SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip: This e-mail address is being protected from spambots. You need JavaScript enabled to view it >
From: Alice <sip: This e-mail address is being protected from spambots. You need JavaScript enabled to view it >;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 INVITE
The ACK request for a non-2xx final response to this request would
look like this:
ACK sip: This e-mail address is being protected from spambots. You need JavaScript enabled to view it SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip: This e-mail address is being protected from spambots. You need JavaScript enabled to view it >;tag=99sa0xk
From: Alice <sip: This e-mail address is being protected from spambots. You need JavaScript enabled to view it >;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 ACK
