When compiling in developer mode, Asterisk fails to compile if the defaultenabled tag is present in the XML docs:

<defaultenabled>no</defaultenabled>

It does not matter if it is "yes" or "no".

This appears syntactically valid but it complains it violates the DTD:

doc/core-en_US.xml:9229.0: Element module content does not follow the DTD, expecting (depend* , use* , conflict* , defaultenabled? , support_level? , replacement? , deprecated_in? , removed_in?), got (defaultenabled depend support_level )

So we will need to figure out why it violates the DTD (currently unclear), or the tag could simply be removed altogether and app_fsk can compile by default.

Recently I was contacted by someone who found this old application app_fsk I made to deal with a tough VoIP customer, whose network administrators won't let me use the network to administer the PBX remotely.

At the time, I only needed to reach my PBX to send a few commands, and the batch mode was quite good.

Later, the batch mode wasn't enough anymore, and the solution got discontinued in favor of a more complex one that allowed direct interactions with PBX using only voice channels Access your PBX using voice channels

It came out that the person who contacted me needs is to send a particular payload using FSK.
I think the best way is to move the payload logic composition from the dialplan to the module to achieve this goal.

This issue is to implement a new function within this application allowing this goal.

Here is the sample implementation for type II callerIDs