[Kamailio-Users] 487 Request Terminated and BYE

Guillaume Lacroix gl at worldline.fr
Tue Mar 17 18:45:44 CET 2009


Thanks for the quick answer and explanation Iñaki :) As you advised, I 
opened a feature request in the tracker and put in it the elements you 
mentionned. If anyone has yet a way to trick openSER to not forward 487 
answer with no transaction attached, I would be glad to know it :)

Bye,
Guillaume

Iñaki Baz Castillo a écrit :
> 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?
>
>
>   




More information about the sr-users mailing list