new Caller-ID spoofing inquiry over SIP for Obi 110
QBZappy:
If you want to pass CID of the original call from one OBi to another OBi it should be possible using the OBiTALK service. I think you can find some examples of CID spoofing using the OBiTALK service if you search the forum.
http://www.obitalk.com/forum/index.php?topic=9.msg13#msg13
Enhancements & Fixes in Maintenance Release 1.3.0(2575):
Version 1.3 highlights:
...
- Allow Caller-id spoofing for calls bridged via OBiTALK service. But use the obi number for circle-of-trust authentication.
QBZappy:
Tom,
Quote from: tmetro on November 21, 2012, 02:21:26 pm
Right, so the expression becomes:
{(Mtesting):vg3($1>9991234)}
At least that's what the administrator's guide leads me to believe. The documentation for InboundCallRoute says:
$1 is used internally (temp incoming CID variable) for the callback feature. I have never seen it used in any other fashion. AFAIK, I don't think it can be used in any user configuration call strategy. If anyone has figured out how to use it, it would be interesting to see it in action.
rob613:
Correct, I tried the > rule and did not see it work.
Is there a particular place where this deficiency is documented? Would anyone from Obihai please comment about when it will work?
I believe that the scenarios I've described would be of general use. Limiting CID spoofing to just two Obi devices would be far less useful than the documentation describes.
hwittenb:
rob613,
With X_SpoofCallerID enabled you should forward the incoming call in the Line Port inbound call route to a sip uri instead of to a regular number and the original caller id should go along with the sip uri call. When you send the call to a number the call often gets rejected by your voip provider when the call has a spoofed caller id. This is usually due to the voip provider's authentication process. Of course your voip provider needs to accept incoming sip uri calls. Many providers do accept them, some do not.
As you know the format for a sip uri call would be something like this: SP2(1234562@losangeles.voip.ms) where SP2 is setup for sip.
Of course, the OBi110 Line port needs to capture the incoming caller id during the "Ring Delay" period which has a default setting of 4 seconds. You should look at your OBi's Call History and see that the OBi captured the incoming caller id as shown in the Peer field.
I'm not sure how to handle the name.
rob613:
I've been tinkering more with the spoofing rules and not seeing it do what I need or expect.
I also see that there is a user agent parameter "X_UserAgentName" in the ITSP areas with a few internal variables in it - does this get evaluated on a per-call basis, and is there any internal variable reflecting caller ID that could be stuck in here?
This might be a way of getting some payload out to the final destination for logging purposes.
I also discovered that although I am using a VG (which is based on my SP2 configuration) I am seeing my SP2 username, which should be irrelevant, getting exposed to the forwarded SIP call.
I don't see any way of including the original call's caller-ID into the AuthUserID parameter, but that might be another option for disclosing that as part of forward.
Navigation
[0] Message Index
[#] Next page
[*] Previous page