Re: [reSIProcate-users] ACK being sent to the contact instead of the place it received it from
Hi Dan,
Could you describe your topology? Also which form of record-routing are you using (which option)?
For reference, I've had the following working:
DUM client <> repro gateway <> core server <> repro gateway<> DUM client
In my configuration, both repro and core record route (as you discovered, without record-routing they drop out of the signaling path -- this is the basic design of SIP).
Note that repro doesn't "fix" the contact. Instead it adds an additional token to the Record-route header. This is a flow-token, and it is encoded in the username portion of the record-route uri. For REGISTER requests, it it is encoded in a Path header. The contact header is left unmolested.
Regards,
Kennard
On Mon, Jan 24, 2011 at 12:02 AM, Dan Weber
<dan@xxxxxxxxxxxxxx> wrote:
Ok, I got through this and I've worked around it by forcing record route
on repro, and it is now sending the ACK back to repro, but repro isn't
sending it to the right destination after it receives it... (e.g.
sending back to the private address that is listed in the 200 OK).
Eerily enough, it appears that even though with rport and TCP the
contact is fixed on the registrations, nothing seems to fix the contact
in on going dialogs that are created after that with DUM. I suspect
repro is reading the contact in the 200 OK instead of processing it back
through itself. In either case, if there is a way to fix both pieces so
that dum puts the right contact, and repro properly routes back the ACK,
I think this would be much better.
Dan