Summary: | ASTERISK-07053: Possible callingpres logic problem | ||
Reporter: | Manuel Wenger (manuel_wenger) | Labels: | |
Date Opened: | 2006-05-30 03:23:27 | Date Closed: | 2006-06-06 15:56:44 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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. |