On 6/4/07 3:37 PM, Iliff, Tina wrote:
>
>
> Please consider the following call flow scenario:
>
> OUA sends INVITE to Proxy
> Proxy sends 100 Trying to OUA
> Proxy routes INVITE to SBC
> SBC sends 100 Trying to Proxy
> SBC routes INVITE to TUA
> SBC does not receive 100 Trying from TUA and retransmits INVITE
> several times
> OUA sends CANCEL to Proxy
> Proxy responds to CANCEL with 200OK
> Proxy routes CANCEL to SBC
> SBC does not route CANCEL to TUA
> A CANCEL timer on Proxy pops and Proxy sends 487 for INVITE request to OUA
>
It shouldn't be running a timer for the CANCEL. CANCEL is a matter to be
handled by the User Agents, not the proxies. Now, the proxy *will* be
running timer C, and may tear down the transaction using section 16.8
processing, but this will happen long after Timer B pops. So, in
practice, when the transaction times out at the SBC, it will send a 408
to the Proxy; the proxy ACKs the 408; the proxy sends a 408 to the UAC;
and the UAC ACKs it. Everything works fine.
However, let's imagine that the proxy *has* somehow lost transaction
state here, and think about what happens when the SBC Timer B pops. (I
think there might be a way to reach a similar state if Timer C expires
at the Proxy before it expires on the SBC).
> Several seconds elapse and Timer B pops on the SBC and it sends a 408
> back to the Proxy for the INVITE request
> The proxy does not ACK the 408 response; therefore, the SBC
> retransmits the 408 for 64*T1 seconds
>
The proxy can do exactly one of two things here, and dropping the
response isn't either of them.
If the proxy still has transaction state for the INVITE transaction,
then the proxy sends an ACK to the 408 -- retransmission stops.
If the proxy does *not* have transaction state for the INVITE
transaction, then it must forward the 408 towards the UAC (what you're
calling the "OUA" in your example) according to the Via header fields:
16.7 Response Processing
When a response is received by an element, it first tries to locate a
client transaction (Section 17.1.3) matching the response. If none
is found, the element MUST process the response (even if it is an
informational response) as a stateless proxy (described below).
(then, in section 16.11)...
When a response arrives at a stateless
proxy, the proxy MUST inspect the sent-by value in the first
(topmost) Via header field value. If that address matches the proxy,
(it equals a value this proxy has inserted into previous requests)
the proxy MUST remove that header field value from the response and
forward the result to the location indicated in the next Via header
field value.
The UAC will hold on to the client transaction until Timer D expires (32
seconds), and any responses that match the client transaction (including
these 408s) will cause the ACK to be retransmitted.
Any retransmissions of the final response that are received while in
the "Completed" state MUST cause the ACK to be re-passed to the
transport layer for retransmission, but the newly received response
MUST NOT be passed up to the TU. A retransmission of the response is
defined as any response which would match the same client transaction
based on the rules of Section 17.1.3.
Now, there _is_ a bit of underspecification here (at least, as far as I
can tell), since there's no normative behavior that would require the
proxy to route this ACK to the SBC; however, the nominal case for most
proxies will be to process the Request-URI in the ACK in the same way as
it did the Request-URI in the INVITE, which would result in routing to
the SBC, and consequently squelching the retransmissions.
I'm sure someone will step in and correct me if I've gotten any of this
wrong. :)
/a
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
