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

Asterisk Bug Tracker noreply at bugs.digium.com
Sat Feb 19 10:25:35 CST 2011


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-02-19 10:25 CST
====================================================================== 
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
====================================================================== 

---------------------------------------------------------------------- 
 (0132184) geertivp (reporter) - 2011-02-19 10:25
 https://issues.asterisk.org/view.php?id=18549#c132184 
---------------------------------------------------------------------- 
Who can prepre 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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-19 10:25 geertivp       Note Added: 0132184                          
======================================================================




More information about the asterisk-bugs mailing list