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

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>

On 1 Jun 2011, at 22:50, Jesse Thompson wrote:
> 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.
Put this line:

_NXXNXXXXXX => Dial(SIP/${EXTEN}@upstream,120); // numbers not handled here
get routed upstream....

in the 'local' context instead of the other one?.... Letting a carrier
use you as a carrier seems like quite a bad idea generally..

S

(reposted with correct subject line, I think messing up the subject
line last time prevented my question from being read. Cheers :)

On Thu, Jun 2, 2011 at 12:27 PM, Jesse Thompson <jesset at gmail.com>
wrote:
>> Letting a carrier use you as a carrier seems like quite a bad idea
generally..
>
> I think I would agree. :)
>
>
>>
>> _NXXNXXXXXX => Dial(SIP/${EXTEN}@upstream,120); // numbers not
handled here get routed upstream....
>> in the 'local' context instead of the other one?....
>>
>
> So here is where the finer points of Asterisk pattern matching must
> come into play.
>
> All of the customer DID's match the pattern _NXXNXXXXXX. If we put
> that pattern in the local context, then wouldn't that mean that calls
> from a local customer to another local customer would match the
> _NXXNXXXXXX pattern before even trying to match against the specific
> patterns in the "clients" context? We need to be able to route
> local-to-local calls without using two trunks to go back and forth
> through the upstream provider.
>
> Thank you for your input. I know this is a problem most operators can
> get past, so there's got to be just something not lining up quite
> right in my mental model. :)
>
> - - Jesse
>