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:

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 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) 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

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 $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. 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: 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

x-ser(a)sidell.org 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

x-ser(a)sidell.org wrote: This seems to have changed a bit. Check out the permissions module. It's README file should explain the usage. Regards, Martin

x-ser(a)sidell.org wrote: It should. Although you can replace the regexp in the condition with @ruri.user == 7605796638 But the old way should still work. Probably in route[SITE_SPECIFIC]. 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

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

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

On Sat, 14 Jun 2008 07:55:31 +0200, Martin Hoffmann 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

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

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

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

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

Can someone give me an example of using ser_ctl to add a usrloc entry? Thanks, John

Steven C. Blair wrote: 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. 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