Hello,
I understand that machines processing RTP are recommended to be physical machines. Does the same apply for machines just proxy'ing RTP?
Also, after how many RTP session would you start noticing issues with RTP when using rtpproxy on a virtual VMware machine?
Regard,
Grant
Hi,
We're hitting an issue in a deployment where all udp receivers are
sitting in FUTEX_WAIT caused by save() -> lock_udomain() and seem to
have deadlocked themselves every couple of days.
Looking at the code, enable_gruu in registrar is active by default, and
in lookup there is a code path
/* temp-gruu lookup */
res = ul.get_urecord_by_ruid(_d, ahash, &inst, &r, &ptr);
but no lock_udomain is obtained. However, when the execution falls
through to the "done:" marker, it does
ul.unlock_udomain(_d, &aor);
without having called ul.lock_udomain first.
1.) Could someone please review this part? Looks a bit suspicious,
although I don't know what implicitly happens in this case. If it were a
semaphore and you decrease it to -1 by decrementing it without prior
increment, it's essentially causing a dead-lock, but the current locking
implementation might work completely different.
2.) Since I have no clue how gruu is supposed to work in detail, and
since in our config we don't explicitly handle gruu (no lookup in
loose-route, but gruu is enabled by default in registrar and we don't
explicitly turned it off), I'm not even sure if we ever hit this code
path. I only see that the ruid column in the location table is filled,
but in order to get to this part, the ";gr" flag needs to be set in the
R-URI for a lookup(), which I don't know whether that happened somehow
in some call flows (we only log $ru, which I don't think logs these
parameters, right?).
Some input is highly appreciated!
Andreas
> Sorry, yeah. you should probably ignore that part :-) The same dispatcher
>deals with client connections from the "public" network as well as inbound
Ok thanks, it's clear now. :)
>> In the REGFWD route you send all the registrations to ALL the Asterisks?
>> If so, why?
> By sending the registration to all the available Asterisk servers then they
> all know where each SIP client can be located. If a call comes in from the
> PSTN or from a SIP client Kamailio can just be sent it to any of the *
> servers and it will find the registered client. This will work even with
> multiple load balancers/dispatchers using DNS SRV.
In this way should be an option to keep registration in Kamailio only,
let Asterisk do its specific job, and configure Asterisk to accept all calls
coming from Kamailio as authorized calls by its IP?
> In this scenario Kamailio is mainly acting as a load balancer, topology
> hider and security/anti-flood front-end to create a scalable and redundant
> Asterisk PBX system. Really depends what you are after.
These are exactly my goals and was trying to understand which is the best way to achieve this.
Any suggestion is welcome, thanks.
Anty
------------------------------
Message: 3
Date: Tue, 30 Apr 2013 23:02:20 +0100
From: Barry Flanagan <barry(a)flanagan.ie>
To: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.sip-router.org>
Subject: Re: [SR-Users] Kamailio 3.x and Asterisk Realtime Integration
plus
Message-ID:
<CALJb54_1FGmGV4HfmR1zHgcAGqMsSPu6kriTv72W3adyHF3dQw(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
Hi everyone,
I believe I've run into a problem when using dlg_end_dlg (with mi_datagram ) called from an external perl script with perl_exec() .
Kamailio just locks after a while (few seconds) after disconnecting a call.
Some parts of my debug log can be found here:
http://pastebin.com/ANaTEifC
The problem was observed while performing a stress test.
Is it a good idea to call dlg_end_dlg() like that or I can kill an established dialog from the routing script in some other way ?
Regards,
Dragos
