Hello,
Recently, I have been trying to fix chan_sip so that hook flash
events, using either SIP INFO "16" or RFC 2833 work correctly. Whenever
I've tried these in the past, I've just seen an warning in the console,
meaning the events are getting to Asterisk but somehow they are not
being handled properly.
I dug into chan_sip.c and found this on line 22,685:
if (event == 16) {
/* send a FLASH event */
struct ast_frame f = { AST_FRAME_CONTROL, {
AST_CONTROL_FLASH, } };
ast_queue_frame(p->owner, &f);
if (sipdebug) {
ast_verbose("* DTMF-relay event received: FLASH\n");
}
}
ast_log(LOG_WARNING, "Event: %d, Content Type: %s\n", event, c);
It seems like chan_sip is *supposed* to support flash events, but for
some reason, the flash events from the ATAs I was testing never got
here. As a test, I printed out c and event and found that c was 32731
and event was 9. Actually, it's more complicated than that. I got 9 when
I tested on a Grandstream ATA but 11 when I tested on a Linksys ATA.
I added the following patch to chan_sip and recompiled to test this out:
// handle SIP INFO flash events from Grandstream, previously e.g.
handle_request_info: Unable to parse INFO message from
85538d91-ae288b51@192.168.10.105. Content
// always turns out that: buffer is empty, c is 32731, and event is
11 on Linksys ATA and 9 on Grandstream
if (!strcasecmp(c, "32731" && (event == 9 || event == 11))) {
/* send a FLASH event */
struct ast_frame f = { AST_FRAME_CONTROL, { AST_CONTROL_FLASH, } };
ast_queue_frame(p->owner, &f);
//if (sipdebug) {
ast_verbose("* DTMF-relay event received: FLASH\n");
//}
transmit_response(p, "200 OK", req);
return;
}
It didn't work, because c turned out to be 32743. This was consistent
with both ATAs and in multiple calls. I restarted Asterisk and c was now
consistently 32751, so it seems like c is getting incremented each time
Asterisk starts. I thought this was a bit odd as ln. 22624 says c is
supposed to be the Content-Type header. I'm printing c as a string, so
I'm led to believe it really is an integer for some reason.
I haven't done a whole lot with Asterisk source code before besides
minor patches, so would someone be able to shed some light on this? I'm
looking for a reliable way to pinpoint these flash events that are
getting missed so I can execute the same code as it would if it had
gotten a "16" event, but somehow the goalposts keep moving. I'm not
saying it's not the ATAs' fault, but I'd need to find a way to
accommodate them in Asterisk.
TL; DR - c keeps changing, but event is consistently 9 for one ATA and
11 for the other.
Also, I'm assuming that the if (event == 16) is there to do this in the
first place, so I'm not sure if I'm adding something or it's that which
is broken in the first place. I may have missed something here.
Any insights or thoughts on this appreciated. waitstream_core:
Unexpected control subclass '9' seems to be the error in file.c for
RFC2833/AVT flash events, but I figured I'd focus on this first.
Thanks!
NA
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
