Brett,

I can't answer how it's *supposed* to work, but I can explain how I've made it 
work.

        if (t_check_status("302")) {
                if(!get_redirects("*")) {
                        route(20);      # No redirects, junk the call (send an 
error to the caller, other than 302)
                        exit;
                }

                # Brett, these two may be your key
                serialize_branches(1);
                next_branches();

                setbflag(3);    # 302 in progress
                t_on_failure("4");      # This failure_route
                t_on_branch("1");      # Not sure why I need this, but it used 
to fail without I think

                resetflag(1);
                route(23);      # Send request (some wrappers around a t_relay, 
nothing relevant to the 302)
        }

        if (isbflagset(3)) {
                if (next_branches()) {
                        t_on_failure("4");  # This failure_route
                        resetflag(22);
                        route(23);      # Send request
                } else {
                        resetbflag(3);  # The 302's over
                        setflag(22);    # Make sure there's failure accounting
                        route(20);      # Done trying, fail the call (send an 
error to the caller, other than 302)
                }
         }

This is some older config of mine.  I haven't revisited it because it works, 
but I would imagine there are efficiency improvements to be had.


- Jeff


On Mar 24, 2010, at 10:41 PM, Brett Nemeroff wrote:

Hello All,
I have a question about 302 redirects.Maybe I'm just misunderstanding how it's 
supposed to work..

I get the following redirect:

SIP/2.0 302 Moved temporarily.
Via:SIP/2.0/UDP 192.168.21.10;branch=z9hG4bK6cd5.ae1f6c43.0,SIP/2.0/UDP 
10.10.10.11:5060;branch=z9hG4bK-a96e3-4baac9a7-8c685c67-5898d54b.
From:<sip:[email protected]:5060<http://sip:[email protected]:5060/>>;tag=a9d5ed0-13c4-4baac9a7-8c685c67-19c2a61a.
To:<sip:[email protected]:5060<http://sip:[email protected]:5060/>>;tag=100063687-1269483944267.
Call-ID:cxc-410-65762490-a9d5ed0-13c4-4baac9a7-8c685c67-17d58...@10.10.10.11<mailto:call-id%3acxc-410-65762490-a9d5ed0-13c4-4baac9a7-8c685c67-17d58...@10.10.10.11>.
CSeq:1 INVITE.
Record-Route:<sip:192.168.21.10;lr=on;did=f8d.623e93f6>.
Contact:<sip:[email protected]:5060;user=phone>;q=0.5,<sip:[email protected]:5060;user=phone>;q=0.25.
Content-Length:0.

And in my failure route I have:

        if (t_check_status("302")) {
                get_redirects("*");
                t_relay();
                exit;
        }

Now when I watch a sip trace, right after the 302, an INVITE fires off to BOTH 
192.168.50.10 and 192.168.30.10 at the exact same time. The q values are 
different, shouldn't they be serial?

I'm not entirely sure how much "magic" is handled in the q-value and how much 
needs to be scripted.. But I was under the impression that this magic was 
"fully automatic"

Thanks!
-Brett



_______________________________________________
Users mailing list
[email protected]<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to