On Wednesday 03 August 2005 05:29 am, you wrote:
Hi Michael,
the UAS must notify ASAP the upstream parties when the INVITE was received. Of course, network delays may interfere :(.
If I get it right, you are experience a *FAST* cancel from the UAC (since the proxy haven't received the 100 -even if delayed- from UAC). Is this the case?
Well, the caller sends INVITE to the proxy and then almost immediately it sends CANCEL, but CANCEL happens at the short period of time while INVITE has already been forwarded to callee, but no provisional response from callee has yet been received. "100" and "180" are arriving almost immediately after CANCEL has been processed by openser. I guess this situation is legitimate and in my observations is not quite rare.
If so, since it's not the fault of any parties, I will try to see if there is a way to solve this kind of race.
I don't think it's a fault of caller or callee UACs. I guess, as it's been pointed out by Klaus, openser should keep CANCEL in transaction context until transaction expires (probably until wt_timer expires) and transmit it if provisional response is received during that time.
regards, Bogdan
Michael Ulitskiy wrote:
On Tuesday 02 August 2005 06:25 pm, you wrote:
What is the correct behavior in this scenario?
As the proxy didn't received a "100.." yet, it must not send the CANCEL. IMO it should withhold the CANCEL unless a provisional response is received, but should stop sending INVITE retransmission.
I must confess, I didn't read RFC specifically on this subject, but behavior you described makes no sense to me. If proxy didn't cancel the call the callee keeps ringing forever.
Of course this rises the problem that the callee reponses with a 200 OK instead of a provisional response and then the call can't be cancelled anymore.
it's not the case here. UA replies correctly with 100, but a little too late. It was my understanding that CANCEL should be forwarded to cancel a call regardless of receiving any response. Please correct me if I'm wrong.