Ho provato sulla mia pelle un piccolo problema con Asterisk associato ad una vpn, ma mi spiego meglio.
In questa installazione ho un asterisk collegato a vari telefoni presenti in 4 sedi, collegate con varie VPN IPSEC, e delle volte le telefonate avevano audio unidirezionale; questo nella stragrande maggioranza dei casi è dovuto a problemi di NAT.
Bene si direte voi, ma una VPN non è NAT….bhe questo è vero, ma ad Asterisk chi glielo dice che per quelle reti non deve provare il natting? (quindi avendo per questi device nat=never o nat=no non si ha audio)
Glielo diciamo noi attraverso il parametro localnet nella sezione [general] di sip.conf, ad esempio così
localnet=192.168.0.0/255.255.255.0
localnet=192.168.1.0/255.255.255.0
localnet=192.168.2.0/255.255.255.0
localnet=192.168.3.0/255.255.255.0
Lo stesso effetto si ottiene mettendo nelle varie configurazioni specifiche dei friends la dicitura nat=yes, ma non è corretto dal punto di vista tecnico, dato che si tratta di altre reti facenti parte della struttura di Asterisk, non un device dietro NAT.
Piccolo aggiornamento sul post precedente, ho dovuto fare una piccola correzione alla configurazione postata in precedenza, in quanto non era necessario dtmf-dialing, ed il sintomo che dava era curioso, ovvero il numero di telefono digitato da alcuni apparecchi collegati al PBX classico, erano “storpiati”.
Ad esempio se io digitavo 0577123456 questo mi diventava 0505777711223345455656 ad esempio!!!
Togliendolo tutto ok, inoltre ho creato un nuovo utente per usarlo come “friend” lato pbx ed inoltre ho aggiunto delle rotte per chiamare i cellulari, 8XX e 7XX
#—————————————————————-#
# #
# SN4638/5BIS/UI #
# R3.20 2006-11-17 H323 SIP BRI #
# 2007-07-27T06:39:21 #
# Generated configuration file #
# #
#—————————————————————-#cli version 3.20
dns-client server 88.149.128.12
webserver port 80 language en
snmp community public rosystem
ic voice 0
profile ppp default
profile call-progress-tone IT_Dialtone
play 1 200 425 -12
pause 2 200
play 3 600 425 -12
pause 4 1000profile call-progress-tone IT_Alertingtone
play 1 1000 425 -12
pause 2 4000profile call-progress-tone IT_Busytone
play 1 500 425 -12
pause 2 500profile tone-set default
profile tone-set IT
map call-progress-tone dial-tone IT_Dialtone
map call-progress-tone ringback-tone IT_Alertingtone
map call-progress-tone busy-tone IT_Busytone
map call-progress-tone release-tone IT_Busytone
map call-progress-tone congestion-tone IT_Busytoneprofile voip default
codec 1 g711alaw64k rx-length 20 tx-length 20
codec 2 g711ulaw64k rx-length 20 tx-length 20profile voip ASTERISK
codec 1 g729 rx-length 20 tx-length 20
codec 2 g711ulaw64k rx-length 20 tx-length 20
codec 3 g711alaw64k rx-length 20 tx-length 20profile pstn default
profile sip default
profile sip asterisk
profile aaa default
method 1 local
method 2 nonecontext ip router
interface IF_IP_WAN
ipaddress 192.168.1.101 255.255.255.0
no napt-insideinterface IF_IP_LAN
ipaddress 192.168.1.1 255.255.255.0
no napt-insidecontext cs switch
digit-collection timeout 4
national-prefix 0
international-prefix 00routing-table called-e164 RT_2_ISDN
route .%T dest-service HUNTING MT_ITCrouting-table called-e164 RT_ISDN_2_SIP
route 99[1-9].T3 dest-interface IF_S0_PSTN
route 1[1-9].T3 dest-service SER_HUNT_OUT
route 0[1-9].T3 dest-service SER_HUNT_OUT
route 00[1-9].T3 dest-service SER_HUNT_OUT
route 8[0-9].T3 dest-service SER_HUNT_OUT
route 7[0-9].T3 dest-service SER_HUNT_OUT
route 3[0-9].T3 dest-service SER_HUNT_OUT
route default dest-service SER_HUNT_OUTmapping-table itc to itc MT_ITC
map default to speechinterface isdn IF_S0_PSTN
route call dest-interface IF_S0_PHONE
dtmf-dialinginterface isdn IF_S0_PHONE1
route call dest-table RT_ISDN_2_SIP
use profile tone-set ITinterface isdn IF_S0_PHONE2
route call dest-table RT_ISDN_2_SIP
use profile tone-set ITinterface isdn IF_S0_PHONE3
route call dest-table RT_ISDN_2_SIP
use profile tone-set ITinterface isdn IF_S0_PHONE4
route call dest-table RT_ISDN_2_SIP
use profile tone-set ITinterface sip IF_SIP_ASTERISK
bind gateway GW-ASTERISK
service default
route call dest-table RT_2_ISDN
early-disconnect
remote-party-id called-party
remote-party-id calling-party
address-translation outgoing-call from-header user-part fix 210 host-part call
use profile voip ASTERISKservice hunt-group SER_HUNT_OUT
timeout 6
drop-cause normal-unspecified
drop-cause no-circuit-channel-available
drop-cause network-out-of-order
drop-cause temporary-failure
drop-cause switching-equipment-congestion
drop-cause access-info-discarded
drop-cause circuit-channel-not-available
drop-cause resources-unavailable
route call 1 dest-interface IF_SIP_ASTERISK
route call 2 dest-interface IF_S0_PSTNservice hunt-group HUNTING
drop-cause normal-unspecified
drop-cause no-circuit-channel-available
drop-cause network-out-of-order
drop-cause temporary-failure
drop-cause switching-equipment-congestion
drop-cause access-info-discarded
drop-cause circuit-channel-not-available
drop-cause resources-unavailable
drop-cause user-busy
route call 1 dest-interface IF_S0_PHONE1
route call 2 dest-interface IF_S0_PHONE2
route call 3 dest-interface IF_S0_PHONE3
route call 4 dest-interface IF_S0_PHONE4context cs switch
no shutdowngateway sip GW-ASTERISK
bind interface IF_IP_WAN routerservice default
domain 192.168.1.00
realm 192.168.1.100
authentication 210 password 210
default-server 192.168.1.100 loose-router
registrar 192.168.1.100 5060
user 210
session-timer 1800gateway sip GW-ASTERISK
no shutdownport ethernet 0 0
medium auto
encapsulation ip
bind interface IF_IP_WAN router
no shutdownport ethernet 0 1
medium auto
encapsulation ip
bind interface IF_IP_LAN router
no shutdownport bri 0 0
clock auto
encapsulation q921
power-feedq921
protocol pp
uni-side auto
encapsulation q931q931
protocol dss1
uni-side net
encapsulation cc-isdn
bind interface IF_S0_PHONE1 switchport bri 0 0
no shutdownport bri 0 1
clock auto
encapsulation q921
power-feedq921
protocol pp
uni-side auto
encapsulation q931q931
protocol dss1
uni-side net
encapsulation cc-isdn
bind interface IF_S0_PHONE2 switchport bri 0 1
no shutdownport bri 0 2
clock auto
encapsulation q921
power-feedq921
protocol pp
uni-side auto
encapsulation q931q931
protocol dss1
uni-side net
encapsulation cc-isdn
bind interface IF_S0_PHONE3 switchport bri 0 2
no shutdownport bri 0 3
clock auto
encapsulation q921
power-feedq921
protocol pp
uni-side auto
encapsulation q931q931
protocol dss1
uni-side net
encapsulation cc-isdn
bind interface IF_S0_PHONE4 switchport bri 0 3
no shutdownport bri 0 4
clock auto
encapsulation q921q921
protocol pmp
uni-side auto
encapsulation q931q931
protocol dss1
uni-side user
encapsulation cc-isdn
bind interface IF_S0_PSTN switchport bri 0 4
no shutdown
Lo username 210 in sip.conf[210]
username=210
type=friend
secret=210
record_out=Adhoc
record_in=Adhoc
qualify=no
port=5060
nat=never
mailbox=210@device
host=dynamic
dtmfmode=inband
context=from-internal
canreinvite=no
disallow=all
allow=alaw
I toni dtmf sono molto importanti nella telefonia, sia classica che ip, basti pensare che sono indispensabili per i menù dei vari IVR (che personalemente odio
)
Nella stragrande maggioranza dei telefoni IP, per impostazione predefinita abbiamo toni dtmf in-band (oppure in-audio), ma questa modalità può dar problemi con la voicemail.
Inoltre questa modalità funziona se c’è abilitato il codec ulaw (o alaw), altrimenti la compressione potrebbe “danneggiare” il tono distorcendolo.
Per funzionare con le voicemail i toni dovranno essere rfc2833 o SIP info.
Altresì potete impostare auto, così facendo Asterisk se un dispositivo non sarà in grado di gestire un tono rfc2833, sarà usato inband.
Dimenticavo, dtmfmode= auto, rfc2833 o inband in sip.conf o iax.conf o in ogni singola estensione.
Continuiamo la carrellata di post dedicati al collegamento di più Asterisk.
Adesso mettiamola sul difficile! Colleghiamo quattro server! ![]()
Dobbiamo decidere se optare per una configurazione peer to peer (dove tutti i server hanno le “rotte” per gli altri) oppure un server “centrale” che conterrà le rotte per tutti gli altri, ed ogni server avrà una riga nel dialplan per indirizzare le chiamate per gli altri verso questo “hub”.
Analiziamo brevemente vantaggi e svantaggi delle due soluzioni
Vantaggi P2P
Se un centralino cade, tutti gli altri sono raggiungibili senza problemi, indipendentemente dal nodo offline.
Le chiamate inoltre sono “spalmate” tra i vari PBX, con minore uso di risorse.
Svantaggi P2POgni centralino deve avere una “tabella di routing” che va costantemente aggiornata (su tutti i pbx, ogni volta viene aggiunto un nuovo nodo).
E’ anche vero che questi eventi sarebbero rari e non dipenderebbero dall’aggiunta di interni, ma solo di nuove rotte. (un conto è avere 8-10 server, un conto 100).
Vantaggi “HUB”Un unico “master” che contiene le rotte di tutti i centralini, quindi una sola tabella da aggiornare.
Controllo centralizzato delle chiamate, rotte, monitoraggio e così via.
Svantaggi “HUB”Tutto il traffico tra i nodi passa da questa macchina, gli svantaggi sono ovviamente maggior carico sul server, e se muore questo sono drammi!
Cenni su iax.conf e extensions.conf
In ognuno dei due casi sarà opportuno mettere come context predefinito in sip.conf e iax.conf qualcosa del tipo from-internet, per intercettare le telefonate provenienti da centralini “esteri”.
“p2p”
in iax.conf saranno presenti tanti utenti quanti sono i centralini -1, quindi qualcosa nella forma (dove con il contesto locali si intende qualcosa che fa parte della stessa “rete”, potrebbe essere usato anche rete-asterisk”)
ESEMPIO PBX-A
[pbx-b]
type=user
host=IP_DI_B
context=locali
secret=*********
trunk=yes
[pbx-c]
type=user
host=IP_DI_C
context=locali
secret=*********
trunk=yes
…
…
inoltre saranno necessari i vari peer per comunicare con gli altri PBX (per non dover scrivere utente e password nel dialplan)
[trunk_to_b]
type=peer
host=IP_DI_B
username=pbx-a
secret=*********
context=locali
[trunk_to_c]
type=peer
host=IP_DI_C
username=pbx-a
secret=**********
context=locali
……
……
Useremo invece che la classica dial, switch, che permette di effetuare il “forwarding” delle telefonate verso un altro pbx
Es. numerazione PBX-B 31XXX, PBX-C 32XXX, PBX-D 33XXX
exten=>_31XXX,1,Goto(switch_to_b,${EXTEN},1)
exten=>_32XXX,1,Goto(switch_to_c,${EXTEN},1)
exten=>_33XXX,1,Goto(switch_to_d,${EXTEN},1)
[switch_to_b]
switch => IAX2/trunk_to_b/locali
[switch_to_c]
switch => IAX2/trunk_to_c/locali
[switch_to_d]
switch => IAX2/trunk_to_d/locali
Come risulta ovvio nel caso del p2p, tutti avranno le regole per raggiungere gli altri, mentre nel caso dell’uso dell’hub, lui avrà le regole per raggiunegre tutti gli altri, mentre tutti i PBX normali avranno una cosa del tipo
exten=>_3XXXX,1,Goto(switch_to_hub,${EXTEN},1)
[switch_to_hub]
switch => IAX2/trunk_to_hub/chose_way
Quindi nell’HUB[chose_way]
exten=>_30XXX,1,Goto(switch_to_a,${EXTEN},1)
exten=>_31XXX,1,Goto(switch_to_b,${EXTEN},1)
exten=>_32XXX,1,Goto(switch_to_c,${EXTEN},1)
exten=>_33XXX,1,Goto(switch_to_d,${EXTEN},1)
Ovviamente poi ogni centralino avrà un pattern per matchare le estensioni dei propri utenti locali, che possono avere anche più dispositivi.
[locali]
…….
…….
…….
exten=>30123,1,Dial(SIP/xlite&SIP/GXP2000,30,r)
exten=>30999,1,Dial(SIP/pippo,30,r)
Ogni utente sarà appunto un type=user ed ogni dispositivo un type=friend
Non sapevo come intitolare questo post, sono andato sulla banalità! ![]()
Per un progetto che stiamo portando avanti con un’Università, sto facendo varie prove, tra cui “interconessione” tra 2 PBX, utilizzo pratico di ENUM, fallback delle linee e tante amenità simili.
Alla base della mia demo ci sono 2 server Asterisk, uno di front-end puramente IP, un altro di back-end con una scheda Zaptel a cui è collegato un gateway gsm.
Il sistema riceve telefonate sia SIP che IAX, telefonando direttamente via questi indirizzi al PBX, oppure facendo risolvere questi servizi da ENUM (vedi qualche mio post precedente).
Innanzittutto il context di default in sip.conf e iax.conf sarà from-internet, intercettando così tutto il traffico che proviene “dall’esterno”.
In extensions.conf avremo:
[from-internet]
exten=>390577xxxxxx,1,Dial(SIP/xlite,30)
exten=>390577xxxxxx,2,GotoIf(($[${DIALSTATUS}=CHANNELUNAVAIL]?3:4)
exten=>390577xxxxxx,3,Goto(switch_to_backend,MIOCELLULARE,1)
exten=>390577xxxxxx,4,Goto(102)
exten=>390577xxxxxx,102,Hangup
Nella prima linea abbiamo che tutte le telefonate a quel numero telefonico saranno indirizzate verso l’estenzione xlite, il mio softphone.
Se questo non è collegato, la variabile DIALSTATUS assumerà valore CHANNELUNAVAIL e la chiamata (alla linea 3) sarà switchata verso il server di back-end.
La funzione switch permette di effettuare il forwarding delle chiamate verso un altro server , loggandosi con un utente di quel server e “dirottando” la chiamata in un contesto del dialplan del server remoto.
In generale switch ha questa sintassi
switch => IAX2/user:[key]@server/context
Quindi nell’extensions.conf del server di front-end avremo:
[switch_to_backend]
switch => IAX2/user:password@ip_server_backend/from-internal
Nel contesto from-internal del server di back-end ovviamente c’è un pattern che “intercetta” le chiamate verso i cellulari, quindi la chiamata sarà dirottata verso i gateway GSM (sono due porte FXO, gruppo 3, a ricerca ciclica)
exten=>_3XXX.,1,Dial(ZAP/r3/${EXTEN})
Complesso? ![]()
Non troppo!!In vostro soccorso può giungere il grandissimo voip-info.org, sia per extensions.conf che per la connessione tra due server Asterisk (e mi ci metto anche io)
Uno dei vantaggi dei sistemi IP-PBX Asterisk è quello di permettere ai propri utenti di avere più periferiche, sia telefoni IP che softphone, associati al proprio utente e di far squillare questi dispositivi nell’ordine che preferiamo.
Ad esempio possiamo avere un softphone nel portatile ed un telefono fisso sulla scrivania, così quando avremo acceso il notebook magari squillerà solo quello, facendo andare sul fisso le altre telefonate se siamo occupati. Mentre se scordiamo il portatile avremo sempre quello fisso per rispondere!! ![]()
Il concetto di base è quello di creare il nostro utente in sip.conf
[pippo]
type=user
secret=pluto
context=from-internal
e poi due periferiche sip
[xlite]
username=pippo
type=friend
qualify=no
port=5060
nat=never
host=dynamic
dtmfmode=rfc2833
context=from-internal
canreinvite=no
callerid=”Marco” <1234>[gxp2000]
username=pippo
type=friend
qualify=no
port=5060
nat=never
host=dynamic
dtmfmode=rfc2833
context=from-internal
canreinvite=no
callerid=”Marco” <1234>
A questo punto la regola più semplice è quella per far squillare entrambi i telefoni contemporaneamente:
exten=>1234,1,Dial(SIP/xlite&SIP/gxp2000,30)
Semplice no?

Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void « Default
Life
Earth
Wind
Water
Fire
Light 