[Feb 11 10:10:11] DEBUG netsock2.c: Splitting ‘1x.2x.3x.4x’ into…
[Feb 11 10:10:11] DEBUG netsock2.c: …host ‘1x.2x.3x.4x’ and port ‘’.
In the messages file we can see the messages in a tcpdump style, but no other info what led to the 416 reply. If Asterisk replies with an error code to the INVITE message, one could expect a little more details in the log files. Or are we missing something here?
What would be the fastest solution to fix this issue? Using a sip proxy?
It’s not that common. It’s technically both Asterisk and PJSIP that handle it, but Asterisk doesn’t have the support for it. There is no debugging really required - they’re just not supported in chan_pjsip.
You described on the other thread why it’s complicated to fix this issue. Just to make sure I understood: It’s not just an Asterisk issue, it’s rather an issue within “upstream” PJSIP. Right? So their claim of supporting RFC3966 is misleading?
Switching to chan_sip should do the trick? Or is it the same problem?
And one more thought about the logging issue: Actually I do think that this should show up in the logs. Not for debugging purposes, but just to see that there a calls that have been turned down.
It’s an Asterisk issue. Asterisk uses the URIs, and because of that it has to be aware so it can treat them differently. As this isn’t done requests with tel URI are blocked. The chan_sip may or may not work with tel URIs, it may throw warnings or errors. Requests don’t show up in logs for this, they’d only show up in a SIP trace.
I totally agree, if that tel URI schema isn’t used a lot, then it’s probably not worth screwing up Asterisk for that.
But still I’d appreciate if the logging would be extended. Usually you don’t trace the SIP messages, as far as I know for performance reasons. But then there is no other way of telling that incoming calls have been rejected, since they don’t make it into the call logs either. Rejected calls seem to me worth noting.
NOTICE[C-00000016]: chan_sip.c:19304 check_user_full: From address missing 'sip:', using it anyway
ERROR[C-00000016]: chan_sip.c:19314 check_user_full: Empty domain name in FROM header
NOTICE[C-00000016]: chan_sip.c:26314 handle_request_invite: Failed to authenticate device <tel:0987654321;noa=national;srvattri=national>;tag=srcrey77
The first two messages look like reasonable reactions to tel:.
You should look to see if the authentication is simply failing before blaming this on tel:
Note that cert versions should be avoided by open source users. In particular, they do not load chan_sip, because it is not included in Sangoma support contracts. Also Asterisk 13 is no longer fully maintained.
I’ve just made a patch for chan_sip.c, which allows Incoming calls with tel: schema , and without domain in " From" header.
After patching the source code, the call accepted and answered.
The patch is for asterisk-certified-13.18-cert2, but its not a problem to make the patch for other asterisk versions.
Unfortunately, Chan_SIP is deprecated, in extended support and is community driven. In order for this to be even close to being considered it will need to be submitted like any other patch and doing that in the issue tracker isn’t the right place.
At this time Chan_SIP is in the final countdown to where it can be removed from Asterisk (two years left). If you’re really going to add TEL support do it for Chan_PJSIP as that is the active and supported SIP driver in Asterisk.