- VoiceOps - lists.voiceops.org

Keyless VoIP Phone
by kuylenj＠eastex.com March 29, 2019

March 29, 2019

Any suggestions for a SIP handset without any keys? This will be setup similar to a lobby phone or emergency phone. Thanks Important/Confidential: This communication and any files or documents attached to it are intended only for the use of the person(s) or entity to which it is addressed. It contains information that may be confidential and exempt from disclosure under applicable law. If you are not the intended recipient of this communication, you are hereby notified that the copying, disclosure, distribution, storage, retransmission or other use of this communication is strictly prohibited. If you have received this communication by mistake, please notify the sender immediately and destroy all forms of this communication (electronic or paper).

5 5

Request for Opinions: High density ATA's
by ryandelgrosso＠gmail.com March 26, 2019

March 26, 2019

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

9 13

Request for Opinions: High density ATA's
by nathana＠fsr.com March 26, 2019

March 26, 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

1 0

Canadian (LATA 800) Calls routed to wrong CIC / Verizon contact?
by ivan.kovacevic＠startelecom.ca March 25, 2019

March 25, 2019

Wondering if anyone has come across discrepancies in call rating between originating carrier and their routing (CIC) carrier. So we have a scenario where calls with Canadian ANI are being routed to our non-Canadian CIC (US Carrier). Our US carrier is treating these calls as Canadian, based on ANI. The carrier (Verizon) handing calls off to our US carrier (instead of to our Canadian carrier) does so based on a different criteria (probably fact that they originate on one of their trunks in the US). So one of the two carriers here is wrong - either Verizon who should not be handing calls over to our US carrier, or our US carrier who should not be rating the calls as Canadian. This is what I got from our US carrier: *"TF rating jurisdiction will use the dipped LRN of the CPN first, then moves to the CPN (if no LRN present), then the orignum (if no CPN) and lastly the NPA-NXX of the originating FG-D trunk. Given that all of the calls I?m seeing coming out of this Pittsburgh area have a CPN value, we?d be dipping that CPN to figure out where it was coming from, and if that returns a Canadian number, we?d treat it as Canadian origination. That 504613 number would only be used if we got no CPN at all on the call."* The practical impact is that our cost is twice as high for our Canadian calls with the non-Canadian carrier. I am sure there is potential for this sort of discrepancy at other LATA level (if someone is using TF LCR or LATA based routing). If there is a Verizon contact on the list, I would be curious to get their opinion on why these calls (have examples willing to share) are rated as US, and how is Verizon's rating different from our US carrier. Thanks, <http://www.startelecom.ca> *Ivan Kovacevic* *VP Client Services* *STAR TELECOM* *5915 Airport Rd. Suite 610, Mississauga, ON L4V 1T1 Canada**www.startelecom.ca <http://www.startelecom.ca>* -- NOTE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and destroy all copies of the original message.

1 0

AT&T Local LRN Issue - Maybe?
by mwiles＠akabis.com March 25, 2019

March 25, 2019

Anyone with AT&T local?ish to Charlotte NC that could help with what appears to be stale LRN that?s causing a customer to go nuts? Thanks! Mark mwiles at akabis.com<mailto:mwiles at akabis.com>

1 0

Verizon caller ID name service
by caalvarez＠gmail.com March 14, 2019

March 14, 2019

It appears that Verizon Android phones now come with a Verizon-specific app that shows caller name. It also looks like this probably doesn't do a proper dip, but has cached data. Can anyone confirm that? A customer is reporting a CNAM error, but everything looks good to us. Their only tests have been to two Androids on Verizon (well, and an iPhone, but that doesn't show a name).

1 0

West ERS SOAP API
by nathana＠fsr.com March 13, 2019

March 13, 2019

Anybody here use West's ERS system for E911 ALI provisioning and routing to PSAPs? Of those who do, is anybody using their SOAP API to programmatically do the provisioning? I feel like I'm getting nowhere with the contacts I have over there so far, and I'm tearing my hair out. I was provided with a manual and set of WSDLs, but getting our account provisioned over there correctly has been a minor headache, the manual seems incomplete, and when I make test calls against certain functions, I find that the service defined in the WSDL is bound to a URL that is simply returning HTTP 404. I mean, seriously... I'd love to talk to someone (on-list or off-list) who has successfully performed this integration so that I can get clarification on the parts I'm missing and that West hasn't bothered to document or communicate to me. Thanks, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

1 0

PSTN/Mobile termination with DTLS SRTP (WebRTC)
by miconda＠gmail.com March 11, 2019

March 11, 2019

Hello, anyone aware of providers that supports DTLS-SRTP termination/origination of the audio? I can setup a Kamailio+RTPEngine box in my side, but it would save a bit in complexity/operations for small deployments to avoid additional systems if both far ends support such streams already. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com

1 0

911 and large numbers of corporate home phones
by caalvarez＠gmail.com March 7, 2019

March 7, 2019

I'm wondering what people are doing, and their interpretation of the laws, with companies where they have large numbers of remote (home) users. So far we have only a few really, and we provide 911 for each phone's own CLID. Now we have a customer who wants to have a very large number, PLUS have an office handset, home handset, softphone on a computer, and softphone on a mobile. It makes little sense to put 911 service on each of these.

2 2

Growing difficulties porting DIDs out of major VoIP carriers
by orenyny＠gmail.com March 6, 2019

March 6, 2019

Hello, I am hoping that someone may be able to shed some light as to the difficulties mobile carriers have to port DIDs away from major VoIP carriers such as Bandwidth and Onvoy. The problem does not seem to be on the VoIP providers. In most of the cases, they do not even receive an LSR. The mobile carriers seem to be asking for a CSR multiple times but never submit an LSR, then they tell the EU that the port request has failed. In another case, when the DID is with Bandwidth, the ATT system tells the customer that the number is with LOCKED with Google Voice and cannot be ported. I wonder who builds these faulty systems for these corporations? Any advice is appreciated. Oren

5 5