[asterisk-bugs] [Asterisk 0014653]: Never reply 503, use 500 instead (don't break DNS SRV failover)

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14653 
====================================================================== 
Reported By:                ibc
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14653
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.23 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-12 06:18 CDT
Last Modified:              2009-03-13 15:50 CDT
====================================================================== 
Summary:                    Never reply 503, use 500 instead (don't break DNS
SRV failover)
Description: 
As reported in bug http://bugs.digium.com/view.php?id=14644, Asterisk shouldn't
reply 503 to the client since
a 503 forces a client to contact an alternate server when it's not needed
at all (Asterisk is still alive and working).

RFC 3261:
-----------------------
21.5.4 503 Service Unavailable
    [...]
    A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
    attempt to forward the request to an alternate server. It SHOULD NOT
    forward any other requests to that server for the duration specified
    in the Retry-After header field, if present.
-----------------------
 
As mmichelson tells in http://bugs.digium.com/view.php?id=14644:

  "It appears there are several response codes which Asterisk translates
into
   an AST_CONTROL_CONGESTION frame and then queues onto the channel. When
the
   other side reads this AST_CONTROL_CONGESTION frame, if it is a SIP
channel,
   it will send a 503."


I propose to replace ALL the 503 replies in chan_sip.c to 500. Asterisk
should *never* reply a 503 except in the case Asterisk *does* know it is
not working properly, and AFAIK there is no way in Asterisk to know it.
Replying 503 breaks SIP DNS SRV failover (RFC 3263) so 500 would be a more
appropiate response code.

For example, OpenSer/Kamailio/OpenSIPS proxy converts a 503 from
downstream into a 500 upstream. If a proxy/PBX replies 503 to a client it
is the same as saying "don't use me, try other server".

Asterisk should reply 503 in some cases, for example after a Dial through
a E1/T1 trunk with no avaliable channels. Then, the caller would receive
the 503 and try other server. In this case a 503 is correct (so probably an
agressive "sed 's/503/500/g'" in all chan_sip.c would break it).

Is it feasible? I think Asterisk shouldn't convert so many response codes
into AST_CONTROL_CONGESTION, but use something as AST_INTERNAL_ERROR which
is translated into "SIP 500" while AST_CONTROL_CONGESTION is translated
into "SIP 503" (as now).
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014644 Asterisk should transform SIP 503 code ...
====================================================================== 

---------------------------------------------------------------------- 
 (0101758) mmichelson (administrator) - 2009-03-13 15:50
 http://bugs.digium.com/view.php?id=14653#c101758 
---------------------------------------------------------------------- 
I can think of a couple of other cases where a 503 would be appropriate:

1. If there is some sort of internal failure while processing a message
(such as a memory allocation failure or failure to masquerade channels)
then a 503 seems appropriate.

2. If Asterisk is in the process of shutting down, sending a 503 would be
appropriate. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-13 15:50 mmichelson     Note Added: 0101758                          
======================================================================