7 Feb
2006
7 Feb
'06
6:15 a.m.
For more precise to investigate the case, the ngrep log is listed below for
UA1 ------INVITE ----> UA2
UA2 (ringing)
UA1 ------CANCEL----> UA2
UA2 (ringing)
UA1 -----INVITE--------> UA3 (in few seconds)
UA1 ------call established----UA3
UA1 <-------BYE------- UA2
UA1 -----call drop--------UA3
http://meerkat.no-ip.com/openser/cancel_redial.log
As it is a long ngrep log, I would like to point out some strange
message behaviour.
The first CANCEL message is issued in line 235.
487 is issued in line 291 from the CISCO server
strange: From line 316 to 386, there are 3 rounds of message code 487 and ACK
strange: UA1 keeps sending CANCEL to openser until getting a message
"no more pending branches" in line 442 and 497.
new INVITE message from another call.
strange: In line 597, message code 487 is issued again from openser
with the previous call.
After that, the current call and the previous cancelled call mix
together and finally the current call is dropped.
On 2/7/06, unplug <maillisting(a)gmail.com> wrote:
For the case below.
UA1 -----INVITE ----> UA2
UA1 ------call established---- UA2
UA1 ------BYE --------> UA2
UA1 ------INVITE ------> UA3 (in a few seconds)
UA1 ------call established---- UA3
UA1 <-------BYE -----------UA2
UA1 -----call drop--------UA3
It will cause call drop as the case in the previous discussion. Does
it the same reason for the call drop?
Do you mean there is no way for openser to handle the case as it is
only a proxy? Instead, UA1 device should handle the case such that it
should wait for the cycle completion before it really BYE/CANCEL the
call. Am I right?
In my configuration, UA1 is a hardware sip phone and connect to the
openser server directly.
UA1 --------openser -----------CISCO gateway -------PSTN
(sip phone)
Do you mean the sip phone should handle the matching before it makes
another call?
On 2/3/06, Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote:
On 02/02/06 17:28, unplug wrote:
Thanks for explanation. As a normal user
behaviour, he will cancel
the call when he noted that he has dialed a wrong number. Then he
will make another call for his desired destination immediately.
As you said, UA1 needs to wait until the message cycle complete.
However, user have no idea when the message cycle will complete.
The user should
not be the one to solve the problem. The UA1 device has
to behave properly, to keep the canceled dialog until the cycle
completes. Moreover, it should match the BYE to the proper dialog or
send back "call/leg transaction does not exist" when the call is no
longer active.
For
a long distance call, the time needed for completing the cycle will be
much longer.
Do you mean it can't be prevented in the voip/openser environment?
I would say no. In similar case to UA1 may be a gateway or multi-line
phone which can have several calls in parallel. The UA1 must follow
dialog matching specifications as per RFC3261 and everything should go
just fine.
Cheers,
Daniel