dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
2938

cb14
join:2013-02-04
Miami Beach, FL

cb14 to tommyanon

Member

to tommyanon

Re: [General] Callcentric and Google Voice CID issue

said by tommyanon :

a million with GV forwarded to free DIDs


Mango
Use DMZ and you get a kick in the dick.
Premium Member
join:2008-12-25
www.toao.net

Mango

Premium Member

In case it's relevant, I just experienced this problem, but I don't use forwarding or Google Voice. The call was made from a Shaw Cable (western Canada CLEC) landline to my Callcentric Free DID. It appears as "Anonymous" in the Callcentric portal. I also heard a "clicking" noise periodically throughout the call.

I haven't opened a ticket because Caller ID is not really important for this DID, but wanted to mention it here in case this is useful for anyone else.
VoipisGreat
join:2013-03-25

VoipisGreat to pagemen

Member

to pagemen
I got an update on my ticket. It's the same as what's reported on obi forum: Google set a privacy flag on the call so callcentric in turn pass an 'anonymous' caller ID to me.

Since it doesn't happen all the time, it seems that google sometimes sets privacy flag, sometimes does not.

Also base on my anecdotal observations, it doesn't happen with GV forward to DIDs from other providers. So either GV somehow selectively chooses to set the flag only to calls to callcentric DID, or other providers simply decide to ignore the flag?
Iscream
Premium Member
join:2009-02-17
New York, NY

1 edit

Iscream to Mango

Premium Member

to Mango
Dear Mango:

You may want to check your settings with and then you may need to open a ticket with Shaw in this case.

The "clicking" noise suggests that Shaw uses/used something "cheap" for international termination to US PSTN network or [I'm highly doubtful] your Internet connection suffers some bandwidth/packet loss issues.

Just in case - the NY Free DIDs _ARE_ not a some sort of "cheap" or "discounted" service - those are regular, copper-wire based, PSTN DIDs provided by Telengy CLEC via related TDM/SS7 infrastructure and certified (in order to operate a CLEC) switching equipment. Telengy is a regulated by Public Utility Commission and by FCC, CLEC and IXC and TF/RespOrg carrier.

Those DIDs are fully free because Telengy, as any other CLEC (or like IPKall to this matter), earns its profit from minutes of incoming calls to these DIDs from other LECs. Those same DIDs are also provided on a normal basis to Telengy's wire-line subscribers in NYC.

Dear Mango - please don't get caught on BS spread by some people (not necessarily on these boards, but in some other places - like OBI's forum, who are ready to call for witch-hunt against Callcentric - sure it's much simpler than going against larger ones especially when those larger ones don't provide technical support :-( ) who like the "heat" going on.
VoipisGreat
join:2013-03-25

VoipisGreat to Iscream

Member

to Iscream
said by Iscream:

It doesn't matter the way the call hits the DID - if/when a CID is there - it's passed up to the customer.

But according to the response to my ticket, the CID is there, but in addition there's a privacy flag to be set to determine if CID should be passed.

Can Iscream (or whoever who knows the inner workings of it) clarify?
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream

Premium Member

Sure, I'll provide the complete report later on tonight or tomorrow; the investigation is over as of now.

cb14
join:2013-02-04
Miami Beach, FL

cb14 to VoipisGreat

Member

to VoipisGreat
said by VoipisGreat:

I got an update on my ticket. It's the same as what's reported on obi forum: Google set a privacy flag on the call so callcentric in turn pass an 'anonymous' caller ID to me.

Since it doesn't happen all the time, it seems that google sometimes sets privacy flag, sometimes does not.

Also base on my anecdotal observations, it doesn't happen with GV forward to DIDs from other providers. So either GV somehow selectively chooses to set the flag only to calls to callcentric DID, or other providers simply decide to ignore the flag?

Since exactly the same thing happens to calls from Localphone and according to other posters, from Anveo, there is obviously something else causing this. We should wait up the final report.
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream to pagemen

Premium Member

to pagemen
Below is a link to a Google group (making and receiving calls) discussing this same issue - there is also Google's "community manager" participating in discussion who escalated this matter to Google's attention.

»productforums.google.com ··· P8ZslvcJ

Some positive reports are expected )
Iscream

1 recommendation

Iscream to cb14

Premium Member

to cb14
Well...

The only common thing among Google, Localphone and Anveo, in this case, would be using the same terminating carrier (actually - an aggregator who mixes and matches many different actual carriers to "provide" the value cost SIP to PSTN routing) to deliver calls to Callcentric's underlying CLEC (Telengy).

Callcentric has stopped using such aggregators for US/Canadian domestic termination long time ago due to many troubleshooting and administrative (not talking about a "grey" reporting and taxation situation related to such an usage) problems. This is why our terminating costs are slightly higher, but the signaling, voice quality and call reliability are also incomparably better; by peering directly with actual LECs we're also reporting and paying more taxes (not passed to customer's bill - "eaten" by us internally).

The reason of why CLID is preserved when GV's incoming call comes in through/from other CLECs is either due to carelessness or misconfiguration or negligence on their side (hard to believe) or because a different terminating carrier is used to deliver calls to such CLECs.

If some one wants to perform a slightly complex experiment (requires knowledge of SIP sack and basic shell scripting) - s/he may originate a call from some other SIP network via "in.callcentric.com" peering mechanism while setting "privacy=off" and "privacy=uri" within "Remote-Party-Id:" header.

On another hand - any one on this forum may send a call to their NY Free DID via regular PSTN (landline, FIOS, cable or mobile) to check that the CLID is displayed correctly and then send same call by using their GV, Anveo or Localphone forwarding. One may then PM their NY Free DID used for such testing - then I'll provide entire call capture _here_ - showing the difference between "privacy" flags in both cases. I'll also provide their originating CLIDs either publicly or via PM.

Unfortunately, unless "fixed" by either originating or transit delivery carriers - Callcentric is NOT in the position to violate telecommunications regulations in regards to disclosing original CLID when "privacy" is requested by originating side.

Unfortunately, there is NO way to find out whether an incoming call has been originated (forwarded) by GV or by Joe Schmoe's actual "anonymous" outbound call.

Disclosing a CLID on some "assumption" is a gross violation of telecom laws.

Callcentric is NOT in charge of nor it can explain why some other carriers may do it, but when a call (from the same GV for example) arrives with "privacy=off" from some CLEC - Callcentric display the CLID; when it arrives while requesting privacy - Callcentric's switch acts accordingly. Doing otherwise would be tampering with equipment's software, firmware as well as violating the regulations as I've admitted above.

Thank you.

P.S. If someone wants to study the privacy related matters - the relevant RFC may be found here:
»tools.ietf.org/html/draf ··· ivacy-04
Mango
Use DMZ and you get a kick in the dick.
Premium Member
join:2008-12-25
www.toao.net

Mango

Premium Member

said by Iscream:

Unfortunately, there is NO way to find out whether an incoming call has been originated (forwarded) by GV or by Joe Schmoe's actual "anonymous" outbound call.

I've always wondered about that. Are you saying it's not possible to determine which carrier delivered the call to my DID?

cb14
join:2013-02-04
Miami Beach, FL

cb14 to Iscream

Member

to Iscream
said by Iscream:

Well...

The reason of why CLID is preserved when GV's incoming call comes in through/from other CLECs is either due to carelessness or misconfiguration or negligence on their side (hard to believe) or because a different terminating carrier is used to deliver calls to such CLECs.

On another hand - any one on this forum may send a call to their NY Free DID via regular PSTN (landline, FIOS, cable or mobile) to check that the CLID is displayed correctly and then send same call by using their GV, Anveo or Localphone forwarding. One may then PM their NY Free DID used for such testing - then I'll provide entire call capture _here_ - showing the difference between "privacy" flags in both cases. I'll also provide their originating CLIDs either publicly or via PM.

Obviously, as one poster already mentioned, the problem is with the terminating carrier/aggregator.
When I tested the direct calling and call forwarding to CC through Localphone and Google I obviously also tested a direct call through ' established' providers, I guess it was either TMO or Verizon and it displayed the CID correctly.
It is strange because I never had problems with LP's CID delivery around the globe whether using the VOIP phone or other services. Possibly, due to the price pressure in the US- their US rates are very low- they have to cut corners with termination in some cases.
But I will get back to the test offer in one of these days once zi have more time because it is a bit time consuming. Thanks.
Iscream
Premium Member
join:2009-02-17
New York, NY

1 edit

3 recommendations

Iscream to Mango

Premium Member

to Mango
Those are two different things.

One thing is to find out _who_ originated a call (CLID) and their carrier (CLEC, mobile or VOIP provider) and totally different thing is to know _who_ delivered that call to your (or your provider's) network.

Saying the above - I'd say "NO" to both mentioned things )

In a real telecom world a xLEC's network is connected to multiple tandem switches in a local serving area (LATA); if a xLEC serves multiple LATAs - in each LATA that xLEC has their own switch connected to all tandem switches in that LATA. All local calls from such area arrive from those multiple tandem switches (each switch serving one or many NPA-NXX's for all participating xLECs). Tandem switches are controlled by ILEC in an area and used collectively by all xLECs there).

Local (intra-LATA) calls are served directly by LATA's tandems, inter-LATA calls are served by IXCs (long distance carriers). Each xLEC establishes trunk-groups to one or multiple IXC. IXCs exchange calls among themselves. A xLEC hands off a call to IXC then IXC transports this call either directly to destination area or hands it off to another IXC. When destination local area reached - IXC hands off the call to a tandem switch which is a "home" for NPA-NXX of destination number. At that tandem switch the call is picked up by a destination xLEC. This is a greatly simplified, ideal picture of how it supposed to be according to deregulation Telecom Act. A carrier may be a CLEC or IXC or both as well as it may be serving multiple areas. An ILEC is a LEC responsible for all local infrastructure in LATA (usually/historically a part of original Ma-Bell system - baby-Bell or RBOC or Regional Bell Operating Company).

I've intentionally skipped anything related to call signaling and billing (actual LEC billing - called CABS or carrier access billing system).

There is also another "reverse" routing and billing mechanism used for Toll Free call deliveries by utilizing RespOrg services and SMS/800 databases.

Answering one of your question - NO, it's impossible to determine _how_ a call has been originated.

Answering your another question - no, it's impossible to [directly, on-fly] determine who delivered a call to you in a rich man [carrier ] world. One may identify a trunk-group (TG) used to deliver a call, but that TG could be used for multiple purposes.

For each call there is [at least] an ISUP message sent through Signaling System 7 which is fully separated from data (or voice) trunks. You may view SS7 as a some sort of TCP/IP network (just in a very simplified way). For each call there will be ANI, DNIS and multiple cross-network elements identifying parties involved in transporting and servicing the call. There may also be involved other types of SS7 messages (like data-base queries). By processing those elements all involved switches assemble different CABS elements in order for CABS software to prepare and exchange billing records for clearing among different carriers. I can't explain this matter within the scope of this board ).
PX Eliezer1
Premium Member
join:2013-03-10
Zubrowka USA

PX Eliezer1

Premium Member

Thank you, Iscream, for sharing your expertise and for the detailed explanations of these issues.
VoipisGreat
join:2013-03-25

VoipisGreat to Iscream

Member

to Iscream
Indeed. Looks like google has fixed it on their end. CID now showing on all calls so far. And apparently the call quality has improved too.
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream to cb14

Premium Member

to cb14
Anyone with Anveo or Localphone out there?

I'm positive that forwarding to NY Free DID is still delivering an empty/anonymous/unknown, etc. CLID please tell me that I'm mistaken here.

Thanks!

cb14
join:2013-02-04
Miami Beach, FL

1 edit

cb14

Member

Call from Localphone delivers now " private caller". I tested the calling card, not forwarding, but there is no difference there. Should there be any, I would report later.
On edit ; Call from my dutch DID delivers " private caller " as well

Interesting : Localphone calls or Localphone forwarded calls to Google voice DO deliver the proper CLID.
Iscream
Premium Member
join:2009-02-17
New York, NY

1 edit

Iscream

Premium Member

As I assumed...
Yeah... providers are "cutting corners" due to "pressing" pricing issues )

You may want to point LP guys at _this_ thread as as well as to Google's group discussing same matter and ask them to work with whomever does their SIP routing/aggregation/terminates their calls to NYC's NPA-NXXs.

P.S. It doesn't matter that LP calls to GV deliver proper CLID - it's not relevant here because different carrier may be used for termination to any area as well as multiple carriers can be used to terminate to the same area depending on origination area (CLID). As well as LP's carrier may ignore privacy requirements or LP's software may ignore them...

I provided sufficient amount of information and documentation to show _where_ the issue sits and what causes it )

cb14
join:2013-02-04
Miami Beach, FL

cb14

Member

Will do, especially because after the retirement of GV proper forwarding to CC DID will become far more important.
propcgamer
join:2001-10-10
011010101

propcgamer to Iscream

Member

to Iscream
said by Iscream:

Anyone with Anveo or Localphone out there?

When I called from Anveo to my NY did today it worked fine.
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream

Premium Member

Well, let's hope that Anveo has fixed the issue and that it won't revert back in a few days. Thanks!
VoipisGreat
join:2013-03-25

VoipisGreat

Member

said by VoipisGreat:

Indeed. Looks like google has fixed it on their end. CID now showing on all calls so far. And apparently the call quality has improved too.

uh-ho spoke too soon. I still had one call which came in "anonymous" which had a valid callerID on GV side. Not completely out of the woods yet.
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream

Premium Member

Please update the Google Group's thread I've pointed at in my earlier [day old] post.
PX Eliezer1
Premium Member
join:2013-03-10
Zubrowka USA

PX Eliezer1

Premium Member

I think that it's exceptionally generous for CallCentric to worry about this issue at all.

They provide these DID's at no charge, they include CID which is nice, and also provide CNAM which is even nicer.

And these numbers work fine for their intended consumer purpose.

Except perhaps as an academic exercise, I don't see why they should have to worry about CID/CNAM on calls that have been passed through multiple other sets of hands such as a paid competitor or such as GV.

If I saw that my girlfriend had french kissed 3 other guys when we were on a date, I would tell her, yuk, no goodnight kiss for you.

TL/DR: I think that it's exceptionally generous for CallCentric to worry about this issue at all.

cb14
join:2013-02-04
Miami Beach, FL

cb14

Member

said by PX Eliezer1:

Except perhaps as an academic exercise, I don't see why they should have to worry about CID/CNAM on calls that have been passed through multiple other sets of hands such as a paid competitor or such as GV.

Aside of the highly appreciated generosity, it is a good advertisement for CC and also shows the results of cutting corners by lower price competitors in a subtle, non controversial way.
Also, Telengy is most likely making some money on the incoming calls so it is beneficial to remove any obstacles whoever caused them.After May 14th, if I still have one or both of my GV DID's at that point of time, I will have to forward them somewhere and forwarding them to NYC CC DID would be the most obvious solution. Due to the limitation of LP voice mail I will have to forward at times my LP incoming calls either to my cell phone or to CC DID. Proper functioning of everything is of importance.