Handling of tel URIs

Asterisk Asterisk SIP
1

Hello,

we’re using Debian’s Asterisk package with PJSIP (16.2.1~dfsg-1+deb10u2).

Lately we receive some INVITE messages from the ITSP containing tel URIs in the TO header. Asterisk replies with “416 Unsupported URI Scheme”.

  1. Using tel URIs seems to be okay in terms of the RFC. But is it really common? Do many ITSPs make use of that?

  2. Who is in charge of handling those URIs? Is it Asterisk itself or is it really PJSIP? They claim to be RFC3966 compliant.

  3. We’d like to debug this issue but we’re not really able to understand the logging mechanism. We followed the intructions given under Collecting Debug Information - Asterisk Project - Asterisk Project Wiki but even setting “core set debug 9” doesn’t give us more than those two entries in the debug log file:

[Feb 11 10:10:11] DEBUG[19504] netsock2.c: Splitting ‘1x.2x.3x.4x’ into…
[Feb 11 10:10:11] DEBUG[19504] 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?

  1. What would be the fastest solution to fix this issue? Using a sip proxy?

Thanks in advance!

2

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.

3

This was discussed recently:

1 Like
4

Thanks for your hint. In fact, it’s the same ITSP we’re having this issue with. This came up, when they changed some of their hardware a couple weeks ago. They might fix it.

5

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.

6

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.

7

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.

Thanks to both of you for your quick help.

8

Asterisk 13 can handle such calls using chan_sip channel driver.

From: <tel:0701XXXXXX;phone-context=+40>;tag=xgjix183-CC-147
To: sip:+40213XXXXXX@as1.romtelecom.net;user=phone

At the time of installation, it was the only version that had support for tel:URI. The version used was asterisk-certified-13.18-cert2.

You can download this version from:
https://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/asterisk-certified-13.18-cert2.tar.gz

9

Hi
Even asterisk asterisk-certified-13.18-cert2. did not help to accept incoming call from Huawei SoftX3000 PBX.

The invite was:

<--- SIP read from UDP:192.168.11.2:5060 --->
INVITE sip:+123456789@myid.telecom.au SIP/2.0
Via: SIP/2.0/UDP 192.168.11.2:5060;branch=z9hG4bKk013kj2osqkfpihfgsoo32kfq;Role=3;Hpt=8e82_36;TRC=ffffffff-ffffffff
Call-ID: asbcaydtt7a4fa4mdqcdef2qqq7q87yrqddf@192.168.11.2
From: <tel:0987654321;noa=national;srvattri=national>;tag=srcrey77
To: <sip:+123456789@192.168.11.2;user=phone>
CSeq: 1 INVITE
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Contact: <sip:192.168.11.2:5060;Dsp=ecba-200;Hpt=nw_5d_60461155_c24ec_ex_8e82_16;CxtId=4;TRC=ffffffff-ffffffff>
Max-Forwards: 61
Supported: timer,100rel
User-Agent: Huawei SoftX3000 V600R013
Session-Expires: 1800;refresher=uac
Min-SE: 600
P-Asserted-Identity: <sip:0987654321@192.168.11.2;user=phone>
Privacy: none

Asterisk logs was:

NOTICE[30382][C-00000016]: chan_sip.c:19304 check_user_full: From address missing 'sip:', using it anyway
ERROR[30382][C-00000016]: chan_sip.c:19314 check_user_full: Empty domain name in FROM header
NOTICE[30382][C-00000016]: chan_sip.c:26314 handle_request_invite: Failed to authenticate device <tel:0987654321;noa=national;srvattri=national>;tag=srcrey77
11

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.

12

Hi David.
Yes, of cause I’ve looked into authentication before blaming on tel:
its all about implementation of RFC-3966, which were never completed in asterisk untill now,

https://raw.githubusercontent.com/asterisk/asterisk/master/channels/chan_sip.c ,
‘Empty domain name in FROM header’ message appears always when “From:” header it not a valid URI , and you need to authenticate the peer by a username or IP ( not depending from the schema)

Need some patch to get it working.

13

Hello everyone!
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.

14

For patches to be included in the official versions of Asterisk, they need to be submitted through issues.asterisk.org, so that they have the appropriate copyright releases.

15

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.

16

Even if you use the gerrit route, you still have to sign the Contributor Agreement, and that is done through the issue tracker.

17

Thank you for all the information! will keep in mind!

18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.