[OpenSER-Devel] [ openser-Feature Requests-1968908 ] Allow "append_branch" in FAILURE_ROUTE if best reply is 6XX

[SourceForge.net]

Feature Requests item #1968908, was opened at 2008-05-21 19:31
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743023&aid=1968908&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: core
Group: ver devel
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow "append_branch" in FAILURE_ROUTE if best reply is 6XX

Initial Comment:
Actually OpenSer doesn't allow "append_branch" in FAILURE ROUTE if the best negative reply received is a 6XX. It's done in this way to be RFC 3261 compliant since 6XX means "global failure and no further forking is allowed".

In this way if we implement a voicemail forwarding system based of FAILURE ROUTE it just will work if the called user rejected the call with a 4XX code (480, 486...) but if it used a 6XX then OpenSer won't create a new branch to forward the INVITE to the voicemail. Also note that some UA's use 4XX and others 6XX to reject a call.


But I'm really not sure that OpenSer would break the RFC 3261 if it allows creating a new branch **AFTER** choosing the best response even if it was a 6XX:

FAILURE_ROUTE is executed when all the branches have finished, all of them with a negative response. Then the "best" response is chosen by OpenSer and its code is what we can see if we run:
  t_check_status("XXX")
in FAILURE_ROUTE.

So, I don't think that using "append_branch()" into FAILURE_ROUTE is anti-RFC3261, the steps are:

- OpenSer receives an INVITE and forks it to the user locations.
- OpenSer receives a 480, 486 and 603.
- It chooses 603 as best response.
- It runs the FAILURE_ROUTE in which a "append_branch" is executed.
- The INVITE is forwarded to a media server.

The new branch has been created **AFTER** choosing the best response from "real" branches. The FAILURE_ROUTE is part of our proxy logic, so IMHO those steps are not anti-RFC3261 at all.


So I propose that OpenSer can generate a new branch in FAILURE ROUTE even if the best response was a 6XX.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-05-26 12:14

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi Inaki,

First of all, the text you quoted says very clear - the change is about
the internal processing of the reply and not about the overall outcome - "
the result will be the same - the 6xx is forwarded upstream".

Also your interpretation of the text conflicts with the RFC3261 - see
Section 6 Definitions:

      Sequential Search: In a sequential search, a proxy server attempts
         each contact address in sequence, proceeding to the next one
         only after the previous has generated a final response.  A 2xx
         or 6xx class final response always terminates a sequential
         search.

Regards,
Bogdan


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

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-05-26 11:40

Message:
Logged In: YES 
user_id=1844020
Originator: YES

I also point to RFC 3261:


 28 Changes From RFC 2543

      Proxies no longer forward a 6xx immediately on receiving it.
      Instead, they CANCEL **pending** branches immediately.  This avoids
a
      potential race condition that would result in a UAC getting a 6xx
      followed by a 2xx.  In all cases except this race condition, the
      result will be the same - the 6xx is forwarded upstream.


Note that there is: "6XX CANCEL **pending** branches immediately".
For me, a **pending** branch is an already initiated branch, not a new one
generated after receiving the 6XX. So, IMHO, a 6XX shouldn't cancel a new
branch created in FAILURE_ROUTE after processing the 6XX.


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

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