[Users] ACK processing

[Bogdan-Andrei Iancu]

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
>
>  
>