3 Jun
2008
3 Jun
'08
9:25 a.m.
I was wondering if anyone has documentation on the new syntax used in SER 0.10.x. I see
the following in the ser-advanced.cfg example file but I do not see these parameters
documented anywhere.
Thanks,Steve
if ($t.fr_inv_timer) {
if ($t.fr_timer) {
t_set_fr("$t.fr_inv_timer", "$t.fr_timer");
} else {
t_set_fr("$t.fr_inv_timer");
}
}
Senior Network Engineer,
Information Systems and Computing
Networking and Telecommunications , Suite 221A /6228
University of Pennsylvania
Voice:215-573-8396
FAX:215-898-9348
3 Jun
3 Jun
4:04 p.m.
These are loaded from database. This is the idea behind database AVP --
load-what-have-you-there. If such an AVP exists (see the initial
condition) the rest is executed.
-jiri
Steven C. Blair wrote:
I was wondering if anyone has documentation on the new syntax used in
SER 0.10.x. I see the following in the ser-advanced.cfg example file but
I do not see these parameters documented anywhere.
Thanks,Steve
if ($t.fr_inv_timer) {
if ($t.fr_timer) {
t_set_fr("$t.fr_inv_timer", "$t.fr_timer");
} else {
t_set_fr("$t.fr_inv_timer");
}
}
Senior Network Engineer,
Information Systems and Computing
Networking and Telecommunications , Suite 221A /6228
University of Pennsylvania
Voice:215-573-8396
FAX:215-898-9348
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7:26 p.m.
Jiri:
I was asking for documentation because avpops commands from my ser-0.9.7-pre3 config do
not work on a ser-0.10.x config. Not only are the tables different but they way one
references parts of the sip header is different too. Is there documentation on any of
these topics?
Thanks,Steve
________________________________________
From: Jiri Kuthan [jiri(a)iptel.org]
Sent: Tuesday, June 03, 2008 4:04 PM
To: Steven C. Blair
Cc: serusers(a)iptel.org
Subject: Re: [Serusers] ser 0.10 doucmentation
These are loaded from database. This is the idea behind database AVP --
load-what-have-you-there. If such an AVP exists (see the initial
condition) the rest is executed.
-jiri
Steven C. Blair wrote:
I was wondering if anyone has documentation on the new syntax used in
SER 0.10.x. I see the following in the ser-advanced.cfg example file but
I do not see these parameters documented anywhere.
Thanks,Steve
if ($t.fr_inv_timer) {
if ($t.fr_timer) {
t_set_fr("$t.fr_inv_timer", "$t.fr_timer");
} else {
t_set_fr("$t.fr_inv_timer");
}
}
Senior Network Engineer,
Information Systems and Computing
Networking and Telecommunications , Suite 221A /6228
University of Pennsylvania
Voice:215-573-8396
FAX:215-898-9348
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4 Jun
4 Jun
2:40 p.m.
Steven C. Blair wrote:
I was asking for documentation because avpops commands from my
ser-0.9.7-pre3 config do not work on a ser-0.10.x config. Not only
are the tables different but they way one references parts of the sip
header is different too. Is there documentation on any of these
topics?
I am afraid, there is not much. The only thing by way of documentation
is ser-advanced.cfg and ser-oob.cfg. Jan also had a presentation
introducing the new features. Not sure if this one is available online.
We had intentions to have some admin guide before releasing SER 2.0, but
it seems that nobody has the time, so insisting would delay 2.0 even
more.
In a nutshell:
Attributes can now be addresses by prefixing them with a dollar sign and
can be used directly in the config. For instance, you can assign a value
simply by saying
$foo = "bar";
Similarly, you can check for a value in an if:
if ($foo == "bar") { route(DO_STUFF); }
Most function that used to expect a string literal are now happy with
the name of an attribute as well.
There are several classes of attributes though. This is an extension to
the old model where attributes where prefixed with "caller_" or
"callee_" depending on who they were for. This prefix is now "$t." or
"$f." for "to" and "from". Addtionally, you can have
attributes for the
URI, user, domain, and globally. If you want to address those, the
prefix gets a second letter t, u, d, g respectively. Thus, "$tu.foo" is
the variable to for the from user.
You load these attributes from the database with the functions from the
avp_db and domain modules. For the domain, this is done automagically
with load_domain() if you set the module parameter load_domain_attrs to
yes. For the user and uri attributes, you use the function load_attrs().
First parameter is the prefix where the attributes should go, ie.,
either "$tr", "$fr", "$tu", or "$fu". Second
parameter is the URI or
user ID.
Speaking of which, there is a difference now between users and URIs.
This makes the old aliases table deprecated. Instead, the database
table uri assignes URIs to user IDs. The module uri does the mapping
between the two.
Then there is selects. That's those things with the at sign in front.
They are read only and allow access to many things in the request. Most
important headers are available this way: @from gives you the (entire)
From header (or rather the entire header field value),
@to gives To, and
so on. Even better: @from.uri gives you the URI in the From
header
field. More? Sure: @from.uri.user gives you the username part of the URI
in the From header field.
As I said, there is not much documentation for all this now. But with
these basics, if you read carefully through ser-advanced.cfg and
ser-oob.cfg, you should get the hang of it. If you have questions,
please ask.
Best regards,
Martin
8:28 p.m.
Martin:
Thanks. That helps. I have some questions in-line below.
-Steve
________________________________________
From: Martin Hoffmann [hn(a)nvnc.de]
Sent: Wednesday, June 04, 2008 2:40 PM
To: Steven C. Blair
Cc: Jiri Kuthan; serusers(a)iptel.org
Subject: Re: [Serusers] ser 0.10 doucmentation
Steven C. Blair wrote:
I was asking for documentation because avpops commands from my
ser-0.9.7-pre3 config do not work on a ser-0.10.x config. Not only
are the tables different but they way one references parts of the sip
header is different too. Is there documentation on any of these
topics?
I am afraid, there is not much. The only thing by way of documentation
is ser-advanced.cfg and ser-oob.cfg. Jan also had a presentation
introducing the new features. Not sure if this one is available online.
We had intentions to have some admin guide before releasing SER 2.0, but
it seems that nobody has the time, so insisting would delay 2.0 even
more.
In a nutshell:
Attributes can now be addresses by prefixing them with a dollar sign and
can be used directly in the config. For instance, you can assign a value
simply by saying
$foo = "bar";
[scb] OK, now I see.
Similarly, you can check for a value in an if:
if ($foo == "bar") { route(DO_STUFF); }
Most function that used to expect a string literal are now happy with
the name of an attribute as well.
There are several classes of attributes though. This is an extension to
the old model where attributes where prefixed with "caller_" or
"callee_" depending on who they were for. This prefix is now "$t." or
"$f." for "to" and "from". Addtionally, you can have
attributes for the
URI, user, domain, and globally. If you want to address those, the
prefix gets a second letter t, u, d, g respectively. Thus, "$tu.foo" is
the variable to for the from user.
[scb] Is URI the same as $ruri in SER0.9.x?
[scb] Please explain how "$tu.foo" is the variable to for the from user. I do
not understand.
You load these attributes from the database with the functions from the
avp_db and domain modules. For the domain, this is done automagically
with load_domain() if you set the module parameter load_domain_attrs to
yes. For the user and uri attributes, you use the function load_attrs().
First parameter is the prefix where the attributes should go, ie.,
either "$tr", "$fr", "$tu", or "$fu". Second
parameter is the URI or
user ID.
[scb] OK. I see now. I will try to change my SER 0.9 example.
Speaking of which, there is a difference now between users and URIs.
This makes the old aliases table deprecated. Instead, the database
table uri assignes URIs to user IDs. The module uri does the mapping
between the two.
Then there is selects. That's those things with the at sign in front.
They are read only and allow access to many things in the request. Most
important headers are available this way: @from gives you the (entire)
From header (or rather the entire header field value),
@to gives To, and
so on. Even better: @from.uri gives you the URI in the From
header
field. More? Sure: @from.uri.user gives you the username part of the URI
in the From header field.
As I said, there is not much documentation for all this now. But with
these basics, if you read carefully through ser-advanced.cfg and
ser-oob.cfg, you should get the hang of it. If you have questions,
please ask.
[scb] Thank you I will take another look and email again if I have more questions.
Best regards,
Martin
9:05 p.m.
There are several classes of attributes though. This
is an extension to
the old model where attributes where prefixed with "caller_" or
"callee_" depending on who they were for. This prefix is now "$t."
or
"$f." for "to" and "from". Addtionally, you can have
attributes for the
URI, user, domain, and globally. If you want to address those, the
prefix gets a second letter t, u, d, g respectively. Thus, "$tu.foo" is
the variable to for the from user.
[scb] Is URI the same as $ruri in SER0.9.x?
$ruri is unchanged, it stands for the request uri.
example from oob: !(a)ruri.user means "if there is no user part in
request uri".
Generally the 1e5-feet perspective is that SER produces a result (i.e.
routing
action typically) based on combination of SIP message elements and user
profiles.
SIP message elements are represented by selects, user profiles by AVPs.
Most AVPs are loaded from the database, even though you may have more of
those.
[scb] Please explain how "$tu.foo" is the variable to for the from user. I do
not understand.
well, that's the database thing: it is an AVP named "foo". (presumably
with value "bar" :-))
because in ser processing, a request processing decision may depend both
on caller's
and callee's profile, you need to differentiate. (e.g., call-forwarding
is driven by
recepient's profile, anynomyzation by caller's ... but the script needs
to know).
Thus, if this was a recepient service (such as call-forwarding) you need to
state that by use of the "t" prefix. "$tu.foo" thus means "value
of callee's
attribute named 'foo'". The value is loaded from database (from user_attrs
table).
The "u" letter specifically says "user attribute". You could also
refer
to domain attributes and global ones, most interesting are the
user-specific ones. If you omit this specification, SER will try to find
the "most specific" attribute, i.e. a user-one if present. If not
present, SER defaults to domain-specific attrributes, in lack of those
to global.
-jiri
9:24 p.m.
Thanks Jiri. For my application I typically want to compare the R-URI, To user and/or From
user to see if the call should be forwarded or not. In addition I need to check the look
in the db for an attribute and value pair using the user portion of the r-uri, to or from
address as the key.
I'll try to get my aplication working now that I have a little more information.
Thanks,Steve
________________________________________
From: Jiri Kuthan [jiri(a)iptel.org]
Sent: Wednesday, June 04, 2008 9:05 PM
To: Steven C. Blair
Cc: Martin Hoffmann; serusers(a)iptel.org
Subject: Re: [Serusers] ser 0.10 doucmentation
There are several classes of attributes though. This
is an extension to
the old model where attributes where prefixed with "caller_" or
"callee_" depending on who they were for. This prefix is now "$t."
or
"$f." for "to" and "from". Addtionally, you can have
attributes for the
URI, user, domain, and globally. If you want to address those, the
prefix gets a second letter t, u, d, g respectively. Thus, "$tu.foo" is
the variable to for the from user.
[scb] Is URI the same as $ruri in SER0.9.x?
$ruri is unchanged, it stands for the request uri.
example from oob: !(a)ruri.user means "if there is no user part in
request uri".
Generally the 1e5-feet perspective is that SER produces a result (i.e.
routing
action typically) based on combination of SIP message elements and user
profiles.
SIP message elements are represented by selects, user profiles by AVPs.
Most AVPs are loaded from the database, even though you may have more of
those.
[scb] Please explain how "$tu.foo" is the variable to for the from user. I do
not understand.
well, that's the database thing: it is an AVP named "foo". (presumably
with value "bar" :-))
because in ser processing, a request processing decision may depend both
on caller's
and callee's profile, you need to differentiate. (e.g., call-forwarding
is driven by
recepient's profile, anynomyzation by caller's ... but the script needs
to know).
Thus, if this was a recepient service (such as call-forwarding) you need to
state that by use of the "t" prefix. "$tu.foo" thus means "value
of callee's
attribute named 'foo'". The value is loaded from database (from user_attrs
table).
The "u" letter specifically says "user attribute". You could also
refer
to domain attributes and global ones, most interesting are the
user-specific ones. If you omit this specification, SER will try to find
the "most specific" attribute, i.e. a user-one if present. If not
present, SER defaults to domain-specific attrributes, in lack of those
to global.
-jiri
10:36 p.m.
Steven C. Blair wrote:
Thanks Jiri. For my application I typically want to
compare the R-URI, To user and/or From user to see if the call should be forwarded or not.
For accessing the SIP elements, there is the select operator.
examples:
@from.uri.host
@to.tag
for a full list of those, check interactive doc:
http://www.iptel.org/ser/doc/search
unselect all but "S" for selects.
In addition I need to check the look in the db for an
attribute and value pair using the user portion of the r-uri, to or from address as the
key.
load then AVPs from DB as in the OOB config file (load_attrs("$tu",
"$t.uid"); load_attrs("$fu", "$f.uid");) and use them as in
the example
before (e.g. $fu.foo)
-jiri
I'll try to get my aplication working now that I have a little more information.
Thanks,Steve
________________________________________
From: Jiri Kuthan [jiri(a)iptel.org]
Sent: Wednesday, June 04, 2008 9:05 PM
To: Steven C. Blair
Cc: Martin Hoffmann; serusers(a)iptel.org
Subject: Re: [Serusers] ser 0.10 doucmentation
There are several classes of attributes though.
This is an extension to
the old model where attributes where prefixed with "caller_" or
"callee_" depending on who they were for. This prefix is now "$t."
or
"$f." for "to" and "from". Addtionally, you can have
attributes for the
URI, user, domain, and globally. If you want to address those, the
prefix gets a second letter t, u, d, g respectively. Thus, "$tu.foo" is
the variable to for the from user.
[scb] Is URI the same as $ruri in SER0.9.x?
$ruri is unchanged, it stands for the request uri.
example from oob: !(a)ruri.user means "if there is no user part in
request uri".
Generally the 1e5-feet perspective is that SER produces a result (i.e.
routing
action typically) based on combination of SIP message elements and user
profiles.
SIP message elements are represented by selects, user profiles by AVPs.
Most AVPs are loaded from the database, even though you may have more of
those.
[scb] Please explain how "$tu.foo" is
the variable to for the from user. I do not understand.
well, that's the database thing: it is an AVP named "foo". (presumably
with value "bar" :-))
because in ser processing, a request processing decision may depend both
on caller's
and callee's profile, you need to differentiate. (e.g., call-forwarding
is driven by
recepient's profile, anynomyzation by caller's ... but the script needs
to know).
Thus, if this was a recepient service (such as call-forwarding) you need to
state that by use of the "t" prefix. "$tu.foo" thus means "value
of callee's
attribute named 'foo'". The value is loaded from database (from user_attrs
table).
The "u" letter specifically says "user attribute". You could also
refer
to domain attributes and global ones, most interesting are the
user-specific ones. If you omit this specification, SER will try to find
the "most specific" attribute, i.e. a user-one if present. If not
present, SER defaults to domain-specific attrributes, in lack of those
to global.
-jiri
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
5 Jun
5 Jun
2:06 a.m.
Steven C. Blair wrote:
In addition I need to check the look in the db for an attribute
and value pair using the user portion of the r-uri, to or from address
as the key.
Remember the changed database model. You don't want to do that
explicitely any more. Instead, you determine the user ID from the entire
URI through lookup_user() and then load the attributes for that user.
This way you get multi-domain support for free.
What I forgot last night: I good way to start with SER 2.0 is to take
ser-oob.cfg and modify it step by step to meet your requirements. This
way, you start out with a config that is known to work.
Regards,
Martin
11 Jun
11 Jun
8:31 p.m.
On Thu, 5 Jun 2008 08:06:27 +0200, Martin Hoffmann wrote:
What I forgot last night: I good way to start with SER
2.0 is to take
ser-oob.cfg and modify it step by step to meet your requirements. This
way, you start out with a config that is known to work.
Stupid question: Where do I find ser-oob.cfg? I installed 2.0 rc1,
and got a ser.cfg, but not a ser-oob.cfg.
Also, anyone out there interested in writing/modifying a 2.0 cfg file
for me? I'll pay!
--
Mark Sidell
Partner
Forte, Inc.
919-942-7068
fax 919-969-2844
www.forteinc.com
12 Jun
12 Jun
6:33 p.m.
x-ser(a)sidell.org wrote:
On Thu, 5 Jun 2008 08:06:27 +0200, Martin Hoffmann
wrote:
Dunno if rc1 did contain it already. You can get the current version
through web CVS:
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/*checkout*/ser/sip_router/etc/ser…
Regards,
Martin
What I forgot last night: I good way to start
with SER 2.0 is to take
ser-oob.cfg and modify it step by step to meet your requirements. This
way, you start out with a config that is known to work.
Stupid question: Where do I find ser-oob.cfg? I installed 2.0 rc1,
and got a ser.cfg, but not a ser-oob.cfg.
6:07 p.m.
New subject: [Serusers] testing for trusted peers
Greetings.
I'm in the processing of converting my ser.cfg file from 0.9 to 2.0,
and am trying to use ser-oob.cfg as a starting point.
My system accepts inbound calls from multiple pstn gateways. My 0.9
script used the allow_trusted() function to test whether an invite was
coming from one of the pstn gateways. It used the "trusted" mysql
table.
File ser-oob.cfg appears to be written to handle just a single pstn
gateway, named by the $gw_ip parameter.
Does 2.0 still have the permissions functionality? How should I
modify ser-oob.cfg to do the same test that allow_trusted() did in
0.9?
Many thanks!
--
Mark Sidell
Partner
Forte, Inc.
919-942-7068
fax 919-969-2844
www.forteinc.com
6:37 p.m.
New subject: [Serusers] testing for trusted peers
x-ser(a)sidell.org wrote:
Does 2.0 still have the permissions functionality? How should I
modify ser-oob.cfg to do the same test that allow_trusted() did in
0.9?
This seems to have changed a bit. Check out the permissions module. It's
README file should explain the usage.
Regards,
Martin
6:18 p.m.
New subject: [Serusers] forwarding selected invites to sems
Greetings.
I'm in the processing of converting my ser.cfg file from 0.9 to 2.0,
and am trying to use ser-oob.cfg as a starting point.
I want to forward selected inbound invites to a sems server. In 0.9,
I tested the invite message's uri and forwarded the invites using code
like this:
# Test for a particular DID from the PSTN gateway
#
if (uri =~ "sip:7605796638@") {
log("Forwarding to eliza");
# Do NAT traversal
route(4);
# Tell sems what application to run
append_hf("P-App-Name: fivr\r\n");
append_hf("P-App-Param: cfg_production\r\n");
# Relay the invite to sems
rewritehostport("12.34.56.78:5070");
t_relay_to_udp("12.34.56.78","5070");
break;
}
Will the same code work in ser-oob.cfg? At what point in the script
should I insert these tests? Also, does the script and associated
mysql database provide any way to do this sort of forwarding in a more
generic, table-driven, way?
Many thanks!
--
Mark Sidell
Partner
Forte, Inc.
919-942-7068
fax 919-969-2844
www.forteinc.com
6:46 p.m.
New subject: [Serusers] forwarding selected invites to sems
x-ser(a)sidell.org wrote:
Greetings.
I'm in the processing of converting my ser.cfg file from 0.9 to 2.0,
and am trying to use ser-oob.cfg as a starting point.
I want to forward selected inbound invites to a sems server. In 0.9,
I tested the invite message's uri and forwarded the invites using code
like this:
# Test for a particular DID from the PSTN gateway
#
if (uri =~ "sip:7605796638@") {
log("Forwarding to eliza");
# Do NAT traversal
route(4);
# Tell sems what application to run
append_hf("P-App-Name: fivr\r\n");
append_hf("P-App-Param: cfg_production\r\n");
# Relay the invite to sems
rewritehostport("12.34.56.78:5070");
t_relay_to_udp("12.34.56.78","5070");
break;
}
Will the same code work in ser-oob.cfg?
It should. Although you can replace the regexp in the condition with
@ruri.user == 7605796638
But the old way should still work.
At what point in the script
should I insert these tests?
Probably in route[SITE_SPECIFIC].
Also, does the script and associated
mysql database provide any way to do this sort of forwarding in a more
generic, table-driven, way?
Yes. All these things are done through attributes these days. The
easiest way is probably to create a user but don't give it credentials
so that nobody can register. Then assign the URIs to the user. And
finally, set the attribute "fwd_always_target" for that user in the
user_attrs table. Then ser-oob.cfg will always forward incoming calls
for that user and its assigned URIs to the URI in the attribute.
What you cannot do this way, however, is adding header files as in you
above code snippet. But you shouldn't, anyways. The proper way of
choosing what you media server should do this is through either the
username or URI parameters in the Request-URI. I would presume that SEMS
supports this.
Regards,
Martin
7:08 p.m.
New subject: [Serusers] forwarding selected invites to sems
o Martin Hoffmann [06/13/08 00:46]:
What you cannot do this way, however, is adding header
files as in you
above code snippet. But you shouldn't, anyways. The proper way of
choosing what you media server should do this is through either the
username or URI parameters in the Request-URI. I would presume that SEMS
supports this.
yes, set application=$(ruri.user) or application=$(ruri.param). or,
if
it is a more complicated scheme, application=$(mapping), where
regex=>application mapping is read from app_mapping.conf (see
app_mapping.conf).
For application parameters you will have to add the header, though. But
this could be loaded from an attribute as well.
Stefan
13 Jun
13 Jun
2:43 p.m.
New subject: [Serusers] How does $f.did work?
In ser-oob.cfg, the route[AUTHENTICATION] function has this code:
# Requests from non-local to local domains should be permitted.
# Remove this if you want a walled garden.
if (!$f.did) {
break;
}
I'm guessing that the code is permitting all invites that are
addressed to a local destination, regardless of the source of the
invite, so that the source is not required to authenticate itself. Is
that right?
Also, what is the tersely named $f variable, how does it get
initialized, and what is the meaning of the .did member?
Many thanks!
--
Mark Sidell
Partner
Forte, Inc.
919-942-7068
fax 919-969-2844
www.forteinc.com
3:51 p.m.
New subject: [Serusers] How does $f.did work?
x-ser(a)sidell.org wrote:
In ser-oob.cfg, the route[AUTHENTICATION] function has
this code:
# Requests from non-local to local domains should be permitted.
# Remove this if you want a walled garden.
if (!$f.did) {
break;
}
I'm guessing that the code is permitting all invites that are
addressed to a local destination, regardless of the source of the
invite, so that the source is not required to authenticate itself. Is
that right?
Not quite. If the from domain (usually the domain mentioned in the hostport
part of the From URI) is known, the attribute $f.did is set otherwise it
isn't. The code breaks out of the route for all requests with a unknown
from domain -- more specifically, a from domain that is not processed by
this proxy.
Also, what is the tersely named $f variable, how does
it get
initialized, and what is the meaning of the .did member?
I did write a short explanation a couple of days ago. It is split into
two postings:
o http://lists.iptel.org/pipermail/serusers/2008-June/035035.html
o http://lists.iptel.org/pipermail/serusers/2008-June/035037.html
If I have some time, I will write this all up properly.
Regards,
Martin
5:10 p.m.
New subject: [Serusers] Is ser-oob.cfg compatible with 2.0 rc1?
When I try to have ser check the ser-oob.cfg configuration file, I get
the following errors:
[root@henry ser]# ser -f /usr/local/etc/ser/ser-oob.cfg -c
0(4979) parse error (143,1-10): syntax error
0(4979) parse error (143,1-10):
ERROR: bad config file (2 errors)
--
Mark Sidell
Partner
Forte, Inc.
919-942-7068
fax 919-969-2844
www.forteinc.com
14 Jun
14 Jun
1:55 a.m.
New subject: [Serusers] Is ser-oob.cfg compatible with 2.0 rc1?
x-ser(a)sidell.org wrote:
When I try to have ser check the ser-oob.cfg
configuration file, I get
the following errors:
[root@henry ser]# ser -f /usr/local/etc/ser/ser-oob.cfg -c
0(4979) parse error (143,1-10): syntax error
0(4979) parse error (143,1-10):
ERROR: bad config file (2 errors)
Can you please also post the line in question? There is two versions of
ser-oob.cfg (one for 2.0 and one for CVS head aka 2.1). Both seem not to
have anything offending at line 143 from what I can see.
Regards,
Martin
8:12 a.m.
New subject: [Serusers] Is ser-oob.cfg compatible with 2.0 rc1?
On Sat, 14 Jun 2008 07:55:31 +0200, Martin Hoffmann wrote:
x-ser(a)sidell.org wrote:
Hi, Martin.
I think I'm using the ser-oob.cfg from the cvs head. Below is the
group of lines surrounding line 143. Line 143 is "phone2tel=no". The
error occurs with a clean build of ser 2.0 rc1.
Perhaps I should do what you suggest in your earlier message, and use
a recent 2.0 daily snapshot instead.
# $Id: ser-oob.cfg,v 1.1.2.20 2008/06/11 14:53:45 janakj Exp $
...
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
#port=5060
#children=4
#user=ser
#group=ser
#disable_core=yes # disables core dumping
open_files_limit=20480 # sets the open file descriptors limit
#mhomed=yes # usefull for multihomed hosts, small
performance
# penalty
disable_tcp=no # be conservative about enabling TCP -- it can
# degrade performance a lot
#tcp_accept_aliases=yes # accepts the tcp alias via option (see NEWS)
phone2tel=no # ignore user=phone in request-URIs --
otherwise
# these URIs would be interpreted as
equivalent
# to TEL URIs, and their lookup would fail in URI
# database
reply_to_via=no
--
Mark
When I try to have ser check the ser-oob.cfg
configuration file, I get
the following errors:
[root@henry ser]# ser -f /usr/local/etc/ser/ser-oob.cfg -c
0(4979) parse error (143,1-10): syntax error
0(4979) parse error (143,1-10):
ERROR: bad config file (2 errors)
Can you please also post the line in question? There is two versions of
ser-oob.cfg (one for 2.0 and one for CVS head aka 2.1). Both seem not to
have anything offending at line 143 from what I can see.
8:23 a.m.
New subject: [Serusers] Is ser-oob.cfg compatible with 2.0 rc1?
x-ser(a)sidell.org wrote:
On Sat, 14 Jun 2008 07:55:31 +0200, Martin Hoffmann
wrote:
That one should have the phone2tel core parameter. If it doesn't, you
can safely comment out the line.
Regards,
Martin
x-ser(a)sidell.org wrote:
Hi, Martin.
I think I'm using the ser-oob.cfg from the cvs head. Below is the
group of lines surrounding line 143. Line 143 is "phone2tel=no". The
error occurs with a clean build of ser 2.0 rc1.
Perhaps I should do what you suggest in your earlier message, and use
a recent 2.0 daily snapshot instead. When I try to have ser check the ser-oob.cfg
configuration file, I get
the following errors:
[root@henry ser]# ser -f /usr/local/etc/ser/ser-oob.cfg -c
0(4979) parse error (143,1-10): syntax error
0(4979) parse error (143,1-10):
ERROR: bad config file (2 errors)
Can you please also post the line in question? There is two versions of
ser-oob.cfg (one for 2.0 and one for CVS head aka 2.1). Both seem not to
have anything offending at line 143 from what I can see.
8:50 a.m.
New subject: [Serusers] domain table questions
Thanks to Martin for explaining the 2.0 design for domains.
Looking at the mysql domain table, I now understand the "did" field.
Am I correct in assuming that the "domain" field should be a domain
name that appears on the RHS of a SIP URI?
ALso, if I'm poking the database table manually, should I set the
"flags" field to anything in particular?
Many thanks!
--
Mark
15 Jun
15 Jun
5:35 a.m.
New subject: [Serusers] domain table questions
x-ser(a)sidell.org wrote:
Looking at the mysql domain table, I now understand the "did" field.
Am I correct in assuming that the "domain" field should be a domain
name that appears on the RHS of a SIP URI?
Correct.
ALso, if I'm poking the database table manually,
should I set the
"flags" field to anything in particular?
Yes. Bit 0 (ie., value 1) needs to be set and bit 1 (ie., value 2) needs
not to be set. The bits are explained somewhat in the file db/db.h in
the sources.
Regards,
Martin
14 Jun
14 Jun
9:05 a.m.
New subject: [Serusers] best way to allow outbound calls from multiple SEMS serves
Greetings.
In my application, there will be multiple SEMS servers making outbound
(PSTN) calls via a common SER proxy.
In ser-oob.cfg, the following code allows a single gateway to send
invites without authentication:
# Gateways are usually not able to authenticate for their requests.
# You have to trust them base on some other information such as the
# source IP address.
# WARNING: If at all this is only safe in a local network!
if (@src.ip == $gw_ip) {
break;
}
I suppose I could perform the test multiple times, once for each SEMS
server. But, I wonder if there is a nice 2.0-style database-oriented
way to allow invites from multiple trusted sources?
Thanks again.
--
Mark
15 Jun
15 Jun
6:11 a.m.
New subject: [Serusers] best way to allow outbound calls from multiple SEMS serves
x-ser(a)sidell.org wrote:
# Gateways are usually not able to authenticate for their requests.
# You have to trust them base on some other information such as the
# source IP address.
# WARNING: If at all this is only safe in a local network!
if (@src.ip == $gw_ip) {
break;
}
I suppose I could perform the test multiple times, once for each SEMS
server. But, I wonder if there is a nice 2.0-style database-oriented
way to allow invites from multiple trusted sources?
Please have a look at the permissions module. I have never used it
myself, but it appears to be exactly what you are looking for.
Regards,
Martin
14 Jun
14 Jun
9:10 a.m.
New subject: [Serusers] how to add a user manually?
Greetings, and I promise this will be my last question of the morning!
I apologize if this question has been answered before...
What database tables and fields do I need to edit (manually) to add a
local user? This would for a simple SIP telephone that does standard
registrations. No fancy features.
Oh, wait. One fancy feature... How should I edit the database tables
to cause all inbound calls to the user to be forwarded to a particular
URI?
Thanks!
--
Mark
15 Jun
15 Jun
6:20 a.m.
New subject: [Serusers] how to add a user manually?
x-ser(a)sidell.org wrote:
What database tables and fields do I need to edit (manually) to add a
local user? This would for a simple SIP telephone that does standard
registrations. No fancy features.
The domain table has been mentioned. If you use ser-oob.cfg you also
need to add an attribute named "digest_realm" for your domains to the
domain_attrs table containing the string that should be used as realm
for any digest authentication. Usually, this is set to the canonical
domain name.
Next you need to add the mapping between URI and user ID in the uri
table. Here, you need two extra bits in the flags field: DB_IS_TO (bit
3, with value 8) if you want to allow the use of the URI in incoming
calls and DB_IS_FROM (bit 4, with value 16) if it should be possible to
use it for outgoing calls.
Finally, you need to add credentials for registration and outgoing calls
in the credentials table. This one may be a bit tricky, as you need to
calculate the hash values in the ha1 and ha1b columns. I think there is
a tool "gen_ha1" that helps you with that. Alternatively, you can leave
the fields blank and instead set
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
in the config. In this case, SER is calculating those hashes on the fly.
Oh, wait. One fancy feature... How should I edit the
database tables
to cause all inbound calls to the user to be forwarded to a particular
URI?
Do this by setting the attribute "fwd_always_target" to the URI either
for the user in the user_attrs table or for the URI in the uri_attrs
table.
Best regards,
Martin
13 Jun
13 Jun
7:18 p.m.
New subject: [Serusers] serctl in 2.0 rc1 appears to be obsolete
Using the serctl that came with 2.0 rc1, I tried to add a user:
serctl add foo(a)directra.com asdf foo@bar
and got these errors:
ERROR 1146 (42S02) at line 1: Table 'ser.subscriber' doesn't exist
error: 500 Command 'ul_show_contact' not found
Browsing through the ser database, I see that there no longer is a
ser.subscriber table, which explains the first error.
The second error seems to indicate that the ul_show_contact command
that serctl tried to send to ser is also obsolete.
Does the 2.0 rc1 serctl work at all? (FWIW, the docs in ser.cfg refer
alternatively to "serctl" and ser_ctl". Interesting...)
Given that there is no longer a ser.subscriber database, how does one
add a subscriber?
If one were willing to poke values directly into the ser database
tables, is there any documentation available for them?
Finally, am I on a fool's errand trying to use 2.0 rc1? If so, would
you all recommend going back to 0.9 or trying to use the latest stuff
in cvs?
--
Mark Sidell
Partner
Forte, Inc.
919-942-7068
fax 919-969-2844
www.forteinc.com
14 Jun
14 Jun
1:53 a.m.
New subject: [Serusers] serctl in 2.0 rc1 appears to be obsolete
x-ser(a)sidell.org wrote:
Using the serctl that came with 2.0 rc1, I tried to
add a user:
serctl add foo(a)directra.com asdf foo@bar
and got these errors:
ERROR 1146 (42S02) at line 1: Table 'ser.subscriber' doesn't exist
error: 500 Command 'ul_show_contact' not found
Browsing through the ser database, I see that there no longer is a
ser.subscriber table, which explains the first error.
Correct. The serctl that comes with SER is still for the old 0.9
database. I think it isn't installed if you do a "make install"?
In any case. You want the new serctl which you can download at
ftp://ftp.iptel.org/pub/serctl/daily-snapshots
That is a Python thing and installation may be a bit awkward. In my
case, Python didn't find the libraries when installed using "make install".
Someone should probably have a look at this. The easiest fix (though
probably not the correct one, was to copy
/usr/local/lib/python2.4/site-packages/serctl into
/usr/lib/python2.3/site-packages (given that my old RHES4 was still on
Python 2.3).
Then you can use ser_ctl. Note that this is a bit high level and tuned
for serweb. If you don't want that, you can use the low-level utilities
that have a name based on what they do, like ser_domain for adding
domains, ser_user for adding users, ser_cred for adding credentials, and
ser_uri for adding URI-to-user mappings.
ser_attr can be used for assigning attributes to users, domains, and
URIs. It does insist, though, that the attribute in question is listed
in the table attr_types. I have never bothered to figure out how you add
them there, so I always just put attributes into the database directly.
If one were willing to poke values directly into the
ser database
tables, is there any documentation available for them?
Working on it. SER 2.1 will have man pages for the modules which among
other things will also explain the database tables used.
Finally, am I on a fool's errand trying to use 2.0
rc1? If so, would
you all recommend going back to 0.9 or trying to use the latest stuff
in cvs?
SER 2 has a couple of features that make life much easier. You can do a
lot of things in your ser.cfg that you had to write a module for
earlier. So, switching to 2.0 is definitely worth it. Plus, it can do
TCP and TLS properly which you may want to offer.
The official 2.0 release will appear really soon now. In the mean time,
you can use the latest CVS branch rel_2_0_0 or use the daily builds
from
http://ftp.iptel.org/pub/ser/daily-snapshots/testing
There will be no major changes to the final release any more.
Best regards,
Martin
25 Aug
25 Aug
9:59 p.m.
New subject: [Serusers] ser_ctl usrloc
Can someone give me an example of using ser_ctl to add a usrloc entry?
Thanks,
John
11:51 p.m.
New subject: [Serusers] log_fmt for default acc table
Does anyone have the log_fmt string for the new acc_db module's default acc
table on SER 2.0?
John
5 Jun
5 Jun
2:01 a.m.
Steven C. Blair wrote:
There are several classes of attributes though. This is an extension to
the old model where attributes where prefixed with "caller_" or
"callee_" depending on who they were for. This prefix is now "$t."
or
"$f." for "to" and "from". Addtionally, you can have
attributes for the
URI, user, domain, and globally. If you want to address those, the
prefix gets a second letter t, u, d, g respectively. Thus, "$tu.foo" is
the variable to for the from user.
[scb] Is URI the same as $ruri in SER0.9.x?
It is up to you to pick one. It could be the Request-URI (which was
$ruri before and is @ruri now), it could be the URI in the From (which
is @from.uri now), or even, although that doesn't make much sense, the
URI in the Contact (which would be @contact.uri). You decide by passing
a select to the load_attrs() function.
[scb] Please explain how "$tu.foo" is the
variable to for the from
user. I do not understand.
No wonder, it isn't. That was nonsense. "$tu.foo" is, of course, the
variable (or rather: attribute) foo for the to user. Probably should
re-read my postings before sending.
Regards,
Martin
5965
days inactive
6049
days old
32 comments
6 participants
participants (6)
-
Jiri Kuthan -
John G. Rose -
Martin Hoffmann -
Stefan Sayer -
Steven C. Blair -
x-ser＠sidell.org