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

Tue Mar 17 06:29:25 CDT 2009

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:29 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0101856) ibc (reporter) - 2009-03-17 06:29
 http://bugs.digium.com/view.php?id=14644#c101856 
---------------------------------------------------------------------- 
@amilcar:

> 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).

That's *exactly* what I mean. I opened a new bug for it:
http://bugs.digium.com/view.php?id=14653.

> And you're wrong about 480 maeaning only that the user rejected the call
or
> has DND enabled.

480 can mean:
- The user is note registered (reply from its proxy).
- The user rejects the call (by pressing "Reject" or with DND enabled).
- A gateway terminates a ringing call after 60 seconds since in that time
the callee didn't answer, so replies 480 upstream (I've seen it in some
softswitches).
Probably there are more cases for 480 (one of the worst specifications in
RFC 3261), but I think this is not the point here.

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

That's clearly another bad and ambiguous specification in RFC 3261, and I
agree on the fact that it can cause confussion.

RFC 3263 says clearly:
-----------
4.3 Details of RFC 2782 Process
   [...]
   For SIP requests, failure occurs if the transaction layer reports a
   503 error response or a transport failure of some sort (generally,
   due to fatal ICMP errors in UDP or connection failures in TCP).
   Failure also occurs if the transaction layer times out without ever
   having received any response, provisional or final (i.e., timer B or
   timer F in RFC 3261 [1] fires).  If a failure occurs, the client
   SHOULD create a new request, which is identical to the previous, but
   has a different value of the Via branch ID than the previous (and
   therefore constitutes a new SIP transaction).  That request is sent
   to the next element in the list as specified by RFC 2782.
-----------

Also RFC 3261 says:
------------
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.
------------

I understand what you mean, it also says "If no Retry-After is given, the
client MUST act as if it had received a 500 (Server Internal Error)
response." But I think it doesn't invalidate the next paragraphs about
failover.

I'm opening a thread in sip-implementors about it:

https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-March/022102.html

However I think we agree on the basics: Asterisk shouldn't reply 503 in
lots of cases :)

Thanks for your comments.
PD: Perhaps we could continue this discussion in bug
http://bugs.digium.com/view.php?id=14653. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-17 06:29 ibc            Note Added: 0101856                          
======================================================================