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.