[Asterisk-Users] Re: 'I'nvalid extension handling problems,
even with workaround
telmo at n1.com
telmo at n1.com
Fri Dec 24 09:53:04 MST 2004
Hi Rich,
Thanks for the further help you are extending me. I will be trying your
suggestions during the holidays, and when I get back on-line will post my
progress here.
Thanks again.
Merry Christmas to all,
--
Telmo.
On Thu Dec 23 5:06 , Rich Adamson <radamson at routers.com> sent:
>> 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 : 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" ;format is "name"
>> ;;;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:
>> -- 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:
>> build_route: Contact hop:
>> -- 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 '' 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
>
>
----
SeeqMail - the only email you'll ever need Starts Here
Sign up for FREE personalized email today: http://www.seeqmail.com
http://www.Grassroots.org/ - Make Change!
----
More information about the asterisk-users
mailing list