[Home]

Summary:ASTERISK-07053: Possible callingpres logic problem
Reporter:Manuel Wenger (manuel_wenger)Labels:
Date Opened:2006-05-30 03:23:27Date Closed:2006-06-06 15:56:44
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description: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:

p->callingpres = user->callingpres;
and
p->callingpres = peer->callingpres;

These somehow don't make sense to me. I'm not sure this is a bug, but please bear with me.

Earlier in check_user_full, the following call is made:

p->callingpres = get_rpid_num(rpid,rpid_num, sizeof(rpid_num));


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 (still SIP) 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 SIP 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 callingpres value.

In fact, for our system to work, I had to comment out these 2 lines. Otherwise we only had 2 choices:
1. 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.
2. 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.
Comments:By: Olle Johansson (oej) 2006-06-01 13:38:01

Hmm, I think we should set the defaults from user/peer first, then override by rpid. Would that work?
By: Olle Johansson (oej) 2006-06-05 01:23:52

The way I fixed it is that user/peer setting will override RPID header only if it is set to a value.

Change committed to svn trunk 32183.
By: Olle Johansson (oej) 2006-06-06 15:56:30

Norsk reply. I will assume I fixed it.