12 Jul
2007
12 Jul
'07
7:25 a.m.
On Thursday 12 July 2007 12:54:58 Martin Hoffmann wrote:
You are not telling me anything new here. But as I explained in my other reply
to Klaus it is quite tricky to distinguish a non-2xx ACK with pre-loaded
Route, from a 2xx ACK with just one Route header. Then the only difference is
the RURI.
Because of this I prefer the approach of "routing" pre-loaded requests via
loose_route() to the RURI. That is IMHO the cleanest solution.
Nils Ohlmeier wrote:
You call them non-2xx ACKs, I called them out-of-dialog ACKs (because the
typical scenario for them is the acknowledgment of the 40[17] for the INVITE,
and there is no dialog yet). But we are speaking about the same here.
On Thursday 12 July 2007 09:26:37 Martin Hoffmann
wrote:
Techically, there is no such thing. There is only ACKs to 2xx and
non-2xx responses. The former are always in-dialog requests, since the
2xx creates the dialog should it not yet exists. The latter is a matter
of the transaction layer which doesn't know of dialogs. Is there any argument against putting a
if (method == "ACK") {
t_relay();
drop();
}
somewhere way up in your config?
And how do you distinguish between in-dialog ACKs and out-of-dialog ACKs? In practice, an ACK to a non-2xx response always needs
to be eaten by
tm. This t_relay() does. Any ACK to a 2xx response needs to be routed
like any other in-dialog request to the endpoint (save for some
elaborate processing such as authentication). Which means, my code
snipped does indeed lack a loose_route() before t_relay().
Ok, what is the loose_route suppose to do in this case?
A 2xx ACK would be "routed" according to the Route headers by loose_route(),
and relayed by t_relay() then. And what about the pre-loaded non-2xx ACKs?
I would treat them exactly the same way like the 2xx ACK. loose_route() will
consum the Route header and t_relay() then forwards it to the RURI (which
should be your proxy). When you receive it again, their is no Route in it any
more, so it should hit your normal non-dialog code where it hopefully sooner
or later will hit a t_relay.
Note: they
both have a To-tag and even worse if the original INVITE
contained a pre-loaded Route header (for outbound proxy) the ACK has to
contain this Route as well!
Depends. A non-2xx ACK indeed has to. But a 2xx ACK musn't. It is to be
created like any other in-dialog request. The Route set thus MUST be the
reversed set of the Record-Route headers of the 2xx response, possibly
be empty. Book keeping: Limited to seruser and changed subject.
I'm not sure if that was the right limitation, but anyway ;-)
Regards
Nils