sip-router.org
http://sip-router.org/wiki/
2012-02-05T03:20:49+01:00sip-router.org
http://sip-router.org/wiki/
http://sip-router.org/wiki/lib/tpl/sr-monobook/images/favicon.icotext/html2012-01-19T12:38:02+01:00devel:irc-meetings:next
http://sip-router.org/wiki/devel/irc-meetings/next?rev=1326973082&do=diff
<pre>
@@ -1 +1 @@
- If inoframiotn were soccer, this would be a goooooal!
+ TBA
</pre>text/html2012-01-14T17:28:27+01:00wiki:navigation - old revision restored
http://sip-router.org/wiki/wiki/navigation?rev=1326558507&do=diff
<pre>
@@ -1 +1,13 @@
- A wonderful job. Super helpful inforamiton.
+ ** Wiki **
+ {{indexmenu>..#1|js navbar nocookie}}
+
+ ** Other **
+ * [[http://sip-router.org|Home]]
+ * [[http://lists.sip-router.org|Mailing Lists]]
+ * [[http://git.sip-router.org|Git Repository]]
+ * [[http://sip-router.org/tracker|Bug Tracker]]
+ * [[http://sip-router.org/doxygen/sip-router/branch/master/|Doxygen Docs]]
+ * [[http://sip-router.org/docbook/sip-router/branch/master/|Docbook Docs]]
+ * [[http://kamailio.org/dokuwiki|Kamailio wiki]]
+ * [[http://sip-router.org/wiki/doku.php?do=recent|Recent Changes]]
+
</pre>text/html2012-01-14T17:27:47+01:00start - old revision restored
http://sip-router.org/wiki/start?rev=1326558467&do=diff
<pre>
@@ -1 +1,81 @@
- dvgnYz , [url=http://dxenaitajgyt.com/]dxenaitajgyt[/url], [link=http://vnmmgnnwkzqr.com/]vnmmgnnwkzqr[/link], http://dpnzhjrqfezi.com/
+ ====== SIP Router Project - Wiki Site ======
+
+ The wiki is open, anybody is welcome to contribute here. If you do not want to edit pages anonymously or tired of solving [[wp>Captcha]] puzzles then you can [[https://sip-router.org/wiki/start?do=register| create an account]].
+
+ ===== Documentation =====
+
+ ==== Docbook Documentation ====
+
+
+ | Version ^ Main Index ^ Modules Index ^ Modules_k Index ^ Modules_s Index ^
+ ^ Devel (Master Branch) | [[http://sip-router.org/docbook/sip-router/branch/master/|link]] | [[http://sip-router.org/docbook/sip-router/branch/master/modules/|link]] | [[http://sip-router.org/docbook/sip-router/branch/master/modules_k/|link]] | [[http://sip-router.org/docbook/sip-router/branch/master/modules_s/|link]] |
+ ^ Version 3.2 | [[http://sip-router.org/docbook/sip-router/branch/3.2/|link]] | [[http://sip-router.org/docbook/sip-router/branch/3.2/modules/|link]] | [[http://sip-router.org/docbook/sip-router/branch/3.2/modules_k/|link]] | [[http://sip-router.org/docbook/sip-router/branch/3.2/modules_s/|link]] |
+ ^ Version 3.1 | [[http://sip-router.org/docbook/sip-router/branch/3.1/|link]] | [[http://sip-router.org/docbook/sip-router/branch/3.1/modules/|link]] | [[http://sip-router.org/docbook/sip-router/branch/3.1/modules_k/|link]] | [[http://sip-router.org/docbook/sip-router/branch/3.1/modules_s/|link]] |
+ ^ Version 3.0 | [[http://sip-router.org/docbook/sip-router/branch/3.0/|link]] | [[http://sip-router.org/docbook/sip-router/branch/3.0/modules/|link]] | [[http://sip-router.org/docbook/sip-router/branch/3.0/modules_k/|link]] | [[http://sip-router.org/docbook/sip-router/branch/3.0/modules_s/|link]] |
+
+ ===== Cookbooks =====
+
+
+ | Version ^ Core Cookbook ^ Pseudo-Variables ^ Transformations ^ Selects ^Cfg Vars List ^RPCs List^ Counters/stats List^
+ ^ Devel (Master Branch) | [[cookbooks:core-cookbook:devel|link]] | [[cookbooks:pseudo-variables:devel|link]] | [[cookbooks:transformations:devel|link]] | [[cookbooks:selects:devel|link]] | [[http://sip-router.org/docbook/sip-router/branch/master/cfg_list/cfg_var_list.html|link]] | [[http://sip-router.org/docbook/sip-router/branch/master/rpc_list/rpc_list.html|link]] | [[http://sip-router.org/docbook/sip-router/branch/master/counter_list/counter_list.html|link]] |
+
+
+ ===== Tutorials =====
+
+ * [[tutorials:makefile-system|Makefile System]]
+ * [[tutorials:alias-example|Alias Example]]
+ * [[tutorials:contribute-to-dokuwiki|Contribute to Dokuwiki]]
+
+ ===== APIs =====
+
+ * [[api:lua:devel|Lua API]]
+ * [[api:perl:devel|Perl API]]
+ * [[api:python:devel|Python API]]
+
+ ===== Development =====
+
+ * [[devel:create-library|Create a library in SIP Router]]
+ * [[devel:kamailio-integration|Kamailio Integration Status]]
+ * [[devel:ser-integration|ser Integration Status]]
+ * [[devel:avps-ser|AVPs in SER]]
+ * [[devel:xavp|eXtended AVPS]]
+ * [[http://sip-router.org/docbook/sip-router/branch/master/rpc/ser_rpc.html|RPCs]]
+ * [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=doc/cfg.txt;hb=HEAD|Runtime CFG Variables]]
+ * [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=doc/timers.txt;hb=HEAD|Timers]]
+ * [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=doc/modules_init.txt;hb=HEAD|Module Initialization & Forking New Processes]]
+ * [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=doc/logging-api.txt;hb=HEAD|Logging API]]
+ * [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=doc/locking.txt;hb=HEAD|Locking]]
+ * [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=doc/parse_headers.txt;hb=HEAD|Parse Headers API Changes]]
+ * [[devel:import-k-module|Import Kamailio Module]]
+ * [[devel:git-commit-guidelines|GIT Commit Guidelines]]
+ * [[devel:irc-meetings:index|Devel IRC Meetings]]
+
+ ===== Migration =====
+
+ * [[install:3.1.x-to-3.2.x|Upgrade from 3.1.x to 3.2.x]]
+ * [[install:3.0.x-to-3.1.x|Upgrade from 3.0.x to 3.1.x]]
+ * [[migration:kamailio-tips|Tips For Kamailio 1.5.x Migration]]
+ * [[migration:kamailio-module-docbook|Kamailio 1.5.x Module Docbook Migration]]
+ * [[migration:kamailio-3.0-config|Kamailio 3.0 Config]] (checkout, build, install and configure Kamailio 3.0 devel version)
+ * [[migration:new-features-for-k-users|New features for Kamailio 1.5.x users]]
+ * [[migration:ser-2.1-migration|Tips for Migration from ser 2.1 ]]
+
+ ===== GIT =====
+
+ * [[git|GIT Tutorials Index]]
+
+ ===== Features =====
+
+ * [[features:new-in-devel|New features in devel version]]
+ * [[features:new-in-3.1.x|New features in 3.1.x version]]
+ * [[features:new-in-3.0.x|New features in 3.0.x version]]
+ * [[features:inherited-features|Inherited features]]
+
+ ===== Performance =====
+
+ * [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=doc/tcp_tunning.txt;hb=HEAD|TCP Tunning]]
+
+ ===== Other =====
+
+ * [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=doc/dns.txt;hb=HEAD|Sip-Router and DNS]]
+ * [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=doc/dst_blacklist.txt;hb=HEAD|Sip-Router IP Blacklists]]
</pre>text/html2012-01-11T07:14:29+01:00features:new-in-devel - old revision restored
http://sip-router.org/wiki/features/new-in-devel?rev=1326262469&do=diff
<pre>
@@ -1 +1 @@
- Yo, that's what's up trutfhluly.
+ Just what the docotr ordered, thankity you!
</pre>text/html2012-01-11T05:50:32+01:00talk:history - created
http://sip-router.org/wiki/talk/history?rev=1326257432&do=diff
<pre>
@@ -1 +1 @@
-
+ Normally I'm against killing but this article slauthgered my ignorance.
</pre>text/html2012-01-09T07:39:43+01:00meetings:berlin_2009 - THeWJMei
http://sip-router.org/wiki/meetings/berlin_2009?rev=1326091183&do=diff
<pre>
@@ -1,290 +1 @@
- <code>
- 1 SIP-Router Development Meeting
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- FhG FOKUS Berlin
- 2nd October 2009
-
- This is the minutes from the sip-router meeting held on the 2nd of October
- 2009 in FhG FOKUS in Berlin. The minutes were taken by Jan Janak.
-
- 1.1 Meeting Agenda
- ===================
- * Release of sip-router
- * Short name selection
- * Conflict resolution
- * SEMS Advertisement
- * Project Infrastructure
-
- 1.2 Participants
- =================
- * Ancuta Onofrei
- * Dragos Vingarzan
- * Jan Janak
- * Andrei Pelinescu-Onciul
- * Bogdan Pintea
- * Stefan Sayer
- * Jesus Rodriguez
- * Henning Westerholt
- * Daniel-Constantin Mierla
- * Grzegorz Stanislawski
- * Ramona-Elena Modroiu
- * Marcus Gotzl
- * Markus Hungr
- * Jiri Kuthan
- * Christian Kaiser
- * Bogdan Harjoc
-
- 1.3 Minutes
- ============
-
- 1.3.1 Release of sip-router
- ----------------------------
- * Jan: Updating meeting participands on the status of the email discussion
- that took place before the meeting.
-
- * Daniel:
- - There is a lot of confusion about tools and modules.
- - We don't have a short name and renaming it again will generate
- additional confusion.
- - we planned to have separate release to help kamailio users to get
- adjusted to the new architecture.
- - I do not agree on having two releases at the same time.
-
- * Andrei: We always talked about the linux distribution model.
-
- * Jan: Shouldn't we release sip-router and then make a kamailio release
- from that?
-
- * Daniel: The statistics code is not multi-CPU ready.
-
- * Stefan:
- - You need to have a hook in the repository to release.
- - Isn't the branch that you create for release like a sr release?
-
- * Andrei: We want to release sip-router 3.0.
-
- * Daniel: I do not want to be involved in 2 projects.
-
- * Jan: You already are involved in two projects anyway.
-
- * Henning: How about having different branches for different flavors.
-
- * Daniel: We want to release Kamailio with all K. modules and selected SER
- modules.
-
- * Andrei: It's not a problem if you give users more sources, you do not
- have to remove modules/code that is not supported.
-
- * Daniel: We do not have the approach of "this is not supported" in Kamailio.
-
- * Jan: One reason why people haven't started testing the sr stuff is
- because we have not announced the intention to make a release.
-
- * Daniel: I don't see a solution to advertise two things, I cannot say
- which is better.
-
- * Jiri: To accomodate your customers, you are withdrawing from sip-router,
- so that you do not confuse them?
-
- * Andrei: if you say it is k 3.0 based on sip-router 3.0, is it ok?
-
- * Daniel: Yes, it's your sip-router release.
-
- * Gregorz: Is sip-router going to be a complete solution?
-
- * Jan: We hope that eventually it will.
-
- * Jiri: in order to have achievable milestones, it is too ambitious to
- have a full solution now.
-
- * Gregorz: ser has serweb, kamailio has siremis, can we treat a sip-router
- as tool, just like linux kernel, you will have independent distributions
- and it does not create confusion, you have invested into kamailio trade
- mark
-
- * Daniel:
- - My concern is one month being involved in two releases that do
- the same thing.
- - sip-router we started as project, we advanced more, we planned to have
- common core and tm.
-
- * Jiri: I am confused by the fact that you want to save labor, but have a
- different release at the same time.
-
- * Andrei: New versions are no longer Kamailio, they are Kamailio based on
- sip-router.
-
- * Daniel: OK, then my involvement in next sr (devel) release will be zero.
-
- * Jiri: it is about sharing the foundation.
-
- * Stefan: Isn't it ok to make 3.0 branch and everybody knows this is
- foundation for Kamailio and SER?
-
- * Andrei: It is fair to name it sip-router because this is what it is.
-
- * Daniel: there will be two products that do the same thing.
-
- * Jan: We already have multiple products that do roughly the same, so
- this is nothing new.
-
- * Daniel: (drawing a diagram of the sources and release)
-
- * Andrei: There is a lot of confusion about whether we are aiming for a
- full release or not.
-
- * Jiri: maybe we shall forget the perceptional stuff for a while? and look
- at code sharing?
-
- * Jan as scribe: (the discussion is getting a bit confusing and difficult
- to follow and write down)...
-
- * Henning: I talked to some users, there is confusion about differences
- between sip-router and kamailio, but it can be explained...
-
- * Jan: People ask me for public tarball of sip-router for installations I
- maintain.
-
- * Henning: It is common to have alpha and beta releases. (there is a
- general agreement in the room with Henning's statement).
-
- * Jesus: Can we delay the sr release 2-3 weeks? (everybody agrees).
-
- * Daniel:
- - I don't want to be involved in it (devel release), you can do whatever, I
- cannot be involved.
- - I won't be promoting the sip-router devel release.
-
- * Dragos: It is not going to be distributed through standard distributions
- like Ubuntu yet?
-
- * Jan,Andrei: No, we are not there yet.
-
- * Jan as scribe: (licensing discussion, I got lost in it)
-
- * Henning: So we will have k3.0 and a developer release of sip-router
-
- * Jiri: So we will have a release marked as development
-
- 1.3.2 Short Name
- -----------------
- * Jiri:
- - How do we select short name for the application?
- - Have 1 week for proposals?
- - How do we select who is going to vote?
-
- * Andrei: Everybody who who has at least one commit in all the projects.
-
- * Ramona: For active modules
-
- * Jan: Since the beginning of the project.
-
- * Jiri: past 3 years might be better.
-
- * Andrei: At least 1 commit in 3 years and non-compete provisions.
-
- * Daniels: Let's have registered voters.
-
- * Jiri: Use doodle
-
- * Jan: There will be a deadline, voting is right, not obligation (in
- response to Daniels concern).
-
- * Ancuta: Both projects prepare list of voters
-
- * scribe: there is a consensus that we will approach those who had at
- least one commit in past three years.
-
- * Stefan: Make it clear that users and other people are not included.
-
- * Daniel
- - Community only via anonymous proposals.
- - Don't discuss, just vote.
-
- * Andrei: requirements: no conflicts, shorter version of sip router, less
- or equal than sip-router, shouldn't be an existing application in debian
- or clear trademark. not overlapping with debian package names.
-
- 1.3.3 Resolution Procedures
- ----------------------------
- * Jiri:
- - We have rough consensus that we want to have them.
- - Tt has to be clearly defined (which implies some infairness)
- - Important is that we choose something that is fair and easy to
- understand.
-
- 1.3.4 Resolving Technical Conflicts
- ------------------------------------
- * Jan: Do we need it for the project?
-
- * Daniel: Yes, we had the problem before.
-
- * Daniel: With Kamailio fork it started with a very late commit of local
- route.
-
- * Andrei: Let's have a board.
-
- * Andrei: It is a hard problem, the technical part is not simple.
-
- * Daniel: We end up in political discussions anyway.
-
- * Jiri: Not sure if we need to have a general consensus on that.
-
- * Daniel: I am concerned mainly about the core and tm.
-
- 1.3.5 SIP-Router in Three Years
- --------------------------------
- * Daniel: bigger project, bigger community, trying to build a bigger open
- source project with bigger community.
-
- * Jiri: For Tekelec there is little motivation for promotion.
-
- * Daniel: Why are we having two versions of some modules that depend on
- database, such as rr or sl modules?
-
- * Daniel: We mark features that we obsolete and keep them one release
-
- * Daniel: that does not apply to features that can be done in another way
-
- 1.3.6 OpenSSL License Issue
- ----------------------------
- * Jan: Giving an overview of the problem and possible solutions, this is
- based on a description sent out earlier by email.
-
- * Jan: suggests that we attempt to solve this by approaching as many
- people as we can and we see how far we can get and if we can add an
- exception to the license.
-
- * scribe: The discussion is about whether the exception is needed in the
- whole application or only the TLS module.
-
- * Ramona: is concerned about (c) owning companies.
-
- * Daniel: Lots of contributors on kamailio side dissappeared.
-
- * scribe: resolution seems to be: let's try approach them and see what
- happens.
-
- 1.3.7 Database Schema Merge
- ----------------------------
- * Jan: presenting the document sent out earlier:
- http://iptel.org/jan/db_merge
- * Daniel: concerned about some presence table where we cannot use UID.
- * scribe: most of discussion revolving around some low-level technical
- details.
- * scribe: resolution: Let's merge the easy tables, and then we will see
- how to go futher, Jan and Henning will figure out how to to merge the
- easy tables and store their definition in the repository.
-
- 1.3.8 SEMS
- -----------
- * Stefan: Giving a presentation about SEMS and its features, Stefan will
- send a link to the presentation to the mailing list.
-
- 1.3.9 Project Infrastructure
- -----------------------------
- * Daniel: What is current status?
- * Jan: The domain and server owned and paid by Jan. In long term we should
- have a foundation-like status so that the domain is not owned by a
- single person. We should also have a transparent bank account.
- </code>
+ It's spooky how celevr some ppl are. Thanks!
</pre>text/html2012-01-09T01:22:34+01:00git:merge-into-master - EKKjsDlJvj
http://sip-router.org/wiki/git/merge-into-master?rev=1326068554&do=diff
<pre>
@@ -1,65 +1 @@
- ===== GIT merge into master howto =====
-
- * if you don't have a local **master** branch tracking **origin/master** (git branch|grep master is empty)
- <code>
- git fetch origin
- git checkout --track -b master origin/master
- </code>
-
- * if you already have a local **master** branch tracking **origin/master**
-
- <code>
- git checkout master
- # make sure we have the up-to-date "origin" branches
- git fetch origin
- # make sure the local "master" branch is up-to-date
- git pull --rebase origin master
- </code>
-
- * do the actual merge
-
- <code>
- # merge the branch into the local "master" branch
- git merge --log --no-ff origin/branch_to_merge # for older git version, make sure merge.summary is true and skip --log
- git log -1 # make sure you see a correct merge message (with summary), if not abort
- git log ORIG_HEAD.. # make sure the commits shown are what you wanted to merge, if not abort
- gitk # optional, look if the commit tree looks ok
- # only if everything is ok and you looked at the log
- # push the changes on the local "master" branch to the repository "master" branch
- git push origin master:master
- </code>
-
- * if you did something wrong and pushed and it cannot be easily corrected by a git revert, send an email to sr-dev@lists.sip-router.org asking to revert master to the previous state (this should be avoided in general since it would cause extra work for all people who fetched or pulled master in the meantime)
-
- * if you need to abort or undo a merge attempt and you don't have any local changes that you want to keep and you haven't pushed back to origin (if you did, see above), use:
- <code>
- git reset --hard ORIG_HEAD # WARNING: all local changes to the current branch will be lost
- </code>
-
- * don't try to merge the reverse way, e.g.: git checkout my_branch; git merge master; git push origin my_branch:master. The merge is equivalent to the above one (from the code point of view), but the merge commit message will be wrong.
-
- ===== GIT commit from local branch into master =====
-
- If all you want to do is commit some changes you have in a local branch (called "my_local_branch" from now on), then you could use:
- <code>
- # change to my local branch
- git checkout my_local_branch
- # make sure we have the latest version of the "origin" branches
- git fetch origin
- # rebase "my_local_branch" to the current origin/master
- git rebase origin/master
- # if everything is ok and you don't have any rebase conflicts, push the
- # changes to the repository master branch
- git push origin my_local_branch:master
- </code>
- Alternatively you could use git pull --rebase instead of git rebase:
- <code>
- # change to my local branch
- git checkout my_local_branch
- git fetch origin
- # rebase on the latest origin/master version
- git pull --rebase --ff origin master
- # if everything is ok and you don't have any rebase conflicts, push the
- # changes to the repository master branch
- git push origin my_local_branch:master
- </code>
+ Your's is the itnleliegnt approach to this issue.
</pre>text/html2012-01-08T23:19:51+01:00tbd:db_unix - AIyiDHyVljPLmUUW
http://sip-router.org/wiki/tbd/db_unix?rev=1326061191&do=diff
<pre>
@@ -1,115 +1 @@
- ====== Integration With UNIX/Linux User Database ======
-
- **Contacts**: [[jan@iptel.org|Jan Janak]], [[andrei@iptel.org|Andrei Pelinescu-Onciul]]
-
- ===== Abstract =====
- The goal of this work is to develop an extension module for sip-router that
- will provide support for authentication, authorization, and configuration **the
- UNIX way**, that is ''/etc/passwd'', ''/etc/group'' and plain-text files stored in
- user's home directory. With this module loaded the sip-router server will be
- able to integrate with name services and databases commonly available in UNIX-like
- systems.
-
- ===== State of the Art =====
- Every non-trivial sip-router setup requires a database server to store all kinds
- of data particular to the operation of the SIP server. All users' data, such as
- authentication usernames, passwords and user location contacts, is then stored
- in the database. The administrator usually needs to populate the database with
- some initial data whenever a new user is added to the system. Even simple
- operations, for example when a user decides to change his/her password for SIP
- digest authentication, require the use of a provisioning system (serweb,
- serctl) or the administrator has to use the SQL interface of the database to
- issue one or more SQL commands.
-
- The sip-router server supports a wide variety of database systems (mysql,
- postgres, oracle, berkeley db) through its internal database abstraction
- layer. The database abstraction layer is flexible and adding support for a new
- database type (not necessarily SQL based) is a simple and straightforward
- process. Typically there is no need to modify other extension modules of the
- server because most of them access the database exclusively through the
- database abstraction layer.
-
- Running a dedicated fully-featured database server for a small SIP server
- setup, serving maybe no more then a couple of users, seems like an
- overkill. Yet, there is currently no easy way of achieving this without
- setting up something like mysql. We have support for several embedded
- databases, such as the berkeley db, but even such databases require standalone
- provisioning tools and maintenance.
-
- ===== Goals =====
- The aim of this work is to develop an extension module for sip-router which
- will interface to the database abstraction layer in sip-router on one side to
- traditional UNIX/Linux facilities for user authentication and user management
- on the other side. This module will then (when used instead of a traditional
- database module such as db_mysql) make it possible to use the UNIX/Linux user
- database in ''/etc/passwd'' for authentication, PAM (Pluggable Authentication
- Modules) system for authorization, and so on.
-
- ==== Required features ====
- === Version 1 (strawman) ===
- * Use ''/etc/passwd'' as the user database
- * Digest authentication password stored in ''~/.sr''
- * User location data stored in ''~/.sr''
- * Authorization to use the service using ''/etc/group'' (i.e. only members of sip group will be allowed to register and make calls).
-
- === Version 2 (deluxe) ===
- * PAM-enabled authorization
- * Selected configuration for a user (a set of name-value pairs) can be stored in a plain-text file in ''~/.sr'' (like ''~/.ssh/config'')
- * Keep ''/var/log/wtmp'' up-to-date when user registers/un-registers
- * Accounting in ~
- * Tool to administer the digest password in ''~/.sr''
-
- ===== Overview of Operation =====
- The administator of a Linux host installs the sip-router. The sip-router comes
- with a default configuration file with all important features, such as digest
- authentication and registrar, enabled. He/she configures the sip-router server
- to use ''db_unix'' module as the desired database driver (instead of the default
- db_mysql).
-
- The adminstrator decides to let user jan use the newly installed SIP
- server. The administrator creates a new user with adduser:
-
- <code>
- # adduser jan
- </code>
-
- and after filling all the personal information the user is created in the
- system, his home directory is set to ''/home/jan''. The administrator sets an
- initial digest authentication password for the user:
-
- <code>
- # sippasswd jan
- </code>
-
- The tool saves the password in ''/home/jan/.sr/passwd'' in either plain-text or
- sha1 format, along with all information necessary for digest authentication.
-
- User ''jan'' configures his SIP phone with username ''jan'', hostname of the Linux
- host and the password given to him by the adminstrator and the phone sends a
- REGISTER message and after the obligatory digest authentication round-trip,
- the server gets the user's password from ''/home/jan/.sr/password'' and verifies
- the digest crendentials.
-
- Optionally, the server may use PAM or consult ''/etc/group'' to verify that the
- user has access to the SIP service. If the user has ''~/.sr/config'' then the SIP
- server loads the contents of the file before processing the SIP message.
-
- If the registration was successfull then the SIP server saves all the contacts
- registered by the user's phone in his ''~/.sr/usrloc'' and optionally updates wtmp
- if the user is registered.
-
- When an INVITE arrives for ''jan@host'', the sip server again loads the
- configuration from ''/home/jan/.sr/config'' and then the list of contacts from
- ''/home/jan/.sr/usrloc'' and forwards the INVITE request. The SIP server may also
- record the SIP call in Jan's ''~/.sr'' if ''db_unix'' module supports accouting.
-
- The user (jan) may ssh into the SIP server host and customize his SIP
- configuration by editing ''~/.sr/config''
-
- ===== Reading List =====
- * [[http://en.wikipedia.org/wiki/Pluggable_Authentication_Modules|PAM (Pluggable Authentication Modules)]]
- * [[http://www.kernel.org/pub/linux/libs/pam/|Linux PAM]]
- * ''man 3 login''
- * ''man passwd''
- * ''man group''
-
+ Could you write about Physics so I can pass Scneice class?
</pre>text/html2012-01-08T20:56:07+01:00migration:new-features-for-k-users - dPcPGFnpH
http://sip-router.org/wiki/migration/new-features-for-k-users?rev=1326052567&do=diff
<pre>
@@ -1,4 +1 @@
- ====== Features For Kamailio Users ======
-
- * see: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x
-
+ Way to go on this essay, heelpd a ton.
</pre>text/html2011-12-09T23:26:46+01:00cookbooks:pseudo-variables:3.0.xl - old revision restored
http://sip-router.org/wiki/cookbooks/pseudo-variables/3.0.xl?rev=1323469606&do=diff
<pre>
@@ -1 +1,896 @@
- A piece of erudition ulnkie any other!
+ ====== SIP Router Pseudo-Variables ======
+ **Version: 3.0.x**
+
+ ===== Introduction =====
+
+ The term “pseudo-variable” is used for special tokens that can be given as parameters to different script functions and they will be replaced with a value before the execution of the function.
+
+ The beginning of a “pseudo-variable” is marked by the character “$”. If you want to have the character “$” just double it “$$”.
+
+ There is a set of predefined pseudo-variables, which have the name composed from one to three letters, and special pseudo-variables that are references to dynamic fields (AVP and Headers)
+
+ Pseudo-Variables are implemented by various modules, most of them are provided by [b]pv[/b].
+
+ ===== Pseudo-variables usage =====
+
+
+ Pseudo-variables can be used with many modules, among them:
+
+ * acc
+ * avpops
+ * htable
+ * textops
+ * uac
+ * xlog
+
+ ===== The list of pseudo-variables=====
+
+
+ Predefined pseudo-variables are listed in alphabetical order.
+
+ ==== Pseudo-variable marker ====
+
+ **$$** - represents the character '$'
+
+ ==== URI in SIP Request's P-Asserted-Identity header ====
+
+ **$ai** - reference to URI in request's P-Asserted-Identity header (see RFC 3325)
+
+ ==== Auth Digest URI ====
+
+ **$adu** - URI from Authorization or Proxy-Authorization header. This URI is used when calculating the HTTP Digest Response.
+
+ ==== Auth realm ====
+
+ **$ar** - realm from Authorization or Proxy-Authorization header
+
+
+ ==== Auth username user ====
+
+ **$au** - user part of username from Authorization or Proxy-Authorization header
+
+
+ ==== Auth username domain ====
+
+ **$ad** - domain part of username from Authorization or Proxy-Authorization header
+
+
+ ==== Auth whole username ====
+
+ **$aU** - whole username from Authorization or Proxy-Authorization header
+
+ ==== Acc username ====
+
+ **$Au** - username for accounting purposes. It's a selective pseudo variable (inherited from acc module). It returns $au if exits or From username otherwise.
+
+
+ ==== Branch attributes ====
+
+ **$branch(name)** - reference to attribute 'name' of a branch
+
+ This pseudo variable gives you access to the "additional branches" only, not to the "main branch". E.g. if there are 3 clients registered for the same AoR, after lookup() you will have one contact in the "main branch" and two "additional branches". Using $branch() you can access the additional branches, the main branch can be accessed using $ru and $du. (Note: In branch_routes there is no distinction between the main and the additional branches - the branch_route will be called for all of them.)
+
+ The 'name' can be:
+
+ * uri - return uri of the branch
+ * dst_uri - return destination uri (next hop address)
+ * q - return the q value of the branch
+ * path - return the path vector for the branch
+ * send_socket - return the socket to be used to send the branch
+ * flags - return the branch flags value
+ * count - return the number of the branches
+
+ The PV can take an index to access a specif branch: $(branch(name)[index])
+
+ Example:
+
+ <code>
+ $var(i)=0;
+ while($var(i)<$branch(count))
+ {
+ xlog("$(branch(uri)[$var(i)])\n");
+ $var(i) = $var(i) + 1;
+ }
+ </code>
+
+
+ ==== Request's first branch ====
+
+ **$br** - reference to request's first branch
+
+ <hi #d0d0d0>It is R/W variable, you can assign values to it directly in configuration file (will add a new branch).</hi>
+
+ ==== Request's all branches ====
+
+ **$bR** - reference to request's all branches
+
+ ==== Branch flags ====
+
+ **$bf** - reference to branch flags of branch 0 (RURI) - decimal output
+
+
+ ==== Branch flags ====
+
+ **$bF** - reference to branch flags of branch 0 (RURI) - hexa output
+
+ ==== Body size ====
+
+ **$bs** - body size
+
+ ==== Call-Id ====
+
+ **$ci** - reference to body of call-id header
+
+ ==== Content-Length ====
+
+ **$cl** - reference to body of content-length header
+
+ ==== CSeq ====
+
+ **$cs** - reference to the sequence number in the cseq header. The method in the CSeq header is identical to the request method, thus use $rm to get the methode (works also for responses).
+
+ ==== Contact header ====
+
+ **$ct** - reference to body of contact header
+
+
+ ==== Content-Type ====
+
+ **$cT** - reference to body of content-type header
+
+ ==== Domain of destination URI ====
+
+ **$dd** - reference to domain of destination uri
+
+
+ ==== Diversion header URI ====
+
+ **$di** - reference to Diversion header URI
+
+ ==== Diversion "privacy" parameter ====
+
+ **$dip** - reference to Diversion header "privacy" parameter value
+
+ ==== Diversion "reason" parameter ====
+
+ **$dir** - reference to Diversion header "reason" parameter value
+
+
+
+ ==== Port of destination URI ====
+
+ **$dp** - reference to port of destination uri
+
+ ==== Transport protocol of destination URI ====
+
+ **$dP** - reference to transport protocol of destination uri
+
+ ==== Destination set ====
+
+ **$ds** - reference to destination set
+
+
+ ==== Destination URI ====
+
+ **$du** - reference to destination uri
+ If loose_route() returns TRUE a destination uri is set according to the first Route header.
+ $du is also set if lookup() function of 'registrar' module finds contact(s) behind NAT.
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+
+ To reset $du:
+ $du = null;
+
+ ==== Error class ====
+
+ **$err.class** - the class of error (now is '1' for parsing errors)
+
+ ==== Error level ====
+
+ **$err.level** - severity level for the error
+
+ ==== Error info ====
+
+ **$err.info** - text describing the error
+
+ ==== Error reply code ====
+
+ **$err.rcode** - recommended reply code
+
+ ==== Error reply reason ====
+
+
+ **$err.rreason** - recommended reply reason phrase
+
+ ==== From URI domain ====
+
+ **$fd** - reference to domain in URI of 'From' header
+
+ ==== From display name ====
+
+ **$fn** - reference to display name of 'From' header
+
+ ==== From tag ====
+
+ **$ft** - reference to tag parameter of 'From' header
+
+ ==== From URI ====
+
+ **$fu** - reference to URI of 'From' header
+
+ ==== From URI username ====
+
+ **$fU** - reference to username in URI of 'From' header
+
+ ==== SIP message buffer ====
+
+ **$mb** - reference to SIP message buffer
+
+ ==== Flags ====
+
+ **$mf** - reference to message/transaction flags set for current SIP request
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+
+ ==== Flags in hexadecimal ====
+
+ **$mF** -reference to message/transaction flags set for current SIP request in hexa-decimal
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+
+ ==== SIP message id ====
+
+ **$mi** - reference to SIP message id
+
+ ==== SIP message length ====
+
+ **$ml** - reference to SIP message length
+
+ ==== Domain in SIP Request's original URI ====
+
+ **$od** - reference to domain in request's original R-URI
+
+ ==== Port of SIP request's original URI ====
+
+ **$op** - reference to port of original R-URI
+
+ ==== Transport protocol of SIP request original URI ====
+
+ **$oP** - reference to transport protocol of original R-URI
+
+ ==== SIP Request's original URI ====
+
+ **$ou** - reference to request's original URI
+
+ ==== Username in SIP Request's original URI ====
+
+ **$oU** - reference to username in request's original URI
+
+ ==== Domain in SIP Request's P-Preferred-Identity header URI ====
+
+ **$pd** - reference to domain in request's P-Preferred-Identity header URI (see RFC 3325)
+
+ ==== Display Name in SIP Request's P-Preferred-Identity header ====
+
+ **$pn** - reference to Display Name in request's P-Preferred-Identity header (see RFC 3325)
+
+
+ ==== Process id ====
+
+ **$pp** - reference to process id (pid)
+
+ ==== Protocol of received message ====
+
+ **$pr** or **$proto** - protocol of received message (UDP, TCP, TLS, SCTP)
+
+ ==== User in SIP Request's P-Preferred-Identity header URI ====
+
+ **$pU** - reference to user in request's P-Preferred-Identity header URI (see RFC 3325)
+
+ ==== URI in SIP Request's P-Preferred-Identity header ====
+
+ **$pu** - reference to URI in request's P-Preferred-Identity header (see RFC 3325)
+
+
+ ==== Domain in SIP Request's URI ====
+
+ **$rd** - reference to domain in request's URI
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+
+ ==== Body of request/reply ====
+
+ **$rb** - reference to message body
+
+
+
+ ==== Returned code ====
+
+ **$rc** - reference to returned code by last invoked function
+
+ **$retcode** - same as **$rc**
+
+ ==== Remote-Party-ID header URI ====
+
+ **$re** - reference to Remote-Party-ID header URI
+
+ ==== SIP request's method ====
+
+ **$rm** - reference to request's method. Works also for replies (by using the CSeq header)
+
+ ==== SIP request's port ====
+
+ **$rp** - reference to port of R-URI
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+
+ ==== Transport protocol of SIP request URI ====
+
+ **$rP** - reference to transport protocol of R-URI
+
+ ==== SIP reply's reason ====
+
+ **$rr** - reference to reply's reason
+
+ ==== SIP reply's status ====
+
+ **$rs** - reference to reply's status
+
+ ==== Refer-to URI ====
+
+ **$rt** - reference to URI of refer-to header
+
+ ==== SIP Request's URI ====
+
+ **$ru** - reference to request's URI
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+
+ ==== Username in SIP Request's URI ====
+
+ **$rU** - reference to username in request's URI
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+
+ ==== Received IP address ====
+
+ **$Ri** - reference to IP address of the interface where the request has been received
+
+ ==== Received port ====
+
+ **$Rp** - reference to the port where the message was received
+
+ ==== Script flags ====
+
+ **$sf** - reference to script flags - decimal output
+
+
+ ==== Script flags ====
+
+ **$sF** - reference to script flags - hexa output
+
+ ==== IP source address ====
+
+ **$si** - reference to IP source address of the message
+
+ ==== Source port ====
+
+ **$sp** - reference to the source port of the message
+
+ ==== Statistics ====
+
+ **$stat(name)** - return the value of statistic item specified by 'name'
+
+ ==== Forced socket ====
+
+ **$fs** - reference to the forced socket for message sending (if any) in the form proto:ip:port
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+
+ ==== To URI Domain ====
+
+ **$td** - reference to domain in URI of 'To' header
+
+ ==== To display name ====
+
+ **$tn** - reference to display name of 'To' header
+
+ ==== To tag ====
+
+ **$tt** - reference to tag parameter of 'To' header
+
+ ==== To URI ====
+
+ **$tu** - reference to URI of 'To' header
+
+
+ ==== To URI Username ====
+
+ **$tU** - reference to username in URI of 'To' header
+
+
+
+ ==== String formatted time - cached ====
+
+ **$Tf** - reference string formatted time
+
+ Note: the system time is retrieved only once for each processed SIP message. Subsequent calls of $Tf for same SIP message will return same value.
+
+ ==== String formatted time - current ====
+
+ **$TF** - reference string formatted time
+
+ Note: the system time is computed for each call of $TF. Subsequent calls of $TF for same SIP message may return different values.
+
+ ==== Unix time stamp - cached ====
+
+ **$Ts** - reference to unix time stamp
+
+ Note: the system time is retrieved only once for each processed SIP message. Subsequent calls of $Ts for same SIP message will return same value.
+
+ ==== Unix time stamp - current ====
+
+ **$TS** - reference to unix time stamp
+
+ Note: the system time is computed for each call of $TS. Subsequent calls of $TS for same SIP message may return different values.
+
+ ==== User agent header ====
+
+ **$ua** - reference to user agent header field
+
+ ==== AVPs ====
+
+ **$(avp(id)[N])** - represents the value of N-th AVP identified by 'id'.
+
+ The 'id' can be:
+
+ * "[si]:name" - name is the id of an AVP; 's' and 'i' specifies if the id is string or integer. If missing, it is considered to be string.
+ * "name" - the name is an AVP alias
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+
+ ==== Headers ====
+
+
+ **$(hdr(name)[N])** - represents the body of the N-th header identified by 'name'. If [N] is omitted then the body of the first header is printed. The first header is got when N=0, for the second N=1, a.s.o. In case of a comma-separated multi-body headers, it returns all the bodies, comma-separated. To print the last header of that type, use -1, no other negative values are supported now. No white spaces are allowed inside the specifier (before }, before or after {, [, ] symbols). When N='*', all headers of that type are printed.
+
+ The module should identify most of compact header names (the ones recognised by SIP-Router which should be all at this moment), if not, the compact form has to be specified explicitly. It is recommended to use dedicated specifiers for headers (e.g., %ua for user agent header), if they are available -- they are faster.
+
+ ==== Script variables ====
+
+ **$var(name)** - refers to variables that can be used in configuration script, having integer or string value. This kind of variables are faster the AVPs, being referenced directly to memory location. The value of script variables persists over the processing of SIP messages, being specific per each SIP-Router process.
+
+ Example of usage:
+
+ <code>
+ $var(a) = 2; -- sets the value of variable 'a' to integer '2'
+ $var(a) = "2"; -- sets the value of variable 'a' to string '2'
+ $var(a) = 3 + (7&(~2));
+ $var(a) = "sip:" + $au + "@" + $fd; -- compose a value from authentication username and From URI domain
+
+ if( [ $var(a) & 4 ] ) {
+ xlog("var a has third bit set\n");
+ }
+ </code>
+
+ Setting a variable to null is actually initializing the value to integer '0'. Script variables don't have NULL value.
+
+ **Note:** A script variable persists over the SIP-Router process in which it was initialized, so be sure of giving it a new value before reading it or you'll get the value asigned in any other previous message processed by the same SIP-Router process (pid).
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+
+ [b]pv[/b] module can be used to initialise the script variables.
+
+ ==== Shared variables ====
+
+ **$shv(name)** - it is a class of pseudo-variables stored in shared memory. The value of $shv(name) is visible across all openser processes. Each “shv” has single value and it is initialised to integer 0. You can use “shvset” parameter of **pv module** to initialize the shared variable. The module exports a set of MI functions to get/set the value of shared variables.
+
+ Example - shv(name) pseudo-variable usage:
+
+ <code>
+ ...
+ modparam("pv", "shvset", "debug=i:1")
+ ...
+ if ($shv(debug) == 1) {
+ xlog("request: $rm from $fu to $ru\n");
+ }
+ ...
+ </code>
+
+ <hi #d0d0d0>It is R/W variable (you can assign values to it directly in configuration file)</hi>
+ ==== Broken-down time ====
+
+ **$time(name)** - the PV provides access to broken-down time attributes.
+
+ The 'name' can be:
+ * sec - return seconds (int 0-59)
+ * min - return minutes (int 0-59)
+ * hour - return hours (int 0-23)
+ * mday - return the day of month (int 0-59)
+ * mon - return the month (int 1-12)
+ * year - return the year (int, e.g., 2008)
+ * wday - return the day of week (int, 1=Sunday - 7=Saturday)
+ * yday - return the day of year (int, 1-366)
+ * isdst - return daylight saving time status (int, 0 - DST off, >0 DST on)
+
+ Example - time(name) pseudo-variable usage:
+
+ <code c>
+ ...
+ if ($time(year) == 2008) {
+ xlog("request: $rm from $fu to $ru in year 2008\n");
+ }
+ ...
+ </code>
+
+ ==== Selects ====
+
+ **$sel(name)** - return the value of **select** specified by name. **select** refers a class of config variables introduced by SER 2.0, allowing to select and return parts of sip messages and not only.
+
+ List of available selects:
+ * http://sip-router.org/wiki/cookbooks/selects/devel
+
+ Example:
+
+ <code c>
+
+ if($sel(@via[1].host)=="10.10.10.10")
+ {
+ ...
+ }
+ </code>
+
+ ==== Send Addr Attributes ====
+
+ **$snd(name)** - return attributes of the address where the request is going to be sent. They are available in **onsend_route**. The name can be:
+
+ * ip - IP address of destination
+ * af - address family to be used to send
+ * port - port of destination address
+ * proto - transport protocol to be used to send
+
+ Example:
+
+ <code c>
+
+ onsend_route {
+ if($snd(ip)=="10.10.10.10")
+ {
+ ...
+ }
+ }
+ </code>
+
+ ===== Dialog module Pseudo-Variables =====
+
+ ==== $dlg(attr) ====
+
+ Return the attribute of the current processed dialog.
+
+ <hi #d0d0d0>It is R/O variable.</hi>
+
+ The 'attr' can be:
+ * h_id - hash id
+ * h_entry - hash entry
+ * ref - reference count
+ * state - state of dialog
+ * to_rs - To route set
+ * from_rs - From route set
+ * dflags - dialog internal flags
+ * sflags - dialog script flags
+ * callid - sip call id
+ * to_uri - To uri
+ * to_tag - To tag
+ * from_uri - From uri
+ * from_tag - From tag
+ * toroute - timeout route
+ * lifetime - timeout inteval
+ * start_ts - start timestamp
+ * to_cseq - To CSeq
+ * from_cseq - From CSeq
+ * to_contact - To contact address
+ * from_contact - From contact address
+ * to_bindaddr - To bind address
+ * from_bindaddr - From bind address
+
+ ==== $dlg_ctx(attr) ====
+
+ Return the attribute of the context for current processed dialog.
+
+ <hi #d0d0d0>It is R/W variable.</hi>
+
+ The 'attr' can be:
+ * set
+ * flags
+ * timeout_route
+ * timeout_bye
+
+
+ ===== HTable module Pseudo-Variables =====
+
+ ==== $sht(htable=>key) ====
+
+ Access hash table entries.
+
+ <hi #d0d0d0>It is R/W variable, you can assign values to it directly in configuration file.</hi>
+
+ The “htname” must be a hash table name defined via “htable” parameter.
+
+ The “key” can be:
+
+ * static string - set of characters without pseudo-variables
+ * dynamic string - set of characters that include pseudo-variables. The pseudo-variables will be evaluated at runtime.
+
+ <code>
+ ...
+ modparam("htable", "htable", "a=>size=4;")
+ ...
+ $sht(a=>$au) = 1;
+ $sht(a=>$ru) = $fu;
+ ...
+ </code>
+
+ ==== $shtex(htable=>key) ====
+
+ Access hash table entry expire value. Value represents the seconds until the htable entry will expire and be deleted from htable.
+
+ <hi #d0d0d0>It is R/W variable, you can assign values to it directly in configuration file.</hi>
+
+ The “htname” must be a hash table name defined via “htable” parameter and have auto-expire greater than 0.
+
+ The “key” can be:
+
+ * static string - set of characters without pseudo-variables
+ * dynamic string - set of characters that include pseudo-variables. The pseudo-variables will be evaluated at runtime.
+
+ <code>
+ ...
+ modparam("htable", "htable", "a=>size=4;autoexpire=120;")
+ ...
+ $sht(a=>$au) = 1;
+ $shtex(a=>$au) = 10;
+ ...
+ </code>
+
+
+ ==== $shtcn(htable=>regexp) ====
+
+ Count items matching the name by regexp.
+
+ The “htname” must be a hash table name defined via “htable” parameter.
+
+ The “regexp” must be a regular expression.
+
+ <code>
+ ...
+ modparam("htable", "htable", "a=>size=4;")
+ ...
+ $sht(a=>abc) = 1;
+ $shtex(a=>ade) = 10;
+ xlog("$shtcn(a=>a.*)");
+ ...
+ </code>
+
+ ==== $shtcv(htable=>regexp) ====
+
+ Count items matching the value by regexp.
+
+ The “htname” must be a hash table name defined via “htable” parameter.
+
+ The “regexp” must be a regular expression.
+
+ <code>
+ ...
+ modparam("htable", "htable", "a=>size=4;")
+ ...
+ $sht(a=>abc) = "xyz";
+ $shtex(a=>ade) = "xwt";
+ xlog("$shtcv(a=>x.*)");
+ ...
+ </code>
+
+ ===== Memcached module Pseudo-Variables =====
+
+ ==== $mct(key) ====
+
+ Access hash table entries stored in the memcached server.
+
+ <hi #d0d0d0>It is R/W variable, you can assign values to it directly in configuration file.</hi>
+
+ The “key” can be:
+
+ * static string - set of characters without pseudo-variables
+ * dynamic string - set of characters that include pseudo-variables. The pseudo-variables will be evaluated at runtime.
+
+ <code>
+ ...
+ $mct($au) = 1;
+ $mct($ru) = $fu;
+ $mct(test) = 1;
+ xlog("stored value is $mct(test)");
+ $mct(test) = null; # delete it
+ xlog("stored value is $mct(test)"); # will return <null>
+ ...
+ </code>
+
+ ==== $mcinc(key) ====
+
+ Do a atomic increment operation on the value stored in memcached. You need to add a value previously.
+
+ <hi #d0d0d0>It is R/W variable, you can assign values to it directly in configuration file.</hi>
+
+ The “key” can be:
+
+ * static string - set of characters without pseudo-variables
+ * dynamic string - set of characters that include pseudo-variables. The pseudo-variables will be evaluated at runtime.
+
+ <code>
+ ...
+ $mct(cnt) = 1;
+ $mcinc(cnt) = 2; # increment by 2
+ xlog("counter is now $mct(cnt)");
+ ...
+ </code>
+
+ ==== $mcdec(key) ====
+
+ Do a atomic decrement operation on the value stored in memcached. You need to add a value previously.
+
+ <hi #d0d0d0>It is R/W variable, you can assign values to it directly in configuration file.</hi>
+
+ The “key” can be:
+
+ * static string - set of characters without pseudo-variables
+ * dynamic string - set of characters that include pseudo-variables. The pseudo-variables will be evaluated at runtime.
+
+ <code>
+ ...
+ $mct(cnt) = 10;
+ $mcdec(cnt) = 2; # decrement by 2
+ xlog("counter is now $mct(cnt)");
+ ...
+ </code>
+
+ ===== Presence_xml Pseudo-Variables =====
+
+ ==== $xml(name=>spec) ====
+
+ * name - id to refer the documet
+ * spec - specifier:
+ * doc - set/get the document as text
+ * xpath:xpath-expression - evaluate xpath expression
+
+ Example:
+
+ <code>
+ $xml(x=>doc) = '<?xml version="1.0" encoding="UTF-8"?><a><b>test</b></a>';
+ xlog("content of node b: $xml(x=>xpath:/a/b/text())\n");
+ $xml(x=>xpath:/a/b) = "1234";
+ </code>
+
+ ===== TMX module Pseudo-Variables =====
+
+ ==== $T_branch_idx ====
+
+ * the index (starting with 1 for the first branch) of the branch for which is executed the branch_route[]. If used outside of branch_route[] block, the value is '0'.
+
+ ==== $T_reply_code ====
+
+ * the code of the reply, as follows: in request_route will be the last stateful sent reply; in reply_route will be the current processed reply; in failure_route will be the negative winning reply. In case of no-reply or error, '0' value is returned
+
+ ==== $T_req(pv) ====
+
+ * can be used in reply routes or inside the modules to get access to attributes of the request belonging to same transaction as the reply
+
+ <code>
+ route {
+ t_on_reply("1");
+ t_relay();
+ }
+
+ onreply_route[1] {
+ xlog("Request SRCIP:PORT = $T_req($si):$T_req($sp)\n");
+ }
+ </code>
+
+ ==== $T_rpl(pv) ====
+
+ * can be used in failure routes or inside the modules to get access to attributes of the winning reply belonging to same transaction as the request
+ <code>
+ route {
+ t_on_failure("1");
+ t_relay();
+ }
+
+ failure_route[1] {
+ xlog("Reply SRCIP:PORT = $T_rpl($si):$T_rpl($sp)\n");
+ }
+ </code>
+
+ ==== $T_inv(pv) ====
+
+ * can be used in request routes or inside the modules to get access to attributes of the INVITE request while processing a CANCEL.
+
+ <code>
+ route {
+ if(is_method("CANCEL"))
+ {
+ if($T_inv($mf) & 1 )
+ {
+ # first flag is set in the INVITE transaction
+ }
+ }
+ }
+ </code>
+
+
+ ===== UAC module Pseudo-Variables =====
+
+ ==== $uac_req(key) ====
+
+ * used to build the input for uac_send_req() function of UAC module
+
+ key can be:
+ * method - SIP method
+ * ruri - request URI
+ * furi - From URI
+ * turi - To URI
+ * ouri - Outbound proxy URI
+ * hdrs - SIP Headers
+ * body - Body
+ * all - alias useful to rest all fields - $uac_req(all) = null;
+
+ <code>
+ $uac_req(method)="OPTIONS";
+ $uac_req(ruri)="sip:kamailio.org";
+ $uac_req(furi)="sip:kamailio.org";
+ $uac_req(turi)="sip:kamailio.org";
+ uac_send_req();
+ </code>
+
+ ===== Special pseudo-variables - Escape Sequences =====
+
+
+ These pseudo variables are exported, and mainly used, by xlog module to print messages in many colors (foreground and background) using escape sequences.
+
+
+ ==== Foreground and background colors ====
+
+
+
+ $C(xy) - reference to an escape sequence. “x” represents the foreground color and “y” represents the background color.
+
+ Colors could be:
+
+ * x : default color of the terminal
+ * s : Black
+ * r : Red
+ * g : Green
+ * y : Yellow
+ * b : Blue
+ * p : Purple
+ * c : Cyan
+ * w : White
+
+
+
+
+ ===== Examples =====
+
+
+ A few examples of usage.
+
+ Example 1. Pseudo-variables usage
+ <code c>
+ ...
+ avp_aliases="uuid=I:50"
+ ...
+ route {
+ ...
+ $avp(uuid)="caller_id";
+ $avp(i:20)= $avp(uuid) + ": " + $fu;
+ xdbg("$(C(bg))avp(i:20)$(C(xx)) [$avp(i:20)] $(C(br))cseq$(C(xx))=[$hdr(cseq)]\n");
+ ...
+ }
+ ...
+ </code>
</pre>text/html2011-12-09T23:26:12+01:00admin_guide:management - old revision restored
http://sip-router.org/wiki/admin_guide/management?rev=1323469572&do=diff
<pre>
@@ -1 +1,34 @@
- Shoot, who would have tuoghht that it was that easy?
+ ====== Managing SER Server ======
+ <note important>
+ This guide is work in progress. The guide was originally conceived as the
+ administrator's guide for SER 2.0 and it is currently being transformed
+ into the Administrator's Guide for the SIP Router.
+ </note>
+
+ ===== sercmd =====
+
+ See [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=utils/sercmd/README|sip-router/utils/sercmd/README]] for sercmd help,
+ [[http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=utils/sercmd/EXAMPLES|sip-router/utils/sercmd/EXAMPLES]] for more sercmd examples and
+ [[http://sip-router.org/docbook/sip-router/branch/master/modules_s/ctl/ctl.html|sip-router/modules_s/ctl]]
+ for the ctl module help.
+
+ ===== ser_ctl =====
+ ===== User Management =====
+ * //adding/deleting/modifying users//
+
+ ===== URI Management =====
+ * //assigning/removing SIP URIs to/from users//
+
+ ===== Virtual Domains =====
+ * //creating virtual domains//
+ * //domain settings//
+
+ ===== Configuration Attributes =====
+
+
+
+
+
+
+
+
</pre>text/html2011-12-09T23:25:53+01:00meetings:berlin-2010-minutes - old revision restored
http://sip-router.org/wiki/meetings/berlin-2010-minutes?rev=1323469553&do=diff
<pre>
@@ -1 +1,115 @@
- What I find so interesting is you could never find this anywrhee else.
+ ====== Developers' Meeting, Berlin 2010 ======
+
+ FhG FOKUS Berlin
+ June 8, 2010
+
+ This is the summary of **SIP Express Router (SER) and Kamailio developers meeting**, held on the 8th of June 8, 2010, at FhG FOKUS in Berlin.
+
+ Number of participants: 16
+
+ ===== Main Topics =====
+
+ - SIP SIMPLE Presence
+ - New in development version
+ - Management of next major release - 3.1.0
+ - Review of evolution so far and future development
+ ==== SIP SIMPLE presence ====
+
+ * Inaki Baz Castillo
+ * update about IETF specs, pretty much pessimism regarding scalability and interoperability as well as future development of the current specs
+ * so far they look good only for services inside same provider
+ * OMA and RCS bring new specs on top of IETF, but mostly focused on IMS area
+ * summary of other presence and im systems: msn and xmpp
+ * a potential new presence specification from scratch trying to learn from the best of what is out there.
+ * Daniel-Constantin Mierla
+ * update about embedded XCAP server committed in GIT repository
+ * transport layer works for http/1.0
+ * the http/2.0 chunked needs some coding in the core
+ * not yet full implementation of XCAP requirements
+
+
+ ==== New in development ====
+
+ About the things planned to be finished before 3.1.0 and updates from related projects.
+ * other new features are already completed - not the subject of this discussion, see them at:
+ * http://sip-router.org/wiki/features/new-in-devel
+
+
+ * Andrei Pelinescu-Onciul
+ * update about asynchronous TLS
+ * code in a special branch, to be merge to master after some extra testing
+ * it reuses TCP async options, thus avoiding potential conflicts
+ * reason support for local CANCELs and E2E CANCELs (received CANCELs)
+ * pretty much done
+ * not merged yet because no documentation was written
+ * raw UDP socket support
+ * dedicated branch for now, targeting to boost UDP communication performances by avoiding some kernel limitations
+ * usage is configurable by script
+ * in the future can be reused for icmp support
+ * Marius volunteered for testing and reporting as the time allows.
+ * allow expressions in function parameters
+ * allowing expressions in function parameters for functions that have no fixups or use the pre-defined fixups
+ * part of NG module interface
+ * yet to be decided if to be pushed in 3.1 or the other next release (3.2)
+ * Henning Westerholt
+ * some new modules might be pushed in public repository before 3.1
+ * Timo Reimann
+ * work on dialog module to be split in enhancements to current architecture for 3.1
+ * major re-factoring as discussed on mailing lists for 3.2
+ * Daniel-Constantin Mierla
+ * finish work started for modules
+ * dispatcher - load balancing
+ * weight based distribution donw, next is call load distribution
+ * debugger - interactive config file debugging
+ * more user friendly output
+ * xhttp - embedded HTTP server
+ * http/1.0 done
+ * support for handling received chuncked body as in http/2.0
+ * xcap_server - embedded XCAP server
+ * works now with xhttp and sip transport layers
+ * next work is to complete XCAP specs, making K/S full featured embedded SIMPLE presence server - no external components to be needed anymore
+ * app_lua
+ * review of dynamic PV usage potential issues
+ * export more internal api to lua
+ * Dragos Vingarzan
+ * openimscore module should work out of the box with sip router core
+ * Bogdan Pintea
+ * updates about binrpc and patches to sercmd
+ * Marius Zbihlei
+ * Integration of kamctl/sercmd - work so far, futures steps
+ * CFG framework integration in upcoming Kamailio 3.1.
+ * Status of a unified statistics framework between K and S
+ * Stefan Sayer
+ * status of GSoC2010 project for SEMS and Kamailio Presence Server
+ * SEMS 1.2.x is out - SIP signaling b2bua and media server
+
+ ==== Next release ====
+
+
+ * the set of new features is very impressive
+ * http://sip-router.org/wiki/features/new-in-devel
+ * some modules need to be merged to ease further integration
+ * top list: sl, auth, rr
+ * next release to have a single stable branch
+ * freezing probably mid of July or a bit later to allow fair completion of started work
+ * target date for release
+ * September, probably to second part of it
+ * more precise date to be set at freezing time
+ * discussion whether to make it a LTS release
+ * the usual official support cycle is 1.5 - 2 years anyhow
+
+ ==== Review of evolution so far and the future development ====
+
+ * integration process
+ * successfully completed for 3.0.0 - apart of seas which has now needed patches
+ * next is merging more modules that provide same functionality, main focus on non-db modules
+ * feedback for 3.0
+ * very good
+ * the new features are very attractive
+ * very solid version, reported issues haven't exceeded a normal major release case
+ * work effort for 3.0 and new features already done for 3.1 => the project offers a strong and reliable development team
+ * first half of 2010 had good coverage of the project to various events
+ * project devel resources are pretty much centralized under sip-router.org domain
+ * there is always space for better docs, plans to improve them to be summarized separately
+ * some ideas about what 3.2 should get flowed around, besides new dialog and presence server work
+ * participation to other events is already booked for second part of the year
</pre>text/html2011-12-09T23:25:08+01:00tutorials:makefile-system - old revision restored
http://sip-router.org/wiki/tutorials/makefile-system?rev=1323469508&do=diff
<pre>
@@ -1 +1,135 @@
- Well done article that. I'll make sure to use it wseily.
+ ====== SIP Router Makefile System ======
+
+ ===== Generate Main Binary =====
+
+ <code>
+ make
+ </code>
+
+ ===== Compile Everything =====
+
+ <code>
+ make all
+ </code>
+
+ ===== Install Everything =====
+
+ <code>
+ make install
+ </code>
+
+ ===== Clean Source Tree =====
+
+ * clean object files
+
+ <code>
+ make clean
+ </code>
+
+ * clean all generated files
+
+ <code>
+ make proper
+ </code>
+
+ ===== Generate Modules =====
+
+ <code>
+ make modules
+ make modules_k
+ make modules_s
+ </code>
+
+ ===== Generate Config for Makefile =====
+
+ <code>
+ make cfg
+ </code>
+
+ * add extra defines in makefile config
+
+ <code>
+ make EXTRA_DEFS="-DSTATISTICS" cfg
+ </code>
+
+ * cfg for Makefile is config.mak
+ * you can edit it and tune as you wish before compilation
+
+ ===== Enable Module =====
+
+ If the module is not compiled by default:
+
+ * edit **modules.lst**
+ * remove the name of the module from **exclude_modules** variable
+
+ or type: <code>make modules-cfg include_modules=<name_of_the_module></code> .
+
+ The same can be accomplished with <code>make cfg include_modules=<name_of_the_module> </code>
+ , but this will remake the whole config.
+
+ ===== Combined Parameters =====
+
+ Various parameters can be given to make command, an example:
+
+ <code c>
+ make prefix=/opt/sip-router \
+ SCTP=1 \
+ CC_EXTRA_OPTS=-I/usr/gnu/include \
+ group_include="standard postgres presence" \
+ include_modules="snmpstats perl tls" \
+ all
+
+ </code>
+
+
+ or you can save them in the config (they will be used by future make invocations) by givin the same parameters to make cfg:
+ <code c>
+ make cfg prefix=/opt/sip-router \
+ SCTP=1 \
+ CC_EXTRA_OPTS=-I/usr/gnu/include \
+ group_include="standard postgres presence" \
+ include_modules="snmpstats perl tls"
+ </code>
+
+ ===== Generate README For Modules =====
+
+ * all READMEs for modules located in directory **modules**
+ <code>
+ make modules-readme
+ </code>
+ * all READMEs for modules located in directory **modules_k**
+ <code>
+ make modules_k-readme
+ </code>
+ * all READMEs for modules located in directory **modules_s**
+ <code>
+ make modules_s-readme
+ </code>
+ * README for one module. Example for **modules_k/dispatcher**:
+ <code>
+ make modules-readme modules=modules_k/dispatcher
+ </code>
+
+ or
+
+ <code>
+ make -C modules_k/dispatcher/doc readme
+ </code>
+
+ ===== Generate Different Formats For Modules Documentation =====
+
+ Available formats:
+ * txt - text plain
+ * xhtml - single xhtml file
+ * html - html files (chunks) split by sections
+ * pdf - PDF file
+
+ Command to generate a specific format for a module:
+ <code>
+ make modules-doc doc_format=format modules=path/to/module
+ </code>
+
+ Example: generate single xhtml file for **auth** module:
+ <code>
+ make modules-doc doc_format=xhtml modules=modules_k/auth
+ </code>
</pre>