David McNett
2004-Oct-23 22:42 UTC
[Asterisk-Users] One approach to SIP dialing through asterisk
Caveat: I've only got about three weeks of experience working with Asterisk
so it's possible I've completely overlooked a more obvious
solution
to this issue. Snide comments are welcomed if this is the case.
One of the more puzzling frustrations I've faced in working with Asterisk is
that the dialplan seems to have been built without the accomodation for
SIP dialing to be done through the Asterisk box acting as a sip proxy. I
was startled to discover that dialing an URI-based SIP address such as
sip:nugget@slacker.com from my cisco phone or from a soft phone like x-lite
resulted in a connection to a local "nugget" extension to the
phone's
Asterisk server. I was surprised that Asterisk was stripping off the SIP
domain before working through the dialplan, although I've grown familiar
with
working with the dialplan this way it still feels odd to me.
Early on in my configuring I discovered a function (albeit crufty and akward)
approach devised by Wayne Harrison which is documented at
http://www.planetwayne.com/forums/viewtopic.php?t=196
While that does work, it wasn't what I was hoping to accomplish. I later
found this piece of tease: http://www.voip-forum.com/?p=153&more=1 which
leads the reader to the conclusion that SIP dialing through Asterisk is
just a Simple Matter of Programming(tm) but seems to overlook some rather
significant hurdles that would face a person trying to design a dialplan
as described.
Tonight I set myself to this task and I've come up with a quasi-workable
implementation of the proposal in the voip-forum.com article. I'd
appreciate
any feedback on this approach since it does have some drawbacks.
I created a [trunkuri] context for evaluating extensions to see if the
SIPDOMAIN does not match a MYDOMAIN variable which I hard-code with my
local SIP domain. My first dilemma was where to perform this evaluation.
At first I tried to place it in "exten => s" for my [trunkuri]
context, but
that never seemed to actually be processed. I found that the only way to
have this test hooked was to make a match-all _. extension in my trunkuri
context. This means that I have to be careful to make sure that [trunkuri]
is the last extension context that's applied for any placed call.
I include it last from my container context, as such:
; For stations that are physically inside the house
[house]
include => local
include => kpmirror
include => trunkld
include => trunkint
include => emergency
include => trunkuri
The [trunkuri] context appears as follows:
; Hey, it works.
[trunkuri]
exten => _.,1,NoOp(trunkuri start! ${EXTEN}@${SIPDOMAIN})
exten => _.,2,GotoIf($[${SIPDOMAIN} = ${MYDOMAIN}]?4)
exten => _.,3,Dial(SIP/${EXTEN}@${SIPDOMAIN})
exten => _.,4,Congestion()
This matches any extension that hasn't previously been caught by my local
and
normal targets and dials it if the SIPDOMAIN isn't me. It works, but only
barely. One glaring hole is that with this approach I am unable to dial
SIP URIs that partly match my own local extensions. If, for example, I have a
sip:sales@slacker.com address, I'm unable to dial sip:sales@sc.com with this
because sales will have already hit. The only way I can see around that would
be to burden all my defined internal extensions with that same SIPDOMAIN
evaluation which seems cumbersome and unwieldy to maintain.
Is there a way for me to hang [trunkuri] as the very first included context?
I haven't seen a dialplan command that would allow me to do this. In effect
I'm guessing I'd need a way for the _. extension to voluntarily defer
and
pass on down to the remaining extensions as if it had not been a hit. Is
this even possible?
For context, the whole of my extensions.conf is available at:
http://slacker.com/~nugget/stuff/extensions.conf
Additionally, I've documented my progress at:
http://slacker.com/~nugget/asterisk1.php
Feedback and suggestions would be welcomed.
--
David McNett <nugget@slacker.com>
http://slacker.com/~nugget/