[VoiceOps] Request for Opinions: High density ATA's

Tue Mar 26 17:39:43 EDT 2019

Oh, I also meant to mention the following:

Though I haven't tested use of RPID on inbound, I have tested it on outbound and it works.

If you don't even want to bother with registration at all, and you anticipate that each TA will have a static IP, these TAs support that, too ("Register Mode" > "Service Provider").

-- Nathan

-----Original Message-----
From: Nathan Anderson 
Sent: Tuesday, March 26, 2019 2:36 PM
To: 'Ryan Delgrosso'; 'voiceops at voiceops.org'
Subject: RE: [VoiceOps] Request for Opinions: High density ATA's

So I can confirm that, with the latest firmware, it is possible to have these Yeastar TAs perform a single registration to a SIP proxy/registrar and still have each FXS port be individually addressable.

Though it has been a long time, thinking back, I'm almost sure this wasn't the case when we first started using these, which is why I wasn't sure (I've never used them in this way, although I have *wanted* to).  It looks like at some point they addressed this, and either I wasn't aware, or if I had become aware at the time they released it, I didn't trust it enough based on past experience to put it into production anywhere.  (The lack of this feature may have also been one of the things I was hoping to address by rolling my own firmware.  Again, this was a long time ago...)

The trick is to...

1) ...set the "Register Mode" for the "VoIP Server" to "Template Register"
2) ...set the "DID Number" field for each FXS port to a unique value
3) ...address that particular FXS port in the INVITE by using its given "DID Number" in the "To:" header

If under "SIP Settings" > "Advanced Settings" you enable "trust" for "Remote Party ID", then you can probably address the FXS port by sending its "DID Number" in the RPID header instead (I haven't tested this yet).

That addresses inbound.  For outbound, you can control what it uses for the "From:" header in the INVITEs that the TA sends out on a per-FXS basis by making sure to set each FXS port's "Caller ID Number" field.  Leave the "From User" setting/field black for the "VoIP Server" in question (which will globally override the "From:" and "Contact:" fields) UNLESS you also enable "SIP Settings" > "Advanced Settings" > enable "send" for "Remote Party ID", which will cause it to put the FXS CLID in the RPID header.

I haven't found a way to get it to use PAI instead of RPID, and indeed it may not even be possible given the age of the version of Asterisk we are dealing with here (not sure there was any PAI header support in 1.6.x, and even if there was, the web GUI here does not seem to expose it).  But I would think that if PAI was a hard requirement of yours, it would be easy enough to deal with via a small SIP proxy sitting between the TAs and your main registrar that rewrites RPID to PAI.

Good luck,

-- Nathan

-----Original Message-----
From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Nathan Anderson
Sent: Saturday, March 23, 2019 7:10 PM
To: 'Ryan Delgrosso'; 'voiceops at voiceops.org'
Subject: Re: [VoiceOps] Request for Opinions: High density ATA's

This is a little "outside the box" maybe, but you can get 32 ports of FXS from the Yeastar TA3200 (https://www.yeastar.com/fxs-voip-gateways/).  I've only ever used the 4- and 8-port versions which aren't rackmount and only have single-pair RJ11s, but supposedly the 1U 16-, 24-, and 32-port ones have both RJ11s on the front *and* Amphenols/RJ21s on the back.  And the 3200 can be had brand-new for about ~USD$550/ea shipped all day every day, if you know where to look...so the only way I know how to beat these $-wise would be some refurbished Adtran TA924e (which are arguably a more solid unit anyway, both on hardware and software side).

Though the price is right, these units definitely have their quirks.  I'm not 100% sure they can do single registration per-unit instead of per-port...I'll pull one of my small-port-count ones out to test.  They actually run Linux + Asterisk (ancient and very hacked-up/custom 1.6.2.x build as I recall) and for a while I contemplated building a custom ROM of my own for it from source in order to work around my own irritations, but last time I'd looked they hadn't released their internally-developed patches for either the kernel, Asterisk, or their build environment and I couldn't get them to budge on this, so I sicced the FSF and Digium legal teams on them...I think their attitude may have changed after that but I haven't had time to pursue further.  Also, even if I get the patches, it appears that their analog interfaces are not based on Digium DAHDI reference designs like so many others, but is custom hardware (+ software drivers which they may not have any obligation to release sources for, depending on how their drivers actually link up to DAHDI itself), so it may be a fool's errand regardless.

-- Nathan

-----Original Message-----
From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso
Sent: Thursday, March 21, 2019 8:56 AM
To: voiceops at voiceops.org
Subject: [VoiceOps] Request for Opinions: High density ATA's

I have found myself with a number of hospital opportunities and 
servicing the staff with IP phones is a no-brainer, however there is the 
need for multi-hundred room connectivity for patient room phones and the 
staff mandate is to keep it analog because "ip phones there will grow 
legs".

I am looking for 24+ port density with amphenol connectors, and ideally 
some kind of rudimentary internal routing so i dont need to register all 
24 discreet ports and can route by some header (to or uri) within a 
single registration.

Right now im looking at AudioCodes and the Sangoma Vega series. Obihai 
would be my natural choice here but don't have anything that fits my 
density requirements.

Any opinions on these or others I should consider. Anyone deploy these 
and can speak to the experience?

Thanks in advance

-Ryan

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops