Hello,
Here is a brief git crash course for those who are used to CVS or SVN. The
purpose of this crash course is to get you started, it describes basic
operations that you will need to do simple changes in the sip-router git
repository. You can find links to more documentation at the end.
First of all, you'll need to install git. The name of the corresponding Debian
package is git-core. Debian Lenny contains version 1.5.6.5 which is
sufficient. Newer git versions or packages for other distributions or
architectures can be obtained from http://git-scm.com/.
As the second step you need to configure the git client. I have attached
configuration files to this email for your convenience, save files .gitconfig
and .gitignore in your home directory. File sip-router.org_CA.pem is optional,
you will only need the file if you plan on accessing the repository over https
(that's not the case for developers with write access).
Edit file ~/.gitconfig and configure your name and email address there. This
is the name and email address that will be visible in git commits. Unlike CVS
or SVN commits, git commits contain full name and email address of the
commiter, this is the name and email that will be visible in git history. Note
that the email address to be used in From header of commit logs sent to the
development mailing list is configured separately on the server (there are
technical reasons for this). Here is how I configured my name in email address
in ~/.gitconfig:
[user]
name = Jan Janak
email = jan(a)iptel.org
The git configuration file in your home directory sets up a bunch of short
aliases for most common git commands, so you do not have to type
$ git checkout
every time you are checking out a branch, you can just type 'git co' instead,
and if you alias git to 'g' in your ~/.bashrc then it becomes just 'g co'
which is much more convenient.
Another setting that is particular to our repository is the number of
characters used for tabs in the git pager. Git uses less as the default pager
and less is configured to use 8 spaces for tabs by default. We use 4 spaces in
our sources and thus you might want to re-configure the git pager in your
~/.bashrc. The following setting makes the output of 'git diff' and friends
look prettier:
export GIT_PAGER="less --tabs=4"
Now you can start working with git. The first command that you need to run is
'git clone', this is the command that is used to retrieve the sip-router
repository from the server:
$ git clone ssh://<username>@git.sip-router.org/sip-router
Replace <username> with your real username. The contents of the repository
will be stored in 'sip-router' subdirectory of your current working directory.
This command is the git equivalent of cvs/svn checkout. Like cvs/svn it will
make the most recent version of the sources available in the
subdirectory.
UNLIKE cvs/svn, this command does not retrieve just the latest version of the
sources, it copies the whole history of the project to your local hard drive,
not just the latest revision, but all revisions that are stored in the
repository, since tday 1. You do not have to be worried about the size of
the repository, the full history of SER takes about 40MB only.
Also, you will need to run the command only once (or occassionally if you wipe
your local copy out entirely). There are other git commands (covered later)
that can be used to keep your local copy up-to-date. Those commands can figure
out the difference between your local version of the repository and the
version on the server and they will transfer only the data that has
changed. In other words, 'git clone' is similar to the scp command, it creates
a local identical copy of the remote repository by copying the whole remote
repository to the local machine.
Once you have a local copy of the sip-router repository, you can try to see
what is in there:
$ cd sip-router
$ git branch
The command above shows a list of branches that are present in your local copy
of the repository. Most likely you will see just one branch called 'master'
marked with an asterisk. This means that your local repository contains only
one branch called 'master' and the asterisk tells you that this is the branch
that is currently checked out. So the sources that you see in that directory
come from the master branch. The local master branch is an exact copy of the
'master' branch from the remote repository at git.sip-router.org and it
contains latest sip-router sources.
Typically, the branch with the most up-to-date code is called 'master' in
git. It is the git equivalent of CVS HEAD branch and SVN trunk branch.
NOTE: Branches are sometimes called 'heads' in git documentation, but you can
just remember that 'branch' and 'head' refers to the same thing.
If you look at the remote version of the repository with gitweb at
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=heads you will
notice that there are more branches than the 'master' branch which was created
by 'git clone' in the local copy of the repository. The command 'git clone'
only makes the master branch directly available in the local copy of the
repository. For other branches it merely records the fact that the branches
exist in the remote repository. To display branches from both the local and
the remote repository you can run:
$ git branch -a
The output should look roughly like this:
* master
origin/HEAD
origin/MAIN
origin/Maintainer
origin/andrei/cvshead
origin/andrei/sctp
origin/andrei/sctp_fixes
origin/andrei/sctp_one_to_one
origin/andrei_sctp
origin/cancel_fix
origin/cvs-head
origin/janakj/cvshead
origin/janakj/doxygen
origin/master
Branches that start with "origin/" are branches that exist in the remote
repository. The string origin is just a short alias for the full URI of the
remote repository, such as ssh://git.sip-router.org/sip-router. It is a
convention that the repository you cloned from initially is called the origin.
Once you have the local repository, you can start making changes in it.
Modifying the code on the master branch directly is really easy, because git
clone already created the master branch for you in local repository and it
checked out the master branch by default. Here is how can you make a simple
change in one file and commit the result:
$ edit main.c
$ git add main.c
$ git commit
As you can see above you need to call 'git add' before you call 'git
commit'. 'git add' marks your changes to be commited during the next commit,
this is useful, for example, if you want to leave some local changes
uncommited while you make the commit. Unlike CVS or SVN, git does not assume
that all local changes should be commited during the next commit. It lets you
explicitly select a set of changes to be commited. You can avoid the need to
call two commands with 'git commit -a', see the git documentation for more
details.
When you are done with the commit, you can display the list of changes in the
repository with 'git log'. The command displays the history of changes in the
whole repository, if you want to limit the list to main.c only then you can
run 'git log main.c'.
If you look closely at the output of 'git log' then you will notice strange
lines starting with "commit" followed by a long string of characters:
commit 0253726f99ac151f748712a5d39d71f42d9defc6
The long string is how commits in git are represented. This string is a SHA1
checksum of the commit and it is the git equivalent SVN revision numbers. Like
SVN revision numbers and UNLIKE CVS versions, this identifier represents the
state of the whole repository, not just individual files. Because such long
identifier are tedious to type, git supports abbreviated format, you can type
just the beginning of the string as long as the beginning of the string is
unique. In other words, there must be at most one commit in the database of all
commits with this prefix. For example the following two commands refer to the
same commit:
$ git diff b0f6ec8784712e4c1436fc9a4a3b54296e94ba5c
$ git diff b0f6e
If somebody creates another commit with an SHA1 id starting with b0f6e later
then 'git diff b0f6e' would not longer work and git would complain that the
prefix is ambiguous.
All changes, such as the commit above, that you do affect the local repository
only. There is absolutely no communication with the the remote repository in
any of the commands above (git add, git commit, git log). This is possible
because we created a full copy of the remote repository with 'git clone'. This
is also the reason why all the commands are so fast, unlike their equivalents
in CVS or SVN.
The fact that you perform all actions/modifications on the local repository
only and then you instruct git to do its black magic and synchronize your
local changes with the remote repository is probably the biggest difference
from CVS/SVN and one of the things that is hard to understand for people who
are used to CVS/SVN. This is also why git falls into the category of
distributed revision control systems.
When you are satisfied with your local changes/commits, you can decide to make
them available to others. This can be done by uploading your local changes to
the remote repository (the one you initially cloned from). In git terminology
this operation is called 'push', so you can push your local changes to the
remote repository with 'git push':
$ git push origin master:master
The first parameter is the name of the remote repository, the second parameter
is the name of the local branch and the name of the remote branch, delimited
by ':'. You can omit the 2nd parameter:
$ git push origin
and then 'git push' will upload all local branches to the remote
repository. You can also omit the first parameter:
$ git push
and in that case repository 'origin' is used.
The opposite of 'git push' is 'git pull'. This is the operation that you can
use to synchronize your local repository with the remote repository. 'git
pull' downloads all changes (made by others) from the remote repository that
are not yet in your local repository and integrates them into your local
repository. You can run 'git pull' whenever you are online to fetch latest
changes and keep your local copy of the repository up-to-date.
'git push' and 'git pull' are similar to rsync, they update either the local
or the remote copy of the repository by tranferring only what is missing. 'git
push' is the git equivalent of 'cvs ci' and 'svn ci'. 'git pull' is the git
equivalent of 'cvs update' or 'svn update'.
If you make only small changes to the repository then you can modify the
master branch directly, as described above. This approach is suitable only for
small, trivial changes. If are working on a change which takes longer to
implement, consists of many commits, then it is better to create a separate
branch and do the development on a separate branch. Branches in git are cheap,
remember that all operations, including branch creation, are local
operations. You do not even have to push your local branches into the remote
repository, you can just keep them in the local copy for your own
purposes. You can create a new branch in your local repository with 'git checkout':
$ git checkout --track -b mybranch master
This command creates a new branch called 'mybranch', configures the branch to
track the master branch and checks the new branch out. The word 'track' in
this context means that the newly created branch will receive all updates from
the master branch whenever you run 'git pull' with this branch checked out. In
other words, the branch tracks another branch (master in this case) by merging
all changes from the original branch. Command line option -b instructs git to
to create a new branch. If this option was omitted then git would assume that
'mybranch' is an existing branch and it would try to check the branch out.
The newly created branch exists in the local repository only. If you want to
push the branch to the remote repository then you can use 'git push' again:
$ git push origin mybranch:janakj/mybranch
Because mybranch is a private topic branch of mine, I am pushing it as
janakj/mybranch to the remote repository at git.sip-router.org. The remote
repository only permits new "username" branches. In other words their name
must start with your username. If you try:
$ git push origin mybranch:mybranch
then git will report an error. The main reason why we have this restriction in
place is because we wanted to make sure that people do not push all local
branches to the remote repository by accident. This can easily happen if you
run 'git push' without any parameters.
You can also delete a local branch that is no longer needed by running
$ git branch -D mybranch
This will delete the local branch only. If you pushed the branch to the remote
repository then you might also want to delete the branch in the remote
repository with 'git push':
$ git push :janakj/mybranch
This is a special syntax of 'git push', if you omit the name of the local
branch then 'git push' deletes the remote branch whose name follows ':'.
Test Repository
===============
We have a test repository at git.sip-router.org which you can use to test
various git operations. Clone the repository with:
$ git clone ssh://username@git.sip-router.org/test
and there you can test whatever you want. The repository can also be browsed
with gitweb at
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=test;a=summary
Further Reading
===============
[1] Git related pages in the wiki: http://sip-router.org/wiki/git
[2] http://eagain.net/articles/git-for-computer-scientists/
[3] Git SVN Crashcourse: http://git.or.cz/course/svn.html
[4] http://git-scm.com/documentation
Hi,
during a review i noticed that it seems that all the functionality in the
modules_s/dbg module is also provided from the modules_k/cfgutils module.
function mapping:
- dbg_msleep(n) -> usleep(n*1000)
- dbg_abort() -> abort()
- dbg_pkg_status() -> pkg_status()
- dbg_shm_status() -> shm_status()
It is ok when i remove this module? If this one additional multiplication is
not ok, i can of course also add a 'm_sleep' function to the cfgutils module
as well.
Regards,
Henning
Please don't commit any new features to master, only bug fixes and
documentation updates (they should go to sr_3.0, but for a short time
until everybody gets used to the new branch we will use both of them).
If you want to commit new features, please use another branch name,
either something under tmp/ or under <your_username>/ and we will merge
it into master once the freeze is over.
This freeze should last only a short time (maybe 1 week, we'll see how
things are going).
Andrei
Hi, trying to create a new subscriber I've realized that I must insert
the ha1 (ha1b doesn't appear) by hand... doesn't SIREMIS implement the
generation of the MD5 values by inserting the text plain password?
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
i have twinkle registered from behind nat over tcp and another sip phone
registered over udp using the same aor and q value. this aor is then
called by another sip phone and sr forks the invite:
Oct 28 17:58:37 localhost /usr/sbin/sip-proxy[28989]: INFO: Routing first INVITE to <sip:foo@192.168.0.169:5074;transport=tcp> and <<sip:JzlUogbN0_q5BaWAN1Zv@xx.xx.xx.xx>;q=0>
...
twinkle answers and sends 200 ok. 200 ok is received by the calling
phone, which then sends ack to twinkle via sr, the problem is that
twinkle never receives the ack. instead sr reports a tcp error:
Oct 28 17:58:46 localhost /usr/sbin/sip-proxy[28994]: INFO: Routing in-dialog ACK from <sip:foo.bar@foo.bar> to <sip:foo@192.168.0.169:5074;transport=TCP>
Oct 28 17:58:46 lohi /usr/sbin/sip-proxy[28994]: WARNING: <core>
[tcp_main.c:1200]: WARNING: tcp_do_connect 192.168.0.169:5074: could not
find corresponding listening socket for 192.X.Y.2, using
default...
...
Oct 28 17:58:51 localhost /usr/sbin/sip-proxy[29140]: ERROR: <core>
[tcp_main.c:3747]: connect 192.168.0.169:5074 failed (timeout)
weird thing about the warning is that it mentions ip address 192.X.Y.2,
which is not any of the ip addresses sr has configured to listen at.
192.X.Y.2 is the ip address of eth0 of sr host, but sr is listening at
192.X.Y.10, which is address of interface eth0:1.
am i missing some magic from sr tcp config or what could be the reason
that sr is trying to find non-existing listening socket?
i do have wireshark capture of this if it helps.
-- juha
Module: sip-router
Branch: master
Commit: ed3902e9bd5a3af6ee5d5df08ce2564f028a0f24
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=ed3902e…
Author: Jan Janak <jan(a)ryngle.com>
Committer: Jan Janak <jan(a)ryngle.com>
Date: Sun Oct 18 00:39:31 2009 +0200
tm: Number of fixes in code and documentation for serial forking.
This patch improves the serial forking related code and documentation.
The original code suffers from shortcommits, some of which were result
of the migration to the new core.
The function that decodes destination sets encoded in AVPs has been
improved, because the original version did not handle properly strings
with missing elements. In such case the original implementation was
likely to overwrite memory, because it did not check the return value
of strchr properly. The new implementation tries to handle this
situation. It continues parsing as long as it can, it only requires
that the request-uri string is present, all other fields are made
optional and their variables are properly initialized if their values
cannot be found in the AVP.
There was a bug in the implementation of fr_inv_timer_next modparam in
the original version, changes to the parameter value were ignored by
the serial forking code. This was reported by Andrei and is now fixed
by this commit. The parameter fr_inv_timer_next can now be configured
at runtime with the configuration framework. Its value is in
milliseconds and unlike fr_inv_timer, this timer cannot be configured
separately for individual branches.
Obsolete definition of INV_FR_TIME_OUT_FIRST has been removed. That
macro is not used anywhere in the code, thus it is not needed.
There were several places where LM_DBG printed a string and relied on
the string being zero terminated, this may or may not be true in the
future and this patch uses the macro STR_FMT where appropriate, which
is safer.
Function t_next_contacts now checks if the function decode_branch_info
really returned values for the dst_uri and the path vector. If not then
it calls reset_dst_uri and reset_path_vector. Previous version of the
code crashed sip-router, this is likely due to the merge and updates in
the sip-router core.
We now use t_set_fr in t_next_contacts for setting the fr_inv_timer
value to fr_inv_timer_next. This is much more efficient than creating
AVPs with new timer values. Also the new value of the timer is now
taken from a variable in the configuration framework, instead of just a
regular global variable configured through modparam. This way we can
adjust the value of the timer on the fly. Configuring it through
modparam is, of course, possible too.
The value of of fr_inv_timer_next is now in milliseconds, instead of
seconds. That's the only possibly incompatible change. However, this is
consistent with all other timers in tm module, it is more efficient and
it offers better granularity.
A missing call to destroy_avp has been added to t_next_contacts, in the
code which is executed when no transaction exists. There, the avp
should also be destroyed if all values have been exhausted and none of
them had Q_FLAG set. This is a corner case which should not happen
under normal circumstances, because that situation only happens if all
branches have the same q value. Such AVP would not have been created by
t_load_contacts and therefore t_next_contacts should not be called, but
this bug may be triggered if someone uses t_next_contacts in an
unexpected way and it is probably better to have it fixed.
Also the code which restores the value of fr_inv_timer at the end of
t_next_contacts did not work properly. This patch fixes that. It first
tries to retrieve a value configured with t_set_fr, but that is not
guaranteed to succeed. After that it also tries the timer AVP and
finally the configuration framework. The configuration framework always
yields a value, so we can always restore the timer value, but we may
fail to restore individual transaction timer values set by t_set_fr. If
that fails then the global value from the configuration framework is
used. This is documented as a shortcomming in the README and in the
code.
In addition to code changes this patch also expands documentation on
functions t_load_contacts and t_next_contacts, describing their
operation in more detail. Also the format of the contacts AVP is now
documented.
Finally, there is a whole new section in the README which describes
how serial/parallel forking can be achieved with t_load_contacts and
t_next_contacts and provides a number of examples.
---
modules/tm/README | 592 +++++++++++++++++++++++++++---------------
modules/tm/config.c | 7 +-
modules/tm/config.h | 3 +-
modules/tm/doc/functions.xml | 129 ++++++++--
modules/tm/doc/params.xml | 83 +++++--
modules/tm/doc/tm.xml | 218 ++++++++++++++++
modules/tm/t_serial.c | 208 ++++++++++------
modules/tm/tm.c | 2 +-
8 files changed, 900 insertions(+), 342 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=ed3…
today i noticed that stored messages are not removed from silo table
after delivery and they will be delivered again target ua
re-registers after an hour.
target ua receives the stored messages normally and wireshark shows that
200 ok gets back to sr fine. sr does not try to resend message, so i
assume that its transaction layer accept the 200 ok.
any ideas why delivered messages stay in silo table. this has worked
fine in k.
-- juha