[Kamailio-Devel] [ openser-Feature Requests-2690374 ] Do not forward response to an INVITE if no matching transac

[SourceForge.net]

Feature Requests item #2690374, was opened at 2009-03-17 17:42
Message generated for change (Tracker Item Submitted) made by glwld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743023&aid=2690374&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guillaume (glwld)
Assigned to: Nobody/Anonymous (nobody)
Summary: Do not forward response to an INVITE if no matching transac

Initial Comment:
Do not forward 487 answer if it has no matching transaction accordint to the specification in the draft http://tools.ietf.org/html/draft-sparks-sip-invfix-03, specially : 

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

A direct consequence of the change to the UAC state machine is that a transaction-stateful proxy will not forward 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.
----------------------

That would solve the following situation by not forwarding the 487 answer once a call has been OKed in following transaction :

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.").


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743023&aid=2690374&group_id=139143