| 00:32.24 | coreyfarrell | seanbright: not without restructuring the test-config.yaml files. would probably be faster if test-config.yaml only contained meta-data (testinfo and dependencies) with a separate yaml file for definition based tests (test-modules and such) |
| 00:32.43 | coreyfarrell | but that would be a lot of work for 1 second |
| 01:50.10 | *** join/#asterisk-dev AsteriskRoss_ (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 05:41.01 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 06:48.47 | *** join/#asterisk-dev jkroon (~jkroon@41.113.119.193) |
| 06:58.12 | *** join/#asterisk-dev _Ross_ (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 07:14.54 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:40.25 | *** join/#asterisk-dev CELYA_ (~Thunderbi@185.14.178.189) |
| 08:03.59 | *** join/#asterisk-dev pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 08:44.56 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 11:20.33 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 12:03.55 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 12:15.01 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 12:55.29 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@185.14.178.189) |
| 13:39.14 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@185.14.178.189) |
| 13:42.32 | seanbright | agreed |
| 13:49.22 | seanbright | coreyfarrell: way out-of-scope idea for your app_record patch... |
| 13:49.42 | seanbright | if 'beep' is missing, use ast_tonepair() to generate a beep |
| 13:51.52 | coreyfarrell | rejected! |
| 13:52.26 | seanbright | ok |
| 13:53.18 | coreyfarrell | I mean if we were going to do ast_tonepair we could just stop using beep? but really I just need to unbreak my integration testing and I don't want to copy in the audio files |
| 13:54.17 | seanbright | that would be a behavior change. i was just thinking that rather than the caller hearing nothing it could fall back to _something_ |
| 13:54.27 | seanbright | but just a thought |
| 13:55.34 | file | tonepair requires a translation path |
| 13:55.39 | file | file may not |
| 13:55.48 | seanbright | good point |
| 13:58.21 | seanbright | well then... how does the caller know when to start speaking? |
| 13:58.36 | seanbright | i almost feel like hanging up with an error is the right behavior |
| 14:03.01 | coreyfarrell | a warning is logged. `exten s,1,Playback(beep)` does not hangup if the audio file doesn't exist either |
| 14:03.52 | seanbright | right, but the beep in app_record is a call to action |
| 14:04.10 | coreyfarrell | so is a Playback in an IVR |
| 14:04.37 | seanbright | agree to disagree |
| 15:11.32 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 15:18.06 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-kknokkxwucityqoj) |
| 15:18.06 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 16:05.08 | *** join/#asterisk-dev jkroon (~jkroon@197.184.243.90) |
| 16:07.20 | seanbright | so all of the testsuite patches gets us from about 11.5s down to 1.2s for a ./runtests.py -l |
| 16:07.55 | seanbright | i think that is about as good as we are going to be able to do without a lot of effort, like those outlined by coreyfarrell |
| 16:07.58 | seanbright | so i'm happy |
| 16:18.58 | rmudgett | coreyfarrell: Re: app_record patch: There are other warnings that probably should not cause a hangup either. I think people have been so ingrained to think that a non-zero return of a function signals an error when that is not always the case. |
| 16:19.46 | rmudgett | The return value for the exec functions of applications means hangup on non-zero. |
| 16:21.12 | rmudgett | In the app_record case, there are several places where a channel variable is set and the return value is non-zero. It is rather pointless to set the channel variable if the app is going to return non-zero. |
| 16:22.11 | rmudgett | In that case not much can look at the channel variable value set outside of seeing the AMI varset event. |
| 16:23.36 | coreyfarrell | hangup handlers can see it |
| 16:24.49 | rmudgett | oh. right |
| 16:25.02 | rmudgett | forgot about those |
| 16:25.48 | rmudgett | though I wouldn't expect a hangup handler to be looking for that channel variable. |
| 16:36.20 | coreyfarrell | you might if the hangup handler moves the recording from the temporary location to the place where dialplan would play the file (a dial-in announcement recorder interface) |
| 17:36.05 | kharwell | I'm working on an audio issue involving Firefox, and been trying various things to no avail so far. If someone has a chance can you look at the following SDPs and see if anything of note stands out between them (I think I've been staring at this stuff to long and wondering if I'm missing something) |
| 17:36.36 | seanbright | is there a public issue #? |
| 17:37.31 | kharwell | Here's call from Firefox using StreamEcho in Asterisk where audio in Firefox works: https://pastebin.com/BYR8KfVk, and then here is one using Confbridge (sfu) where Firefox has not audio: https://pastebin.com/ErpLH6ER |
| 17:37.44 | kharwell | seanbright: I haven't created a public issue for it yet |
| 17:40.19 | seanbright | #### channel topo change - PJSIP/guest-00000000 - indicated!!!!! |
| 17:40.19 | seanbright | is that your debug code? |
| 17:40.19 | kharwell | heh some debugging I added in |
| 17:40.19 | kharwell | yeah |
| 17:42.42 | seanbright | just doing a simple side by side (opening them in two browser tabs and switching back and forth) the only stuff changing is the stuff you expect to change (port numbers, ids, etc) |
| 17:42.44 | kharwell | oddly if I remove the video codec from "allow" on the endpoint (so no video codecs only audio) the browser then outputs audio |
| 17:43.18 | kharwell | thanks for looking. That's all I've noticed as well |
| 17:45.36 | seanbright | yeah. sorry :-( |
| 17:45.49 | kharwell | Forcing a video attribute of recvonly (a=recvonly vs sendrecv) in the initial 200 okay response from the initial offer also resulted in audio |
| 17:46.08 | file | the first would have bidirectional for both audio and video, the second wouldn't |
| 17:46.14 | seanbright | FF 72.0.1 i assume? |
| 17:46.48 | kharwell | I'm currently running 71.0 |
| 17:47.21 | seanbright | file: why is that? because of streamecho vs. confbridge? |
| 17:47.33 | file | seanbright: ConfBridge doesn't generate video, so if you're the only participant you get no video |
| 17:47.50 | file | and the initial video stream is only used for video from browser to Asterisk |
| 17:48.17 | seanbright | gotcha |
| 17:48.26 | kharwell | file: hrm yeah true. If I add another participant I still get no audio, but video for both |
| 17:48.28 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.109) |
| 17:48.44 | file | right, that adds a stream |
| 17:51.55 | kharwell | So thinking since Firefox is not receiving video it doesn't trigger the audio? |
| 17:52.09 | file | yes, it probably is waiting for video to synchronize them |
| 17:52.13 | file | or uses it for timing |
| 17:52.57 | kharwell | In this scenario I've also set the video stream to a=recvonly in the reinvite, but won't trigger the audio still. It will do trigger audio if I put a=recvonly in the initial response |
| 17:53.32 | kharwell | so maybe works only on the original negotiation |
| 17:53.36 | file | hrm, dunno then |
| 17:54.16 | kharwell | maybe we just declare FF unsupported "you're mileage may vary" :-P |
| 17:54.24 | kharwell | ugh *your |
| 17:55.30 | kharwell | "your kilometers may vary" for those outside the US :-D |
| 17:55.32 | file | ha |
| 17:57.07 | file | anything come up with Firefox WebRTC logging? |
| 17:57.53 | file | I also just sent a message to someone who follows things more closely seeing if he's seen anything |
| 17:58.37 | kharwell | I haven't looked at the FF logs in a while, but if I recall there too was nothing of note in the logs |
| 18:06.59 | kharwell | just tired 72.0.1 and still doesn't work. |
| 18:07.08 | kharwell | I wonder if I should just file an issue with FF |
| 18:07.46 | file | that may be an answer |
| 18:09.34 | file | ponders |
| 18:19.30 | file | I wonder if it's the video element itself |
| 18:25.53 | kharwell | I think I'll file a bug report with FF, and then yeah maybe look into the video element and see if there is something I can do to narrow it down to that |
| 18:30.50 | file | kharwell: I have a response |
| 18:30.53 | file | kharwell: "oh wait... this sounds familiar. does audio work if you attach it to a <audio> element?" |
| 18:32.20 | file | to which the answer is yes |
| 18:35.15 | file | kharwell: this is silly |
| 18:38.06 | kharwell | I wonder we are not using just a plain <audio> element though from what I can tell? Using something called a mediabox (may just be a wrapper) |
| 18:38.16 | file | that's a wrapper |
| 19:16.58 | kharwell | an update for those interested! After a suggestion by Josh to force the audio element in the client audio in FF has seemingly been restored |
| 19:17.26 | file | video element no longer plays out audio without video |
| 19:17.37 | seanbright | interesting. FF only? |
| 19:17.49 | file | having also an audio element play kicks the video one into going |
| 19:17.50 | file | yes |
| 19:17.58 | kharwell | seanbright: yes. Seems okay in Chrome |
| 19:18.07 | seanbright | sad |
| 19:18.25 | seanbright | do you think it's a bug or intentional |
| 19:18.53 | file | that's a question |
| 19:18.55 | kharwell | good question not sure |
| 19:19.46 | file | I can understand why it could be intentional |
| 19:20.10 | file | if you want data from all streams before playing, for example |
| 19:20.26 | kharwell | I lean toward a bug though. I mean it does work if in the intial sdp response the video is set to recvonly it outputs audio |
| 19:20.45 | file | kharwell: I think because you're telling it not to expect video |
| 19:20.50 | kharwell | aah yeah but that still aligns with what you just said file |
| 19:21.35 | kharwell | could be a bug then that it doesn't start audio on the reinvite though |
| 19:21.45 | file | yeah |
| 19:24.56 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 19:26.46 | seanbright | ohh, firefox is converting their SDP parser to rust |
| 19:26.52 | seanbright | me likey |
| 20:58.54 | seanbright | gtjoseph: the docs will get generated overnight tonight? |
| 20:59.06 | gtjoseph | if those reviews merged, then yes |
| 20:59.09 | seanbright | they did |
| 20:59.11 | seanbright | very nice |
| 20:59.31 | gtjoseph | i actually did it manually the other day so they should be there in the 16 branch at least |
| 20:59.54 | seanbright | sure enough |
| 21:01.03 | seanbright | i feel bad for this guy: https://issues.asterisk.org/jira/browse/ASTERISK-28674 |
| 21:01.43 | gtjoseph | yeah that's a tough area. |
| 21:01.44 | rmudgett | He seems to have found a solution |
| 21:01.53 | seanbright | yes, but he's screaming into the void |
| 21:02.06 | seanbright | but he's passionate, i'll say that |
| 21:03.18 | seanbright | "I would greatly appreciate it if you could submit the first fix for inclusion in the next version of libss7" |
| 21:03.23 | seanbright | yeahhhhhh, about that... |
| 21:03.25 | seanbright | heh |
| 21:10.28 | rmudgett | It could be included but when the next release happens.... |
| 21:11.48 | kharwell | yeah trying to figure out if that would ever happen. I'd feel back recommending him jump through the hoops of contrib license, gerrit, etc.., he does it, and then we never release |
| 21:13.38 | rmudgett | Thing is, I don't remember the status of the various branches. master, v2.0, and v1.0 |
| 21:13.49 | rmudgett | Definitely shouldn't go in v1.0 branch. |
| 21:13.51 | file | that's probably a cresl1n question |
| 21:14.14 | rmudgett | Don't think master is a live branch. |
| 21:23.16 | seanbright | as a north american - what would i need to set up an SS7 link? |
| 21:23.22 | seanbright | can i just call verizon and ask for one? |
| 21:24.21 | seanbright | i know very little about voice-not-over-ip |
| 21:28.52 | file | ditto |
| 21:58.00 | seanbright | anyone wanna drop users.conf support in master? |
| 22:01.46 | file | do I like pain... |
| 22:02.42 | seanbright | your objection has been recorded |
| 22:02.57 | seanbright | we have to break _something_ in master |
| 22:16.48 | rmudgett | users.conf has been getting less and less supported. When we create a new module we won't add support for users.conf. :D |
| 22:17.27 | rmudgett | When we rewrite a module like chan_iax2.c or app_voicemail we'll remove users.conf. :P |
| 22:20.28 | rmudgett | Course just removing users.conf from those modules would be an improvement. :) |
| 22:31.16 | seanbright | heh. indeed. |
| 22:50.17 | coreyfarrell | can we do something about main/manager.c loading users.conf? get rid of or deprecate hasmanager=yes...? |
| 22:59.31 | rmudgett | just need a patch to do it. :D |
| 23:06.43 | coreyfarrell | patch to do what (deprecate or remove the option)? |
| 23:07.04 | rmudgett | either |
| 23:07.53 | rmudgett | I'm not fussy as users.conf was a "good" idea that wasn't worth much. |
| 23:09.33 | file | people still use users.conf, removing it without any notice is a no-go |
| 23:13.08 | coreyfarrell | file: but do people use `hasmanager=yes`? what I'm talking about is removing that one option |
| 23:13.24 | file | no insight into that level |
| 23:13.30 | file | I'd hope not, but never know |
| 23:13.58 | rmudgett | Suppose we should try to wean people off of users.conf. |