[VoiceOps] Appearance of an International call

Wed Jun 15 18:49:01 EDT 2016

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> 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> 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> 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 <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>
>>>> 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> 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
>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>>
>>>
>>>
>>>
>>> --
>>> Kidd Filby
>>> 661.557.5640 (C)
>>> http://www.linkedin.com/in/kiddfilby
>>>
>>> _______________________________________________
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>
>>>
>>
>
>
> --
> Kidd Filby
> 661.557.5640 (C)
> http://www.linkedin.com/in/kiddfilby
>
> _______________________________________________
> VoiceOps mailing list
> 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/20160615/28555da9/attachment-0001.html>