[Users] The usrloc table, Oracle, and Asterisk

[Juan Carlos Castro y Castro]

Argh. I can't use avp_db_query from inside an on_reply_route. What do I do?

Dec 15 10:55:32 vntst2 openser: parse error (109,18-19): Command cannot 
be used in the block

Juan Carlos Castro y Castro escreveu:
> Any way I could catch the final OK message instead of the REGISTER 
> message? Right now, I'm using the code below. Now I see that's not 
> good because I get the Expires from the client which may be higher 
> than the real Expires.
>
>        if( method=="REGISTER" ) {
>                if (!www_authorize("myrealm", "sip_conf")) {
>                        www_challenge("myrealm", "0");
>                        exit;
>                };
>
>                save("location");
>                avp_db_query("UPDATE sipfriends SET ipaddr='$si', 
> port='$sp', regseconds=$Ts+$hdr(expires), useragent='$ua' WHERE 
> name='$au'");
>                exit;
>        };
>
>
> Bogdan-Andrei Iancu escreveu:
>> Hi Jerome,
>>
>> you are right - a server may change the expire advertised by the 
>> client. If it is the case or not, it's a matter of configuration in 
>> OpenSER - see the min_expires and max_expires in the registrar module.
>>    http://www.openser.org/docs/modules/1.2.x/registrar.html
>>
>> if this params are not set, there is no risk of using the value 
>> advertised by the client.
>>
>> regards,
>> bogdan
>>
>> Jerome Martin wrote:
>>
>>> On Thu, 2006-12-14 at 17:32 -0200, Juan Carlos Castro y Castro wrote:
>>>  
>>>
>>>> Forget I said that! There's $Ts + $hdr("Expires")! That'll teach me 
>>>> to always RTFA before answering!
>>>>   
>>>
>>> Well, you need to be carefull about $hdr("Expires"). This is NOT the
>>> only way a UA can specify an expiration delay for a REGISTER request.
>>>
>>> If you take a look at the relevant parts of rfc3261
>>> ( http://www.ietf.org/rfc/rfc3261.txt ), you'll see that using an
>>> Expires header is only one way of specifying a desired expired duration
>>> for the REGISTER. The other way is by using a Contact header parameter
>>> (page 60 of the rfc) :
>>>
>>>  
>>>
>>>> 10.2.1.1 Setting the Expiration Interval of Contact Addresses
>>>>
>>>>   When a client sends a REGISTER request, it MAY suggest an expiration
>>>>   interval that indicates how long the client would like the
>>>>   registration to be valid.  (As described in Section 10.3, the
>>>>   registrar selects the actual time interval based on its local
>>>>   policy.)
>>>>
>>>>   There are two ways in which a client can suggest an expiration
>>>>   interval for a binding: through an Expires header field or an
>>>>   "expires" Contact header parameter.  The latter allows expiration
>>>>   intervals to be suggested on a per-binding basis when more than one
>>>>   binding is given in a single REGISTER request, whereas the former
>>>>   suggests an expiration interval for all Contact header field values
>>>>   that do not contain the "expires" parameter.
>>>>   
>>>
>>> Also note that the expire parameter to a Contact header is totally 
>>> case-unsensitive ( page 32 of the RFC) :
>>>
>>>
>>>  
>>>
>>>>   When comparing header fields, field names are always case-
>>>>   insensitive.  Unless otherwise stated in the definition of a
>>>>   particular header field, field values, parameter names, and 
>>>> parameter
>>>>   values are case-insensitive.  Tokens are always case-insensitive.
>>>>   Unless specified otherwise, values expressed as quoted strings are
>>>>   case-sensitive.  For example,
>>>>
>>>>      Contact: <sip:alice at atlanta.com>;expires=3600
>>>>
>>>>   is equivalent to
>>>>
>>>>      CONTACT: <sip:alice at atlanta.com>;ExPiReS=3600
>>>>   
>>>
>>> A good example of a very popular SIP UA always using the Contact 
>>> header parameter method is the Linksys PAP2 ATA. On the other hand, 
>>> there are also
>>> many popular ATAs that use the Expires header method, i.e. 
>>> Audiocodes MP1XX ATAs. So unless you're in a very controlled 
>>> environment and you don't
>>> care at all to be generic and RFC3261-compliant, you must support 
>>> both. But
>>> be carefull, in my experience this almost always bites you back one 
>>> day or the other.
>>>
>>> Hope this helps,
>>> Best Regards,
>>>
>>> Jérôme Martin
>>>
>>>
>>>
>>>
>>>
>>>  
>>>
>>
>>
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>