I know this has been discussed on some old posts, I guess I'm looking for some fresh thoughts on it.
I picked up a 3rd gen Total Access 916e attempting to replace my Atlas 550 to break analog lines off my PRI for Sur-Gard alarm receivers. The alarm receivers require Feature Group D to pulse out *ANI*DNIS* to the alarm receivers, and apparently the 900e series isn't capable of this (although I saw one post say they've managed to do it with no other information).
I don't know if my recollection is right or not but I was told by one person that I could add (I think) a TA 600 ahead of the 916 to take the PRI and add FGD to the T1 input of the 916e - or something like that...
So, I guess I'm looking for a good, solid answer on what my options are for taking our PRI and breaking out analog lines with FGD, and whether or not I can still use the TA 916e in some way, or if I should just abandon the 916 and take another route completely.
Any help is appreciated, Thanks!
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.
John Wable
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.
John,
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.
Thanks,
Gary
Gary,
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.
John Wable