[asterisk-bugs] [Asterisk 0014653]: Never reply 503, use 500 instead (don't break DNS SRV failover)
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Aug 25 11:28:11 CDT 2009
The following issue has been UPDATED.
======================================================================
https://issues.asterisk.org/view.php?id=14653
======================================================================
Reported By: ibc
Assigned To: dvossel
======================================================================
Project: Asterisk
Issue ID: 14653
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: no change required
Fixed in Version:
======================================================================
Date Submitted: 2009-03-12 06:18 CDT
Last Modified: 2009-08-25 11:28 CDT
======================================================================
Summary: Never reply 503, use 500 instead (don't break DNS
SRV failover)
Description:
As reported in bug https://issues.asterisk.org/view.php?id=14644, Asterisk
shouldn't reply 503 to the client since
a 503 forces a client to contact an alternate server when it's not needed
at all (Asterisk is still alive and working).
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.
-----------------------
As mmichelson tells in https://issues.asterisk.org/view.php?id=14644:
"It appears there are several response codes which Asterisk translates
into
an AST_CONTROL_CONGESTION frame and then queues onto the channel. When
the
other side reads this AST_CONTROL_CONGESTION frame, if it is a SIP
channel,
it will send a 503."
I propose to replace ALL the 503 replies in chan_sip.c to 500. Asterisk
should *never* reply a 503 except in the case Asterisk *does* know it is
not working properly, and AFAIK there is no way in Asterisk to know it.
Replying 503 breaks SIP DNS SRV failover (RFC 3263) so 500 would be a more
appropiate response code.
For example, OpenSer/Kamailio/OpenSIPS proxy converts a 503 from
downstream into a 500 upstream. If a proxy/PBX replies 503 to a client it
is the same as saying "don't use me, try other server".
Asterisk should reply 503 in some cases, for example after a Dial through
a E1/T1 trunk with no avaliable channels. Then, the caller would receive
the 503 and try other server. In this case a 503 is correct (so probably an
agressive "sed 's/503/500/g'" in all chan_sip.c would break it).
Is it feasible? I think Asterisk shouldn't convert so many response codes
into AST_CONTROL_CONGESTION, but use something as AST_INTERNAL_ERROR which
is translated into "SIP 500" while AST_CONTROL_CONGESTION is translated
into "SIP 503" (as now).
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0014644 [patch] Asterisk should transform SIP 5...
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2009-08-25 11:28 dvossel Resolution open => no change
required
======================================================================
More information about the asterisk-bugs
mailing list