This means that openser does not receive the ACK or is not able to match the ACK to the canceled transaction. Thus it is re-transmitting the 487.

Increas the debug level and take a look at the syslog to find out if: 1. the ACK to the 487 is received by openser 2. if it is received, check if there is a problem during handling of the ACK. (for these kind of ACKs just t_relay()).

klaus

On Wed, February 15, 2006 5:13, unplug said:

For the normal cancel situation.

UA1 OPENSER UA2 --------INVITE-----------------> <-----------100----------------- --------------------INVITE----------> <---------------100------------------- ----------CANCEL----------> --------------CANCEL-------------> <--------------200------------------ <------------487------------------- --------------ACK-----------------> <---------487--------------- -------------ACK------------>

But in my case, I found that there are many 487 created from openser to

UA1. The multiple 487 may cause a call drop in the following call.

Why does openser create so many 487 for UA1? How can I prevent it?

UA1 OPENSER UA2 --------INVITE-----------------> <-----------100----------------- --------------------INVITE----------> <---------------100------------------- ----------CANCEL----------> --------------CANCEL-------------> <--------------200------------------ <------------487------------------- --------------ACK-----------------> <---------487--------------- -------------ACK------------> <---------487------------- -------------ACK------------> <---------487--------------- -------------ACK------------> <---------487------------- -------------ACK------------> <---------487------------- -------------ACK------------> <---------487------------- -------------ACK------------> <---------487------------- -------------ACK------------> ...

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users