December 2016 - VoiceOps - lists.voiceops.org

Maintenance for Performance Technologies SEGway
by scott＠socket.net May 17, 2017

May 17, 2017

We have been using a set of PTI SEGway x201s with point code emulation for a number of years now. We also have an unlicensed spare in stock. The maintenance contract renewals are due and the two quotes I've received are quite high. I know of at least one other company that has chosen to drop the vendor maintenance and take care of that in-house. I would like to hear from anyone that is currently using SEGways and find out what they chose to do for maintenance. I would also be very interested to hear of any bad experiences from chosing the in-house option. Thanks. Scott Stratman Network Facilities Manager SOCKET 573-999-4376 scott at socket.net 1-800-SOCKET-3 www.socket.net

3 2

Long PDD to Israel
by sahin＠eurecom.fr Dec. 23, 2016

Dec. 23, 2016

Hi, some aspects of what you describe looks like the effects of Over-The-Top (OTT) bypass. This is a recent type of interconnect fraud, where regular international calls are hijacked and terminated on the OTT application installed on callee's phone. In this case, the gateway between the bypassing transit operator and the OTT network may increase the PDD. However, this effect is usually concealed with a ring tone. That could explain why you have 20+ seconds of ring time, but no connection at the other end. If you would like to read more about this, you can refer to our recent study on OTT bypass: http://s3.eurecom.fr/docs/ccs16_sahin.pdf Best regards, Merve > -------- Original Message -------- > From: Shripal Daphtary <shripald at gmail.com> > Sent: December 21, 2016 9:15:16 PM CET > To: "VoiceOps at voiceops.org" <voiceops at voiceops.org> > Subject: [VoiceOps] Long PDD to Israel > > Hey guys -- long time no email! > > We've been experiencing super long PDD and connection timeouts dialing +972 > (israel). > > we've sent traffic to bandwidth (10-11 seconds of pdd, followed by ring of > 20+ seconds and no connection at the other end > > we've sent traffic to L3 direct and its just a little bit better but still > longer that one would expect. > > i've called several numbers with my ATT mobile (not connected to our switch > in any way) also long pdd or connection times. > > > > Does anyone know if something changed within Israel to cause such long > pdd's? > > seems to be with all many of our carriers. All other international > destinations seem to work fine. > > > thanks! > > shri > > > ------------------------------------------------------------------------ > > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops >

2 1

Long PDD to Israel
by shripald＠gmail.com Dec. 21, 2016

Dec. 21, 2016

Hey guys -- long time no email! We've been experiencing super long PDD and connection timeouts dialing +972 (israel). we've sent traffic to bandwidth (10-11 seconds of pdd, followed by ring of 20+ seconds and no connection at the other end we've sent traffic to L3 direct and its just a little bit better but still longer that one would expect. i've called several numbers with my ATT mobile (not connected to our switch in any way) also long pdd or connection times. Does anyone know if something changed within Israel to cause such long pdd's? seems to be with all many of our carriers. All other international destinations seem to work fine. thanks! shri

1 0

503 usage
by slocoach＠gmail.com Dec. 14, 2016

Dec. 14, 2016

I tend to see a 503 as a symptom of a critical situation (per cpu/cps/license threshold breach). And I would consider 503 spikes a decent canary for a sip trunk coal mine. Others view 503s as business as usual, specifically in LCR arrangements, and don't alarm/study them What's the general idea behind industry best practice? E.g. 503 simply signifies another route should be taken, or 503 is cause for a remedy? Sent from my Windows 10 phone

6 6

Using mobile/SS7/IS-41 data to track a missing person
by ivan.kovacevic＠startelecom.ca Dec. 12, 2016

Dec. 12, 2016

A bit of a deviation from the usual fare for the list, but I hope it is close enough to being on-topic that it doesn?t get dropped. A close friend of mine has asked me whether there is any data or meta-data (aside from device-based GPS info) that would help in tracking a missing person (a relative). The person travelled outside of their home country to Italy and then Malta. Their belief is that the person made contact with someone locally in one or both countries and that they would have used the mobile. This was back in September, so some time has already passed from the last known contact, but they are looking to at least validate their assumptions regarding the last known location, maybe even to the level of the mobile tower ? if this data is available. My high level understanding of mobile internetworking is that once the device attempted to registered on the local, the local network would need to make a query to the ?home? network to allow services (inbound/outbound/etc). So in the least, the home provider would have some sort of trace of which network/country the device is registering at. What would they (or the police which at the locality isn?t very tech-savvy) be asking the mobile provider to investigate/provide? Any other telecom data that they could use ? (They?ve already made requests to access information on Facebook, Yahoo and Google accounts which the person may have used) Any assistance is appreciated and apologies if this is too far off topic. Best Regards, Ivan

1 0

AT&T / Onvoy / Vonage call routing screwup after LNP
by nathana＠fsr.com Dec. 10, 2016

Dec. 10, 2016

So here's a weird one: we took over a small business account from Vonage. Vonage was using Onvoy for origination, and we elected to keep the TNs with Onvoy (through a wholesaler). So the "port" only consisted of Onvoy repointing traffic for those TNs internally away from Vonage and to our reseller, with no LRN change. The weird bit is that we definitely are seeing some traffic for those numbers hitting us, but it's been nearly 72 hours now and some calls are still ringing their Vonage ATAs. I couldn't tell you definitively where the delineation is, but I can tell you, for example, that if I call any of the TNs from my AT&T cell, those calls still hit Vonage, so I can at least reproduce the problem at-will. This is for a local real-estate office, and AT&T is big in our relatively rural market, so even if it turns out that AT&T is the only provider that is affected, that is still a huge percentage of our end-user's client base. And the frustrating bit is that traffic is now effectively being "forked", which is a huge inconvenience for our end-user since they have an old key system with analog trunks and so we have to choose between having our IAD hooked up to their KSU or having their stack of Vonage ATAs hooked up. (For now, we have left the Vonage ATAs in place, and we are forwarding calls that come to us to a single line from the ILEC that this office ended up keeping. I don't know what we would have done if they didn't have that line.) Onvoy swears up and down that everything is configured correctly on their side, and given that we are at least getting *some* calls, I am inclined to believe them. When I give them call examples from my cell phone, they say that they don't even see those calls hitting their systems at all. At this point, the running theory is that AT&T must have some kind of direct peering with Vonage, and Onvoy isn't in the loop at all on those calls. If that's the case, then perhaps everything magically works itself out once I have the end-user call up Vonage and have them close out the account completely. But I'm not sure it is worth the risk of having them take that step with things as they are, on the off-chance that I guessed wrong (instead of the problem getting fixed, calls from AT&T start going to /dev/null). Has anybody encountered anything like this before, or heard of national wireless carriers doing direct peering with national VoIP providers while completely bypassing PSTN switching infrastructure? Are there any AT&T, Onvoy, and/or Vonage reps reading this who can help un-**** this cluster? Thanks, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

8 8