These also work great http://www.grandstream.com/sites/default/files/Resources/datasheet_gxw42xx_e... Telephone Interfaces GXW4216/4224/4232: 16/24/32 x RJ11 & 1/1/2 50-pin Telco connectors GXW4248: 2 50-pin Telco connectors -----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Michael Palmer Sent: Thursday, March 21, 2019 11:50 AM To: Ryan Delgrosso <ryandelgrosso at gmail.com> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Request for Opinions: High density ATA's I've got a few Adtran 6336 with 24 port FXS on it. They work fine. One has been in production for 7 years! They connect back to an asterisk system in most of our use cases, but would be fine with any SIP system I'm sure. You can register each line, or setup a trunk and route to an analog port. We also use Audiocodes 4 and 8 port FXS's, and they operate basically the same, they're both just "fine" for me, nothing really special about them. -Michael ----- Original Message ----- From: "Ryan Delgrosso" <ryandelgrosso at gmail.com> To: voiceops at voiceops.org Sent: Thursday, March 21, 2019 10:55:37 AM 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

Honestly just for signaling efficiency. I do everything with TLS, and maintaining 900+ TLS sessions all the time is wasteful, especially for endpoints that will be infrequently used. I would prefer to register a single signaling trunk per device. On 3/21/2019 9:03 AM, Matthew Yaklin wrote:

When I read your email the first thought that popped into my head was a bunch of Calix E5-111s used for pennies on the dollar. They are simply ADSL/POTs boxes. 48 ports of pots. But each line registers individually. But at least the box is stupid dumb and you handle everything on the switch side. I would not want anything complex on site barring a distinct requirement. Of course just turn off the ADSL.

Why do you prefer that the lines do not register individually? Do you have a requirement for so much box intelligence in their closets?

*Matthew Yaklin* Network Engineer *FirstLight* 359 Corporate Drive ? Portsmouth, NH 03801 Mobile 603-845-5031 myaklin at firstlight.net | www.firstlight.net /This email may contain FirstLight confidential and/or privileged information. If you are not the intended recipient, you are directed/ /not to read, disclose or otherwise use this transmission and to immediately delete same. Delivery of this message is not intended/ /to waive any applicable privileges./

------------------------------------------------------------------------ *From:* VoiceOps <voiceops-bounces at voiceops.org> on behalf of Ryan Delgrosso <ryandelgrosso at gmail.com> *Sent:* Thursday, March 21, 2019 11:55:37 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

Just how many pots lines do you need to deliver to one single "closet"? Or do they expect you to pop these boxes on each floor of the facility? Or does all the wiring go to a central telco room? Things like that would shape my decision. Like does this hospital have a central wiring room and they have 400 patient rooms? Which means I might want a single box that can do 400 plus lines. All of a sudden a TA5000 with 20 24port rpots line cards looks really good to me. Matthew Yaklin Network Engineer FirstLight 359 Corporate Drive ? Portsmouth, NH 03801 Mobile 603-845-5031 myaklin at firstlight.net | www.firstlight.net This email may contain FirstLight confidential and/or privileged information. If you are not the intended recipient, you are directed not to read, disclose or otherwise use this transmission and to immediately delete same. Delivery of this message is not intended to waive any applicable privileges. ________________________________ From: Ryan Delgrosso <ryandelgrosso at gmail.com> Sent: Thursday, March 21, 2019 12:17:28 PM To: Matthew Yaklin; voiceops at voiceops.org Subject: Re: [VoiceOps] Request for Opinions: High density ATA's Honestly just for signaling efficiency. I do everything with TLS, and maintaining 900+ TLS sessions all the time is wasteful, especially for endpoints that will be infrequently used. I would prefer to register a single signaling trunk per device. On 3/21/2019 9:03 AM, Matthew Yaklin wrote: When I read your email the first thought that popped into my head was a bunch of Calix E5-111s used for pennies on the dollar. They are simply ADSL/POTs boxes. 48 ports of pots. But each line registers individually. But at least the box is stupid dumb and you handle everything on the switch side. I would not want anything complex on site barring a distinct requirement. Of course just turn off the ADSL. Why do you prefer that the lines do not register individually? Do you have a requirement for so much box intelligence in their closets? Matthew Yaklin Network Engineer FirstLight 359 Corporate Drive ? Portsmouth, NH 03801 Mobile 603-845-5031 myaklin at firstlight.net<mailto:myaklin at firstlight.net> | www.firstlight.net<http://www.firstlight.net> This email may contain FirstLight confidential and/or privileged information. If you are not the intended recipient, you are directed not to read, disclose or otherwise use this transmission and to immediately delete same. Delivery of this message is not intended to waive any applicable privileges. ________________________________ From: VoiceOps <voiceops-bounces at voiceops.org><mailto:voiceops-bounces at voiceops.org> on behalf of Ryan Delgrosso <ryandelgrosso at gmail.com><mailto:ryandelgrosso at gmail.com> Sent: Thursday, March 21, 2019 11:55:37 AM To: voiceops at voiceops.org<mailto: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<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops

Good on ya for doing the right thing in calling them out on it anyway Nathan! Great story :) I've only used the single and dual port versions of these Yeastar boxes but I also discovered they were linux & Asterisk and I've found them to be quite reliable in the small numbers I've used. Pete

On 24/03/2019, at 3:09 PM, Nathan Anderson <nathana at fsr.com> wrote:

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 sou rces for, depending on how their drivers actually link up to DAHDI itself), so it may be a fool's errand regardless.

-- Nathan

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