I have recently been looking at the function “check_user_full” in chan_sip.c (running the tarball Asterisk 1.2.7.1). In that function, 2 lines got my attention:
and
These somehow don’t make sense to me. I didn’t want to file a bug because possibly I will be wrong, but please bear with me.
Earlier in check_user_full, the following call is made:
Basically, this way p->callingpres will contain AST_PRES_PROHIB_USER_NUMBER_NOT_SCREENED if the RPID contains “privacy=full” or “privacy=uri”, therefore telling the new call leg that it will have to hide the caller ID, as per the caller’s wish.
But if we “reset” p->callingpres by issuing one of the first 2 statements quoted above, this information will be lost, as it will be overwritten by the third statement I quoted, and basically be useless. p->callingpres will contain whatever value is specific by the called peer or user.
The side-effect of this is that if a call is coming in from a peer/user where “trustrpid” is set to “yes”, the number coming in through the RPID will always be shown to the callee, regardless of the “privacy=uri” flag in the caller’s INVITE message. Which IMHO is wrong. The following code in the “initreqprep” function should hide it:
if (!ast_test_flag(p, SIP_SENDRPID) && ((p->callingpres & AST_PRES_RESTRICTION) != AST_PRES_ALLOWED)) {
l = CALLERID_UNKNOWN;
n = l;
} But it doesn’t, because p->callingpres has been previously overwritten with the peer’s/user’s value.
In fact, for our system to work, I had to comment out these 2 lines. Otherwise we only had 2 choices:
- set “trustrpid=yes” on our SIP-to-PSTN provider’s peer. This would mean that all Caller IDs would be visible to our end users, which is not desirable.
- set “trustrpid=no” on our SIP-to-PSTN provider’s peer. This would hide all restricted Caller IDs - even from our CDRs! Which is not desirable either.
Did I miss something or do I have a point? Oh, by the way, this was behaving differently in Asterisk 1.0.x …
Thank you for reading
-Manuel