Thanks for the info. Unfortunately that is not the current behavior of the system. I removed the lcr routing on the BYE request so that it uses t_relay(). Now it sends the ACK (in response to the 200 OK) and the BYE to the to uri domain/ip-address rather than continuing the dialog. Yet the previous parts of the dialog are forwarded properly.
What exactly does the tm module use to differentiate between transactions? Cause a problem could be that it is getting responses from the gateways at different ip addresses than it is sending. My "gateways" are simply a single machine with a bunch of aliased IPs running sipp. So a request comes in on .91 and goes out on .89
Would that cause this behavior?
On Wed, 2006-03-15 at 01:50 +0200, Juha Heinanen wrote:
Rick Richardson writes:
I have the lcr module in my proxies properly distributing INVITES
and
maintaining the dialog throughout a sip call. Except for the BYE,
and
the reason is simply that that is a new transaction. So is the only
way
for me to reach the callee with a BYE message to find the proper
gateway
for it using the LCR module again? I'm guessing this or possibly
AVPs
would be the only method sending the request to the proper user.
bye is in-dialog request and its request uri points to the right gw.
so
you just t_relay in-dialog requests.
-- juha