Parsing of privacy header by Asterisk

Development
1

Hello everyone,

My company operates a FreePBX system running ~500 endpoints, and have been having issues with calls forwarded externally of the system being anonymized.

Our SIP trunk provider sends privacy headers for calls not requesting anonymity in this format:

Privacy: off

I understand that this is not a token value recognized under RFC 3323, and assume off is a being used as a synonym for none, but the industry has adopted this value widely enough that it now needs to be accounted for.

I found that in the res_pjsip.c file, at line 2728 in Asterisk 22.4, this logic statement is provided:

res_pjsip_before
res_pjsip_before611×420 71.9 KB

It appears that this only provides the ability to parse single-token values in the privacy, and sets calls to prohibited (Anonymous) if the value does not match “none”.

To test my theory, I included “off” as a value to match:

if (!privacy || !pj_stricmp2(&privacy->hvalue, "none") || !pj_stricmp2(&privacy->hvalue, "off")) {

I compiled with this modification on a test system, and the issue seems to be fixed.

I am not well-versed in C or the Asterisk codebase, so I would like input on whether this is the appropriate way to fix this behavior.

If this is in fact the section that handles the privacy header, it would be great if it could also handle multiple values, as described in RFC 3323. Being able to parse values separated by semicolons and spaces, as well as leading and/or trailing spaces. Being able to handle commas is a requirement for some other systems not fully compliant with RFC 3323.

The code should follow this logic statement:

“Privacy header values that include tokens other than “off” and “none” should be anonymized.”

This logical statement is given due to the non-granular privacy of the original code. Further RFC compliance may be a bit more challenging. In my opinion, an “on and off” approach to privacy is still acceptable until further provisions are made. Being able to parse the values is my main goal in bringing this up.

To further clarify, here’s some examples of multiple-value Privacy headers and how I interpret they should be handled:

• Privacy: off;none (Behavior should be to present user details normally, log RFC violation)

• Privacy: off , none (Behavior should be to present user details normally, log RFC violation)

• Privacy: none; none,off (Behavior should be to present user details normally, log RFC violation)

• Privacy: id ;off (Reject with 400 Bad Request, log RFC violation)

• Privacy: session;header (Anonymize the call accordingly)

• Privacy: header;session;id;user (Anonymize the call accordingly)

Even if some of these input values are sent in a strange way due to the configuration of other provider’s systems, Asterisk should be capable of fully interpreting header contents. I can tell you from experience, people don’t like when all their incoming calls are being anonymized! :sweat_smile:

Thanks in advance.

2

That is the location yes and the change that would be needed. To actually have changes included, though, they need to go up on Github with a contributor license agreement signed.

3

This interpretation has to be a protocol violation. Whilst it is, itself, a protocol violation to include anything else with “none”, it seems very clear to me that none value overrides everything else and requires that all privacy measures be disabled.

Also, I note that handling “critical” is mandatory. I’d therefore say that, if critical is found, combined with anything undefined, including “off”, the request should be rejected with a server error. One would need a careful analysis of known options to make sure that compliance was complete. “critical” combined with “none” should, I think, also be faulted, as it is even more explicitly a protocol violation, and leaves one in doubt as to what was intended, in a context where the options are supposed not to leave any doubt.

Actually, I’d suggest that any request with “critical” should also be faulted for any punctuation error.

4

True, in RFC 3323 Section 4.2, it specifies in the definition of “none” that no additional tokens should be specified. Thank you for pointing that out, and I have corrected the examples to reflect.
I also changed the 4th example, as it may be better to reject calls making a self-conflicting privacy request.