Appearance of an International call
Group; I have noticed some weird trouble cases, over the past year, dealing with US originated calls showing up on a cell phone as an international call, using the first 2-digits as a country code. On one incident, we worked with Verizon, to really nail down the culprit. Their engineer was very interested in finding the root cause and he spent a lot of time with us (as well as our carriers and our customer) trying to figure out what was causing this to occur. He determined, in their network anyway, it was how they were treating call information when he activated the VoLTE service. If he turned off the service, on the same phone, the caller ID information would be correct. When he activated the VoLTE, the information was incorrect and said it was an international call and provided the country it thought the call originated from. He said there is nothing he can currently do about it, other than turning off VoLTE? and we all know that isn?t going to happen. All of the complaints, we have had, have been to iPhones. *There is also another cause for this behavior that has to do with a CNAM-Like AP, some people had activated, and that had us chasing our tails for a while as well.* What I am wondering is, how many other folks out there are running into these scenarios and?. 1. What are your telling your customers? 2. What are your carriers telling you. 3. What have you determined the issue was? Also, if what we have been being told is incorrect, then I?d like to know that too. Several of our customers are negatively affected by this and we really need to figure out a solution for the industry. Thanks; Kidd
Well, I've never even heard of this before, so are you sure it's not related to your upstream carriers, and/or your own systems? Have you tested multiple upstreams (and which have you tried)? We're on Onvoy and calling Verizon phones that should be on VoLTE, no issues. I'm not sure if there's a way to know for sure if one particular phone is on VoLTE. Also, why the hell would you send e-mail in comic sans font?!? On Wed, Jun 15, 2016 at 10:22 AM, Kidd Filby <kiddfilby at gmail.com> wrote:
Group;
I have noticed some weird trouble cases, over the past year, dealing with US originated calls showing up on a cell phone as an international call, using the first 2-digits as a country code.
On one incident, we worked with Verizon, to really nail down the culprit. Their engineer was very interested in finding the root cause and he spent a lot of time with us (as well as our carriers and our customer) trying to figure out what was causing this to occur. He determined, in their network anyway, it was how they were treating call information when he activated the VoLTE service. If he turned off the service, on the same phone, the caller ID information would be correct. When he activated the VoLTE, the information was incorrect and said it was an international call and provided the country it thought the call originated from. He said there is nothing he can currently do about it, other than turning off VoLTE? and we all know that isn?t going to happen.
All of the complaints, we have had, have been to iPhones.
*There is also another cause for this behavior that has to do with a CNAM-Like AP, some people had activated, and that had us chasing our tails for a while as well.*
What I am wondering is, how many other folks out there are running into these scenarios and?.
1. What are your telling your customers?
2. What are your carriers telling you.
3. What have you determined the issue was?
Also, if what we have been being told is incorrect, then I?d like to know that too.
Several of our customers are negatively affected by this and we really need to figure out a solution for the industry.
Thanks;
Kidd
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Also, why the hell would you send e-mail in comic sans font?!? This is really the most important part. On Wed, Jun 15, 2016 at 1:30 PM, Carlos Alvarez <caalvarez at gmail.com> wrote:
Well, I've never even heard of this before, so are you sure it's not related to your upstream carriers, and/or your own systems? Have you tested multiple upstreams (and which have you tried)? We're on Onvoy and calling Verizon phones that should be on VoLTE, no issues. I'm not sure if there's a way to know for sure if one particular phone is on VoLTE.
Also, why the hell would you send e-mail in comic sans font?!?
On Wed, Jun 15, 2016 at 10:22 AM, Kidd Filby <kiddfilby at gmail.com> wrote:
Group;
I have noticed some weird trouble cases, over the past year, dealing with US originated calls showing up on a cell phone as an international call, using the first 2-digits as a country code.
On one incident, we worked with Verizon, to really nail down the culprit. Their engineer was very interested in finding the root cause and he spent a lot of time with us (as well as our carriers and our customer) trying to figure out what was causing this to occur. He determined, in their network anyway, it was how they were treating call information when he activated the VoLTE service. If he turned off the service, on the same phone, the caller ID information would be correct. When he activated the VoLTE, the information was incorrect and said it was an international call and provided the country it thought the call originated from. He said there is nothing he can currently do about it, other than turning off VoLTE? and we all know that isn?t going to happen.
All of the complaints, we have had, have been to iPhones.
*There is also another cause for this behavior that has to do with a CNAM-Like AP, some people had activated, and that had us chasing our tails for a while as well.*
What I am wondering is, how many other folks out there are running into these scenarios and?.
1. What are your telling your customers?
2. What are your carriers telling you.
3. What have you determined the issue was?
Also, if what we have been being told is incorrect, then I?d like to know that too.
Several of our customers are negatively affected by this and we really need to figure out a solution for the industry.
Thanks;
Kidd
_______________________________________________ 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
LOL. He flamed me off-list for pointing that out, after also trying to be helpful. I was told that I was an idiot basically. Ah well. I'd still like to hear if others are running into this because we're working on a project that will interface with hundreds of iPhones on VoLTE. On Wed, Jun 15, 2016 at 10:46 AM, Colin Brown <zavoid at gmail.com> wrote:
Also, why the hell would you send e-mail in comic sans font?!?
This is really the most important part.
On Wed, Jun 15, 2016 at 1:30 PM, Carlos Alvarez <caalvarez at gmail.com> wrote:
Well, I've never even heard of this before, so are you sure it's not related to your upstream carriers, and/or your own systems? Have you tested multiple upstreams (and which have you tried)? We're on Onvoy and calling Verizon phones that should be on VoLTE, no issues. I'm not sure if there's a way to know for sure if one particular phone is on VoLTE.
Also, why the hell would you send e-mail in comic sans font?!?
On Wed, Jun 15, 2016 at 10:22 AM, Kidd Filby <kiddfilby at gmail.com> wrote:
Group;
I have noticed some weird trouble cases, over the past year, dealing with US originated calls showing up on a cell phone as an international call, using the first 2-digits as a country code.
On one incident, we worked with Verizon, to really nail down the culprit. Their engineer was very interested in finding the root cause and he spent a lot of time with us (as well as our carriers and our customer) trying to figure out what was causing this to occur. He determined, in their network anyway, it was how they were treating call information when he activated the VoLTE service. If he turned off the service, on the same phone, the caller ID information would be correct. When he activated the VoLTE, the information was incorrect and said it was an international call and provided the country it thought the call originated from. He said there is nothing he can currently do about it, other than turning off VoLTE? and we all know that isn?t going to happen.
All of the complaints, we have had, have been to iPhones.
*There is also another cause for this behavior that has to do with a CNAM-Like AP, some people had activated, and that had us chasing our tails for a while as well.*
What I am wondering is, how many other folks out there are running into these scenarios and?.
1. What are your telling your customers?
2. What are your carriers telling you.
3. What have you determined the issue was?
Also, if what we have been being told is incorrect, then I?d like to know that too.
Several of our customers are negatively affected by this and we really need to figure out a solution for the industry.
Thanks;
Kidd
_______________________________________________ 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
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. -- Alex -- Principal, Evariste Systems LLC (www.evaristesys.com) Sent from my Google Nexus.
Sorry for breaking the cardinal rule of the list... Since the font used in one's message is far more important than the content. I should receive 30 lashes, I suppose. To put the issue plainly... 1. We are not marking the call as an international call and then sending it out into the world 2. We are not setting any locale marker of any kind as international 3. The called-party, on the cell side, is presented with a country/region on their screen 1. In this particular scenario, they saw Palestine Territory 2. The caller is land-based VoIP 4. Once the Engineer turned off the VoLTE option on the cell phone, the correct information was displayed. On Wed, Jun 15, 2016 at 11: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.
-- Alex
-- Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
_______________________________________________ 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
Whoops... I really do apologize... I just saw my email on a different computer... it does look bad in that font. However, it does not show up like that on my computer's screen for some reason. On Wed, Jun 15, 2016 at 12:42 PM, Kidd Filby <kiddfilby at gmail.com> wrote:
Sorry for breaking the cardinal rule of the list... Since the font used in one's message is far more important than the content. I should receive 30 lashes, I suppose.
To put the issue plainly...
1. We are not marking the call as an international call and then sending it out into the world 2. We are not setting any locale marker of any kind as international 3. The called-party, on the cell side, is presented with a country/region on their screen 1. In this particular scenario, they saw Palestine Territory 2. The caller is land-based VoIP 4. Once the Engineer turned off the VoLTE option on the cell phone, the correct information was displayed.
On Wed, Jun 15, 2016 at 11: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.
-- Alex
-- Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
_______________________________________________ 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
-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby
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.
-- Alex
-- Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
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.
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
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
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
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
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
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
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
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
participants (7)
-
abalashov＠evaristesys.com -
caalvarez＠gmail.com -
DLai＠transbeam.com -
jared＠compuwizz.net -
kiddfilby＠gmail.com -
pete＠fiberphone.co.nz -
zavoid＠gmail.com