The following problem in the PBX I have noticed and it is the res_pjsip which outputs a error in the case of incoming calls with the following configuration
Support for tel: URIs isn’t a requirement for a conforming SIP implementation and PJSIP doesn’t support them.
Also, I’d want to see the incoming request,as I suspect that rejection only happens for bad request IDs, in which case the provider would be broken, as they would not be returning the contact URI as provided.
Also, if you have provided a single response from Asterisk, the Server line indicates that you have overridden the user agent name in a strange way. If not, then the source of the logging is unclear.
You should mark all logs and configurations as pre-formatted text, one benefit of which is that the forum won’t mark up URIs, so won’t count them towards the limit of URIs in a newbie post.
which means that any URI that doesn’t contain an “@” must be the domain part, containing either a domain name or an IP address literal. I’m not sure how chan_sip would cope with this. I can only suspect that it was treating it as a hostport, but not checking that it was a possible one, and sending it to extension “s”.
Normally, if registration is involved, the request URI should match the client ID in your configuration.
If my assumption that local_id looks like a phone number is wrong, your redaction has destroyed relevant information.
If the request line is of this format, then Asterisk is at fault, as 416 only applies to request URIs, not to To or From headers, and the request URI scheme is valid. Also, the syntax for To and From headers allows any absolute URI, and a tel: URI seems to meet that definition, even though you can’t expect it to do anything with it, especially as Asterisk is a back to back user agent, so can’t simply pass unrecognised input through.
The chan_pjsip module doesn’t support tel URIs anywhere, including To and From. 416 was the best response code we found, if I recall, to send back even though the request URI wasn’t the source of the issue.
I would suggest 403, because it is a policy decision to refuse a well formed request, with Error-Info, because 403 will result in lots of “why did I get this?” questions.
The specification doesn’t allow general URIs on REGISTER, so we are basically talking about INVITE, where the only actually required behaviour is to reflect the value received, opaquely, in future responses and requests.
I think even with an Error-Info people would still gloss over it and think they had an authentication issue and go down that path.
The reason currently why tel URIs aren’t supported in PJSIP is that it requires a full audit of everything and everywhere. This is because URIs in PJSIP aren’t opaque, and are used - for example for caller id, for determining endpoint. You have to write things explicitly with a “if this is SIP or SIPs do this, if this is Tel do this”. Noone has done that as of yet. If you don’t do it properly or miss, then a tel URI can crash Asterisk.
I just looked at my pjsip.conf again and had to find out that I had commented out the realm the whole time because of the error message.
I set the realm in the trunk auth to sip: sip.alice-voip.de and now I get the following error message
[Jan 29 17:48:47] WARNING[2936]: res_pjsip_outbound_authenticator_digest.c:178 digest_create_request_with_auth: Host: '62.52.28.195:5060': Unable to create request with auth. No auth credentials for realm(s) 'ims.telefonica.de' in challenge.
[Jan 29 17:48:47] WARNING[2936]: res_pjsip_outbound_registration.c:933 handle_registration_response: Failed to create authenticated REGISTER request to server 'sip:sip.alice-voip.de' from client 'sip:sip_id@sip.alice-voip.de'
[Jan 29 17:48:47] WARNING[2936]: res_pjsip_outbound_registration.c:1006 handle_registration_response: Fatal response '401' received from 'sip:sip.alice-voip.de' on registration attempt to 'sip:sip_id@sip.alice-voip.de', stopping outbound registration