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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> 1. We have made numerous test calls to (4) different Android models >>> of Verizon phones w/o any issue >>> 2. >>> 3. However, I have also made calls to Verizon iPhones that did >>> not reproduce the problem >>> 3. We have troubles reported to us relating to both Verizon and >>> AT&T wireless end users >>> 1. Have all been end users with iPhones >>> 4. 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 < >>>> [email protected]> 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 >>>> [email protected] >>>> https://puck.nether.net/mailman/listinfo/voiceops >>>> >>> >>> >>> >>> -- >>> Kidd Filby >>> 661.557.5640 (C) >>> http://www.linkedin.com/in/kiddfilby >>> >>> _______________________________________________ >>> VoiceOps mailing list >>> [email protected] >>> https://puck.nether.net/mailman/listinfo/voiceops >>> >>> >> > > > -- > Kidd Filby > 661.557.5640 (C) > http://www.linkedin.com/in/kiddfilby > > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops > >
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
