Summary: | ASTERISK-13736: Never reply 503, use 500 instead (don't break DNS SRV failover) | ||
Reporter: | Iñaki Baz Castillo (ibc) | Labels: | |
Date Opened: | 2009-03-12 06:18:22 | Date Closed: | 2011-06-07 14:03:17 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | As reported in bug ASTERISK-13728, 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 ASTERISK-13728: "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). | ||
Comments: | By: Iñaki Baz Castillo (ibc) 2009-03-12 06:57:57 Other correct case in which Asterisk should reply 503 in when exceeding the maximun number of channels defined in asterisk.conf ("maxcalls" option). By: Mark Michelson (mmichelson) 2009-03-13 15:50:22 I can think of a couple of other cases where a 503 would be appropriate: 1. If there is some sort of internal failure while processing a message (such as a memory allocation failure or failure to masquerade channels) then a 503 seems appropriate. 2. If Asterisk is in the process of shutting down, sending a 503 would be appropriate. By: Iñaki Baz Castillo (ibc) 2009-03-16 03:51:07 Yes, these are two good cases to reply 503. By: David Vossel (dvossel) 2009-08-25 11:28:10 I understand the issue, and I understand where your concern is coming from, but changing all 503 errors 500 errors in chan_sip is not a good idea... If it was only SIP that we were concerned about this might be different, but its not. SIP talks to ISDN and other channels, and in many cases a congestion frame should be translated into a 503 error and sent out. There is a dialplan solution for this however. If you understand your setup enough to know a 503 error should not be forwarded, changing the hangup cause in the dialplan, ${HANGUPCAUSE}, from AST_CAUSE_CONGESTION or AST_CAUSE_SWITCH_CONGESTION to AST_CAUSE_FAILURE will convert the 503 to a 500 error. |