[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-16 09:18 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0101794) ibc (reporter) - 2009-03-16 09:18
 http://bugs.digium.com/view.php?id=14644#c101794 
---------------------------------------------------------------------- 
@amilcar: Your solution (using 480) is just valid for your case and it's
not a correct approach since it *breaks* SIP DNS failover.
If Asterisk has to dial via PRI, "Dial" is the last application, and all
the PRI channels are used then Asterisk MUST reply 503 so the UA would try
other server (if it's present in SRV resolution). That's the correct
behaviour. Yours is like a hack for your specific case (no DNS SRV failover
and a client wrongly assumming 60 seconds of waiting after a 503 with no
reason for that).

480 means "User not available now". This reply occurs often when the
called rejects the call, or has DND enabled. It's also replies by gateways
when the caller doesn't answer a call in 60 seconds. But in this report we
are speaking about SIP SRV failover and the fact that Asterisk *cannot*
process the call due to internal failure/issue (as all the PRI channels
busy is).

I think SIP specifications and standars whould be above of particular
escenarios. Regards. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-16 09:18 ibc            Note Added: 0101794                          
======================================================================