[Users] The usrloc table, Oracle, and Asterisk

[Juan Carlos Castro y Castro]

I gave up and let Oracle deal with the "if". Alas, it doesn't have a 
neat IIF(cond,expr1,expr2) function. Instead, I had to use the unholy 
monstrosity below. But it works. Now let me see if at least I can refine 
it so there isn't "3600" written all over the place.

avp_db_query("UPDATE sip_conf SET ipaddr='$si', port='$sp', 
regseconds=$Ts+decode(($hdr(expires)-3600)-abs($hdr(expires)-3600), 0, 
3600, $hdr(expires)), useragent='$ua' WHERE name='$au'");

FUGLY, ain't it?

Bogdan-Andrei Iancu escreveu:
> Hi,
>
> you cannot catch the reply from REGISTER as it is statelessly sent by 
> the save() function. Also you cannot use avps in reply_route because 
> of lack of synchronization - this route is not locked when executed, 
> and it can be processed in parallel for multiple received replies.
>
> regards,
> bogdan
>
> Juan Carlos Castro y Castro wrote:
>
>> 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
>>>
>>
>>
>
>