[Devel] msilo m_store

Juha Heinanen jh at tutpro.com
Wed Oct 4 10:42:50 CEST 2006


Bogdan-Andrei Iancu writes:

 > it sounds logic to me, so I'm for it. Maybe for backward compatibility 
 > we can have the PV parameter optional - if not present keep the current 
 > behaviour, otherwise try to look get and use the PV value.

after studying the code, i have found that m_store documentation does
not match it.  in fact, there already is a way to get receiving user's
uri from an avp:

1.3.10. userid_avp (int)

   The integer ID of an AVP which may contain the SIP URI of the
   user to whom the message was sent. It is better to store it in
   an AVP in the case of speed dial or aliases usage, so you do
   not need second processing of R-URI in failure route. The AVP
   is used ony by m_store().

   If the parameter is not set to a value different than 0, the
   module does not look for this AVP. If the value is set to a
   number different than 0, then the module expects in the AVP
   with that ID a SIP URI.

   Default value is "0". 

   Example 1-10. Set the "userid_avp" parameter
...
modparam("msilo", "userid_avp", 34)
...

after the uri is taken from the avp, there are tests like this
in the code:

	if(mode && mode[0]=='0' && puri.user.len == 0 && msg->new_uri.len > 0)

i.e., the mode business is done only if avp value didn't exist.

so in theory i could get what i need using the current code.  only
m_silo documentation would need to be clarified.  however, the current
solution is not very clean:

- useid_avp module parameter is an integer (string avps are not
  supported).
- it would be better if m_store would accept any pseudo variable from
  where uri is taken

i thought about how to preserve the current behavior and just add pseudo
variable option. so there would be two versions of m_store:

m_store(mode)
m_store(mode, pseudo_variable)

in the latter case, mode would not be used for anything and that does
not look nice.  perhaps better would be a whole new function

m_store_pv(pseudo_variable)

but that would duplicate code.

-- juha



More information about the Devel mailing list