00:30.47 | Helenah2 | How come Zoiper wants money if it is crap? |
00:31.17 | Helenah2 | No seriously, all softphones seem crappy |
00:31.40 | Helenah2 | In that they sound bad, they don't stay awake in the background when running on cell phones. |
00:38.27 | *** join/#asterisk war9407 (war@2600:4040:4001:1e00::f7aa) |
00:39.17 | Samot | Bria doesn't have that problem. |
00:39.28 | Samot | It's well worth what I pay for it. |
01:06.15 | Helenah2 | Samot: I will if I try it and it is good. |
01:06.29 | Helenah2 | But I'm not willing to blindly pay for software. |
01:06.50 | Helenah2 | Installing Bria |
01:18.34 | *** join/#asterisk spatel (~spatel@pool-96-237-230-64.bstnma.fios.verizon.net) |
01:56.18 | Samot | Well I bundle Bria with my services. My techs use it on the road, no missed calls. |
02:05.44 | *** join/#asterisk MoonTide (~NiHola@unaffiliated/liuyan) |
02:28.42 | *** join/#asterisk ketas (~ketas@0011-0000-0000-0000-d7dc-830e-07d0-2001.dyn.estpak.ee) |
02:33.11 | *** join/#asterisk GoldenBear (~gb@131.255.4.22) |
02:37.53 | Helenah2 | Hi |
02:39.06 | Helenah2 | I'm trying to create an alarm clock, how would I keep an AGI script running to do it? I'm also using Python for AGI. |
02:40.13 | Samot | AGI lets you execute external scripts/commands from dialplan |
02:40.32 | Samot | So how would the alarm be triggered? |
02:40.38 | Helenah2 | That I know how to do... |
02:40.46 | Helenah2 | BUt I need a script to always be running |
02:40.54 | Samot | You don't keep an AGI script script running. |
02:41.00 | Helenah2 | I dial an extension, put in the time i want waking up |
02:41.01 | Samot | It's called on when the dialplan is excuted. |
02:41.09 | Samot | It's called on when the dialplan is executed. |
02:41.10 | Helenah2 | and then when that time comes, the phone is called |
02:41.20 | Samot | OK that is using callfiles. |
02:41.21 | Helenah2 | Ah |
02:41.28 | Helenah2 | That I didn't know |
02:41.32 | Samot | Or setting up an Originate command. |
02:41.41 | Helenah2 | I thought it was only called if the corresponding extension is dialed |
02:41.42 | Samot | Via AMI to execute from a remote script. |
02:41.51 | Samot | No. |
02:42.04 | Helenah2 | I haven't used AMI yet. |
02:42.04 | Samot | You can use callfiles to trigger an Originate. |
02:42.10 | Helenah2 | I shall look into it |
02:42.14 | Samot | Or you can use AMI |
02:42.17 | Samot | Or ARI |
02:42.23 | Helenah2 | Googles callfiles |
02:43.13 | Helenah2 | Interesting |
02:55.58 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
02:59.24 | *** join/#asterisk setham (~textual@unaffiliated/setham) |
03:10.32 | *** join/#asterisk GoldenBear (~gb@131.255.4.22) |
03:19.48 | *** join/#asterisk sysgrammer (~sysgramme@d205-234-48-174.yt.northwestel.net) |
03:24.15 | *** join/#asterisk moe__sysgrammer (~sysgramme@d205-234-48-174.yt.northwestel.net) |
03:29.44 | *** join/#asterisk GoldenBear (~gb@172.83.42.24) |
03:46.51 | *** join/#asterisk cp (~cp@b157153.ppp.asahi-net.or.jp) |
04:52.36 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
05:01.21 | *** join/#asterisk MoonTide (~NiHola@unaffiliated/liuyan) |
05:50.49 | *** join/#asterisk MoonTide (~NiHola@unaffiliated/liuyan) |
06:20.26 | *** join/#asterisk RudyValencia (rudy@unaffiliated/rudyvalencia) |
06:37.14 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
06:56.02 | *** join/#asterisk MoonTide (~NiHola@unaffiliated/liuyan) |
07:36.27 | *** join/#asterisk KValchev (~KValchev@ns.atsoftconsult-bg.com) |
07:47.16 | *** join/#asterisk jkroon (~jkroon@41.113.22.246) |
08:26.10 | *** join/#asterisk sekil (~sekil@178-222-22-196.dynamic.isp.telekom.rs) |
08:38.02 | *** join/#asterisk MoonTide (~NiHola@unaffiliated/liuyan) |
08:45.03 | *** join/#asterisk defsdoor (~Andrew@46.16.211.156) |
08:50.13 | *** join/#asterisk MoonTide (~NiHola@unaffiliated/liuyan) |
09:02.42 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
09:02.53 | *** join/#asterisk Da-Geek (~Da-Geek@5.154.189.38) |
09:07.24 | *** join/#asterisk MoonTide (~NiHola@unaffiliated/liuyan) |
10:14.21 | *** join/#asterisk tsal (~tsal@i59F4A46E.versanet.de) |
10:25.16 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
10:46.12 | *** join/#asterisk LunarTide (~NiHola@unaffiliated/liuyan) |
11:08.24 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
11:23.32 | *** join/#asterisk defsdoor (~Andrew@46.16.211.156) |
11:29.23 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
12:04.17 | *** join/#asterisk emsjessec (~emsjessec@pool-173-54-255-231.nwrknj.fios.verizon.net) |
12:09.34 | *** join/#asterisk orn (~orn@nova-078-040-250-100.corp.nova.is) |
12:10.36 | orn | Hello -- quick question: Does asterisk still look at mtime of call files and ignores future mtimes? Because mine seems to completely ignore mtime. |
12:14.00 | sibiria | it does |
12:17.22 | orn | strange |
12:18.02 | orn | i place three call files in the spool directory, and asterisk updates the mtime of the file it opens and sets it 10m in the future, and then processes the remaining 2 (with mtimes 20 and 30 minutes in the future) in an arbitrary order |
12:18.10 | orn | i need to investigate further |
12:19.06 | sibiria | sure you're not making the mistake of copying the files in there instead of moving them? |
12:19.56 | sibiria | (which will forfeit their mtime unless asked to be preserved with -p) |
12:24.42 | orn | yeah, i'm using python's os.rename -- and am checking the file stats before and after relocation |
12:25.43 | orn | i'd be curious to know also why the mtime alters to approx. 10 minutes in the future once asterisk starts processing the call file -- maybe it's perfectly natural and asterisk does it to stop itself re-processing it while the call is ongoing or something |
12:26.26 | sibiria | does the RetryTime of the call file happen to be 600? |
12:27.07 | orn | i don't define retrytime, and maxretries is 0 |
12:27.11 | sibiria | if yes, it does sound like the file's mtime is either incorrect or ignored, and that asterisk processes the file instantly with some odd result |
12:27.13 | orn | but interesting thought -- maybe the default value is 300 |
12:27.20 | sibiria | the default is 300, yes |
12:29.17 | sibiria | i actually don't know if this feature of pbx_spool hinges on something in the func_ or res_ family or so |
12:33.01 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
12:33.01 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
12:45.14 | *** join/#asterisk Da-Geek (~Da-Geek@5.154.189.38) |
12:56.39 | *** join/#asterisk jkroon (~jkroon@41.113.22.246) |
13:01.26 | *** join/#asterisk jkroon (~jkroon@41.113.22.246) |
13:03.30 | *** join/#asterisk jkroon (~jkroon@41.113.22.246) |
13:10.06 | *** join/#asterisk Phruis` (Phruis@gateway/vpn/privateinternetaccess/phruis) |
13:17.08 | *** join/#asterisk war9407 (war@2600:4040:4001:1e00::f7aa) |
13:17.49 | *** join/#asterisk iq (~iq@2600:100e:bf10:1089:d00a:41ae:d994:5a7b) |
13:32.36 | orn | this is weird -- sometimes asterisk listens to the mtime perfectly and sometimes it just seems to randomly call at random times -- trying to figure out a pattern here |
13:34.56 | Samot | So if you don't adjust the mtime does every call get sent immediately and properly when you move the call file into the outgoing spool? |
13:35.19 | orn | yes |
13:35.35 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
13:35.45 | Samot | And how far into the future are you setting the mtime? |
13:35.56 | orn | presently 2 and 4 mintues, but i tried increasing to 20 and 30 |
13:36.15 | Samot | And how are you doing it? |
13:36.16 | orn | and the mtime seems to have an effect even when it behaves strangely |
13:36.32 | orn | there is always a delay, but it's unpredictable |
13:37.20 | orn | i'm creating the call files in /tmp, adjusting the mtime with python's os.utime, and then using python's os.rename |
13:37.28 | orn | and i'm checking the mtime with stat |
13:37.33 | orn | and everything looks as it should |
13:38.42 | Samot | And you are changing the ownership/group to the asterisk user? |
13:38.48 | Samot | And not leaving it as root? |
13:38.48 | orn | yes |
13:39.40 | Samot | OK so create a file, adjust the mtime and show it via the ls -lt |
13:39.51 | Samot | Then move it to the outgoing spool and do the same thing. |
13:39.58 | Samot | Make sure the timestamp is the same. |
13:40.17 | orn | i've been doing that essentially -- am checking the timestamp before and after moving and it is not changing |
13:40.30 | orn | though not checking with ls, but rateher with stat |
13:40.48 | orn | *rather |
13:42.14 | sibiria | orn: are you sure python's os.rename is being a big doodie head and doing something stupid as copying file and then adjusting its stats? |
13:42.19 | sibiria | isn't being* |
13:43.18 | sibiria | maybe try mv(1) via os.system() |
13:43.43 | sibiria | or subprocess.run(), whichever tickles your fancy |
13:45.56 | orn | yeah, considered doing that just to elimate that as a possibility, but it would be some weird combo of that being broken and stat showing me the wrong thing |
13:46.11 | Samot | How about you create it |
13:46.18 | Samot | and then touch it |
13:46.29 | Samot | mod the owner/group and then mv it |
13:46.44 | Samot | How about trying this manually and making sure it does work |
13:46.45 | orn | i'm gonna paste output showing me continually moniting the stat of the call files in the spool directory, which shows (via the sudden change of the call file mtime) a premature launch |
13:46.56 | sibiria | why don't you turn asterisk off, do the whole spiel you do for the call file, "ls --full-time" the spool directory and see what you have before asterisk gets its hands over it |
13:47.11 | orn | really good ideas for debugging this, thanks guys |
13:48.20 | *** join/#asterisk jkroon (~jkroon@41.113.50.206) |
13:52.19 | orn | https://pastebin.com/cUkWxG6t |
13:52.29 | orn | here's what it looks like with minor commentary |
13:53.09 | orn | but i'll be sure to create call files manually with future mtimes and see what happens -- maybe it's something to do with the fact that i'm creating three files within a short period and the first one is supposed to execute straight away |
13:55.03 | Samot | Why does the first file have a different access and modified times? |
13:56.26 | orn | i ran stat after asterisk began processing it |
13:56.53 | orn | asterisk seems to change the mtime and ctime |
13:57.16 | orn | its mtime is just the creation time as it is supposed to run right away |
13:57.31 | Samot | And what version of Asterisk are you running? |
13:57.44 | orn | 13.1.0 |
13:57.49 | Samot | Sigh. |
13:57.53 | Samot | Update. |
13:58.10 | Samot | 13.29.1 <-- Current version. |
13:58.22 | Samot | You're on a, what, 5 year old release? |
13:58.37 | orn | this is from ubuntu's packaging system |
13:58.44 | orn | not sure when 13.1.0 came out though |
13:58.53 | orn | but yeah, valid |
13:59.15 | Samot | It came out 5 years ago |
13:59.39 | Samot | You are missing 5 years of bug fixes. |
14:04.36 | sibiria | the mtime feature works in ast 13, but there may be a tiny risk you're right on top of a temporary regression |
14:04.50 | sibiria | unless PEBCAK, of course ,) |
14:05.27 | *** join/#asterisk lbazan (~lbazan@fedora/LoKoMurdoK) |
14:06.18 | orn | haha, PEBCAK is always an option |
14:06.38 | orn | though i've done both rubber duck debugging and actual person debugging to try to limit that :) |
14:08.27 | sibiria | but, uh.. i'd just try doing this manually: create a few basic test call files (calling Playback with a soundfile, nothing more) on the terminal, set their mtime with touch(1) and mv them files into the spool |
14:08.48 | sibiria | to confirm basic funcationality before looking at how the larger application is breaking it |
14:09.03 | sibiria | +spelling |
14:09.38 | sibiria | no need to have the call files even go into the dial plan. a simple "Application: Playback" with "Data: en/monkeys" or something will suffice |
14:11.44 | orn | yeah, good point |
14:11.55 | orn | thanks a lot for your input |
14:34.19 | *** join/#asterisk engine20191 (~engine201@190.145.222.242) |
14:42.24 | *** join/#asterisk jkroon (~jkroon@41.113.50.206) |
15:00.38 | *** join/#asterisk defsdoor (~Andrew@46.16.211.156) |
15:06.56 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-vfinkiochcawneqr) |
15:06.56 | *** mode/#asterisk [+o bford] by ChanServ |
15:32.12 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-hrettgiuxkxmqnzy) |
15:32.12 | *** mode/#asterisk [+o kharwell] by ChanServ |
15:33.38 | orn | fwiw, i upgraded to asterisk 13.18.3 and am seeing the same behavior. that is still ~2 years older than the most recent version and i have yet to try simplifying the scenario as suggested |
15:33.51 | orn | but thought i'd share for posterity |
15:33.52 | orn | :) |
15:43.49 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
15:44.00 | *** join/#asterisk defsdoor (~Andrew@46.16.211.156) |
15:44.56 | Samot | orn: So you've done this manually? With no code? |
15:45.06 | *** join/#asterisk LoKoMurdoK (~lbazan@fedora/LoKoMurdoK) |
15:47.16 | orn | no, that's what i'm currently doing |
15:47.33 | orn | decided to upgrade the OS and asterisk first, which was a good idea anyway |
15:56.17 | igcewieling | The important thing with call files, is that you need to create them in another directory on the same file system, then move them to the correct location. Otherwise Asterisk might try processing the call file before it is finished being written to disk. |
16:01.58 | orn | igcewieling: that's how i'm doing it -- there seems to be something else that's affecting it, but i haven't figured out what. am testing things suggested by Samot and sibiria |
16:02.15 | orn | seeing if i can reproduce the problem that way |
16:05.59 | *** join/#asterisk engine20191 (~engine201@190.145.222.242) |
16:06.21 | *** join/#asterisk dacod (~dacod@2804:7f5:f380:da4e::1) |
16:31.26 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
16:35.12 | *** join/#asterisk LoKoMurdoK (~lbazan@fedora/LoKoMurdoK) |
17:14.02 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
17:16.28 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
17:21.28 | *** join/#asterisk miralin (~Thunderbi@host-5-138-109-170.stavropol.ru) |
17:23.24 | *** join/#asterisk miralin (~Thunderbi@host-5-138-109-170.stavropol.ru) |
17:29.38 | *** join/#asterisk dacod (~dacod@189.114.201.131.dynamic.adsl.gvt.net.br) |
17:56.54 | *** join/#asterisk jkroon (~jkroon@165.16.204.99) |
17:59.26 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
18:19.37 | Someone_Else | what variable in the asterisk dialpan gives me the 'contact' string of the extension? |
18:23.39 | jkroon | of the dialog of the sip channel? |
18:24.35 | igcewieling | Someone_Else: try "core show function CHANNEL" |
18:25.21 | igcewieling | Anything more would require us to know the channel driver you are using. |
18:29.03 | Someone_Else | igcewieling: thanks. didn't find the right thing yet. when I do pjsip show aor xxx, it lists a uri under contact: sip:blah |
18:29.22 | Someone_Else | I need a variable to pass that to a script from my dialplan |
18:29.41 | Someone_Else | so, in case you missed it, I'm using pjsip |
18:32.13 | Samot | Is this an outbound call from the endpoint? |
18:32.39 | igcewieling | "core show functions like PJSIP" |
18:32.39 | Someone_Else | Samot: yes |
18:32.54 | igcewieling | tada! |
18:33.04 | Samot | No, it's in the channel function |
18:33.15 | Samot | you need to use PJSIP_CONTACTS with it. |
18:33.57 | Samot | <PROTECTED> |
18:34.13 | Samot | Says so right in the channel function details. |
18:34.56 | Samot | However, that means Asterisk -> device |
18:35.11 | Samot | Device -> Asterisk is an incoming leg. |
18:35.57 | Samot | Because a contact doesn't need to exist for Asterisk to receive a call from an endpoint as long as the endpoint auth's how asterisk wants. |
18:36.15 | Samot | Contacts are for calls leaving Asterisk to some place. |
18:37.30 | Samot | You probably want this: remote_addr - On inbound calls, the full IP address and port number that the INVITE request was received from. On outbound calls, the full IP address and port number that the INVITE request was transmitted to. |
18:37.42 | Samot | So CHANNEL(pjsip,remote_addr) |
18:39.44 | Someone_Else | Samot: the 'client' I need to get the uri from is a softphone that includes a push token inside the uri |
18:39.57 | Someone_Else | I need that to wake up the device prior to calling |
18:40.18 | Samot | OK so this is a call FROM Asterisk to a specific contact? |
18:40.27 | Someone_Else | yes |
18:40.30 | Samot | OK. |
18:40.54 | Samot | That's the opposite of what you told me. |
18:41.17 | Samot | So then you need to use PJSIP_CONTACT to get the contacts on the AOR |
18:41.33 | Samot | You can get the UA from there. |
18:42.41 | Someone_Else | Samot: and how do I pass that to a AGI script? something like ${PJSIP_CONTACT(xxx,uri)} ? |
18:43.25 | Samot | Yes. |
18:43.46 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
18:46.57 | Someone_Else | Samot: not working, getting an empty variable |
18:47.20 | Samot | What did you actually put in there? |
18:47.44 | Someone_Else | like I said above, where xxx is the softphone number |
18:50.28 | Samot | OK, you need to use a few functions here. |
18:50.56 | Samot | The name part is the actual contact URI |
18:51.01 | Samot | aor/contact |
18:51.36 | Samot | So you need to get your contacts via PJSIP_AOR(aorname,contact) |
18:51.54 | Samot | If you have more than one static or dynamic contact, you'll need to loop them. |
18:55.10 | Someone_Else | Samot: the string returned is not the one in sip show aor xxx |
18:55.51 | Samot | String for what? |
18:56.05 | Samot | You need to relay your information in a more detailed fashion. |
18:56.22 | Samot | I have no idea what you did or what you were expecting when you did it. |
18:57.13 | Someone_Else | again, I need to have the value of 'contact' under sip show aor xxx, the full string |
18:57.16 | Someone_Else | that's all |
18:58.31 | Samot | What is the dialplan you used? |
18:58.47 | Samot | What was the output in the log to said dialplan when executed? |
18:59.04 | Samot | telling it just doesn't work or you didn't get the right result doesn't mean anything for me. |
19:28.14 | *** join/#asterisk miralin1 (~Thunderbi@host-46-45-217-207.stavropol.ru) |
19:29.39 | *** join/#asterisk miralin (~Thunderbi@host-5-138-109-170.stavropol.ru) |
20:38.43 | *** join/#asterisk LoKoMurdoK (~lbazan@fedora/LoKoMurdoK) |
21:10.35 | *** join/#asterisk GoldenBear (~gb@172.83.42.24) |
21:36.06 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |
22:04.08 | *** join/#asterisk bmg505 (~leon@169-0-149-160.ip.afrihost.co.za) |
22:26.35 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
22:46.44 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
22:56.54 | *** join/#asterisk anderj101 (~anderj101@mail.thehouseofbacon.com) |
23:00.30 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |