[VoiceOps] Appearance of an International call

Wed Jun 15 18:02:18 EDT 2016

Carlos;

You can actually disable the function on the iPhone, which is what the VZN
Engineer did for our testing.  I know for sure that all (4) different model
Androids had VoLTE enabled.  They were Motorola, Sony and 2 different
Samsung

We send calls out to several carriers and each one has been involved in the
issue.  I'm not ready to point at carriers yet, since the evidence is
overwhelmingly pointing at iOS/iPhone but.... I don't want say that IS the
root cause either.  The bulk of these calls are traveling the Impact
network via SIP.  However, it is possible 2 or 3 hops later they all ride
the same carrier that is making it seem like all the carriers' networks are
doing it.

As you say, VoLTE could be acting totally different than any other system
out there.  I just know what the Engineer at VZN told us on the phone about
their network.

I've been doing this for over 30 years... nothing surprises me now.

On Wed, Jun 15, 2016 at 3:45 PM, Carlos Alvarez <caalvarez at gmail.com> wrote:

> Is there a way to know if a handset is using VoLTE?  IE, so we could
> specifically test it?  Can you be sure the Androids were VoLTE capable?
>
> The VoLTE network could be handling things completely differently and I
> don't think it's safe to assume that it's not a carrier to carrier issue.
> I would still recommend trying calls with any other carrier if at all
> possible.  And if you'd like, I can try a call from our Asterisk via Onvoy
> to one of the problem phones and see what happens.  I don't think it's safe
> to eliminate ANY item, including your switch.  Like I said in the private
> e-mail, we're fighting a signaling issue right now that ONLY happens if
> it's from our primary server, to Onvoy, to certain other carriers, and it's
> a transfer.  Eliminate any one and the problem goes away.
>
>
>
> 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
>>
>>
>
> _______________________________________________
> 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/20160615/84ae9fd6/attachment-0001.html>