[asterisk-bugs] [JIRA] (ASTERISK-29370) chan_sip header parsing sometimes broken
N A (JIRA)
noreply at issues.asterisk.org
Fri Mar 26 10:51:15 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=254344#comment-254344 ]
N A commented on ASTERISK-29370:
--------------------------------
Ah, so the Local channel will propagate it, but be unable to inherently do anything with it? That is, keep propagating until it exists Asterisk to some other device, if it does at all?
Something promising seemed to be something like: astman_send_ack(s, m, "Hook Flash Received"); I can see astman_send_err being used in chan_sip.c, but I need an s and an m to pass in as arguments, and it seems these only are present in functions intended to be called from AMI (e.g. AMI to a SIP peer). So, the opposite of what I'm looking for.
This from manager_channels.c appears to be similar to exactly what I need:
manager_event(EVENT_FLAG_DTMF, "DTMFBegin",
"%s"
"Digit: %s\r\n"
"Direction: %s\r\n",
ast_str_buffer(channel_event_string),
digit, direction);
What's funny is the comment here is: <para>DTMF digit received or transmitted (0-9, A-E, # or *</para>. Not sure what "E" could be if it wasn't "Flash". Typo? Not sure what to think.
However, only ast_manager_event_blob and ast_manager_event_blob_create are present in chan_sip.c, related to a static struct that's globally defined.
chan_sip #includes manager.h, which does #define manager_event(), so it looks like I might be able to call it directly. I'm assuming the manager library takes care of including the channel the event was raised on for me.
manager.h defines EVENT_FLAG_DTMF as (1 << 8):
#define EVENT_FLAG_SYSTEM (1 << 0) /* System events such as module load/unload */
#define EVENT_FLAG_CALL (1 << 1) /* Call event, such as state change, etc */
#define EVENT_FLAG_LOG (1 << 2) /* Log events */
#define EVENT_FLAG_VERBOSE (1 << 3) /* Verbose messages */
#define EVENT_FLAG_COMMAND (1 << 4) /* Ability to read/set commands */
#define EVENT_FLAG_AGENT (1 << 5) /* Ability to read/set agent info */
#define EVENT_FLAG_USER (1 << 6) /* Ability to read/set user info */
#define EVENT_FLAG_CONFIG (1 << 7) /* Ability to modify configurations */
#define EVENT_FLAG_DTMF (1 << 8) /* Ability to read DTMF events */
#define EVENT_FLAG_REPORTING (1 << 9) /* Reporting events such as rtcp sent */
#define EVENT_FLAG_CDR (1 << 10) /* CDR events */
#define EVENT_FLAG_DIALPLAN (1 << 11) /* Dialplan events (VarSet, NewExten) */
#define EVENT_FLAG_ORIGINATE (1 << 12) /* Originate a call to an extension */
#define EVENT_FLAG_AGI (1 << 13) /* AGI events */
#define EVENT_FLAG_HOOKRESPONSE (1 << 14) /* Hook Response */
#define EVENT_FLAG_CC (1 << 15) /* Call Completion events */
#define EVENT_FLAG_AOC (1 << 16) /* Advice Of Charge events */
#define EVENT_FLAG_TEST (1 << 17) /* Test event used to signal the Asterisk Test Suite */
#define EVENT_FLAG_SECURITY (1 << 18) /* Security Message as AMI Event */
/*XXX Why shifted by 30? XXX */
#define EVENT_FLAG_MESSAGE (1 << 30) /* MESSAGE events. */
So, I'm assuming I would need something like #define EVENT_FLAG_FLASH (1 << 19) /* Hook flash as AMI event */
And then in manager.c, add:
{ EVENT_FLAG_FLASH, "flash" },
Does any of this sound off?
> 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
>
> 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