This is driving me nuts. All the documentation for the ‘s’ extension calls it the ‘start’ extension. Someone said in this forum recently it’s a wild card (why can’t the docs just CALL it a damn wild card then!)
I dial 12345 and I get a 404 not found. I thought s was a wild card? If that’s the case, then dialling ANY NUMBER should cause tt-weasels to be played. Right? Arrrgh!
It’s not a wildcard, it stands for “start”, as you mentioned. It’s used to handle incoming IAX, SIP or Zaptel channels because the caller hasn’t had the chance to enter an extension before the channel is answered. I don’t really know of a reason (or if you can) to use it in an internal context.
If you need ‘wildcard’ functionality, look into using pattern matching in the dialplan.
Pattern matching won’t do what I want. When someone dials a number and I use a pattern match to set a variable…
exten => _X., SetVar(…)
… the logic is going to end there in the dial plan. I want it to continue on executing AFTER setting the variable. I swear getting Asterisk to do what you want is like pulling teeth.
Ugh. Ok, so this is the scenario. We have two extensions. Each has it’s own extension number, say 1001 and 1002. We want outgoing calls from these extensions to show the same caller id, which will the main number of this business. Not too weird. People do this all the time.
However, we don’t want to set the caller id with callerid= in sip.conf because that breaks the ability to do cool things with their unique caller id (1001 and 1002) like not ask for a mailbox number when dialling voicemail, or not asking for an agent number when logging into an ACD queue.
So, one way around this is to manually set the caller id with CALLERID or SetCallerID command or whatever it is (the command seems to keep changing). Therefore when these phones call/match an extension in their dial plan we want to call CALLERID/SetCallerID and manually set it to be the main number of the business.
Ok, so who knows how to do that?
I haven’t tried it yet but I guess I could use AGI. The script would take the caller id as a parameter, look that up in a plaintext file and return the ‘fake’ caller id we want to use for this call.
It’s my understanding that no matter WHAT NUMBER I dial, I should hear the tt-weasels sound file. That’s what all the documentation says, but it just doesn’t bloody work!
to answer whatever number was dialled, regardless of pattern or length,
or a more specific pattern to answer only specific numbers.
‘s’ is the ‘start’ pattern for contexts you entered via a ‘goto’ – the
context specified in sip.conf (here c_2001) has to start with a match
for the dialled number, not with ‘s’ - at least that’s my experience.
To set a different CID number for external calls than for internal calls,
I would dial external and internal calls in two separate contexts, and in
the external context set the callerid number to the global variable.
This will overrule the originating extensions individual callerid which
you set in sip.conf.
So your first match should probably be for _9x to catch outside calls,
where you branch to your external context; in the internal context you
don’t set callerid, so the one from sip.conf is retained.
And if I did not understand your problem correctly please bear with me,
don’t badmouth either the people trying to help or Asterisk. There are
enough people who manage to get it to work with a little effort that failure to do so cannot simply be pinned on Asterisk.
It is possible, as I do it all the time, to use the ‘s’ as a wildcard for any incoming request, as it will match against any extension dialed. Also, a dial occurs to invoke a context, a user does not have to ‘enter’ an extension, as this is done in the original request. Some extension is always ‘dialed’.
Now, if you have other patterns matched in the context:
As to why this is not working, please post the output from a verbose CLI as to when this error occurs. Although this appears more along the lines of not recognizing something within your SIP config as opposed to an extensions problem.[/img]
We all have our own styles of posting, although the tone of posts like this tend to become the focus rather than the original question the poster was asking. Better to post with a bit of courtesy, so as to keep folks focused on assisting to solve your original problem.
If you are as frustrated as you appear to be with the way Asterisk extensions logic works, the best thing for you may be to branch out into whatever language you prefer, such as PHP, Perl, Java, C, etc. This may all be done by using a call to an AGI, have a look here:
This way, you are not beholden to the Asterisk internal logic, but may handle associating invidiual CLIs in any logic you see fit. Another option would be to use AEL: