When UA1 calls UA2, UA1 drop the call before UA2 take the call. After a few second, UA1 makes another call to UA3. The call established and it will drop after a few second. I expect the situation below.
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
What can I do to reduce the situation above?
Hello,
On 02/02/06 13:11, unplug wrote:
When UA1 calls UA2, UA1 drop the call before UA2 take the call. After a few second, UA1 makes another call to UA3. The call established and it will drop after a few second. I expect the situation below.
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
What can I do to reduce the situation above?
such situation is hard to prevent from proxy side. In my opinion, the UA1 does not behave correctly. After UA1 sends the CANCEL, it has to way for 200OK of CANCEL and 487 for INVITE and then send the ACK for INVITE's reply. Only after all these messages , it can close the dialog to UA2 and not the one to UA3.
Basically, the UA1 matches the wrong dialog for BYE (the From tag in BYE (UA2) should be different than the tag of UA3).
Cheers, Daniel
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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. 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?
such situation is hard to prevent from proxy side. In my opinion, the UA1 does not behave correctly. After UA1 sends the CANCEL, it has to way for 200OK of CANCEL and 487 for INVITE and then send the ACK for INVITE's reply. Only after all these messages , it can close the dialog to UA2 and not the one to UA3.
Basically, the UA1 matches the wrong dialog for BYE (the From tag in BYE (UA2) should be different than the tag of UA3).
Cheers, Daniel
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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
such situation is hard to prevent from proxy side. In my opinion, the UA1 does not behave correctly. After UA1 sends the CANCEL, it has to way for 200OK of CANCEL and 487 for INVITE and then send the ACK for INVITE's reply. Only after all these messages , it can close the dialog to UA2 and not the one to UA3.
Basically, the UA1 matches the wrong dialog for BYE (the From tag in BYE (UA2) should be different than the tag of UA3).
Cheers, Daniel
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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
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@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@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
Can I simply drop the ACK of the CANCEL according to the tag to solve this problem?
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
-
Daniel-Constantin Mierla -
unplug