[asterisk-bugs] [JIRA] (ASTERISK-29370) chan_sip header parsing sometimes broken
Asterisk Team (JIRA)
noreply at issues.asterisk.org
Fri Mar 26 08:34:15 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=254331#comment-254331 ]
Asterisk Team commented on ASTERISK-29370:
------------------------------------------
Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.
A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.
Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
> 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
> 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