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,
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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:
- 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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Michael,
what to do with broken hop-by-hop ACKs ? :) just drop them, otherwise they will loop on the server.
t_newtran() basically creates a new transaction. If it's ACK and it matched to an INVITE transaction, it will be silently discarded (so function will never return to script). If ACk doesn't match, the function will return; so after t_newtran() you will have only unmatched ACKs filtered out.
so,
..... if (is_method("ACK")) { #hop-by-hop ACKs are absorbed here t_newtran(); # drop broken ACKs exit; } ......
should be ok.
regards, bogdan
Michael Ulitskiy wrote:
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:
- 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
Hi Bogdan,
Yeap, I've already figured it out by experimenting. Thanks a lot for clarification. I couldn't find clear description of this tm module behavior anywhere in documentation or on the web. I think it's worth to put your replies in this thread in FAQ/documentation/etc. I find it quite confusing figuring it out on your own.
Michael
On Wednesday 27 July 2005 12:03 pm, you wrote:
Hi Michael,
what to do with broken hop-by-hop ACKs ? :) just drop them, otherwise they will loop on the server.
t_newtran() basically creates a new transaction. If it's ACK and it matched to an INVITE transaction, it will be silently discarded (so function will never return to script). If ACk doesn't match, the function will return; so after t_newtran() you will have only unmatched ACKs filtered out.
so,
..... if (is_method("ACK")) { #hop-by-hop ACKs are absorbed here t_newtran(); # drop broken ACKs exit; } ......
should be ok.
regards, bogdan
Michael Ulitskiy wrote:
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:
- 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
Hi Michael,
it will be really cool if you could add all the info related to CANCEL and ACK routing and tm behaviour into the wiki. All docs from wiki will go for sure into cvs and web docs.
thanks and regards, bogdan
Michael Ulitskiy wrote:
Hi Bogdan,
Yeap, I've already figured it out by experimenting. Thanks a lot for clarification. I couldn't find clear description of this tm module behavior anywhere in documentation or on the web. I think it's worth to put your replies in this thread in FAQ/documentation/etc. I find it quite confusing figuring it out on your own.
Michael
On Wednesday 27 July 2005 12:03 pm, you wrote:
Hi Michael,
what to do with broken hop-by-hop ACKs ? :) just drop them, otherwise they will loop on the server.
t_newtran() basically creates a new transaction. If it's ACK and it matched to an INVITE transaction, it will be silently discarded (so function will never return to script). If ACk doesn't match, the function will return; so after t_newtran() you will have only unmatched ACKs filtered out.
so,
..... if (is_method("ACK")) { #hop-by-hop ACKs are absorbed here t_newtran(); # drop broken ACKs exit; } ......
should be ok.
regards, bogdan
Michael Ulitskiy wrote:
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:
- 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
I'll try. I've never dealt with wiki before, but I'll try.
Michael
On Wednesday 27 July 2005 01:19 pm, Bogdan-Andrei Iancu wrote:
Hi Michael,
it will be really cool if you could add all the info related to CANCEL and ACK routing and tm behaviour into the wiki. All docs from wiki will go for sure into cvs and web docs.
thanks and regards, bogdan
Michael Ulitskiy wrote:
Hi Bogdan,
Yeap, I've already figured it out by experimenting. Thanks a lot for clarification. I couldn't find clear description of this tm module behavior anywhere in documentation or on the web. I think it's worth to put your replies in this thread in FAQ/documentation/etc. I find it quite confusing figuring it out on your own.
Michael
On Wednesday 27 July 2005 12:03 pm, you wrote:
Hi Michael,
what to do with broken hop-by-hop ACKs ? :) just drop them, otherwise they will loop on the server.
t_newtran() basically creates a new transaction. If it's ACK and it matched to an INVITE transaction, it will be silently discarded (so function will never return to script). If ACk doesn't match, the function will return; so after t_newtran() you will have only unmatched ACKs filtered out.
so,
..... if (is_method("ACK")) { #hop-by-hop ACKs are absorbed here t_newtran(); # drop broken ACKs exit; } ......
should be ok.
regards, bogdan
Michael Ulitskiy wrote:
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:
- 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
I must confess that first time wiki editing has been a challenge due to it doesn't work well with konqueror - my default browser of choice. It took me some time to figure it out :)
Michael
On Wednesday 27 July 2005 01:19 pm, Bogdan-Andrei Iancu wrote:
Hi Michael,
it will be really cool if you could add all the info related to CANCEL and ACK routing and tm behaviour into the wiki. All docs from wiki will go for sure into cvs and web docs.
thanks and regards, bogdan
Michael Ulitskiy wrote:
Hi Bogdan,
Yeap, I've already figured it out by experimenting. Thanks a lot for clarification. I couldn't find clear description of this tm module behavior anywhere in documentation or on the web. I think it's worth to put your replies in this thread in FAQ/documentation/etc. I find it quite confusing figuring it out on your own.
Michael
On Wednesday 27 July 2005 12:03 pm, you wrote:
Hi Michael,
what to do with broken hop-by-hop ACKs ? :) just drop them, otherwise they will loop on the server.
t_newtran() basically creates a new transaction. If it's ACK and it matched to an INVITE transaction, it will be silently discarded (so function will never return to script). If ACk doesn't match, the function will return; so after t_newtran() you will have only unmatched ACKs filtered out.
so,
..... if (is_method("ACK")) { #hop-by-hop ACKs are absorbed here t_newtran(); # drop broken ACKs exit; } ......
should be ok.
regards, bogdan
Michael Ulitskiy wrote:
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:
- 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
-
Bogdan-Andrei Iancu -
Michael Ulitskiy