On Fri, Jan 22, 2010 at 7:16 AM, Frank Bax <[email protected]> wrote:

> No more suggestions?  Does this mean:
> 1) What I did should "Just Work"?  If so, how do I diagnose/resolve?
> 2) My error is so simple; nobody has time to explain it?
>
>
>
> On 2010-Jan-16, Frank Bax wrote:
>
>> From previously mentioned examples, I have ('XXXX' are really numbers):
>>>>  exten => _1226289XXXX,n,Dial(SIP/1519702x...@fpl,60,)
>>>> which forwards calls to 1519870XXXX when I dial 226289XXXX.  As a first
>>>> step towards my goal; my first attempt was to change this to:
>>>>  exten => _1226289XXXX/_1519455.,n,Dial(SIP/1519702x...@fpl,60,)
>>>>
>>>> Using _1519455. or _519455. produces same results.  When I dial
>>>> 226289XXXX from 519455XXXX, I get:
>>>>
>>>> [Jan 16 09:45:13] NOTICE[15707]: chan_sip.c:17962 handle_request_invite:
>>>> Call from '1226289XXXX' to extension '1226289XXXX' rejected because
>>>> extension not found.
>>>>
>>>
>>
Frank,

When I read your original posts, nothing jumped out at me as an error.  I
don't roll up my sleeves with dialplan stuff every day so I thought one of
our experts might weight in.  In lieu of an expert, here are some of my
thoughts.  :-)

I wonder if the issue lies outside the code snippet you sent.  One of the
important facets of Asterisk Dialplans is the idea of contexts and
inclusion.  Is the phone you're dialing from (or maybe the trunk that's
inbouding the call) in a context that can access the context you've shown
us?  Using an include statement is one way to accomplish this.

The error you've shown could easily be caused by an oversight in context
setup rather than a problem with your code.

For debugging the dialplan, I'll often replace a code block with a
noop("Dave: This statement should get executed").  Noops are short for No
Operation.  They have no real effect but they cause text to be echoed to the
CLI and can help you debug like a printf in C.  This will help you determine
whether you have code issues like parameters or structure issues in terms of
how the dialplan is being parsed.

I think you've accurately deduced the meaning of those extra lines of code
in your first email but I'd suggest continuing as you've indicated more
recently by just adding a couple of lines at a time until you get at the
root of the issue.

I hope this helps.  If not, keep posting and we'll get to the bottom of it.

Dave Donovan

Reply via email to