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