As you probably have noticed the git repository for sip-router is now
online.
It was started from ser core and tm.
git urls:
git://git.sip-router.org/sip-router
(read only)
http://git.sip-router.org/sip-router
(read only, slower, git://... recomended)
ssh://git.sip-router.org/sip-router
(read write but account on git.sip-router.org needed)
Web interface: http://git.sip-router.org/cgi-bin/gitweb.cgi
Branches acl: the repository is setup so that you can write/commit
only to the following branches:
<your_username>/.*
tmp/.*
master
We'll add access to more branches as needed (I've added this rules to
avoid creating lots of "root" branches by mistake, e.g. git pull
from a local branch without a refspec).
Please create the commit messages following the git convention
(start with one short line, preferably less then 50 chars summarizing
the changes, then one empty line and then a more detailed description).
See:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#creating-g…http://www.tpope.net/node/106
Quick git introduction:
# clone the repo into the sip-router directory
git clone git://git.sip-router.org/sip-router
cd sip-router
git branch -a # show all branches
# create a local branch based on origin/andrei/mod_f_params
git checkout --track -b my_branch origin/andrei/mod_f_params
git log # see commit log
git log --pretty=oneline # only the first line from each commit
vim Makefile.defs
git add Makefile.defs
git commit # or git commmit -a to skip the add step and commit all
# changed files
# push changes back (note you need ssh access for this)
# note: the next command will fail, unless your username is andrei :-)
# publish changes on the local "my_branc" to the remote
# andrei/mod_f_params
git push origin my_branch:andrei/mod_f_params
# or push them into the master branch if you are sure about them
git push origin my_branch:master
For more info about git try:
http://git.or.cz/gitwiki/GitDocumentation
and if you want to know how it works:
http://eagain.net/articles/git-for-computer-scientists/
(highly recommended)
CVS access:
CVS_SERVER="git cvsserver" cvs \
-d :ext:andrei@git.sip-router.org/sip-router co master
(instead of master you can use any other branch name that doesn't
include a '/')
The initial checkout takes a while, but after that cvs update seems fast
enough.
SVN access: unfortunately we do not have it. It looks like the
git svnserver is in the project stage (there is some python code but not
runnable yet). There is a way around it, but it would be quite complex
to setup: a git to svn gateway and then svn to git imports.
Other repositories on git.sip-router.org:
ser - entire ser updated from cvs
ser_core - only ser_core, automatically updated from cvs, read-only
test - test repository, contains an early sip-router version, it has the
same access rules as sip-router (if you have something you want
to test, please use it rather then trying directly on
sip-router).
Special thanks go to Jan, who not only did setup git.sip-router.org
(including automatic cvs sync for some of the repos), but he's also
hosting it on one of his private machines.
Andrei
[crossposting since this is of general interest]
On Nov 12, 2008 at 00:30, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
> Hi Miklos!
>
> This sounds great. Can you make a sample function which uses the new
> feature?
We are thinking of doing a dns_prefetch module using this.
The sip-router.cfg will look like:
route{
...
dns_prefetch("uri", ROUTE_DNS_OK);
# end of script
}
route[ROUTE_DNS_OK]{
if (dns_error){
...
}
# continue normal processing
# the uri was resolved and is in the dns cache
...
t_relay()
...
}
However don't expect something quickly as everybody is quite busy and we
would still need to write a dns resolver process pool (time consuming).
Note that this is not the "final" async. solution since it's not
transparent for the script writer (scripts would have to be written in a
special way), works only with tm and it's also a little inefficient for
dns usage.
In the long term we will have completely transparent async. support for dns
and maybe db lookups (though it's controversial if we really need it for
normal db lookups). This will take much longer and will require among
other things reviewing all the global variable use (most of the global
variables will either need to be registered or allocated in some known
special place).
If Miklos doesn't beat me to it, I'll probably start working on it only
after the core merging is complete.
>
> Can this also be used for DNS lookups and TCP/TLS connection setup?
Yes for DNS (see above) and in general for any route-level async processing
involving tm (e.g. lookup some part of the message in a slow DB and
execute automatically another route when the DB responds).
It cannot be used for TCP/TLS, but it's not needed anyway. In ser TCP
connection setup and TCP send is already asynchronous, at least if
you have tcp_buf_write=yes in ser.cfg (I agree it's not a very well
chosen name :-)). TLS does not support it yet, so if you use TLS
you should not set this option (that's why it's not yet the default).
TLS support for it requires non-trivial changes in the tcp core and it
will probably come after the merge (it's started already but far from
finished).
(BTW: most of the core new options documentation in ser can be found
in NEWS)
Andrei
>
> Further, also for Kamailio cooperation better documentation would be
> needed. Thus, instead of writing long CVS commit messages I think it
> would be better to write the text into the module documentation, and
> then copy/paste it into the CVS commit.
>
> regards
> Klaus
>
> Miklos Tirpak wrote:
> > tirpi 2008/11/10 13:47:03 CET
> >
> > SER CVS Repository
> >
> > Modified files:
> > modules/tm t_cancel.c t_fwd.c t_reply.c t_reply.h
> > tm.c tm_load.c tm_load.h
> > Added files:
> > modules/tm t_suspend.c t_suspend.h
> > Log:
> > t_suspend() and t_continue() functions are introduced.
> >
> > These fuctions can be used by other modules to implement
> > asynchronous actions: t_suspend() saves the transaction, returns its
> > identifiers, and t_continue() continues the SIP request processing.
> > (The transaction processing does not continue from the same point
> > in the script, a separate route block defined by the parameter of
> > t_continue() is executed instead. The reply lock is held during the
> > route block execution.) FR timer is ticking while the
> > transaction is suspended, and the transaction's failure route is
> > executed if t_continue() is not called in time.
> >
> > Missing: msg lumps are saved by t_suspend() and are not updated by
> > the subsequent t_relay(). This means that the modifications made
> > between them are lost.
> >
> > Revision Changes Path
> > 1.32 +7 -2 sip_router/modules/tm/t_cancel.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_cance…
> > 1.107 +8 -2 sip_router/modules/tm/t_fwd.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_fwd.c…
> > 1.162 +4 -4 sip_router/modules/tm/t_reply.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_reply…
> > 1.31 +7 -1 sip_router/modules/tm/t_reply.h
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_reply…
> > 1.1 +154 -0 sip_router/modules/tm/t_suspend.c (new)
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_suspe…
> > 1.1 +42 -0 sip_router/modules/tm/t_suspend.h (new)
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_suspe…
> > 1.177 +3 -1 sip_router/modules/tm/tm.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm.c.di…
> > 1.31 +11 -1 sip_router/modules/tm/tm_load.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm_load…
> > 1.31 +4 -1 sip_router/modules/tm/tm_load.h
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm_load…
> > _______________________________________________
> > Serdev mailing list
> > Serdev(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serdev
>
> _______________________________________________
> Serdev mailing list
> Serdev(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
Hello,
there are couple of modules that change the R-URI and automatically call
append_branch() if the execution takes place in failure_route, other
modules don't.
Perhaps we should get to a coherent behavior, if not for existing code,
then for the future. Probably the most flexible, better in my opinion,
is to let script writer to call append_branch() in config -- once done,
it is no way now to revert. A new branch should be automatically done
only if it is a specific operation, e.g., location lookup with more than
one record.
What do you think?
Cheers,
Daniel
PS. this blending of the ser-kamailio sources gives me ideas to do some
cleanup as I review the code ... especially after midnight ...
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello,
There seem to be many places where static buffers are used for building
strings. It is clear they are used just for usage inside some functions,
with no need to keep the value for usage somewhere else.
Would defining a global static buffer to be used for such cases make
sense? The access to the pointer and size can be given via functions.
There could be couple of such buffers to be used in the cases one
function need concurrent access to more than one ... opinions? It will
reduce memory space reserved and used...
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
It's highly recommended to use git versions >= 1.5.6 (e.g. 1.5.6.1,
1.6.0.4 a.s.o) if you use/do git merge.
Older versions do not support the merge.log options or git merge --log
and _will_ not generate merge summaries in the merge commit messages
(which are very nice to have).
If you have an older version and you don't want to upgrade try setting
merge.summary (git config merge.summary true).
Andrei