System information

Table 12-2. NameMapping table

Name Extension Context

leif 100 publicExtensions

leif.madsen 100 publicExtensions

lmadsen 100 publicExtensions

jim 101 publicExtensions

reception 0 Services

voicemail *98 Services

Make sure this context exists on your system.

We believe that having a separate table that only handles name-to-extension/context

mapping is the most useful solution, since this table can be used to handle more than

just users with telephone sets. You are encouraged to come up with other ways to

handle this that may be more suitable to your environment.

In the dialplan, we would refer to this table using Asterisk’s func_odbc function:

[subLookupNameInNameMappingTable]

exten => start,1,Verbose(2,Looking up ${ARG1})

; where 'name' is the username as found in the email address

same => n,Set(ARRAY(CalleeExtension,CalleeContext)=${GET_NAME_LOOKUP(${ARG1})})

same => n,GotoIf($[${ISNULL(${CalleeExtension})}]?no_result,1)

same => n,GotoIf($[${ISNULL(${CalleeContext})}]?no_result,1)

same => n,Return() ; You'll need to handle the new CalleeExtension and

; CalleeContext variables in the code that called this

; subroutine

exten => no_result,1,Verbose(2,Name was not found in the database.)

same => n,Return(NoResult)

The /etc/asterisk/func_odbc.conf file will require the following entry:

[NAME_LOOKUP](DB)

prefix=GET

SELECT Extension,Context FROM NameMapping WHERE Name='${ARG1}'

Keep in mind that there’s nothing to say you can’t reference more than

one datastore to look up names. For example, you might have a table

such as the one we’ve described here, but also have a secondary lookup

that goes to, say, an LDAP database to try to resolve names there as well.

This can get complicated to configure and maintain, but if designed right

it can also mean that your Asterisk system can be tightly integrated with

other systems in your enterprise.

DNS and SIP URIs | 245