Hi Adam, Not sure it's a correction or more of a question, as I might have got this wrong myself...
> -----Original Message----- > From: Adam Roach [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 06, 2007 1:54 AM > To: Iliff, Tina > Cc: [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu > Subject: Re: [Sipping] Proxy acting as UAS -- CANCEL scenario > > 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. > The stateful proxy has client transaction(s) for each server transaction. Meaning that on one end it acts as a UAS and on the other a UAC. Section 16.10 (CANCEL Processing): A stateful proxy MAY generate a CANCEL to any other request it has generated at any time (subject to receiving a provisional response to that request as described in section 9.1). A proxy MUST cancel any pending client transactions associated with a response context when it receives a matching CANCEL request. When the proxy cancels the client transaction is it also subject to the following statement in section 9.1? Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request. It seems to me as if it should because the proxy might have sent the CANCEL request to an RFC 2543-compliant UAS. Is it a good idea to leave this behavior to user agents only? I cannot think of a scenario that would really require the proxy to hold the transaction for 3 minutes given the fact that if it won't respond to the CANCEL request the UAC will terminate it after 64*T1 seconds. If the proxy does not send the 487 response, I still think there is a slight race condition. The UAC will only receive the 408 response, not 487, because the proxy waits. Therefore, if the CANCEL was sent almost immediately after the INVITE both the UAC and the SBC are waiting for 64*T1 seconds. It's possible the 408 will not reach in time. If anyone is really into solving this rare scenario, one possible solution is to wait a bit longer after the CANCEL, for example 64*T1 + T4. Cheers, Gilad _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
