[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-14 09:13 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0101770) amilcar (reporter) - 2009-03-14 09:13
 http://bugs.digium.com/view.php?id=14644#c101770 
---------------------------------------------------------------------- 
I have the same issue here, but with another consequences.

If I make a call from a softphone (X-Lite or Eyebeam, in my case) to a
number that is going to use a DAHDI PRI link, for example, most failure
causes are translated into AST_CONTROL_CONGESTION. Look at the code below:

case PRI_CAUSE_CALL_REJECTED:
case PRI_CAUSE_NETWORK_OUT_OF_ORDER:
case PRI_CAUSE_NORMAL_CIRCUIT_CONGESTION:
case PRI_CAUSE_SWITCH_CONGESTION:
case PRI_CAUSE_DESTINATION_OUT_OF_ORDER:
case PRI_CAUSE_NORMAL_TEMPORARY_FAILURE:
    pri->pvts[chanpos]->subs[SUB_REAL].needcongestion =1;
    break;

And, as it is now,  if chan_dahdi returns AST_CONTROL_CONGESTION, chan_sip
will than return "503 Service unavailable" to the softphone. That's
absolutely wrong answer in any of the pri causes.

Weel, after this answer (503), the softphone can't dial anywhere in the
next 60 seconds (according to RFC: "It SHOULD NOT forward any other
requests to that server for the duration specified in the Retry-After
header field, if present.", so the Retry-Asfter header is not present, and
x-lite have a default of 60 seconds).

Conclusion, the phone will be stucked and can't dial anywhere else (other
good extensions, for example) after any PRI cause that generates a
AST_CONTROL_CONGESTION in reply.

My solution to this is exactly the same patch that mmichelson have
uploaded, but instead using "500 Service unavailable", I use "480
Temporarily unavailable", and everything works fine (i can make any calls
after that PRI causes). After all, the PRI cause that chan_dahdi received
is about THAT particular call, not every other calls, neither is a problem
in asterisk. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-14 09:13 amilcar        Note Added: 0101770                          
======================================================================