[Devel] msilo m_store
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...
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' && 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
>- 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:
>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
>but that would duplicate code.
More information about the Devel