[sr-dev] problem with locally generated ACKs

[Andrei Pelinescu-Onciul]

On Dec 18, 2009 at 15:01, Juha Heinanen <jh at tutpro.com> wrote:
> Andrei Pelinescu-Onciul writes:
> 
>  > Right now the only way to solve this without code changes is to add
>  > another hop (e.g. route the message once through localhost or another
>  > proxy and fix the contact there).
> 
> andrei,
> 
> this used to work fine in k, so i would don't like the idea about
> changing the script, especially when the change would not be trivial.

After looking at the code, I doubt it used to work in k. k still sends
an ACK based on the reply contact and the final replies are processed
before the reply route is executed (same as in sr).

> 
>  > With coding changes I see 2 possible workarounds:
>  > 1. add a param. for using the local INVITE dst. when generating the ACK
>  >  (instead of obeying the rfc) (easy)
> 
> where would that param be added?

tm global param, e.g. modparam("tm", "local_200_ack_send_mode", 1).

> can't the param be set automatically
> when invite is issued by tm.t_uac_wait?

That would complicate things. We would need another flags and we would
need to chande t_uac_wait to take another param.

> 
>  > 2. add a t_reply_fake_contact() command for changing the contact seen by
>  > tm and maybe modifiying fix_nated_contact() to use it.
> 
> if t_reply_fake_contact() is implemented, why can't i just call that
> function in onreply_route instead of fix_nated_contact()?

In this case we would need to copy fix_nated_contact() into
t_reply_fake_contact().

Andrei