and yes the DSP is healthy and present. I'm very aware of that trouble
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.
1 of 1 people found this helpful
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.
Thanks Jayh. We'll look into the SABR - seems this may be the scenario. Not seeing a codec missmatch.
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.
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
accept 212-NXX-XXXX cost 0
accept [other eastern NPAs] cost 0
accept $ cost 100
voice grouped-trunk WEST
accept 213-NXX-XXXX cost 0
accept [other western NPAs] cost 0
accept $ cost 100
voice grouped-trunk PRI
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.