[OpenSER-Devel] [ openser-Bugs-1822692 ] 503 behavior

Tue Nov 13 17:42:40 UTC 2007

Bugs item #1822692, was opened at 2007-10-30 13:07
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1822692&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 1.2.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Klaus Darilion (klaus_darilion)
Assigned to: Bogdan (bogdan_iancu)
Summary: 503 behavior

Initial Comment:
Hi!

1. bug: Openser should change 503 to 500 when relaying responses as otherwise it will disable itself if upstream proxy is also openser with default blacklisting.

RFC 3261 page 111:

         A proxy which receives a 503 (Service Unavailable) response
         SHOULD NOT forward it upstream unless it can determine that any
         subsequent requests it might proxy will also generate a 503.
         In other words, forwarding a 503 means that the proxy knows it
         cannot service any requests, not just the one for the Request-
         URI in the request which generated the 503.  If the only
         response that was received is a 503, the proxy SHOULD generate
         a 500 response and forward that upstream.

2. bug: Openser puts SIP node which sent 503 on blacklist even if Retry-After header is not present (this case should be handled like 500):

RFC 3261 page 191:

   The server is temporarily unable to process the request due to a
   temporary overloading or maintenance of the server.  The server MAY
   indicate when the client should retry the request in a Retry-After
   header field.  If no Retry-After is given, the client MUST act as if
   it had received a 500 (Server Internal Error) response.

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

>Comment By: Bogdan (bogdan_iancu)
Date: 2007-11-13 19:42

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

Hi Klaus,

stateless versus statefull - well you can do it for stateless also, but
you have no idea about branches, winning reply, etc, so you need a more
tough approach - if you see a 503, just change it to 500.

1a) could be

1b) 503 should be ignored if there are any other branches.

2) still sounds ilogical, but :)...

So, the fix should be:
A) on outbound side, all 503 should be changed to 500 (with or without
RA), both on stateful and stateless - but only for received replies and not
for local generated ones.
B) ignore 503 in branch selection
C) put 503 in BL only if it has a RA hdr.

Is this correct according to your understanding on the matter?

Regards,
Bogdan

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

Comment By: Klaus Darilion (klaus_darilion)
Date: 2007-11-13 09:40

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

Hi Bogdan!

I think it is valid for stateless too. E.g. you have 3 proxies, A, B and
C. A forwards to B and B forwards to C. Then, C replies with 503-retry
after 60 seconds. If B forwards this response to A, then A will think that
B is out of order although only C is out of order. In this scenario I can
not see a difference between stateless and statefull.

1a) I would think in the failure route there should be 503, but the reply
should be a 500. Maybe this conversion can be  used as response text,
e.g.:
SIP/2.0 500 Received 503 From Upstream Server

1b) Regarding blacklisting: If a branch responds with 503 I think it
should be added to the blacklist (if Retry-After header is present).
Regarding Winning Branch: 

RFC3261: For example, if a proxy forwarded a request to 4 locations, and
         received 503, 407, 501, and 404 responses, it may choose to
         forward the 407 (Proxy Authentication Required) response......

Here it is clear as the 4xx codes should be used. If there is a 6xx
response this one must be used. If there are only 5xx response codes, and
there is at least one response code != 503, then IMO the proxy should not
respond with 503 - thus choosing one of the response codes except 503.

2)
> But treating 503 without a RA hdr as a 500 make no sense
> to be..why not use 500 directly instead of 503 without RA??

IMO this indicates that the UA-server is not well designed. SIP offers a
503 response code which can be used to signal "out of service" with a RA
time. But if the server does not indicate a Retry-After time, then the
proxy MUST not choose any Retry-After time as it does not know if the
server is still out of order - thus handling the 503 just like 500.

Thus, I think the logic is, that the proxy has to deal with server which
fail to add a Retry-After header to 503. My conclusion: A 503 without RA
header is the same as a 500.

regards
klaus

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

Comment By: Bogdan (bogdan_iancu)
Date: 2007-11-12 18:55

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

Hi Klaus,

First of all I think this discussion is valid only for the stateful
processing (TM) and not for stateless one.

Now,for 1) - the RFC makes a recomandation which makes sense (logically
speaking). Here some things need to be clarify:
   a) if there is a single branch replied with 503, then openser should
replace it with 500; Question: what reply code should be presented in
failure route? if we put 503, it will not reflect the sent reply; if you
put 500, it will not reflect the received reply
   b) if there are multiple branches, should a 503 branch be treated as it
is? should it be ignore or should it be processed as an 500? should this
branch be a potential winning branch?

For 2) - to be honest I fail to see the logic here. If a Retry-After is
present, then puting the destination in the BL only for that period of
time, make sense. But treating 503 without a RA hdr as a 500 make no sense
to be..why not use 500 directly instead of 503 without RA??

Regards,
Bogdan

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

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