[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:                 reopened
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-03-11 11:08 CDT
Last Modified:              2009-08-26 12:20 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0109691) dvossel (administrator) - 2009-08-26 12:20
 https://issues.asterisk.org/view.php?id=14644#c109691 
---------------------------------------------------------------------- 
"So, not all the 503 should be translated into 500, but some should
(IMHO)."

I agree, and I'm not saying you're wrong.

What we're dealing with here is a side effect of Asterisk being a
multi-protocol system.  Every error has to go from protocol specific, into
generic Asterisk land, and then back to protocol specific. That way, it
doesn't matter what is on each end.  The problem here is that lots of
errors in all kinds of channel drivers can get lumped into the generic
CONGESTION frame.  Chan_sip has no idea why CONGESTION was sent to it, it
just knows that should result in a 503 response, and in most cases this is
probably correct, but you have found a situation in which it is not.  We
understand this and that's why ISDN cause codes and HANGUP cause codes are
available in the dialplan.  You can change the generic mapping to be
anything you want via the dialplan.  If you want all AST_CAUSE_CONGESTION
causes to be mapped to AST_CAUSE_FAILURE, this will force sip to respond
respond with a 500 instead of a 503.

so here's the break down.
When sip gets a 503 it maps that to CONGESTION, it doesn't know what the
other side is.  When sip gets CONGESTION from Asterisk it maps that to a
503, and it doesn't know what the other side is.  If we changed that
mapping to be anything else, it would mess up how sip talks with other
channel drivers, but would resolve the single issue you are having.  We
simply can not do this, especially when there are valid workarounds in the
dialplan.

I'm closing the issue, but that doesn't mean it should not be discussed
further.  We're open for proposals for architecture changes on how this
stuff works.  If you have any ideas, please pursue them on the -dev list. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-26 12:20 dvossel        Note Added: 0109691                          
2009-08-26 12:20 dvossel        Status                   assigned => closed  
======================================================================