21 Dec
2009
21 Dec
'09
6:18 a.m.
On Dec 21, 2009 at 12:17, Juha Heinanen <jh(a)tutpro.com> wrote:
since i'm stuck with ACKs to locally generated
INVITEs never reaching
UASes behind NATs, i tried to read tm code to find out how to make sr
always send ACK to locally generated INVITE to use the same r-uri and
destination set as the INVITE itself.
i found this piece of code reply_received() function of t_reply.c:
if (is_invite(t)) {
if (msg_status >= 300) {
ack = build_ack(p_msg, t, branch, &ack_len);
it looks to me that the desired effect could be achieved if the middle
line is changed to something like this:
if ((msg_status >= 300) || "invite was generated locally by t_uac function")
{
No, not that line, You should change the else part of the same if:
} else if (is_local(t) /*&& 200 <= msg_status < 300*/) {
This is the part that generates ACK to 2xx for local transactions.
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).
does someone know how to implement the test, i.e., is there some info in
t structure that could be used to figure out if the invite was locally
generated?
Change build_dlg_ack() (t_msg_builder.c:915), the part awhere dst is set
(uri2dst). There are some ifs enclodes in #ifdef USE_DNS_FAILOVER,
arround line 987-1009. They should be changed to look for a new tm
modparam and if it is set, set dst to the invite dst (obtained from
Trans and branch).
I'll try to do it today.
Andrei