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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users