[asterisk-bugs] [JIRA] (ASTERISK-17179) [patch] IMS TEL URI incoming INVITE RFC 3966 not recognized

Geert Van Pamel (JIRA) noreply at issues.asterisk.org
Wed Sep 11 15:07:03 CDT 2013

Previous message: [asterisk-bugs] [JIRA] (ASTERISK-22424) bridge_native_rtp: Asterisk 12 attempts to remotely bridge on 200OK response to invite when the 200 lacks SDP
Next message: [asterisk-bugs] [JIRA] (ASTERISK-17179) [patch] IMS TEL URI incoming INVITE RFC 3966 not recognized
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-17179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geert Van Pamel updated ASTERISK-17179:
---------------------------------------

         Description: 
This problem also exists in version 1.8!

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

****** ADDITIONAL INFORMATION ******

<code removed>
Please always add code as an attachment and mark as code.
</code removed>

  was:
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

****** ADDITIONAL INFORMATION ******

<code removed>
Please always add code as an attachment and mark as code.
</code removed>

         Environment: All platforms
    Issue Consultant: matt
          Issue Type: Improvement  (was: New Feature)
    
> [patch] IMS TEL URI incoming INVITE RFC 3966 not recognized
> -----------------------------------------------------------
>
>                 Key: ASTERISK-17179
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17179
>             Project: Asterisk
>          Issue Type: Improvement
>          Components: Channels/chan_sip/Interoperability
>         Environment: All platforms
>            Reporter: Geert Van Pamel
>              Labels: INVITE, PATCH, RFC3966, RFC5341, SIP, TEL, URI
>         Attachments: asterisk_10.1.3_chan_sip_diff.txt, asterisk_10.1.3_reqresp_parser_diff.txt, asterisk-1.6.2.7-sip_chan.dif, asterisk-1.8.13.1-chan_sip-diff.txt, asterisk-1.8.13.1-reqresp_parser-diff.txt, chan_sip-asterisk_1.6.2.9-2ubuntu2.1-diff.txt, chan_sip-asterisk-1.6.2.9.txt, chan_sip-diff.txt
>
>
> This problem also exists in version 1.8!
> 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
> ****** ADDITIONAL INFORMATION ******
> <code removed>
> Please always add code as an attachment and mark as code.
> </code removed>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Previous message: [asterisk-bugs] [JIRA] (ASTERISK-22424) bridge_native_rtp: Asterisk 12 attempts to remotely bridge on 200OK response to invite when the 200 lacks SDP
Next message: [asterisk-bugs] [JIRA] (ASTERISK-17179) [patch] IMS TEL URI incoming INVITE RFC 3966 not recognized
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the asterisk-bugs mailing list