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