Hello,
I suggest to run kamailio with debug=3 in kamailio.cfg to see if the
ringing state is published by dialog/pua_dialoginfo during the call setup.
On the other hand, the dialoginfo is a different event than user/device
presence state, so the endpoints have to subscribe for both dialog info
and presence states to get notifications on both cases. Eventually you
can enhance the config (or code) to generate presence states on
dialog-info events -- iirc, with pua (or pua_json), you can push any
PUBLISH (or presence states).
Cheers,
Daniel
On 11.06.20 18:43, Pover A.V. wrote:
Summary: Using Kamailio to load balance between Asterisk servers.
Trouble getting call queuing working because can’t get device state
hints to work reliably.
—
Hello
I’d be grateful for any advice that can be offered for this problem to
do with presence and call queueing.
I have 3 Kamailio (v5.3.4) servers that load-balance incoming traffic
from various sources: a legacy PBX, soft phone clients, and a SIP
trunking service.
Sitting behind the 3 Kamailio servers are 2 Asterisk (v16 LTS) servers.
Kamailio acts as a registrar and user location service. Asterisk is
routing calls and (should be) providing device state information for
each extension.
An external script builds a list of PJSIP endpoints based on the
content of the Kamailio subscriber table, and deploys it to the
Asterisk servers whenever a change is detected. The AOR for each
record is configured to point to Kamailio. No authentication details
are attached to these endpoints, as Kamailio is doing authentication
before dispatching a request to Asterisk.
Whenever Kamailio receives an INVITE, it passes this to an Asterisk
server using the dispatcher module (round-robin algorithm ‘4’);
asterisk then processes the request.
At the moment, everything is working except for presence/device states
and call queueing.
I’ve tried to set up ‘presence’, ‘pua’, ‘dialog’ and
‘(presence/pua)_dialoginfo’ modules on Kamailio with limited success.
The presence state when a user toggles ‘do not disturb’ on their soft
phone is passed to other users who are subscribed (watching), however
when a user makes a call, no presence updates are seen by subscribed
users (the extensions show as ‘Idle’ or ‘Available’ instead of ‘In
Use’ or ‘Busy’).
Asterisk is able to report that an extension is ‘Ringing’ or ‘InUse’
when a call is made to that extension, because an INVITE to an
internal extension matches a pattern in the dialplan and Asterisk
routes it to a PJSIP endpoint with the same name. However, when
somebody makes a call, Asterisk is unable to track the state of the
extension making the call because the call is going via Kamailio so
Asterisk is not seeing the caller as an internal extension. We need a
way to make Asterisk think the call is coming from an internal device
if the caller ID matches a PJSIP endpoint.
Both Asterisk servers are configured to share device state updates
with each other, and this is working.
Without being able to see device state for an internal calling party,
we will be unable to reliably set up call queues in Asterisk.
Using the ‘mohqueue’ module on Kamailio is not something we want to do
because of its reliance on a database, which is creating a single
point of failure – if the database server is down for any reason,
Kamailio refuses to start.
Ideally, we would achieve some form of distributed call queueing,
however the simplest option seems to be setting up a queue on one
Asterisk server and having an active-passive high availability
configuration, should a server go down.
I’m looking for advice on how best to keep track of what is happening
in a call, and for Asterisk to know the states of each extension and
make these available in a dialplan hint. Or any other suggestions that
might help to achieve call queueing in this setup.
Thank you
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla --
www.asipto.com
www.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding:
https://www.paypal.me/dcmierla