[VoiceOps] Appearance of an International call

Wed Jun 15 21:01:16 EDT 2016

For what it’s worth, I have an iPhone 6 Plus running IOS 9.2.1 on ATT.  I’ve recently been experiencing this “problem” on received calls.
I haven’t had a chance to investigate it, just know that it started occurring on 6/6/2016, and it’s only when receiving calls from a specific calling party, and it doesn’t happen all the time.

[cid:image001.png at 01D1C748.8FBD36D0]

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jared Geiger
Sent: Wednesday, June 15, 2016 6:49 PM
To: Kidd Filby <kiddfilby at gmail.com>
Cc: <voiceops at voiceops.org> <voiceops at voiceops.org>
Subject: Re: [VoiceOps] Appearance of an International call

I'm thinking since the VoLTE call is going through a GSM type Verizon switch which is separate from their 1X CDMA voice network. The VoLTE switch would be e164 format (+1) all the way whereas the legacy switch is probably more catered to act like a US PSTN switch (10 Digit).

I don't think this is 100% related but could be: When we setup our trunks to Verizon Business, we had to choose between sending our ANI in e164 or in 10 digit US form. Maybe a carrier along the path isn't transforming the ANI correctly to match their trunk with Verizon. Granted I don't know how interconnection with Verizon wireless looks like at all so it could be completely different than VZB.

On Wed, Jun 15, 2016 at 3:11 PM, Kidd Filby <kiddfilby at gmail.com<mailto:kiddfilby at gmail.com>> wrote:
Jared;

We did not try that specific call scenario.  What I can tell you is that I get calls from people all the time, to my VZN Motorola phone, sometimes they show up with a + and other times they don't.  I'm talking about the same calling number.  So, I think it depends on what tower they are hitting or something along those lines as to what the translations are in the routing.
What are you thoughts about the +1??  Are you thinking that is a info bit that does something in the VZN network or w/in VoLTE?
Thanks;
Kidd

On Wed, Jun 15, 2016 at 3:54 PM, Jared Geiger <jared at compuwizz.net<mailto:jared at compuwizz.net>> wrote:
What happens if you send the call with a +1 in the beginning of the ANI? Does the VoLTE phone correctly show or does Verizon reject the call?

On Wed, Jun 15, 2016 at 2:33 PM, Kidd Filby <kiddfilby at gmail.com<mailto:kiddfilby at gmail.com>> wrote:
Hey Pete;
Thanks for the chime-in.  That must have been a fun one to chase as well.
Well, I cannot say... for certain, it is an iOS problem or directly related to the iPhone.  Here is what I know for sure, from testing.

  1.  We have only gotten complaints related to users of iPhones
  2.  I have made test calls to Android devices and have not had the problem occur

     *   We have made numerous test calls to (4) different Android models of Verizon phones w/o any issue
     *
     *   However, I have also made calls to Verizon iPhones that did not reproduce the problem

  1.  We have troubles reported to us relating to both Verizon and AT&T wireless end users

     *   Have all been end users with iPhones

  1.  As stated earlier, when the VZN Engineer deactivated VoLTE on the iPhone, the information displayed correctly

The reason why its not as wide spread, I think, is that people mostly call people they know and the contact list on their cell phone overrides the presentation and a lot more calls are wireless to wireless today (even on the same network) that were landline related in the past.

It's definitely a strange one.

Thanks;

Kidd

On Wed, Jun 15, 2016 at 2:50 PM, Pete Mundy <pete at fiberphone.co.nz<mailto:pete at fiberphone.co.nz>> wrote:

Do you think this is an iPhone-specific issue? Ie a fault in iOS and the way it's dealing with decoding the caller ID?

We saw similar issues with txt messages from other mobile users inside our country (New Zealand) way back when the iPhone first hit the market. Basically txt messages would be shown as coming from the full number including country code prefix (+64) and not matched against the number already in the contacts list. Users would then add the new number to the existing contact, then when they tried to txt or call the number back the carrier would refuse the transmission. It all came right once Apple cottoned on to the problem and a fix was included in an iOS update (although it took like 2 months for that to occur, meanwhile pretty much everyone with an iPhone in NZ experienced the hassle of it).

I just wonder if it might be worth testing the same scenario from an Android phone to see if it works. That may help discount the carriers and upstreams as being part of the equation and give you more credence when trying to escalate the issue to Apple (and good luck with that too!).

Pete

Ps, yes I also giggled at the Comic Sans on the first posting too ;)

> On 16/06/2016, at 6:54 am, Carlos Alvarez <caalvarez at gmail.com<mailto:caalvarez at gmail.com>> wrote:
>
> That sort of conversation was the intent of my original message. We have seen odd things happen from one carrier to another when we don't send the whole presentation. The carriers will accept a 10 digit caller ID but then something strange will happen at random. So that's just one of many things that could be going on.
>
> Sent from my iPhone
>
>> On Jun 15, 2016, at 10:57 AM, Alex Balashov <abalashov at evaristesys.com<mailto:abalashov at evaristesys.com>> wrote:
>>
>> Comic sans isn't a fashion accessory in my part of town.
>>
>> I figure this is an issue of presentation and locality setting transmission. Don't GSM/3GPP and LTE require all numbers to be internally represented as fully-qualified E.164 anyhow? What gives a number "local" presentation is a setting on the phone that says "I'm within this country code", and I imagine that whether this is honoured can be modulated via some calling number presentation setting in the signalling message.
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops

--
Kidd Filby
661.557.5640<tel:661.557.5640> (C)
http://www.linkedin.com/in/kiddfilby

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops

--
Kidd Filby
661.557.5640<tel:661.557.5640> (C)
http://www.linkedin.com/in/kiddfilby

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160616/6a62ef3f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 28863 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160616/6a62ef3f/attachment-0001.png>