Unrecognized Option: 'X' after call is answered

Asterisk Asterisk Dialplan
1

Whenever a call is answered I am seeing a message like this in the logs:

[Jun 13 14:10:16] WARNING[15913][C-0000006b]: app.c:3114 parse_options: Unrecognized option: 'X'

I can’t find what’s the cause of this, apparently somewhere that option is set but I don’t have a clue where that might be.

1 Like
2

It’s set on the command line of the application that your dialplan is trying to run, and which should be visible in the logs, if you have verbosity at, at least, 3.

3

That was of course the first thing I tried (setting debug and verbose to maximum), and while I see a bunch of “Executing xxxx” messages none of them contain the X-Option. The last thing that is being executed is a dial-command (Dial("PJSIP/MyPhone-000001eb", "PJSIP/12345@MyProvider,,TK") and then there is nothing until the call is answered, where the abovementioned message is logged after the call is answered but before the channels are joining the bridge.

4

In that case, I can’t help you, but I do note you haven’t said which version.

5

Thanks, I forgot to mention that. I am currently on Asterisk 20.2.0, but I was on 19.x before and the issue was there aswell.

6

I’d suggest providing a complete log, instead of two lines.

7 
  == Using SIP RTP Audio TOS bits 184
  == Using SIP RTP Audio TOS bits 184 in TCLASS field.
    -- Executing [0123456@main:1] Macro("PJSIP/MyPhone-000001fc", "DialStartMonitor,123456") in new stack
    -- Executing [s@macro-DialStartMonitor:1] Set("PJSIP/MyPhone-000001fc", "MONITOR_FILENAME=20230614-190954-FROM-1234-TO-123456") in new stack
    -- Executing [s@macro-DialStartMonitor:2] Monitor("PJSIP/MyPhone-000001fc", "wav,20230614-190954-FROM-1234-TO-123456,bm") in new stack
    -- Executing [0123456@main:2] Dial("PJSIP/MyPhone-000001fc", "PJSIP/123456@external_provider-Default,,TK") in new stack
    -- Called PJSIP/123456@external_provider-Default
  == Using SIP RTP Audio TOS bits 184
  == Using SIP RTP Audio TOS bits 184 in TCLASS field.
    -- PJSIP/external_provider-Default-000001fd is ringing
       > 0xb563f48 -- Strict RTP learning after remote address set to: x.x.x.x:18026
    -- PJSIP/external_provider-Default-000001fd answered PJSIP/MyPhone-000001fc
[Jun 14 19:10:00] WARNING[20909][C-00000073]: app.c:3114 parse_options: Unrecognized option: 'X'
8

hmm I thourt that Macro was depricated in Asterisk 11
Am I wrong or is it a feature.conf thing

9

I think Macro is deprecated, yes. If someone has a suggestion on how to achieve the same thing using a sub/gosub/whatever I could try changing that to see if the warning goes away.

10
11

It was deprecated in Asterisk 1.6; I think Asterisk 11 was when the deprecation process was more precisely specified,

12

I migrated to using Gosub but the message is exactly the same. I commented out various parts of the dialplan and identified that the Monitor-Command is the one that’s causing the message. In the logs above it’s this command:

-- Executing [s@macro-DialStartMonitor:2] Monitor("PJSIP/MyPhone-000001fc", "wav,20230614-190954-FROM-1234-TO-123456,bm") in new stack

I don’t see where/how the X-Option is added there though.

13

Look at the options you are passing to the Monitor application. From the log trace it looks like you are passing the b and m options. Are you actually trying to pass a third? Or it could be that the character you are passing is in an unsupported character encoding.

14

No, I am only trying to pass b and m. I don’t think there is an encoding issue either.

The relevant section of the dialplan looks like this:

exten => s,1,Set(MONITOR_FILENAME=${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}-FROM-${CALLERID(num)}-TO-${ARG1})
same => n,Monitor(wav,${MONITOR_FILENAME},bm)
same => n,Return()
15

I am not shure about the value of variable “MONITOR_FILENAME”. Maybe the call to the Monitor aplication looks different than you think.
Do a

same => n,verbose("Filename ${MONITOR_FILENAME}")

right before calling Monitor.
Then check the output on the console to see what content is actually in the variable.

16

The verbose application isn’t available, so I used NoOp and it is entirely what’s expected.

I’d like to point out again that the message doesn’t appear when the Monitor application is executed but later on when the call is answered. So Monitor apparently does “something” that executes “something” with an unsupported parameter later on in my case.

17

I’m surprised Verbose is not available.

I think the only way we’d really get to the bottom of this is if you ran under a debugger and and set a breakpoint on the production of that message and looked at the stack backtrace to see exactly what it was doing.

18

My idea was that there might be a comma in the MONITOR_FILENAME variable (or some other character that confuses the application when processing).
I am also surprised that the application verbose is not available.

Unfortunately I have no further idea and suspect that debugging as suggested by David leads to the solution.

19

I can’t see any mention of the Asterisk version involved. Checking through the Wiki, I find that Verbose is present at least as far back as Asterisk 1.8, and I can’t find docs for any older versions. Is this version of Asterisk older than that?

21

No it’s not, the application verbose is just not loaded on this system.

Also unfortunately it seems like I don’t have the option to debug on this system. I can however modify the source code. Is there anything I can add (like additional debug output) to for example print out which options are passed and to which function it’s passed?