[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 18:42
Message generated for change (Settings changed) made by ibc_sf
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: modules
>Group: ver devel
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Guillaume (glwld)
>Assigned to: Iñaki Baz (ibc_sf)
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.").


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

>Comment By: Iñaki Baz (ibc_sf)
Date: 2009-03-18 02:11

Message:
I've added a new TM parameter "drop_stateless_replies" to the trunk
version:

 
http://openser.svn.sourceforge.net/viewvc/openser?view=rev&revision=5718

Since there are already two solutions for this issue I close the report
:)

Thanks a lot.

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

Comment By: Iñaki Baz (ibc_sf)
Date: 2009-03-17 22:06

Message:
There is a solution for it:

---------------
onreply_route {
  if ! t_check_trans() {
    xlog("L_CRIT", "--- Response with no transaction received -->
drop()\n");
    drop();
  }
}
---------------

It works and the response is not forwarded :)

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

Comment By: Iñaki Baz (ibc_sf)
Date: 2009-03-17 21:30

Message:
According to draft-sparks-sip-invfix-03, no one response not matching a
proxy client transation should be stateless forwarded. This is not
exclusive for 487.

Kamailio should implement this draft.

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

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