Hi,
I notice that under my /tmp folder there are openser_receiver filles as
well (kamailio_fifo and kamailio_ctl are know....)
Version is 3.3.2 latest branch.
Any ideas?
Thanks,
Uri
Hi guys,
I wonder if someone could sanity check something for me.
I currently have a simple load balancer set up using algorithm 10 (call
load distribution) from the dispatcher module. I'm using Record-Routing so
that I can clear down the call load record at the end of the call.
Everything looked like it was working okay until I just spotted a problem
that I think might be a bug. It's to do with ACKs to non-200 responses.
In a normal call, the flow goes:
UAC Proxy UAS
1 INVITE -->
2 INVITE-->
3 <-- 200 OK
--- ds_load_update()
4 <-- 200 OK
5 ACK -->
6 ACK -->
Now between step 3 and 4 the proxy runs ds_load_update which according to
the documentation "set internal state to confirmed for the call load" entry
in the internal call state store. This means the proxy knows where to send
the ACK at step 5 because it is safely in the call state store so you can
use ds_select_dst again on the ACK to get it to the right place. Works fine!
Now consider the non-200 case:
UAC Proxy UAS
1 INVITE -->
2 INVITE-->
3 <-- 603 Decline
--- ds_load_unset()
4 <-- 603 Decline
5 ACK -->
6 ACK --> ???
Between step 3 and 4 the proxy is supposed to run ds_load_unset() which
unconditionally removes the call from the call state store. Now when the
ACK comes in at step 5, the proxy has no record of the call and so doesn't
know where to send the ACK. This results in retried Declines and ACKs.
Broken :-(
If the proxy doesn't run ds_load_unset() on the 603 response, is there some
kind of timer that will cause the call to be removed from the call state
store on unconfirmed calls?
I don't think I can run ds_load_unset on the ACK because there's nothing in
the ACK that tells me it is because of a 603, rather than a 200.
Edit: actually there is! The Route header is present on the 200 ACK, but *
not* on the 3xx to 6xx ACK. Maybe I can use loose_route... Anyway, any
thoughts would be appreciated!
Cheers,
Richard
Hello,
based on community interaction, development, package distributions and
documentation maintenance in the recent years, the default flavour has
been switched now to 'kamailio'.
As written in my previous email, we started the last phase to complete
the integration between kamailio-ser, aiming to get to a unique database
schema and set of modules in maximum 6 months.
Kamailio is the most spread and popular flavour, presented in many
linux/unix distributions, being the one released and packaged
periodically. So it will stay as main flavour, the one officially
released by the project. Those that want can take the sources and build
their own flavour, as the support in Makefile system is kept.
Once the integration is finished, the flavour system will just set the
application name, nothing else. From the open source project
perspective, the resources will be allocated only on releasing under the
main/default flavour (Kamailio).
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
we plan to start the last phase of integration between kamailio and ser.
After about 4 years with same source code tree, there is still some
overhead caused by several duplicated modules. Following the decision to
go on with the most developed components and absorb the missing features
from the duplicates, kamailio modules are those that will stay (move to
modules/ eventually) and get updates when needed. We used same decision
to keep the core and makefile system from ser, adding to it what was
extra in kamailio.
I present next a summary of what is planned to happen:
1) Modules from modules_s/ that will be simply moved to modules/ because
there is no conflict at all:
- avp, avp_db, db_ops, eval, mangler, print, print_lib
2) Modules from modules_s/ that will be renamed and moved modules/
because it is mainly only conflict of name, but not in the backend
(e.g., database):
- auth_db => auth_dbattrs - because it uses (attribute,value) style
to store subscriber profiles, which can be a preferred alternative for
many out there
- ldap => db2_ldap - it is a DB APIv2 connector to ldap server
- bdb => db2_bdb - it is a DB APIv2 connector to berkeley db (to be
double-checked)
- xlog => xprintf - it uses %spec to print log messages with all
the code inside the module - the only reason not discarding it and stick
only to modules_k/xlog for the moment is because it is used from other
modules, otherwise modules_k/xlog has more features (e.g., syslog
facility, color printing, a.s.o)
3) Modules from modules_s/ that will be removed, after absorbing some
extra features:
- usrloc/registrar => get the ability to store AVPs per contact
(modules_k is more advanced in features, like path/gruu/partial outbound
support, publish presence states, etc.)
- several modules must be reviewed: acc*, radius*, permissions,
pike, gflags, options, timer
4) Modules from modules_s/ that will be removed, by moving to obsolete/
directory
- the rest of them from modules_s/, like dialog, xcap, cpl-c,
presence_b2b, dispatcher, dbtext, domain, etc.
The categories and their content are not nailed down, it is the purpose
of this discussion to see if something was overlooked.
We hope to end this process in max 6 months time - after that will be a
unique database schema and a unique set of modules. Flavour system in
the Makefile will stay just for letting people choose easier the name of
binary, otherwise everything will be the same (e.g., what is compiled,
installed, etc).
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
Kamailio SIP Server v3.3.2 stable release is out.
This is a maintenance release of the latest stable branch, 3.3, that
includes fixes since release of v3.3.1. There is no change to database
schema or configuration language structure that you have to do on
installations of v3.3.0 or v3.3.1. Deployments running previous v3.x.x
versions are strongly recommended to be upgraded to v3.3.2.
For more details about version 3.3.2 (including links and hints to
download the tarball or from GIT repository), visit:
* http://www.kamailio.org/w/2012/10/kamailio-v3-3-2-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -
http://asipto.com/u/katu
I've added a basic working kamailio.cfg with Shared Call Appearances to the SCA docs. It should help clarify where and when it's necessary to have the sca module inspect traffic. Those of you simply wanting to test SCA can just copy and paste the configuration, updating the listen address as necessary.
Until the sca module doc on kamailio.org gets updated, you can find the sample configuration in the git master branch, or view it through gitweb at the link below.
Best,
andrew
<http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob_plain;f=mo…>
Hello all,
By inspecting the source code, the only difference that I could see
between kamailio and ser flavours is that kamailio has support for the
"tm:local-request".
Are there any constrains in having the tm:local-request present for ser flavour?
Does it make sense to continue to build two flavours?
My suggestion would be to focus one one single flavour and go forward
with it for the next release.
Comments?
Regards,
Ovidiu Sas
--
VoIP Embedded, Inc.
http://www.voipembedded.com
I am having issues with LCR failure route. I have two gateways specified in LCR table, if I change the address of the gateway with highest priority to a bogus IP, the failure route never seems to takes place and call is never routed to second gateway.
Also, I have tested successful calls to both gateways by switching the priorities around.
Here is what I receive after the first gateway times out:
U kamailio:5060 -> asterisk:5060
SIP/2.0 408 Request Timeout.
Via: SIP/2.0/UDP asterisk:5060;branch=z9hG4bK633b44d8;rport=5060.
From: "user" <sip:user@asterisk>;tag=as67c0037f.
To: <sip:dialednumber@domain>;tag=d7177f97ed67076dddc3163c85ab0656-f2e5.
Call-ID: 248d69ed6495d0a65315458e2ba6c528@asterisk:5060.
CSeq: 102 INVITE.
Server: SIP Proxy.
Content-Length: 0.
Config:
modparam("tm", "fr_timer", 10000)
modparam("tm", "fr_inv_timer", 120000)
modparam("lcr", "db_url", DBURL)
modparam("lcr", "gw_uri_avp", "$avp(i:709)")
modparam("lcr", "ruri_user_avp", "$avp(i:500)")
modparam("lcr", "flags_avp", "$avp(i:712)")
modparam("lcr", "lcr_id_avp", "$avp(s:lcr_id_avp)")
route[LCR] {
if (!load_gws(1)) {
sl_send_reply("503", "Internal Server Error, Unable to load gateways");
exit;
} else {
if (next_gw()) {
t_on_failure("LCR_FAIL");
route(RELAY);
} else {
sl_send_reply("503", "Service Unavailable, No available gateways");
exit;
};
};
exit;
}
failure_route[LCR_FAIL] {
if (next_gw()) {
t_on_failure("LCR_FAIL");
route(RELAY);
} else {
t_reply("503", "Service Unavailable, No gateways");
exit;
};
exit;
}
Kamailio project is announcing its first dedicated event - Kamailio
World - to take place in Berlin, Germany, during April 16-17, 2013. The
event is organized by Asipto (http://www.asipto.com) in collaboration
with Fraunhofer Fokus Institute (http://www.fokus.fraunhofer.de).
The conference is targeting to present commercial products and services
build around Kamailio and related projects, as well as technical
workshops of how to use Kamailio for various purposes. Along with the
conference will be space for exhibition, that will allow companies to
make demos and show cases for participants.
For more details, visit the web site of the event:
http://conference.kamailio.com
Besides Kamailio, you will have the chance to interact with other open
source VoIP projects such Asterisk, FreeSwitch, SIP Express Media
Server, Homer SIP Capture, Siremis, a.s.o., as well as with commercial
vendors in real time communications market.
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda