[Users] The usrloc table, Oracle, and Asterisk

[Juan Carlos Castro y Castro]

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
>>
>>
>>
>>
>>
>>  
>>
>
>