[asterisk-bugs] [JIRA] (ASTERISK-29370) chan_sip header parsing sometimes broken
N A (JIRA)
noreply at issues.asterisk.org
Fri Mar 26 08:46:15 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=254333#comment-254333 ]
N A commented on ASTERISK-29370:
--------------------------------
I realize hook-flash is not supported, and I think you told me that before. Unfortunately, all my ATAs send application/hook-flash, not application/dtmf 16 for some reason. It should be trivial to add logic to support this, and if Digium is not going to do it, then I will and have no problem with adding the feature. However, right now the problem is that the headers are not even coming in right. I can see the correct headers in a SIP debug, but when I print them out, I am getting nonsensical values (different headers). Once this works right, I could simply add an if (application/hookflash) { do the same thing as the 16 flash code }.
So, are you saying that sip_get_header is not currently capable of parsing "application/hook-flash", and that would need to be updated to add this? That is, sip_get_header is not capable of getting any arbitrary header sent, it needs to be part of some "whitelist"?
> chan_sip header parsing sometimes broken
> ----------------------------------------
>
> 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
> Severity: Major
>
> 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