I think my previous issues boil down to my lack of understanding as to how the tm module knows where to forward requests in a new transaction.
In the initial invite, the LCR sets the uri:host,port and t_relay obviously sends the item to the proper destination.
However.. after the 180 and 200. The resulting ACK is a new transaction, as well as the messages that follow.
What I don't understand is t_relay knows to forward to the destination selected by the lcr module in these new transactions?.
Currently its behavior is to forward to the host part of the TO URI. This does not do me any good. How can I ensure that the dialog continues to go through the proper gateway?
Thanks,
Rick
Rick Richardson writes:
However.. after the 180 and 200. The resulting ACK is a new transaction, as well as the messages that follow.
What I don't understand is t_relay knows to forward to the destination selected by the lcr module in these new transactions?.
see Request-URI in the ACK.
Currently its behavior is to forward to the host part of the TO URI.
To URI is never used to forward the request.
-- juha
Ahh... so in my test the r-uri is set the same in my test as the to-uri. Which i doubt is that uncommon, the problem is that this does not actually point to the proper location, it is relying on the proxy to guide it to the proper place.
If I understand this correctly, the difference is in normal proxy interaction, only the invite-180-200 pass through the proxy, then the uas and uac should learn each other's location and send the ACK and BYE etc directly.
My problem is twofold. A: since my proxy is record routing, it is receiving all messages between the two UA's, and the r-uri's it is receiving from the URIs indicate that they still don't know the location of the UAs.
The other part of that problem is that I've dynamically chosen the gateway, so I can't simply statically route these messages to their proper destination.
I have been playing around with routing the ACK and BYE the same way I do the INVITE, that is, find the proper gateway using the LCR module.
This seems to work, the downside is that I'm very frequently calling load_gws and next_gw and it is very frequently failing and responding with "...No Gateways..."
If there were a way I could store this gateway information in a dialog-stateful AVP I would be set.
Thanks for your help.
On Thu, 2006-03-16 at 00:26 +0200, Juha Heinanen wrote:
Rick Richardson writes:
However.. after the 180 and 200. The resulting ACK is a new transaction, as well as the messages that follow.
What I don't understand is t_relay knows to forward to the destination selected by the lcr module in these new transactions?.
see Request-URI in the ACK.
Currently its behavior is to forward to the host part of the TO URI.
To URI is never used to forward the request.
-- juha
-
Juha Heinanen -
Rick Richardson