[asterisk-bugs] [JIRA] (ASTERISK-29370) chan_sip does not recognize application/hook-flash
Asterisk Team (JIRA)
noreply at issues.asterisk.org
Wed Oct 13 06:05:56 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Asterisk Team updated ASTERISK-29370:
-------------------------------------
Target Release Version/s: 19.0.0
> chan_sip does not recognize application/hook-flash
> --------------------------------------------------
>
> Key: ASTERISK-29370
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29370
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/General
> Affects Versions: 18.2.0
> Environment: Debian 10
> Reporter: N A
> Assignee: N A
> Labels: patch
> Target Release: 16.19.0, 18.5.0, 19.0.0
>
> Attachments: flashdiff.patch
>
>
> Every time I send a hook flash event on one of my ATAs (SIP INFO), it sends an application/hook-flash to Asterisk that would always result in two WARNINGs about it being unrecognized. I noticed there was code in chan_sip to handle the 16 flash event code, so I tried debugging to see if I could fix that.
> Actually, it seems the problem here is that the headers for the event are not coming in correctly, and I'm not entirely sure why. I added some lines to print out some of the information it's getting, and it's definitely not right:
> I don't know how much this is actually related to the flashing issue, but in any case, there seems to be something rather off with the sip_get_header function or how it gets used.
> Here is the code I added - notice that Content-Type seems to be getting read as Content-Length, since they are the same, and match up with the info in the sip debug:
> const char *c2 = sip_get_header(req, "Content-Length");
> ....
> ast_log(LOG_WARNING, "Event: %d, Content Type: %s\n", event, c); //nav
>
> // 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;
> }
> Ignore the weird if conditional, that was just for testing and isn't right at all.
> Also, notice that the "event" is the content length and that the "content type" is some number around 32,000 that keeps incrementing slightly. It increases every time Asterisk restarts. Not sure what this is, but I don't think it's the content type. This leads me to believe that Asterisk is getting all the wrong headers for this SIP info packet.
> Here is a SIP debug that demonstrates the issue:
> [Mar 26 09:20:50] <--- SIP read from TLS:PUBLIC-IP-REDACTED:37654 --->
> [Mar 26 09:20:50] INFO sip:01 at SERVER-IP-REDACTED:SERVER-PORT-REDACTED;transport=tls SIP/2.0
> [Mar 26 09:20:50] Via: SIP/2.0/TLS 192.168.10.106:38967;branch=z9hG4bK170601491;rport
> [Mar 26 09:20:50] From: "ATAx4" <sip:ATAx4 at SERVER-IP-REDACTED:SERVER-PORT-REDACTED>;tag=2050706533
> [Mar 26 09:20:50] To: <sip:01 at SERVER-IP-REDACTED:SERVER-PORT-REDACTED>;tag=as16838c32
> [Mar 26 09:20:50] Call-ID: 358973344-38967-17 at BJC.BGI.BA.BAG
> [Mar 26 09:20:50] CSeq: 132 INFO
> [Mar 26 09:20:50] Contact: <sip:ATAx4 at 192.168.10.106:38967;transport=tls>
> [Mar 26 09:20:50] Max-Forwards: 70
> [Mar 26 09:20:50] Supported: replaces, path, timer, eventlist
> [Mar 26 09:20:50] User-Agent: Grandstream HT704 1.0.10.3
> [Mar 26 09:20:50] Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
> [Mar 26 09:20:50] Content-Type: application/hook-flash
> [Mar 26 09:20:50] Content-Length: 9
> [Mar 26 09:20:50]
> [Mar 26 09:20:50] signal=hf
> [Mar 26 09:20:50] <------------->
> [Mar 26 09:20:50] --- (13 headers 1 lines) ---
> [Mar 26 09:20:50] Receiving INFO!
> [2021-03-26 09:20:50] WARNING[13835][C-00000003]: chan_sip.c:22804 handle_request_info: Event: 0, Content Type: 9 Content Length: 9
> [2021-03-26 09:20:50] WARNING[13835][C-00000003]: chan_sip.c:22821 handle_request_info: Unable to parse INFO message from 358973344-38967-17 at BJC.BGI.BA.BAG. Content
> [Mar 26 09:22:27] <--- SIP read from TLS:PUBLIC-IP-REDACTED:5072 --->
> [Mar 26 09:22:27] INFO sip:01 at SERVER-IP-REDACTED:SERVER-PORT-REDACTED;transport=tls SIP/2.0
> [Mar 26 09:22:27] Via: SIP/2.0/TLS 192.168.10.105:5072;branch=z9hG4bK-17e5ecf8
> [Mar 26 09:22:27] From: "ATAxLB1" <sip:ATAxLB1 at SERVER-IP-REDACTED>;tag=66280aa944f70150o0
> [Mar 26 09:22:27] To: <sip:01 at SERVER-IP-REDACTED>;tag=as598b9104
> [Mar 26 09:22:27] Call-ID: 7451d45d-33d6a32c at 192.168.10.105
> [Mar 26 09:22:27] CSeq: 102 INFO
> [Mar 26 09:22:27] Max-Forwards: 70
> [Mar 26 09:22:27] User-Agent: Linksys/SPA2102-5.2.13(004)
> [Mar 26 09:22:27] Content-Length: 11
> [Mar 26 09:22:27] Content-Type: application/hook-flash
> [Mar 26 09:22:27]
> [Mar 26 09:22:27] Signal=hf
> [Mar 26 09:22:27] <------------->
> [Mar 26 09:22:27] --- (10 headers 1 lines) ---
> [Mar 26 09:22:27] Receiving INFO!
> [2021-03-26 09:22:27] WARNING[13774][C-00000004]: chan_sip.c:22804 handle_request_info: Event: 0, Content Type: 11 Content Length: 11
> [2021-03-26 09:22:27] WARNING[13774][C-00000004]: chan_sip.c:22821 handle_request_info: Unable to parse INFO message from 7451d45d-33d6a32c at 192.168.10.105. Content
> In theory, I could try to work with what I'm getting here and patch chan_sip so it recognizes these as a hook flash event, but the variables are all wrong so I think that would be a bit nonsensical since this is indicative of some other larger issue. I am not familiar with the rest of chan_sip, so I am reporting this, and I would like to see if I can get the hook flashes recognized once I have the proper headers to work with.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list