Confidential number coming thru iTalk VOIP

Forums › VoIP › Confidential number coming thru iTalk VOIP

tonyb

9 posts

Wannabe Geek

#12861 10-Apr-2007 13:12

We use iTalk for our phone service, and have a number of people call us that have confidential numbers.

But we are seeing that their phone number is actually coming thru with iTalk....has anyone else seen this ?

Most calls seem to come thru with the {number/no name}, whereas the confidential listings are showing as {anonymous/number}

maybe just a bad implementation of caller id ?

1 | 2

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#66719 10-Apr-2007 13:44

What sort of ATA/phone are you using?

There are two parts to callerid. The ANI/ALI information which is sent as part of the SS7 signalling with a setting as to whether this should be visible or hidden to the end party. The CallerID is then sent between the 1st and 2nd ring.

iTalk were initially not blocking any CID information however they have been doing this for at least the past year and I haven't experienced what you are seeing. The information is available however if you're using Asterisk and I agree that CallPlus should probably not be doing this, they should be stopping all callerid information from being transmitted to remote partys. At the end of the day however you can't truely block your callerid information, much like you can't really hide you IP address on the internet.

tonyb

9 posts

Wannabe Geek

#66721 10-Apr-2007 14:13

Yes, I am using Asterisk, I would have thought that the callerid would be blocked at the originating network, but I guess it needs to be passed thru right till the end for proper call tracking.....obviously as you say Call Plus is not doing the final supression of the number.

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#66722 10-Apr-2007 14:40

The ANI/ALI part is sent as part of the signalling so this is passed to Asterisk. Asterisk should be default not generate the CLI information if the ANI/ALI says this should be blocked. I purposely changed my system so I could view the blocked information, by default Asterisk shouldn't.

The big question is whether CallPlus should be sending this information to Asterisk in the first place, maybe Phil would like to comment on whether this is right or rong?

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#66723 10-Apr-2007 14:49

Actually, CLI should not be presented at all to an End User Device, if a Carrier hands off a Call with Restricted CLI then the Carrier should be marking this in a SIP Packet like so, The From Header Field should be changed

The Carrier would recieve something like this
From:"099501300";tag=1641775454-1176172714933 privacy=full

and we would change it to delievry to the end user so it appears as

From:"Anonymous";tag=1641775454-1176172714933 now this is what you as the user should get anything else is bad

There is another way to do this but this is at a carrier level and uses privacy indicators instead of changing the From Header, sending that type type of message to a End user in a class 5 situation is not Technically correct for a Carrier installation as it means anyone that can decode the SIP message can find the calling CLI (very bad practice)

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#66727 10-Apr-2007 15:30

If you can send me a copy of the Invite you recieve I will tell you what is wrong with it if you like.

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

jpollock

600 posts

Ultimate Geek

Trusted

#66744 10-Apr-2007 20:51

Maverick is correct, if presentation is restricted in the SS7 message, it definitely should not be passed on by iTalk's session border controller.

It's a pretty standard problem where trusted carrier networks meet untrusted customer networks, and will only get worse in the coming years.

This is the same class of bug that allowed the Paris Hilton and ministerial voice mail hacks last year. (except those were in the other direction).

Nicely caught!

---
http://blog.jason.pollock.ca

richms

28218 posts

Uber Geek

Trusted

Lifetime subscriber

#66752 10-Apr-2007 21:28

tonyb: We use iTalk for our phone service, and have a number of people call us that have confidential numbers.

But we are seeing that their phone number is actually coming thru with iTalk....has anyone else seen this ?

Most calls seem to come thru with the {number/no name}, whereas the confidential listings are showing as {anonymous/number}

maybe just a bad implementation of caller id ?

That explains my lack of inconsiderate callers, shame they will most likly fix it :(

Richard rich.ms

Sharesies

Trade NZ and US shares and funds with Sharesies (affiliate link).

paradoxsm

3000 posts

Uber Geek

Trusted

#66753 10-Apr-2007 21:33

This is rather interesting. I wonder how long it will remain now it's been revealed. I might make some nice use of this over the next few days if so....

Ps, is that your number maverick? "099501300"

richms

28218 posts

Uber Geek

Trusted

Lifetime subscriber

#66754 10-Apr-2007 21:38

Just tried it, and sure enough, even with 0197 the cellphone number comes up. This is great, lets hope they don't fix it.

Richard rich.ms

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#66755 10-Apr-2007 21:45

paradoxsm: This is rather interesting. I wonder how long it will remain now it's been revealed. I might make some nice use of this over the next few days if so....

Ps, is that your number maverick? "099501300"

It was "revealed" about 18 months ago on the iTalk forums, it's hardly news. "Anonymous" is sent as the CID by iTalk, it's just that the number is available if you look for it.

FYI Phil here's a debug of a SIP packet I just looked it with CID blocked

To: <sip:64497xxxxx@203.184.16.35:5060>
From: "anonymous" <sip:6421xxxxxx@203.184.16.35>;tag=3385186495-822849

and a packet with CID unblocked

To: <sip:64497xxxxx@203.184.16.35:5060>
From: <sip:6421xxxxxx@203.184.16.35>;tag=3385186662-555498

If you have FreePBX installed you see "anonymous" <6421xxxxxx> show up in the CLID column in reports.

Is it a requirement of telcos who have interconnects to actually block CID if this has been set by the originator of the call?

paradoxsm

3000 posts

Uber Geek

Trusted

#66761 10-Apr-2007 22:50

yes but our "normal" caller id's on stock-o phones (not new_fangled asterisk pc pabx systems) did not show the anonymous numbers a month back, it looks to have changed when they reset the clock from daylight saving to normal time... let's say nothing more and enjoy it.

richms

28218 posts

Uber Geek

Trusted

Lifetime subscriber

#66763 10-Apr-2007 23:33

My thoughts exactly, mods, please kill this thread before someone at slingshot reads it.

Richard rich.ms

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#66767 11-Apr-2007 05:53

paradoxsm: This is rather interesting. I wonder how long it will remain now it's been revealed. I might make some nice use of this over the next few days if so....

Ps, is that your number maverick? "099501300"

Nope....:).....Company Main Office Number

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#66768 11-Apr-2007 06:15

sbiddle:
paradoxsm: This is rather interesting. I wonder how long it will remain now it's been revealed. I might make some nice use of this over the next few days if so....

Ps, is that your number maverick? "099501300"

FYI Phil here's a debug of a SIP packet I just looked it with CID blocked

To:
From: "anonymous" ;tag=3385186495-822849

and a packet with CID unblocked

To:
From: ;tag=3385186662-555498

If you have FreePBX installed you see "anonymous" <6421xxxxxx> show up in the CLID column in reports.

Is it a requirement of telcos who have interconnects to actually block CID if this has been set by the originator of the call?

Yes , by the looks without seeing the full invite, the formatting of the Invite is not correct, if you are seeing CLI then the formatting of the message is incorrect

here is an example of a correct message through a carrier network, the first message will contain privacy information even though the CLI is visbale through the messaging (privacy=full), but the message to the user level has been changed to reflect the privacy which all carriers should honourl

Rxed from Interconnect

INVITE sip:9950xxxx@x.x.x.x:5060;user=phone SIP/2.0
Max-Forwards: 69
Session-Expires: 3600;Refresher=uac
Supported: timer
From: "anonymous" ;tag=3385216987-490578
Remote-Party-Id: ;party=calling;screen=yes;privacy=full
Call-ID: 3528851-3385216987-490511@x.x.x.x
CSeq: 1 INVITE
Via: SIP/2.0/UDP x.x.x.x:5060;branch=d82aec242937edf825a50a0a4cbdbb2f
Contact: sip:0213xxxxx@x.x.x.x:5060
Content-Type: application/sdp
Content-Length: 349

Passed to Enduser
INVITE sip:9950xxxx@x.x.x.x:8062;transport=UDP SIP/2.0
From: "Anonymous";tag=96141c3a-1f7c-461bd046-678fbe42-4080b1db
To: "Ops 2 Test"
Call-ID: BW055831430110407366942355@x.x.x.x
CSeq: 1 INVITE
Via: SIP/2.0/UDP x.x.x.x:8060;branch=z9hG4bK-461bd046-678fbe43-575ea478
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,UPDATE,NOTIFY
Supported: 100rel
Accept: multipart/mixed,application/sdp
Max-Forwards: 10
Contact:
Content-Type: application/SDP
Content-Length: 334

Yes it is a requirment to restrict CLI if presented, however whilst we have SS7 standards for interconnect which all carriers must pass , SIP by it's nature is open standrad and can implemented in a number of ways and bad implentations can lead to issues, it appears they are trying too, but not only are they using bad formatted messaging, really they are also using the totally incorrect way of supplying privacy to an end user. This is not good

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

ajobbins

5052 posts

Uber Geek

Trusted

#69210 2-May-2007 12:01

Yes I can see them too. I'm running asterisk and they come through on all the call logs. I saw the same thing with Woosh last year, brought it to their attention and then they fixed it.

Twitter: ajobbins

1 | 2