The dialer module

The dialer module allows the user to initiate a phone call by speaking either the number to dial or the name of a known contact. For voice dialing to work, the handsfree phone (HFP) subsystem must be running and a mobile phone device must be paired. If these conditions aren't met, the dialer conversation module will still work, but it won't be possible to connect any calls.

Like all other modules, the dialer module provides an initialization callback function. After io-asr has loaded all modules, it invokes the initialization callback to set up the private data structures managed by the module.

The initialization callback loads the dialer-specific configuration tree to make it available to the module. This configuration data is assumed to be in the module/cardialer path of the global configuration tree. The dialer module has two locale-specific configuration files that are used to customize its behavior:

Next, the initialization callback loads the result confidence threshold and opens a connection to the PPS control object of the HFP subsystem. The URI of this control object is configurable; the module obtains the location when it loads the configuration data.

When io-asr shuts down, it releases all modules that it has dynamically loaded. The dialer module provides the destroy() callback, which releases resources allocated during the initialization phase and closes any open PPS connections before the module is deleted from the ASR subsystem.

The HFP subsystem

The dialer module is responsible for issuing dial commands to the HFP subsystem to initiate outgoing phone calls. Because it relies on the HFP subsytem, the dialer module queries the /pps/services/bluetooth/services object to ensure the system is available before issuing any commands. It issues dial commands via the PPS handsfree control and status objects. For more information about these objects, see the PPS Objects Reference.


The dialer conversation module can:

In addition to these actions, an IDLE action is defined. This describes the system at the beginning of a speech session. Most interactions with the dialer will be initiated from this state.

Conversation flow

The dialer module has the following conversation states:

ASR state transitions

Like other conversation modules, the dialer module defines a step() callback function to keep track of the current ASR state.

In addition, the dialer module's private data structure contains fields that specify the number of digits in the phone number that have been confirmed as correct and the number of digits that remain. A minimum number of confirmed digits are required before a call can be dialed. The total number of digits in the phone number can be obtained by taking the sum of confirmed digits and new digits.

The step() callback function handles the following state transitions:

The step() function ignores all other state transitions.

Result handling

The on_result() callback function of the conversation module interface, asr_conversation_if, handles speech results (utterances) for the digit dialing context. This handler takes one of the following actions:

When the utterance has been processed, the handler returns the ASR action (asr_result_action_t) to perform next. This action indicates whether recognition is complete (the call has been dialed), recognition needs to be restarted (to gather more information and continue the conversation), or recognition should be aborted (terminate the conversation without invoking any functions).

The result-handling callback sets the internal state of the dialer module based on the intents of the utterances received and processed by the recognizer. To support incomplete data from an utterance—for example, if a dial request was made without specifying the number, requiring ASR to prompt the user for the number to dial—a member of the dialer module's private data structure keeps track of the internal state between invocations of callbacks.


The conversation flow understood by the dialer module is defined in the control configuration file by a BNF grammar that expresses the intents of the spoken utterances. The ASR subsystem uses this grammer to extract the intents from the utterance. It adds this information as payload data to the result structure for the NLP component of the conversation pipeline to use. The BNF grammar for the dialer module is defined in car-control.cfg.

In addition to the NLAL grammar used by the conversation pipeline, the dialer module also defines a BNF grammar that can be used to create a context for the third-party recognizer module. The default dialing context is defined in the recognizer/en-US/dialer/car-dialer.bnf directory.

Finally, a default grammar for the contact list is generated. This grammar defines the contact-name slot as being a null feature. The context created by this grammar will be replaced when a phonebook is actually connected to the host device. This context simply serves as a placeholder, allowing the dialer module to work until the contact list context is generated. This substitution is done at runtime as described in the following section.

Updating the guest context

The dialer module defines several helper functions that are used to construct an internal representation of the contact list used to build a guest context for voice dialing. The names of all the contacts are first obtained from the phonebook database and added to an ordered list, removing all duplicate entries.

The contact list associated with the dialer module is constructed a little differently than one might expect. Normally, given names are paired with family names. However, in this case, given names and family names are included as separate entries in the contact list. This will allow the constructed context to match on utterances of given name or family name only.

The contact list must be updated whenever there is a change to the phonebook database. To facilitate this, the dialer module spawns a monitor thread that listens for changes to the phonebook and updates the contact name list accordingly.

Receive-list database table

The dialer conversation module uses a receive list database table in the phonebook database to track contacts that are accumulated by the call-by-name action. This table (named asr-matched-contacts) tracks the contact names and the confidence with which those names correspond to a specified match string. The table can be easily published to other applications that can access the database (e.g., a GUI application). However, this approach assumes that the database facilities are available and that an appropriate table for storing the data exists. When the module queries the contacts database table, it retrieves the contact ID that is associated with the contact. This allows the module to insert a new row into the table for each match.