Not all these numbers are in active use all the time.
When I want to “turn off” a did, I just hit clear dest. and submit. This causes asterisk to answer the call (form a valid trunk) and play the “number not in service” message- and hang up.
I have learned form my provider that if I can set up my box to send back sip 404 (not found) instead of answering the call- my provider will re-route to the intercept message for “not in service”
This would be better all around for my application- I would not be billed for the incoming call-- and the caller would most likely not be billed either.
This method would also allow the call to flow back through the call routing system as “not in service”… in some cases all the way back to the originating central office that the call came form playing the “not in service” intercept message.
Is it possible to get asterisk to send back a 404 when a did is called instead of answering the call?
I suppose I am one of the only people left that gets slightly annoyed when I get an “out of service” message but I know the call was “answered” and the call doesn’t ring all the way back as “not in service”
yes-- when I call an out of service number-- or anything else that doesn’t go through I usually stay on the line until the call rings all the way back, or as far as its going to go.
If there’s no way, there’s no way… but I would like it if there were.
don’t go commenting out ext-did-catchall in such a way that you are going to have an error prone solution that needs to be constantly manually put back each time you upgrade. That is a very bad suggestion.
Instead, simply define your own context, e.g. “from-myprovider” in extensions_custom.conf and use that in the ‘context=’ part of your trunk configuration. Then you can choose what should be there, for example it might look something like this:
[from-myprovider]
include => ext-did
You can look at what is normally included in ‘from-pstn’ to see if there are other contexts you also want included as well. If you do this, Asterisk should not find a matching context and I think that it will send back a 404 though I’m not sure, you would have to test.
your solution is too convoluted. It would be simpler to just flip context from from-trunk to ext-did in the trunk definition. No need to edit config files.
that is true if that is the only context that he needs.
However, there are other contexts that he may want to examine of which neither of us knows with the information provided. For that reason, it is not cut and dry and he very well may require creating a custom context because there may be other includes that he needs.