I have changed how our Asterisk system handles inbound calls to undefined extensions. It seemed like a good idea to me, but before I put in a feature request I thought I’d see whether it would be useful to others, or if I should just continue to use my custom solution.
What I have done is to modify my configuration so that inbound DID calls on our PRI to undefined extensions simply do a Hangup(1) to return an “unallocated” cause code instead of answering the call and playing a “We are unable to complete your call” recording. My reasoning is twofold: (1) callers will hear a recording from their own provider in their own language instead of mine, and (2) the call is not answered so there is no LD charge or any CDR record anywhere of a completed call.
My current solution is to define a “catch all” (any DID/any CID) inbound route which is directed to a custom application to do the Hangup(1). This works well, and I have no problem using this solution indefinitely. Still, I was curious about the reasons for the default behavior, and I wondered if I was missing something.
I also started playing around with a more generic solution, and tried replacing the [bad-number] context with one that does the Hangup(1). However, that also affected local calls between extensions, and that may not be a good thing. For one thing, with SIP extensions (which we use here) different SIP phones react differently to a 404 message (which Hangup(1) sends for SIP calls). Some are friendly and some are not, so perhaps playing a recording is a better idea. It also occurred to me that Zap extensions (e.g., on FXS ports) really do need the recording (or at least a reorder tone) since otherwise the caller would simply get a hangup with no explanation.
So replacing [bad-number] was not a good option, and I decided that the Hangup(1) change should only apply to inbound calls from outside the PBX. But then what about inbound calls on SIP or IAX trunks (which we don’t currently use so I haven’t experimented with)? It still seems to me that doing a Hangup(1) is the proper thing to do since it should be up to the remote system to display a failed call in a manner appropriate at the calling end.
I am curious to know other folks’ opinions on this. Is there a reason for the current behavior on inbound calls? Why not use the “unallocated” cause code and let the far end handle it appropriately? Would it benefit anyone else to make it an option for inbound calls – either reject the call or answer it with a recording?
Thanks,
Lee