new Caller-ID spoofing inquiry over SIP for Obi 110

[rob613]

This forum shows an old topic somewhat similar to this, but over PSTN.
I would like to get some guidance for how to use Caller-ID spoofing over a SIP forward that I am testing.
I have enabled the spoofing (field X_SpoofCallerID) in both the ITSP profiles for SIP.

My inbound call route is the following:
{(Mtesting):vg3(9991234)},{(Mreject):sp1(2125551234)}...

As I will explain, what else should I put near vg3 to enable spoofing the call with the Caller-ID of the call that matches my "testing" digit map?

My VG3 uses the technique listed in another thread for tf.callwithus.com for toll-free calls.

When I receive a call on my PSTN line that matches a known set of Caller-ID's, I want to forward them through to a specific SIP URI, such as my softphone.   This forwarding is working but I want to do it so that the call will come through with the original call's Caller-ID, not the caller ID of my SP service.

My forward is working via the LINE port InboundCallRoute.   Within the parameter I am calling out through a VG because I am using a different SIP configuration than my normal SP configuration.

By using a digitmap for the set of CID's that I want to match and forward I suspect that I can use a backreference, and that I will need to use the > character within the forward rule.

And since this is receiving CID with Name on my PSTN line, and I am spoofing a SIP call to a SIP extension, is there anything more I need to do so that the CID-Name field will be populated within the SIP header?    Are there any other SIP header fields I can fill out to try to distinguish that this is my PSTN line's received calls?

When I am home I am likely to answer these calls on my regular phone handset, but if I am away, but have a SIP phone with me and online, I think I should be able to easily answer my ringing PSTN line from a remote location with this technique.  Question: will the Obi take my PSTN line off hook only when the SIP call answers?

And for calls that I want to reject, I already have another rule in place (discussed in another thread), for calls from known telemarketers who have been told to not call my PSTN line again.   I still enjoy this when the Obi spares me from having to answer such calls.   I would like to add the CID spoofing capability there as well.

[QBZappy]

rob613,

..., not the caller ID of my SP service.

You may need to find a CID spoofing friendly service provider. Most SPs prevent CID spoofing. I know that voipms, and a few others allow it.

[tmetro]

You may need to find a CID spoofing friendly service provider.

This can be true if you are using a VoIP provider to gateway to PSTN. In that case you are dependent on the VoIP provider to permit you to spoof a CID, which they in turn send as part of the PSTN call.

To clarify, in this situation Rob is making a connection from an OBi to a SIP end-point, and the only party involved in the spoofing is the OBi.

-Tom

[QBZappy]

rob613,

This might help:

http://www.obitalk.com/forum/index.php?topic=530.msg3269#msg3269
Re: Inbound call routing issue: $1 not working

OBi passes both, name and number, from the original call, if X_SpoofCallerID is yes.
ITSP however might not take it, and may reject the call all together. That's why
this is option depending on your ITSP.

However, using the SP2(xyz > abc) syntax in an InboundCallRoute, it can only spoof the number; we currently don't have a syntax for spoofing a name this way.

Also, even when we spoof it, the ITSP can selectively take the name or number part as they please and present the call to the final destination.

You have more control if the "ITSP" is a PBX (like Asterisk) for example. I do not expect this option to be very useful for a general commercial ITSP.

[tmetro]

I have enabled the spoofing (field X_SpoofCallerID) in both the ITSP profiles for SIP.

I didn't see mention of that in the documentation as being necessary in order to use CID spoofing in the InboundCallRoute. That's not to say it isn't, as the documentation could be deficient.

The impression I get from the documentation for X_SpoofCallerID is that it is used when the OBi is gatewaying a call from PSTN to a VoIP outbound trunk line. It isn't clear whether this is orthogonal to the InboundCallRoute rules, or whether it merely establishes a default behavior.

My inbound call route is the following:
{(Mtesting):vg3(9991234)},{(Mreject):sp1(2125551234)}...

Lets simplify. Only one of these is relevant to the question at hand:
  {(Mtesting):vg3(9991234)}

As I will explain, what else should I put near vg3 to enable spoofing the call with the Caller-ID of the call that matches my "testing" digit map?

...forwarding is working but I want to do it so that the call will come through with the original call's Caller-ID, not the caller ID of my SP service.

...that I will need to use the > character within the forward rule.

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:

Code Select Expand


  terminal := PHx OR AAx OR LIx(arg) OR SPx(arg) OR PPx(arg)
  arg := cid > target
  cid := spoofed-caller-number OR $1
  target = number-to-call OR $2

  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

  $1 is an internal variable containing the value of the caller number of this inbound call,
  after any digit map transformation in the matched caller object of the matched peering
  object in the peering-list.


But my understanding is that you've tried this, and it didn't work.

-Tom

[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,

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.

[hwittenb]

rob613,

The X_UserAgentName field is to tell the distant server about your OBi adapter ... for instantance that it is an OBi110 running firmware 1.3.0.2744.

On a straight outbound call, in the Sip Invite the VoiceGateway (if using) AuthID goes into the From: and the Remote-Party-ID: fields.  The SPx AuthUserName goes into the Contact field.  This is also true if ringing a distant number from the Inbound Routing. 

On the other hand, if you are forwarding a call to a Sip Uri using SPx (and have X_SpoofCallerID enabled) the CallerID goes into the From: and Remote-Party-ID: fields, the SPx AuthUserName goes into the Contact field, assuming the OBi captured the incoming caller ID.  If you are forwarding a call to a Sip Uri using VGx the OBi does not forward the call, you need to specify SPx.

The toll free call example mentioned early on in the thread works because the distant server (tf.callwithus.com) does not authenticate the call (determine that you do have an account with them) and the AuthID you setup in the VGx goes into the From: and the Remote-Party-ID fields.

If you want to study how different variables affect the sip signalling you should setup to use the packet sniffer WireShark.  You can look at the packets that actually come out of the adapter.  You setup your OBi adapter and your computer to both attach to an old fashioned hub (not a switch) that is cabled to your external router.  With that cabling your computer can see all the ethernet traffic going to and from your OBi and the internet.  Then you install WireShark (a free program) on your computer.  WireShark has a nice formatting feature for sip calls.  After you make a call you can invoke the WireShark formatter which will outline the call signalling and then you can click on a specific packet (like the sip INVITE) and see the various fields. 

[tmetro]

...the expression becomes:
  {(Mtesting):vg3($1>9991234)}

$1 is used internally (temp incoming CID variable) for the callback feature. ...I don't think it can be used in any user configuration call strategy.

So would you agree that if it doesn't work as depicted above, the firmware or the documentation has a bug?

Does Obihai have a bug reporting mechanism, or do we just hope they notice mention of bugs in forum threads?

-Tom

[tmetro]

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.

Sounds like a bug.

If you are forwarding a call to a Sip Uri using VGx the OBi does not forward the call, you need to specify SPx.

Sounds like a bug.

If you want to study how different variables affect the sip signalling you should setup to use the packet sniffer WireShark.

Good general advice. In this case Rob is using a developer account at Tropo (free) to receive the SIP invite messages, and it logs the full headers for easy inspection.

-Tom

[QBZappy]

rob613,

This might be the solution to pass CID. Have a look.
ui=$1

Re: Spoofing Solved
http://www.obitalk.com/forum/index.php?topic=4658.msg30451#msg30451

I never could get spoofing to work.  I gave it one more try and I did it!

This works WITHOUT enabling X_SpoofCallerID.  The problem with X_SpoofCallerID is that some providers don't like spoofing and when enabled it's on  for everything going out SPx.

I got it to work with PBX in a Flash and Callcentric.

Here's an InboundCallRoute example:

{ph,sp2(100@192.168.1.999:5060;ui=$1),sp2(17772223333@in.callcentric.com;ui=$1}

[rob613]

QBZappy,  thank you very much for following up with this information.

It did not work for me.
Putting the ";ui=$1" expression within the call through the VG (where it only takes an extension, not a full SIP specification) resulted in it getting inserted as part of the extension, literally.   I also tried putting it elsewhere in the VG call.

For my need I would like to see something like an even more generic SIP forward option where, similar to a VG, no registration is used, but where all options for a SIP call could be specified, including ui, and spoofing.

This would also help reduce the exposure of the SP2 username when calling out through a VG that has nothing in common with the SP2 configuration except that it is the same SIP protocol - I see this as a bug.

FYI, I have solved my problem a different way - a bit complicated but it seems to work.   Anyone who wants to know more can try to get a private message to me.  It requires external help, and runs not just within the Obi.

[QBZappy]

Have a look here. The info looks like it may help you.

Enhancements & Fixes in Maintenance Release 1.2.1(2283):
http://www.obitalk.com/forum/index.php?topic=9.msg13#msg13