it happens only when they return 480
I’m thinking, could this be SIP ALG issue?
Asterisk is also indicating NO ANSWER, as the hangup cause, which should have been translated to 480.
However the 181 is totally weird. I can’t see that being sent unless the AGI script is doing something weird, My guess is that you’ve got some sort of mixed up status as a result of a failed attempt redirect the call within the script.
I also note that the dialplan Hangup isn’t being executed, which means that the AGI script has already hung up the channel.
At the moment, I would say this should be treated as an a2billing problem not an Asterisk one.
(Does a2billing possibly use a customised Asterisk?)
Nope. I am going with A2Billing issue as well, as Asterisk is what is generating the 181 on receiving a 480.
a2billing.php appears to be a very large script, spread over 11 files, and which hasn’t been touched in over a decade. I doubt that anyone is going to be able to sensibly address this in a reasonable amount of time unless they are already familiar with its internals.
talking of a2billing.php, I have another link that returns SIP 480, same a2billing and asterisk version is running on both. only difference is that this is connected to provider using E1 (dahdi). now, I want to copy it’s working a2billing.php and see if it works.
That would mean there is no 480 SIP Code because DAHDi isn’t SIP. That would be Asterisk taking the DAHDi response and converting to a SIP Code to send to the SIP based device. I mean you could try to copy the file over, no guarantees.
meanwhile, is there a way to perform code mapping here? something like mapping SIP 486 to SIP 480?
There might be a way but this is old versions of Asterisk/chan_sip and it involves A2Billing. This is something you’re going to have to bring up in the A2Billing community.
As I said, it appears the hangup is being done in the AGI script, which means we don’t know where you could intervene to modify the code. If control had been returned to the dialplan, you would have had some control of what was fed to hangup.
Hangup causes are ISDN cause codes, so, in the E1 case, you would have been passing the 19 code with no translations.
Something that is confusing me here is that the 19 code is included in the 486 response. chan_sip has a table for converting the ISDN causes to SIP status codes, and 19 does map to 480:
case AST_CAUSE_NO_ANSWER: /* 19 */
case AST_CAUSE_UNREGISTERED: /* 20 */
return "480 Temporarily unavailable";
with the inverse being:
case 480:|/* No answer */|
return AST_CAUSE_NO_ANSWER;|
(Code extracts from 13.38, as the security fix sub-versions don’t seem to be on github.)
It would appear though, that chan_sip doesn’t use the standard lookup logic for 480. It basically looks wrong to me, but as chan_sip is about to be removed, is only community supported, and has no current maintainer, I can’t see that getting fixed, even if people agree that it is wrong. It would appear that in trying to capture the reason string from the response, some strange decisions have been made, which result in a bogus redirecting event being generated, hence the 181, and ast_indicate(AST_CONTROL_BUSY) being invoked, which will cause the other chan_sip channel to generate 486.
This is not consistent with RFC 3398, which says that 480 should map to ISDN 18 and 18 should map to 408 (not 480).
I don’t know what the supported driver, chan_pjsip, does for this.
I think you still have a problem that a2billing seems to actually hanging up the channel in response to the busy, as the dialplan hangup isn’t shown as being reached in your logs, so you can’t manipulate the hangup cause.
case 480: /* Temporarily unavailable. */
/* RFC 3261 encourages setting the reason phrase to something indicative
* of why the endpoint is not available. We will make this readable via the
* redirecting reason.
*/
xmitres = transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, FALSE);
append_history(p, "TempUnavailable", "Endpoint is temporarily unavailable.");
if (p->owner && !req->ignore) {
struct ast_party_redirecting redirecting;
struct ast_set_party_redirecting update_redirecting;
char *quoted_rest = ast_alloca(strlen(rest) + 3);
ast_party_redirecting_set_init(&redirecting, ast_channel_redirecting(p->owner));
memset(&update_redirecting, 0, sizeof(update_redirecting));
redirecting.reason.code = ast_redirecting_reason_parse(rest);
if (redirecting.reason.code < 0) {
sprintf(quoted_rest, "\"%s\"", rest);/* Safe */
redirecting.reason.code = AST_REDIRECTING_REASON_UNKNOWN;
redirecting.reason.str = quoted_rest;
} else {
redirecting.reason.str = "";
}
ast_channel_queue_redirecting_update(p->owner, &redirecting, &update_redirecting);
ast_queue_control(p->owner, AST_CONTROL_BUSY);
}
break;
Thank you for your directions, I changed the value in busy_timeout of my agi-conf in a2billing from 1 to 0 and got 480 this time.
thank you for your guide.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.