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'; '[email protected]'
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:[email protected]] On Behalf Of Nathan
Anderson
Sent: Saturday, March 23, 2019 7:10 PM
To: 'Ryan Delgrosso'; '[email protected]'
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 sou
rces 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:[email protected]] On Behalf Of Ryan
Delgrosso
Sent: Thursday, March 21, 2019 8:56 AM
To: [email protected]
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
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
