[asterisk-dev] chan_sip: Hook flash events

[phreak at phreaknet.org]

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 at 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