February 2019 - VoiceOps - lists.voiceops.org

ANIs flagged as telemarketer/spammer/scammer
by abalashov＠evaristesys.com Nov. 15, 2021

Nov. 15, 2021

Hi, So, of course, it is a known problem in the legitimate side of the lead engagement call centre, survey, etc. business that ANIs get flagged as "telemarketer" pretty quickly and start showing up that way on people's phones. Your normative viewpoint on that may vary depending on what you think of lead gen calls, but regardless, a reasonable person would differentiate between: (1) Legitimate outbound dialing operations that are following up with leads who provided their phone number and agreed to be called (at least, as a matter of clicking "accept" on _something_), or for some other legitimate mass-dialing purpose, and who actually own the DID inventory from which they present local-market ANIs and can in fact be reached on those numbers; (2) Illegal spammers who use fake ANIs and call people who did not in any way consent to being called by them. I am trying to learn a bit more about how this is done and what a legitimate, above-board business can do about it. Ignoring the factor of third-party call-screening apps (which most people with a mobile don't use), where is this generally implemented? As I understand it, T-Mobile do it on the network level. I have T-Mobile myself, and probably 2/3rds of unfamiliar numbers, including quite legitimate ones, show up as "Scam Likely" ? I know that's come up on the list before. AT&T displays "Telemarketer"; do they do it that way too, or do they use a Google Android feature for that which they enable as part of their carrier defaults for carrier-issued phones? What about other carriers and Android? As far as I know, Apple don't do anything like this. Do people with iPhones just not receive this "service"? How does that work? Asking where the central, or the most influential authority lies and who provides it goes to the heart of the real question, which is: what can a legitimate business do if their number has been blacklisted this way? As I understand it, the maintainers of these lists, along with the criteria for getting on them, are elusive and inscrutable, and there's really no recourse and no appeals process. I furthermore understand that this has led to the widespread approach of rotating ANIs, but that's a losing battle; they get flagged too. I imagine it won't be long before the criteria for "Scam Likely" are just "number appears to call lots of numbers in this rate centre and otherwise hasn't been around very long". But this is all just conjecture on my part; I really don't know much about how my carrier, anyone's carrier, or some BigCo that's behind my mobile OS decides that a call is a "telemarketer" or "scam" call. If anyone can shed some light on how this really works and what, if anything can be done about it, I would be most appreciative. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

8 14

Shoretel/Mitel phone systems and generic SIP trunking
by nelsonh＠socket.net Feb. 14, 2019

Feb. 14, 2019

Hello, We've had a small but growing number of customers or leads with Shoretel/Mitel phone systems that want SIP trunking, but when we begin trying to setup and test trunking, we're being told they can't configure how the SIP trunking behaves, and that for the vendor to get support, the ITSP needs to be signed up for their Center of Excellence and qualify our SIP trunking with them. One customer says they are using a "MiVoice Business vMCD or 3300 with a MBG Proxy server in server-gateway", the other a "MiVC_Connect_Build_21.90.4127.0". I'm told a couple others are using ShoreTel phone systems, but I haven't seen details for those yet. We're mostly just using Broadworks for SIP trunking, and we've provided SIP trunking for Mitel systems in the past. Does anyone have experience with continuing to make these systems work with generic SIP trunking, or experiences like I've described above? Thanks, -- Nelson Hicks Network Operations SOCKET (573) 817-0000 ext. 210 nelsonh at socket.net

3 2

RTP Proxy TTL Behavior
by ciscoplumber＠gmail.com Feb. 11, 2019

Feb. 11, 2019

We are occasionally running into a situation where our IP Header TTL expires in transit for RTP streams. It has been our observation that our SBC B2BUA that anchors media is not resetting the TTL on RTP packets but is on SIP packets. Is there a standard expected behavior for how SBC B2BUA with media anchoring might handle RTP packets? I would have thought if it resets the SIP packet TTL it would also reset the RTP packet TTL. Thoughts?

2 2