[sr-dev] problem with locally generated ACKs

Andrei Pelinescu-Onciul andrei at iptel.org
Mon Dec 21 12:18:36 CET 2009


On Dec 21, 2009 at 12:17, Juha Heinanen <jh at 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



More information about the sr-dev mailing list