Call Loop Between SIP Providers

[jonathanblack]

We have a situation where we have two SIP providers coming across a data connection.  We're using a 908e to interface between this and our legacy PRI equipment (internal voice servers, basically acting as a PBX).  The problem is this:  If one SIP provider routes a new phone number to us, but we don't have the number provisioned in our voice server/PBX, the 908e will route the call to the other SIP provider, creating a call loop, which quickly shuts down our service.  We initially created rejects on the opposite SIP (voice grouped-)trunk for each phone number; however, since we're a service bureau, we have hundreds of numbers, so maintenance of this is tedious.  Also, if we get a new number pointed to us by accident it can create the loop which brings down our service for all other phone numbers.

Based on what I've read, we should be able to use a permit list, and restrict calls from being accepted by one SIP trunk when they originate on another SIP trunk.  In pursuit of that, I created the following:

voice trunk-list PRI

  trunk T02

  trunk T03

!

voice trunk-list SIP

  trunk T01

  trunk T04

!

voice trunk T01 type sip

  description "SIP to OSN 1"

  match dnis "1-NXX-NXX-XXXX" substitute "011-1-NXX-NXX-XXXX"

  match dnis "NXX-NXX-XXXX" substitute "011-1-NXX-NXX-XXXX"

  sip-server primary X.X.X.X

  codec-group Compressed

!

voice trunk T02 type isdn

  description "PRI to PBX 1"

  resource-selection linear descending

  connect isdn-group 1

  modem-passthrough

  rtp delay-mode adaptive

!

voice trunk T03 type isdn

  description "PRI to PBX 2"

  resource-selection linear descending

  connect isdn-group 2

  modem-passthrough

  rtp delay-mode adaptive

!

voice trunk T04 type sip

  description "SIP PacWest"

  sip-server primary X.X.X.X

  sip-server secondary X.X.X.X

  codec-group Compressed

!

voice grouped-trunk OSN

  description "SIP to OSN 1"

  trunk T01

  accept $ cost 10

  accept NXX-NXX-XXXX cost 0

  accept 1-NXX-NXX-XXXX cost 0

  permit list PRI

  !deny all other trunks

  !deny all other ani

!

voice grouped-trunk PRI

  description "PRI to PBX 1-DV5"

  trunk T02

  accept $ cost 0

  permit list SIP

  !deny all other trunks

  !deny all other ani

!

voice grouped-trunk PACWEST

  trunk T04

  accept 800-NXX-XXXX cost 1

  accept 888-NXX-XXXX cost 1

  accept 877-NXX-XXXX cost 1

  accept 866-NXX-XXXX cost 1

  accept 855-NXX-XXXX cost 1

  accept 1-855-NXX-XXXX cost 0

  accept 1-866-NXX-XXXX cost 0

  accept 1-877-NXX-XXXX cost 0

  accept 1-888-NXX-XXXX cost 0

  accept 1-800-NXX-XXXX cost 0

  accept NXX-NXX-XXXX cost 400

  accept 1-NXX-NXX-XXXX cost 400

  permit list PRI

  !deny all other trunks

  !deny all other ani

!

voice grouped-trunk PRI2

  description "PRI to PBX 2-DV3"

  trunk T03

  accept $ cost 0

  permit list SIP

  !deny all other trunks

  !deny all other ani

(I do still have quite a few reject entries for specific numbers on various trunk groups, but have excluded them here for the sake of confidentiality.)

However, the carrier is still claiming that they are seeing occasional call loops.  Am I missing something?  Do the accept commands conflict with the permit commands?

[jayh · Accepted solution]

The configuration you show should work.  Is it possible that either PBX is forwarding calls back out to the TA900?  Or one PBX sending a call back to the other and then back out?

Permit and accept don't conflict.

accept : If a call arrives to the unit with the destination pattern matching this string, then this trunk will accept the call.  Prefer the lowest cost.

permit : Only permit routing calls to this trunk group if the source ANI or trunk is in this list.  Otherwise deny the use of this trunk group.

You could put an explicit deny for the SIP trunk list on the SIP trunk group but it theoretically shouldn't be needed. 

[jonathanblack]

Thanks for the confirmation.  The carrier is now backpedaling and saying that maybe the multiple identical calls are just due to a retry from the far end, rather than a loop.  I don't know of a way to prove this either way without having a trace going while the alleged loop occurs (and we cannot replicate the problem on demand).

By the way, we confirmed that the issue was not on the PBX side.  The PBX is just rejecting the call as unallocated.