No subject

Thu Jan 29 11:41:19 CET 2009

then a 500 (relayed) and a 503 (scripted) at the same time.  The UAC ACKs
both of them and the transaction is over.

Is all of this due to the lcr module still appending a branch in the failur=
e
route when it shouldn=B9t be?  Or, does it appear something else is going on?
Normally I=B9d post config snippits but in it=B9s got so much more unrelated an=
d
properly-functioning stuff I didn=B9t want to confuse the issue with the
truth.  :)

Or, as an aside, can drouting duplicate the load_gw_from_grp() and gateway
flags functionality of lcr?

Thanks,
Jeff

--B_3319198807_5334289
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>next_gw still does append_branch in failure_route?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:10pt'=
>Hello,<BR>
<BR>
I&#8217;m using the LCR module in Opensips 1.5. &nbsp;(I realize I should p=
robably be using drouting if I&#8217;m starting from scratch, but I need the=
 gateway group and flags functionality that only appear to be in the LCR mod=
ule. &nbsp;More on that at the end.)<BR>
<BR>
Bogdan emailed the list about not needing append_branch any longer in a fai=
lure_route (<a href=3D"http://www.mail-archive.com/devel@lists.opensips.org/ms=
g00663.html">http://www.mail-archive.com/devel@lists.opensips.org/msg00663.h=
tml</a>). &nbsp;All the documentation seems to indicate that next_gw still d=
oes the append_branch automatically.<BR>
<BR>
The behavior I&#8217;m seeing, along with Bogdan&#8217;s email from January=
, seem to indicate it&#8217;s not necessary anymore. &nbsp;In my configurati=
on, next_gw is called from the request_route. &nbsp;The request is sent out =
with t_relay. &nbsp;The request fails with a 503, and is caught in the armed=
 failure_route. &nbsp;next_gw is called again, then t_relay. &nbsp;There app=
ear to be two branches present, the old one to the first (failed) gateway an=
d the new one to the second newly loaded gateway. &nbsp;t_relay does a paral=
lel fork to both of them. &nbsp;The first gateway fails again 503, and in my=
 test setup, so does the second, also with a 503. &nbsp;One of these 503s is=
 properly processed by the armed failure_route, the other one is converted t=
o a 500 and relayed to the UAC.<BR>
<BR>