[Users] ACK processing

[Michael Ulitskiy]

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 at openser.org
> >http://openser.org/cgi-bin/mailman/listinfo/users
> >
> >  
> >
> 
>