Asterisk: trunk e utenza interna con lo stesso numero

Per fare in modo che una determinata utenza interna di Asterisk corrisponda appieno al numero urbano a cui è legata, può far comodo definirla con un numero identico a quello del “trunk”: in questo modo sarà contattata dagli altri interni senza interessare le connessioni esterne e senza dover ricordare uno specifico numero d’interno.

Supponiamo, dunque, di disporre di un’utenza VoIP standard presso un provider VoIP, dove il numero urbano assegnato sia 0255667788 e la password sia “trunkpassword”. Vogliamo definire un’utenza interna con lo stesso numero, raggiungibile dagli altri utenti dello stesso centralino, designata però anche a rispondere alle chiamate entranti provenienti da quell’utenza VoIP esterna.

Un’utenza interna così definita ha il vantaggio di poter essere chiamata dagli altri interni con il suo numero, cioè 0255667788, ma nessun “trunk” verrà interessato, neanche per un “redirect”, in quanto il numero si trova nel “dial plan” di Asterisk, che sa di poterla raggiungere direttamente.

Se si definisce l’utenza interna con lo stesso numero e con la stessa password del “trunk” (nell’esempio “trunkpassword”) non vi sono problemi. In genere, però, l’utenza interna tende ad avere password diverse (molti amministratori ne usano una unica per tutti gli interni) e in questo caso occorre fare attenzione, perché i due elementi vanno definiti in Asterisk (usando FreePBX o interfaccia simile) nel seguente ordine:

• l’utenza interna, facendo una prova di collegamento con il client SIP (o IAX o altro protocollo);
• il relativo “trunk” VoIP esterno, che rappresenta il “collegamento urbano” (quello che ha la password uguale a “trunkpassword”).

Se erroneamente si genera prima il “trunk” e poi l’utenza interna, possono esservi problemi di autenticazione: Asterisk in molti casi prende per buona la prima password utilizzata per quel numero. Se la password del “trunk” è diversa da quella dell’interno, il client SIP non riuscirà ad autenticarsi perché Asterisk si aspetta la password del “trunk” (se è stato generato per primo) e non quella dell’interno, mentre il “trunk” risulterà tranquillamente autenticato ma inservibile.

Per evitare ciò, quindi, generare sempre prima l’utenza interna, collaudarla e poi generare il “trunk”.