[asterisk-users] DUNDi + SIP Realtime

JR Richardson jmr.richardson at gmail.com
Sat Sep 19 09:34:47 CDT 2009


> Good afternoon gentlemen (and ladies).
> 
> A costumer of mine has many servers and each one maps their SIP extensions
> to the others via DUNDi. It works like a charm. SIP extensions can only
> register at one server, the one they "belong" to. In case one extension
> wants to call other that is registered in another server, DUNDi takes care
> of that by calling the other server using IAX2 and G.729 codec. It's
> important to clarify that each server today works as a completely
> independent PBX, talking to each other using IAX2 that is routed via a
> MPLS network. Also, the servers are very distant from each other
> physically.
> 
> Today the extensions are being mapped in DUNDi like this:
> 
> [dundi-internal]
> exten => _70XX,1,Noop()
> 
> And all extensions configurations are done in sip.conf. No realtime is
> being used, yet.
> 
> 
> 
> 
> Now the customer wants to take a step further and make it possible that
> *every* SIP extension could be able to register in *every* server. That
> would make possible for them to use DNS to automatically "find" the
> closest PBX and make the extension register on that one.
> 
> So far I considered the following for this project:
> 
> - Moving all SIP extensions from individual sip.confs to one MySQL
> database, and point all servers to that one
> - Configure sip.conf on each machine like this:
> 
> regcontext=dundi-internal
> rtcachefriends=yes
> rtsavesysname=yes
> rtupdate=no
> rtautoclear=yes
> ignoreregexpire=no
> 
> That way each time an extension registers, Asterisk would add an extension
> to the dundi-internal context, which as you guessed, is the one being
> mapped to the other servers. So instead of mapping extensions using
> wildcards, the extensions will be mapped individually.
> 
> extensions.conf would be something like this:
> 
> [internal]
> ;Tries to make the call using SIP, in the case
> ;the extension is registered in this server
> ;If it's not, switches to DUNDi
> exten => _XXXX,1,Dial(SIP/${EXTEN},60)
> exten => _XXXX,n,NoOp(DIALSTATUS = ${DIALSTATUS})
> exten => _XXXX,n,NoOp(FROM_DUNDI = ${FROM_DUNDI})
> exten => _XXXX,n,GotoIf($["${FROM_DUNDI}" = "1"]?end:start)
> exten => _XXXX,n(start),Answer()
> exten => _XXXX,n,Playback(vm-dialout)
> exten => _XXXX,n,Goto(dundi-internal-helper,${EXTEN},1)
> exten => _XXXX,n(end),Noop(Loop detected. Hanging up.)
> exten => _XXXX,n,Hangup()
> 
> [dundi-internal-helper]
> switch => DUNDi/dundi_internal
> 
> [from-dundi]
> exten => _XXXX,1,Set(FROM_DUNDI=1)
> exten => _XXXX,n,Dial(SIP/${EXTEN},60)
> 
> 
> So far it's working fine in a test lab with 2 servers running Asterisk
> 1.6.0.15.
> 
> For the gurus out there: is there something that I'm doing terribly wrong,
> that would break everything and make the universe collapse into itself
> when I apply the same principle on production?
> 
> I'll be happy to provide more details in case there are any doubts. I
> really appreciate your feedback, no matter what is it. :)
> 
> 
> 
> Vin?cius Fontes
> www.asteriskforum.com.br - Informa??es e discuss?o sobre Asterisk e
> telefonia IP
>
[JR Richardson] 
I used to do this exact thing a few years ago, wrote a couple of papers
about it.  Realtime + DINDi works great for this, I would add in MySQL
replication to the mix so each server writes the SIP cache info to a Master
database that is replicated out to all the servers.  Each server will have a
copy of the same database and be able to contact the phones if DUNDi queries
become unavailable.

The tricky problem you may run into, if you haven't figured it out yet, is
what to do about voicemail and where the storage will be, distributed
voicemail will be problematic in a dynamic sip ua registration environment
across multiple servers.  Centralize voicemail using DUNDi can help this out
as well.

I'll send you some papers off line

Hope this helps.

JR
----
Engineering for the Masses 




More information about the asterisk-users mailing list