[Devel] msilo m_store

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed Oct 4 12:47:47 CEST 2006


maybe the most consistent approach will be to keep the current m_store() 
function as it is, remove the "userid_avp" module parameter and its 
functionality inside m_store() and add as you suggested a new function 
m_store_pv() / m_store_aor() which will take as parameter an PV to 
provide the AOR...

regards,
bogdan


Juha Heinanen wrote:

>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