[Kamailio-Users] 487 Request Terminated and BYE

[Iñaki Baz Castillo]

2009/3/17 Guillaume Lacroix <gl at worldline.fr>:
> 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.").

Really interesting issue.

When Kamailio receives the 200 Ok in the second branch, it terminates
the transaction (according to RFC 3261), but the first branch remains
receiving 487 responses. Then, following RFC 3261, Kamailio forwards
*stateless* these responses with no transaction, so the 487 is
received by the client (and it decides to terminate de call).

There is a draft handling those issues:
  http://tools.ietf.org/html/draft-sparks-sip-invfix-03

----------------------
7.3.  Proxy Considerations

   A direct consequence of the change to the UAC state machine is that a
   transaction-stateful proxy will not foward any stray INVITE
   responses.  When receiving any SIP response, a transaction-stateful
   proxy MUST compare the transaction identifier in that response
   against its existing transaction state machines.  The proxy MUST NOT
   forward the response if there is no matching transaction state
   machine.
----------------------

Kamailio should implement this specification, I don't know if there is
some way now to imitate this behaviour.


> 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) ?

The behaviour you desire is already "draft"-compliant :)

Interesting issue however, could you please open a feature request on
the tracker?


-- 
Iñaki Baz Castillo
<ibc at aliax.net>