Hello,I'd like to use a feature code for stopping recordings. Things are
quite easy when the call is received from the outside or just dialed from
inside to outside, but it can go really crazy when there are blind and
attended transfer going on. It ends I don't know on which call leg is the
Starting to make sense when I saw this line:
[2015-08-18 15:01:33] DEBUG[19366][C-1cfc]: pbx.c:3785
ast_str_retrieve_variable: Result of 'OUT_3_SUFFIX' is '@CUBE'
But I can’t find where this is in configuration ..
Brendan Ord
OntheNet - Network Engineer
P 07 5553 9222
F 07 5593 3557
Level
just got back to my mail.
What I'd do is go into /etc/asterisk and grep for OUT_3_SUFFIX in all the files
once the file with that variable is located, we can figure out why it's adding
it
On 08/17/2015 11:26 PM, David Cunningham wrote:
Yes indeed.
Do you have the dialplan, eg from
Hello,
So, I found this line under macro-dialout-trunk, in extensions_additional.conf
(FreePBX, so it controls the conf files mostly);
exten =
s,n,Dial(${OUT_${DIAL_TRUNK}}/${OUTNUM}${OUT_${DIAL_TRUNK}_SUFFIX},${TRUNK_RING_TIMER},${DIAL_TRUNK_OPTIONS})
If I grep for OUT_3_SUFFIX in all files
yes, the sip_buddies (or equal) has a field that says which server handled the
registration
On 08/17/2015 07:58 AM, Mehdi Shirazi wrote:
Hi
If we have a shared RealTime database for sip registration of multiple
Asterisk servers, is there a way to realize which Asterisk server registered
sip
Hi all,
I'm using Kamailio + Asterisk 13 (PJSIP), where Kamailio (using rtpengine)
acts as the registrar and forwards all calls to Asterisk.
This works fine when using udp / tcp and RTP. When switching to TLS/SRTP,
the call is set up correctly, however, I get no audio.
When I skip kamailio and
Yes indeed.
Do you have the dialplan, eg from /etc/asterisk/extensions.conf?
Something is getting this OUT_3_SUFFIX variable and including it in a Dial
to 172.22.4.12.
On 18 August 2015 at 16:21, Brendan Ord b...@staff.onthenet.com.au wrote:
Starting to make sense when I saw this line:
Halt the wild goose chase
It was obviously something left over in the dial plan. Restarted Asterisk
seeing as though we're now after-hours and I can do interruptive work, and it
seems to have solved my @CUBE problem.
Interestingly, it persisted through a dialplan reload and the
Glad to hear it's sorted.
On 18 August 2015 at 17:08, Brendan Ord b...@staff.onthenet.com.au wrote:
Halt the wild goose chase
It was obviously something left over in the dial plan. Restarted Asterisk
seeing as though we're now after-hours and I can do interruptive work, and
it seems
