I'm working on an Asterisk+OpenSER setup and I am in the process of implementing the following: registration has to be handled by OpenSER, but it has to be recognized by Asterisk. For that purpose, OpenSER is authenticating against Asterisk's "sipfriends" realtime table. That works OK. But OpenSER should also update fields "ipaddr", "port", and "regseconds" in the same table, or else Asterisk won't be able to direct calls to the logged SIP phones.
I'm thinking of implementing an Oracle trigger (or rather asking the Oracle DBA to do that) so all updates/inserts into the location table will cause updates in sipfriends. As far as I know, I need to take the IP and port from the "contact" field of the location table. Or should I use the "received" field? In my tests, the "received" field gets set to NULL, although "contact" has the info I need. Can I use the data from "contact" always?
For the regseconds field, I'll just have to make a conversion from the local time format (used by the "expires" field of location) to the unix timestamp format (used by "regseconds" in Asterisk).
Oh, by the way, this is the location table definition that worked OK with Oracle. I had to ask for a login trigger so the date fields would accept the 'YYYY-MM-DD HH:MM:SS' format. Also, Oracle refuses to accept an empty string as a non-null value.
CREATE TABLE location ( username varchar2(64) DEFAULT '', domain varchar2(128) DEFAULT 'vono.net.br', contact varchar2(255) DEFAULT '', received varchar2(255) DEFAULT '', path varchar2(255) DEFAULT '', expires date DEFAULT '2020-05-28 21:32:15' NOT NULL, q decimal(10,2) DEFAULT 1.0 NOT NULL, callid varchar2(255) DEFAULT 'Default-Call-ID' NOT NULL, cseq int DEFAULT 42 NOT NULL, last_modified date DEFAULT '1900-01-01 00:00' NOT NULL, flags int DEFAULT 0 NOT NULL, user_agent varchar2(255) DEFAULT '', socket varchar2(128) DEFAULT '', methods int DEFAULT NULL, PRIMARY KEY(username, domain, contact) );
Hi Juan,
OpenSER and Asterisk is quite a hot topic and I see interesting and useful information on your email. You can refer to the wiki page : http://openser.org/dokuwiki/doku.php to see or share info from/with other users.
now, regarding your question regarding "contact" and "received".
first of all, instead of using Oracle triggers you can log this info directly from OpenSER using avp_db_query http://www.openser.org/docs/modules/1.2.x/avpops.html#AEN268 and pseudo-variables to get the src_ip ($si), src_port ($sp) and expire header. See http://www.openser.org/dokuwiki/doku.php/pseudovariables:devel
otherwise, using triggers, you need to look to the "contact" and "received" columns in location. "contact" contains the received contact and "received" the source addr of the REGISTER - used in nat scenarios, where contact has private IPs. so,it depends of your OpenSER cfg, if received is or not populated (via fix_natted_registrar function). Anyhow, first you should try to use received and if empty, use contact. or, if no nat, just use contact.
regards, bogdan
Juan Carlos Castro y Castro wrote:
I'm working on an Asterisk+OpenSER setup and I am in the process of implementing the following: registration has to be handled by OpenSER, but it has to be recognized by Asterisk. For that purpose, OpenSER is authenticating against Asterisk's "sipfriends" realtime table. That works OK. But OpenSER should also update fields "ipaddr", "port", and "regseconds" in the same table, or else Asterisk won't be able to direct calls to the logged SIP phones.
I'm thinking of implementing an Oracle trigger (or rather asking the Oracle DBA to do that) so all updates/inserts into the location table will cause updates in sipfriends. As far as I know, I need to take the IP and port from the "contact" field of the location table. Or should I use the "received" field? In my tests, the "received" field gets set to NULL, although "contact" has the info I need. Can I use the data from "contact" always?
For the regseconds field, I'll just have to make a conversion from the local time format (used by the "expires" field of location) to the unix timestamp format (used by "regseconds" in Asterisk).
Oh, by the way, this is the location table definition that worked OK with Oracle. I had to ask for a login trigger so the date fields would accept the 'YYYY-MM-DD HH:MM:SS' format. Also, Oracle refuses to accept an empty string as a non-null value.
CREATE TABLE location ( username varchar2(64) DEFAULT '', domain varchar2(128) DEFAULT 'vono.net.br', contact varchar2(255) DEFAULT '', received varchar2(255) DEFAULT '', path varchar2(255) DEFAULT '', expires date DEFAULT '2020-05-28 21:32:15' NOT NULL, q decimal(10,2) DEFAULT 1.0 NOT NULL, callid varchar2(255) DEFAULT 'Default-Call-ID' NOT NULL, cseq int DEFAULT 42 NOT NULL, last_modified date DEFAULT '1900-01-01 00:00' NOT NULL, flags int DEFAULT 0 NOT NULL, user_agent varchar2(255) DEFAULT '', socket varchar2(128) DEFAULT '', methods int DEFAULT NULL, PRIMARY KEY(username, domain, contact) );
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu escreveu:
first of all, instead of using Oracle triggers you can log this info directly from OpenSER using avp_db_query http://www.openser.org/docs/modules/1.2.x/avpops.html#AEN268 and pseudo-variables to get the src_ip ($si), src_port ($sp) and expire header. See http://www.openser.org/dokuwiki/doku.php/pseudovariables:devel
That's cool (and a nice thing to know for future projects), but I still have the regseconds problem. I can't get that from pseudovariables. Seems I'm stuck with triggers. But what you say next DOES eliminate a nagging doubt I had:
otherwise, using triggers, you need to look to the "contact" and "received" columns in location. "contact" contains the received contact and "received" the source addr of the REGISTER - used in nat scenarios, where contact has private IPs. so,it depends of your OpenSER cfg, if received is or not populated (via fix_natted_registrar function). Anyhow, first you should try to use received and if empty, use contact. or, if no nat, just use contact.
No NAT here, so I can use contact only and be happy (the DBA is miffed enough about the trigger as it is!)
Many many thanks, Juan
Forget I said that! There's $Ts + $hdr("Expires")! That'll teach me to always RTFA before answering!
Juan Carlos Castro y Castro escreveu:
I still have the regseconds problem. I can't get that from pseudovariables. Seems I'm stuck with triggers. But what you say next DOES eliminate a nagging doubt I had:
otherwise, using triggers, you need to look to the "contact" and "received" columns in location. "contact" contains the received contact and "received" the source addr of the REGISTER - used in nat scenarios, where contact has private IPs. so,it depends of your OpenSER cfg, if received is or not populated (via fix_natted_registrar function). Anyhow, first you should try to use received and if empty, use contact. or, if no nat, just use contact.
No NAT here, so I can use contact only and be happy (the DBA is miffed enough about the trigger as it is!)
Many many thanks, Juan
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
On Thu, 2006-12-14 at 21:41 +0100, Jerome Martin wrote:
Contact: <sip:alice@atlanta.com>;expires=3600
is equivalent to
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
I mentionned the fact that the header parameters are case-insensitive, but as this example shows, headers themselves are. I'm not sure that $hdr("Foobar") is equivalent to $hdr("FooBar"). I would guess that static pseudo variables would handle this, but not for $hdr(XXX).
Bogdan, do you have the answer in mind or should I take a look at the code ? If that's not the case, then maybe that would be an interesting feature request for 1.2.0 ...
Regards, Jerome
Hi Jerome,
the case sensitivity is automatically taken care by opense's pseudo variables. First of all, for the known (recognizable) headers, the name is replaced with an integer id at startup, so at runtime only an integer comparison is done. For the rest of the headers, a case insensitive string comparison is done.
so, this should not be an issue.
regards, bogdan
Jerome Martin wrote:
On Thu, 2006-12-14 at 21:41 +0100, Jerome Martin wrote:
Contact: <sip:alice@atlanta.com>;expires=3600
is equivalent to
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
I mentionned the fact that the header parameters are case-insensitive, but as this example shows, headers themselves are. I'm not sure that $hdr("Foobar") is equivalent to $hdr("FooBar"). I would guess that static pseudo variables would handle this, but not for $hdr(XXX).
Bogdan, do you have the answer in mind or should I take a look at the code ? If that's not the case, then maybe that would be an interesting feature request for 1.2.0 ...
Regards, Jerome
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On Fri, 2006-12-15 at 10:55 +0200, Bogdan-Andrei Iancu wrote:
the case sensitivity is automatically taken care by opense's pseudo variables. First of all, for the known (recognizable) headers, the name is replaced with an integer id at startup, so at runtime only an integer comparison is done. For the rest of the headers, a case insensitive string comparison is done.
Excellent. I was pretty sure for known headers, but not as positive for string headers. This is good news :-)
Thanks for the answer !
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@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
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@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
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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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:
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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On Fri, 2006-12-15 at 12:07 -0200, Juan Carlos Castro y Castro wrote:
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?
Take a look at avpcheck() :
http://www.openser.org/docs/modules/1.1.x/avpops.html#AEN384
Jerome Martin escreveu:
On Fri, 2006-12-15 at 12:07 -0200, Juan Carlos Castro y Castro wrote:
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?
Take a look at avpcheck() :
OK, now I'm doing the following, but the "if" always yields false regardless of the passed Expires value. At first I thought the problem was interpreting values as strings, but in that case it would yield true for an Expires of zero. It doesn't. Could it be some flags problem? Using "/g" at the end does no good.
if (avp_check("$hdr(expires)","lt/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'"); };
I also tried writing the value to an AVP beforehand. Still always false:
avp_write("$hdr(expires)","$avp(i:777)"); if (avp_check("$avp(i:777)","lt/3600/g")) { 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'"); };
Hello,
could you rint the value of the Expires header and see what you get? Try:
xlog("Expires header is [$hdr(expires)]\n");
Cheers, Daniel
On 12/15/06 18:29, Juan Carlos Castro y Castro wrote:
Jerome Martin escreveu:
On Fri, 2006-12-15 at 12:07 -0200, Juan Carlos Castro y Castro wrote:
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?
Take a look at avpcheck() :
OK, now I'm doing the following, but the "if" always yields false regardless of the passed Expires value. At first I thought the problem was interpreting values as strings, but in that case it would yield true for an Expires of zero. It doesn't. Could it be some flags problem? Using "/g" at the end does no good.
if (avp_check("$hdr(expires)","lt/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'"); };
I also tried writing the value to an AVP beforehand. Still always false:
avp_write("$hdr(expires)","$avp(i:777)"); if (avp_check("$avp(i:777)","lt/3600/g")) { 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'"); };
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Dear friends,
when I refresh the PUBLISH message, the openser send a NOTIFY to the watchers, but, don't send the notes of the original PUBLISH.
how to make that openser send in a NOTIFY the notes of the last PUBLISH ? best regards Lou
Hello,
could you get the latest CVS version of branch rel_1_1_0 and try again? There was an issue with string lengths and return code of strncasecmp() for '<' and '>' operators in string comparisons.
Thanks, Daniel
On 12/15/06 18:47, Juan Carlos Castro y Castro wrote:
Expires header is [300]
Daniel-Constantin Mierla escreveu:
Hello,
could you rint the value of the Expires header and see what you get? Try:
xlog("Expires header is [$hdr(expires)]\n");
Cheers, Daniel
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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu escreveu:
first of all, instead of using Oracle triggers you can log this info directly from OpenSER using avp_db_query http://www.openser.org/docs/modules/1.2.x/avpops.html#AEN268 and pseudo-variables to get the src_ip ($si), src_port ($sp) and expire header. See http://www.openser.org/dokuwiki/doku.php/pseudovariables:devel
avp_db_query("UPDATE sipfriends SET ipaddr='$si', port='$sp', regseconds=$Ts+$hdr(expires) WHERE name='$au'");
makes me a happy man! Unified registry for OpenSER and Asterisk. Y-EAH!
Did you see my answer to "he usrloc table, Oracle, and Asterisk" ?
On Thu, 2006-12-14 at 18:47 -0200, Juan Carlos Castro y Castro wrote:
Bogdan-Andrei Iancu escreveu:
first of all, instead of using Oracle triggers you can log this info directly from OpenSER using avp_db_query http://www.openser.org/docs/modules/1.2.x/avpops.html#AEN268 and pseudo-variables to get the src_ip ($si), src_port ($sp) and expire header. See http://www.openser.org/dokuwiki/doku.php/pseudovariables:devel
avp_db_query("UPDATE sipfriends SET ipaddr='$si', port='$sp', regseconds=$Ts+$hdr(expires) WHERE name='$au'");
makes me a happy man! Unified registry for OpenSER and Asterisk. Y-EAH!
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
How usrloc handle the expire? it supports both Expire header and contact expires "field"?
If openser handle this, you could do an avp_db_query() selecting the expere field from usrloc saving it to an avp, and than use this avp to do the update on sipfriends?
theres a little overhead, but you will got the rigth expire value.
On Thu, 2006-12-14 at 21:49 +0100, Jerome Martin wrote:
Did you see my answer to "he usrloc table, Oracle, and Asterisk" ?
On Thu, 2006-12-14 at 18:47 -0200, Juan Carlos Castro y Castro wrote:
Bogdan-Andrei Iancu escreveu:
first of all, instead of using Oracle triggers you can log this info directly from OpenSER using avp_db_query http://www.openser.org/docs/modules/1.2.x/avpops.html#AEN268 and pseudo-variables to get the src_ip ($si), src_port ($sp) and expire header. See http://www.openser.org/dokuwiki/doku.php/pseudovariables:devel
avp_db_query("UPDATE sipfriends SET ipaddr='$si', port='$sp', regseconds=$Ts+$hdr(expires) WHERE name='$au'");
makes me a happy man! Unified registry for OpenSER and Asterisk. Y-EAH!
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Lúcio Fernando Maciel Telecom South America R. Ramiro D'Ávilla, 20 sala 306 Porto Alegre - RS - Brasil lucio@tesatelecom.com +55 (51) 3061-5569 +55 (51) 8442-1079
I guess I could do that, but I'd have to resuscitate the location table, which I'd love not to be necessary (performance). The best thing would be a pseudovariable ($ex?) that computes that depending on the contents of both headers. That's why I'm changing the subject to "wishlist".
Lucio Maciel escreveu:
How usrloc handle the expire? it supports both Expire header and contact expires "field"?
If openser handle this, you could do an avp_db_query() selecting the expere field from usrloc saving it to an avp, and than use this avp to do the update on sipfriends?
theres a little overhead, but you will got the rigth expire value.
If you have some time, the Asterisk - OpenSER integration section of the dokuwiki would really benefit from a tutorial about this.
Mike
On Thursday 14 December 2006 03:47, Juan Carlos Castro y Castro wrote:
Bogdan-Andrei Iancu escreveu:
first of all, instead of using Oracle triggers you can log this info directly from OpenSER using avp_db_query http://www.openser.org/docs/modules/1.2.x/avpops.html#AEN268 and pseudo-variables to get the src_ip ($si), src_port ($sp) and expire header. See http://www.openser.org/dokuwiki/doku.php/pseudovariables:devel
avp_db_query("UPDATE sipfriends SET ipaddr='$si', port='$sp', regseconds=$Ts+$hdr(expires) WHERE name='$au'");
makes me a happy man! Unified registry for OpenSER and Asterisk. Y-EAH!
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users