15 Dec
2006
15 Dec
'06
4:07 p.m.
OK, now I'm trying to do something along the lines of:
if ("$hdr(expires)" > 3600) {
avp_db_query("UPDATE sip_conf SET ipaddr='$si', port='$sp',
regseconds=$Ts+$hdr(expires), useragent='$ua' WHERE name='$au'");
} else {
avp_db_query("UPDATE sip_conf SET ipaddr='$si', port='$sp',
regseconds=$Ts+3600, useragent='$ua' WHERE name='$au'");
};
But I get a syntax error at the "if". How can I do such a comparison?
Juan Carlos Castro y Castro escreveu:
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:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
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@atlanta.com>;expires=3600
>
> is equivalent to
>
> CONTACT: <sip:alice@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