I have not had any success getting Alarms to work properly going through Analog to SIP conversion. Most of the alarm devices expect to be able to transmit at 33.6 or higher but modem traffic over sip is generally at best only able to work at 14.4 at G.711 speeds. This is a limitation to G.711 specifically having to do with the number of packets the available bandwidth allows. Most upstream carriers automatically convert modem tones to G.711 because G.711 is the best suited protocol for FAX survivability. And since T.38 is specifically designed around FAX tones and not regular modem tones using it is out as well. I would recommend for alarm lines to use good old fashioned local Telco analog lines, they also have the added benefit of providing their own power so they do not go down in a power outage scenario. Sorry I don't have the answer to original question not sure if would help or not but I am kind of doubtful based on what I have learned about SIP and modem traffic.
The alarm companies are really doing it wrong if they're going to higher baud rates. Alarm data is very low throughput. Subscriber number and zone in alarm, maybe a checksum, battery voltage, etc. The entire message is going to be under a kilobyte. By going to higher baud rates they suffer longer training times and higher likelihood of the message failing. That's why dial-up credit card terminals are 2400 baud. They'll train and send the entire transaction before a 33.6 modem can even sync up.
I'm sorry, I guess I should have been more clear. I just need PRI input to FXS ports with FGD.
What I'm doing is going from our PRI out the FXS ports on the TA 916e (no SIP involved). Once I had that working I realized the surgard receive (in our particular config) needs FGD to pulse out *ANI*DNIS*, like our Atlas 550 does.
My understanding is that this is unsupported on the TA 916e, though I've seen in a previous post that it will work even though unsupported - I'm not smart enough to even experiment with that.
Speaking to some lady in Adtran support half a year ago I was told that there was something I could use maybe the TA 600? to introduce feature group D ahead of the TA 916e. At least that's what I think she was saying. I can't seem to find my notes, and I'd like to verify whether or not there's something I can do that includes the TA
916e's before I look for some other solution.
Sorry I didn't read the whole question properly, my bad. I made the mistake of automatically assuming SIP was involved somewhere. The TA 900 does have what appears to be limited support for Feature Group D on the PRI side according to the AOS feature Matrix it is supported on the 900 series on PRIs emulating the network role. The Netvanta 644 (Now Discontinued) says in the Matrix it is supported on both the User and Network Emulation roles, however it does not have analog support so you would have to use another device to convert T1 to Analog which may not help your issue in the first place . So depending on which role your PRI is configured as may depend on which option it needs. Beyond that the only thing I could recommend is maybe getting a call going with Adtran Pre-Sales support and see if they can point you in the right direction or possibly there is another line of product that would work better in their carrier line of products.