Re: [asterisk-users] asterisk 16 manager --END COMMAND--
On 2018-10-12 12:22, Dmitry Melekhov wrote: >> AMI: >> - The Command action now sends the output from the CLI command as a >> series >> of Output headers for each line instead of as a block of text with >> the >> --END COMMAND-- delimiter to match the output from other actions. >> >> Commands that fail to execute (no such command, invalid syntax >> etc.) now >> return an Error response instead of Success. >> > Very pity that you break compatibility... The old AMI protocol was so broken, so it was hardly possible to make any compatible client implementation. Whatever you do, it would break on some corner cases. This change fixed a little bit of this mess. And if some client library is not properly updated for major Asterisk releases, then that is not Asterisk to blame. Jacek -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] PJSIP TLS certificate reload
Hi, I have a problem with TLS certificate change and, especially, automated renewal. How to make Asterisk reload the certificate with minimal service disruption? Asterisk (PJSIP) doesn't seem to detect certificate changes on its own. It won't normally reload transport settings either, unless it is explicitly allowed, but event then, it probably won't detect any changes when only certificate file contents changes, so reloading pjsip won't help even when the certificate is changed. The only option left is to restart whole Asterisk, which is quite disruptive. Is there any other way? Jacek -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AMI version of CONNECTEDLINE
On 2016-12-12 02:21, David Cunningham wrote: Is there any equivalent of the CONNECTEDLINE function which can be called from an application using the AMI? You can use dialplan functions from AMI using GetVar, so this should work: Action: GetVar Variable: CONNECTEDLINE(num) Jacek -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] [SOLVED] Re: Feature Request: what about "core stop panic" ?
On 2016-09-09 11:34, Olivier wrote: Adding an /etc/sysctl.d/foobar.conf file with the bellow content allowed me to at last produce core dump files (in /var/tmp directory), even if asterisk is run by asterisk user (and by root). I choosed this /var/tmp directory to make sure core dumps are not erased after a reboot and because this directory is "world-writable". To trigger core dumping, previously recommended "pkill -SEGV asterisk" was used. /etc/sysctl.d/foobar.conf content is simply: kernel.core_pattern=/var/tmp/core.%e.%t Maybe taming systemd to consider /var/lib/asterisk as a current directory when running asterisk daemon would be a better solution ? Maybe Asterisk or more generally long running daemons, should warn when they are run with "-g option" and from a current directory where it can't write any file (or any file matching core pattern) ? Maybe this is already done but I overlooked it or looked in the wrong place ? Why not just use the systemd journal and coredumpctl for core files management? systemd solves that quite well. Jacek -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Join the Asterisk Community at the 13th AstriCon, September 27-29, 2016 http://www.asterisk.org/community/astricon-user-conference New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] chan_pjsip ignoring endpoint device state (qualify) on dial
On 2016-08-10 11:53, Joshua Colp wrote: Jacek Konieczny wrote: On 2016-08-09 10:06, Faheem Muhammad wrote: trip time and Call Setup time of SIP Requests. In case of GSM Network with high delay you need to set the T1 timer a higher value like 1000ms (500 ms default). Similarly you can reduce the Call setup time by configuring 'T2' upto you choice as per you telephony network. Configure t1min, timert1 and timerb according to your network. No, that won't work. First – 't1min', 'timert1' and 'timerb' are chan_sip, not pjsip options. Second – the 'timer_t1' and 'timer_b' settings available in 'pjsip.conf' are global and not per-endpoint. I cannot change T1 for trunks, as they might not be fast enough to respond and I cannot set it for phones only. It seems I need to bring back the chan_sip behaviour – 'do not bother with INVITE to Unreachable devices'. I'd suggest filing an issue on the issue tracker[1] for this. It's reasonable behavior. Done: https://issues.asterisk.org/jira/browse/ASTERISK-26281 I just wanted to make sure I am not missing something, first. Jacek -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] chan_pjsip ignoring endpoint device state (qualify) on dial
On 2016-08-09 10:06, Faheem Muhammad wrote: trip time and Call Setup time of SIP Requests. In case of GSM Network with high delay you need to set the T1 timer a higher value like 1000ms (500 ms default). Similarly you can reduce the Call setup time by configuring 'T2' upto you choice as per you telephony network. Configure t1min, timert1 and timerb according to your network. No, that won't work. First – 't1min', 'timert1' and 'timerb' are chan_sip, not pjsip options. Second – the 'timer_t1' and 'timer_b' settings available in 'pjsip.conf' are global and not per-endpoint. I cannot change T1 for trunks, as they might not be fast enough to respond and I cannot set it for phones only. It seems I need to bring back the chan_sip behaviour – 'do not bother with INVITE to Unreachable devices'. Jacek On Tue, Aug 9, 2016 at 12:03 PM, Jacek Konieczny <jaj...@jajcus.net <mailto:jaj...@jajcus.net>> wrote: Hi, We have been migrating our PBX system from Asterisk 1.8 and chan_sip to Asterisk 13 and chan_pjsip. Things are mostly, ok, but now I have stumbled on a behaviour difference I don't like. With chan_pjsip when a phone went unexpectedly offline (Ethernet cable disconnected) Asterisk would detect this quickly (through the 'qualify' pings), mark the phone as 'Unavailable' and fail immediately with 'CHANUNAVAIL' when dialling this phone. With Asterisk 13 and chan_pjsip qualify still works for determining current phone availability (endpoint shown as 'Unavailable' shortly after disconnecting the cable), but the phone is being dialled like nothing is wrong – Asterisk sends the INVITE and waits for the response, until SIP timeout (a bit more than 30s total). That is much longer time until 'CHANUNAVAIL' than I expect. It is also longer than the dial timeout in some cases, so I would get 'NOANSWER' instead of 'CHANUNAVAIL' which breaks my dialplan logic. Is that that the expected behaviour, a bug or a configuration problem? Am I supposed to check for device availability in my dialplan? Greets, Jacek -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users <http://lists.digium.com/mailman/listinfo/asterisk-users> -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] chan_pjsip ignoring endpoint device state (qualify) on dial
On 2016-08-09 10:06, Faheem Muhammad wrote: Jacek, This might be a bug or configuration issue, but you need to understand the SIP Session Timers. With Session Timers you can control the round trip time and Call Setup time of SIP Requests. I don't think you really mean SIP Session Timers (https://tools.ietf.org/html/rfc4028) these do not affect RTT or call setup, but provide kind of 'keepalive' and session expiration for established calls. In case of GSM Network with high delay you need to set the T1 timer a higher value like 1000ms (500 ms default). Similarly you can reduce the Call setup time by configuring 'T2' upto you choice as per you telephony network. Configure t1min, timert1 and timerb according to your network. Also set session-type=uas. Yes, tweaking the T1 and T2 timers may work for me. I'll try that, though the old 'qualify' magic with chan_sip was quite convenient. I wonder why it doesn't work with chan_pjsip. Jacek -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] chan_pjsip ignoring endpoint device state (qualify) on dial
Hi, We have been migrating our PBX system from Asterisk 1.8 and chan_sip to Asterisk 13 and chan_pjsip. Things are mostly, ok, but now I have stumbled on a behaviour difference I don't like. With chan_pjsip when a phone went unexpectedly offline (Ethernet cable disconnected) Asterisk would detect this quickly (through the 'qualify' pings), mark the phone as 'Unavailable' and fail immediately with 'CHANUNAVAIL' when dialling this phone. With Asterisk 13 and chan_pjsip qualify still works for determining current phone availability (endpoint shown as 'Unavailable' shortly after disconnecting the cable), but the phone is being dialled like nothing is wrong – Asterisk sends the INVITE and waits for the response, until SIP timeout (a bit more than 30s total). That is much longer time until 'CHANUNAVAIL' than I expect. It is also longer than the dial timeout in some cases, so I would get 'NOANSWER' instead of 'CHANUNAVAIL' which breaks my dialplan logic. Is that that the expected behaviour, a bug or a configuration problem? Am I supposed to check for device availability in my dialplan? Greets, Jacek -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
