[OpenSIPS-Users] 487 Request Terminated and BYE

[Bogdan-Andrei Iancu]

Hi Guillaume,

the problem is because of statefull versus stateless - you are right 
about what RFC says (no negative reply after 200 OK), but this applies 
only if you have a transaction.

What happens in your case is that the 487 retransmission exceeds the 
lifetime of the INVITE transaction and because the reply does not match 
a transaction anymore, it is simply forwarded stateless.

This behaviour is fixed in 1.5.0 (just released today) -  if you do not 
use any stateless request fwd functions, the OpenSIPS core will also 
refuse to forward any stateless reply.

so, in your scenario, during the lifetime of the INVITE transaction , 
the 487 will be blocked by TM; after the transaction is deleted, the 
reply will be dropped by core.

So, you have to upgrade to 1.5 as any previous version does not offer 
any solution for this case.

Regards,
bogdan

Guillaume Lacroix wrote:
> 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
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>