openser.cfg 1.3 branch

Hi,

I am trying to build my OpenSER configuration by expanding openser.cfg from 1.3 branch. So far I can't exactly figure out two things in it.

1. What is the point of "exit;" on line 232 if it is preceded by "if () { } else { }" block?

Code:

204: if (has_totag()) { 207:   if (loose_route()) {        ..... 213:   } else { 231:   } 232:   exit;  <----- HOW WE CAN EVER BE HERE? 233: }

2. What is the point of "t_check_trans();" on line 245 if it is not in "if (..)" statement?

Sorry for asking perhaps dummy questions, but want to fully understand openser.cfg supplied with 1.3 before going further with my own config.

The file I am talking about above can be found here:
http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/etc/openser.cfg?revision=3542&view=markup

Thanks for help in answering my questions.

As the config is designed, messages within a dialog (e.g., that have a To tag) must have a Route header -- if not, then is a broken device or someone trying nasty things. So, drop processing it -- exit.

The second is good to absorb retransmissions.

Hi,
Thanks for reply. I was more trying to understand logical structure of sample .cfg shipped with OpenSER 1.3.

Lines 204 - 233 it is:

Code:

if (something) {   if (A)   {     do A;   }   else   {     do B;   }   exit; }

so once we are inside "something" (has_totag() in our case) we do "A" if (A) or we do "B" in ALL other cases. So logically we will NEVER reach "exit" statement - unless there is something in OpenSER control structures which I don't know/understand.

Again my question about t_check_trans() was because reading: http://www.openser.org/docs/modules/1.3.x/tm.html#AEN480 I assumed all it does is returns bool [true/false]. So why someone would like to use it without "if (t_check_trans()) { do something }" wasn't clear to me. Can you please explain bit more (or point me to documentation) how it is "good to absorb retransmissions".

Many thanks

Quote:

So logically we will NEVER reach "exit" statement

That is only true if operation A and B both exit the script by some means (relaying the message perhaps, or sending a negative response). if A and B just assign avp values or some other arbitrary task, the exit call will be reached.

Quote:

"if (t_check_trans()) { do something }" wasn't clear to me.

Well, its basically like saying "if the message is part of an existing transaction, then do some stuff, else do other stuff"