7 Jun
2007
7 Jun
'07
12:40 a.m.
Hello All,
I'm having trouble getting lcr to work properly. I am not sure
what to use for wild card matching.
In 1.1 i was using PREFIX 4____ ( 4 followed by 4 underscores) and
"from_uri" with value %.
Now, in 1.2 I changed the from_uri to be empty (by updating
from_uri="") but lcr is not able to match on 5 digit numbers starting
with 4. It works if i actually put a 5 digit extension. LCR module
documentation mentions regex use for "from_uri" but says nothing
about the prefix field
Another problem for me is the change in db tables usr_preferences and
subscriber. All tables are created using openser_mysql reinit command
usr_preferences has "modified" field changed to "last_modified".
Subscirber table in 1.2 (no serweb or additional tables;
'
+------------------+------------------+------+-----
+---------------------+----------------+
| Field | Type | Null | Key |
Default | Extra |
+------------------+------------------+------+-----
+---------------------+----------------+
| id | int(10) unsigned | | PRI |
NULL | auto_increment |
| username | varchar(64) | | MUL
| | |
| domain | varchar(128) | |
| | |
| password | varchar(25) | |
| | |
| first_name | varchar(25) | |
| | |
| last_name | varchar(45) | |
| | |
| email_address | varchar(50) | |
| | |
| datetime_created | datetime | | | 0000-00-00
00:00:00 | |
| ha1 | varchar(128) | |
| | |
| ha1b | varchar(128) | |
| | |
| timezone | varchar(128) | YES | |
NULL | |
| rpid | varchar(128) | YES | |
NULL | |
| phone | varchar(15) | YES | |
NULL | |
+------------------+------------------+------+-----
+---------------------+----------------+
subscriber in 1.1
+-------------------+--------------+------+-----+---------------------
+-------+
| Field | Type | Null | Key | Default
| Extra |
+-------------------+--------------+------+-----+---------------------
+-------+
| phplib_id | varchar(32) | | UNI |
| |
| username | varchar(64) | | PRI |
| |
| domain | varchar(128) | | PRI |
| |
| password | varchar(25) | | |
| |
| first_name | varchar(25) | | |
| |
| last_name | varchar(45) | | |
| |
| phone | varchar(15) | | |
| |
| email_address | varchar(50) | | |
| |
| datetime_created | datetime | | | 0000-00-00 00:00:00
| |
| datetime_modified | datetime | | | 0000-00-00 00:00:00
| |
| confirmation | varchar(64) | | |
| |
| flag | char(1) | | | o
| |
| sendnotification | varchar(50) | | |
| |
| greeting | varchar(50) | | |
| |
| ha1 | varchar(128) | | |
| |
| ha1b | varchar(128) | | |
| |
| allow_find | char(1) | | | 0
| |
| timezone | varchar(128) | YES | | NULL
| |
| rpid | varchar(128) | YES | | NULL
| |
| domn | int(10) | YES | | NULL
| |
| uuid | varchar(64) | YES | | NULL
| |
+-------------------+--------------+------+-----+---------------------
+-------+
Installing serweb tables seems to add the missing fields in subscriber.
I dont know if this is desired behavior or not. In any case I think
this should be mentioned on the openser 1.1.x to v1.2.x migration doc.
Thanks.
--
Zahid
3:36 p.m.
Juha,
we want only 5 digit numbers to match when prefixed with a 4. Not any
length. Was pattern matching remove from lcr in 1.2?
/a
...... Original Message .......
On Thu, 7 Jun 2007 07:29:50 +0300 "Juha Heinanen" <jh(a)tutpro.com> wrote:
zm23 writes:
In 1.1 i was using PREFIX 4____ ( 4 followed by
4 underscores) and
"from_uri" with value %.
prefix is just prefix, i.e., in your case 4. from uri is regular
expression, in your case you can use NULL value.
-- juha
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users 
5:02 p.m.
Alan Crosswell writes:
we want only 5 digit numbers to match when prefixed
with a 4. Not any
length. Was pattern matching remove from lcr in 1.2?
alan,
i'm not sure if there was in 1.1 pattern matching on prefix. i just
checked from the code and looks like % was added to the prefix in the
mysql query:
... AND '%.*s' LIKE CONCAT(%.*s.%.*s, '%%')
which would mean a match on any length of uri user. at least readme
didn't indicate any pattern matching on prefix:
139 Table lcr contains prefix of user part of Request-URI, From
140 URI, gateway group id, and priority. From URI can contain
141 special characters % and _ matching any number of any
142 characters and any one character, respectively, if db_mod
143 parameter is set to 0. If db_mod parameter is set to 1, then
144 From URI is a regular expression.
-- juha
10:33 p.m.
Yes, 1.1 has pattern matching on prefix despite the lack of
documentation. It does a SQL match or regex match just like on the from
URI. We've used this extensively here for the last year.
/a
Juha Heinanen wrote:
Alan Crosswell writes:
we want only 5 digit numbers to match when
prefixed with a 4. Not any
length. Was pattern matching remove from lcr in 1.2?
alan,
i'm not sure if there was in 1.1 pattern matching on prefix. i just
checked from the code and looks like % was added to the prefix in the
mysql query:
... AND '%.*s' LIKE CONCAT(%.*s.%.*s, '%%')
which would mean a match on any length of uri user. at least readme
didn't indicate any pattern matching on prefix:
139 Table lcr contains prefix of user part of Request-URI, From
140 URI, gateway group id, and priority. From URI can contain
141 special characters % and _ matching any number of any
142 characters and any one character, respectively, if db_mod
143 parameter is set to 0. If db_mod parameter is set to 1, then
144 From URI is a regular expression.
-- juha
10:48 p.m.
Alan Crosswell writes:
Yes, 1.1 has pattern matching on prefix despite the
lack of
documentation. It does a SQL match or regex match just like on the from
URI. We've used this extensively here for the last year.
if you have included chars in the prefix that have special meaning in
mysql LIKE expression, then you may have gotten regexp behavior, but
that has not been intentional.
it would be lot of work to add regexp support to the current caching
implementation. the main reason is that regexps need to be compiled and
compilation cannot be made to use shared memory.
-- juha
10:55 p.m.
Yes, we used SQL like patterns. I guess we'll have to look at
re-implementing some of what we were using LCR for in openser.cfg code
since it was a really convenient way to do a table-drive dial plan.
/a
Juha Heinanen wrote:
Alan Crosswell writes:
Yes, 1.1 has pattern matching on prefix despite
the lack of
documentation. It does a SQL match or regex match just like on the from
URI. We've used this extensively here for the last year.
if you have included chars in the prefix that have special meaning in
mysql LIKE expression, then you may have gotten regexp behavior, but
that has not been intentional.
it would be lot of work to add regexp support to the current caching
implementation. the main reason is that regexps need to be compiled and
compilation cannot be made to use shared memory.
-- juha
11:21 p.m.
Juha,
Thanks for your resoponse. I am a bit confused. How is LCR
using regex for "from_uri" ?
Would it be relatively easier to provide the option for db mode again?
--
Zahid
On Jun 7, 2007, at 2:55 PM, Alan Crosswell wrote:
Yes, we used SQL like patterns. I guess we'll
have to look at
re-implementing some of what we were using LCR for in openser.cfg code
since it was a really convenient way to do a table-drive dial plan.
/a
Juha Heinanen wrote:
> Alan Crosswell writes:
>
>> Yes, 1.1 has pattern matching on prefix despite the lack of
>> documentation. It does a SQL match or regex match just like on
>> the from
>> URI. We've used this extensively here for the last year.
>
> if you have included chars in the prefix that have special meaning in
> mysql LIKE expression, then you may have gotten regexp behavior, but
> that has not been intentional.
>
> it would be lot of work to add regexp support to the current caching
> implementation. the main reason is that regexps need to be
> compiled and
> compilation cannot be made to use shared memory.
>
> -- juha
11:30 p.m.
Zahid Mehmood writes:
Would it be relatively easier to provide the option
for db mode
again?
i don't remember the details anymore, but db mode didn't support some
other feature that we have in caching mode. but the main reason for
dropping db mode was performance, which got very poor (because of mysql
LIKE) when number of gw/lcr entries got bigger.
-- juha
11:59 p.m.
Adding regex support for prefix shouldn't be very hard.
Unfortunately, right now I'm busy with some other stuff, but maybe
latter on I can work on it.
Regards,
Ovidiu Sas
On 6/7/07, Juha Heinanen <jh(a)tutpro.com> wrote:
Zahid Mehmood writes:
Would it be relatively easier to provide the
option for db mode
again?
i don't remember the details anymore, but db mode didn't support some
other feature that we have in caching mode. but the main reason for
dropping db mode was performance, which got very poor (because of mysql
LIKE) when number of gw/lcr entries got bigger.
-- juha
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
8 Jun
8 Jun
12:03 a.m.
Ovidiu Sas writes:
Adding regex support for prefix shouldn't be very
hard.
Unfortunately, right now I'm busy with some other stuff, but maybe
latter on I can work on it.
ovidiu,
it would be nice if you had time to do it. the code is getting quite
long and complex already so maintainability might start getting an issue
though.
-- juha
12:07 a.m.
Hi Juha,
I will see if I can slip it in for 1.3.
Just ping me if you hear nothing from me in the next ... let's say ...
two months.
-ovi
On 6/7/07, Juha Heinanen <jh(a)tutpro.com> wrote:
Ovidiu Sas writes:
Adding regex support for prefix shouldn't be
very hard.
Unfortunately, right now I'm busy with some other stuff, but maybe
latter on I can work on it.
ovidiu,
it would be nice if you had time to do it. the code is getting quite
long and complex already so maintainability might start getting an issue
though.
-- juha
6:55 p.m.
Juha, Ovidiu:
Does the LCR implementation in 1.2 search the lcr_routes table in order
listed? If so, then we can live without regexps for prefixes.
Otherwise we have ambiguity in our dialplan. For instance, we have
entries like:
3_____ (in regexp this would be 3[0-9]{4})
311
If we change this in the lcr_route table to:
311 ...
3 ...
Then we'd be OK, but if the query randomly comes back in the other order
which is a function of the SQL select and underlying table structure
unless there's an order by some field which is not explicitly shown as
being a sequence number we are screwed.
/a
Ovidiu Sas wrote:
Hi Juha,
I will see if I can slip it in for 1.3.
Just ping me if you hear nothing from me in the next ... let's say ...
two months.
-ovi
On 6/7/07, Juha Heinanen <jh(a)tutpro.com> wrote:
Ovidiu Sas writes:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users Adding regex support for prefix shouldn't be
very hard.
Unfortunately, right now I'm busy with some other stuff, but maybe
latter on I can work on it.
ovidiu,
it would be nice if you had time to do it. the code is getting quite
long and complex already so maintainability might start getting an issue
though.
-- juha
7:07 p.m.
Alan Crosswell writes:
Does the LCR implementation in 1.2 search the
lcr_routes table in order
listed?
from README:
Matching gateways are
then ordered for forwarding purpose (1) according to longest
user part match, (2) according to gateway's priority, and (3)
randomly.
so if you have in lcr table
311 ...
3 ...
and call goes to r-uri where userpart starts with 311, then the first
entry would be selected.
-- juha
7:09 p.m.
alan,
i'm still wondering how your prefix pattern can limit the number of
digits in the match, since definitely % (that matches anything of any
length) is added automatically to the prefix. otherwise, plain prefixes
like 00358 would not work at all.
-- juha
7:51 p.m.
This would be an issue for prefix regex matching.
How we determine the best match, since checking the prefix length
doesn't make sense anymore?
-ovi
On 6/8/07, Juha Heinanen <jh(a)tutpro.com> wrote:
alan,
i'm still wondering how your prefix pattern can limit the number of
digits in the match, since definitely % (that matches anything of any
length) is added automatically to the prefix. otherwise, plain prefixes
like 00358 would not work at all.
-- juha
8:03 p.m.
Ovidiu Sas writes:
This would be an issue for prefix regex matching.
i was referring to alan's current setup.
How we determine the best match, since checking the
prefix length
doesn't make sense anymore?
it would still need to be on the longest match of any regexp and may get
tricky.
-- juha
9:32 p.m.
Hi Juha,
I know that you were referring to Alan's setup. I was just pointing
out that regex has this issue in general.
Let's consider the following example: a call to a 1800 number.
The destination is 18001231234 and in the lcr table we have the
following two prefixes:
1. ^18[01234567]
2. ^18[0-2]01
The second prefix is a better match for the 1800 number, but it has a
shorter length.
-ovi
On 6/8/07, Juha Heinanen <jh(a)tutpro.com> wrote:
Ovidiu Sas writes:
This would be an issue for prefix regex matching.
i was referring to alan's current setup.
How we determine the best match, since checking
the prefix length
doesn't make sense anymore?
it would still need to be on the longest match of any regexp and may get
tricky.
-- juha
9:43 p.m.
A solution to consider is to do first match rather than longest match
and make it explicitly incumbent upon the person entering data into LCR
tables to put things in the right order (by adding a sort column). This
is analogous to Cisco access list entires for example. Basically you
need to extend the openserctl UI by just adding another column....
/a
Ovidiu Sas wrote:
Hi Juha,
I know that you were referring to Alan's setup. I was just pointing
out that regex has this issue in general.
Let's consider the following example: a call to a 1800 number.
The destination is 18001231234 and in the lcr table we have the
following two prefixes:
1. ^18[01234567]
2. ^18[0-2]01
The second prefix is a better match for the 1800 number, but it has a
shorter length.
-ovi
On 6/8/07, Juha Heinanen <jh(a)tutpro.com> wrote:
> Ovidiu Sas writes:
>
> > This would be an issue for prefix regex matching.
>
> i was referring to alan's current setup.
>
> > How we determine the best match, since checking the prefix length
> > doesn't make sense anymore?
>
> it would still need to be on the longest match of any regexp and may get
> tricky.
>
> -- juha
>
9:54 p.m.
Ovidiu Sas writes:
Let's consider the following example: a call to a
1800 number.
The destination is 18001231234 and in the lcr table we have the
following two prefixes:
1. ^18[01234567]
2. ^18[0-2]01
The second prefix is a better match for the 1800 number, but it has a
shorter length.
you can always add dots to (2) to make it longer if you want. dial
plans also need to be sensibly designed.
-- juha
13 Jun
13 Jun
11:22 p.m.
Hi Juha,
Pls. check the regex prefix patch available here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1736696&gr…
I kept the impact on the existing mode of operation as low as possible.
I performed a few tests and everything was working fine in my environment.
Regards,
Ovidiu Sas
On 6/8/07, Juha Heinanen <jh(a)tutpro.com> wrote:
Ovidiu Sas writes:
Let's consider the following example: a call
to a 1800 number.
The destination is 18001231234 and in the lcr table we have the
following two prefixes:
1. ^18[01234567]
2. ^18[0-2]01
The second prefix is a better match for the 1800 number, but it has a
shorter length.
you can always add dots to (2) to make it longer if you want. dial
plans also need to be sensibly designed.
-- juha
8 Jun
8 Jun
10:29 p.m.
Just a thought. How about the following idea:
1. Before compiling the regex, change it the following way: prefix ->
^(prefix).*$
2. Match the called number to all the provisioned prefixes.
3. The "best" match amongst the matched regexes is the one where the
length of the substring matched to the first subpattern (part of the
regex in the parentheses) is the longest.
The drawback of this approach is that it is necessary to always try to
match against all the prefixes, so, if it is necessary to support many
prefixes then it is not a good idea.
Anatoly.
Hi Juha,
I know that you were referring to Alan's setup. I was just pointing
out that regex has this issue in general.
Let's consider the following example: a call to a 1800 number.
The destination is 18001231234 and in the lcr table we have the
following two prefixes:
1. ^18[01234567]
2. ^18[0-2]01
The second prefix is a better match for the 1800 number, but it has a
shorter length.
-ovi
On 6/8/07, Juha Heinanen <jh(a)tutpro.com> wrote:
Ovidiu Sas writes:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
This would be an issue for prefix regex matching.
i was referring to alan's current setup.
How we determine the best match, since checking
the prefix length
doesn't make sense anymore?
it would still need to be on the longest match of any regexp and may get
tricky.
-- juha
8:16 p.m.
Didn't say it was perfect. Just trying to document our dialplan and
make it clear to mere mortals who have to deal with it. A better plan
would be to use anchored regexps.
Specifically, the longest match issue is a problem which is why I forced
the length in 1.1 LCR.
31123 is dialed. Does this match the 3____ prefix or the 311 prefix In
1.2 LCR it would match 311 which is the longer prefix now.?
/a
Juha Heinanen wrote:
alan,
i'm still wondering how your prefix pattern can limit the number of
digits in the match, since definitely % (that matches anything of any
length) is added automatically to the prefix. otherwise, plain prefixes
like 00358 would not work at all.
-- juha
8:24 p.m.
Alan Crosswell writes:
31123 is dialed. Does this match the 3____ prefix or
the 311 prefix.
in 1.1 db mode your prefix 3____ is actually 3____%. if you dial 31123,
it would match 3____% because it is longer match than 311. in 1.2, if
you have 3 and 311, 31123 would match 311 because it is longer.
-- juha
9:27 p.m.
Yes, my point exactly
...... Original Message .......
On Fri, 8 Jun 2007 19:24:20 +0300 "Juha Heinanen" <jh(a)tutpro.com> wrote:
Alan Crosswell writes:
31123 is dialed. Does this match the 3____ prefix
or the 311 prefix.
in 1.1 db mode your prefix 3____ is actually 3____%. if you dial 31123,
it would match 3____% because it is longer match than 311. in 1.2, if
you have 3 and 311, 31123 would match 311 because it is longer.
-- juha 
11:40 a.m.
On Thursday 07 June 2007 21:21, Zahid Mehmood wrote:
Would it be relatively easier to provide the option
for db mode again?
You can get the same -and more- functionality by using db_query, creating a
list of destinations in the format and avp that next_gw() expects. ie
sip:|0@destination;transport=udp
which can be stored directly in the db or use a CONCAT or similar to create it
from separate fields.
modparam("lcr", "gw_uri_avp", "1400")
modparam("lcr", "ruri_user_avp", "1402")
if not avp_db_query("SELECT uri FROM pstn_gw WHERE '$(fU{s.escape.common})'
LIKE callerid ORDER BY callerid DESC", "$avp(i:1400)") {
INFO("Can't find PSTN gateways");
sl_send_reply("500", "Cannot load gateways");
return;
}
next_gw();
t_relay();
...
Performance will be very dependent on the complexity of the query.
--
Greetings,
Alex Hermann
11:45 a.m.
Alex Hermann writes:
it this is acceptable, i would prefer using it rather than increasing
complexity of lcr module. it also occurred to me that making prefix a
regular expression, may break backwards compatibility.
-- juha
Would it be
relatively easier to provide the option for db mode again?
You can get the same -and more- functionality by using db_query, creating a
list of destinations in the format and avp that next_gw() expects. ie
sip:|0@destination;transport=udp which can be stored directly in the
db or use a CONCAT or similar to create it
from separate fields.
2:17 p.m.
Hi Juha,
With respect to backward compatibility I was thinking about adding a
new module parameter: 'prefix_mode'.
The "prefix_mode' can have two values:
- the default value: 'prefix' (backward compatible)
- new value: 'regex'
-ovi
On 6/8/07, Juha Heinanen <jh(a)tutpro.com> wrote:
Alex Hermann writes:
it this is acceptable, i would prefer using it rather than increasing
complexity of lcr module. it also occurred to me that making prefix a
regular expression, may break backwards compatibility.
-- juha
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
Would it
be relatively easier to provide the option for db mode again?
You can get the same -and more- functionality by using db_query, creating a
list of destinations in the format and avp that next_gw() expects. ie
sip:|0@destination;transport=udp which can be stored directly in the
db or use a CONCAT or similar to create it
from separate fields.
2:22 p.m.
Ovidiu Sas writes:
With respect to backward compatibility I was thinking
about adding a
new module parameter: 'prefix_mode'.
The "prefix_mode' can have two values:
- the default value: 'prefix' (backward compatible)
- new value: 'regex'
ok. can you also avoid regexp compilation and matching is prefix_mode =
'prefix'?
-- juha
2:26 p.m.
Yes. That would be the purpose of the new flag.
-ovi
On 6/8/07, Juha Heinanen <jh(a)tutpro.com> wrote:
Ovidiu Sas writes:
With respect to backward compatibility I was
thinking about adding a
new module parameter: 'prefix_mode'.
The "prefix_mode' can have two values:
- the default value: 'prefix' (backward compatible)
- new value: 'regex'
ok. can you also avoid regexp compilation and matching is prefix_mode =
'prefix'?
-- juha
7:42 p.m.
Thank you everyone who responded to my lcr question. Really
appreciate your help.
I was wondering if someone could comment on the second part of my
email relating to DB schema changes.
Another thing that i noticed is that subscriber table gets the
additional (missing compared to v1.1) fields when I install serweb
tables. In v1.1 these fields were present without installing serweb
tables.
--
Zahid
On Jun 6, 2007, at 4:40 PM, zm23 wrote:
Hello All,
I'm having trouble getting lcr to work properly. I am not sure
what to use for wild card matching.
In 1.1 i was using PREFIX 4____ ( 4 followed by 4 underscores) and
"from_uri" with value %.
Now, in 1.2 I changed the from_uri to be empty (by updating
from_uri="") but lcr is not able to match on 5 digit numbers
starting with 4. It works if i actually put a 5 digit extension.
LCR module documentation mentions regex use for "from_uri" but says
nothing about the prefix field
Another problem for me is the change in db tables usr_preferences
and subscriber. All tables are created using openser_mysql reinit
command
usr_preferences has "modified" field changed to "last_modified".
Subscirber table in 1.2 (no serweb or additional tables;
'
+------------------+------------------+------+-----
+---------------------+----------------+
| Field | Type | Null | Key |
Default | Extra |
+------------------+------------------+------+-----
+---------------------+----------------+
| id | int(10) unsigned | | PRI |
NULL | auto_increment |
| username | varchar(64) | | MUL
| | |
| domain | varchar(128) | |
| | |
| password | varchar(25) | |
| | |
| first_name | varchar(25) | |
| | |
| last_name | varchar(45) | |
| | |
| email_address | varchar(50) | |
| | |
| datetime_created | datetime | | | 0000-00-00
00:00:00 | |
| ha1 | varchar(128) | |
| | |
| ha1b | varchar(128) | |
| | |
| timezone | varchar(128) | YES | |
NULL | |
| rpid | varchar(128) | YES | |
NULL | |
| phone | varchar(15) | YES | |
NULL | |
+------------------+------------------+------+-----
+---------------------+----------------+
subscriber in 1.1
+-------------------+--------------+------+-----
+---------------------+-------+
| Field | Type | Null | Key |
Default | Extra |
+-------------------+--------------+------+-----
+---------------------+-------+
| phplib_id | varchar(32) | | UNI
| | |
| username | varchar(64) | | PRI
| | |
| domain | varchar(128) | | PRI
| | |
| password | varchar(25) | |
| | |
| first_name | varchar(25) | |
| | |
| last_name | varchar(45) | |
| | |
| phone | varchar(15) | |
| | |
| email_address | varchar(50) | |
| | |
| datetime_created | datetime | | | 0000-00-00
00:00:00 | |
| datetime_modified | datetime | | | 0000-00-00
00:00:00 | |
| confirmation | varchar(64) | |
| | |
| flag | char(1) | | |
o | |
| sendnotification | varchar(50) | |
| | |
| greeting | varchar(50) | |
| | |
| ha1 | varchar(128) | |
| | |
| ha1b | varchar(128) | |
| | |
| allow_find | char(1) | | |
0 | |
| timezone | varchar(128) | YES | |
NULL | |
| rpid | varchar(128) | YES | |
NULL | |
| domn | int(10) | YES | |
NULL | |
| uuid | varchar(64) | YES | |
NULL | |
+-------------------+--------------+------+-----
+---------------------+-------+
Installing serweb tables seems to add the missing fields in
subscriber.
I dont know if this is desired behavior or not. In any case I
think this should be mentioned on the openser 1.1.x to v1.2.x
migration doc.
Thanks.
--
Zahid
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6318
days inactive
6325
days old
30 comments
7 participants
participants (7)
-
Alan Crosswell -
Alex Hermann -
Anatoly Pidruchny -
jh＠tutpro.com -
Ovidiu Sas -
Zahid Mehmood -
zm23