Asterisk
  1. Asterisk
  2. ASTERISK-17179

[patch] IMS TEL URI incoming INVITE RFC 3966 not recognized

    Details

      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

      1. asterisk_10.1.3_chan_sip_diff.txt
        1 kB
        Geert Van Pamel
      2. asterisk_10.1.3_reqresp_parser_diff.txt
        0.5 kB
        Geert Van Pamel
      3. asterisk-1.6.2.7-sip_chan.dif
        1 kB
        Geert Van Pamel
      4. asterisk-1.8.13.1-chan_sip-diff.txt
        2 kB
        Geert Van Pamel
      5. asterisk-1.8.13.1-reqresp_parser-diff.txt
        0.7 kB
        Geert Van Pamel
      6. asterisk-11.5.1-chan_sip-diff.txt
        0.9 kB
        Geert Van Pamel
      7. asterisk-11.5.1-reqresp_parser-diff.txt
        0.5 kB
        Geert Van Pamel
      8. asterisk-12.0.0-chan_sip-RFC3966_patch.txt
        1 kB
        Geert Van Pamel
      9. asterisk-12.0.0-reqresp_parser-RFC3966_patch.txt
        2 kB
        Geert Van Pamel
      10. chan_sip-asterisk_1.6.2.9-2ubuntu2.1-diff.txt
        1 kB
        Geert Van Pamel
      11. chan_sip-asterisk-1.6.2.9.txt
        1 kB
        Geert Van Pamel
      12. chan_sip-diff.txt
        2 kB
        Geert Van Pamel

        Issue Links

          Activity

          Hide
          Corey Farrell added a comment - - edited

          I'm fine with the way you are setting teluri_scheme but I would isolate tel uri parsing further:

          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 ...
          

          I recommend you take a look at Coding Guidelines, you have extra whitespace and missing line-feeds in your if statements.

          As for Reviewboard, you'll want to read 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.

          Show
          Corey Farrell added a comment - - edited I'm fine with the way you are setting teluri_scheme but I would isolate tel uri parsing further: 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 ... I recommend you take a look at Coding Guidelines , you have extra whitespace and missing line-feeds in your if statements. As for Reviewboard, you'll want to read 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.
          Hide
          Geert Van Pamel added a comment -

          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.

          Show
          Geert Van Pamel added a comment - 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.
          Hide
          Geert Van Pamel added a comment -
          Show
          Geert Van Pamel added a comment - Have just published https://reviewboard.asterisk.org/r/3349/
          Hide
          Alexander Gonchiy added a comment - - edited

          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)?

          Show
          Alexander Gonchiy added a comment - - edited 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)?
          Hide
          Richard Mudgett added a comment -

          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.

          Show
          Richard Mudgett added a comment - 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.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development