News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Outbound CID Spoofing is it possible?

Started by Loughary, February 26, 2011, 12:03:23 PM

Previous topic - Next topic

RonR

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.

RonR

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. 

QBZappy

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
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

VaHam

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?

VaHam

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.


RonR

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.

RonR

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.

VaHam

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 :)

RonR

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.

VaHam

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.

RonR

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

VaHam

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!


RonR

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).

VaHam

#33
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!

RonR

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?

VaHam

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 :)

RonR

{(<**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.

VaHam

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.

Encino_Stan

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?

jimates

Correct, you can't change the number that shows up when calling using google voice.