[asterisk-bugs] [Asterisk 0018549]: [patch] IMS TEL URI incoming INVITE RFC 3966 not recognized

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18549 
====================================================================== 
Reported By:                geertivp
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18549
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     confirmed
Asterisk Version:           SVN 
JIRA:                       SWP-2825 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-12-29 04:50 CST
Last Modified:              2011-05-26 06:00 CDT
====================================================================== 
Summary:                    [patch] IMS TEL URI incoming INVITE RFC 3966 not
recognized
Description: 
This problem should also exist in version 1.8! Please verify & confirm.

Asterisk seems *not* to support RFC 3966 TEL URI for incoming INVITE.
X-Lite does.

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 at ...>
Diversion:
<sip:+3212345678 at ...;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

I have solved the problem by patching chan_sip.c -- see rcsdiff -u below

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

I have written a patch for Asterisk 1.6.1.20 chan-sip.c to support the TEL
URI INVITE standard for incoming calls.

I have changed the following functions:

* parse_uri
* check_user_full
* get_destination

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

When there is no domain as with TEL INVITE we should set name to the
calling number (I simply reversed dom and name in the original source for
TEL INVITE leaving the domain blank). It was already suggested in the code
that there is confusion with the RFC.



More information:

http://forums.digium.com/viewtopic.php?f=1&t=76432&sid=6d53062361c22079757c53ccc73d3132
====================================================================== 

---------------------------------------------------------------------- 
 (0135427) geertivp (reporter) - 2011-05-26 06:00
 https://issues.asterisk.org/view.php?id=18549#c135427 
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-26 06:00 geertivp       Note Added: 0135427                          
======================================================================