[asterisk-bugs] [Asterisk 0014644]: [patch] Asterisk should transform SIP 503 code to SIP 500

[Asterisk Bug Tracker]

The following issue has been CLOSED 
====================================================================== 
https://issues.asterisk.org/view.php?id=14644 
====================================================================== 
Reported By:                ibc
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   14644
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.23 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 open
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-03-11 11:08 CDT
Last Modified:              2009-08-25 11:29 CDT
====================================================================== 
Summary:                    [patch] Asterisk should transform SIP 503 code to
SIP 500
Description: 
Hi, in the following simple dialplan:

  exten => _X.,1,Dial(SIP/trunk1/${EXTEN})
  exten => _X.,n,Hangup

In case the trunk1 replies "SIP/2.0 503 Service Unavailable" Asterisk uses
the same SIP code to reply upstream. Asterisk shouldn't do it and MUST
convert that 503 into 500.

503 means that a client receiving it should try the same request against
an alternate server (got via DNS SRV and so).

This is "clearly" defined is 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.
-----------------------

Since Asterisk keep the 503 and replies it to the client, Asterisk breaks
the SIP failover mechanism, since it forces a client to contact an
alternate server when it's not needed at all (Asterisk is still alive and
working).

The correct behaviour is easy: When Asterisk receives a 503 from leg_B it
must convert it to 500 in leg_A.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014653 Never reply 503, use 500 instead (don't...
====================================================================== 

---------------------------------------------------------------------- 
 (0109600) dvossel (administrator) - 2009-08-25 11:29
 https://issues.asterisk.org/view.php?id=14644#c109600 
---------------------------------------------------------------------- 
I'm going to post here exactly what I did for issue
https://issues.asterisk.org/view.php?id=14653.

"I understand the issue, and I understand where your concern is coming
from, but changing all 503 errors 500 errors in chan_sip is not a good
idea... If it was only SIP that we were concerned about this might be
different, but its not.  SIP talks to ISDN and other channels, and in many
cases a congestion frame should be translated into a 503 error and sent
out.  There is a dialplan solution for this however.  If you understand
your setup enough to know a 503 error should not be forwarded, changing the
hangup cause in the dialplan, ${HANGUPCAUSE}, from AST_CAUSE_CONGESTION or
AST_CAUSE_SWITCH_CONGESTION to AST_CAUSE_FAILURE will convert the 503 to a
500 error." 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-25 11:29 dvossel        Note Added: 0109600                          
2009-08-25 11:29 dvossel        Status                   assigned => closed  
======================================================================