OBi110 and star codes
aloysius:
Quote from: ianobi on November 01, 2012, 11:18:15 am
That's odd. I'm running out of ideas ??? Also running out of time for today. Over the next few days I will try to reproduce exactly what you are doing on my OBi and see if I can figure something out.
Keep experimenting, I find trial and error is a good method :)
I will, thanks for your help.
ianobi:
First the corrections From the ObiDeviceAdminGuide:
$BCI = block outbound caller-ID enable (trunk specific; admissible value: 0 for disable, 1 for enable)
$BCI1 = block caller-ID once (global; admissible value: 1 for enable)
So the persistant version of blocking can be trunk specific, but the “block once” has to be global – all trunks.
From my experiments, all that is happening here is that if you use *67 (*66 in your case), then all that happens is that Obi blocks Caller ID Name.
I tried using “Caller ID Spoofing” (not using Star Codes). This can be made to work, but then most providers use the Caller ID as part of the call authentication process, so the call fails. I was using sip2sip for my experiments – calls fail without Caller ID.
Is this another case of sending a code to your service provider to get them to block your Caller ID from going forward to the called number?
aloysius:
Quote from: ianobi on November 02, 2012, 04:08:50 am
First the corrections From the ObiDeviceAdminGuide:
$BCI = block outbound caller-ID enable (trunk specific; admissible value: 0 for disable, 1 for enable)
$BCI1 = block caller-ID once (global; admissible value: 1 for enable)
So the persistant version of blocking can be trunk specific, but the “block once” has to be global – all trunks.
From my experiments, all that is happening here is that if you use *67 (*66 in your case), then all that happens is that Obi blocks Caller ID Name.
I tried using “Caller ID Spoofing” (not using Star Codes). This can be made to work, but then most providers use the Caller ID as part of the call authentication process, so the call fails. I was using sip2sip for my experiments – calls fail without Caller ID.
Is this another case of sending a code to your service provider to get them to block your Caller ID from going forward to the called number?
Unfortunately most of what you said is Greek to me. :D
I saw an X_SpoofCallerID parameter under ITSP Profile A, but there's only a checkbox as value. I understand that's only to allow it, but where is the outgoing CID supposed to be specified? ???
Anyway this issue is not really important for me: the real crux was with *67# and that has been solved.
jimates:
x_calleridspoofing is only for bridged calls. You don't provide the information, it is taken from the original call that id being bridged.
X_CallerIdSpoofing
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, e.g. an IP PBX may allow it.
ianobi:
@ jimates:
Everything you say is true. However, in additon it is possible to "invent" Caller ID by setting Allow Outbound Caller ID Spoofing to Yes and putting a rule such as this:
{(<**2:>(Msp2)):sp2(123456>)}
into the Phone Port OutboundCallRoute. This will change Caller ID for calls dialled with **2 to 123456.
Anyhow, it's all a bit academic as the result with most service provider is that the call fails its authentication process.
Another little trip down a wandering tangent of a lane :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page