[Home]

Summary:ASTERISK-16538: Unavailable presentation number status is ignored if sendrpid is true (chan_sip)
Reporter:David Woolley (davidw)Labels:
Date Opened:2010-08-10 12:24:15Date Closed:2012-01-06 17:20:01.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If you set CALLERPRES() to Unavailable (done from the dialplan) and sendrpid to no (sip.conf), Asterisk sends a From header with the both name and number set to Unknown.

If you set sendrpid to yes, Asterisk sends the original number, with no Remote-Party-Id header

It should, at least, send Unknown in the From header, in the second case.  (It would do if a screening state other than 0 (not screened) were included with the the unavailable restriction state.)


****** ADDITIONAL INFORMATION ******

This was noted on 1.6.1.0, but 1.6.2 SVN shows unchanged code for the sendrpid=yes case, and only changes that don't affect the core of the issues, for sendrpid=no.  The following extracts apply to 1.6.2 SVN:

With sendrpid set to yes, the following code is executed, if CALLERPRES is exactly the Unavailable value:

 10736         case AST_PRES_NUMBER_NOT_AVAILABLE:
 10737                 send_pres_tags = FALSE;
 10738                 break;


 10752         if (send_pres_tags)
 10753                 snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), "
 10753 ;privacy=%s;screen=%s", privacy, screen);
 10754         ast_string_field_set(p, rpid, buf);
 10755
 10756         ast_string_field_build(p, rpid_from, "\"%s\" <sip:%s@%s>;tag=%s"

this bypasses the default handling, which can set the privacy on for an unavailable restriction state:

 10739         default:
 10740                 ast_log(LOG_WARNING, "Unsupported callingpres (%d)\n", p
 10740 ->callingpres);
 10741                 if ((p->callingpres & AST_PRES_RESTRICTION) != AST_PRES_
 10741 ALLOWED)
 10742                         privacy = "full";
 10743                 else
 10744                         privacy = "off";
 10745                 screen = "no";
 10746                 break;
 10747         }

If sendrpid is off, the following code is used, which is what sets Unknown:

 10803         if (!ast_test_flag(&p->flags[0], SIP_SENDRPID) &&
 10804             ((p->callingpres & AST_PRES_RESTRICTION) != AST_PRES_ALLOWED
 10804 )) {
 10805                 l = CALLERID_UNKNOWN;
 10806                 n = l;
 10807                 d = FROMDOMAIN_INVALID;
 10808         }

The draft RFC that seems to apply is <http://tools.ietf.org/html/draft-ietf-sip-privacy-04>.  On a quick skim, I think there are some other violations, but I'm really just addressing the obvious inconsistency in the level of privacy.

The draft RFC does permit sending the clear ID downstream, but only to a trusted proxy and only with a Proxy-Require header set, and, presumably, with a Remote-Party-ID to carry the privacy=full.  Asterisk does not contain "Proxy-Require".

As background we have an issue where leaking an IP address is unacceptable, but this is what happens if there is no user part in the incoming From address, which is what happens for an unavailable status reported through a Cisco gateway.  We can work round this by explicitly manipulating caller IDs, and we will probably do so rather than making Remote-Party-ID well behaved, given that SIP doesn't really have a way of signalling unavailable downstream.

Note that I don't believe that anything forces privacy and screening values to take the the special combination, when received from ISDN.  Maybe the ISDN standards do.

The essential difference in the sendrpid = no case, between 1.6.1.0 and 1.6.2 is the addition of this line:

 10807                 d = FROMDOMAIN_INVALID;

which also needs to be applied to the sendrpid=yes case.

The essential difference in the sendrpid = no case, between 1.6.1.0 and 1.6.2 is the addition of this line:

 10807                 d = FROMDOMAIN_INVALID;

which also needs to be applied to the sendrpid=yes case.
Comments:By: David Woolley (davidw) 2010-08-10 12:26:10

Ouch!  Got true and false mixed in the summary!
By: Leif Madsen (lmadsen) 2010-08-11 12:27:53

Summary fixed. Acknowledging issue. Thanks!
By: John Todd (jtodd) 2010-08-12 15:00:57

Looks like a good catch.  Out of curiosity, would you be interested in having SVN access to fix minor things like this after you put your patch up on reviewboard?  It seems you've found a number of issues, and are able to fix things yourself.
By: David Woolley (davidw) 2010-08-19 05:28:50

I might be interested in SVN access, but:

1) although I've seen reviewboard being used, I've never seen documentation for the change control process - could you point me to it;

2) we are using Asterisk is a fairly constrained environment.  This means that sometimes the best approach for us is to avoid a problem area, once it is characterised.  I think this may be the case for this one.

3) although we try to minimise patches, we've added functionality and made changes, and have frozen out the Asterisk version.  There is a limit to the amount of time that I can prioritise to adapt changes to supported versions (and separate new features from fixes).