[Home]

Summary:ASTERISK-29176: Private REDIRECTING party ID data not used in PJSIP headers
Reporter:Kris Shaw (shawkris)Labels:patch
Date Opened:2020-11-23 11:48:04.000-0600Date Closed:
Priority:MinorRegression?No
Status:Open/NewComponents:Channels/chan_pjsip
Versions:16.15.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) diversion-sip-trace.txt
( 1) priv-div_trust.diff
( 2) priv-div.diff
( 3) priv-div-hist.diff
Description:Unlike in chan_sip (and sig_pri), chan_pjsip does not take into account the priv* representations of the orig/from/to redirecting party IDs. When constructing the diversion and history headers via res_pjsip_diversion, the priv* values aren't merged with the standard party IDs to get the effective party IDs.
Therefore, these headers may not be set as you might expect them to be from the documentation.
Comments:By: Asterisk Team (asteriskteam) 2020-11-23 11:48:04.749-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
By: Kevin Harwell (kharwell) 2020-11-24 10:18:05.655-0600

Could you explain more about what's given vs expected? Please include an example of what it's currently doing vs. what it should be doing.

Also please attach the dialplan and/or configuration used.

Thanks!
By: Kris Shaw (shawkris) 2020-11-24 16:58:19.074-0600

In my test setup, extensions 1000 and 1001 are defined as PJSIP endpoints with:

{code}send_diversion = yes
send_history_info = yes{code}

The following dialplan is used to setup basic redirecting data

{code}exten = 1002,1,Verbose(0,Test extension)
same => n,Set(REDIRECTING(from-num,i)=1234)
same => n,Set(REDIRECTING(priv-from-num,i)=4567)
same => n,Set(REDIRECTING(reason,i)=cfu)
same => n,Set(REDIRECTING(count,i)=1)
same => n,Dial(PJSIP/1001)
same => n,Hangup{code}

The expected result is that the diversion/history headers sent to 1001 should contain 4567 when 1000 dials 1002, but instead they contain 1234.
By: Kevin Harwell (kharwell) 2020-11-30 12:39:35.977-0600

Yeah looks like just the from number info is checked and used:
{noformat}
if (from->number.valid && !ast_strlen_zero(from->number.str)) {
pj_strdup2(tdata->pool, &name_addr->display, from->name.str);
pj_strdup2(tdata->pool, &uri->user, from->number.str);
}
{noformat}
I think the fix should check if there is valid private info available then use it--, but only if {{trust_id_outbound}} has been set to "yes" too--. *edit*: see below, but might not need to check this option
By: Kris Shaw (shawkris) 2020-11-30 18:51:16.352-0600

That might suggest there's another related bug then. If the {{trust_id_outbound}} parameter is going to be honoured then presumably the presentation values need to be checked too. If they are set to {{prohib}} or {{unavailable}} then the related REDIRECTING values shouldn't be in the header anyway (unless {{trust_id_outbound}} is set)? I've interpreted Private REDIRECTING values to just mean they relate only to that particular channel/caller, instead of meaning some presentation value. That appears to be the case with other channel drivers and when used for CONNECTEDLINE.
By: Kevin Harwell (kharwell) 2020-12-01 09:10:45.759-0600

[~shawkris] Good points. In this case there may be no need to check the {{trust_id_outbound}} parameter.
By: Kris Shaw (shawkris) 2021-10-24 12:41:31.990-0500

I think the attached patch will fix the problem, although it doesn't address honouring the {{trust_id_outbound}} setting which is probably separate issue to fix.
By: Kris Shaw (shawkris) 2021-10-25 05:24:17.771-0500

This patch is an attempt to implement the {{trust_id_outbound}} functionality and add the privacy value to the Diversion header (full or off). If the approach is correct then I guess History-Info would need to be fixed too.
By: Kris Shaw (shawkris) 2021-10-27 04:17:25.688-0500

As a proof of concept, this fixes the redirecting data for History-Info. However, when trying to indicate History-Info privacy I found 2 issues.

1. When adding privacy to the History-Item header field, PJSIP doesn't seem to allow header_param values to be added.
2. Adding the Privacy header to the message probably needs to be done in conjunction with the existing function in res_pjsip_caller_id.c (which adds value "id"). The value "history" needs to be added to any existing value.