| 00:11.11 | *** join/#asterisk gregf (~gregf@unaffiliated/gregf) |
| 00:21.31 | *** join/#asterisk Gugge (gugge@guggemand.dk) |
| 00:38.34 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 01:18.46 | *** join/#asterisk catphish_ (~charlie@unaffiliated/catphish) |
| 01:19.56 | *** join/#asterisk friedrich (~friedrich@aextron.de) |
| 01:19.59 | *** join/#asterisk drc (~drc@stratum0/entity/drc) |
| 01:20.14 | *** join/#asterisk electronic_eel (~quassel@electroniceel.org) |
| 01:21.19 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 01:22.35 | catphish_ | is there an easy way to detect whether i have a caller id that can be presented to a user? the only way i've found is to look at the first few characters of CALLERID(pres) which seems messy |
| 01:24.58 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 01:26.59 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 01:33.53 | Samot | Callerid(name) callerid(num) callerid(all) |
| 01:40.54 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 01:46.58 | igcewieling | catphish_: depends on a few thiings, but pres is as good as any |
| 01:47.52 | igcewieling | Should 2 hosts connected to the same switch with gig ethernet ports, get more than 30MB/s ? It seems to me that it should. |
| 01:48.03 | igcewieling | using FTP |
| 01:48.18 | catphish_ | Samot: callerid(num) seemed to have the number even when presentation was disallowed |
| 01:48.38 | catphish_ | igcewieling: the pres string seem to work anyway |
| 01:48.51 | Samot | Is this SIP? |
| 01:48.55 | catphish_ | Samot: yes |
| 01:49.06 | Samot | Then that setting doesn't matter. |
| 01:49.41 | catphish_ | i don't understand, why wouldn't it matter? |
| 01:49.43 | igcewieling | It will be set based on Privacy header if you trust the privacy header. |
| 01:49.59 | Samot | Because CALLERID(pres) is a PRI/analog thing. |
| 01:50.03 | igcewieling | same way CallerID is set from PAID if you trust PAID. |
| 01:50.11 | catphish_ | igcewieling: yes, i trust and send privacy headers |
| 01:50.25 | Samot | SIP is going to use From, PAI or RPID. |
| 01:50.40 | Samot | By default Asterisk reads from the From header |
| 01:50.43 | igcewieling | if all else fails, check the privacy headers instead of the tech agnostic pres |
| 01:50.48 | Samot | You have to get the PAI header and parse it. |
| 01:51.10 | catphish_ | Samot: right, i'm using PAI, but i need to check the privacy setting |
| 01:51.10 | Samot | You need to get Privacy and PAI to use them. |
| 01:51.27 | Samot | That's not what I'm saying at all |
| 01:51.35 | Samot | There is no "incoming PAI" setting |
| 01:51.59 | Samot | An incoming call to Asterisk uses the from header by default for the CallerID or the callerid= setting on the endpoint. |
| 01:51.59 | igcewieling | Samot: um, trust_id_inbound=yes |
| 01:52.46 | Samot | Yes, that ignored the callerid= setting on the endpoint. |
| 01:53.47 | catphish_ | let me start over, i'm using trust_id_inbound, i receive a number, and a privacy setting, what i want to do is test whether the number is allowed to be presented to my end user or not |
| 01:54.04 | Samot | They you need to look for the privacy settings the carrier sends. |
| 01:54.12 | catphish_ | callerid(num) always contains the number |
| 01:54.12 | Samot | If that is Privacy, you need to look at that header |
| 01:54.17 | igcewieling | nevermind about that FTP bandwidth comment. I just realized one of the NICs might be GigE, but it is still connectd with USB |
| 01:54.29 | Samot | catphish_: Because that is in the FROM header. |
| 01:54.39 | Samot | Did you look at the actual SIP message? |
| 01:54.48 | igcewieling | catphish_: Privacy: none = allowed Privacy: id = block |
| 01:55.07 | catphish_ | yeah, checking the header will work i guess |
| 01:55.31 | Samot | Just like you need to get the PAI header to use P-Asserted for CallerID |
| 01:55.35 | *** join/#asterisk AsteriskRoss (~AsteriskR@37.157.48.2) |
| 01:55.37 | catphish_ | callerid(pres) *is* set, but i was just hoping there was a correct protocol agnostic boolean i could check |
| 01:55.38 | Samot | Because by default Asterisk pulls the FROM header. |
| 01:56.10 | igcewieling | catphish_: the values are too complicated for something like that, mostly because it origianlly was designed for PRI |
| 01:56.33 | catphish_ | makes sense, there are values i don't really understand, like the screened stuff |
| 01:56.33 | Samot | Yes, a lot of the CALLERID() options are PRI/POTS |
| 01:56.48 | Samot | Which doesn't apply to how SIP does CallerID/Privacy |
| 01:57.05 | catphish_ | i'll look at the privacy header, that's the simpest / most reliable option here |
| 01:57.17 | Samot | But if you're using PAI, you need that too. |
| 01:57.31 | Samot | Specially if the PAI is different from the FROM header. Which is totally possible. |
| 01:57.38 | catphish_ | i don't know if asterisk is setting things from rpid or pai, i receive both, and it works |
| 01:57.54 | catphish_ | it's not set from the FROM header |
| 01:57.55 | Samot | You have to grab the header and parse it. |
| 01:58.02 | igcewieling | catphish_: assuming SIP only, I'd think the CALLERID(pres) values should be only one of two values, but you'd have to verify that. |
| 01:58.02 | Samot | OK. |
| 01:58.22 | catphish_ | asterisk is definitely parsing one of those headers for me |
| 01:58.28 | Samot | The FROM header |
| 01:58.33 | Samot | Since it's the only standard header. |
| 01:58.43 | catphish_ | because incoming caller id works, even when the FROM header is blanked by the peer |
| 01:58.46 | igcewieling | Samot: you are not going to extract presentation info from the From header. |
| 01:58.51 | Samot | There's no guarantee of PAI or RPID or any other method. |
| 01:58.55 | Samot | JFC |
| 01:58.58 | Samot | It's a PRI setting. |
| 01:59.00 | Samot | So forget it. |
| 01:59.03 | Samot | It is not for SIP |
| 01:59.20 | Samot | Don't latch on to things not meant for this tech. |
| 01:59.33 | Samot | Just because it has a value doesn't mean it's the right one. |
| 01:59.59 | Samot | It doesn't seem a SIP trace was done to look at the actual SIP message to see what is set where. |
| 02:00.44 | Samot | Because if I make a call from my Polycom... |
| 02:00.52 | Samot | I have trust_id_inbound=yes |
| 02:01.16 | Samot | So the CallerID set in my Polycom (in the from header) is what is grabbed by CALLERID(all) |
| 02:01.46 | Samot | At the SIP proxy I add PAI headers, those have to be grabbed and parsed by Asterisk to set the CallerID to the proper name. |
| 02:01.59 | Samot | Or what I want the CallerID to be for that user. |
| 02:02.00 | catphish_ | as i said, i know that callerid(num) and callerid(pres) are set based on rpid, or pai and privary, i don't know which because both are set the same |
| 02:02.15 | Samot | And I'm telling you none of those are required. |
| 02:02.23 | Samot | That don't have to sent at all |
| 02:02.28 | Samot | They don't exist 100% of the time. |
| 02:02.35 | Samot | So it is not the default thing Asterisk uses. |
| 02:02.42 | Samot | FROM is default. It's 100% always there. |
| 02:02.47 | catphish_ | sure, if they're missing, it'll use FROM |
| 02:02.54 | Samot | No. |
| 02:03.00 | Samot | But I digress. |
| 02:03.03 | catphish_ | no? |
| 02:03.08 | Samot | I just told you that. |
| 02:03.15 | Samot | Phone -> Proxy -> Asterisk |
| 02:03.24 | Samot | Proxy adds PAI headers for CallerID |
| 02:03.36 | Samot | Asterisk pulls FROM header for CallerID(name) and CallerID(num) |
| 02:03.37 | catphish_ | what's that go to do with asterisk? |
| 02:03.44 | Samot | See my last statement |
| 02:03.53 | Samot | It doesn't use the PAI header |
| 02:03.55 | catphish_ | it uses PAI or RPID, i promise |
| 02:03.59 | Samot | Show me. |
| 02:04.10 | Samot | Show me a SIP message with that and how Asterisk is setting that |
| 02:04.17 | Samot | And that it is 100% different from the FROM header. |
| 02:05.24 | catphish_ | no, because if i do, you'll try to claim you meant something else |
| 02:05.28 | catphish_ | so i'd be wasting my time |
| 02:05.30 | Samot | No I won't. |
| 02:05.42 | Samot | I've been doing this for a very long time. I would like to see what I and others have been missing |
| 02:06.01 | Samot | Because if this is the case, my testing of all my systems was fucked and I can remove sub routines. |
| 02:06.10 | Samot | So it would actually be beneficial. |
| 02:06.11 | catphish_ | to clarify, you're telling me that if my FROM header reads "anonymous@invalid" i will not have a callerid(num)? |
| 02:06.25 | Samot | You'll have anonymous |
| 02:06.32 | Samot | Or restricted |
| 02:06.35 | catphish_ | because i'm 99% sure you're wrong |
| 02:06.37 | catphish_ | but i'll check |
| 02:06.38 | Samot | OK |
| 02:10.41 | Samot | https://www.irccloud.com/pastebin/3epjFLFo/ |
| 02:10.56 | Samot | Note the different in the FROM user to the CallerID Number.... |
| 02:11.52 | catphish_ | Samot: this is my INVITE https://i.imgur.com/6Eh5JaD.png |
| 02:12.42 | catphish_ | and i can assure you that CALLERID(num) contains the redacted number |
| 02:13.19 | Samot | Hang on now. |
| 02:13.28 | Samot | Because I'm about to stand corrected. |
| 02:13.43 | catphish_ | when trust_id_inbound=yes, rpid is used when available instead of from |
| 02:14.04 | catphish_ | (or possibly PAID, i'm not sure which) |
| 02:14.51 | Samot | I think there was some updates on behavior. Because yes, I can confirm that. |
| 02:14.51 | catphish_ | what did you get in your test with PAID? |
| 02:15.12 | catphish_ | ah, good, glad i'm not crazy :) |
| 02:15.20 | Samot | No, which is actually better for me. |
| 02:15.32 | Samot | There, see I was not going to say I meant something else. |
| 02:15.44 | Samot | I said what I meant and I wanted to be shown otherwise. I was. |
| 02:16.04 | catphish_ | the good part is that asterisk also sets callerid(pres) and witholds it from untrusted peers |
| 02:16.17 | Samot | So this wasn't always the way but I haven't tested this against current versions because it's low on the list of what to check because it was just working. |
| 02:16.47 | catphish_ | Samot: thank you, i dislike such arguments, they usually result in people claiming they meant something else, and me wasting 10 minutes testing :) |
| 02:17.34 | catphish_ | but as you said, "pres" is a poorly specified concept, and a string, so i dislike relying on it in my own code |
| 02:17.45 | catphish_ | but it is working |
| 02:18.41 | Samot | Yeah but now I can rip out this gosub. |
| 02:18.47 | catphish_ | :) |
| 02:18.58 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 02:20.08 | catphish_ | i have this right now, to record a customer-visible copy of the callerid: https://paste.ubuntu.com/p/WDV7BSz5h7/ |
| 02:20.22 | Samot | And also why Chan_PJSIP > Chan_SIP. |
| 02:20.41 | catphish_ | yeah, i've had a few nice surprises since upgrading to pjsip |
| 02:21.00 | catphish_ | the main ones being multiple registrations, and non-shit realtime |
| 02:22.36 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 02:23.50 | catphish_ | my new web interface is primative so far, but showing response times for each registration is very cool https://i.imgur.com/SxFoQdk.png |
| 02:24.41 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 02:26.07 | catphish_ | and realtime let me sync those registrations between 2 hosts using mysql replication and avoid the (imo greater) complexity of using kamailion in this deployment |
| 02:26.36 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 02:32.50 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 02:34.09 | Samot | I like the fact Kamailio takes load off Asterisk. |
| 02:35.21 | Samot | And gives me more control |
| 02:37.43 | Samot | Oh and allows for call failover better since it stays one channel in Asterisk and Im not cycling Dial() processes |
| 02:38.41 | Samot | Allowing for proper LCR routing and upstream failover |
| 02:39.15 | Samot | And one call = one CDR |
| 02:40.46 | catphish_ | yep, there's definitely benefits in some setups |
| 02:41.20 | catphish_ | mine is simple enough that i don't think i need it |
| 02:43.16 | Samot | I can also see who hung up with a bunch of extra Dialplan. And process SIP replied properly and not what Asterisk thinks they should be |
| 02:43.31 | Samot | Without |
| 02:45.04 | catphish_ | oops, it's nearly 3am, i sleep now, thanks! |
| 02:56.08 | *** join/#asterisk tsal_ (~tsal@i59F52F34.versanet.de) |
| 03:27.48 | *** join/#asterisk Dovid (~dovid@96.56.22.146) |
| 03:54.57 | *** join/#asterisk fling (~fling@fsf/member/fling) |
| 04:10.53 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 04:14.56 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 04:32.32 | *** join/#asterisk shalzz (shalzzjmat@gateway/shell/matrix.org/x-piucekzhlfqnnddd) |
| 04:33.29 | shalzz | Hi, can I use a simcom lte modules with asterisk? |
| 04:33.41 | shalzz | Which channel driver do I need? |
| 04:34.48 | shalzz | I could only find out the simcom modules can be controller via AT commands |
| 04:34.59 | shalzz | does asterisk have a channel driver using AT commands? |
| 04:40.00 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 04:40.06 | igcewieling | shalzz: no. |
| 04:41.02 | shalzz | igcewieling Thanks, Is there any other way of controlling simcom modules with asterisks? |
| 04:41.46 | igcewieling | control them? yes, you could use an agi script and access the serial port of the system. Use them for voice calls? I doubt it, |
| 04:42.16 | shalzz | or maybe any other production quality software to use with simcom and not just one off scripts for sms/call redirect |
| 04:42.53 | shalzz | Hmm... I mostly need to read sms and maybe setup sip calls |
| 04:43.29 | shalzz | but reading sms and forwarding to an email is higher priority for me |
| 04:46.40 | shalzz | I'm particularly looking to use this: https://www.waveshare.com/wiki/SIM7600G-H_4G_for_Jetson_Nano |
| 04:52.27 | igcewieling | most of that sounds like sometihng totally outside of Asterisk |
| 05:35.02 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 05:38.43 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
| 05:44.23 | shalzz | Hmm.. I see. Thanks anyways |
| 05:45.08 | shalzz | I'll try and use a huwaei dongle instead, but somehow it's drawing more power than my jetson can handle... |
| 06:21.11 | *** join/#asterisk AsteriskRoss (~AsteriskR@37.157.48.2) |
| 06:46.18 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 06:47.43 | *** join/#asterisk maristo (~maristo@109.174.114.229) |
| 07:23.06 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 08:25.22 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 09:24.34 | *** join/#asterisk GoldenBear (~gb@titan.pathogen.is) |
| 09:28.17 | *** join/#asterisk GoldenBear (~gb@172.83.42.132) |
| 10:01.34 | *** join/#asterisk maximCH (~maximCH@mail.swill.org) |
| 10:05.09 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 11:04.10 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 11:57.12 | *** join/#asterisk hvxgr (~wl2v_usrn@epjdn.zq3q.org) |
| 12:38.54 | *** join/#asterisk ghoti (~paul@dsl-rb-64-118-22-154.wtccommunications.ca) |
| 14:15.26 | *** join/#asterisk maristo (~maristo@109.174.114.229) |
| 14:33.35 | *** join/#asterisk fstd (~fstd@unaffiliated/fisted) |
| 15:05.41 | *** join/#asterisk retentiveboy (~retentive@2601:cf:4500:5ea0:7aa4:e0bd:9b53:71a8) |
| 15:06.43 | igcewieling | looks like chan_dongle isn't supported in 16.x |
| 15:07.46 | Samot | Or its noload |
| 15:08.20 | *** join/#asterisk Ravenheart (~Ravenhear@82-137-78-53.ip.btc-net.bg) |
| 15:08.47 | Samot | https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Deprecations |
| 15:09.22 | file | chan_dongle is not in tree |
| 15:09.28 | igcewieling | I did an ls chan_*.c in the channels/ dir. |
| 15:09.58 | Samot | Oh yeah its an add on right |
| 15:10.10 | Samot | Its outside of Asterisk |
| 15:11.01 | igcewieling | where do people get it from? |
| 15:11.34 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:74e2:8a35:3b8c:b319) |
| 15:12.46 | *** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com) |
| 15:14.01 | Samot | No clue |
| 15:14.15 | Samot | Not a thing I was ever using |
| 15:17.17 | Kobaz | poor chan_sip getting removed in 21.. long live chan_sip |
| 15:35.06 | Samot | No. |
| 15:47.51 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 16:06.58 | *** join/#asterisk gregf (~gregf@unaffiliated/gregf) |
| 16:50.51 | DanFromUK | Hi. Can anyone recommend an external SIP availability monitoring company? Our previous monitoring company recently closed their services for some unknown reason. |
| 16:51.53 | DanFromUK | SIP monitoring = monitoring that Asterisk is responding to packets. More detailed monitoring is performed within the datacentre, so we only need external for basic availability checking. |
| 16:55.37 | igcewieling | DanFromUK: Nope. Have you considered an inexpensive virtual machine with GCS or AWS and monitor it yourself? |
| 16:57.07 | DanFromUK | igcewieling: I have considered it, but not gotten past that as it would involve maintaining another server and finding/configuring the software. So if theres an out-of-the-box solution that's around $20 a month or less, it's more preferable, simply to save admin time. |
| 16:57.55 | igcewieling | *nod* |
| 17:08.15 | drmessano | DanFromUK: You just need a YES/NO confirmation that SIP is working from the outside? |
| 17:08.22 | DanFromUK | Yes |
| 17:08.38 | drmessano | Spin up a VM, load monit on it, and spend 5 mins configuring it |
| 17:08.41 | drmessano | Ez Pz |
| 17:09.05 | drmessano | So like $5 a month |
| 17:09.07 | drmessano | or less |
| 17:09.27 | sibiria | ez pz indeed, but the weight of "one more thing to manage and keep track of" is always concern |
| 17:09.33 | sibiria | +a |
| 17:10.39 | DanFromUK | I wasn't aware of monit. We use zabbix internally, but it config on that is a little more involved than we need for the purpose of external monitoring. |
| 17:11.19 | drmessano | Other than the 10 lines of config, it's a few lines to monitor SIP |
| 17:11.46 | DanFromUK | It won't have any more access to our production network than any other internet user, so running a VM, even if we forget to install security updates won't expose us to more risk than we are already exposed to. |
| 17:11.52 | DanFromUK | drmessano: thanks. I'll take a look at it. |
| 17:12.11 | drmessano | https://mmonit.com/monit/documentation/monit.html#SIP |
| 17:13.12 | DanFromUK | awesome. looks great. now to find a suitable VM provider... |
| 17:13.12 | Samot | I need to figure out a SIP probe for The Dude |
| 17:13.20 | DanFromUK | Have a good day everyone. |
| 17:13.36 | drmessano | Samot: I use TCP and TLS probes. The UDP was too much work |
| 17:13.44 | Samot | I hear Hetzner is awesome. |
| 17:14.06 | Samot | For two hours straight. Last night. |
| 17:14.17 | drmessano | sibiria: I can't imagine a single app like monit on a basic VM is that much to maintain |
| 17:16.44 | sibiria | the concern of the machine/instance is one more item on the check list |
| 17:17.14 | sibiria | zabbix can do SIP, btw. |
| 17:17.30 | drmessano | 1. He was asking for an OUTSIDE monitor |
| 17:17.35 | drmessano | 2. Wanted something simple |
| 17:17.44 | drmessano | This is simple and not a full NMS |
| 17:20.22 | DanFromUK | Yes, I'm happy with drmessano's suggestion. |
| 17:21.10 | electronic_eel | hmm, good monitoring is on my todo as well. but i'm more thinking of something that actually does a call through some other sip provider |
| 17:21.44 | electronic_eel | including accepting the call on my side, playing some tones, decoding them on the montioring machine to check that i actually get audio through |
| 17:22.06 | sibiria | how is Monit not an NMS? |
| 17:22.23 | *** join/#asterisk rpifan (~rpifan@p200300d2672b5d00a37456e8d6bd1bdf.dip0.t-ipconnect.de) |
| 17:22.25 | sibiria | peas in a pod, but different approach to configuring them |
| 17:22.42 | drmessano | No |
| 17:22.55 | sibiria | electronic_eel: we do this as part of a live integration test that runs 24/7 |
| 17:23.02 | drmessano | Again, it's like 5 mins of config, less than 15 lines to check SIP and send an email |
| 17:23.07 | drmessano | A script would be more work |
| 17:23.13 | electronic_eel | sibiria: what program do you use for that? |
| 17:23.28 | drmessano | It's not like installing Zabbix and it's not a full NMS |
| 17:23.31 | drmessano | So no |
| 17:24.13 | sibiria | you don't need to script this with zabbix |
| 17:24.52 | drmessano | He wants to monitor from the outside. His Zabbix is inside. Guess you missed that all 3 times it was mentioned |
| 17:25.00 | sibiria | no |
| 17:25.38 | sibiria | electronic_eel: a shell script of our own that produces a call file and then inspects the result. the asterisk context managing the call handles recording of the call and reporting of what goes out and comes back in from the call |
| 17:26.45 | sibiria | i.e. it spits out RTPQoS details, AMD analysis, DTMF events etc. |
| 17:27.14 | electronic_eel | sibiria: do you have something like an "audio-diff" that compares the audio coming back to what should be there, accounting for small time deviations and so on? |
| 17:28.14 | sibiria | electronic_eel: no, it doesn't concern itself with the line quality other than reacting to the QoS output if its shows there's no audio coming back at all |
| 17:28.39 | sibiria | network monitoring is outside its scope |
| 17:29.00 | drmessano | That seems useless then |
| 17:29.11 | electronic_eel | i had some issues in the past with the sip provider just playing some stupid announcement instead of letting the call through. monitoring should catch that |
| 17:29.17 | sibiria | yeah lol, totally useless to know if our platform is performing and behaving the way it's developed to do |
| 17:29.35 | drmessano | For what was requested, it's completely useless |
| 17:29.46 | sibiria | stop arguing just for the sake of arguing, man :D |
| 17:29.54 | drmessano | Excuse me? |
| 17:29.56 | sibiria | i know, it's sundat, but still |
| 17:30.12 | drmessano | You seem to be the fucking argumentative one, even after the dude accepted the suggestion |
| 17:30.16 | drmessano | So go fly a kit |
| 17:30.17 | drmessano | So go fly a kite |
| 17:31.01 | sibiria | electronic_eel: part of our integration test does echo testing for the AMD analysis, and it also does DTMF in two steps, one being rfc4733 and the other being in-audio |
| 17:31.50 | electronic_eel | what does "amd analysis" stand for? |
| 17:32.20 | sibiria | AMD, answering machine detection. in our case a DSP thingamajig counting words and detecting fixed tones |
| 17:33.06 | electronic_eel | thanks |
| 17:33.36 | electronic_eel | hmm, so i still have to look for some program to do the audio-diff part |
| 17:33.37 | sibiria | this integration test runs directly towards our system, we don't terminate the call through an external provider or via the PSTN (though we do test provider availability as part of other tests) |
| 17:33.53 | *** part/#asterisk igcewieling (~ewieling@199.27.202.86) |
| 17:44.40 | *** join/#asterisk paulgrmn__ (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 17:46.03 | sibiria | electronic_eel: you can use e.g. wavdiff or so for that. sox can possibly also do it and report a percentual difference instead of producing a waf differential |
| 17:46.35 | electronic_eel | thanks, i will put them on my to-check list |
| 19:39.00 | *** join/#asterisk paulgrmn__ (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 20:40.48 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 21:06.56 | *** join/#asterisk paulgrmn__ (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 21:54.28 | *** join/#asterisk bmg505 (~leon@8ta-146-7-37.telkomadsl.co.za) |
| 22:23.26 | *** join/#asterisk maximCH (~maximCH@mail.swill.org) |
| 23:35.53 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 23:38.02 | *** join/#asterisk paulgrmn__ (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
