On Friday 07 March 2008, Maxim Sobolev wrote: > Klaus Darilion wrote: > >> The correct behavior of the tm module in this case would be to > >> continue with INVITE re-transmits until we get provisional response > >> and immediate CANCEL once that response comes in. > > > > Is this really the correct behavior? Is this behavior defined in RFC > > 3261? > > --- RFC 3261 --- > Once the CANCEL is constructed, the client SHOULD check whether it > has received any response (provisional or final) for the request > being cancelled (herein referred to as the "original request"). > > If no provisional response has been received, the CANCEL request > MUST NOT be sent; rather, the client MUST wait for the arrival of a > provisional response before sending the request. > --- RFC 3261 --- > > According to my reading yes, UAC should wait either arrival of the > first provisional response or expiration of Timer B (doing due > retransmits in the meantime for unreliable transports) and send CANCEL > if provisional reply comes in.
In the paragraph quoted above I do not see any reference to TimerB or to keep retransmitting the initial INVITE on a branch that did not send a provisional reply, even after the caller has canceled the call. The only thing I read in there is that if a branch has not sent a provisional reply until the branch is about to be canceled, either because other branch has picked up the call or because the caller has canceled the call himself, then a CANCEL should not be transmitted on the branch without a provisional reply. This behavior is already honored by openser, AFAIK. -- Dan _______________________________________________ Devel mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/devel
