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

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: !@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

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@iptel.org] Sent: Wednesday, June 04, 2008 9:05 PM To: Steven C. Blair Cc: Martin Hoffmann; serusers@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: !@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

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!

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!

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!

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

x-ser@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

x-ser@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

x-ser@sidell.org wrote:

On Sat, 14 Jun 2008 07:55:31 +0200, Martin Hoffmann wrote:

...

x-ser@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.

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.

That one should have the phone2tel core parameter. If it doesn't, you can safely comment out the line.

Regards, Martin

x-ser@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

x-ser@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

x-ser@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

x-ser@sidell.org wrote:

Using the serctl that came with 2.0 rc1, I tried to add a user:

serctl add foo@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

Does anyone have the log_fmt string for the new acc_db module's default acc table on SER 2.0?

John