| 00:00.04 | FuriousGeorge | "al to the main office please" |
| 00:00.08 | Samot | Yeah, I got that earlier. |
| 00:00.15 | Samot | What wasn't part of it was the "live PA" |
| 00:00.20 | Samot | It was just "recording" |
| 00:00.26 | drmessano | As I said |
| 00:00.39 | drmessano | You're gonn have to count 1 mississippi, 2 mississippi, and so on, then start talking |
| 00:00.47 | Samot | FuriousGeorge: You can record the message before playback |
| 00:00.48 | drmessano | The timing is going to be shit if you use a conference |
| 00:00.57 | drmessano | So just record it and use playback in the call files |
| 00:01.01 | FuriousGeorge | if it's not gonna work right ill not do it |
| 00:01.11 | drmessano | I just fucking told you how to do it |
| 00:01.12 | drmessano | lol |
| 00:01.17 | drmessano | Two of us did |
| 00:01.28 | drmessano | Conference = Bad idea |
| 00:01.30 | Samot | You can dial your feature code, record your message, hit # and trigger it to call everyone and playback your message. |
| 00:01.39 | drmessano | Call files + recording + playback() = good idea |
| 00:01.54 | FuriousGeorge | drmessano: deep breaths. it seems multiple people are telling me to forget that. i was just agreeing. am i missing something? |
| 00:02.02 | drmessano | No one told you to forget that |
| 00:02.11 | drmessano | All 3 of us are saying the same thing |
| 00:02.17 | FuriousGeorge | (6:58:08 PM) drmessano: The timing is going to be shit if you use a conference |
| 00:02.27 | drmessano | Yes, DO NOT USE A CONFERENCE.. BAD IDEA |
| 00:02.31 | drmessano | Call files + recording + playback() = good idea |
| 00:02.33 | FuriousGeorge | like i said |
| 00:02.38 | FuriousGeorge | if it's not gonna work right.... |
| 00:02.43 | FuriousGeorge | ill just do playback |
| 00:02.45 | drmessano | Yes, dont do THAT ONE |
| 00:02.48 | drmessano | Do the OTHER ONE |
| 00:02.52 | FuriousGeorge | copy |
| 00:03.05 | Samot | FuriousGeorge: Multicast paging would shit the bed at 200+ endpoints. |
| 00:03.25 | Samot | If they are over the Internet, it could be worse. |
| 00:03.30 | FuriousGeorge | what's a safe amount of extensions to do THAT ONE with, on moderns server hardware (more or less)? |
| 00:03.43 | drmessano | Its not gonna work because of TIMING |
| 00:03.44 | FuriousGeorge | maybe they wanna do a floor at a time in real time for some reason, just thinking ahead |
| 00:03.45 | FuriousGeorge | all over lan |
| 00:03.49 | drmessano | You will HAVE TO WAIT |
| 00:03.50 | FuriousGeorge | gotcha, not gonna work |
| 00:04.06 | drmessano | Literally PAUSE and HOPE EVERYONE IS IN THE CONFERENCE WHEN YOU START TALKING |
| 00:04.13 | drmessano | I keep repeating that, and its not sinking in |
| 00:04.22 | FuriousGeorge | having to wait and not working are not the same thing. |
| 00:04.34 | Samot | In this case they are. |
| 00:04.38 | drmessano | So you're gonna dial, wait 10 seconds, and then start talking? |
| 00:04.46 | Samot | Because you could have people answering after the conf bridge is _closed_ |
| 00:04.46 | drmessano | or 15 |
| 00:04.55 | drmessano | Yep, that too |
| 00:05.07 | drmessano | This will ASYNCRONOUS |
| 00:05.11 | drmessano | This will be ASYNCRONOUS |
| 00:05.28 | Samot | FuriousGeorge: What is the plan for No Answers or Busy's? |
| 00:05.32 | drmessano | 10, 20, 100, or 200 extensions will NOT join the conference at the SAME MOMENT |
| 00:05.35 | Samot | What should happen in those cases? |
| 00:05.40 | drmessano | So you have to GUESS how long to wait |
| 00:06.14 | drmessano | These are all FXS, so they may AUTO ANSWER, but it will be far from instant |
| 00:06.15 | Samot | And are these phones or paging devices that are hooked up to the FXS gateways? |
| 00:07.28 | Samot | Take away the whole conference bridge or callfiles... |
| 00:07.56 | drmessano | The time it takes to record the message and generate the call files will be LESS than the dead silence while you wait for all the extensions to hit the conference |
| 00:08.02 | Samot | If everyone should hear the page _no matter what state of the phone or where they physically are_, then doing via the phones is a bad idea. |
| 00:08.05 | Samot | No matter the method. |
| 00:08.06 | Samot | Period. |
| 00:08.45 | Samot | Get some PA devices that can actually broadcast the message so anyone can hear no matter what. |
| 00:08.58 | Samot | Because if I'm in the pisser, I'm missing that important page. |
| 00:09.10 | sibiria | FuriousGeorge: the thing is, if you want to do this LIVE you will have to wait for every single person to pick up, or just go ahead without the people delaying. it's better to robo call this sort of task. everyone picks up in their own pace, everyone gets the message at once, you don't have to sit around and wait. |
| 00:09.13 | Samot | My phone will answer but I'm no where near it. The one downside of auto answer. |
| 00:09.28 | Samot | Guys, stop with the conference bridge stuff. |
| 00:09.38 | Samot | Until we know how the page should be received overall.... |
| 00:09.43 | Samot | It moot. |
| 00:10.06 | Samot | Like I said, if it is 100% important people hear the page _live_ no matter what...using phones is a bad idea. |
| 00:10.14 | drmessano | Samot: Dude, HE is the one stuck on the idea.. sibiria and I are BOTH trying to convince him WHY it wont work |
| 00:10.19 | Samot | I know. |
| 00:10.20 | drmessano | I think YOU need to chill out |
| 00:10.23 | drmessano | Youre not reading |
| 00:10.39 | drmessano | Calm down |
| 00:10.40 | Samot | And I'm telling you all, it doesn't matter the method of delivery if the phones are the wrong choice as the PA endpoints. |
| 00:10.57 | drmessano | The phones are the static |
| 00:10.57 | sibiria | maybe they have pigeons at that office |
| 00:11.04 | sibiria | but i would count on the phones first |
| 00:11.06 | drmessano | He said it's auto-answer FXS |
| 00:11.14 | drmessano | Doesnt matter whats connected to it |
| 00:11.28 | drmessano | The POTS device is moot.. |
| 00:11.41 | Samot | Is it? |
| 00:11.46 | drmessano | Indeed |
| 00:12.00 | Samot | If I want a page to reach a 100' square foot area.. |
| 00:12.05 | drmessano | 16:15:33 <FuriousGeorge> i have a several grandstream fxs gateway. the analog phones on the other side of it always auto-answer. i want to call them all at the same time, and play a prerecorded or live message. i'm trying to figure out the best way to do this. |
| 00:12.09 | Samot | I'm not using a phone, I'm using a speaker. |
| 00:12.12 | drmessano | It was all the in the first message |
| 00:12.17 | drmessano | SO why are we arguing over this? |
| 00:12.24 | drmessano | He already stated the target |
| 00:12.31 | Samot | So yeah, if the pages are personal phones are great. |
| 00:12.39 | Samot | If it's a floor wide page, phones are bad. |
| 00:12.41 | Samot | 7:08:58 PM <Samot> Because if I'm in the pisser, I'm missing that important page. |
| 00:13.00 | drmessano | That goes with ANY form of paging |
| 00:13.03 | Samot | Right |
| 00:13.08 | drmessano | Ok, so? |
| 00:13.27 | drmessano | The phones auto answer, so that's the intention |
| 00:13.32 | Samot | OK. |
| 00:13.37 | drmessano | He's not asking for a store and retrieve system |
| 00:13.41 | Samot | OK |
| 00:15.13 | drmessano | Recording, generating call files, and then blasting extensions with the recording is going to handle your ASYNC issues, which I would fully expect |
| 00:15.43 | Samot | Yup. |
| 00:18.29 | sibiria | and put a few retries with a minute or two in there as well |
| 00:18.32 | sibiria | for people in the pisser :P |
| 00:19.01 | drmessano | Yeah but if he has auto-answer, as he says, there's no way to test for that |
| 00:19.15 | drmessano | So basically just chuck it out there and hope for the best |
| 00:19.17 | drmessano | or.... |
| 00:19.40 | drmessano | Create a "What was that?" extension that plays the last recording |
| 00:19.58 | drmessano | So if they hear the page, but can't make it out, they go to a phone and call in |
| 00:20.03 | *** join/#asterisk pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 00:20.49 | FuriousGeorge | yeah, that's what i'm gonna do |
| 00:21.40 | FuriousGeorge | i was more curious as to the tolerance of asterisk for this sort of thing in real time, and i gather that it is not a high level of tolerance |
| 00:21.50 | drmessano | Asterisk isn't the problem |
| 00:22.12 | drmessano | It's all your devices that won't truly answer at the same time, or join the conference the same instant |
| 00:22.24 | drmessano | Sigh |
| 00:22.30 | FuriousGeorge | i'll let them confirm that they like the sound of it, before they send, then write a no frills script to drop the call files |
| 00:22.59 | drmessano | Asking them to confirm the message is going to add more delay |
| 00:23.21 | drmessano | Don't make it an option |
| 00:23.21 | FuriousGeorge | drmessano: if that's the case, then (only hypothetically speaking) couldn't the speaking party simply be joined last |
| 00:23.30 | drmessano | Dude |
| 00:23.33 | drmessano | ..... |
| 00:23.42 | drmessano | How long do you think you should wait? |
| 00:23.47 | drmessano | 5 seconds? |
| 00:23.51 | drmessano | 10 seconds? |
| 00:23.53 | drmessano | 8 seconds? |
| 00:24.03 | drmessano | What if there's bigger delay this time than last |
| 00:24.07 | drmessano | What do you tell the users? |
| 00:24.10 | drmessano | Wait 15 just in case? |
| 00:24.21 | drmessano | Tell them to literally count to 15? |
| 00:24.25 | drmessano | Why is this not sinking in? |
| 00:25.04 | Samot | FuriousGeorge: Have you actually looked at the Page app? |
| 00:25.05 | Samot | https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Application_Page |
| 00:25.20 | Samot | Places outbound calls to the given technology/resource and dumps them into a conference bridge as muted participants. The original caller is dumped into the conference as a speaker and the room is destroyed when the original caller leaves. |
| 00:25.29 | FuriousGeorge | im asking a hypothetical question. i didn't mention that the speaking party has a visual reference for if the call is answered on the other side. in addition, the receiving party does not need to know there is a 15 second delay |
| 00:26.10 | drmessano | "Steve please call the office" takes 2 seconds, then it's blasted out |
| 00:26.17 | Samot | ^^^ |
| 00:26.36 | FuriousGeorge | Samot: yes, i've looked at it. i initially thought i would be using that with some sort of chan_local loop, but the call files solution seems more elegant. i suppose i could use page instead of dial in the call file, if that's what you're getting at |
| 00:26.41 | drmessano | This isn't about the receiving party |
| 00:26.52 | drmessano | Recording a page takes A FEW SECONDS, then it's BLASTED OUT.. No telling the use "wait a sec before you start talking" |
| 00:26.56 | FuriousGeorge | drmessano: i agree. that's the way to go. i was only asking hypothetically |
| 00:27.13 | drmessano | EVERY. SINGLE. TIME. You send a page and use a conference, the user will have to STOP THEMSELVES and WAIT X seconds |
| 00:27.30 | drmessano | Because you DONT KNOW what the delay is going to be for all the devices to answer and join |
| 00:27.38 | drmessano | It will not be SYNCRONOUS |
| 00:28.23 | drmessano | The blasting of the message won't be either, but it doesn't matter, since they're all gonna start playback after answer |
| 00:28.25 | Samot | What about if they are IN_USE or BUSY? |
| 00:28.40 | drmessano | Like any page, it would be lost |
| 00:28.40 | FuriousGeorge | all of that i understood earlier. as i mentioned, it was just a hypothetical. i was thinking along the lines of 2 way communication with a subset of the devices when i raised the hypothetical, in any case |
| 00:28.44 | drmessano | Nothing to do there |
| 00:28.49 | FuriousGeorge | they cannot be in use |
| 00:28.58 | Samot | Well, in his case..probably. |
| 00:29.04 | Samot | Proper IP phones, no so much. |
| 00:29.17 | drmessano | Not really.. I don't use whisper |
| 00:29.25 | drmessano | So people miss pages on the phone |
| 00:29.26 | drmessano | Same as here |
| 00:30.21 | FuriousGeorge | page, i assume, would cause multiple phones to answer and be in a two way communication, similar to (iirc) using dial with multiple extensions and answer-after=0 in the header |
| 00:30.44 | Samot | It doesnt have to be duplex |
| 00:30.58 | Samot | As the description I pasted said, they are _muted_ |
| 00:31.06 | Samot | They can't _send audio_ |
| 00:31.15 | sibiria | and even if not, it doesn't matter. it's a robo call, and you don't need to monitor the incoming stream, |
| 00:32.51 | Samot | Well based on everything so far: |
| 00:33.41 | Samot | 7:02:31 PM <drmessano> Call files + recording + playback() = good idea <-- That has been the consensus and it's probably the best choice based on what has been relayed.... |
| 00:35.54 | FuriousGeorge | Samot: that's right, -d would be for duplex |
| 00:36.24 | FuriousGeorge | Samot: but the more interesting question is ( drmessano , i am not going to do THIS THING ) would it work for the number of extensions im talking about |
| 00:36.31 | drmessano | NO |
| 00:36.51 | FuriousGeorge | just checking ;) |
| 00:37.02 | Samot | Yeah probably not at all. |
| 00:37.12 | drmessano | How many times do I need to say the same thing over and over |
| 00:37.13 | FuriousGeorge | waxing hypothetically on freenode |
| 00:37.30 | FuriousGeorge | drmessano: since you asked, what about for like 20 extensions? |
| 00:37.37 | Samot | 7:03:05 PM <Samot> FuriousGeorge: Multicast paging would shit the bed at 200+ endpoints. |
| 00:37.43 | drmessano | 19:27:14 <drmessano> EVERY. SINGLE. TIME. You send a page and use a conference, the user will have to STOP THEMSELVES and WAIT X seconds |
| 00:37.43 | drmessano | 19:27:31 <drmessano> Because you DONT KNOW what the delay is going to be for all the devices to answer and join |
| 00:37.43 | drmessano | 19:27:38 <drmessano> It will not be SYNCRONOUS |
| 00:38.00 | drmessano | Dude, ASTERISK IS NOT THE PROBLEM |
| 00:38.16 | drmessano | 20 devices will have the SAME PROBLEM |
| 00:38.18 | FuriousGeorge | right, but the variability would surely shrink with less users |
| 00:38.29 | FuriousGeorge | what about two users? can u conference with two other parties? |
| 00:38.34 | FuriousGeorge | what's the cutoff? |
| 00:38.54 | drmessano | They ð will ð not ð join ð at ð the ð same ð time |
| 00:39.00 | Samot | ^^^^ |
| 00:39.13 | Samot | Or perhaps at all |
| 00:39.15 | drmessano | These are NOT SIP PHONES |
| 00:39.22 | FuriousGeorge | they are sip phones |
| 00:39.22 | Samot | ^^^^^^^^^^ |
| 00:39.25 | Samot | What?! |
| 00:39.27 | drmessano | They are FXS devices WITH DELAY |
| 00:39.32 | drmessano | THEY ARE NOT |
| 00:39.33 | Samot | FXS gateways are not SIP phones. |
| 00:39.34 | FuriousGeorge | they connect via sip |
| 00:39.43 | drmessano | God damn |
| 00:39.44 | Samot | They take the SIP and convert it to FXS and vice versa. |
| 00:39.49 | FuriousGeorge | yes |
| 00:39.50 | drmessano | FuriousGeorge: |
| 00:39.57 | FuriousGeorge | drmessano: |
| 00:39.57 | Samot | That's not a SIP phone. |
| 00:40.09 | drmessano | Your devices are NOT SIP PHONES.. they have a DELAY |
| 00:40.17 | drmessano | ANALOG DELAY |
| 00:40.19 | Samot | They are analog devices |
| 00:40.44 | drmessano | THAT ð has ð been ð the ð issue ð the ð whole ð time |
| 00:40.49 | drmessano | Not asterisk |
| 00:40.51 | drmessano | Not SIP |
| 00:40.57 | drmessano | YOUR CHOICE OF DEVICES |
| 00:41.07 | FuriousGeorge | two wire |
| 00:41.09 | drmessano | They will not just all spring into syncronous auto answer |
| 00:41.15 | drmessano | Even with "auto answer" on the phones |
| 00:41.46 | drmessano | They ð are ð not ð going ð to ð answer ð the ð same ð instant ð like ð actual ð sip ð phones |
| 00:41.51 | Samot | The Grandstream is what is Auto-Answering the SIP |
| 00:41.56 | Samot | Not the actual phones |
| 00:42.10 | Samot | Then the Grandstream has to tell the FXS side what to do. |
| 00:42.23 | drmessano | So words will get CUT OFF |
| 00:42.32 | drmessano | I have DONE THIS |
| 00:43.37 | *** join/#asterisk nix8n82 (~AndChat62@2600:100e:b04e:2693:2103:1e6c:a8e8:5e9c) |
| 00:43.43 | drmessano | Put 10 of them side by side.. put 10 phones on them.. you're gonna hear BEEP..BEEP..BEEP..BEEP....... BEEP.... BEEP..BEEP..BEEP....BEEP |
| 00:44.12 | drmessano | So you have to sit there, as the sender.. and COUNT... wait for all the phones to be ready |
| 00:44.12 | FuriousGeorge | all my questions are just to get a feel for how variable the answer time would be in this _hypothetical_ situation. having seen these devices answer a call, any variability in the time between dialing and them answering is imperceivable. granted, in this _hypothetical_ asterisk would likely be trying to establish the channels one at a time, or the gateway may have more trouble doing 48 or 16 channels at a time |
| 00:44.31 | drmessano | Asterisk is not the problem |
| 00:45.19 | Samot | Are these basically "Dan pick up line 1"? |
| 00:45.23 | drmessano | How is the delay NOT PERCEIVABLE? |
| 00:45.30 | drmessano | It will EXIST |
| 00:45.31 | FuriousGeorge | while i continue to agree that a recorded message is the best solution, ill try to page 20 of these things on Monday and I'll let you know how long I had to WAIT ;) |
| 00:45.40 | drmessano | and page or conference DOESNT WAIT |
| 00:45.45 | FuriousGeorge | variability in the delay |
| 00:45.53 | FuriousGeorge | the same delay exists when you call one channel from the concierge |
| 00:46.00 | drmessano | PAGE OR CONFERENCE DOESNT WAIT |
| 00:46.06 | drmessano | Dude... |
| 00:46.08 | sibiria | FuriousGeorge: when robo-calling this task, does it really matter how long it takes? your pre-recorded audio file won't play until the phone is picked up anyway. |
| 00:46.12 | FuriousGeorge | the devices auto answer anyway |
| 00:46.17 | drmessano | This has been a massive waste of my time |
| 00:46.19 | FuriousGeorge | sibiria: it doesn't matter. |
| 00:46.35 | drmessano | Go do it with conference |
| 00:46.35 | sibiria | then why even be concerned about the time? |
| 00:46.41 | FuriousGeorge | i'm just curious, and drmessano is so charming such that i can't stop talking to him |
| 00:46.52 | sibiria | it's a one-shot action. fire and forget |
| 00:46.55 | drmessano | Now you're gonna insult me? |
| 00:46.57 | drmessano | Ok |
| 00:47.01 | Samot | 7:45:20 PM <Samot> Are these basically "Dan pick up line 1"? |
| 00:47.46 | drmessano | I literally sat here and gave you a detailed explanation of why this won't work, like 10 times. So insult away.. I've got cleaning to do. |
| 00:48.26 | FuriousGeorge | Samot: sibiria: i'm just intrigued by the notion that the time it takes to establish n channels grows by an undefined amount with n |
| 00:48.39 | drmessano | It dsoesnt |
| 00:48.43 | FuriousGeorge | to be clear, it is because of the grandstream phones |
| 00:48.43 | drmessano | Nobody said it did |
| 00:48.57 | drmessano | They ð are ð not ð going ð to ð answer ð the ð same ð instant ð like ð actual ð sip ð phones |
| 00:49.04 | drmessano | ^^^^ It's the damn devices |
| 00:49.07 | drmessano | Not Asterisk |
| 00:49.31 | FuriousGeorge | drmessano: are you saying that the consequence of them not answering at the same time is that only one will have the channel? |
| 00:49.39 | Samot | So wait, this isn't a real problem that needs a real solution...you're just being "curious"? |
| 00:49.45 | drmessano | ROFL |
| 00:49.58 | FuriousGeorge | Samot: the real solution is what you guys said |
| 00:50.12 | Samot | Well, based on what you have said. |
| 00:50.14 | drmessano | FuriousGeorge: You understand that ANY device that doesnt yet answer doesnt hear the page, right? |
| 00:50.18 | drmessano | Because its realtime |
| 00:50.26 | Samot | And I've asked some very pointed questions that you have ignored and not answered.. |
| 00:50.34 | drmessano | Tell me you understand that |
| 00:50.38 | Samot | So yes, based on what you have provided so far...it's the right option. |
| 00:50.43 | drmessano | They ð are ð not ð going ð to ð answer ð the ð same ð instant ð like ð actual ð sip ð phones |
| 00:50.53 | drmessano | ^ Your devices will all have random delays |
| 00:51.00 | drmessano | FuriousGeorge: You understand that ANY device that doesnt yet answer doesnt hear the page, right? |
| 00:51.03 | drmessano | ^^^ |
| 00:51.17 | FuriousGeorge | yeah, so, like you said, the pager would have to wait |
| 00:51.23 | Samot | But since there are different scenarios and needs for paging/announcements like this...it's hard to say what your real solution should be. |
| 00:51.32 | Samot | And the fact that you have analog devices... |
| 00:51.38 | FuriousGeorge | they may look at the expansion pads on the phone, to see when all the BLF are lit up, for instance |
| 00:51.40 | drmessano | Yes, and you have no idea how long you're going to have to wait for any given page |
| 00:51.48 | drmessano | NO |
| 00:51.51 | drmessano | THATS THE SIP SIDE |
| 00:51.56 | Samot | How do analog phones have BLF? |
| 00:52.00 | Samot | On Asterisk?! |
| 00:52.07 | drmessano | BLF on the ATA is USELESS |
| 00:52.22 | FuriousGeorge | Samot: i like drmessano's idea of just blasting it through with no confirmation... just * for send or # for do over, or some such |
| 00:52.23 | drmessano | An ATA IS A B2BUA |
| 00:52.44 | FuriousGeorge | Samot: the calling party is a sip phone. it is calling an fxs gateway with 24 fxs |
| 00:52.53 | FuriousGeorge | i mapped the fxs prots to blf on the expansion panels |
| 00:53.07 | drmessano | All 24 of those SIP extensions will likely auto answer withing milliseconds of each other |
| 00:53.21 | drmessano | ON THE SIP SIDE |
| 00:53.38 | drmessano | Then you have to wait for all 24 of those ANALOG CALLS to AUTO ANSWER on the devices |
| 00:53.44 | drmessano | Which IS NOT INSTANT |
| 00:53.49 | drmessano | It's literally NOT |
| 00:53.52 | FuriousGeorge | ok, so blf is no good. so not only do you not know, there is no way of knowing |
| 00:54.06 | FuriousGeorge | drmessano: it's pretty close when you call them one at a time |
| 00:54.11 | drmessano | Sigh |
| 00:54.22 | drmessano | YOU PERCEIVE it as INSTANT |
| 00:54.43 | drmessano | N+1 will show you how much it's NOT |
| 00:56.36 | FuriousGeorge | so the bottle neck will be the channel bank bringing up the voltage for the ports, i presume. n+1 will result in substantially more delay. the more you know |
| 00:56.47 | Samot | Yes... |
| 00:56.59 | Samot | There is a conversion happening |
| 00:56.59 | drmessano | N+1 isn't the issue.. |
| 00:57.16 | drmessano | N+23 isn't worse than 1 or N+1 |
| 00:57.26 | drmessano | All ports will be different, period |
| 00:57.31 | drmessano | All devices will be different |
| 00:57.59 | Samot | Lets try this... |
| 00:58.00 | FuriousGeorge | drmessano: im really glad we had this talk |
| 00:58.30 | Samot | My Polycom VVX501 will autoanswer the same time as your Grandstream.... |
| 00:58.42 | FuriousGeorge | Samot: i'll try it with 20 on monday while i implement the other thing. ill wire them right into the front rj11s on the bank before we install them |
| 00:58.45 | drmessano | I can literally send a SIP/101&SIP/102 call to a channel bank as 2 lines of the same analog device, and they WILL NOT see the call at the same instant |
| 00:58.52 | drmessano | I literally do this every day |
| 00:59.02 | sibiria | FuriousGeorge: hm no, the time won't grow just because you have several phones unless you tell asterisk to only place a number of simultaneous calls much lower than the number of phones you have |
| 00:59.02 | Samot | But your GS still gas to talk to the analog devce and convert it |
| 00:59.40 | drmessano | I can literally send a SIP/101&SIP/102 call to a channel bank as 2 lines of the same analog device, and they WILL NOT see the call at the same instant <-- that's 2 calls to the same device |
| 00:59.55 | drmessano | It's never "at the same instant" with analog hardware, ever |
| 01:00.10 | sibiria | FuriousGeorge: you're probably underestimating asterisk's capacity of simultaneity |
| 01:00.42 | FuriousGeorge | so the gateway and asterisk do their sip handshake, the gateway then brings up the fxs port, the two channels are bridged. i'm understanding that as n increases, the middle step will become increasingly variable |
| 01:00.50 | FuriousGeorge | where n is the number of endpoints |
| 01:00.57 | drmessano | But hell, to be completely fair, with 40 SIP phones, I still hear devices staggered across the building.. So we all wait 2 seconds anyway |
| 01:01.02 | drmessano | Analog will just be that much worse |
| 01:01.17 | drmessano | FuriousGeorge: Your statement is wrong |
| 01:01.18 | Samot | Also Dial(dev1&dev2&dev3) regardless of tech means the first to answer wins...all other channels dropped |
| 01:01.34 | drmessano | <PROTECTED> |
| 01:01.46 | drmessano | You asked this 5 mins ago, and I told you this was wrong |
| 01:01.49 | FuriousGeorge | drmessano: perhaps im still a bit hazy in where this variability increases with n |
| 01:01.58 | drmessano | IT DOESNT INCREASE |
| 01:02.07 | drmessano | It's never "at the same instant" with analog hardware, ever |
| 01:02.52 | sibiria | asterisk itself has no problems initializing 50 calls at the same time. it won't be noticably slower than starting 5 calls at the same time. |
| 01:03.08 | FuriousGeorge | drmessano: i haven been testing these things with an ami script ive been writing that generates calls. i know the sound of the concierge calling the unit and the channel going up (as evidence by white noise) like the sound of my wife saying my name at this point |
| 01:03.09 | drmessano | Between the channel answering, being passed to the FXS channel, the phone getting the ring, it taking X milliseconds to answer.. none of them will answer at the same time |
| 01:03.11 | drmessano | None of them |
| 01:03.14 | sibiria | as far as asterisk is concerned, your worry about delays is unfounded |
| 01:03.15 | FuriousGeorge | when n < 3 there is like no variability |
| 01:03.20 | FuriousGeorge | this is on a lan, it just works |
| 01:03.22 | drmessano | As I said |
| 01:03.27 | drmessano | And will repeat ONE more time |
| 01:03.32 | drmessano | But hell, to be completely fair, with 40 SIP phones, I still hear devices staggered across the building.. So we all wait 2 seconds anyway |
| 01:03.39 | drmessano | Analog will just be that much worse |
| 01:04.00 | drmessano | Asterisk is not the problem |
| 01:04.12 | drmessano | It's device delay.. and Analog endpoints will exaggerate that |
| 01:05.13 | FuriousGeorge | perhaps i'm so focused on debugging the script im just not noticing this intrinsic variability. so, in summation, it's NOT the gateway bringing up the FXS port. it's just intrinsic variability that i have been assuming wasn't there, cuz i didn't notice it |
| 01:05.28 | FuriousGeorge | https://media3.giphy.com/media/3og0IMJcSI8p6hYQXS/giphy.gif |
| 01:07.33 | FuriousGeorge | why didn't you just say so? |
| 01:07.35 | FuriousGeorge | :P |
| 01:07.49 | drmessano | so, in summation, it's NOT the gateway bringing up the FXS port. <--- Wrong again |
| 01:08.01 | drmessano | It's all of the above |
| 01:08.22 | FuriousGeorge | copy |
| 01:08.33 | drmessano | Time to answer, time to bridge, time to bring up the port, time for the phone to answer, time for the phone to pass audio |
| 01:08.42 | drmessano | It's ALL going to vary from phone to phone, call to call |
| 01:08.50 | drmessano | But hell, to be completely fair, with 40 SIP phones, I still hear devices staggered across the building.. So we all wait 2 seconds anyway |
| 01:08.57 | drmessano | It's device delay.. and Analog endpoints will exaggerate that |
| 01:09.01 | drmessano | ALL of it |
| 01:09.14 | drmessano | None of that is Asterisk's fault |
| 01:09.28 | drmessano | and it doesn't scale up or down.. it's device to device, period |
| 01:14.21 | *** join/#asterisk Oatmeal (~Suzeanne@c-73-169-85-214.hsd1.co.comcast.net) |
| 03:12.23 | *** join/#asterisk infobot (ibot@208.53.50.136) |
| 03:12.23 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.23.1 (2018/09/20) 16.0.1 (2018/11/14), Security Only: 15.6.2 (2018/11/14); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
| 03:37.54 | life_of_e | Hmm, this long thread reminded me of a question, what's the length limit on concatenated channel strings? So SIP/100&SIP/101&SIP/102... |
| 03:52.55 | drmessano | life_of_e: basically as long as Samots johnson, so however many characters fit into 2 1/2 inches. |
| 03:53.02 | life_of_e | :) |
| 03:53.37 | life_of_e | I'm so glad I was not drinking at that moment. Thank you for the laugh. |
| 03:57.07 | *** join/#asterisk kunwon1 (~kunwon1@unaffiliated/kunwon1) |
| 04:07.28 | *** join/#asterisk kunwon1 (~kunwon1@unaffiliated/kunwon1) |
| 04:09.41 | *** join/#asterisk elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 04:44.38 | *** join/#asterisk FuriousGeorge (~Brian@pool-74-102-33-231.nwrknj.fios.verizon.net) |
| 05:38.39 | *** join/#asterisk rpifan (~rpifan@178.24.241.100) |
| 05:48.45 | drmessano | life_of_e: I doubt you would have laughed harder than Samot's wife |
| 05:48.52 | drmessano | Damn, that's 2 zingers |
| 05:49.19 | drmessano | He's on vacation, so I should go easy on him |
| 05:51.40 | Samot | Why? Im not going easy on your ex's right now. |
| 05:55.17 | drmessano | Oh shit... You can break off as much of that as you want |
| 06:04.20 | *** join/#asterisk Omniflux (~Omniflux@ircpuzzles/2016/april-fools/seventh/Omniflux) |
| 06:05.23 | Omniflux | Is it possible to check for the existance of a subscription in the dialplan? |
| 06:08.45 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 06:18.37 | *** join/#asterisk Mr_Pleb_Mgoo (~jakeb@103.89.83.14) |
| 07:22.45 | *** join/#asterisk MrTAP1 (~MrT@unaffiliated/mrtap) |
| 08:10.19 | *** part/#asterisk Omniflux (~Omniflux@ircpuzzles/2016/april-fools/seventh/Omniflux) |
| 08:18.31 | *** join/#asterisk miralin (~Thunderbi@194.8.128.67) |
| 08:46.57 | *** join/#asterisk DanB (~DanB@clt-195.192.205.194.ip-anschluss.net) |
| 09:33.48 | *** join/#asterisk pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 11:12.15 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 11:27.25 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 12:03.11 | *** join/#asterisk rpifan (~rpifan@ipb218f164.dynamic.kabel-deutschland.de) |
| 12:10.36 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 13:14.17 | *** join/#asterisk miralin (~Thunderbi@194.8.128.67) |
| 13:22.31 | *** join/#asterisk paulgrmn (~paulgrmn@87.101.92.110) |
| 13:32.04 | *** join/#asterisk life_of_e (~life_of_e@108-95-189-245.lightspeed.irvnca.sbcglobal.net) |
| 13:47.11 | *** join/#asterisk rpifan (~rpifan@ipb218f164.dynamic.kabel-deutschland.de) |
| 13:53.15 | *** join/#asterisk Mr_Pleb_Mgoo (~jakeb@103.46.212.49) |
| 13:55.39 | *** join/#asterisk wakko1 (~wakko@176.164.184.251) |
| 14:06.41 | *** join/#asterisk rpifan (~rpifan@ipb218f164.dynamic.kabel-deutschland.de) |
| 14:21.49 | *** join/#asterisk miralin (~Thunderbi@194.8.128.67) |
| 14:28.37 | *** join/#asterisk jkroon (~jkroon@165.16.204.35) |
| 14:52.53 | *** join/#asterisk FuriousGeorge (~Brian@pool-74-102-33-231.nwrknj.fios.verizon.net) |
| 15:06.39 | *** join/#asterisk miralin (~Thunderbi@194.8.128.67) |
| 15:25.54 | *** join/#asterisk LoKoMurdoK (~LoKoMurdo@fedora/LoKoMurdoK) |
| 15:31.42 | *** join/#asterisk rpifan (~rpifan@ipb218f164.dynamic.kabel-deutschland.de) |
| 15:35.21 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 15:46.08 | *** join/#asterisk war9407 (~war@2600:4040:400f:c300:10a:12ee:bd81:2acb) |
| 15:56.56 | *** join/#asterisk war9407 (~war@2600:4040:400f:c300:10a:12ee:bd81:2acb) |
| 16:04.47 | FuriousGeorge | lol |
| 16:30.08 | *** join/#asterisk rpifan (~rpifan@ipb218f164.dynamic.kabel-deutschland.de) |
| 16:57.41 | *** join/#asterisk gusto (~gusto@2a01:c844:14b5:da02:7566:a723:7a58:cb6e) |
| 17:03.00 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 17:33.34 | *** join/#asterisk dcollins0 (~dandann00@2601:840:8401:d7ee:cd87:f9f3:b237:db82) |
| 18:18.26 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-hsmsssrnmjmqvlnf) |
| 18:18.45 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 18:34.50 | *** join/#asterisk Hyper_Eye (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 19:46.09 | *** join/#asterisk dcollins0 (~dandann00@2601:840:8401:d7ee:cd87:f9f3:b237:db82) |
| 20:12.54 | *** join/#asterisk pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 20:35.06 | *** join/#asterisk rpifan (~rpifan@ipb218f0bf.dynamic.kabel-deutschland.de) |
| 20:38.31 | *** join/#asterisk rpifan (~rpifan@ipb218f0bf.dynamic.kabel-deutschland.de) |
| 21:39.30 | *** join/#asterisk AndChat|620489 (~AndChat62@151.sub-97-43-194.myvzw.com) |
| 21:40.31 | *** join/#asterisk AndChat-620489 (~AndChat62@2600:100e:b044:e6cd:306d:32e2:f524:7db5) |
| 21:43.15 | *** join/#asterisk nix8n82 (~AndChat62@30.sub-97-44-0.myvzw.com) |
| 21:44.28 | *** join/#asterisk AndChat|620489 (~AndChat62@2600:100e:b04f:ffa1:4057:12a1:a8ba:d09b) |
| 21:52.51 | *** join/#asterisk kunwon1 (~kunwon1@unaffiliated/kunwon1) |
| 21:53.13 | *** join/#asterisk nix8n82 (~AndChat62@226.sub-97-43-194.myvzw.com) |
| 21:54.17 | *** join/#asterisk AndChat-620489 (~AndChat62@2600:100e:b02a:e12:cddb:7a84:8795:df05) |
| 22:00.35 | *** join/#asterisk miralin (~Thunderbi@194.8.128.67) |
| 22:51.58 | *** join/#asterisk rpifan (~rpifan@178.24.240.109) |
| 23:08.20 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
