Hi all, I'm in doubt of the means of setflag()'s parameter. I have looked for it everywhere including internet and the ser source code, but no any docs explained it in detail. can anybody tell me about it ?
On 07/05/2010 09:59 PM, zhou tianjun wrote:
I'm in doubt of the means of setflag()'s parameter. I have looked for it everywhere including internet and the ser source code, but no any docs explained it in detail. can anybody tell me about it ?
It sets bits in a 32-bit integer (it may be 64-bit on 64-bit platforms, of this I am not sure) that is bound to a transaction, so those "flags" may be accessed in requests and replies associated with a given transaction, or, further down in the execution flow of same message handler.
It is precisely equivalent to the way bit vectors are used in general-purpose programming languages, e.g.
int flags = 0;
flags |= (1 << 4); /* Set bit 4 */
if(flags & (1 << 4)) { printf("Bit 4 is set!\n"); } else { printf("Bit 4 is not set!\n"); }
/* If bit 4 is set, unset it */
if(flags & (1 << 4)) flags &= ~(1 << 4);
Hello,
here is a wiki page with some flag bitmask vector examples that might help: http://www.kamailio.org/dokuwiki/doku.php/tutorials:openser-flag-operations
The cfg file examples are for older kamailio versions.
Cheers, Daniel
On 7/6/10 4:02 AM, Alex Balashov wrote:
On 07/05/2010 09:59 PM, zhou tianjun wrote:
I'm in doubt of the means of setflag()'s parameter. I have looked for it everywhere including internet and the ser source code, but no any docs explained it in detail. can anybody tell me about it ?
It sets bits in a 32-bit integer (it may be 64-bit on 64-bit platforms, of this I am not sure) that is bound to a transaction, so those "flags" may be accessed in requests and replies associated with a given transaction, or, further down in the execution flow of same message handler.
It is precisely equivalent to the way bit vectors are used in general-purpose programming languages, e.g.
int flags = 0; flags |= (1 << 4); /* Set bit 4 */ if(flags & (1 << 4)) { printf("Bit 4 is set!\n"); } else { printf("Bit 4 is not set!\n"); } /* If bit 4 is set, unset it */ if(flags & (1 << 4)) flags &= ~(1 << 4);
Daniel,
Based on this, I think I was erroneous in suggesting that plain flags (setflag, isflagset) are transaction-associated. They seem to be message-associated, not transaction. Is this right?
Thanks,
-- Alex
On 07/06/2010 04:05 AM, Daniel-Constantin Mierla wrote:
Hello,
here is a wiki page with some flag bitmask vector examples that might help: http://www.kamailio.org/dokuwiki/doku.php/tutorials:openser-flag-operations
The cfg file examples are for older kamailio versions.
Cheers, Daniel
On 7/6/10 4:02 AM, Alex Balashov wrote:
On 07/05/2010 09:59 PM, zhou tianjun wrote:
I'm in doubt of the means of setflag()'s parameter. I have looked for it everywhere including internet and the ser source code, but no any docs explained it in detail. can anybody tell me about it ?
It sets bits in a 32-bit integer (it may be 64-bit on 64-bit platforms, of this I am not sure) that is bound to a transaction, so those "flags" may be accessed in requests and replies associated with a given transaction, or, further down in the execution flow of same message handler.
It is precisely equivalent to the way bit vectors are used in general-purpose programming languages, e.g.
int flags = 0;
flags |= (1 << 4); /* Set bit 4 */
if(flags & (1 << 4)) { printf("Bit 4 is set!\n"); } else { printf("Bit 4 is not set!\n"); }
/* If bit 4 is set, unset it */
if(flags & (1 << 4)) flags &= ~(1 << 4);
Hello,
On 7/6/10 10:16 AM, Alex Balashov wrote:
Daniel,
Based on this, I think I was erroneous in suggesting that plain flags (setflag, isflagset) are transaction-associated. They seem to be message-associated, not transaction. Is this right?
in first place is associated to message, then inherited to transaction (when that is created) and kept for the life of the transaction. So both associations are true, of course, a matter of whether the transaction was created or not at respective time.
Cheers, Daniel
Thanks,
-- Alex
On 07/06/2010 04:05 AM, Daniel-Constantin Mierla wrote:
Hello,
here is a wiki page with some flag bitmask vector examples that might help: http://www.kamailio.org/dokuwiki/doku.php/tutorials:openser-flag-operations
The cfg file examples are for older kamailio versions.
Cheers, Daniel
On 7/6/10 4:02 AM, Alex Balashov wrote:
On 07/05/2010 09:59 PM, zhou tianjun wrote:
I'm in doubt of the means of setflag()'s parameter. I have looked for it everywhere including internet and the ser source code, but no any docs explained it in detail. can anybody tell me about it ?
It sets bits in a 32-bit integer (it may be 64-bit on 64-bit platforms, of this I am not sure) that is bound to a transaction, so those "flags" may be accessed in requests and replies associated with a given transaction, or, further down in the execution flow of same message handler.
It is precisely equivalent to the way bit vectors are used in general-purpose programming languages, e.g.
int flags = 0;
flags |= (1 << 4); /* Set bit 4 */
if(flags & (1 << 4)) { printf("Bit 4 is set!\n"); } else { printf("Bit 4 is not set!\n"); }
/* If bit 4 is set, unset it */
if(flags & (1 << 4)) flags &= ~(1 << 4);
On 07/06/2010 04:24 AM, Daniel-Constantin Mierla wrote:
On 7/6/10 10:16 AM, Alex Balashov wrote:
Daniel,
Based on this, I think I was erroneous in suggesting that plain flags (setflag, isflagset) are transaction-associated. They seem to be message-associated, not transaction. Is this right?
in first place is associated to message, then inherited to transaction (when that is created) and kept for the life of the transaction. So both associations are true, of course, a matter of whether the transaction was created or not at respective time.
Oh, I see. The documentation on the dokuwiki suggests they are only message-association.
I was pretty sure I had used flags in a transaction-bound way at some point when I wrote the original response. However, I did not remember for sure because I tend to use variables for almost everything transaction-associated these days just due to the nature of the data in most cases.
On 7/6/10 10:32 AM, Alex Balashov wrote:
On 07/06/2010 04:24 AM, Daniel-Constantin Mierla wrote:
On 7/6/10 10:16 AM, Alex Balashov wrote:
Daniel,
Based on this, I think I was erroneous in suggesting that plain flags (setflag, isflagset) are transaction-associated. They seem to be message-associated, not transaction. Is this right?
in first place is associated to message, then inherited to transaction (when that is created) and kept for the life of the transaction. So both associations are true, of course, a matter of whether the transaction was created or not at respective time.
Oh, I see. The documentation on the dokuwiki suggests they are only message-association.
I was pretty sure I had used flags in a transaction-bound way at some point when I wrote the original response. However, I did not remember for sure because I tend to use variables for almost everything transaction-associated these days just due to the nature of the data in most cases.
Probably would be good to improve the page a bit, is pretty old.
I found this statement:
"They provide a very easy and fast way of keeping states during processing a request or during a transcation, if Kamailio (OpenSER) is in stateful mode."
but none that says is for request only.
Cheers, Daniel
On Jul 06, 2010 at 10:24, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 7/6/10 10:16 AM, Alex Balashov wrote:
Daniel,
Based on this, I think I was erroneous in suggesting that plain flags (setflag, isflagset) are transaction-associated. They seem to be message-associated, not transaction. Is this right?
in first place is associated to message, then inherited to transaction (when that is created) and kept for the life of the transaction. So both associations are true, of course, a matter of whether the transaction was created or not at respective time.
Not exactly, the flags are updated at t_relay() time, even if the transaction was created before by t_newtran(). E.g.:
flags a, b;
setflag(a); t_newtran(); setflag(b); t_on_failure("failure_route"); t_on_reply("reply_route"); t_relay(); => both a & b will be set in the reply_route or failure_route.
Andrei
On 7/6/10 11:34 AM, Andrei Pelinescu-Onciul wrote:
On Jul 06, 2010 at 10:24, Daniel-Constantin Mierlamiconda@gmail.com wrote:
Hello,
On 7/6/10 10:16 AM, Alex Balashov wrote:
Daniel,
Based on this, I think I was erroneous in suggesting that plain flags (setflag, isflagset) are transaction-associated. They seem to be message-associated, not transaction. Is this right?
in first place is associated to message, then inherited to transaction (when that is created) and kept for the life of the transaction. So both associations are true, of course, a matter of whether the transaction was created or not at respective time.
Not exactly, the flags are updated at t_relay() time, even if the transaction was created before by t_newtran(). E.g.:
flags a, b;
setflag(a); t_newtran(); setflag(b); t_on_failure("failure_route"); t_on_reply("reply_route"); t_relay();=> both a& b will be set in the reply_route or failure_route.
right, maybe my phrasing was not clear. I wanted to mean that when the transaction is created the flags become associated to the transaction - they can be updated afterwards (e.g., failure/onreply route as well).
Cheers, Daniel
On Jul 06, 2010 at 10:05, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
here is a wiki page with some flag bitmask vector examples that might help: http://www.kamailio.org/dokuwiki/doku.php/tutorials:openser-flag-operations
The cfg file examples are for older kamailio versions.
Indeed.
The flags support names (you don't have to deal with flag numbers by hand any longer).
E.g.:
flags test, a, b;
route { #.... setflag(test); if (isflagset(a)) { ... } }
One could also force a specific mapping between a flag name and the actual flag "number" used, e.g.:
flags a:1, b:2 ;
Andrei
On 7/6/10 4:02 AM, Alex Balashov wrote:
On 07/05/2010 09:59 PM, zhou tianjun wrote:
I'm in doubt of the means of setflag()'s parameter. I have looked for it everywhere including internet and the ser source code, but no any docs explained it in detail. can anybody tell me about it ?
It sets bits in a 32-bit integer (it may be 64-bit on 64-bit platforms, of this I am not sure) that is bound to a transaction, so those "flags" may be accessed in requests and replies associated with a given transaction, or, further down in the execution flow of same message handler.
It is precisely equivalent to the way bit vectors are used in general-purpose programming languages, e.g.
int flags = 0;
flags |= (1 << 4); /* Set bit 4 */
if(flags & (1 << 4)) { printf("Bit 4 is set!\n"); } else { printf("Bit 4 is not set!\n"); }
/* If bit 4 is set, unset it */
if(flags & (1 << 4)) flags &= ~(1 << 4);
-- Daniel-Constantin Mierla http://www.asipto.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2010/7/6 Alex Balashov abalashov@evaristesys.com:
It sets bits in a 32-bit integer (it may be 64-bit on 64-bit platforms, of this I am not sure)
Hi, could it be clarified please? I also wonder how many integer AVP's (i:N) can exist. Does it depend on the 32/64 bits architecture?
Thanks.
On Jul 06, 2010 at 10:43, Iñaki Baz Castillo ibc@aliax.net wrote:
2010/7/6 Alex Balashov abalashov@evaristesys.com:
It sets bits in a 32-bit integer (it may be 64-bit on 64-bit platforms, of this I am not sure)
Hi, could it be clarified please? I also wonder how many integer AVP's (i:N) can exist. Does it depend on the 32/64 bits architecture?
The flags are stored internally on 32 bits, but you should use names for the flags so you shouldn't care (unless you use more then 32 :-)).
There is no limit on the number of AVPs, but the I:N format is deprecated (use only names).
Andrei
2010/7/6 Andrei Pelinescu-Onciul andrei@iptel.org:
Hi, could it be clarified please? I also wonder how many integer AVP's (i:N) can exist. Does it depend on the 32/64 bits architecture?
The flags are stored internally on 32 bits, but you should use names for the flags so you shouldn't care (unless you use more then 32 :-)).
There is no limit on the number of AVPs, but the I:N format is deprecated (use only names).
Thanks.
On 7/6/10 11:49 AM, Iñaki Baz Castillo wrote:
2010/7/6 Andrei Pelinescu-Onciulandrei@iptel.org:
Hi, could it be clarified please? I also wonder how many integer AVP's (i:N) can exist. Does it depend on the 32/64 bits architecture?
The flags are stored internally on 32 bits, but you should use names for the flags so you shouldn't care (unless you use more then 32 :-)).
There is no limit on the number of AVPs, but the I:N format is deprecated (use only names).
Thanks.
was your question how many avps with ID N can be or how many distinct N you can have?
Haven't check if has changed in SER 2.0 (therefore in 3.0 as well), but in K 1.x and older S the ID was short int (16b), so N can be any number from 1 to 2^16-1.
Cheers, Daniel
2010/7/6 Daniel-Constantin Mierla miconda@gmail.com:
was your question how many avps with ID N can be or how many distinct N you can have?
Haven't check if has changed in SER 2.0 (therefore in 3.0 as well), but in K 1.x and older S the ID was short int (16b), so N can be any number from 1 to 2^16-1.
My question was about the max number of N in avp(i:N). I expected that the max numbers of ID N avps is N. Anyhow my question was about K 1.5 as I know that in 3.X there are changes in AVP indexing syntax.
Thanks.
On 7/6/10 12:07 PM, Iñaki Baz Castillo wrote:
2010/7/6 Daniel-Constantin Mierlamiconda@gmail.com:
was your question how many avps with ID N can be or how many distinct N you can have?
Haven't check if has changed in SER 2.0 (therefore in 3.0 as well), but in K 1.x and older S the ID was short int (16b), so N can be any number from 1 to 2^16-1.
My question was about the max number of N in avp(i:N). I expected that the max numbers of ID N avps is N.
hmm, unless I misunderstand you, this is wrong.
Say N=10, then you can have as many $avp(i:10) as you want -- is no limit.
For example:
$avp(i:10) = 50; $avp(i:10) = 60; $avp(i:10) = 70; $avp(i:10) = 80;
results in 4 avps having same name (i:10) and different values.
Cheers, Daniel
Anyhow my question was about K 1.5 as I know that in 3.X there are changes in AVP indexing syntax.
Thanks.
2010/7/6 Daniel-Constantin Mierla miconda@gmail.com:
My question was about the max number of N in avp(i:N). I expected that the max numbers of ID N avps is N.
hmm, unless I misunderstand you, this is wrong.
Say N=10, then you can have as many $avp(i:10) as you want -- is no limit.
For example:
$avp(i:10) = 50; $avp(i:10) = 60; $avp(i:10) = 70; $avp(i:10) = 80;
results in 4 avps having same name (i:10) and different values.
I mean the indexes and not the values. My question was (related to K 1.5) which is the max value of an AVP index, is it 32 so we can use from avp(i:1) to avo(i:32)? is it 64 (so it would depend on the CPU architecture)? But from your previous mail I understand the maximun value is 65535, am I right?
Thanks.
-
Alex Balashov -
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
zhou tianjun