Printable View
Hello All Asterisk Users, for the most part :).
We are putting in some further restrictions where you can not pass caller ID information for a phone number that you do not own / "belongs to your account". So from here on out you will want to send outbound calls, via a phone number that belongs to your account.
Thanks.
VOIPo Team
I guess that blows DISA for my Mother-in-law. I sure don't want her friends calling me back just because that was a number associated with a particular outbound trunk. Passing her number through was a true reflection of the caller, now it won't be if a VOIPo line is choosen.Quote:
Originally Posted by VOIPoBrandon
Guess I'd better restrict the outbound options for the DISA function to the 'cheaper' routes.
Will there be an option to specify numbers we 'own' (but not through VOIPo)? Also, will this restriction apply to Express accounts, or just Residential?
I just checked my Express account and no more caller id with my business phone number. I thought Express accounts would still be able to pass a primary number. I can understand that with a residential account, but not with an Express account. That would be a show stopper for me.
We can look at adding an area in vPanel to add a limited number of "Authorized CIDs" maybe. Would that work for you guys?
Basically, we're just in the phase of development where we're making sure everything is in place in terms of security and uniformity so we have a nice secure, consistent system.
What we were seeing a lot of is people sending invalid CIDs to us. In a lot of cases, the major upstream carriers (Level3, Global Crossing, etc) in the industry are now starting to "rate" a call based on the CID info and the destination. Typically carriers pay significantly different rates for interstate calls (state-to-state) and intrastate (same state). In the past, people would sometimes use fake CID info to spoof their way to interstate rates and basically avoid intrastate altogether (since in some cases intra can be extremely expensive and several times the interstate rate). This is one reason the new Truth-In-Caller ID act stuff has been coming up. Since people were bypassing the system in a sense, most carriers are not adopting policies to simply rate "unknown" calls or ones with fake CID info at the highest rate. That avoids the problem altogether.
If you've seen dial around or some of the lower end web-based services or similar type things that in the past that sent a CID of like 12345 when you called using them, this is essentially why...they were manipulating the CID to manipulate how the call was rated. In some cases, they send a CID of a specific number for a specific reason. If you know the "system", there is a whole book full of ways to abuse it for profit.
Anyway when we were getting fake CIDs...some of them not even numbers, we don't have a valid number to pass upstream, etc and this potentially could affect how the calls are rated for us. It's also somewhat poor security to allow any random CID to be put in because of the potential for spoofing and just billing fraud in general.
Hopefully this makes sense...
I completely understand your position. I'm all for a consistent, secure system--that benefits everyone. However, there should be a limited amount of room for flexibility in certain situations. For example, if someone wants a voipo line as a secondary line (a per-minute plan or limited plan like 500 min/mo), they might want to pass the CID info of their main number. This would be my situation. Another good reason to pass a different CID number is during a number port--if I sign up for voipo and want to port my number, it would be nice to use the voipo line for incoming by forwarding the existing line to the voipo# AND outgoing, provided voipo can pass the ported number, even though it still operates using the temporary number.
I'd be interested to hear from other users what kind of limitations you think are reasonable. Should there be just one additional "authorized CID"? Should there be up to 5? Should there be a monthly fee to "buy" more authorized CID's beyond the standard limit? From a security standpoint, should these numbers be verified somehow? (I envision an automated verification, where upon entering the number in vpanel, voipo calls that number and asks for permission, and if given, a numeric passcode that is displayed on the vPanel screen when submitting the number. Refreshing the screen would show status--Active, Denied, or Invalid Passcode.)
In terms of people sending invalid CIDs, can't you figure out who's making the call based on registration info? I'd think you could send CID based on the registration, couldn't you? (FWIW, I have another provider with an alpha (non-numeric) SIP username, and the CID sent from that account is the assigned DID number...)
Before AT&T bought anywho.com, it was a great directory service.
You could look up the published info, and you could correct it.
To authenticate the correction, you had to call in from the number
being updated.
Perhaps VOIPo could use that technique? Designate a desired CID.
Then call from it (maybe enter some auth code supplied from vPanel),
and the truth in CID is fulfilled?
I suppose it could still be abused. But it would take some work to
simply foil LD charges by changing up the number on an asterisk box.
Just thinking . . .
Once you have a list . . . there could be a "use xxx-xxx-xxxx" if CID does not match list. I think that is what you are suggesting?Quote:
Originally Posted by fisamo
DIFFERENT SUBJECT:
Also, it would be cool if I could call my VOIPo from my cell, when voicemail kicks in press ***, VOIPo asks for a password, and VOIPo would let me call friends in Canada for example.
OR, add a list of CIDs like my cell, the wife's cell . . . and have some number at VOIPo that recognizes my CID and simply lets me make a call to Canada using minutes from my VOIPo account.
AND SENDS ON a preferred CID so the party I am calling knows me.
For all practical purposes, CallVantage already offers this feature. However, instead of calling my CV line, I call one of approximately 50 numbers distributed throughout the US. If the number is 'recognized' (e.g. in my entered in my control panel), I can just enter a PIN; if I"m not calling from a recognized number, I have to enter my CallVantage # and the PIN. Once logged in, I can turn "locate me" on or off, set/cancel Do Not Disturb, get my voicemail, or place a call using the CallVantage service. The called party sees my Callvantage # on their CID display. This feature, along with CallVantage reliability and good sound quality, keeps me very loyal to that service.Quote:
Originally Posted by usa2k
I think you should probably separate the issue as related to residential from Express handling.
I also have to consider multiple things when I route calls from my * boxes. Although this is just a hobby for me:
My daughter in NY has an assigned DID, but dials outbound through _an_ available trunk prioritized and selected on several factors. Her husband in VA has no DID, but has a system extension; he dials outbound through _an_ available trunk prioritized and selected on several factors. My mother in FL has POTS, but uses a local DID to call family on extensions, and has DISA access as well. My mother-in-law has POTS and accesses DISA via a local DID as does my wife when she needs to make a personal long distance call while at work. The rest of my family around the country has a variety of extensions and local DIDs to communicate with internally with each other, but are generally expected to use their own POTS for their long distance. I don't need to pay for their freight, they earn their own living and can afford it. The one exception is that I generally allow them to place personal calls to family members overseas through my system since I have a variety of cost-effective routes [and some extensions] available.
So is it better to reflect a caller ID associated with some varying outbound trunk, or to attempt to pass through the CallerID info if received from the call initiator, or perhaps one by which the caller may currently be directly reached, POTS, cell phone, etc.?
After a night's rest and time to think a bit more, I guess the first question I have to ask is whether you are planning on differentiating how Caller ID is handled between the Codeblue/Residential offering and the Express/'Roll-yer-own' package?
If so, I believe a limited ability to substitute caller ID should be available for the residential customer, based on some sort of verifiable call-in-from-that-number system perhaps as mentioned above.
I don't think such a system would be practical for the Express service, just because of the much different target audience and probable uses. Perhaps just ensuring that each call at least has some valid caller ID information is all you can do to protect yourself. Or grab ANI information if available? I suppose the ultimate solution is to just simply _reject_ any call with invalid entries in the fields, and a "No Caller ID, no call" message to the caller. I guess that does away with Caller ID blocking? Wouldn't bother me at all! ;-) I'm not sure _you_ want to, or even should, attempt to play traffic cop since you have no real way of knowing the true origin of a call.
I guess I still don't understand why you can't override the CID info. After all, if you can reject a call based on whether or not the CID is 'owned' for that user, can't you simply replace what the user passes with that CID info? That would certainly make it harder for a user to dynamically pass different CIDs (should you choose to make that an allowable option)...
Another question about this issue is in regard to providers who offer outbound-only service. What CID info would they pass if no DID is assigned to that account? In particular, how would they be in compliance with a "Truth in CID" act? If they pass 'Unavailable' and that results in them being billed at the highest rates, how will they stay competitive? (That's a rhetorical question, of course--I realize it's not voipo's problem. :) )
FWIW, a limited number of "Authorized CIDs" would work for me. But I still think the Express product should be handled differently than the residential product.