Type: New Feature
Affects Version/s: None
Target Release Version/s: None
This patch is app_sipredirect. Here is the modified description from the bounty request on -biz:
= Info about application 'SIPRedirect' =
Sends a SIP 302 message to caller with custom content
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)