Hello,
I am redirecting the agents/reps to their asterisk server based on the
hostname which they connect, and, i wonder if it's possible to read from db
instead of the file cause it's getting big ;)
# Dispatch requests
route[DISPATCH] {
switch ($fd){
case "oro.streamlinepbx.nl":
if (!ds_select_dst("1", "4")) {
send_reply(503, "Service
Unavailable $fd");
exit;
}
break;
case "oro3.streamlinepbx.nl":
if (!ds_select_dst("2", "4")) {
send_reply(503, "Service
Unavailable $fd");
exit;
}
break;
............
default:
log("unknow destination?");
send_reply(503, "No service defined");
xlog("--- SCRIPT: going to <$ru> via <$du>
...Exiting");
exit;
}
xlog("--- SCRIPT: going to <$ru> via <$du> (attrs:
$xavp(_dsdst_=>attrs))\n");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
Thanks,
A year that was very tough for the entire world is getting close to its
end, no doubt that was the most challenging in our life so far for many
of us, however, with a distributed, friendly and collaborative
community, Kamailio project continued to develop consistently, bringing
out a new major release. I trust it helped people and companies world
wide to to connect with the dear ones and build a better way of living.
The season holidays are ahead, time to rest a bit, spend time with
family and friends, being online or face to face. As usual, I take this
chance to express my thanks and greetings to all the friends,
developers, supporting companies and community members that made 2020
another great year for Kamailio project.
Enjoy the holidays! Merry Christmas!
Daniel
* Santa is flying Kamailio! *
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hallo,
I try to install the module app_lua in Kamailio 5.3.
ls: cannot access '/usr/lib/liblua*': No such file or directory
ls: cannot access '/usr/lib/liblua*': No such file or directory
CC (gcc) [M app_lua.so] app_lua_mod.o
In file included from app_lua_mod.c:32:
app_lua_api.h:25:10: fatal error: lua.h: No such file or directory
#include <lua.h>
^~~~~~~
compilation terminated.
make[2]: *** [../../Makefile.rules:100: app_lua_mod.o] Error 1
make[1]: *** [Makefile:511: modules] Error 1
make[1]: Leaving directory '/usr/local/src/kamailio-5.3/kamailio/src'
make: *** [Makefile:34: all] Error 2
Any help appreciated
Greeting Rob van den Bulk
FOSDEM - Real Time Communications devroom CfP
=============================================
NOTE: we have extended the deadline but we will give preference
to people who submitted earlier when we set the time for each
talk. Please submit your proposal ASAP so that you can get
your preferred time slot.
Overview
--------
[FOSDEM](https://fosdem.org) is one of the world's premier meetings of
free software developers, with over five thousand people attending each
year. FOSDEM 2021 takes place 6-7 February 2021 and for the very first
time, it will be online.
This document contains information about:
- Real-Time Communications developer room (devroom)
- speaking opportunities
- volunteering
New rules for the online edition
--------------------------------
This year FOSDEM will be fully online instead of being held in Brussels,
here are the most important things to know about this (quite
significant) change:
- The reference time will be Brussels local time (CET)
- Talks will be pre-recorded in advance, and streamed during the event
- The Q/A session will be live
- A facility will be provided for people watching to chat between
themselves
- A facility will be provided for people watching to submit questions
Call for participation - Real Time Communications (RTC)
-------------------------------------------------------
The Real-Time devroom is about all things involving real-time
communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP,
codecs, peer-to-peer, privacy and encryption.
**We are looking for speakers for the devroom and volunteers who can
help manage the scheduling and live Q&A sessions.**
The devroom is only on Saturday, 6th of February 2021.
To discuss the devroom, volunteer or ask questions, please join the
[Free-RTC mailing
list](http://lists.freertc.org/mailman/listinfo/discuss).
### Key dates
- 20th Dec: Submission deadline (extended to 8 January)
- 24th Dec: Announcement of selected talks
- 15th Jan: Presentations upload deadline
- 6th & 7th Feb: Conference dates (online)
- 6th Feb: RTC devroom date (online)
### Speaking opportunities
Note: if you used FOSDEM Pentabarf before, please use the same
account/username
Real-Time Communications devroom: deadline 23:59 UTC on 20th of
December. Please use the
[Pentabarf](https://penta.fosdem.org/submission/FOSDEM21/) system to
submit a talk proposal for the devroom. On the "General" tab, please
look for the "Track" option and choose "Real Time Communications
devroom".
### First-time speaking?
FOSDEM devrooms are a welcoming environment for people who have never
given a talk before. Please feel free to contact the devroom
administrators personally if you would like to ask any questions about
it.
This year this is more true than ever, being able to record your
presentation offline without an audience in front can greatly help build
up one's confidence!
### Submission guidelines
The Pentabarf system will ask for many of the essential details. Please
remember to re-use your account from previous years if you have one.
In the "Submission notes", please tell us about:
- The purpose of your talk
- Any other talk applications (devrooms, lightning talks, main track)
- Availability constraints and special needs
You can use HTML and links in your bio, abstract and description.
If you maintain a blog, please consider providing us with the URL of a
feed with posts tagged for your RTC-related work.
We will be looking for relevance to the conference and devroom themes,
presentations aimed at developers of free and open source software about
RTC-related topics.
Please feel free to suggest a duration between 20 minutes and 55 minutes
but note that the final decision on talk durations will be made by the
devroom administrators based on the number of received proposals. As the
two previous devrooms have been combined into one, we may decide to give
shorter slots than in previous years so that more speakers can
participate.
Please note FOSDEM aims to record and live-stream all talks. The CC-BY
license is used.
### Recording help
The devroom organization is able to provide help with recording your
session. The recording would be performed at a scheduled time with one
of us, so you won't be alone giving your presentation. Minimal edits
will be possible, but the ideal plan is to record it in one shot.
Thanks Dan Jenkins for providing us with the means to do this!
Volunteers needed
-----------------
To make the devroom run successfully, we are looking for volunteers.
This year many things be done for the first time, so all the help we can
get is more than welcome.
Spread the word and discuss
---------------------------
If you know of any mailing lists where this CfP would be relevant,
please forward this document. If this devroom excites you, please blog
or microblog about it, especially if you are submitting a talk.
If you regularly blog about RTC topics, please send details about your
blog to the planet site administrators:
- All projects https://planet.freertc.org planet(a)freertc.org
- XMPP https://planet.jabber.org ralphm(a)ik.nu
- SIP https://planet.sip5060.net planet(a)sip5060.net
Please also link to the Planet sites from your own blog or web site as
this helps everybody in the free real-time communications community.
Contact
-------
For any private queries, contact us directly using the address
**fosdem-rtc-admin(a)freertc.org** and for any other queries please ask on
the [Free-RTC mailing
list](http://lists.freertc.org/mailman/listinfo/discuss).
The devroom administration team:
- Saúl Ibarra Corretgé <s(a)saghul.net>
- Ralph Meijer <ralphm(a)ik.nu>
- Daniel-Constantin Mierla <miconda(a)gmail.com>
- Daniel Pocock <daniel(a)pocock.pro>
- Guus der Kinderen <guus.der.kinderen(a)gmail.com>
Hello,
I'm a newbie when it comes to Kamailio and I would like to know if there's a
working example of a Mid-Registrar implementation. I read on other posts
that the UAC module can be used to achieve this but, honestly, I don't
understand how. If any of you could provide some path I could follow I would
be very thankful.
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
Any updates on this?
On Tue, Dec 15, 2020 at 8:13 PM Syed Shahryar <syedshahryar(a)gmail.com>
wrote:
> I am new to Kamailio so may be doing something wrong. I looked at
> https://www.kamailio.org/wiki/cookbooks/5.4.x/core.
>
> I tried the following combinations but getting errors in all cases:
>
> #!subst "/EVAPI_PORT/$env(EVAPI_PORT)/"
> #!substdef "/EVAPI_PORT/$env(EVAPI_PORT)/"
> #!substdefs "/EVAPI_PORT/$env(EVAPI_PORT)/"
>
> *Errors:*
> 0(6) ERROR: <core> [core/pvapi.c:924]: pv_parse_spec2(): error searching
> pvar "env"
> 0(6) ERROR: <core> [core/pvapi.c:1127]: pv_parse_spec2(): wrong char
> [E/69] in [$env(EVAPI_PORT)/] at [5 (5)]
> 0(6) ERROR: <core> [core/re.c:170]: parse_repl(): bad specifier in
> replace part /$env(EVAPI_PORT)/
> 0(6) ERROR: <core> [core/ppcfg.c:69]: pp_subst_add(): bad subst
> expression: /EVAPI_PORT/$env(EVAPI_PORT)/
>
> At a later step, I would like to do:
> #!define EVAPI_LISTEN "0.0.0.0:EVAPI_PORT"
>
> And use EVAP_LISTEN in mod_param for the evapi module.
>
> And something similar to above for TLS settings.
>
>
> On Tue, Dec 15, 2020 at 12:41 PM Daniel-Constantin Mierla <
> miconda(a)gmail.com> wrote:
>
>> Hello,
>>
>> as written on the tracker, look at using #!subst or #!substdef (see core
>> cookbook), they should be able to get the substitution value from
>> environment using $env(NAME).
>>
>> The master branch introduced #!defenv as a (simpler) alternative.
>>
>> Cheers,
>> Daniel
>> On 12.12.20 05:33, Syed Shahryar wrote:
>>
>> I tried many combinations of the following but I keep getting syntax
>> errors:
>>
>> listen=tls:TLS_IP:$env(TLS_PORT) advertise PUBLIC_IP:$env(TLS_PORT)
>>
>>
>> TLS_IP and PUBLIC_IP are constants defined at the top using #!define.
>> And, TLS_PORT is supposed to be the env variable.
>>
>>
>> --
>> --
>> This message contains confidential information and is intended only for
>> the individual named. If you are not the named addressee, you should not
>> disseminate, distribute or copy this email. Please notify the sender
>> immediately by email if you have received this email by mistake and delete
>> this email from your system. Email transmission cannot be guaranteed to be
>> secure or error-free, as information could be intercepted, corrupted, lost,
>> destroyed, arrive late or incomplete, or contain viruses. The sender,
>> therefore, does not accept liability for any errors or omissions in the
>> contents of this message which arise as a result of email transmission. If
>> verification is required, please request a hard-copy version.
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Funding: https://www.paypal.me/dcmierla
>>
>>
>
> --
> --
> This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee, you should not
> disseminate, distribute or copy this email. Please notify the sender
> immediately by email if you have received this email by mistake and delete
> this email from your system. Email transmission cannot be guaranteed to be
> secure or error-free, as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender,
> therefore, does not accept liability for any errors or omissions in the
> contents of this message which arise as a result of email transmission. If
> verification is required, please request a hard-copy version.
>
--
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by email if you have received this email by mistake and delete
this email from your system. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission. If
verification is required, please request a hard-copy version.
Hello,
I consider using keydb-server in an active/action setup without sentinel.
Do you know if there is a way to declare both hosts in ndb_redis with the same server name (target use : topos) ?
Regards,
David
Apologies for not having included the sr-users in the previous email.
Anyhow, the solution suggested by Social Boh indeed worked, as a side
effect of which we would not run into the issue described.
*NOTE:* There was a peculiar configuration in keepalived with keeping both
the nodes as BACKUP and setting the 'nopreempt' flag only in the actual
MASTER(one with higher 'priority') side to make the keepalived thing to
work properly.
However, I was wondering if someone could confirm if this issue has been
fixed inside the source code itself as I am using an older release v5.3.2
Regards,
Harneet Singh
On Thu, Dec 17, 2020 at 9:52 PM harneet singh <hbilling(a)gmail.com> wrote:
> Thanks Social Boh,
>
> I will investigate this possibility and if it does work in our case, that
> should circumvent the issue.
> In addition, is there a fix known to the SR-Users which could be available
> inside the Dispatcher module to cause syncing just like the syncing is
> there in the Dialog module via DMQ. I wanted to check this as I am using
> v5.3.2 and unaware if new releases could have fixed this issue?
>
> Regards,
> Harneet Singh
>
> On Wed, Dec 16, 2020 at 10:46 PM Social Boh <social(a)bohboh.info> wrote:
>
>> Maybe a option is leave the secondary like primary when primary go up
>> newly.
>>
>> Example: Primary go down, Secondary is the new Primary. Primary came back
>> up but Secondary still is the VIP and still process the calls.
>>
>> Only if Secondary go down, primary is the new VIP.
>>
>> The keepalived parameter for this behaviour is:
>>
>> *nopreempt*
>>
>> ---
>> I'm SoCIaL, MayBe
>>
>> El 16/12/2020 a las 11:57 a. m., harneet singh escribió:
>>
>> Hi All,
>>
>> I am using Kamailio in HA mode with Keepalived providing the VIP(Virtual
>> IP) functionality, and have run into a rather peculiar issue.
>>
>> *Setup:*
>>
>> Caller ------------ KamailioVIP(*Primary *and *Secondary*
>> Kamailio)------- Callee
>>
>> HA provided by Keepalived
>> DMQ is used between the Primary and Secondary Kamailio for dialog sync
>>
>> *Issue Seen:*
>>
>> *Suppose the Primary Kamailio has been brought down* and the Secondary
>> one is actually active and tied to the VIP.
>>
>> When a call is fired from the Caller, it traverses through the Secondary
>> Kamailio and lands onto the callee. The dialogs are updated properly. At
>> this point, the Primary Kamailio is brought up, and dialog state is synced
>> due to the DMQ module.
>> The Keepalived will now attach the VIP to the Primary Instance. If the
>> caller hangs up the phone at this point, the BYE sip message traverses
>> through the Primary Kamailio instance to the callee and the call is
>> cleared, but there are two issues here.
>>
>> 1. The Primary Kamailio throws an error in *ds_load_remove() *saying
>> that it cannot find the load for the specific call id. This is apparently
>> due to the fact that the dispatcher data is not synced between the two
>> modules but dialog data is. So dialog wise, things are fine. Can this be
>> fixed somehow?
>>
>> 2. The above is still as grave a problem as the dialogs are cleared.
>> BUT, if we check the '*kamcmd dispatcher.list*' on the *SECONDARY*
>> kamailio even well after the call is cleared, the *DLGLOAD* shows 1.
>> Since we are using the *Call Load based distribution* for the
>> dispatching, this is effectively one call stuck on the dispatcher, which
>> leads to resource leak.
>>
>> Is this a known issue, and if so, do we have a way to circumvent this?
>>
>> Regards,
>> Harneet Singh
>> --
>> "Once you eliminate the impossible, whatever remains, no matter how
>> improbable, must be the truth" - Sir Arthur Conan Doyle
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
> --
> "Once you eliminate the impossible, whatever remains, no matter how
> improbable, must be the truth" - Sir Arthur Conan Doyle
>
--
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
Hello,
Kamailio SIP Server v5.3.8 stable has been released.
This is a maintenance release of the previous stable branch (5.3), that includes fixes since the release of v5.3.7. There are no change to database schema or configuration language structure that you have to do on previous installations of v5.3.x.
Deployments running previous v5.3.x versions are recommended to be upgraded to v5.3.8.
For more details about version 5.3.8 (including links and guidelines to download the tar file or from GIT repository), visit:
https://www.kamailio.org/w/2020/12/kamailio-v5-3-8-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com<https://gilawa.com/>
Hi, I have been trying to integrate MSTeams with PBX Through Kamailio. Calls are working now. Hold has Issues. MSTeams uses REFER to manage this all with NOTIFY.
I am sending t_send_reply("202", "Accepted");
when receive Refer now I need to send NOTIFY I think I can use t_uac_send() NOTIFY I am unable to send t_uac_send properly on when recertifications refer from MSTeams.
Any one with the experience on this ?
Thanks,