[OpenSIPS-Users] 487 Request Terminated and BYE

Guillaume Lacroix gl at worldline.fr
Sun Mar 15 19:03:23 CET 2009


Hi,

I am facing problem with handling CANCEL/487 Request Terminated in a 
case of a call hunting. The problem is that the call terminating carrier 
doesn't process the ACK properly and keeps sending 487 messages.

Here is an example.

Let's say UAC1 has the following rules of call hunting :
1. call +33123456 for 10s
2. call +33789456 for 10s

Let's say that an incoming call to UAC1 triggers the call hunting.

Here is a diagram :

openSER -> Terminating Carrier (TC) : INVITE +33123456

... (time out : +33123456 didn't answer in 10s, so openSER sends an 
INVITE to +33789456 - and let's say to an other Terminating carrier TC2 
- and CANCEL the current INVITE to TC)

openSER -> TC2 : INVITE : +33789456
openSER -> TC : CANCEL
TC -> openSER : 487 Request Terminated
openSER -> TC : ACK

The problem is now TC doesn't process the ACK correctly and keeps 
sending 487. So, in the case of +33789456 answering the call (a 200 OK 
is sent to openSER), openSER will keep relaying the 487 to TC2 and TC2 
will then send a BYE a terminate the call :

TC -> openSER : 487
openSER -> TC : ACK

TC -> openSER : 487
openSER -> TC : ACK

TC2 -> openSER : OK
openSER -> TC2 : ACK
<-- The call is taking place -->

TC -> openSER : 487
openSER -> TC : ACK
openser -> TC2 : 487 (openSER relays the 487 once the call has been 
established to TC2)
TC2 -> openSER : ACK
TC2 -> openSER : BYE
<-- Call is ended but should not -->

According to the RFC, once a call has been OKed and a 487 is received, 
TC2 may go on with the call or send a BYE (up to it). So it behaves the 
right way (chapter 15. end of 3rd paragraph : "If the INVITE results in 
2xx final response(s) to the INVITE, this means that a UAS accepted the 
invitation while the CANCEL was in progress.  The UAC MAY continue with 
the sessions established by any 2xx responses, or MAY terminate them 
with BYE.").

My question is then : is there a way to prevent this behavior when a 
terminating carrier doesn't behave correctly, either by preventing 
relaying of the 487 once it has been ACKed or once the call has been 
OKed (but I guess we are not RFC compliant then) ?

Thanks

Bye,
Guillaume



More information about the Users mailing list