| 00:10.00 | *** part/#asterisk kharwell (kharwell@nat/digium/x-hbtdspvybzfblpfg) |
| 00:12.18 | lvlinux | If my provider supports T.38, and I start sending a fax with G.711, they should detect the fax tone and send me back a t.38 reinvite right?? |
| 00:13.31 | Samot | 4:33:16 PM D<danielyk> Why on so an old version? |
| 00:13.31 | Samot | 4:33:24 PM V<vo1pbx> cepstral |
| 00:13.54 | Samot | ^^ Cepstral runs fine all the way up to 13. Haven't really tested on 14 yet. |
| 00:22.18 | [NC] | lvlinux: They should, yes. But not all do and most do it for only some destinations. |
| 00:23.27 | lvlinux | Hmm, well I'm trying with Flowroute, and they are supposed to support it pretty well. I don't get a reinvite for some reason. I am able to send a fax with t.38 directly from asterisk to my ATA/fax machine, so I think I have it setup properly. |
| 00:23.53 | Samot | Do you have T.38 enabled on the peer? |
| 00:25.02 | lvlinux | Yes on the Flowoute endpoint and also the ATA |
| 00:25.12 | Samot | No. |
| 00:25.20 | Samot | In Asterisk. |
| 00:25.31 | Samot | In your flowroute trunk, you have t38 enabled? |
| 00:25.56 | lvlinux | Yes that's what I mean: on the endpoint config in pjsip.conf I have t.38 enabled for both the flowroute section and the ATA. |
| 00:26.05 | Samot | OK. |
| 00:27.41 | lvlinux | When I do a sip debug and send the ATA a fax directly from asterisk, the ATA gives me a reinvite and then asterisk starts sending t.38 udptl packets, as expected. But when calling from the ATA to flowroute, via Asterisk, I don't see the reinvite, and it stays ulaw for some reason. |
| 00:27.58 | lvlinux | I also tried with Vitelity with the same results. |
| 00:28.09 | Samot | OK.. |
| 00:28.11 | Samot | So.. |
| 00:29.02 | Samot | T.38 isn't a codec. |
| 00:29.07 | lvlinux | yes i know |
| 00:29.08 | Samot | It's an encapsulation. |
| 00:29.10 | Samot | OK |
| 00:30.14 | lvlinux | When t.38 is in use, pjsip show channelstats does not show ulaw for the call. |
| 00:30.16 | Samot | So when you send an outbound fax via the ATA to Asterisk, you see the call get answered and bridged.. |
| 00:30.25 | lvlinux | Yes |
| 00:30.28 | Samot | But you don't see a re-Invite after? |
| 00:30.33 | lvlinux | correct |
| 00:30.38 | Samot | Show a debug. |
| 00:31.19 | lvlinux | Also, I tried sending directly from Asterisk to Flowroute, and it failed saying that ulaw faxes weren't allowed, and T.38 negotiation failed. |
| 00:31.34 | *** join/#asterisk mutin-sa (~s-mutin@85.234.114.134) |
| 00:32.28 | Samot | Show a debug. |
| 00:33.39 | lvlinux | getting it... |
| 00:39.06 | lvlinux | http://susepaste.org/90984463 |
| 00:43.12 | Samot | So the VGAFXS device, not sending T.38 in the SDP offer. |
| 00:43.16 | Samot | That's 1 |
| 00:44.03 | Samot | I see the call ACK but then I just see a BYE. |
| 00:44.21 | Samot | The reason Flowroute isn't sending back T.38 is because it's not in the SDP offering. |
| 00:44.35 | Samot | So as far as they are concerned, you don't want T.38. |
| 00:44.48 | Samot | The other side needs to know you can support it. |
| 00:45.02 | Samot | They just won't re-INVITE with t.38 if you don't tell them to. |
| 00:45.59 | Samot | The call is going to answer normally |
| 00:46.05 | lvlinux | ah ok |
| 00:46.07 | Samot | Until you send FAX tones. |
| 00:46.19 | Samot | Then they'll re-INVITE with t.38 |
| 00:46.22 | lvlinux | i wondered if it was supposed to be in the SDP but didn't know for sure. |
| 00:46.31 | Samot | So 1) Your ATA needs to have T.38 support enabled. |
| 00:47.04 | Samot | 2) You need to actually initiate FAX tones for Flowroute to send back a T.38 re-INVITE |
| 00:47.17 | lvlinux | It has it enabled, but I don't know why it isn't sending it. It's a MultiTech MultiVoIP. |
| 00:47.27 | Samot | Double check. |
| 00:47.35 | Samot | It's a setting that can be disabled. |
| 00:47.36 | [NC] | Samot: Does Flowroute really do that? I never saw a provider require udptl in the original INVITE SDP offer... and ATAs/gateways/FAX servers don't advertise udptl in the original INVITE in normal configuration (when they can at all...) |
| 00:47.38 | Samot | Make sure it isn't. |
| 00:47.47 | Samot | OK. |
| 00:47.52 | Samot | I just explained how it works. |
| 00:48.07 | Samot | 1) You need to send T.38 in the SDP |
| 00:48.13 | Samot | 2) They need to support it |
| 00:48.35 | lvlinux | Now let me pb a debug from Asterisk trying to send the fax directly to Vitelity, with no ATA involved. |
| 00:48.38 | Samot | 3) Once a FAX starts and the other side supprots it, they send back a Re-INVITE for t.38 |
| 00:48.47 | [NC] | Samot: That's not the standard way to do it. Flowroute is not standard if they work like that. |
| 00:48.56 | Samot | I'm sorry what? |
| 00:49.01 | Samot | What do you think is the standard way? |
| 00:49.03 | Samot | Please tell me. |
| 00:50.12 | [NC] | Samot: Call is established with G.711. Then receiving side sends a re-invite to T.38 to sending side. If sending side supports it, it accepts and the call continue with T.38, if it doesn't, it sends 488 response and the call continue with G.711. |
| 00:50.39 | lvlinux | http://susepaste.org/132807 |
| 00:50.55 | Samot | Yes. |
| 00:51.07 | Samot | The call is established with g711 |
| 00:51.11 | Samot | Because as I said |
| 00:51.15 | lvlinux | That pastebin is debug of trying to send the fax directly from Asterisk. |
| 00:51.29 | Samot | 7:29:07 PM S<Samot> It's an encapsulation. <-- Thats what T.38 is |
| 00:51.43 | Samot | So the other side needs to know you want to use T.38 |
| 00:51.52 | Samot | And when they realize it's a FAX call.. |
| 00:52.06 | Samot | Sorry.. |
| 00:52.08 | Samot | Flipped it |
| 00:52.21 | [NC] | There is a way to advertise support for udptl in the original INVITE (RFC 6913), but that is not often supported. |
| 00:52.21 | Samot | They cause the re-INVITE but from the sending side, yes. |
| 00:52.29 | Samot | I just corrected myself. |
| 00:52.50 | Samot | But that doesn't change that T.38 needs to be offered. |
| 00:52.58 | Samot | So it can be answered. |
| 00:53.11 | [NC] | The standard way is for the receiving side to do the re-invite... but there are providers that require the sending side to do it. |
| 00:53.14 | Samot | But yes, it makes the other side do a Re-INVITE |
| 00:53.21 | Samot | FFS. |
| 00:53.27 | Samot | OK. |
| 00:53.42 | Samot | It's clear we are talking about the same process and getting wires crossed. |
| 00:53.53 | Samot | The bottom line, there was no T.38 in the call |
| 00:54.30 | lvlinux | So I'm confused why they aren't sending the re-invite when I start sending fax tones? |
| 00:54.33 | [NC] | And there are providers that don't support T.38 for all destinations (depends on their undercarrier). |
| 01:01.09 | [NC] | lvlinux: They might not support T.38 for this destination... you can try different fax destinations and see if some do get Flowroute to re-invite. It's possible Flowroute (never used them, so I don't know) doesn't ever do re-invite, but accepts them if you do, you could try to configure your ATA to do the re-invite itself and see if that works. That's not the best configuration, but it sometime is the only one that works for some providers. |
| 01:02.35 | [NC] | lvlinux: Or you try another provider. |
| 01:03.12 | lvlinux | I tried two providers, Flowroute and Vitelity (both are supposed to have excellent t.38 support). |
| 01:03.55 | lvlinux | ah, i tried a different destination number and it worked. |
| 01:09.05 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 01:22.09 | *** join/#asterisk s-mutin (~s-mutin@85.234.114.134) |
| 01:27.33 | *** join/#asterisk NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 01:28.17 | *** join/#asterisk retentiveboy (~retentive@c-73-82-30-193.hsd1.ga.comcast.net) |
| 01:28.17 | *** join/#asterisk Marquel (~Marquel@fuchsfanclub/allerdings/marquel) |
| 01:28.17 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 01:28.17 | *** join/#asterisk troyt (~troyt@c-73-65-211-33.hsd1.ut.comcast.net) |
| 01:28.17 | *** join/#asterisk iggi (~iggi@ip69.50-31-21.static.steadfastdns.net) |
| 01:28.17 | *** join/#asterisk gregs (sid160074@gateway/web/irccloud.com/x-oteogdjoeudqffhu) |
| 01:28.17 | *** join/#asterisk netman (~netman@185.94.249.77) |
| 01:28.17 | *** join/#asterisk stefan27 (~stefan27@static-212-247-4-149.cust.tele2.se) |
| 01:28.17 | *** join/#asterisk emk (~emk@unaffiliated/emk) |
| 01:28.17 | *** join/#asterisk somepoortech (~somepoort@72-0-128-109.static.firstlight.net) |
| 01:28.17 | *** join/#asterisk sibiria (~sibiria@unaffiliated/sibiria) |
| 01:35.52 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 02:05.20 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:06.10 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:06.56 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:07.46 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:08.36 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:09.24 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:10.08 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:10.58 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:11.48 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:12.33 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:13.23 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:14.08 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:14.58 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:15.48 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:16.35 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:17.25 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:18.10 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:19.00 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:19.52 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:43.53 | *** join/#asterisk Korolev (~Korolev@c-73-179-85-246.hsd1.fl.comcast.net) |
| 03:09.08 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 03:36.34 | *** join/#asterisk jeffspeff (~Jeff@209.141.208.197) |
| 04:05.12 | Korolev | Hi, packetization doesn't seem to be working on IAX, is there something else that needs to be set besides allow=codec:size? |
| 04:05.17 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 04:12.58 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 04:54.06 | *** join/#asterisk iheartlinux (~jwpierce3@mail.trunkmasters.com) |
| 05:05.50 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 05:06.11 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 06:05.45 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 06:08.46 | *** join/#asterisk tripleslash (~triplesla@unaffiliated/imsaguy) |
| 06:32.13 | *** join/#asterisk gerhard7__ (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 07:01.56 | *** join/#asterisk defsdoor (~andy@cpc120600-sutt6-2-0-cust177.19-1.cable.virginm.net) |
| 07:35.11 | *** part/#asterisk _ppp (Elite20382@gateway/shell/elitebnc/x-ixidbajhsqivpawj) |
| 12:36.56 | *** join/#asterisk infobot (~infobot@rikers.org) |
| 12:36.56 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.18.2 (2017/11/10), Standard: 15.1.2 (2017/11/10); 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 |
| 12:49.44 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 12:55.35 | *** join/#asterisk pawiecki (~pawiecki@router.dir.pl) |
| 13:16.02 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 13:28.18 | *** join/#asterisk jkroon (~jkroon@165.16.204.174) |
| 13:34.51 | *** join/#asterisk wim_ (~wim@ip-94-140-174-105.reverse.destiny.be) |
| 13:36.45 | wim_ | Hello all. I have a question about the RTP stream qualifying. Could there be a bug in case there's both audio and video sent? |
| 13:38.05 | wim_ | when i set up a video call with strictrtp = yes from behind a nat, the audio stream gets qualified, the video stream logs "qualifying new stream" but the counter never goes down. It keeps logging "Will switch to it in 3 packets" |
| 13:41.39 | wim_ | This is a log with rtp debug on, debug 5 res_rtp_asterisk and verbose 5 https://pastebin.com/wpYsx3ke |
| 13:46.17 | wim_ | oh, and the asterisk version is 13.18.0-rc1 |
| 14:01.50 | Samot | Why are you using an RC? |
| 14:03.56 | *** join/#asterisk sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 14:04.04 | wim_ | good question, it's not my choice. |
| 14:04.35 | sibiria | anyone here good with EAGI? |
| 14:06.11 | sibiria | in the case of outgoing calls, i wonder if there's a chance that (or way to control) the incoming/them audio stream is something else than slin |
| 14:07.09 | sibiria | we had a weird case of our internal answering machine detection, suddenly, from one specific provider, not being able to recognize beeps in the audio stream in real time |
| 14:07.27 | sibiria | but flawless 100% accuracy when feeding the software the wav recording of the same calls |
| 14:07.57 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 14:08.10 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 14:08.43 | sibiria | am i wrong assuming that asterisk will always feed the EAGI application slin? |
| 14:08.57 | *** join/#asterisk gerhard7__ (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 14:09.56 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 14:10.07 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 14:15.32 | Samot | And how does the provider send you DTMF? |
| 14:15.47 | Samot | Or what DTMF options do they support? |
| 14:16.45 | wim_ | not sure sibiria means a dtmf beep, but rather the beep you hear to start recording the voicemail |
| 14:17.52 | Samot | OK |
| 14:18.04 | Samot | 1) Your answering machine greeting is just an audio stream. |
| 14:18.23 | Samot | 2) Unless the BEEP is an actual DTMF tone, it's just audio. |
| 14:18.31 | sibiria | exactly, it's not a DTMF problem |
| 14:18.39 | sibiria | also, we catch DTMF in the audio stream |
| 14:18.48 | sibiria | but again, it's not about DTMF |
| 14:18.50 | Samot | So it's the beep in the audio stream from the machine? |
| 14:18.57 | Samot | Only over one provider? |
| 14:19.02 | sibiria | yes and yes |
| 14:19.13 | Samot | No matter who you call, that beep is never picked up? |
| 14:19.23 | sibiria | yes, from that specific provider |
| 14:19.26 | wim_ | what codec does that provider use? |
| 14:19.31 | sibiria | alaw |
| 14:19.35 | sibiria | the audio recording is crisp clear |
| 14:19.50 | *** join/#asterisk Da-Geek (~Da-Geek@88.98.221.152) |
| 14:19.52 | sibiria | our AMD software notices the beep with 100% accuracy when it analyzes the *recording* |
| 14:20.00 | sibiria | but not in the real time audio feed via EAGI |
| 14:20.08 | sibiria | and only that one provider... |
| 14:20.24 | Samot | So you're AMD software listens for beeps? |
| 14:20.33 | sibiria | the only thing i can think of is if asterisk for some reason suddenly fed something else than SLIN over EAGI |
| 14:20.36 | sibiria | yes |
| 14:20.40 | Samot | Every type of beep a voicemail can prompt? |
| 14:20.45 | Samot | That's odd. |
| 14:21.04 | sibiria | is the audio format for EAGI configurable maybe? |
| 14:21.17 | sibiria | it's like that specific trunk somehow messes with EAGI |
| 14:22.15 | sibiria | the sip config for that trunk is no different than for the others, and the audio recording is proof that, at least internally for asteirsk, everything is alright with the audio |
| 14:22.37 | sibiria | maybe asterisk never fed any audio to the EAGI application |
| 14:22.48 | Samot | OK |
| 14:22.53 | Samot | So have you read EAGI? |
| 14:23.14 | sibiria | that's our AMD software's modus operandi, yes |
| 14:23.32 | sibiria | streams a message while listening to the incoming audio |
| 14:24.13 | Samot | And how it sends the audio out of band |
| 14:24.32 | sibiria | it sends it the EAGI way, across the outgoing file descriptor |
| 14:24.37 | sibiria | the amd itself is not the problem, really |
| 14:24.44 | Samot | OK |
| 14:24.45 | sibiria | it works with 99% accuracy |
| 14:24.55 | Samot | When not sent via EAGI |
| 14:25.03 | Samot | Or just through this provider? |
| 14:25.11 | sibiria | i'm really getting the feeling that asterisk just didn't send it any audio, or that it for some reason suddenly sent something else than SLIN |
| 14:25.21 | sibiria | this has only happened with this one provider |
| 14:26.21 | Samot | So.. |
| 14:26.23 | Samot | Just curious.. |
| 14:26.36 | Samot | What if I play a beep in my greeting as a joke? |
| 14:26.42 | Samot | Before the real beep hits? |
| 14:26.49 | Samot | What does your AMD software do then? |
| 14:27.02 | sibiria | depending on how good a beep you send, our software can be fooled, obviously |
| 14:27.13 | Samot | The same beep |
| 14:27.39 | sibiria | then it can be fooled, if you say a few words and then beep |
| 14:27.57 | Samot | So it doesn't look for actual speech patterns? |
| 14:28.18 | Samot | Or speaking and silence gaps? |
| 14:28.43 | sibiria | it wants a certain amount of words before its fourier transformation kicks in to analyze frequency spikes |
| 14:29.02 | sibiria | pardon, but how is this relevant? the software does a great job when it's being fed SLIN audio :) |
| 14:29.17 | Samot | Well |
| 14:29.19 | Samot | Lets see. |
| 14:29.49 | *** part/#asterisk wim_ (~wim@ip-94-140-174-105.reverse.destiny.be) |
| 14:29.52 | *** join/#asterisk wim_ (~wim@ip-94-140-174-105.reverse.destiny.be) |
| 14:29.57 | Samot | You're having an issue interrupting the DTMF/audio on a call. Understand how it does those things, helps. |
| 14:30.13 | Samot | Otherwise we're just guessing at what this software is doing. |
| 14:30.36 | Samot | Have you looked at the debugs between two calls? |
| 14:33.24 | wim_ | sibiria, you say that it needs to detect a few words for the beep detection to work. does it log this? If so you could at least see it that's working as expected |
| 14:33.27 | sibiria | we don't need to guess what the software does. it's *our* software. we developed it. the question isn't really if the software itself performs good or bad, but whether there's a chance that asterisk ocassionally might not feed audio over EAGI at all |
| 14:33.50 | sibiria | is it perhaps a file descriptor limit? did asterisk fail to allocate? |
| 14:34.06 | sibiria | (i find no warnings in asterisk's log, though) |
| 14:34.17 | sibiria | wim_: it works as expected |
| 14:34.36 | Samot | I said *we* as in the people you are asking for help. |
| 14:34.44 | Samot | We don't know who this software works. |
| 14:34.56 | Samot | Have you looked at a debug between calls? |
| 14:35.03 | sibiria | perhaps this was missed: feeding the software the final call recordings OF THE EXACT SAME CALLS yields a positive result on every single case |
| 14:35.04 | Samot | One that works and one that doesn't? |
| 14:35.04 | wim_ | so that proves that the audio actually is sent to the eagi. |
| 14:35.09 | Samot | Are they being sent differently? |
| 14:35.22 | Samot | OK. |
| 14:35.30 | Samot | Have you looked at the calls? |
| 14:35.37 | Samot | Simple question. |
| 14:35.43 | sibiria | there's no discernable difference between working and failing calls |
| 14:35.54 | Samot | So the debugs show nothing different |
| 14:35.58 | sibiria | correct |
| 14:36.50 | sibiria | since there's no clear insight in whether or not asterisk may send something else than SLIN over EAGI, or send silence suddenly, i think the only resort is that i start tapping and dumping the incoming audio from within the EAGI application |
| 14:37.00 | sibiria | to compare with asterisk's own saved recording |
| 14:37.11 | sibiria | to see if it really is feeding silence, which seems to be the case |
| 14:37.41 | wim_ | sibiria, you say that it detects the speech normally, so you know the eagi hears audio. |
| 14:38.03 | sibiria | wim_: maybe a language barrier - i said that it looks for speech as well |
| 14:38.08 | sibiria | not just a repeating waveform |
| 14:39.21 | wim_ | well, maybe but you said "it wants a certain amount of words before its fourier transformation kicks in to analyze frequency spikes" |
| 14:40.36 | wim_ | so you need to detect both speech and then a beep. the question was, when the beep is not detected, did it detect the voice? If not you could say no audio is fed to the eagi |
| 14:41.45 | sibiria | it doesn't seem to detect either, but i don't know if it's because silence is being fed, or "noise" is being fed (read: audio in something else than SLIN format) |
| 14:42.08 | sibiria | cannot find anything in the asterisk documentation regarding possibly different audio formats coming across EAGI |
| 14:47.54 | wim_ | i guess it makes sense to dump the audio from the script and see what that gives |
| 14:48.08 | *** join/#asterisk [[thufir]] (~thufir@192.157.119.2) |
| 14:49.59 | *** join/#asterisk kharwell (kharwell@nat/digium/x-cyesgzrtdvusugvk) |
| 14:50.00 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:55.16 | [[thufir]] | what is the default login for AsteriskNOW? from the console. https://community.asterisk.org/t/asterisknow-login-command-line-cli/72644 user:root password: ? |
| 15:12.15 | *** join/#asterisk Dirk23 (Dirk23@diehildebrands.de) |
| 15:13.03 | Samot | It's what you make it. |
| 15:13.12 | Samot | There is no "default" |
| 15:14.05 | *** join/#asterisk bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:14.05 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:14.10 | Samot | You set the systems root password when you installed the ISO |
| 15:14.23 | Samot | And configured the system, like any other Linux distro install. |
| 15:15.02 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 15:15.11 | Samot | If you don't have or forgot the root password for the system, you need to recover it normally based on the Linux distro you are using. |
| 15:15.13 | [[thufir]] | Samot: ok, thanks. I don't recall those steps with this install. It was with kvm. I still would've been prompted? weird. |
| 15:15.23 | Samot | Yes, you would have been. |
| 15:15.28 | Samot | It's a normal Linux install. |
| 15:15.31 | [[thufir]] | ok. thx. |
| 15:15.35 | Samot | You would have been asked for the root password. |
| 15:15.39 | Samot | To set it. |
| 15:15.47 | Samot | What OS is this? |
| 15:16.11 | [[thufir]] | AsteriskNOW (virtual) as guest on kvm. I'm running Ubuntu. |
| 15:16.42 | [[thufir]] | ubuntu as host. AsteriskNOW as guest. (kvm) |
| 15:17.10 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 15:17.24 | [[thufir]] | lol. logged in! guessed my password. heh, just didn't recall that step for some reason. |
| 15:21.54 | [[thufir]] | AsteriskNOW is basically freePBX? |
| 15:23.27 | Samot | Yes |
| 15:23.54 | [[thufir]] | is it preferable to use AsteriskNOW, or just download freepbx? half a dozen of one, six other? |
| 15:24.36 | [TK]D-Fender | I'd stick with the FreePBX distro |
| 15:24.49 | [TK]D-Fender | leave the GUI to the GUI people. |
| 15:26.12 | [[thufir]] | ok. thx. |
| 15:26.41 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 15:29.44 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 15:30.39 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 15:33.01 | tzafrir | Has anybody been using chan_console recently on Linux? It gives me an error about trying to write to a read-only (audio) device |
| 15:35.09 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:35.09 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 15:37.11 | wim_ | tzafrir, i remember i had the same issue a while ago. I think it's been 6 months to a year ago. Couldn't be bothered to find a solution, just wanted to show the feature to a colleague |
| 15:38.23 | tzafrir | chan_alsa would have worked, but I need to use more than a single device. |
| 15:39.07 | *** join/#asterisk Stokkeland (~tstokkel@64.238.139.2) |
| 15:48.56 | Stokkeland | stability issue - in stress testing, about a million sip (chan_sip) calls and 800 config change/reloads done in 36 hours - segfault in chan_sip (i think). |
| 15:48.59 | Stokkeland | with 13.18.2 - last log entries are astobj2.c: FRACK!, Failed assertion user_data is NULL (0). I have traces etc but dont know how to read them. |
| 15:49.02 | Stokkeland | it is reproducable, just takes 1-2 days, sometimes 3. uncertain where to turn for consultancy on somehting like this - digium directly? |
| 15:50.00 | Samot | Uhm. |
| 15:50.03 | Samot | A million calls? |
| 15:50.05 | Samot | WTF? |
| 15:50.14 | Samot | What scenario will that actually be applied in? |
| 15:50.56 | Stokkeland | well yes.. in a production setup - system may process 50 thousand calls a day.. we have that in production today, one site started getting segfaults, and we can reproduce with stress tests |
| 15:51.16 | Samot | 50,000 per day? |
| 15:51.25 | Samot | Is this for an ITSP or something? |
| 15:51.40 | Stokkeland | more or less - 12000 configured users, ~4000 online at the time |
| 15:52.11 | Stokkeland | large business - voice in an app basically |
| 15:52.38 | Stokkeland | (we support our app directly to CUCM also, but many dont want to pay cisco so they take our asterisk based option) |
| 15:53.19 | Samot | But you're only using one server to support all this? |
| 15:53.33 | Stokkeland | yes - our limit is 4000 active users on a single server |
| 15:53.57 | Samot | So that means 4000 users get 50,000 calls? |
| 15:54.03 | Samot | I'm trying to understand this. |
| 15:54.04 | Korolev | I get over a million attempts on a single server too, nothing rara |
| 15:54.14 | Samot | "attempts" |
| 15:54.18 | Stokkeland | yes - typical max in a day is around 50k |
| 15:54.19 | Samot | As in people attacking you? |
| 15:54.26 | Samot | Trying to get into the system? |
| 15:54.31 | Samot | Or actual calls on the system? |
| 15:54.36 | Korolev | no, as in people trying to call, but not all are answered |
| 15:54.38 | Samot | That are being processed. |
| 15:54.43 | Stokkeland | actual calls - there is no internex exposure |
| 15:54.44 | Samot | OK |
| 15:54.46 | Samot | So.. |
| 15:55.22 | Samot | What is this system running as resources? |
| 15:55.23 | Korolev | with pjsip, chan_sip segfaults with far less than that |
| 15:55.28 | Stokkeland | we stresstested a year ago for 3 weeks without issue.. issue started recently, no idea what the difference is - same kernel etc |
| 15:55.41 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-icfbnszzaldhlxid) |
| 15:55.41 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 15:55.54 | Stokkeland | during the tests i hva 4vcpu and run no more than 1.5 |
| 15:56.09 | Samot | How many core? |
| 15:56.14 | Stokkeland | 4 |
| 15:56.20 | Samot | Each CPU |
| 15:56.22 | Samot | Or overall? |
| 15:56.34 | Samot | Because so far this is underpowered. |
| 15:56.34 | Stokkeland | it is a vmware vm, it has 4 vcore |
| 15:56.37 | Stokkeland | total |
| 15:56.46 | Samot | 4 cores is not enough |
| 15:56.48 | Korolev | yeah, very underpowered |
| 15:56.56 | Samot | At all. |
| 15:56.58 | Stokkeland | there is no transcoding |
| 15:57.02 | Samot | Doesn't matter. |
| 15:57.05 | Samot | Not enough |
| 15:57.07 | Samot | Period. |
| 15:57.08 | Korolev | still,that is a lot of call setups |
| 15:57.10 | Samot | For eal load. |
| 15:57.12 | Samot | real |
| 15:57.24 | Stokkeland | load never goes above 2.0 |
| 15:57.29 | Samot | OK |
| 15:57.30 | Samot | Dude. |
| 15:57.37 | Samot | Your box is underpowered. |
| 15:57.38 | Samot | Period. |
| 15:57.46 | Samot | You can tell us all the things in the world. |
| 15:58.04 | Samot | 4 core for 50K calls and 4K users is not enough |
| 15:58.06 | Samot | At all. |
| 15:58.44 | Stokkeland | i use 8 core at customer sites - i purposely use 4 in my stress test to see how it pushes the limit. regardless though, can that cuase the segfault? |
| 15:58.55 | Samot | Yes. |
| 15:59.06 | Samot | An underpowered box being hammered will do that |
| 15:59.20 | Stokkeland | okay - I will redo my stresstest with 24 core and see if it improves |
| 15:59.21 | Korolev | about chan_sip, I'm not sure that the load is the reason |
| 15:59.44 | Korolev | I have had chan_sip segfault with about 100 calls, a mix of transcoding and passthrough |
| 16:00.33 | Samot | i haven't. |
| 16:00.37 | Korolev | my impression is that is more related to calls per second than total number of calls |
| 16:00.44 | Stokkeland | okay |
| 16:00.50 | Samot | It's a combination of both |
| 16:00.52 | Stokkeland | that is an interresting thing to test |
| 16:00.52 | Korolev | my solution was to switch pjsip |
| 16:01.06 | Korolev | switch to* |
| 16:01.53 | Korolev | for an easy example, I get a high volume of domestic calls |
| 16:02.04 | Stokkeland | yeah pjsip is teh long term goal - perhaps a comparison test in my lab would be worth it |
| 16:02.32 | Korolev | with conference traffic, which has an acd around 20 minutes, I can push near 100 calls with chan_sip before it started to segfault randomly |
| 16:03.29 | Korolev | with callcenter traffic, with an acd below 1 minute, but a much higher number of calls per second, north of 10, chan_sip dies after 40 or 50 simultaneous calls |
| 16:04.32 | Stokkeland | thank you for the input guys - I will do some other tests around it now, more cores as well as a pjsip test comparison |
| 16:04.36 | Korolev | if you could come up with more accurate numbers and publish them, that would help a lot of people plan their setups better |
| 16:06.57 | Samot | I push 1800 calls in 3 minutes with Chan_SIP for alert calls. |
| 16:07.09 | Samot | I do not have these issues. |
| 16:07.24 | Korolev | that's 10 calls per second, for how long? |
| 16:07.36 | Samot | This sounds more like poor or not configured right systems. |
| 16:07.49 | Stokkeland | spaced randomly or fixed? I use startrinity Sip testers and randomize the calling to try make it life like |
| 16:07.51 | Samot | 60 to 90 seconds when they connect. |
| 16:07.59 | Samot | Yes, 10 CPS. |
| 16:08.09 | Korolev | no, for how long do you run the alert calls, all day long? |
| 16:08.15 | Samot | When needed. |
| 16:08.33 | Samot | It's tied to the National/State Weather databases. |
| 16:08.34 | Korolev | chan_sip can certainly hold it's own for a short period of time |
| 16:08.38 | Samot | No. |
| 16:08.46 | Samot | It can hold it's own for a long period of time. |
| 16:08.50 | Samot | If you do it right |
| 16:08.51 | Korolev | ok |
| 16:08.57 | Samot | Just like anything else. |
| 16:09.38 | Samot | What do you think people did before 2014? |
| 16:09.40 | Korolev | would you mind setting up a test machine and doing an experiment with me? |
| 16:10.03 | Korolev | I have been selling voip traffic since 2008 |
| 16:10.06 | Samot | Just said "Screw it Chan_SIP can't do it, let's use IAX?" |
| 16:10.12 | Samot | I mean before PJSIP |
| 16:10.26 | Korolev | no, I said screw it, chan_sip can't do it, let's use sophia |
| 16:10.34 | Samot | Except it can. |
| 16:10.45 | Korolev | we can test it out |
| 16:10.54 | Samot | I don't need to test anything. |
| 16:11.07 | Korolev | I can push 200 concurrent calls to you, and you can return them to a second server of mine so that they complete |
| 16:11.07 | Samot | I've run providers on Asterisk networks for over 10 years. |
| 16:11.12 | Korolev | and see how long chan_sip lasts |
| 16:11.17 | Samot | I don't need to |
| 16:11.25 | Samot | I have networks that already do that |
| 16:11.34 | Samot | I don't need to test with you because you don't believe me. |
| 16:11.43 | Korolev | then I must have been configuring it the wrong way |
| 16:11.57 | Samot | 11:07:35 AM S<Samot> This sounds more like poor or not configured right systems. |
| 16:11.57 | voipmonk | but its coming back to your misconfigured systems - sounds like a fail anyway |
| 16:11.59 | Korolev | but now I'm interested |
| 16:12.24 | Korolev | what tweeks are out there to make chan_sip more rubust? |
| 16:12.37 | Korolev | i would love to change away from pjsip and back to chan_sip |
| 16:12.45 | Samot | There's like 15 years of documentation all over on that |
| 16:12.56 | Korolev | could you point to some? |
| 16:12.56 | Samot | Why? |
| 16:13.06 | Samot | Chan_SIP is dying. |
| 16:13.16 | Samot | It will be the way of the dodo soon. |
| 16:13.20 | Samot | That's what PJSIP is for. |
| 16:13.50 | Samot | Even next year I have plans to start the conversion. |
| 16:15.34 | Samot | But again... |
| 16:15.38 | Samot | I do things that most don't |
| 16:15.45 | Samot | 1) I never use Asterisk as a switch |
| 16:15.53 | Samot | 2) I never use Asterisk as a billing system |
| 16:16.26 | Korolev | when you say asterisk as a billing system, is that even possible? |
| 16:16.43 | Samot | There are a few billing software programs out there for this. |
| 16:16.48 | Samot | That many providers use |
| 16:17.43 | Samot | Part of the problem with providers is they think an Asterisk box, some billing software and a couple upstream providers makes them an ITSP or VoIP Provider. |
| 16:17.57 | Korolev | doesn't it though? |
| 16:18.00 | voipmonk | ... |
| 16:18.02 | Samot | No. |
| 16:18.07 | Samot | Not at all. |
| 16:18.18 | Korolev | what makes a voip provider one? |
| 16:18.32 | Samot | Well technically yes, it does. |
| 16:18.37 | Samot | Does it mean you're doing it right? |
| 16:18.39 | Samot | Or well? |
| 16:18.40 | Samot | No. |
| 16:18.49 | voipmonk | You have to know how to read. |
| 16:18.55 | Samot | Well I would say understanding the basics of Telephony |
| 16:18.56 | voipmonk | and apply what you have read. |
| 16:18.59 | Samot | The basics of SIP |
| 16:19.07 | Samot | Before you even get to your system... |
| 16:19.12 | Samot | Should be in the wheelhouse. |
| 16:20.54 | Korolev | no I get it, and I tend to agree with you, most people using asterisk/freeswitch/whathaveyou with some piece of php built billing system are doing it wrong |
| 16:20.59 | Samot | This is also the reason why many use FreePBX/AsteriskNOW and end up spinning up numerous boxes for 5 user accounts. |
| 16:21.12 | Samot | Because they can't figure out how to make Asterisk work properly |
| 16:21.14 | Korolev | but my point was, because most are doing it wrong, doesn't mean it can't be done right |
| 16:21.27 | Samot | Right. |
| 16:21.30 | Samot | My point. |
| 16:21.34 | Samot | It should be done right. |
| 16:21.35 | Korolev | so I disagree with *i never use asterisk as a billing system* |
| 16:21.41 | Samot | OK |
| 16:21.44 | Samot | I don't. |
| 16:21.50 | Samot | Why put the load on my voice server? |
| 16:22.02 | Korolev | of course not |
| 16:22.03 | Samot | Why does my billing need to be on the same system that does calls? |
| 16:22.08 | Samot | Sounds kinda silly. |
| 16:22.16 | Samot | Oh.. |
| 16:22.39 | Samot | And then there is the "I'm going to push users on Box A through Box Y and then Box Z" |
| 16:22.48 | Samot | Because Y is billing and Z is switching |
| 16:22.50 | Samot | All Asterisk |
| 16:23.01 | Samot | So you know, nine freaking channels for one call. |
| 16:23.24 | Korolev | heh, and call one of them session border controller |
| 16:23.35 | Samot | I use a softswitch |
| 16:23.38 | voipmonk | what? |
| 16:23.38 | Korolev | I'm talking about you adrian, if you are reading :D |
| 16:23.41 | Samot | I use sip proxies. |
| 16:23.45 | voipmonk | Asterisk != SBC |
| 16:23.49 | Samot | My Asterisk servers do one thing... |
| 16:23.52 | Samot | handle calls. |
| 16:24.03 | Samot | All the other crap is on different systems. |
| 16:25.29 | Korolev | well, a routing system is really only one method with a webservice interface |
| 16:25.33 | Korolev | andso is a billing system |
| 16:26.02 | Korolev | all you need is to feed routing data/ read billign data from asterisk |
| 16:26.03 | Kobaz | having a weird issue |
| 16:26.06 | Samot | I use Kamailio. |
| 16:26.16 | Samot | There is no "web service interface" unless I write it. |
| 16:26.19 | Kobaz | chan_sip... i don't have match_auth_username turned on |
| 16:26.26 | Samot | OK. |
| 16:27.10 | Kobaz | INVITE is coming in from a peer, 192.168.181.9, the peer is AudiocodesGW.... the From header: 1344 |
| 16:27.19 | Kobaz | asterisk is matching the invite to peer 1344 |
| 16:27.25 | Samot | Right. |
| 16:27.27 | Samot | As it should. |
| 16:27.28 | Kobaz | that does not have a registered endpoint |
| 16:27.35 | Samot | Doesn't matter. |
| 16:27.36 | Kobaz | match_auth_username=no |
| 16:27.39 | Samot | Do you have a peer? |
| 16:27.43 | Samot | That is FROM |
| 16:27.44 | Kobaz | so it should match the peer ip |
| 16:27.46 | Samot | Not AUTH |
| 16:27.51 | Kobaz | er, right, doh |
| 16:28.08 | Samot | You have a call coming FROM 1344 |
| 16:28.13 | Samot | Which is a peer on that system. |
| 16:28.17 | Kobaz | right |
| 16:28.22 | Samot | So.. |
| 16:28.22 | Kobaz | hmm |
| 16:28.26 | Kobaz | this used to work |
| 16:29.17 | Samot | The endpoints don't need to be registered. |
| 16:29.31 | Samot | They just need existing peer configs. |
| 16:29.38 | Samot | So Asterisk knows, it's a peer. |
| 16:29.53 | Samot | How is the trunk setup? |
| 16:30.00 | Samot | What are the settings in the trunk? |
| 16:30.09 | Samot | And who is first in sip.conf? |
| 16:30.20 | Kobaz | trunk's pretty basic... peeer... host= |
| 16:30.50 | Samot | Where is it in sip.conf |
| 16:30.53 | Samot | Order matters. |
| 16:31.06 | Kobaz | good point |
| 16:31.08 | Samot | It is before the 1344 peer? |
| 16:31.17 | Samot | Which would match first if it's above the other |
| 16:31.48 | Kobaz | right |
| 16:31.49 | Kobaz | yeah |
| 16:31.54 | Kobaz | this system just got rebuild |
| 16:31.56 | Kobaz | *t |
| 16:31.59 | Kobaz | that's probably the issue |
| 16:32.16 | Kobaz | this is someone elses box... i never have this sort of problem because i have things in expected orders |
| 16:32.42 | Kobaz | it's basically "our old asterisk guy went on hiatus and we can't get him to finish this" |
| 16:33.21 | Kobaz | ugh, yeah extensions is loading first |
| 16:36.03 | Kobaz | since our platform doesn't have this sort of issue, my troubleshooting skill for that got forgotten about |
| 16:51.52 | Kobaz | okay |
| 16:51.57 | Kobaz | so, the trunk is up first now |
| 16:52.03 | Kobaz | still matching 1344 |
| 16:52.55 | Kobaz | https://pastebin.com/CT1094b8 |
| 16:53.01 | Kobaz | simple as simple can be |
| 16:53.05 | tzafrir | wim_, regarding my chan_console problem: see https://issues.asterisk.org/jira/browse/ASTERISK-27426 |
| 16:54.37 | Samot | Kobaz: So you're authing incoming calls? |
| 16:54.53 | Samot | Because you don't have insecure there. |
| 16:55.05 | Kobaz | it's ip based |
| 16:55.08 | Samot | So it's matching and wanting to auth incoming calls on that peer. |
| 16:55.14 | Kobaz | i tried insecure=port,invite as well |
| 16:55.14 | Samot | You are still authing. |
| 16:55.39 | Samot | host= just means you expect them to come/go to that IP |
| 16:55.43 | Kobaz | right |
| 16:55.52 | Samot | You can still force an auth |
| 16:55.55 | Kobaz | you could |
| 16:55.57 | Kobaz | but i'm not |
| 16:56.08 | Kobaz | you can still invite to a peer without insecure=port,invite |
| 16:56.14 | Samot | Not having insecure=invite,port does that |
| 16:56.17 | Samot | Right |
| 16:56.18 | Kobaz | if there's no secret specified |
| 16:56.28 | Samot | But then the INVITE will be auth. |
| 16:56.38 | Kobaz | killin me |
| 16:56.40 | Kobaz | i wonder if this is a bug |
| 16:56.41 | Samot | You are confusing letting the IP in.. |
| 16:56.50 | Samot | Vs allowing it to do something. |
| 16:56.51 | Kobaz | they just updated to a new asterisk |
| 16:57.02 | Kobaz | Samot: host= without auth, accomplishes both |
| 16:57.48 | Samot | host=dynamic with insecure=invite,port |
| 16:58.00 | Samot | Means any IP can send a call into Asterisk and not be authed. |
| 16:58.01 | Samot | ANY |
| 16:58.10 | Kobaz | right, hah |
| 16:58.11 | Samot | with that peer as the FROM |
| 16:58.15 | Kobaz | that's umm... one way |
| 16:58.18 | Samot | So host=ip |
| 16:58.34 | Samot | Means that incoming calls from that IP are accepted. |
| 16:58.41 | Kobaz | right |
| 16:58.49 | Samot | Now whether or not you secure that invite |
| 16:58.50 | Kobaz | *and* it also means they are authorized if there's no secret= |
| 16:58.58 | Samot | OK. |
| 16:59.08 | Samot | I don't see debugs of this mis-match |
| 16:59.19 | Samot | Or how this is being handled. |
| 16:59.35 | Kobaz | this is more and more looking like a bug |
| 16:59.39 | Kobaz | doing more experiments |
| 17:00.38 | [sr] | hi, for network sound broadcast, which is the dev library for this? the name is a bit similar with so many |
| 17:01.43 | Samot | ? |
| 17:07.59 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 17:11.48 | Samot | [sR]: The install_prereq should have this |
| 17:12.15 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 17:12.55 | [sr] | Samot: that file exists on the sources? dont see it |
| 17:13.24 | Samot | You run it during the configuration process when you install Asterisk. |
| 17:13.55 | [sr] | im using menuselect to choose options |
| 17:14.08 | Samot | You run it before that |
| 17:14.29 | Samot | It installs any missing prereq's Asterisk needs. |
| 17:14.52 | Samot | Now NBS isn't something that is really needed but it does seem to be in the process. |
| 17:15.04 | Samot | https://github.com/asterisk/asterisk/blob/master/contrib/scripts/install_prereq <-- It's in there. |
| 17:15.22 | Samot | echo "*** Installing NBS (Network Broadcast Sound) ***" <<- Even would have echoed this. |
| 17:21.18 | [sr] | ah cool, |
| 17:21.22 | [sr] | got it |
| 17:21.29 | [sr] | normally i install the packages on my own |
| 17:21.39 | [sr] | the names are normally easy to identify the -dev packages |
| 17:29.43 | [sr] | ahhh this script was helpfull Samot, for lua it required 5.1 version and i was installing 5.3 |
| 17:31.48 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
| 17:45.40 | [sr] | Samot: i dont see much references to mysql here in the module selection |
| 17:45.44 | [sr] | only pgsql/sqlite |
| 17:45.54 | [sr] | is there any ideia to remove mysql from here? |
| 17:46.21 | [sr] | (because is now from oracle, etc etc, the history i already know) |
| 18:06.33 | Samot | I don't know what you are taking about. |
| 18:11.14 | [sr] | Samot: there was a cdr_mysql |
| 18:11.23 | [sr] | and now only exists cdr_adaptive_odbc |
| 18:11.34 | [sr] | ok its going to be configured via odbc |
| 18:11.43 | [sr] | but still exists an cdr_pgsql and cdt_sqlite |
| 18:13.46 | Samot | OK |
| 18:14.02 | Samot | cdr_mysql still exists. |
| 18:14.55 | [sr] | yes but marked as obsolete |
| 18:14.58 | [sr] | deprecated |
| 18:16.03 | Samot | The idea is you really should use ODBC for any connection. |
| 18:16.16 | Samot | For the database. |
| 18:16.36 | Samot | Want to store your CDRs in pgsql, OK. ODBC will handle that. |
| 18:18.30 | [sr] | my case will be mysql |
| 18:18.49 | [sr] | i just asked 'cause only cdr_mysql was marked as deprecated |
| 18:18.58 | [sr] | not cdr_pgsql and cdr_sqlite |
| 18:29.15 | *** join/#asterisk tzafrir (~tzafrir@62-90-199-170.barak.net.il) |
| 18:33.06 | *** join/#asterisk jkroon (~jkroon@165.16.204.167) |
| 18:36.42 | Samot | It's been like that for years. |
| 18:36.46 | Samot | This isn't something new. |
| 18:37.08 | Samot | I think even since 1.8 or at least 10 |
| 18:37.29 | Samot | Or maybe it was 12. |
| 18:37.45 | Samot | But it's been at least 5 years. |
| 18:59.45 | *** join/#asterisk [sID] (~sid@logv.pl) |
| 19:14.07 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 19:32.45 | Samot | SQL ERROR [ mysqli ] |
| 19:32.45 | Samot | Can't connect to MySQL server on '127.0.0.1' (111) [2003] |
| 19:32.49 | Samot | file: ^^^^ |
| 19:33.04 | Samot | http://forums.asterisk.org/viewtopic.php?f=1&t=87826 << When I tried to hit |
| 19:33.31 | file | oh, the old forums |
| 19:34.42 | Samot | Oh |
| 19:34.43 | Samot | OK |
| 19:34.46 | Samot | False alarm. |
| 19:35.28 | file | https://community.asterisk.org is the new place |
| 19:37.01 | file | I opened a ticket internally about it though |
| 19:38.34 | Samot | Yeah, it didn't even register |
| 19:38.41 | Samot | I read it "Eastern" style. |
| 19:38.47 | Samot | I never got to the subdomain. |
| 19:38.58 | Samot | org asterisk "oh shit" |
| 19:39.57 | Samot | <PROTECTED> |
| 19:40.28 | Samot | ^^ What would case that on a t.38 call. I really can't ever recall seeing that error before.. |
| 19:40.42 | Samot | s/case/cause/ |
| 19:41.13 | Samot | I see it related to WebRTC calls but nothing is popping up for T.38 |
| 19:41.35 | file | if the SDP is somehow malformed or the chan_sip SDP parser/negotiator tripped up |
| 19:42.40 | Samot | Better way to tell which side? I'm looking at the SDP it looks ok in the debug. |
| 19:44.34 | file | not really, gotta dig in and I don't remember the chan_sip stuff |
| 19:45.25 | Samot | K. |
| 19:45.36 | Samot | The SDP looks fine in the c= section |
| 19:45.37 | Samot | heh |
| 19:45.39 | Samot | c section |
| 19:46.05 | Samot | But the person is also running 13.17.0 |
| 19:46.08 | Samot | Soooo... |
| 19:46.13 | Samot | That had it's own issues. |
| 19:46.29 | Samot | I would lean on something in the negotiator perhaps. |
| 19:46.56 | file | that T.38 attempt was rejected |
| 19:47.44 | Samot | Yeah. |
| 19:47.49 | Samot | But that error followed. |
| 19:48.03 | Samot | I'm assuming that was the cause of the rejection. |
| 19:48.14 | Samot | wait.. |
| 19:50.28 | [sr] | Samot: maybe from 2012, in v11 still not marked as obsolete |
| 19:50.48 | [sr] | so i'll just update myself to odbc now :) |
| 20:00.50 | *** join/#asterisk imcdona (~imcdona@64.122.164.5) |
| 20:07.40 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 20:08.19 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 20:18.04 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
| 20:19.53 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 20:27.04 | *** part/#asterisk ezra-s (~ezra-s@apache/committer/dferradal) |
| 20:27.40 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 20:27.40 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 20:31.55 | *** join/#asterisk Hyper_Eye (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 20:54.08 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 20:54.08 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 20:58.52 | *** join/#asterisk Yiota (~textual@207.164.151.42) |
| 21:56.18 | *** join/#asterisk bluenemo (~bluenemo@unaffiliated/bluenemo) |
| 21:57.57 | bluenemo | hi guys. This is not exactly an asterisk question but maybe you have an idea. We run a IT company which provides emergency services for SLA customers. We want the customers employees to call us anytime. We however develop the need to authenticate if the person calling really belongs to that company. We are looking for a solution that lets the CEO of our customer distribute and manage a way for his employees to authenticate when calling us. |
| 21:58.53 | bluenemo | So far I thought about something like OTP. Each employee gets its custom QR code which he scans with his phone and we do also on our laptops. When sbd then calls and claims to be this person, we could compare the QR code. |
| 22:03.53 | Samot | Or you can give them a specific "pincode" |
| 22:03.58 | sibiria | SIP accounts aren't enough? |
| 22:04.09 | Samot | This is for inbound calls. |
| 22:04.22 | Samot | So they can verify the caller is with the company under SLA contract. |
| 22:04.55 | Samot | This is basically making an IVR that accepts specific digits to route the call somewhere. |
| 22:05.11 | Samot | Authenticate() could be used as well for a pincode. |
| 22:05.38 | Samot | I'm going to guess this would be a "client wide" code and not a "per end user" code.. |
| 22:06.04 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 22:06.04 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 22:07.04 | *** join/#asterisk zopsi (~zopsi@dir.ac) |
| 22:07.22 | *** join/#asterisk underport (~underport@138.121.100.9) |
| 22:09.12 | *** join/#asterisk Iamnacho (~Iamnacho@ip72-213-55-66.om.om.cox.net) |
| 22:12.36 | *** join/#asterisk sparkmeasure (cfa4e601@gateway/web/freenode/ip.207.164.230.1) |
| 22:12.55 | sparkmeasure | anyone here has experience working with Sangoma Vega gateways? |
| 22:13.55 | *** join/#asterisk cryptic (~cryptic@142.196.170.87) |
| 22:26.10 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 22:26.10 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 22:59.09 | *** join/#asterisk zopsi (~zopsi@dir.ac) |
| 23:02.14 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 23:02.14 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 23:19.28 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 23:29.35 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 23:54.06 | *** join/#asterisk Yiota (~textual@2605:8d80:6c2:baf4:4d3b:a60e:fadc:8d33) |