voice grouped-trunk config questions - fail-over/backup

[Anonymous]

I have a question about the "voice grouped-trunk" configs that I can't seem to find on any AOS documentation.

See code below - but basically I have 2 trunks configured in a group, which should work as primary/primary (or primary/secondary) to whichever one is available and for fail-over operations.

Depending on the firmware I occasionally get the error "RTP resource unavailable or SDP negotiation failed."

Is there a preferred method for having 2 trunks configured to a single group? Is this documented somewhere that I'm (likely) overlooking?

!

voice trunk T01 type sip

  description "New York"

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

  sip-server primary xx.xx.xx.xx

  codec-list "High Bit Rate" both

!

voice trunk T02 type isdn

  description "PRI to Customer PBX"

  resource-selection circular descending

  connect isdn-group 1

  no early-cut-through

  rtp delay-mode adaptive

!

voice trunk T03 type sip

  description "Los Angeles"

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

  sip-server primary xx.xx.xx.xx

  codec-list "High Bit Rate" both

!

!

voice grouped-trunk PRI

  trunk T02

  accept $ cost 100

!

!

voice grouped-trunk SIP

  trunk T01

  trunk T03

  accept $ cost 0

!

!

voice grouped-trunk BACKUP

  trunk T03

  accept $ cost 200

!

!

voice user 13144272564

  connect fxs 0/1

  no cos

  password encrypted "xxxxxxx"

  no call-waiting

  did "1234567889"

  no special-ring-cadences

  no message-waiting

  sip-identity 1234567889 T01 register auth-name "1234567889" password encrypted "xxxxxx"

  sip-identity 1234567889 T03 register auth-name "1234567889" password encrypted "xxxxxx"

  sip-authentication password encrypted "xxxxxx"

  modem-passthrough

  t38

  no echo-cancellation

  codec-list FAX

!

[Anonymous]

and yes the DSP is healthy and present. I'm very aware of that trouble

[Anonymous]

I should also specify that I'm seeing this RTP resource unavailable or SDP negotiation failed. message on INBOUND calls, not outbound.

We can manipulate the outbound calls via cost on the trunks...

just seems that the INBOUND calls are coming in, then trying to go out the wrong trunk instead of to the FXS line... or something along those lines.  Not much info on debugs.

[jayh]

You've got something odd in your configuration as the PBX is also accepting all but with a cost of 100, between your primary and backup. On the voice grouped-trunk PRI, I'd put just the DIDs that the PBX is configured to accept, and set it to cost 0.

Also, I'm not sure if your BACKUP group will ever be hit, as T03 is also in the SIP group at cost 0.

Seeing as your trunks are "Los Angeles" and "New York" presumably for geographic redundancy, in this scenario, you might try something like:

voice grouped-trunk EAST

trunk T01

accept 212-NXX-XXXX cost 0

accept [other eastern NPAs] cost 0

accept $ cost 100

voice grouped-trunk WEST

trunk T03

accept 213-NXX-XXXX cost 0

accept [other western NPAs] cost 0

accept $ cost 100

voice grouped-trunk PRI

trunk T02

accept 312-555-23XX cost 0  [Just the DIDs that the PBX is expecting]

You obviously don't need to list every NPA as the wildcard at cost 100 will catch all calls that don't match the more specific entry.

I also believe that the algorithm is such that once a trunk selection has been made and the call delivered, RTP and SDP issues aren't going to route-advance to the next trunk. It will only route-advance if it gets a SIP timeout, 404, 503, etc. Could it be that your codec list doesn't line up with those of one of your carriers? Are these possibly fax calls where T38 isn't being negotiated or the carrier is forcing G.729?

Also, if the Adtran is directly registering to both carriers, does your fax line on the FXS also need to register with the carriers? The switchboard in the TA900 should be capable of routing those calls to the registered trunks.

Lastly, can you reproduce the problem? A "debug sip stack messages" and "debug voice verbose" on a failed call would help narrow it down.

[jayh]

This is only on inbound fax calls? That's something completely different. What does your codec-list FAX look like? That sounds like it could be the issue.

If you're also seeing it on inbound calls to the PBX, I'd definitely tweak the voice grouped-trunk PRI to have only the DIDs programmed into the PBX, and at cost 0. Most specific match wins, so this will ensure that calls for the PBX are routed to the PBX.

You'll probably want to implement SABR to prevent calls coming in one SIP carrier from going out the other. This can cause operational issues as well as economic ones if something breaks upstream and you unwittingly become a transit link between your two SIP carriers.

[Anonymous]

Thanks Jayh. We'll look into the SABR - seems this may be the scenario. Not seeing a codec missmatch.

[jayh]

I think that limiting the accept numbers on the PRI to just the DIDs that the PBX is programmed to accept will fix most of it. When this happens, are they real calls, or are you just seeing log entries?

If one carrier sends you a call for a number that doesn't exist in your system it could indeed loop back to the other carrier (who will punt it to the originating carrier, then back to you, etc.) This will result in resource starvation. It may not show up as a SIP loop because it'll traverse the traditional PSTN between the carriers. SABR will fix this. Essentially permit only the PRI trunk and the FAX DID(s) outbound to each carrier trunk.