This post is at: ForumFeatures Wanted
3 posts / 0 new
Last post
amagurie's picture
Joined: 2008/04/02
Points: 0


I was wondering if it would be possible to get a checkbox in the TL user extension screen to select if the extensions outgoing callerid will be displayed or masked. I don't know if it is common or not but our SIP trunk provider will mask the CallerId if we set the caller if name to 'Anonymous', the only issue with this is some of our users like to unmask there callerid for certain calls.

I created two 'Feature extension' that will allow our users to either dial 0197... (mask) or 0196... (unmask) there callerid based on the following scripts.

exten => s,1,Set(CALLERPRES()=prohib_passed_screen)
exten => s,n,Goto(from-inside-redir${TL_DASH}${tenant},${MACRO_EXTEN:${ARG1}},1)

exten => s,1,Set(CALLERPRES()=allowed_passed_screen)
exten => s,n,Goto(from-inside-redir${TL_DASH}${tenant},${MACRO_EXTEN:${ARG1}},1)

I cloned tl-dialout-base and added the following to see if the extension should mask there extension by default:

exten => s,n,GotoIf($["${temp}" = "Anonymous"]?:noanonymous)
exten => s,n,GotoIf($[${CALLINGPRES} > 0]?callerpres)
exten => s,n,Set(CALLERPRES()=prohib_passed_screen)
exten => s,n(callerpres),Set(temp="")
exten => s,n(noanonymous),Set(CALLERID(name)=${temp})

This all works well except if the callerid name is set to anonymous I need to unset it if they choose to unmask for a particular call as the SIP provider seem to prefer it over callerid presentation.

Would it be possible to get a definable include/macro that we can implement our own logic without having to clone and maintain our own version of tl-dialout-base via a variable being set from the TL for the extension Mask/Unmask of callerid, or set CALLERPRES() directly... not sure if it works for any trunk type other than SIP though.

What do you think?


eeman's picture
Joined: 2007/11/06
Points: 290

we tried.. CALLERPRES works on pri's and it works when enabling Remote-Party-ID sip hearers (trustrpid and sendrpid in sip.conf). However many broadsoft switches wont trust it and insist on a makeshift work around where you delete the callerid data and then send the callerid in a sip header called P-Asserted-Identity. This header does not traverse through asterisk servers.. so if your take a scenario like

phone->Asterisk1->Asterisk2->Broadsoft the headers added by SIPAddHeader do not end up in the packets leaving Asterisk2 to the broadsoft switch.

Another concern about the P-Asserted-Identity 'trick' is that you will notice in the news/announcement forum I posted that one state has now created a law that criminalizes altering callerid. Technically setting the value of CALLERID(num) and CALLERID(name) to an empty string and the word 'private' technically violates that.

This gets even MORE complicated by the fact that there are now 6 different 'tricks' for the SIPAddHeader method and each provider wants a different trick.

I am totally with you on CALLERPRES function being the simplest way to implement this. In my opinion the dialplan should be as simple as setting CALLERPRES and chan_sip should handle the rest. This would mean some additional parameters like 'usepassertedid' and 'trustpassertedid' which would solve the vanishing headers issue.

This goes to the heart of my statements about the SIP standard being something loosely defined as a standard. The RFC should have specifically defined EXACTLY how to do callerid blocking just like the PRI standards define such a behavior. I fear that until the SIP community that creates the RFCs are put under the same requirements that those who wrote NATIONAL-2 for PRI's are held to; this disparity would continue.

in the short term I would use those vertical service codes (like *67) to block it on a per-call basis.

BTW I wouldnt worry about CALLERID(name) ... it doesnt go anywhere. Once a call arrives on the PSTN only the number is delivered... just before the call reaches the recipient a CNAM database lookup is made on the number and that name is what is presented to the callee, regardless of what you set it to.

Erik Smith
Thirdlane/Asterisk Support available

amagurie's picture
Joined: 2008/04/02
Points: 0

Thanks for the reply Erik, talk about a mess, we had similar issues with call forwarding while maintaining A party Caller-Id.

I have found another way to get it set in TL for the extension; add 'callingpres=prohib_passed_screen' to the 'Other options' field. This way it can change it via the vertical service codes if needed.