[VoiceOps] ADT Alarms Special Dialing?

[Nathan Anderson]

Colton Conor write:

> However, it sounds like inband is the best anyways for DMTF for alarms,
> so I am not sure this will help since Adtran only supports inband already.

Yes, that was precisely my point: you don't need T.38 and RFC2833 support in your customer-facing switch, just so that you can go into the config and flip those settings off, because they are already "off" by virtue of *not existing*. :)

I think we are getting far afield by concentrating on the TA5K at all.  It is also (most likely) pointless to worry about how the peering between the TA5K and Broadsoft is configured on the Broadsoft side (short of a Broadsoft software bug or a very glaring configuration error) because since the TA5K cannot support either protocol, no session between the Broadsoft and the TA5K will ever successfully negotiate the use of those protocols.  The TA5K will never generate or accept a T.38 INVITE, nor will it advertise RFC2833 support in the SDPs it sends to the Broadsoft.  It's possible that if one side tries to initiate the use of one or the other that problems could arise of both sides do not deal with such a request gracefully, but I think that would be more likely to result in a complete call drop mid-call.  (Do a packet capture, though, of an alarm monitoring session between the Adtran and the Broadsoft.  It could be revealing.)

So leave the Adtran out of it for now.  The problem is most likely to be upstream.  If you are getting your service provided to your Broadsoft via a telecom wholesaler, and that service is delivered to your Broadsoft via SIP, and then they themselves have both SIP and TDM peering with other providers, then the problem could be between your Broadsoft and them, or between them and the other providers they peer with via SIP.  If I were a betting man, I'd put my money on the former.

Again, you'd do best to capture multiple call legs of a live session.  Have an alarm system make a call, and insert yourself both between the Adtran and the Broadsoft, and between the Broadsoft and your provider.  Then check for the various things that have been talked about here (T.38 re-INVITE, advertisement of OOB DTMF by either party, transmission of OOB DTMF on either leg of the call regardless of whether it was successfully negotiated during call set-up, etc.)  If any of these guesses were right on the money, you should be able to spot the culprit pretty fast.  After you figure out *where* it is happening, only then can you devise a plan of attack.

-- Nathan