[VoiceOps] Appearance of an International call

Thu Jun 16 11:52:04 EDT 2016

Hey Jared... you could be onto something here.  I started down a similar
road, in the beginning thinking, it was a digits issue but, when we started
working directly with VZN they didn't mention anything about getting the
wrong call-type, digits, an unneeded or missing 1 or + or +1 from any of
our carriers.  They just said it had to do with VoLTE functions and, right
now, they can't do anything about it.  This particular troubleshooting
exercise with VZN was for a 970 NPA land line origination and the
called-party saw Palestine Territory on their cell display.  If you look up
+970 it is Palestine.  The VZN engineer turned of the VoLTE function on the
cell phone and the call worked as it should, deisplayig the proper
information.

I think its either trunk group related, as you mentioned, or some
VoLTE-related AP is not operating correctly.  But, there could be multiple
reason this could happen.

Thanks;
Kidd

On Wed, Jun 15, 2016 at 4:49 PM, Jared Geiger <jared at compuwizz.net> wrote:

> 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
>>
>>
>

-- 
Kidd Filby
661.557.5640 (C)
http://www.linkedin.com/in/kiddfilby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160616/ba23bd6d/attachment-0001.html>