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

SourceForge.net noreply at sourceforge.net
Mon May 26 12:01:16 CEST 2008 

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: modules
Group: ver devel
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
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 13:01

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

Hi Inaki,

Talking outside the RFC limitations, I would say you are right - let's
imagine the most simple case: global failure reply received and you do not
want to send this to clients, but rather play an announcement "call could
not be completed - world was nuked down". 

Also, I have to agree that RFC is ambigous about 6xx replies. The
definition says (21.6 Global Failures 6xx):

   6xx responses indicate that a server has definitive information about
   a particular user, not just the particular instance indicated in the
   Request-URI.

But during serial forking you may send the call to a totally different
user, who will not be under the incidence of the received 6xx..

So, INMHO 6xx (as reply codes are defined) is not as global as said.

Regards,
Bogdan


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

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-05-26 12:38

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

Well Bogdan, definitively I should report this bug to IETF instead of
OpenSer XDDD
It's Ok, your argument is clear and OpenSer behaviour is completely RFC
3261 compliant in this subject.

So I really wonder what were IETF people thinking about when deciding that
a 6XX cancels a sequential search and also decides "Decline" code to be 603
instead of a 4XX (in fact there is a draft [1] defining "441 Decline").

This escenario causes that a UAC declining a call ("I'm not busy, neither
in DND, I just don't want to answer this call") sending a 603 response that
cancelles any proxy forward to voicemail or wherever. IMHO it's a bad
design of response code.

Thanks a lot for all.

[1] http://tools.ietf.org/html/draft-worley-6xx-considered-harmful

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

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

More information about the Devel mailing list