[Asterisk-Users] Re: 'I'nvalid extension handling problems,
even with workaround
Rich Adamson
radamson at routers.com
Thu Dec 23 06:06:06 MST 2004
> Hello Rich,
>
> First of all, thank you very much for your help and patience.
>
> I've just arrived home from work (yes, I'm one of the midnight oil burners :-))
> and implemented and tested your suggestions; unfortunatelly it didn't work, the
> same behaviour remains.
>
> More details follow below, in-line:
>
> On Wed Dec 22 4:14 , Rich Adamson <radamson at routers.com> sent:
> >Inline...
> >
> >> Humrmrm... 2 days, no answers... :-/
> >
> >Well, let me see if I can take a stab at this one.
>
> You sure did. Your help was most appreciated, I learned a lot from thinking about
> your suggestions, even if they did not work as planned (see below) they made a
> lot of sense.
>
> >After working with * for about a year now, I'd suggest the toughest
> >part of the learning curve is truly understanding how to take advantage
> >of the various 'context' statements to accomplish an objective. Part of
> >reason for the steep learning curve appears to relate to the lack of
> >any reasonable form of tracing/debugging what the system is actually
> >using for a context at each step. (What I mean is that its not intutive
> >for the beginner.)
>
> I agree. I'm working with 15 (!) "-v" on the command-line here and yet I can only
> perceive Asterisk has left or entered a context indirectly, by the commands that
> are executing.
>
> >It would really be nice if there was a 'debug context' type command
> >that would simply display each extensions.conf line as it is executed.
>
> That can't be too hard to implement, when I'm a little more familiarized with
> Asterisk I will certainly try to code that in.
>
> >> Either I made a stupid question (I don't think so: I have *really* tried to solve
> >> that on my own before asking the list) or this one's just something nobody has
> >> ever tried but me (I also find that unlikely: even the telco here plays a message
> >> when I dial a wrong number; also there's the wiki page I mentioned, which
> >> indicates that someone in the past has had the same issue).
> >>
> >> >I'm having trouble configuring Asterisk to play an "invalid extension" message to
> >> >anyone dialing an undefined extension.
> >>
> >> >I then did the "separate context with _." trick the above wiki page suggests; at
> >> >first it seemed to work: picking up an extension and dialing any invalid
> >> >extension would play the message (albeit it would play twice, can't understand
> >> >why) and then hang up.
> >>
> >> >;;;extensions.conf
> >> >[internal] ;;; context used by our internal SIP-phon
> >> >include => voiptalk.org ;include context below
> >> >exten => 11,1,Dial(SIP/gsbt100,20,tr);calling : dial our office phone
> >> >include => invalid_calls ;all ext numbers not handled above are invalid
> >
> >The 'separate context' approach _does_ work, but you've just confused
> >that approach by dropping the Dial statement in the middle. Change this
> >to something like:
> > [internal]
> > include => valid-extensions
> > include => voiptalk
> > include => any-other-context-that-you-need
> > include => invalid-calls
>
> Makes a lot of sense, and also leads to much more intelligible structure. I
> implemented it almost literally as you suggest (see below for my extensions.conf
> file after the modifications).
>
> >The above _sequence_ of include statements is maintained for each call.
> >In other words, if a call does _not_ match entries in 'valid-extensions',
> >then it proceeds to the next include. However, if a match is found (including
> >special cases such as 't', etc) then the call processing may _not_ step
> >through the remaining includes.
>
> OK. I understand what you are stating, it makes a lot of sense. Unfortunatelly it
> seems Asterisk disagrees with us... :-) please see below.
>
> >I'm not sure at all about using context names with a period in it, so
> >just to ensure that isn't causing an issue, stick to context names with
> >alphanumeric characters. (At least eliminate that uncertainty.)
>
> OK. Let's play it _really_ safe: I've removed "." from context names, and
> replaced "_" (underline) for "-" (dashes), so right now I'm only using characters
> from the set [a-z0-9-] in context names.
>
> >> >[voiptalk.org]
> >> >;forwards any calls starting with an "8" thru voiptalk.org
> >> >exten => _8.,1,Answer
> >> >exten => _8.,3,SetCIDNum(55555555)
> >> >exten => _8.,4,SetCIDName(My Name And Surname)
> >> >exten => _8.,5,Dial(SIP/${EXTEN:1}@voiptalk.org,,g)
> >> >exten => _8.,6,HangUp
> >> >[invalid_calls] ;;; default context for invalid calls
> >> >exten => _.,1,Wait(1)
> >> >exten => _.,2,Answer
> >> >exten => _.,3,Playback(invalid)
> >> >exten => _.,4,Hangup
> >> >;;;end of extensions.conf
> >
> >In the above [invalid_calls] context, change the order to:
> > exten => _.,1,Answer
> > exten => _.,2,Wait(1)
> > exten => _.,3,Playback(invalid)
> > exten => _.,4,Hangup
>
> Also makes a lot of sense. Done it that way.
>
> >It is rather important from a learning perspective that you create
> >the [internal] context for use by "internal phones only". Don't try
> >to use that same context for incoming voiptalk calls, etc. For incoming
> >external calls, create a separate context something like:
> >[incoming-voiptalk]
> > include => valid-extensions
> > include => invalid-calls
>
> Ah! Thanks for the tip. Also makes a lot of sense.
>
> >After you've made the above changes, "stop" and restart asterisk to
> >ensure you know exactly what asterisk believes the dialplan is supposed
> >to be. Stay away from the various 'reload' commands until you understand
> >exactly what is happening.
>
> Did that: "stop now" in the cli, and then restarted asterisk with "asterisk -cp
> -vvvvvvvvvvvvvv" after modifying the files.
>
> >Then place test calls and watch the CLI paying close attention to which
> >contexts are actually in use (or which context a call stops progressing
> >in). If necessary, increase the debug level to see the needed call progress
> >info.
>
> Did it; unfortunatelly the same behaviour continues: when I call (for example)
> 8902, I hear Voiptalk's welcome message and right after it I hear the "invalid
> extension" message...
>
> The files ended up as below:
>
> ;;;extensions.conf
> [internal]
> include => valid-extensions ;; internal sip phones
> include => voiptalk ;; dial out thru voiptalk.org
> include => tests ;; miscellaneous tests
> include => invalid-calls ;all ext numbers not handled above are invalid
> [valid-extensions] ;;; context used by our internal SIP-phon
> exten => 11,1,Dial(SIP/gsbt100,20,tr) ;calling <11>: dial our office phone
> [voiptalk]
> ;forwards any calls starting with an "8" thru voiptalk.org
> exten => _8.,1,Answer
> exten => _8.,3,SetCIDNum(55555555)
> exten => _8.,4,SetCIDName(My Full Name)
> exten => _8.,5,Dial(SIP/${EXTEN:1}@voiptalk,999,g)
> exten => _8.,6,HangUp
> [invalid-calls] ;;; default context for invalid calls
> exten => _.,1,Answer
> exten => _.,2,Wait(1)
> exten => _.,3,Playback(invalid)
> exten => _.,4,Hangup
> ;;;eof extensions.conf
>
>
> ;;;sip.conf
> [general]
> register => 55555555:666666 at voiptalk.org/1000
> maxexpirey = 180
> defaultexpirey = 160
> [voiptalk]
> type=friend
> secret=666666
> username=55555555
> host=voiptalk.org
> fromdomain=voiptalk.org
> insecure=very ;needed to allow incoming calls to bypass authentication
> dtmfmode=info ;Choices are inband, rfc2833, or info
> [gsbt100]
> type=friend
> host=dynamic ;must use dynamic even if fixed ip/hostname, or else
> defaultip=192.168.1.200 ;asterisk won't allow it to register
> canreinvite=no ;avoid trouble with NAT: keeps Asterisk "in the middle"
> username=gsbt100 ;gsbt100 sends that when the respective fields are empty
> secret=mysecret
> dtmfmode=rfc2833 ;Choices are inband, rfc2833, or info
> mailbox=1234 ;Mailbox for message waiting indicator
> context=internal ;Context for internal SIP phones
> callerid="Office" <11> ;format is "name" <number>
> ;;;eof sip.conf
>
> Here comes the output on the console when I dial '8902':
>
> Setting NAT on RTP to 0
> Stopping retransmission on '5e5172baa8c28adf at 192.168.1.200' of Response 45199: F
> ound
> Setting NAT on RTP to 0
> Check for res for gsbt100
> Call from user 'gsbt100' is 1 out of 0
> build_route: Contact hop: <sip:gsbt100 at 192.168.1.200;user=phone>
> -- Executing Answer("SIP/gsbt100-7dcf", "") in new stack
> -- Executing Wait("SIP/gsbt100-7dcf", "1") in new stack
> Stopping retransmission on '5e5172baa8c28adf at 192.168.1.200' of Response 45200: F
> ound
> -- Executing SetCIDNum("SIP/gsbt100-7dcf", "55555555") in new stack
> -- Executing SetCIDName("SIP/gsbt100-7dcf", "My Full Name") in new stack
> -- Executing Dial("SIP/gsbt100-7dcf", "SIP/902 at voiptalk|999|g") in new stack
> SIMPLE DIAL (NO URL)
> Setting NAT on RTP to 0
> Outgoing Call for 902
> 902 is not a local user
> -- Called 902 at voiptalk
> (Provisional) Stopping retransmission (but retaining packet) on
> '12e2f2cc30702a0c3647cbeb4d2d2193 at voiptalk.org' Request 102: Found
> Acked pending invite 102
> Stopping retransmission on '12e2f2cc30702a0c3647cbeb4d2d2193 at voiptalk.org' of
> Request 102: Found
> Stopping retransmission on '12e2f2cc30702a0c3647cbeb4d2d2193 at voiptalk.org' of
> Request 102: Not Found
> (Provisional) Stopping retransmission (but retaining packet) on
> '12e2f2cc30702a0c3647cbeb4d2d2193 at voiptalk.org' Request 103: Found
> Acked pending invite 103
> Stopping retransmission on '12e2f2cc30702a0c3647cbeb4d2d2193 at voiptalk.org' of
> Request 103: Found
> build_route: Record-Route hop: <sip:902 at 82.145.32.73;ftag=as3688ce90;lr=on>
> build_route: Contact hop: <sip:902 at 217.14.132.184>
> -- SIP/voiptalk-bbd4 answered SIP/gsbt100-7dcf
> -- Attempting native bridge of SIP/gsbt100-7dcf and SIP/voiptalk-bbd4
> Oooh, format changed to 8
> Ooh, format changed from UNKN to ULAW
> Ooh, format changed from UNKN to ALAW
> Registration from '<sip:gsht286 at 192.168.1.1;user=phone>' failed for '192.168.1.201'
> Auto destroying call 'd761b1512a710969 at 192.168.1.201'
> Scheduled a timeout # 55
> Stopping retransmission on '327b23c6643c98696633487374b0dc51 at 192.168.1.1' of
> Request 107: Found
> Stopping retransmission on '327b23c6643c98696633487374b0dc51 at 192.168.1.1' of
> Request 108: Found
> Registration successful
> Cancelling timeout 55
> Auto destroying call '8a7ae46c9e0d1370 at 192.168.1.201'
> Didn't get a frame from channel: SIP/voiptalk-bbd4
> Bridge stops bridging channels SIP/gsbt100-7dcf and SIP/voiptalk-bbd4
> update_user_counter(902) - decrement outUse counter
> 902 is not a local user
> Exiting with DIALSTATUS=ANSWER.
> -- Executing Hangup("SIP/gsbt100-7dcf", "") in new stack
> == Spawn extension (internal, 8902, 6) exited non-zero on 'SIP/gsbt100-7dcf'
> -- Executing Answer("SIP/gsbt100-7dcf", "") in new stack
> -- Executing Wait("SIP/gsbt100-7dcf", "1") in new stack
> -- Executing Playback("SIP/gsbt100-7dcf", "invalid") in new stack
> Difference is 50272, ms is 6304
> -- Playing 'invalid' (language 'en')
> -- Executing Hangup("SIP/gsbt100-7dcf", "") in new stack
> == Spawn extension (internal, h, 4) exited non-zero on 'SIP/gsbt100-7dcf'
> update_user_counter(gsbt100) - decrement inUse counter
> Stopping retransmission on '5e5172baa8c28adf at 192.168.1.200' of Request 102: Found
>
> As I said above, what I hear on the gsbt100 phone when I pick it up and dial
> '8902' remains unchanged: first I hear VoipTalk's message, and it's followed by
> my "invalid" message. Examining the console output above seems to indicate that
> Asterisk is simply "falling thru" the list of contexts included in the
> "[internal]" context, contrarywise to what we were expecting...
>
> As I said, I'm using Asterisk 1.0.2; Can this be a bug in that release? If so,
> can you indicate me a release where you think this works?
Comments relative to the above:
1. Without knowing exactly how your * box is configured, it would appear
you are using some sort of firewall/nat box. The [voiptalk] context in
sip.conf does not include anything relating to nat=yes, etc. Might look
a little closer at the nat requirements.
2. Not sure it will make any significant difference, but you might add
canreinvite=no to the [voiptalk] context.
3. I see addresses like 192.168.1.200, 1.201, and 1.1 in the above. What
is 192.168.1.1?
4. It would appear there are many more definitions in extensions.conf
that you've chosen to not show us, and some of these might be important
towards diagnosing the problem. Example, I see:
== Spawn extension (internal, h, 4) exited non-zero on 'SIP/gsbt100-7dcf
in the CLI stuff, but there config files you shown don't include an "h"
section in the internal context. Have you defined that? (If you don't
want to post your entire sip.conf and extensions.conf, then at least email
direct (minus secrets) to me.
5. The syntax of:
exten => _8.,5,Dial(SIP/${EXTEN:1}@voiptalk,999,g)
does not appear to be correct. Try something like:
exten => _8.,5,Dial(Sip/voiptalk/${EXTEN:1}
where 'voiptalk' is referring to the context [voiptalk] and not a domain
name. (Check the exact syntax as I typed the above from memory.)
You said you dialed 8902 in the example above. But, the debug shows:
-- Executing Dial("SIP/gsbt100-7dcf", "SIP/902 at voiptalk|999|g") in new stack
SIMPLE DIAL (NO URL)
Setting NAT on RTP to 0
Outgoing Call for 902
902 is not a local user
-- Called 902 at voiptalk
Is extension 902 at voiptalk a valid extension? (Doesn't look like it to me.)
I'm more then a little confused with the above. It would almost appear
that you are expecting the [invalid-calls] context to be executed when
an invalid extension "at" voiptalk is attempted. If so, that isn't the
way this stuff works. The [invalid-calls] context will only get executed
when there is no matching dialplan entries on your * box (not theirs),
and 8902 found a match in the form of _8. in the [voiptalk] context.
6. Your voiptalk register command looks like:
register => 55555555:666666 at voiptalk.org/1000
which tells the voiptalk.org folks to always send incoming calls to your
* box to extension 1000. But, your extensions.conf doesn't include an
entry for exten => 1000,1,...
Is that because it was left out of the copy/paste, or does it not really
exist?
7. In the sip.conf definitions, definitions that use type=friend do not
require/want any statements associated with an IP address. The registration
process 'supplies' the appropriate IP address to asterisk. If the
registration process is not working without those statements, then debug
that before trying to debug the other stuff.
Rich
More information about the asterisk-users
mailing list