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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14644 
====================================================================== 
Reported By:                ibc
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14644
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
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-11 11:08 CDT
Last Modified:              2009-03-17 06:09 CDT
====================================================================== 
Summary:                    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...
====================================================================== 

---------------------------------------------------------------------- 
 (0101854) amilcar (reporter) - 2009-03-17 06:09
 http://bugs.digium.com/view.php?id=14644#c101854 
---------------------------------------------------------------------- 
@ibc: You missed the whole point, I guess. I'm not saying that is correct
to use 480 in all cases. What I'm saying is, because of the architecture of
asterisk, all calls that end on a CHANUNAVAIL or CONGESTION status will
return 503 to the endpoint. That's incorrect, and I use the chan_dahdi
example to show a very common case that many hangup causes are simply
transformed into a 503.

There are many other examples: try to dial to a non-existant SIP channels.
Asterisk will return cause "20 - absent", and 503 to endpoint. Try calling
with libpri to a number and that returns causes 1, 3 or 20, for example....
In all cases, endpoint will receive 503. That's cleary incorrect. According
to RFC3398, cause 21 should return 403, causes 1, 3 should return 404,
cause 20 should return 480, etc... And you're wrong about 480 maeaning only
that the user rejected the call or has DND enabled.

I'm not saying that is correct using 480 in all AST_CONTROL_CONGESTION
cases. All I'm saying is that is not correct returning 503 to all
AST_CONTROL_CONGESTION cases (there are cases for 503, like the cases when
SIP DNS failover applies).

And in the strict sense of SIP specifications, your bug report is
incorrect anyway, According to RFC:

21.5.4 503 Service Unavailable

   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.

Every 503 WITHOUT "Retry-After" MUST be treated as a 500. So, the whole
point of changing 503 to 500 is useless. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-17 06:09 amilcar        Note Added: 0101854                          
======================================================================