Evidently responding publically to my own question is some sort of cheap therapy. Anyway, I found some old examples of how this is supposed to work, and all the examples included a t_on_branch() statement. My config did not. I ripped off one of the examples almost character for character and it is now behaving as one would expect. Apparently my lack of understanding when it comes to branch routes was to blame all along.
- Jeff On 3/30/09 4:17 PM, "Jeff Pyle" <[email protected]> wrote: > Bogdan, > > I'm seeing the same behavior in 1.4.5. There's got to be some misconfig on > my part, no? > > > - Jeff > > > > On 3/30/09 3:02 PM, "Jeff Pyle" <[email protected]> wrote: > >> Hi Bogdan, >> >> Here it is: >> >> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:get_redirect: resume >> branch=0 >> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:get_redirect: checking >> branch=0 (added=0) >> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:get_redirect: branch=0 is a >> redirect (added=0) >> Mar 30 14:55:58 opensips[16337]: DBG:core:parse_headers: flags=7 >> Mar 30 14:55:58 opensips[16337]: DBG:core:get_hdr_field: content_length=0 >> Mar 30 14:55:58 opensips[16337]: DBG:core:get_hdr_field: found end of header >> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts: >> sort_contacts: <sip:[email protected]:5060;user=phone> q=250 >> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts: >> sort_contacts: <sip:[email protected]:5060;user=phone> q=500 >> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding >> contact <sip:[email protected]:5060;user=phone> >> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding >> contact <sip:[email protected]:5060;user=phone> >> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded >> <sip:[email protected]:5060;user=phone>, q=250 q_flag <0> >> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded >> <sip:[email protected]:5060;user=phone>, q=500 q_flag <16> >> Mar 30 14:55:58 opensips[16337]: DBG:core:next_branches: branch is >> <sip:[email protected]:5060;user=phone> >> >> When t_relay¹ing this, parallel invites went out to both the .119.46 and >> .116.46 hosts. Same as before. Same 302 Contact header as well. >> >> Shortly I¹m going to be reverting to 1.4.5 from 1.5.0 because 1.5.0 just >> ³stops² after many hours of use with no debug info and no core. I have no >> idea why, and my attempts to get debug information have failed. >> Unfortunately >> it¹s my only option. As such, I won¹t be able to test this anymore on 1.5. >> >> >> - Jeff >> >> >> >> >> On 3/30/09 5:12 AM, "Bogdan-Andrei Iancu" <[email protected]> wrote: >> >>> Hi Jeff, >>> >>> could you post the debug again? maybe there is something else.... >>> >>> Thanks and regards, >>> Bogdan >>> >>> Jeff Pyle wrote: >>>> Hi Bogdan, >>>> >>>> I still get the parallel forking to both contacts. >>>> >>>> >>>> - Jeff >>>> >>>> >>>> >>>> On 3/26/09 2:48 PM, "Bogdan-Andrei Iancu" <[email protected]> wrote: >>>> >>>> >>>>> Hi Jeff, >>>>> >>>>> I found a small bug in the uac_redirect() function - I fixed it on 1.5 >>>>> and trunk, so if you upload from svn it should work now. >>>>> >>>>> Thanks and regards, >>>>> Bogdan >>>>> >>>>> Jeff Pyle wrote: >>>>> >>>>>> Hi Bogdan, >>>>>> >>>>>> Debug level was 6 for get_redirects("*"), serialize_branches(1) and >>>>>> next_branches(). The contact header from the 302 was as follows: >>>>>> >>>>>> > Contact:<sip:[email protected]:5060;user=phone>;q=0.5,<sip:+130300>>>>> > > 0 >>>>>> 00 >>>>>> [email protected]:5060;user=phone>;q=0.25 >>>>>> >>>>>> Debug output: >>>>>> >>>>>> DBG:uac_redirect:get_redirect: resume branch=0 >>>>>> DBG:uac_redirect:get_redirect: checking branch=0 (added=0) >>>>>> DBG:uac_redirect:get_redirect: branch=0 is a redirect (added=0) >>>>>> DBG:core:parse_headers: flags=7 >>>>>> DBG:core:get_hdr_field: content_length=0 >>>>>> DBG:core:get_hdr_field: found end of header >>>>>> DBG:uac_redirect:sort_contacts: sort_contacts: >>>>>> <sip:[email protected]:5060;user=phone> q=250 >>>>>> DBG:uac_redirect:sort_contacts: sort_contacts: >>>>>> <sip:[email protected]:5060;user=phone> q=500 >>>>>> DBG:uac_redirect:shmcontact2dset: adding contact >>>>>> <sip:[email protected]:5060;user=phone> >>>>>> DBG:uac_redirect:shmcontact2dset: adding contact >>>>>> <sip:[email protected]:5060;user=phone> >>>>>> DBG:core:serialize_branches: loaded >>>>>> <sip:[email protected]:5060;user=phone>, q=-1 q_flag <0> >>>>>> DBG:core:serialize_branches: loaded >>>>>> <sip:[email protected]:5060;user=phone>, q=500 q_flag <16> >>>>>> DBG:core:next_branches: branch is >>>>>> <sip:[email protected]:5060;user=phone> >>>>>> >>>>>> The Opensips build is from an SVN checkout of branches/1.5 about 15:00 >>>>>> GMT today. >>>>>> >>>>>> >>>>>> - Jeff >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 3/23/09 10:38 AM, "Bogdan-Andrei Iancu" <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Hi Jeff, >>>>>>> >>>>>>> please post the debug=6 logs - also be sure you are using the latest >>>>>>> version as a similar bug was fixed one or two weeks ago. >>>>>>> >>>>>>> Regards, >>>>>>> Bogdan >>>>>>> >>>>>>> Jeff Pyle wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I catch a 302 in a failure_route that runs: get_redirects(³*²), >>>>>>>> serialize_branches and next_branches. The subsequent t_relay() causes >>>>>>>> a parallel fork to both contacts in the 302¹s Contact header. >>>>>>>> >>>>>>>> The 302¹s Contact header looks like this: >>>>>>>> >>>>>>>> >>>>>> > Contact:<sip:[email protected]:5060;user=phone>;q=0.5,<sip:+1303000>>>>> > > 0 >>>>>> 00 >>>>>> >>>>>>>> [email protected]:5060;user=phone>;q=0.25 >>>>>>>> >>>>>>>> I would expect it to load only the q=0.5 route at first, no? >>>>>>>> >>>>>>>> >>>>>>>> - Jeff >>>>>>>> ----------------------------------------------------------------------->>>>>>>> - >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> [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 > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
