Hello,
a kind reminder for today's audio conference scheduled for 16:00GMT.
Check the start time for your zone at:
http://vuc.me/next
After presenting the achievements so far within SIP Router, with what is
new in 3.0.0 release and development version, you have an unique
opportunity to ask questions to:
- Andrei Pelinescu-Onciul, the creator of SIP Express Router (SER), the
architect behind the core (transport layers, memory management,
asynchronous processing, timers, etc), who will be …
[View More]also able to answer
anything from project's history started in 2001
- Alex Balashov, Kamailio management team member, experienced consultant
in building large SIP platforms
- myself, as co-founder of Kamailio (OpenSER)
You can join via irc on #vuc (note that some of us started to hang out
on #sip-router) channel at irc.freenode.net.
Dialing to VUC is possible via sip, skype, pstn, web page and more, see:
http://vuc.me
Five hours to go right now, hear you then!
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
[View Less]
Hello,
I have the pleasure to announce that our project has an accepted
application for Google Summer of Code 2010. The proposed application was
done within SIP Communicator Organization and is related to extending
the presence server for conference calls notifications. See more:
http://www.sip-communicator.org/index.php/GSOC2010/Kamailio4575http://www.sip-communicator.org/index.php/Development/Gsoc2010
The friends from SEMS project will be part as well, with separate
application, …
[View More]implementing the audio mixer part.
More details will be published soon. Start thinking about good
candidates (they must be students (college or university)), we need them
to get the project accepted for implementation.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
[View Less]
Revision: 5996
http://openser.svn.sourceforge.net/openser/?rev=5996&view=rev
Author: mariuszbihlei
Date: 2010-03-19 10:35:11 +0000 (Fri, 19 Mar 2010)
Log Message:
-----------
modules/carrierroute Documentation for cr_reload_routes in case of carrier mapping is changed.
We do not allow cr_reload_routes when a carrier name has changed, so documentation states now that
a restart of the server is to be done. (Server craches in some cases when carrier name has changed and
…
[View More]cr_reload_routes is issued This affects only 1.3 version of carrierroute)
Modified Paths:
--------------
branches/1.3/modules/carrierroute/doc/carrierroute_user.sgml
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
[View Less]
Hey Iñaki,
Iñaki Baz Castillo wrote:
> 2010/3/12 Timo Reimann <timo.reimann(a)1und1.de>:
>
>> If so, my major concern with this approach is that it will break dialog
>> callback functionality. If a dialog user, upon creation of an
>> unconfirmed dialog (initial request received), registers for further
>> callbacks associated with that dialog (for instance, DLGCB_CONFIRMED),
>> it won't get any further callbacks in the scenario outlined above. The
…
[View More]>> reason for this is that when the dialog is terminated due to the 5xx
>> response, all associated callbacks will be swept out too, and the
>> re-created dialog's structure will not contain any callbacks yet.
>
> A suggestion to cover all the cases:
>
> There could be two kinds of dialog entries in the module:
>
> - dialog-in: It's a *single* dialog entry generated upon receipt of
> the INVITE. No info about To-tag is stored with it. It has a status
> field (none, early, confirmed, terminated), but this status is handled
> carefully (see below). This entry exists until the dialog or
> early-dialog is terminated. Callbacks are inserted *here*.
>
> - dialog-out: It's a single or multiple entries pointing to a single
> dialog-in entry. It contains a To-tag and status fields. A dialog-out
> is generated when a response for same Call-ID and From-tag is received
> and contains a new To-tag. Status for each dialog-out is updated
> according to the status of the response (early, confirmed,
> terminated). No callbacks are inserted here.
>
> When a dialog-out is generated (provisional response received) it
> updates the dialog-in status to "early" (so callback is raised), but
> just in case the dialog-in status was "none".
>
> When a dialog-out receives a (200 it also updates the dialog-in status
> to "confirmed" (so callback is raised), just in case it was in "none"
> or "early" status.
>
> When a dialog-out is terminated ([3456]XX response received) it *just*
> updates the dialog-in status to "terminated" in case there are no more
> alive dialog-outs (for parallel forking cases) and *also* in case the
> INVITE transaction has terminated (for serial forking cases in which
> still there is no new branches).
>
>
> I think that with this approach all the cases are covered. Opinions?
Interesting idea. Let me ask two questions:
(1) I re-checked when dialog state is modified exactly for responses
(and believe I have to doubt what I initially claimed to be true):
According to dlg_handlers.c, dlg_onreply() is called right before a
response is forwarded, after it was forwarded, and when the associated
transaction is terminated. (tm callbacks TMCB_RESPONSE_PRE_OUT,
TMCB_RESPONSE_FWDED, and TMCB_TRANS_DELETED, respectively, in Kamailio
1.5. The 3.x branch seems to have renamed TMCB_RESPONSE_PRE_OUT to
TMCB_RESPONSE_READY and TMCB_TRANS_DELETED to TMCB_DESTROY. Correct me
if this wasn't just for the looks.) So, taking into account that (serial
and parallel) forking proxies will *forward* responses only when all
forking attempts have finally failed or one succeeded, wouldn't that
automatically implement your "dialog-outs will properly adjust
dialog-in's state" approach and render dialog-outs unnecessary? Or am I
wrong on the assumption how forking works?
(2) How would your approach deal with unconfirmed requests traversing
the same proxy multiple times, i.e., what has been denoted as
"spiraling" in this thread, as in this example:
UA1 --> P1 --> P2 --> P1 --> UA2
Will that result in the creation of two dialog(-in)s?
Cheers,
--Timo
[View Less]
Hello,
I was thinking to get an easy way to build flavours completely out of
the same source tree, one of the benefits is to have only one branch for
future releases.
make FLAVOUR=abc cfg
does most of the job. The missing pieces are manual pages and some doc
files (e.g., INSTALL).
My idea is to restructure a bit the pkg content:
pkg:
|
+--- default -+-- docs (Install, man pages, etc)
| |
| +-- debian
| +-- rpm
| +-- ...
|
+--- abc -----+-- …
[View More]docs (Install, man pages, etc)
|
| +-- debian
| +-- rpm
| +-- ...
|
make FLAVOUR=... cfg
will copy the docs files from pkg/flavour/docs in source tree root.
'default' can be 'sip-router' to match the flavours values right now.
In source tree root plan have README.first where to mention to run make
cfg (which is called anyhow by simple 'make') first to get INSTALL, etc ...
Other opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
[View Less]
Hi!
I have not followed the whole discussion. I just had an idea which might
be useful: Why not hook up dialog module with tm module? Tm module
already knows the state of forked INVITE transaction, which ones are in
early states, and which branch is the winner.
regards
klaus
Am 15.03.2010 14:00, schrieb Iñaki Baz Castillo:
> 2010/3/12 Timo Reimann<timo.reimann(a)1und1.de>:
>
>> If so, my major concern with this approach is that it will break dialog
>> callback …
[View More]functionality. If a dialog user, upon creation of an
>> unconfirmed dialog (initial request received), registers for further
>> callbacks associated with that dialog (for instance, DLGCB_CONFIRMED),
>> it won't get any further callbacks in the scenario outlined above. The
>> reason for this is that when the dialog is terminated due to the 5xx
>> response, all associated callbacks will be swept out too, and the
>> re-created dialog's structure will not contain any callbacks yet.
>
> A suggestion to cover all the cases:
>
> There could be two kinds of dialog entries in the module:
>
> - dialog-in: It's a *single* dialog entry generated upon receipt of
> the INVITE. No info about To-tag is stored with it. It has a status
> field (none, early, confirmed, terminated), but this status is handled
> carefully (see below). This entry exists until the dialog or
> early-dialog is terminated. Callbacks are inserted *here*.
>
> - dialog-out: It's a single or multiple entries pointing to a single
> dialog-in entry. It contains a To-tag and status fields. A dialog-out
> is generated when a response for same Call-ID and From-tag is received
> and contains a new To-tag. Status for each dialog-out is updated
> according to the status of the response (early, confirmed,
> terminated). No callbacks are inserted here.
>
> When a dialog-out is generated (provisional response received) it
> updates the dialog-in status to "early" (so callback is raised), but
> just in case the dialog-in status was "none".
>
> When a dialog-out receives a (200 it also updates the dialog-in status
> to "confirmed" (so callback is raised), just in case it was in "none"
> or "early" status.
>
> When a dialog-out is terminated ([3456]XX response received) it *just*
> updates the dialog-in status to "terminated" in case there are no more
> alive dialog-outs (for parallel forking cases) and *also* in case the
> INVITE transaction has terminated (for serial forking cases in which
> still there is no new branches).
>
>
> I think that with this approach all the cases are covered. Opinions?
>
>
[View Less]
Hello,
this Friday, March 19, late afternoon, the weekly VoIP User Conference
is hosting a session about SIP Router project. My goals are to present
the achievements so far within SIP Router projects, what is new in
Kamailio 3.0 release and plans for the future.
More details can be found at:
http://www.kamailio.org/w/vuc-the-sip-router-project/
You can join the audio conference via sip, skype, pstn line or other
several options presented on http://vuc.me site. There is a irc channel
…
[View More]available for it: #vuc on irc.freenode.net.
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/
[View Less]
Hello,
On Thu, Mar 11, 2010 at 3:32 AM, Nathaniel L Keeling
<keeling(a)akan-tech.com>wrote:
> I am trying to install the new release of Kamailio 3.0.0 on Solaris 10.
> When I perform the install, I am getting this error. Here is the command
> that I am entering for the install:
>
> make prefix=/usr/local/kamailio-3.0.0 INSTALL=install
> group_include="standard standard-dep postgres" CPU=ultrasparc install
>
> install mode
> make[2]: Entering directory `/usr/…
[View More]local/src/kamailio-3.0.0/lib/kcore'
> make[2]: Nothing to be done for `install-if-newer'.
> make[2]: Leaving directory `/usr/local/src/kamailio-3.0.0/lib/kcore'
> touch
> /usr/local/kamailio-3.0.0/lib/kamailio/modules_k/speeddial.so
> install -m 755 speeddial.so
> /usr/local/kamailio-3.0.0/lib/kamailio/modules_k
> make[1]: Leaving directory
> `/usr/local/src/kamailio-3.0.0/modules_k/speeddial'
> mkdir -p /usr/local/kamailio-3.0.0/etc/kamailio/
> # other configs
> /bin/sh: syntax error at line 1: `;' unexpected
> make: *** [install-cfg] Error 2
>
> I am new to Kamailio and would appreciate any help.
>
are you using gmake?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
[View Less]