Hi Elias,
indeed the build_dlg_ack() was specially designed to build acks for 2xx
replies and not for negative replies - and there are different building
algorithms....
please post this bug on the tracker and I will take care of it.
thanks and regards,
bogdan
Elias Baixas wrote:
Hi all,
I was referring to send_ack for local transactions, where
build_dlg_ack() is used (I thought I had told it, but now I see it
slipped off my mind !! sorry :P)
thanks,
Elias
On Tue, 2006-04-18 at 11:34, Bogdan-Andrei Iancu wrote:
Hi Elias,
not sure which part of code you are referring to. If you look to
send_ack(), for non local transactions, build_local() is used for
building the ACK....and this function uses the send URI of the
corresponding branch (Trans->uac[branch].uri.len) - as in RFC 3261.
try to give me more hints about the location of the code to you are
referring to (starting from send_ack() ).
regards,
bogdan
elias wrote:
Hi all, I've been looking at the source code in "send_ack" in
(tm/t_reply.c) and I've found that for local transactions, the ACK's
request-URI is created from the Route-Set (if it exists) or from
Contact (if no route-set), although section 17.1.1.3 (construction of
the ACK request) in 3261 says that the ACK must have the same
request-URI,From and Call-ID headers as the original INVITE. So the
request-URI should be taken from the transaction buffer
(t->uac[0].request).
I've found that changing
process_routeset(rpl,&contact,&list,&ruri,&next_hop)
to
process_routeset(rpl,&Trans->uac[0].uri,&list,&ruri,&next_hop)
and then
if ((contact.s != ruri.s) || (contact.len != ruri.len)) {
to
if ((Trans->uac[0].uri.s != ruri.s) || (Trans->uac[0].uri.len !=
ruri.len)) {
fixes this behavior. I dont know if this breaks som
2543-compatibility... but I think not, because if the next hop is a
strict-router, then (Trans->uac[0].uri.s != ruri.s) will be true, so
the contact-uri will be appended at the end of the Route list.
best regards,
Elias Baixas
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
