[Devel] ucontact flags

[Daniel-Constantin Mierla]

On 11/15/05 04:03, Juha Heinanen wrote:
> i started to work on including information on methods that a contact
> supports into location table.  i thought to add a new "methods" column
> to the table, but noticed that "flags" column already includes such
> information:
>
> /*
>  * Flags that can be associated with a Contact
>  */
> typedef enum flags {
> 	FL_NONE        = 0,          /* No flags set */
> 	FL_NAT         = 1 << 0,     /* Contact is behind NAT */
> 	FL_INVITE      = 1 << 1,     /* Contact supports INVITE and related methods */
> 	FL_N_INVITE    = 1 << 2,     /* Contact doesn't support INVITE and related methods */
> 	FL_MESSAGE     = 1 << 3,     /* Contact supports MESSAGE */
> 	FL_N_MESSAGE   = 1 << 4,     /* Contact doesn't support MESSAGE */
> 	FL_SUBSCRIBE   = 1 << 5,     /* Contact supports SUBSCRIBE and NOTIFY */
> 	FL_N_SUBSCRIBE = 1 << 6,     /* Contact doesn't support SUBSCRIBE and NOTIFY */
> 	FL_PERMANENT   = 1 << 7,     /* Permanent contact (does not expire) */
> 	FL_MEM         = 1 << 8,     /* Update memory only -- used for REGISTER replication */
> 	FL_NAT_SIPPING = 1 << 9,     /* Use SIP ping if nated */
> 	FL_ALL         = 0xFFFFFFFF  /* All flags set */
> } flags_t;
>
> the current flag values are, however, not complete.  for example,
> OPTIONS, REFER, and PRACK methods are not included.  out of curiosity, i
> did grep on FL_SUBSCRIBE and didn't find it used anywhere.
>
> so how should we proceed on this?  keep on using flags column, but make
> sure that the flags cover all methods and are also set according to
> contact methods parameter or allow header or forget the flags column and
> create a new methods column?
>
> perhaps it would be easier to keep on using the current flags column (no
> need to change location table definition), but i personally don't like
> the current flags usage.  is it really necessary to have yes and no
> information separately (consumes two flags per method)?
>
> i also found that ul_mod.c defines a configuration variable:
>
> str method_col      = {METHOD_COL, sizeof(METHOD_COL) - 1};         /*
> Name of column containing supported method */
>
> which is not used anywhere.
>   
I analyzed a bit in the last days this feature and I am of the opinion 
that a separate column is better. And we should stick to the method IDs 
defined now in openser (see "enum request_method" in 
parser/msg_parser.h), they are bitmap flags and is easier to check them, 
and matches the result of parse_methods(). There is a special processing 
for unknown methods, we have to think of, e.g: in REGISTER the client 
advertise ASD method which will set METHOD_OTHER flag and if someone 
wants to send ZXC which also sets METHOD_OTHER, but is different than ASD.

A limitation will come when the number of methods will exceeds 31, but I 
think there is enough space at this moment.

In the flags attribute should be kept the information whether to check 
the methods or not.

Daniel
> -- juha
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>
>