26 Jul
2005
26 Jul
'05
7:18 p.m.
Bogdan,
Thanks a lot. Your replies are very useful.
Just couple more questions raised by comments.
What would I want to do with broken ACKs? I thought I'd just drop it.
Also how would I distinguish them? I don't really understand how
you use t_newtran(). Don't real ACKs still need to hit t_relay to
finish transaction?
I thought about something like the following, but so far couldn't find
a way to determine if ACK is matching transaction or not:
if (is_method("ACK")) { #hop-by-hop ACKs are absorbed here
if (in-transaction ACK) {
t_relay();
}
# lost ACKs are dropped
# .......
exit;
}
I've tried to t_lookup_request() to check if it's in transaction, but it
didn't work.
Could you please comment on it?
Thanks,
Michael
On Tuesday 26 July 2005 06:55 am, you wrote:
Hi Michael,
that's ok. only two comments:
1) all ACKs are in-dialog: ACKs for negative replies are hop-by-hop and
are the one absorbed by tm functions; the ACKs for 2xx replies are
end-to-end and are Route driven.
2) since you may have hop-by-hop ACKs (no route) which doesn't match any
transaction (broken or lost ACKs), if you want to deal with them
separately, do like this:
if (loose_route()) { #end-2-end ACKs are forwarded here
#do something
t_relay();
exit;
}
if (is_method("ACK")) { #hop-by-hop ACKs are absorbed here
t_newtran();
# deal with broken / lost ACKs
# .......
exit;
}
regards,
bogdan
Michael Ulitskiy wrote:
Thanks, Bogdan. So it's still better to
process CANCEL the same as
INVITE to avoid this race condition.
My next question is about ACK processing. In my observations if one
uses statefull processing ACKs are either loose_routed or absorbed by
t_relay(). In my test scenarios I've never seen otherwise. So, again, my
question is if the following is OK:
if (loose_route()) { #in-dialog ACKs are forwarded here
do something
t_relay();
exit;
}
if (is_method("ACK")) { #out-of-dialog ACKs are absorbed here
t_relay();
exit;
}
if (uri==myself) {
do lookups that rewrite RURI
t_relay();
}
Thank you,
Michael
On Monday 25 July 2005 07:39 am, you wrote:
>Hi Michael,
>
>that is correct. just note you may encounter some races between INVITEs
>and CANCELs in the case of a fast CANCEL (CANCEL follows the INVITE
>almost instantly) - when one process is still handling the INVITE (the
>transaction may not be build yet), another process receives the CANCEL
>and it will not be able to match it to a transaction in this case, the
>CANCEL will be forward based on its RURI without any info from INVITE.....
>
>regards,
>bogdan
>
>Michael Ulitskiy wrote:
>
>
>
>>Hello,
>>
>>I have a question about CANCEL processing.
>>I read on the mailing list that CANCEL will be automatically matched by t_relay
>>to transaction it's cancelling, if needed transformation to RURI will be
automatically
>>applied and then it will be automatically send to correct destination.
>>I'm experimenting with openser 0.10.x and it seems to be true, but I'd
like to confirm
>>that the following is OK:
>>
>>if (loose_route()) {
>>do something
>>t_relay();
>>break;
>>}
>>if (is_method("CANCEL")) {
>> t_relay();
>> break;
>>}
>>if (uri==myself) {
>>do lookups that rewrite RURI
>>t_relay();
>>}
>>
>>Thank you,
>>
>>
>>
>>
>>
>
>
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users