23 Dec
2009
23 Dec
'09
7:35 a.m.
On Dec 21, 2009 at 14:51, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
Yes, but the ACK to the negative reply is built differently. It's built
from the original INVITE and hence it doesn't include the proper route
set and possible uri changes (due to strict routers).
If you change the negative ack part, then
you'll have an ack to 2xx
generated the same way as a neg. ack (the route set and the uri might be
wrong).
andrei,
this is exactly what i tried to achieve, i.e., if 200 ok is to a locally
generated invite, then ack should be send the same way as negative ack.
from rfc3261:
The ACK (to negative reply) MUST be sent to the same address, port,
and transport to which the original request was sent.
so what i proposed should work IF it is possible to add the test that i
outlined:
if ((msg_status >= 300) || "invite was
generated locally by t_uac function") {
i.e, if ack is to negative reply OR if invite was locally generated,
send the ack the same way.
but for me, of course, any way to get to the same result if fine.
I've added a new parameter (local_ack_mode) on the sr_3.0 branch.
Docs will come a bit later.
Sorry for the delay, but my laptop had an unfortunate accident
(involving water) and it took some time to recover (drying) :-)
Andrei