[Home]

Summary:ASTERISK-25373: add documentation for CALLERID(pres) and also the CONNECTEDLINE and REDIRECTING variants
Reporter:Walter Doekes (wdoekes)Labels:
Date Opened:2015-09-04 03:07:39Date Closed:2015-11-10 10:06:41.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Documentation Functions/func_callerid
Versions:11.19.0 11.20.0 13.5.0 13.6.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If you use:
{noformat}
Set(CALLERPRES()=allowed_passed_screen)
{noformat}

You get a deprecationwarning:
{noformat}
       if (!callerpres_deprecate_notify) {
               callerpres_deprecate_notify = 1;
               ast_log(LOG_WARNING, "CALLERPRES is deprecated."
                       "  Use CALLERID(name-pres) or CALLERID(num-pres) instead.\n");
       }
{noformat}

Right now it does this:
{noformat}
               chan->caller.id.name.presentation = pres;
               chan->caller.id.number.presentation = pres;
{noformat}

Which in dialplan terms would be:
{noformat}
Set(CALLERID(name-pres)=allowed_passed_screen)
Set(CALLERID(num-pres)=allowed_passed_screen)
{noformat}

And you need to set both, because chan_sip reads it as a single value -- through {{ast_party_id_presentation()}} -- where value with the most privacy wins.

So, I don't consider two dialplan statements an improvement over one.

Suggested fix: add a 'all-pres' item to CALLERID.
{noformat}
Set(CALLERID(all-pres)=allowed_passed_screen)
{noformat}

Preferably in the release branches so one can get rid of deprecationwarnings sooner.

Thanks :)
Comments:By: Asterisk Team (asteriskteam) 2015-09-04 03:07:40.744-0500

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.

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].

By: Rusty Newton (rnewton) 2015-09-04 18:28:30.848-0500

I know you really want to provide a patch! :) Don't you?

By: Walter Doekes (wdoekes) 2015-09-06 05:16:57.776-0500

So, I started one. But then I found out the functionality exists, but is intentionally undocumented:

{noformat}
commit ec37ffbdaf4c8e9c134efd4e1fe7fd8bd72632ed
Author: Richard Mudgett <rmudgett@digium.com>
Date:   Wed Jul 14 15:48:36 2010 +0000

   ast_callerid restructuring
...
{noformat}
{noformat}
   * CALLERPRES() is now deprecated because the name and number have their
   own presentation values.
...
+/*
+ * Do not document the CALLERID(pres) datatype.
+ * The name and number now have their own presentation value.  The pres
+ * option will simply live on as a historical relic with as best
+ * as can be managed backward compatible meaning.
...
+ * Do not document the CONNECTEDLINE(pres) datatype.
...
+ * Do not document the REDIRECTING(pres) datatype.
{noformat}

I do mind the need for duplicate code. In SIP it's rare to hide only the display-name or only the user-addr. We either hide the whole caller or we don't. (At least for the CALLERID(pres) bit, I haven't had use for CONNECTEDLINE/REDIRECTING presentation yet.)

[~rmudgett]: can we get documentation that CALLERID(pres) gets/sets both name and num presentation?

Currently you would end up with something like this:

{noformat}
[incoming]
Set(is_public=$["${CALLERID(name-pres):0:7}"="allowed"]) ; either name-pres or num-pres will work if the call comes in on chan_sip
;; do stuff

[outgoing]
Set(CALLERID(name-pres)=${IF(${is_public}?allowed_passed_screen:prohib_passed_screen)})
Set(CALLERID(num-pres)=${IF(${is_public}?allowed_passed_screen:prohib_passed_screen)})
;; dial out
{noformat}

Failing to set one of them on the outgoing end will mess up (at least) the chan_sip presentation.

By: Richard Mudgett (rmudgett) 2015-09-08 18:05:09.481-0500

There is no problem using CALLERID(pres) to set the name and number presentation.  However, if you use CALLERID(pres) to read the setting then Asterisk *has* to generate a combined presentation value from the name and number presentations.  The CALLERID(pres) option was made undocumented when the name and number presentations became independent precicely because Asterisk may have to *lie* to generate the combined read value.

By: Walter Doekes (wdoekes) 2015-09-09 02:35:34.960-0500

Thanks for your answer Richard.

{quote}
Asterisk may have to lie to generate the combined read value.
{quote}

I understand that. But asterisk internals -- when I'm writing a dialplan, I consider the chan_sip module an internal -- is using that *lie* as well. It makes sense to use the same lying interface for both the internals and the dialplan.

Would it make sense to create a {{CALLERID(combined-pres)}} alias to the current {{CALLERID(pres)}}, with clear documentation that explains that it may silently drop information.

What do you suggest?

By: Richard Mudgett (rmudgett) 2015-09-09 11:04:41.919-0500

There is no need to add an alias for something that already exists and in fact existed before the name and number presentation split.  It would make more sense to just add the documentation for the CALLERID(pres) and also the CONNECTEDLINE and REDIRECTING variants with the behavior for read and write explained.

The name and number presentation split was a result of some messaging in ISDN that could conceivably result in differing presentation values for the name and number.  For historical reasons inside Asterisk and because SIP doesn't have any distinction between name and number presentation a combined name and number presentation value was needed.

[~rnewton] This is now just a documentation issue.