[Home]

Summary:ASTERISK-08355: chan_sip does not handle 504 "Service Unavailable" case
Reporter:wiseoldowl (wiseoldowl)Labels:
Date Opened:2006-12-14 18:51:12.000-0600Date Closed:2006-12-15 04:59:02.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Problem:  When a Sipura SPA-3000 is already handling a call on its PSTN port and you attempt to place another call through it, versions with newer firmware (specifically Linksys/SPA3000-3.1.10(GWd)) return the following error:

504 "Service Unavailable"

(Apparently older versions of the firmware returned 503 rather than 504, which Asterisk does handle properly).

When the 504 code is returned, Asterisk hangs up the call rather than rejecting it with congestion so that other outbound trunks are used.





****** ADDITIONAL INFORMATION ******

Here is an edited transcript of a discussion I had with JT in the #asterisk channel regarding this problem. We agree that it would be better if the Sipura returned 503 as it used to, but also feel that Asterisk could handle the 504 case more gracefully:
{{{
(05:57:32 PM) wiseoldowl: This may seems like a strange question, but does anyone know how Asterisk is coded to react when, on an outgoing call, a SIP device returns 504 "Service Unavailable" ?
(05:59:19 PM) JT: wiseoldowl: case 503:       /* Service unavailable */
(05:59:20 PM) JT:                         return AST_CAUSE_CONGESTION;
(05:59:36 PM) JT: sorry, 504
(05:59:46 PM) JT: no idea
(05:59:54 PM) JT: 504 isn't in chan_sip
(06:00:26 PM) wiseoldowl: Okay, I ask because that's what a Sipura 3000 returns when it's in use (in the latest firmware)
(06:00:40 PM) JT: what happens with asterisk?
(06:00:54 PM) wiseoldowl: It hangs up
(06:01:06 PM) JT: do you know what 504 is?
(06:01:33 PM) wiseoldowl: Nope, just that the Sipura consistently sends it when it is in use
(06:02:14 PM) JT: 504 Server Time-out
(06:02:20 PM) JT: acording to wikipedia
(06:02:28 PM) wiseoldowl: Specifically when it's in use for a call and you attempt to send it another call.
(06:02:49 PM) JT: i think 504 is the wrong response then
(06:02:54 PM) wiseoldowl: Okay, so shouldn't Asterisk treat that as congestion?
(06:03:29 PM) JT: wiseoldowl: well 504 is not in chan sip
(06:03:35 PM) JT: looks like a bug in chan sip actually
(06:03:47 PM) JT: wiseoldowl: as you'd be getting   default:
(06:03:47 PM) JT:                         return AST_CAUSE_NORMAL;
(06:03:55 PM) JT: normal hangup cause
(06:04:01 PM) JT: and it's clearly not normal
(06:04:11 PM) JT: wiseoldowl: maybe you should consider filing a bug
.....
(06:06:21 PM) JT: wiseoldowl: i ALSO think it is a bug in the sipura
(06:06:25 PM) JT: wiseoldowl: which model is it
(06:06:38 PM) JT: wiseoldowl: 504 is the wrong cause code for no channels available
(06:06:45 PM) JT: however, asterisk should cater for it anyway
(06:07:11 PM) wiseoldowl: Sipura 3000  sip packet returns Server: Linksys/SPA3000-3.1.10(GWd)
(06:07:23 PM) JT: wiseoldowl: ah ok
(06:07:33 PM) wiseoldowl: And that is the latest firmware, we just re-flashed it yesterday.
(06:07:41 PM) JT: wiseoldowl: check with the latest firmware, and if it still sends a 504, file a bug with sipura too
(06:08:03 PM) wiseoldowl: The problem it causes is when the call fails then no other trunks are checked.
(06:08:13 PM) JT: wiseoldowl: indeed
(06:09:09 PM) JT: wiseoldowl: imho, asterisk should not return NORMAL call clearing on any 500 series code
(06:09:17 PM) wiseoldowl: Will try doing that but Sipura is really bad about fixing bugs on older models (I've had a bug report in with them for six months that they more or less acknowledged was a bug, but still have never fixed).
(06:09:34 PM) wiseoldowl: I would think not either.
(06:10:46 PM) wiseoldowl: And that is definitely the latest firmware, we downloaded it off Sipura's site yesterday afternoon, so unless they came out with an upgrade in the last 24 hours, that's it.
(06:11:38 PM) wiseoldowl: Thanks again JT
}}}
Comments:By: Olle Johansson (oej) 2006-12-15 04:58:50.000-0600

Fix commited to 1.2 (rev 48484), 1.4 rev 48487, trunk rev 48488.

Thanks!

/O