Asterisk
  1. Asterisk
  2. ASTERISK-3344

[patch] app_sipredirect for generating '302 Moved Temporarily' messages

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Core/General
    • Labels:
      None
    • Mantis ID:
      3419
    • Regression:
      No

      Description

      This patch is app_sipredirect. Here is the modified description from the bounty request on -biz:

      Syntax:

      = Info about application 'SIPRedirect' =

      [Synopsis]:
      Sends a SIP 302 message to caller with custom content

      [Description]:
      SIPRedirect(extension[@host[:port]])
      extension := string which contains new extension (mandatory)
      host := hostname or IP address of SIP destination. If left blank, this host's IP address will be used.
      port := integer. If left unset, no port will be specified.

      This application can only be called before a call is answered. Calling this application after a call has been answered, or if the originating channel is not a SIP channel creates a 0 result. After being called successfully, the application exits with a -1 result. This seems to be opposite of what should happen, but there isn't much reason to continue processing the dialplan after handing off the 302 redirect, and giving a "0" result would allow for graceful error handling and continued dialplan processing if non-SIP or previously answered calls were handed to the application.

      The host information is tricky in the default situation: it uses the externip if specified in sip.conf. If that is blank, it uses externhost if the timer for the host is still valid. If that is blank, it uses the IP address:port or hostname:port in the original INVITE. Of course, you can specify the host and port in the command line if you wish; it will only try the other methods if there is no host[:port] specified in the command. I would suggest that typically the host should at least be specified unless you are doing really exotic things. If you're not redirecting the call to a different server, then I'd suggest you look more at Goto as an option instead of SIPRedirect.

      The application re-writes the Contact: address on the reply, so that the newly formed URI would be used by the requester to re-initiate the call to a different location.

      This nifty trick might be used to create a central "call diverter" which then redirects many end users to multiple endpoints without having to keep state. The CDR would be very brief on the central host, and would not contain any data about activity that happened on the redirected host/gateway. However, that's fine - this isn't designed to replace app_dial; it's just a crude method to distribute SIP callers when they might not really need to be attached to this particular Asterisk instance.

      The only feature it lacks is the ability to specify the human-readable text in the Contact: field, but that does not seem to be very important. Currently, it just says "redirect" which seems sufficient.

      Written by Martin Pycko as a work for hire by John Todd. Both John and Martin have disclaimers on file. John is the "sponsor" for this work, so he explicitly allows it to be added to the project under the same guidelines as usual for patches to be added to *.

      This is a seemingly minor item, but will be insanely handy for larger installations or where (due to billing issues) calls need to appear to come from the end-user device no matter how they got the information. Solves lots of NAT problems, too! Overall, a useful tool in the toolkit for advanced SIP hacking on Asterisk.

      Applies to version 1.367 of chan_sip.c (2005-01-24)

        Activity

        Hide
        John Todd added a comment -

        Passes my preliminary tests for transfers with SIP 302's, yes. The patch needs to be updated because sip_transfer has moved, but there is no code change (just position within the file.)

        Show
        John Todd added a comment - Passes my preliminary tests for transfers with SIP 302's, yes. The patch needs to be updated because sip_transfer has moved, but there is no code change (just position within the file.)
        Hide
        John Todd added a comment -

        Other than the extremely minor patch offset (probably does not require a new patch being created) I see no reason to not have this go in.

        Show
        John Todd added a comment - Other than the extremely minor patch offset (probably does not require a new patch being created) I see no reason to not have this go in.
        Hide
        Mark Spencer added a comment -

        Added to CVS with mods. Thanks!

        Show
        Mark Spencer added a comment - Added to CVS with mods. Thanks!
        Hide
        Russell Bryant added a comment -

        not included in 1.0 since it's a new feature

        Show
        Russell Bryant added a comment - not included in 1.0 since it's a new feature
        Hide
        Digium Subversion added a comment -

        Repository: asterisk
        Revision: 5055

        U trunk/apps/app_transfer.c
        U trunk/channels/chan_sip.c

        ------------------------------------------------------------------------
        r5055 | markster | 2008-01-15 15:25:44 -0600 (Tue, 15 Jan 2008) | 2 lines

        Add sip redirect support (bug #3419i, with mods)

        ------------------------------------------------------------------------

        http://svn.digium.com/view/asterisk?view=rev&revision=5055

        Show
        Digium Subversion added a comment - Repository: asterisk Revision: 5055 U trunk/apps/app_transfer.c U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r5055 | markster | 2008-01-15 15:25:44 -0600 (Tue, 15 Jan 2008) | 2 lines Add sip redirect support (bug #3419i, with mods) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5055

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development