[SR-Users] behaviour of uac_redirect module

[Dirk Teurlings - Signet B.V.]

On 06/22/2016 07:45 AM, Daniel-Constantin Mierla wrote:
> Looking quickly at the code, both versions of the functions are
> executing the same inner function, but there can still be some
> conditions on the reason parameter, so I need to dig in further.
> 
> However, I need to understand first what you actually do there:
> 
>   - you are getting a 302 from downstream
>   - call get redirects to created new branches from the contacts of
> received 302
>   - don't forward the 302 to upstream, but generated a new 302 with
> t_reply(...) to be sent upstream

Yes, this is how it is done now, only the 302 isn't sent upstream in our
case, but to our mediaservers (asterisk).

Here's the part now handling the 302 routing.

failure_route[MANAGE_FAILURE] {

        # Respond to 3XX messages.
        if (t_check_status("3[0-9][0-9]")) {
                if (from_any_gw($si, 0)) {
                        t_reply("404", "Not Found");
                        exit;
                }

                # Fetch Contact: headers and log this entry.
                get_redirects("*", "Redirects");

                # Update Contact: header and reply instead of UA, ensuring
                # Redirected Dialed Number Information Service stays intact.
                $ru = "sip:" + $rU + "@sip.wlvoip.net";
                t_reply("302", "Moved Temporarily");

                exit;
        }
}


So my, possibly bad, assumption was that I could replace this with the
get_redirects("*"), skipping the logging entirely. But that results in
the earlier sent SIP packets.

Cheers,
Dirk