Frankly I did not expect this. Just like (Open)SER, I also suppress INVITE retransmission when canceling INVITE UAC (that hasn't been responded to). I wonder where did we get that specification from.
So it looks like one more bug to fix for me too.. sigh.. -benny On 3/10/08, Klaus Darilion <[EMAIL PROTECTED]> wrote: > From the "sip-implementors" list - looks like Maxim is right. > > regards > klaus > > > Robert Sparks schrieb: > > Part of why it does this is to deal with the case that the first > > INVITE the proxy sent actually got somewhere, but its response was > > lost. The retransmission will stimulate a retransmission of the > > response, letting you move forward to sending the CANCEL from the > > proxy. > > > > RjS > > > > On Mar 7, 2008, at 7:06 AM, Bob Penfield wrote: > > > >> > >> The INVITE transaction must still complete independent of the > >> CANCEL. So the proxy would continue to re-transmit the INVITE. If > >> the proxy does receive a provisional response, it would then stop > >> retransmissions and send the CANCEL down stream. If timer B fired, > >> it would send a 408 response to the INVITE. > >> > >> Note that the proxy should respond to the CANCEL with 200 OK when > >> it receives it since the INVITE transaction is in progress. > >> > >> cheers, (-:bob > >> > >> -----Original Message----- From: > >> [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf > >> Of Klaus Darilion Sent: Friday, March 07, 2008 4:11 AM To: > >> [EMAIL PROTECTED] Subject: [Sip-implementors] > >> CANCEL retransmisson question of no provisional response! > >> > >> Hi! > >> > >> Could someone help me please with this question. > >> > >> Scenario: A transaction-stateful proxy forwards the INVITE request. > >> The proxy does not receive a provisional response, thus starts > >> retransmissions. Now, the caller CANCELs the call. How is the proxy > >> supposed to handle this? Does the proxy still have to retransmit > >> the INVITE or can it stop retransmitting the INVITE? > >> > >> From logical point of view I would think that the proxy should stop > >> the retransmissions, but from Figure 5 in RFC 3261 it looks like > >> the only way to come from "Calling" state to "Terminated" state is > >> waiting for Timer B fires (as there is no provisional response > >> yet). > >> > >> thanks klaus > > > > > _______________________________________________ > Devel mailing list > Devel@lists.openser.org > http://lists.openser.org/cgi-bin/mailman/listinfo/devel > _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel