We cannot call a certain telephone number.
Our SIP-Provider said, the reason is the paramter “Privacy: off” in our SIP signalling, which is not supported by the SIP provider.
Therefor the call is blocked at provider site.
So I should remove this parameter completely.
But I don’t know, what to configure to remove this paramter.
In Advanced Settings > Device settings we have:
SIP trustrpid yes
SIP sendrpid pai
if this has anything to with the issue.
Below, there is a complete dump of a connection init.
regards
Daniel
I suspect that is not why it is failing. They don’t seem to have rejected the call, but rather have not responded. If they find a header unacceptable, they must reject the call, not ignore it.
However, a quick check of the RFCs suggests that “off” should be “none”, and it looks like you have a chan_sip style call-id. If so, it is possible there is a bug in chan_sip, but as that is deprecated, so it won’t get fixed; you should move to chan_pjsip.
PS tags aren’t sensitive and they can be important for debugging. Same for branch, although it is unlikely to be important. Also, you should obfuscate different values differently. I wanted to ask whether certain values were your public address, but everything is xxx, even things that are not addresses.
You should be able to leave your chan_sip trunk alone and create a new outbound-only pjsip trunk. System should operate as before. Set up an Outbound Route using a prefix that routes to the new trunk. Make test calls with that prefix and observe behavior. By default, pjsip does not send Privacy headers.
The whole process should take only a few minutes. If you have trouble, paste a log using the pjsip trunk.
Looking at the leading edge source code, it never send Privacy: off, only ever Privacy:id, and it only sends that if you set sendrpid=pai, which you seem to have done.
Because the source file is so large, it is a little fiddly to look at multiple versions, to see if it did send Privacy: off in earlier versions, but I’d suggest this may have been fixed or else it is the FreePBX code (seems unlikely to me) or your custom code, that is setting it.
At a guess sendrpid=yes or no may stop it in older versions of chan_sip, if that is the source. This might break outbound caller ID.
This is the only code in chan_sip that sends Privacy, and, as you can see, in the head version, it only sends Privacy: id.
if (ast_test_flag(&p->flags[0], SIP_SENDRPID_PAI)) {
if (ast_test_flag(&p->flags[1], SIP_PAGE2_TRUST_ID_OUTBOUND) != SIP_PAGE2_TRUST_ID_OUTBOUND_LEGACY) {
/* trust_id_outbound = yes - Always give full information even if it's private, but append a privacy header
* When private data is included */
ast_str_set(&tmp, -1, "\"%s\" <sip:%s@%s>", lid_name_buf, lid_num, fromdomain);
if ((lid_pres & AST_PRES_RESTRICTION) != AST_PRES_ALLOWED) {
add_header(req, "Privacy", "id");
}
} else {
Thank you David for code inspection.
Meanwhile I found our mistake - We have set this parameter by ourselves.
In 2016, when migrating from old SIP provider to another we wanted to use Clip no Screening until our number is ported.
In this macro we inserted a PAI with the Network provided Number for authentication at the SIP trunk.
And in this macro we also set “Privacy:off”. We don’t no why anymore. Probably a C&P mistake.
And we have not deleted this macro after porting of our number, because it worked - until 2022.
Changing this parameter to “Privacy:none” or deleting this parameter solved the problem.
Sorry for causing problems with self written maco and again thank you for investigating.
Stewart,
you have been right. I set up an outbound channel with chan_pjsip. This is working and have been quite easy.
May I ask one (off topic) question for this.
With adding chan_pjsip Extension Menu was changing.
Now we have a tab with Extensions chan_sip (with all our extensions).
And one empty tab with Extensions for chan_pjsip.
Do we have to migrate the extensions when we want to migrate to chan_pjsip completley?