Does the OBi110 have the ability to spoof outbound CID? What I was hoping to do is add my name to my outbound CID when placing calls. Right now it just displays my number with "UNKNOWN NAME" I thought I read somewhere that some ATA devices can spoof the email...if not not a big deal.
FYI..I'm using a normal SIP Service provider.
Thanks.
Are you setting?:
Voice Servies -> SPx Service -> CallerIDName : [caller name]
Quote from: RonR on February 26, 2011, 01:04:08 PM
Are you setting?:
Voice Servies -> SPx Service -> CallerIDName : [caller name]
@RonR...yes I've added the caller name there doesn't seem to help...I'm assuming this data has to be sent from SIP service provider?
Thanks.
You might want to read the 'Calling-line identification' section of:
http://en.wikipedia.org/wiki/Caller_ID
To get a caller's name in addition to the CallerID (phone number) on calls that go through the PSTN, the phone service provider has to maintain (or subscribe to) a database that provides the name. VoIP-to-VoIP often passes the name provided in the ATA, but that information isn't passed through the PSTN (only the number).
CID number can be spoof-ed on the OBi device but not the CID name, and this is only if the ITSP cooperates (i.e. let it pass).
Your SIP ITSP can enable your CID name after they have it registered with Verisign.
What does "X_SpoofCallerID" do in the OBi settings?
Quote from: OBi-Guru on February 26, 2011, 01:39:41 PM
CID number can be spoof-ed on the OBi device but not the CID name, and this is only if the ITSP cooperates (i.e. let it pass).
And very few ITSP's cooperate.
Quote from: Loughary on February 26, 2011, 01:41:41 PM
What does "X_SpoofCallerID" do in the OBi settings?
You might want to download the OBi Device Administration Guide (OBiDeviceAdminGuide.pdf). X_SpoofCallerID is documented on page 56. As previously noted, very few ITSP's honor this field in the FROM header and simply ignore it.
Quote from: RonR on February 26, 2011, 02:25:37 PM
Quote from: Loughary on February 26, 2011, 01:41:41 PM
What does "X_SpoofCallerID" do in the OBi settings?
You might want to download the OBi Device Administration Guide (OBiDeviceAdminGuide.pdf). X_SpoofCallerID is documented on page 56. As previously noted, very few ITSP's honor this field in the FROM header and simply ignore it.
I read page 56 and it says X_SpoofCallerID can be used but doesn't provide any example of how to implement it. In fact I have searched the documentation extensively and cannot locate a single example of how to do it.
I do have a provider setup in SP2 which allows spoofing and I would like to have calls which go out on SP2 show my SP1 (Google Voice) cid instead of the SP2's DID.
Can someone please provide an simple example?
From page 58/59 of the latest version of the OBi Device Administration Guide:
Allow outbound Caller ID spoofing. If set to Yes, device will attempt to set the caller-id name and userid field in the FROM header to that of a remote caller in the case of a bridged call (from another trunk, such as PSTN Line or another SP Service). Otherwise, device always its own account information to form the FROM header.
Note that most service provider will not allow originating a call if the FROM header field does not match the account credentials. Enable this option only if you are sure that the service provider allows it. For example, an IP PBX may allow it.
X_SpoofCallerID is simply an enable checkbox. It applies to bridged calls (a call originated by the OBi that is then connected to an incoming call). If X_SpoofCallerID is disabled (default), the OBi will use your CallerID info when originating the outgoing call. If X_SpoofCallerID is enabled (checked), the OBi will attempt to use the CallerID info from the incoming call that it intends to bridge with.
Quote from: RonR on April 08, 2011, 02:01:32 PM
From page 58/59 of the latest version of the OBi Device Administration Guide:
Allow outbound Caller ID spoofing. If set to Yes, device will attempt to set the caller-id name and userid field in the FROM header to that of a remote caller in the case of a bridged call (from another trunk, such as PSTN Line or another SP Service). Otherwise, device always its own account information to form the FROM header.
Note that most service provider will not allow originating a call if the FROM header field does not match the account credentials. Enable this option only if you are sure that the service provider allows it. For example, an IP PBX may allow it.
X_SpoofCallerID is simply an enable checkbox. It applies to bridged calls (a call originated by the OBi that is then connected to an incoming call). If X_SpoofCallerID is disabled (default), the OBi will use your CallerID info when originating the outgoing call. If X_SpoofCallerID is enabled (checked), the OBi will attempt to use the CallerID info from the incoming call that it intends to bridge with.
Yes I read the document but this still provides no example of how to use it as I described. The source is the attached phone not from an incoming call; and I do not see any example of defining spoofed cid.
I am guessing it is done by modifying the OutboundCallRoute of the Phone port in it's dial string but there is no example of the syntax anywhere that I can find. There are examples of w/o spoofing but none with.
Again I assume it is the {(<**2:>(Msp2)):sp2} rule which needs to be modified just not sure of the cid syntax needed here.
Well at least I don't feel so stupid! Apparently no one else knows how to do this either!
Some work around ways.
Change your VSP username/clientid to your GV#.
Voip.ms provides true spoofing for PSTN out. (ie:Send from the White House# cname shows United States. :o
Use listyourself.net.
Edit: To set in Voip.ms > Account settings> General> CallerID Number.
VaHam
Quote from: VaHam on April 08, 2011, 09:37:04 PM
Quote from: RonR on April 08, 2011, 02:01:32 PM
X_SpoofCallerID is simply an enable checkbox. It applies to bridged calls (a call originated by the OBi that is then connected to an incoming call). If X_SpoofCallerID is disabled (default), the OBi will use your CallerID info when originating the outgoing call. If X_SpoofCallerID is enabled (checked), the OBi will attempt to use the CallerID info from the incoming call that it intends to bridge with.
Yes I read the document but this still provides no example of how to use it as I described. The source is the attached phone not from an incoming call; and I do not see any example of defining spoofed cid.
I am guessing it is done by modifying the OutboundCallRoute of the Phone port in it's dial string but there is no example of the syntax anywhere that I can find. There are examples of w/o spoofing but none with.
Again I assume it is the {(<**2:>(Msp2)):sp2} rule which needs to be modified just not sure of the cid syntax needed here.
CID Spoofing does not belong in the digi mapping. There is no CID syntax. The only place in the OBi you can type in some type of CID is in the
Voice Services>SP1 (2) Service>Calling Features>Parameter Name>CallerIDName = Whatever
See if that works.
I use VoipMS. Their CID spoofing works by getting the CID you setup in the ATA or PBX account when it registers with their service.
Quote from: QBZappy on April 11, 2011, 02:14:48 PM
CID Spoofing does not belong in the digi mapping. There is no CID syntax. The only place in the OBi you can type in some type of CID is in the
Voice Services>SP1 (2) Service>Calling Features>Parameter Name>CallerIDName = Whatever
See if that works.
I use VoipMS. Their CID spoofing works by getting the CID you setup in the ATA or PBX account when it registers with their service.
No I have tried CallerIDName and that doesn't work to change the cid.
Page 115/116 talks about cid spoofing in the OutboundCallRoute. It shows cid as an arg of the terminal and says it is a literal string. That is what is confusing me. I know cid spoofing works with my provider because using the same account from my Asterisk box spoofs it just fine. But I have tried many different combinations of syntax as described on page 115/116 of the latest Obi User Guide to no avail.
VaHam,
I assume from your posts that you're probably experimenting with an OutboundCalRoute rule something like this?:
{(<**2:>(Msp2)):sp2(14151234567>)}
If so, are you testing it by dialing **2 + number. That's the only way this particular rule would match and attempt to set your CallerID. If your VoIP provider is on SP2 and your PrimaryLine is set to SP2, dialing without **2 does go out SP2, but not via this rule. Sorry if you already know and understand this.
I don't have a VoIP provider that permits setting CallerID, so I can't try anything here.
VaHam,
I think there is some confusion over what you think "spoofed caller number" means and what the Admin manual definition of it is.
In the context of the user we expect that term to mean passing our Caller ID info to the party receiving our call.
In the case of the manual (P115-116) I believe it means to pass a "spoofed" telephone number over the digimap to replace the digits which were dialed.
Good examples of spoofed caller number
http://www.obitalk.com/forum/index.php?topic=339.0
{(<411:18002464411>):sp1},
In this context dialing 411 will be replaced (or spoofed) with 18002464411 over SP1
I think they could have used another term to express that concept. It has a dual meaning, which would obviouly create some confusion.
Any other takes on this.
QBZappy,
I more inclined to think you're confused. :)
CallerID spoofing is not the same as number substitution in a DigitMap.
From the OBi Device Administration Guide:
terminal := PHx OR AAx OR LIx(arg) OR SPx(arg) OR PPx(arg) (arg object is optional)
arg := cid > target
- spoofed-caller-number is a literal string, such as 14081112233, to be used as the caller number for making a new call on the specified trunk
More notes on the arg, cid, and target objects:
- The cid object inside an arg object is optional. If omitted, it implies no caller-ID spoofing when making the call on the specified trunk. The succeeding '>' can be omitted is cid is omitted
- The target object inside an arg object is optional. If omitted, it implies the target $2, which means to call the original called number after applying any necessary digit map transformation implied by the rule. The preceding '>' cannot be omitted if target is omitted but cid is not
- arg object is optional. If omitted, it implies the arg with the target $2 and no cid. If arg is omitted, the succeeding parentheses ( ) can be omitted also.
RonR,
Quote from: RonR on April 11, 2011, 10:20:06 PM
From the OBi Device Administration Guide:
- spoofed-caller-number is a literal string, such as 14081112233, to be used as the caller number for making a new call on the specified trunk
Is this not an example of above mentioned statement?
Example:
{(<411:
18002464411>):sp1},
In this context dialing 411 will be replaced
(or spoofed) with 18002464411
(<-literal string) over SP1
(Trunk)
RonR,
Quote from: RonR on April 11, 2011, 10:20:06 PM
CallerID spoofing is not the same as number substitution in a DigitMap.
I didn't say that it was.
I reread that section of the manual (P115-116) and that is the impression I get of what they are trying to convey.
However I can see how you could interpret this to mean Celler ID spoofing.
{(<**2:>(Msp2)):sp2(14151234567>)}
Note the Admin guide uses the term "spoofed-caller-number" as opposed to spoofed caller ID. I think there it is subtle difference in meaning.
QBZappy,
No, it's not.
The syntax for an OutboundCallRoute rule is:
{(callee list):terminal(cid > target)}
cid is an optional number to use for CallerID instead of the default CallerID (spoofed caller number)
target is an optional number to call instead of the original called number.
For example:
{(1xxxxxxxxxx|xxxxxxx):sp2(14151234567>18005551212)}
would match an 11 or 7 digit number, place the call through sp2 using a CallerID of 14151234567, and call 18005551212 rather than the original 11 or 7 digit number that matched.
Quote from: QBZappy on April 11, 2011, 10:41:46 PMNote the Admin guide uses the term "spoofed-caller-number" as opposed to spoofed caller ID. I think there it is subtle difference in meaning.
There is a caller number and a called number. What is caller number if not CallerID.
RonR,
Interesting.
I'll have to play with that.
This is by far the best discussion on this topic. It might even be the first.
Thanks Ron
Progress!
So far I can confirm that using literals does indeed spoof the cid as expected using the following syntax as Ron suggested:
{(1xxxxxxxxxx|xxxxxxx):sp2(14151234567>18005551212)}
I have not yet been successful at getting the cid spoofing working when the called number is a variable. The documentation says that it can either be a literal (which works) or $2 (which doesn't work for me.
This is why I brought up the question about syntax here. Am I miss understanding the meaning of the "$2" in the second part of the arg (above that is the 18005551212) perhaps?
Quote from: VaHam on April 12, 2011, 09:54:58 AM
Progress!
So far I can confirm that using literals does indeed spoof the cid as expected using the following syntax as Ron suggested:
{(1xxxxxxxxxx|xxxxxxx):sp2(14151234567>18005551212)}
I have not yet been successful at getting the cid spoofing working when the called number is a variable. The documentation says that it can either be a literal (which works) or $2 (which doesn't work for me.
This is why I brought up the question about syntax here. Am I miss understanding the meaning of the "$2" in the second part of the arg (above that is the 18005551212) perhaps?
Ok problem solved; it is indeed the interpretation of
$2. $2 is the term
(Msp2). So the correct syntax here is:
{(<**2:>(Msp2)):sp2(NNNNNNNNNN>(Msp2))} for that term of the Phone OutboundCallRoute where NNNNNNNNNN is the spoofed cid.
By making NNNNNNNNNN equal to my GV number which is on SP1 then I can call out on either SP1 or SP2 (which is a different sip provider) and have my GV cid displayed to the caller.
VaHam,
From my read of the documentation, both of these should be identical:
{(1xxxxxxxxxx|xxxxxxx):sp2(14151234567>$2)}
{(1xxxxxxxxxx|xxxxxxx):sp2(14151234567>)}
and should set the CallerID to 14151234567 on an SP2 call to the 11 or 7 digit number resulting from the matched embedded DigitMap (1xxxxxxxxxx|xxxxxxx).
In another thread, the poster noted that $2 does not work as advertised, but was unable to get an explanation from the Obihai folks as to why.
I don't believe that's correct. From the documentation:
$2 is an internal variable containing the called number of this inbound call, after any digit map transformation in the matched callee object of the matched peering object in the peering-list.
and
The target object inside an arg object is optional. If omitted, it implies the target $2, which means to call the original called number after applying any necessary digit map transformation implied by the rule. The preceding '>' cannot be omitted if target is omitted but cid is not
'$2 is the term (Msp2)' doesn't make any sense to me, nor does its use in the manner you suggest.
Quote from: RonR on April 12, 2011, 10:28:34 AM
I don't believe that's correct. From the documentation:
$2 is an internal variable containing the called number of this inbound call, after any digit map transformation in the matched callee object of the matched peering object in the peering-list.
and
The target object inside an arg object is optional. If omitted, it implies the target $2, which means to call the original called number after applying any necessary digit map transformation implied by the rule. The preceding '>' cannot be omitted if target is omitted but cid is not
'$2 is the term (Msp2)' doesn't make any sense to me, nor does its use in the manner you suggest.
While I agree with your assessment of the $2's intended value I can tell you that it does not work however using (Msp2) as I showed above does in fact work! I won't fight with success :)
I give up. The documentation says:
arg := cid > target
cid := spoofed-caller-number OR $1
target := number-to-call OR $2
Notes:
- number and number-to-call are literal strings, such as 14089991234
Putting a DigitMap (Msp2) in as a literal string doesn't make any sense.
Quote from: RonR on April 12, 2011, 02:33:11 PM
I give up. The documentation says:
arg := cid > target
cid := spoofed-caller-number OR $1
target := number-to-call OR $2
Notes:
- number and number-to-call are literal strings, such as 14089991234
Putting a DigitMap (Msp2) in as a literal string doesn't make any sense.
Fortunately is looks like because the Msp2 is enclosed in brackets () it gets interpreted as a variable rather than a literal string.
For some reason $2 does not seem to equate to (Msp2) as both you and I would have thought from the documentation.
I suspect the difference has to do with stripping off the leading **2 from the number to call. I am guessing that $2 includes the leading **2 and in processing the DigitMap for the Phone port (Msp2) gets the **2 stripped off.
Quote from: VaHam on April 12, 2011, 03:01:02 PMFor some reason $2 does not seem to equate to (Msp2) as both you and I would have thought from the documentation.
I've never thought that $2 equates to (Msp2). $2 is supposed to an internal varialble that holds the number to be called, which is the result of the DMP evaluating the (<**2:>(Msp2)) to the left of the colon, using the value returned by the DMP when it evaluated the number dialed though the PHONE Port DigitMap.
Page 116:
- $2 is an internal variable containing the called number of this outbound call, after any digit map transformation in the matched callee object
Quote from: RonR on April 12, 2011, 03:22:51 PM
Quote from: VaHam on April 12, 2011, 03:01:02 PMFor some reason $2 does not seem to equate to (Msp2) as both you and I would have thought from the documentation.
I've never thought that $2 equates to (Msp2). $2 is supposed to an internal varialble that holds the number to be called, which is the result of the DMP evaluating the (<**2:>(Msp2)) to the left of the colon, using the value returned by the DMP when it evaluated the number dialed though the PHONE Port DigitMap.
Page 116:
- $2 is an internal variable containing the called number of this outbound call, after any digit map transformation in the matched callee object
I should have said $2 should equate to the result of Msp2 having been applied as I think we both surmised from the documentation. But that does not appear to be the case. However enclosing the Msp2 in brackets (which apparently makes it be interpreted as a variable) does in fact give us the correct value.
I know what the manual says; but from my testing it does not work that way. Perhaps someone else who actually has the capability of testing this can confirm my tests; but for me I can tell you that is works as I stated above and not as the manual states!
Have you also tried?:
{(<**2:>(Msp2)):sp2(14151234567>)}
Note the trailing '>' above.
With ITSPx -> X_SpoofCallerID checked.
And testing it by making a call as **2 + number to see if the correct number is called and if the expected CallerID is displayed (using the desired CallerID in place of 14151234567, of course).
Quote from: RonR on April 12, 2011, 04:03:27 PM
Have you also tried?:
{(<**2:>(Msp2)):sp2(14151234567>)}
Note the trailing '>' above.
With ITSPx -> X_SpoofCallerID checked.
And testing it by making a call as **2 + number to see if the correct number is called and if the expected CallerID is displayed (using the desired CallerID in place of 14151234567, of course).
Yes I have and no it doesn not work!
UPDATE: I was wrong this does work!
Ok, I just wanted to make sure all those aspects went into the test at the same time.
What part(s) failed? Wrong number called? Wrong CallerID?
Quote from: RonR on April 12, 2011, 04:16:50 PM
Ok, I just wanted to make sure all those aspects went into the test at the same time.
What part(s) failed? Wrong number called? Wrong CallerID?
Ok I went back to make sure the error code was the usual 407. And I must correct myself; it seems that the
{(<**2:>(Msp2)):sp2(4151234567>)} syntax does also work just fine. I know I attempted to try this case in earlier testing before I hit on the one which worked; so I must have made some other mistake back then.
So now the document makes a little more sense when it states:
"The target object inside an arg object is optional. If omitted, it implies the target $2, which means to call the original called number after applying any necessary digit map transformation implied by the rule. The preceding '>' cannot be omitted if target is omitted but not the cid."
The $2 is equal to the value of (Msp2) but can be specified by simply leaving it blank in which case it defaults to the same value as (Msp2). The syntax I used probably caused the Msp2 algorithms to be called twice.
By "preceding", in the documentation, it is applying to the target and whether the default target is used or not the > must follow the spoofed-caller-number.
What is interesting here is that since (Msp2) also work then other DigitMaps can probably be used here as well I would assume to include user DigitMaps. This may provide for other interesting possibilities. Perhaps the digitmap for the called number could be different than the original dialed number by use of user defined digitmaps.
Again I think one example of the spoofing in the documentation could have avoided all the discussion in this thread :)
{(<**2:>(Msp2)):sp2(14151234567>)} was the only suggestion I made because it's exactly what the documentation calls for.
I still think you have some misconceptions about $2 and Msp2, but this has gone on long enough already. I certainly agree the documentation could be improved. Occasional input from the Obihai folks would also go a long way to clarify things.
Quote from: RonR on April 12, 2011, 10:23:38 AM
VaHam,
From my read of the documentation, both of these should be identical:
{(1xxxxxxxxxx|xxxxxxx):sp2(14151234567>$2)}
{(1xxxxxxxxxx|xxxxxxx):sp2(14151234567>)}
and should set the CallerID to 14151234567 on an SP2 call to the 11 or 7 digit number resulting from the matched embedded DigitMap (1xxxxxxxxxx|xxxxxxx).
In another thread, the poster noted that $2 does not work as advertised, but was unable to get an explanation from the Obihai folks as to why.
Well I will have to agree with the poster in the other thread that $2 does not work and therefore the two cases you cite above are not in fact equal.
But either
{(<**2:>(Msp2)):sp2(4151234567>)} OR
{(<**2:>(Msp2)):sp2(4151234567>(Msp2))} does achieve my goal of having my GV cid shown on my second provider instead of it's own cid, since my second provider is on SP2. That way no matter which one I use to dial out on; if the called party just returns the call they will go back to my GV number.
Quote from: VaHam on April 12, 2011, 09:13:31 PM
Well I will have to agree with the poster in the other thread that $2 does not work and therefore the two cases you cite above are not in fact equal.
But either {(<**2:>(Msp2)):sp2(4151234567>)} OR {(<**2:>(Msp2)):sp2(4151234567>(Msp2))} does achieve my goal of having my GV cid shown on my second provider instead of it's own cid, since my second provider is on SP2. That way no matter which one I use to dial out on; if the called party just returns the call they will go back to my GV number.
You say you can show your google voice cid over either sp1 or sp2. But I would like my sp2 number to show on sp1. However, since sp1 is my gv number it is my understanding that I cannot do that, since gv doesn't support spoofing. Is this correct?
Correct, you can't change the number that shows up when calling using google voice.
Quote from: VaHam on April 12, 2011, 09:13:31 PM
Well I will have to agree with the poster in the other thread that $2 does not work and therefore the two cases you cite above are not in fact equal.
But either {(<**2:>(Msp2)):sp2(4151234567>)} OR {(<**2:>(Msp2)):sp2(4151234567>(Msp2))} does achieve my goal of having my GV cid shown on my second provider instead of it's own cid...
Hi all,
(old thread i know but it's exactly my issue)
Can anyone confirm the above quoted method and syntax still works on current OBIs/firmware?
I'm trying to get this to work on an OBi200 with firmware 3.0.1 (build: 4581) ... and it's not happening.
I can confirm that Voip.ms blocks this functionality.
http://wiki.voip.ms/article/Caller_ID#Outgoing_Caller_ID_number
There is currently a field within the customer's account pages that allows the CallerID to be entered (or left blank). It can be changed at any time by the customer and does not have to match any numbers on-account. If the field is left blank, Voip.ms passes the customer's 'main account ID' as the CallerID - which I'm not sure is such a great idea.
I've put in a feature request for them to allow ATA/software-specified CallerID to pass through their system but I don't expect a response as to If or When it might be implemented.
I have the same issue - I'm using Freecall as the provider. They allow you to set any registered number (that has been verified) or no callerid. But what I want is to be able to set one of my DIDs as the callerid if I call a specific country and the other one if not. I shoudl be able to so that with OBI100 I thnk, but I gues that Freecall is blocking it. (at the moment I am having a hard time getting the to understan dteh question I am asking, even)
Quote from: amarden on December 07, 2015, 11:24:32 AM
I have the same issue - I'm using Freecall as the provider. They allow you to set any registered number (that has been verified) or no callerid. But what I want is to be able to set one of my DIDs as the callerid if I call a specific country and the other one if not. I shoudl be able to so that with OBI100 I thnk, but I gues that Freecall is blocking it. (at the moment I am having a hard time getting the to understan dteh question I am asking, even)
https://www.freecall.com/helpdesk2#/answer-772_ is not clear as to whether the outbound CID from them is changeable on the fly from your OBi.
- On SIP
Log in on the website with username / password and choose the tab option called "Settings".
1. Check the SIP settings on the Settings page. The Sip Server Access should be set to "Enable".
2. In the phone number section on the same Settings page check if the number you want to use as Caller ID is verified and "Caller ID" is selected.
Check the configuration of your SIP device (Check the SIP information on our website and/or the information of the producer of your SIP device) and depending on the chosen configuration below, check the following:
- When using the User name in the SIP configuration of your device, we will use the caller ID as set on the Settings page of our website.
- When using a Phone number in the SIP configuration of your device, make sure you use the international format and that the same number has been entered in the Phone number section of the Settings page and has been verified.