[Home]

Summary:ASTERISK-17179: [patch] IMS TEL URI incoming INVITE RFC 3966 not recognized
Reporter:Geert Van Pamel (geertivp)Labels:INVITE PATCH RFC3966 RFC5341 SIP TEL URI
Date Opened:2010-12-29 04:50:56.000-0600Date Closed:2022-08-31 06:22:17
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:11.5.1 12.0.0 Frequency of
Occurrence
Related
Issues:
is a clone ofASTERISK-25414 CLONE - [patch] IMS TEL URI incoming INVITE RFC 3966 not recognized
is related toASTERISK-28345 IMS TEL URI incoming INVITE RFC 3966 not recognized
Environment:All platformsAttachments:( 0) asterisk_10.1.3_chan_sip_diff.txt
( 1) asterisk_10.1.3_reqresp_parser_diff.txt
( 2) asterisk-1.6.2.7-sip_chan.dif
( 3) asterisk-1.8.13.1-chan_sip-diff.txt
( 4) asterisk-1.8.13.1-reqresp_parser-diff.txt
( 5) asterisk-11.5.1-chan_sip-diff.txt
( 6) asterisk-11.5.1-reqresp_parser-diff.txt
( 7) asterisk-12.0.0-chan_sip-RFC3966_patch.txt
( 8) asterisk-12.0.0-reqresp_parser-RFC3966_patch.txt
( 9) chan_sip-asterisk_1.6.2.9-2ubuntu2.1-diff.txt
(10) chan_sip-asterisk-1.6.2.9.txt
(11) chan_sip-diff.txt
Description:This problem exists in ALL versions of Asterisk.

Asterisk seems *not* to support RFC 3966 TEL URI for INCOMING INVITEs. X-Lite and other clients like Bria are compliant with RFC 3966.

When an IMS server sends an incoming TEL URI INVITE I get the following errors, and the incoming call is disconnected (number busy).

Here you find part of an (incoming) INVITE request and sip debug output:

From: <*tel:0987654321;phone-context=+32987654321*>;tag=tag-etc
CSeq: 1 INVITE
P-Asserted-Identity: <tel:0987654321>
P-Called-Party-ID: <sip:+3212345678@...>
Diversion: <sip:+3212345678@...;user=phone>;reason="extension";privacy="off";counter=1

Using INVITE request as basis request -
Nov 13 17:52:05 NOTICE[27459]: chan_sip.c:6973 check_user_full: *From address missing 'sip:', using it anyway*

Nov 13 17:52:05 WARNING[27459]: chan_sip.c:6525 get_destination: Huh? Not a SIP header (*tel:0987654321;phone-context=+32987654321*)?

RDNIS is +3212345678
SIP/2.0 404 Not Found

Actually I found out that Asterisk is indeed not conform to the RFC 3966 standard.

I have solved the problem by patching chan_sip.c and reqresp_parser.c -- see patch in code attachments.


I have changed the following functions:

* check_user_full
* get_destination
* parse_uri OR parse_uri_full (depending on the Asterisk version)

When ;phone-context= is provided in the incoming tel:uri then we can extract the calling number for further call handling.

Now IMS and Asterisk are talking to each other without problems.

More information:

http://forums.digium.com/viewtopic.php?f=1&t=76432&sid=6d53062361c22079757c53ccc73d3132
Comments:By: Geert Van Pamel (geertivp) 2010-12-30 04:43:08.000-0600

Asterisk should implement current VoIP standard protocols:

• RFC 2806 - URLs for Telephone Calls [2000 replaced by RFC 3966]
• RFC 3261 - SIP - Session Initiation Protocol [2002]
• RFC 3761 - E.164 number ("ENUM") translation
• RFC 3966 - The tel URI for Telephone Numbers (TEL URI INVITE) [2004 superseding RFC 2806]

By: Leif Madsen (lmadsen) 2011-01-04 16:05:04.000-0600

Asterisk should do a lot of things, but code has yet to be submitted to do it. Adding those RFCs constitute a feature request.

By: Geert Van Pamel (geertivp) 2011-02-19 10:25:35.000-0600

Who can prepare an RFC 3966 TEL URI INVITE "feature request" ?
Patch code is available in chan_sip-diff.txt attached file.
It works in my configuration, and I did not see any side effects.
I agree that this patch is only a strict minimum for TEL URI INVITE to work.
Much more code would be needed to fully implement RFC 3966 TEL URI INVITE.



By: Geert Van Pamel (geertivp) 2011-05-26 02:16:45

I have uploaded asterisk-1.6.2.7-sip_chan.dif which is a patch for sip_chan.c for Ubuntu Asterisk 1.6.2.7 for the earlier reported problem.

I originally detected the problem with Asterisk 1.6.1.

The TEL URI INVITE problem is still there. I did not see any final released solution. So I need to reapply my patch manually after each upgrade.

In Asterisk 1.6.2.7 there is one more instance of the same problem as related to 1.6.1.

[May 26 01:09:47] NOTICE[17493]: chan_sip.c:20067 handle_request_invite: Call from 'XXXXX' to extension '+3212345678' rejected because extension not found.

I hope that the TEL URI INVITE problem will be fixed in a future version of Asterisk! Please reinvestigate the impact on the different protocols.

By: Walter Doekes (wdoekes) 2011-05-26 02:33:18

geertivp: it looks your patches assume that there simply exists no domain-only uri. I believe that to be incorrect. Shouldn't you take the protocol (tel:) into account when assuming that the @-less user-addr is a user-part instead of a domain-part?

By: Geert Van Pamel (geertivp) 2011-05-26 06:00:35

Re: wdoekes: I agree that the full implementation of RFC 3966 TEL URI INVITE would involve much more code changes.

In one of my previous notes, I admitted that the code changes I report here are only a strict minimum for the TEL URI INVITE to work with my telco's provider implementation of the TEL URI INVITE prototol.

Much more code would be needed to fully implement RFC 3966 TEL URI INVITE.

By: Geert Van Pamel (geertivp) 2011-06-06 14:32:57.379-0500

Patch for RFC 2966 INVITE TEL URI for Asterisk 1.6.2.9

By: Geert Van Pamel (geertivp) 2011-07-30 10:35:52.746-0500

Patch for TEL URI RFC 3966 functionality in chan_sip.c for asterisk_1.6.2.9-2ubuntu2.1

Changed functions:

* parse_uri (1 section)
* get_destination (2 sections)
* check_user_full (2 sections)


By: Geert Van Pamel (geertivp) 2012-03-10 09:39:27.696-0600

Patch for *Asterisk 10.1.3* to implement incoming *TEL URI INVITE RFC 3966 functionality*

* Added "tel:" to the function *get_destination* in file channels/chan_sip.c; see attachment asterisk_10.1.3_chan_sip_diff.txt (1 code section)
* Added "tel:" to the function *check_user_full* in file channels/chan_sip.c; see attachment asterisk_10.1.3_chan_sip_diff.txt (2 code sections)
* Added "phone-context" to the function *parse_uri_full* in file channels/sip/reqresp_parser.c; see attachment asterisk_10.1.3_reqresp_parser_diff.txt (1 code section)

With the extra else-if in module reqresp_parser, I implemented the remark above of Walter Doekes - 26/May/11 2:33 AM that I should handle the domain-less URI.

By: Matt Jordan (mjordan) 2012-03-12 08:46:59.241-0500

Geert:

I'm glad you pinged me - I had lost the card where I wrote down this issue number.  Thanks for reminding me about it!

To get this patch moving, the best next step would probably be to put it up on ReviewBoard so that more people can take a look at it and review it for inclusion.  This being a new feature, the patch would have to be written such that it merged with the current version of chan_sip in trunk (which shouldn't be too much different from the 10.1.3 version you have posted on this issue).

ReviewBoard is located here: https://reviewboard.asterisk.org/dashboard/

If you need an account, feel free to contact me at mjordan@digium.com and I'll set one up for you.

Thanks

Matt

By: Geert Van Pamel (geertivp) 2012-07-21 07:05:59.138-0500

In addition to the base RFC 3966,
I have discovered another related RFC 5341:
see http://tools.ietf.org/html/rfc5341

By: Geert Van Pamel (geertivp) 2012-09-29 06:59:08.010-0500

Additional parameter: ;enumdi
https://tools.ietf.org/html/rfc4759
Used when an e164.arpa lookup has already been performed, with or without results.
Potential security issue with faked TEL URI.

By: Geert Van Pamel (geertivp) 2012-09-29 07:42:30.532-0500

New ENUM translation:
https://tools.ietf.org/html/rfc6116 obsoletes RFC 3761


By: Geert Van Pamel (geertivp) 2012-09-29 07:59:36.123-0500

Number Portability Parameters for the "tel" URI
http://www.ietf.org/rfc/rfc4694.txt

By: Geert Van Pamel (geertivp) 2012-09-29 08:09:29.544-0500

More information about ENUM and E.164:
International public telecommunication numbering plan
http://en.wikipedia.org/wiki/Telephone_number_mapping
http://en.wikipedia.org/wiki/E.164

By: Geert Van Pamel (geertivp) 2012-09-29 11:17:49.765-0500

RFC 3403 replaces 2915, 2168.
http://tools.ietf.org/html/rfc3403
See also RFC 3401.

By: Geert Van Pamel (geertivp) 2013-01-27 15:54:39.207-0600

Patch for *Asterisk 1.8.13.1* to implement incoming TEL URI INVITE RFC 3966 functionality.
This version is used by *Raspberry Pi* - *Raspbian* 7.0...

   Added "tel:" to the function *get_destination* in file channels/chan_sip.c; see attachment asterisk-1.8.13.1-chan_sip-diff.txt (4 code sections)
   Added "tel:" to the function *check_user_full* in file channels/chan_sip.c; see attachment asterisk-1.8.13.1-chan_sip-diff.txt (2 code sections)
   Added "phone-context" to the function *parse_uri_full* in file channels/sip/reqresp_parser.c; see attachment asterisk-1.8.13.1-reqresp_parser-diff.txt (1 code section)


By: Geert Van Pamel (geertivp) 2013-01-27 15:56:05.975-0600

asterisk-1.8.13.1 RFC 3966 patch

By: Geert Van Pamel (geertivp) 2013-01-27 15:56:37.060-0600

asterisk-1.8.13.1 RFC 3966 patch

By: Geert Van Pamel (geertivp) 2013-09-12 16:18:35.189-0500

Asterisk 11.5.1 patch for incoming TEL URI

By: Geert Van Pamel (geertivp) 2013-09-12 16:19:23.924-0500

Asterisk 11.5.1 patch for incoming TEL URI

By: Geert Van Pamel (geertivp) 2014-01-12 09:24:09.294-0600

I have applied the same patch once again to the Asterisk 12.0.0 sip_chan module.
For the TEL URI INVITE changes see the patch for 11.5.1 or 1.8.13.1 above.
When will RFC 3966 (this exists already sinds 2004...) be fully implemented in Asterisk PBX?
Every time I upgrade Asterisk I must reapply the same patch and do a build from sources... keeps me busy for an hour or 2...


By: Geert Van Pamel (geertivp) 2014-01-12 12:35:13.441-0600

Question: Would the new chan_pjsip SIP driver solve the RFC 3966 chan_sip TEL URI INVITE problem??

Could we easily switch amongst chan_sip and chan_pjsip?

By: Slashi (slashi) 2014-02-17 11:28:12.206-0600

Successfully applied your patch for TEL IMS support in asterisk 1.8.

Unfortunately, this patch does not fix CALLERID support for tel: headers
"
No supported scheme found in 'tel:+325175023413' using the scheme[s] sip:,sips:
can not parse name and number from sip header.
"
So, CallerId for tel: calls is missed in logs and not operable in extension.conf

Is it possible to provide additional fix for callerid support in tel: URIs (probably additional  reqresp_parser.c modifications?)

By: Geert Van Pamel (geertivp) 2014-02-17 12:03:57.087-0600

Slashi, there is indeed another patch necessary in function parse_uri_full in channels/sip/reqresp_parser.c; see my post of 27/Jan/13 above for 1.8.13.1 and rcsdiff -u attachment in asterisk-1.8.13.1-reqresp_parser-diff.txt.

I would rather love that those 2 patches would be incorporated into the mainstream code for any future version...

I will attach the rcsdiff files for Asterisk 12.0.0.

By: Geert Van Pamel (geertivp) 2014-02-17 12:10:38.689-0600

RFC 3966 patch for Asterisk 12.0.0

Added "tel:" to the function get_destination in file channels/chan_sip.c (2 code sections)
Added "tel:" to the function check_user_full in file channels/chan_sip.c (2 code sections)


By: Geert Van Pamel (geertivp) 2014-02-17 12:11:07.406-0600

RFC 3966 patch for Asterisk 12.0.0

Added "phone-context" to the function parse_uri_full in file channels/sip/reqresp_parser.c (1 code section)

By: Slashi (slashi) 2014-02-17 12:20:01.269-0600

Geert, thanks again for your patches!

I applied provided reqresp_parser patch, but still could not get valid SIP CALLERID for incoming tel: calls in my CDR logs or in debug logs.

May be I missed something.

Could you check again, please, if CALLERID for incoming tel: calls is extracted correctly on you asterisk instance(in csv CDR, for example).



By: Geert Van Pamel (geertivp) 2014-02-18 14:24:23.190-0600

Slashi, The RFC 3966 standard is a bit unclear and complex... it can contain local numbers, global numbers, prefixes, extensions, parameters, and domains; under certain conditions you might need to concatenate the part after and the part before phone-context to see the complete caller ID.

My From line is as follows:

From: <tel:087654321;phone-context=+3287654321>;tag=tag-etc

What is your From line ? (enable SIP debug mode to see it...)

   Do you see any ";phone-context="?
   In RFC 3966 the phone-context is only required when local numbers are used to make the local numbers unique

sip set debug on

It all depends on the calling client/server how the tel: invite is structured... it can become quite complicated.

By: Slashi (slashi) 2014-02-18 18:33:13.404-0600

Geert, I have no phone-context in From: string.

Here is mine:

From: <tel:+11231234567>;tag=....
...
...


So, probably reqresp_parser could not extract callerId because of tel: prefix.



By: Geert Van Pamel (geertivp) 2014-02-19 03:21:42.922-0600

I will send you another patch...

By: Slashi (slashi) 2014-02-19 12:44:58.596-0600

Thanks a lot,Geert!
I will look forward for your reply!

By: Geert Van Pamel (geertivp) 2014-02-19 17:56:53.563-0600

I have added another patch in attachment asterisk-12.0.0-reqresp_parser-RFC3966_patch.txt for RFC 3966 recognition of global telephone numbers for incoming TEL URI INVITE

/* extract from RFC 3966 */
  telephone-uri        = "tel:" telephone-subscriber
  telephone-subscriber = global-number / local-number
  global-number        = global-number-digits *par
  local-number         = local-number-digits *par context *par
  par                  = parameter / extension / isdn-subaddress
  isdn-subaddress      = ";isub=" 1*uric
  extension            = ";ext=" 1*phonedigit
  context              = ";phone-context=" descriptor
  descriptor           = domainname / global-number-digits
  global-number-digits = "+" *phonedigit DIGIT *phonedigit


By: Slashi (slashi) 2014-02-19 20:37:01.794-0600

Applied, and now got this in log(Asterisk 1.8.25):
"
Empty domain name in FROM header
Failed to authenticate device <tel:+11231234567>;tag=.....
"

By: Geert Van Pamel (geertivp) 2014-02-19 22:04:46.203-0600

Well, I think the solution to this is easy:

(extract from RFC3966)
There are two ways to label the context:  via a global number or any
  number of its leading digits (e.g., "+33") and via a domain name,
  e.g., "houston.example.com".  The choice between the two is left to
  the "owner" of the local number and is governed by whether there is a
  global number or domain name that is a valid identifier for a
  particular local number.

Since we receive already a global number; we just copy it into the context (domain).

So we can code this as follows: ( added *dom = uri;* )
 
               } else if ( '+' == uri[0] ) { /* TEL URI INVITE RFC3966 patch */
                       userinfo = uri; /* Global number without context or domain */
*dom = uri;* /* Global number */
c = strchr(uri, ';'); /* Any further parameters? */
if ( c ) { *c++ = '\0'; uri = c; } else { uri = ""; }
}

By: Slashi (slashi) 2014-02-19 23:55:00.426-0600

Thanks once more, Geert! It works perfectly now!

So, why this patch or full rfc3966 support still not in Asterisk distro?
How could I help to include it? May be vote somewhere, or make something else?

By: Geert Van Pamel (geertivp) 2014-02-20 03:51:30.970-0600

Slashi, glad to hear that it works on your site.

Well, yes, the RFC 3966 TEL URI standard exists since 2004... time that the main Asterisk distro would implement it, no? -- standard exists since 10 years now... Technology adherence is not always that fast...

In 2012 I was in contact with Matt Jordan, and he proposed to put this path on the Asterisk Jira "Review board".

But I never could figure out how to do this... since then I implemented always a patch for every new release... a bit of embarrassing...

Now that we are already with at least 2 persons seeing the real benefit of this (standard, but missing) functionality do you know what steps needs to be taken to put this Issue on the review board?

See also https://twitter.com/asteriskpbx/status/434457042141859840

By: Geert Van Pamel (geertivp) 2014-02-20 03:58:30.656-0600

New version of asterisk-12.0.0-reqresp_parser-RFC3966_patch.txt for RFC 3966.

Confirmend to work for *global numbers*.

By: Slashi (slashi) 2014-02-20 04:13:56.413-0600

Geert,
talking about Review Board you probably mean this one: https://reviewboard.asterisk.org/r/

To submit a review request you need to have a Review board account.
Matt Jordan offered you account by email request.
"If you need an account, feel free to contact me at mjordan@digium.com and I'll set one up for you."
Did you already get it?





By: Walter Doekes (wdoekes) 2014-02-20 05:56:29.197-0600

If you want, I can put it on the reviewboard. Or you could get an account through Matt.

In either case, the feature will have to be against trunk, unless you can make a really compelling argument why it should be in Asterisk 12.


By: Geert Van Pamel (geertivp) 2014-02-20 14:31:11.969-0600

I am sorry, but I asked Matt already 3 times to provide me with an account...

If it is easy for you, Walter, please go ahead and put it on the review board...

By: Slashi (slashi) 2014-02-21 09:32:58.541-0600

Geert, also pls try to send Review Board account creation request to asteriskteam@digium.com




By: Geert Van Pamel (geertivp) 2014-02-22 08:00:13.076-0600

I have done so...

By: Walter Doekes (wdoekes) 2014-02-23 14:12:38.283-0600

It is posted. And it has gotten feedback.

Geert: are you willing to work with Corey's concerns and improve the patch?

By: Geert Van Pamel (geertivp) 2014-02-23 18:11:01.714-0600

Please tell me how...

By: Corey Farrell (coreyfarrell) 2014-02-23 18:16:57.512-0600

Geert,

Please take a look at my comments on reviewboard, https://reviewboard.asterisk.org/r/3250/.  You can post updated patches or questions here.

By: Geert Van Pamel (geertivp) 2014-02-26 16:26:38.628-0600

New patch for TEL URI reqresp_parser.c
see asterisk-12.0.0-reqresp_parser-RFC3966_patch.txt.
Taking into account remarks from Corey Farrell.

By: Corey Farrell (coreyfarrell) 2014-02-26 17:43:40.539-0600

I'm fine with the way you are setting teluri_scheme but I would isolate tel uri parsing further:
{noformat}
if (!hostport) {
/* if we don't want to split around hostport, keep everything as a
* userinfo - cos thats how old parse_uri operated*/
} else if (teluri_scheme) {
/* tel: URI parsing here */
} else ...
{noformat}

I recommend you take a look at [Coding Guidelines|https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines], you have extra whitespace and missing line-feeds in your if statements.

As for Reviewboard, you'll want to read [Reviewboard Usage|https://wiki.asterisk.org/wiki/display/AST/Reviewboard+Usage]. You will have to open a new review since only Walter can replace the patch for the review he opened.

Please don't forget to update sip_parse_uri_full_test.

Edited to correct error in example code.

By: Geert Van Pamel (geertivp) 2014-02-28 01:30:43.851-0600

Thanks, Corey Farrell, you probably understand that I need some more time to first setup my development environment (svn, python-setuptools) and then to learn how to use the Reviewboard to create a new patch.

By: Geert Van Pamel (geertivp) 2014-03-13 13:28:24.252-0500

Have just published https://reviewboard.asterisk.org/r/3349/

By: Alexander Gonchiy (alexander.gonchiy) 2015-09-22 09:02:00.167-0500

Why is this still an issue in 11.17 and later?
This is definitely not fixed!
Source code for 11.17+ do not contain this patch, causing this warning:

chan_sip.c:17454 get_rdnis: Huh?  Not an RDNIS SIP header (tel:786XXXXXXXX)?

By: Richard Mudgett (rmudgett) 2015-09-22 13:39:20.554-0500

If you look at the Source tab above you will see that this patch was committed to trunk on April 17, 2014.  The v13 branch has since been branched from trunk so it contains this patch.  Since it is a new feature, it will not go into Asterisk v11.

By: Arkadiy (ethaniel) 2022-08-27 03:14:56.759-0500

Any idea why this error might still show up in Asterisk 19.6.0?
[Aug 27 11:13:08] WARNING[135322][C-00000001] chan_sip.c: Huh?  Not an RDNIS SIP header (tel:7495XXXXX10)?

(numbers removed for privacy reasons)

By: Geert Van Pamel (geertivp) 2022-08-27 07:44:06.398-0500

Maybe RDNIS problem caused by missing phone_context in SIP header?

By: Asterisk Team (asteriskteam) 2022-08-27 07:44:07.652-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.