[asterisk-users] Question about "null routing" calls to DIDs we don't handle

[Jesse Thompson]

Hello, this is Jesse with Webformix.

We are managing an Asterisk installation for residential VOIP service, and
we are having a problem where all inbound calls to DIDs which are assigned
to us by our wholesaler but not yet assigned to a downstream customer get
caught in a routing loop.

** For example: we get assigned DID block 1230-1239 and only 1230-1233 are
given to our customers, then our routing logic sends inbound calls to 1234
back to upstream, which bounce back to us again, tying up all our trunks
before emitting an error.

When we recognized the problem I automatically added ael commands to route
all known unassigned numbers to a friendly error message, but that is a
clumsy approach and the larger issue remains that if we get routed a call
for a number we didn't expect — due to provisioning mistake, premature
porting, or mis-routing at our wholesaler — we still need to avoid a routing
loop.

** For example, we have block 1230-1239, and upstream sends us a call for
4321 for no reason at all.. we're not specifically failing that DID so we
still get a routing loop.

What I would like is to somehow identify all inbound calls (originating from
upstream) that are not terminated inside our network, and give them the
friendly error. Calls originating from our customers should get routed
upstream, but calls originating upstream should not bounce back upstream
without an intervening new Dial command.

** For example: we want...
upstream calls customer @ 1230, rings customer
upstream sends us call for 4321, we play an error
customer calls customer @ 1230, rings customer without bothering upstream
customer calls 4321, call bubbles upstream.
anyone calls customer @ 1233, which has unconditional forwarding set to
4322. Via new Dial command, call should route upstream.

The trouble is that, to our knowledge, all calls from local clients and all
calls we get from upstream have to pass through a context we call "clients"
that routes calls to specific local clients. Local calls can't be sent
upstream until after they've run this gauntlet, and inbound calls can't be
failed until they have been matched against same patterns, but after those
matches it's no longer clear how to separate the remotely sourced calls into
an &Unavailable() bin and send the locally sourced calls upstream.

Here is a simplified version of our configs to give you an idea of the tack
we are presently taking.

Thanks guys! :)

- - Jesse Thompson
Webformix Telephone Services

--------------------------------------------------------------------

== sip.conf
[general]
context=clients; default context for all calls

register => skdfjh at peer.upstreamVOIP.com

[upstream]
type=peer
host=peer.upstreamVOIP.com
username=dfjhjkb
secret=redacted
context=clients; context for all inbound calls
call-limit=8

[residential]
type=friend
host=dynamic
context=local

(SIPcust1)[residentia] ; SIP customer name
username=SIPcust1
mailbox=SIPcust1
secret=redacted

; and other sip customers


== extentions.ael
context local
{
  // Does some local cleanup, strips leading 1 off number, _N11, star codes,
fun stuff
  includes { clients; };
}

context clients
{
  custDID1 => Dial(SIP/SIPcust1,35);
  custDID2 => Dial(SIP/SIPcust2,35);
  custDID3 => Dial(SIP/UNCforwardNumber at upstream,120); // inbound calls to
forwarding customers should route back upstream
  unassignedDID => &Unassigned();

  _NXXNXXXXXX => Dial(SIP/${EXTEN}@upstream,120); // numbers not handled
here get routed upstream....
  // ... which is a problem if those calls originally came *from* upstream.
:(
}

macro Unassigned() // Audio message played for unavailable numbers, not sure
if there's a machine-friendlier error approach or not. :)
{
  PlayBack(ro_sit);
  PlayBack(unassigned);
  PlayBack(5413);

  PlayBack(ro_sit);
  PlayBack(unassigned);
  PlayBack(5413);


  HangUp();
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110601/3580c506/attachment.htm>