| 00:23.31 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-ddinhxgplwxexwvf) |
| 01:20.12 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 06:00.58 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 06:00.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:58.55 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:02.26 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:23.11 | *** join/#asterisk-dev ulexus (~ulexus@2601:c6:4101:6b01:2e56:dcff:fe38:7208) |
| 07:53.43 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::10de) |
| 07:58.33 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:58.33 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:24.13 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:41.33 | *** join/#asterisk-dev oej (~oej@h77-53-157-212.cust.se.alltele.net) |
| 08:41.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:15.19 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 09:24.53 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 09:35.44 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 11:09.32 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 11:46.49 | file | Wednesday! |
| 11:47.08 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 11:51.43 | seanbright | yeshhhhh |
| 11:53.31 | file | are you prepared for it? |
| 11:53.42 | seanbright | of course not |
| 11:54.21 | file | very good |
| 11:54.38 | seanbright | but i'm having greek yogurt and coffee |
| 11:54.41 | seanbright | so things are looking up |
| 11:55.13 | seanbright | so why do these build keeps failing? |
| 11:56.27 | seanbright | ah. originate_to_dialplan/non_local_channels |
| 12:01.14 | file | yes, there are unrelated test race condition failures |
| 12:39.51 | *** join/#asterisk-dev dustinm (~dustinm@68.ip-149-56-14.net) |
| 12:43.37 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 12:47.45 | *** join/#asterisk-dev newtonr (~newtonr@173-17-133-211.client.mchsi.com) |
| 12:47.45 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:52.13 | tsearle | hey |
| 13:52.28 | tsearle | for an identify section in pjsip |
| 13:52.37 | tsearle | is there a way to make it also identify based on port? |
| 13:52.48 | file | not currently |
| 13:53.17 | tsearle | I have ast testsuite tests that are sipp instances running on different ports, worked with the old peer logic |
| 13:55.17 | tsearle | perhaps I can adapt and use 127.0.0.1 127.0.0.2 127.0.0.3, etc, instead |
| 14:02.22 | file | that's what tests in the testsuite do afaik |
| 14:19.30 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-uciupdjlnusarywf) |
| 14:19.30 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:21.21 | ulexus | So, I've implemented mute and dtmf_passthrough configuration support into ARI's AddChannel (to bridge) according to @mjordan's post (https://community.asterisk.org/t/how-to-stop-dtmf-tones-being-heard-in-bridge/67618/4). It works, and everything is great, but I'm pretty certain I'm doing something wrong with the cleanup routine. I'm guessing there is likely a simple solution. |
| 14:21.38 | ulexus | Anyone able to offer a suggestion? |
| 14:22.59 | ulexus | The issue revolves around code in bridge.c objecting strongly if the bridge_features struct is cleaned before it does its _own_ cleanup. |
| 14:24.47 | ulexus | Code is https://github.com/Ulexus/asterisk, since I don't (yet) have access to Gerritt |
| 14:26.31 | ulexus | Specifically, reference my node at control.c:101 |
| 14:26.36 | ulexus | node->note |
| 14:37.23 | coreyfarrell | ulexus: have you filled out the license agreement? link at top of https://issues.asterisk.org/ |
| 14:38.18 | ulexus | Yes |
| 14:42.04 | ulexus | It was just last night, so I doubt legal has reviewed it yet; I had tried before, but it was rejected for business/personal email conflict. |
| 14:44.07 | file | yeah, probably hasn't yet |
| 14:44.46 | file | hum |
| 14:49.30 | file | ulexus: when impart is used you have to allocate a features using ast_bridge_features_new() and once imparted the owner of it is the bridge - you can't modify/destroy it |
| 14:51.48 | file | so either you'd have to generate the features before calling impart based on stored details, or once impart is done create a new features in the control structure since the old one can't be touched |
| 14:53.29 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:53.29 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:58.00 | cresl1n | waves |
| 14:58.08 | file | cresl1n: haylo |
| 14:58.13 | cresl1n | gerrit oh gerrit, why must you forget me so soon⦠|
| 14:58.26 | file | perhaps you are easily forgettable |
| 15:07.30 | cresl1n | meanie. |
| 15:10.51 | cresl1n | Hey file, why's the "<unknown>" state in brackets in your cli patch for core show channel |
| 15:11.08 | file | because I copy/pasted it from the media type 2str implementation :D |
| 15:11.20 | cresl1n | O-kay. |
| 15:11.41 | cresl1n | prior art |
| 15:19.19 | ulexus | @file thanks; I have no need of modifying it, but according @mjordan's post, it's supposed to be cleaned up in control_dtor(). If that's not necessary, all is well. As you said, the bridge cleans it up itself. |
| 15:20.21 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-184-179-14-87.ph.ph.cox.net) |
| 15:20.23 | file | yup yup |
| 15:21.04 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-nymcgrcmbmhrghzy) |
| 15:21.04 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:21.19 | ulexus | Perfect, thanks. As soon as I get gerritt access, then... |
| 15:24.33 | seanbright | so realloc() returns NULL on failure |
| 15:24.40 | seanbright | is the original memory freed in that case? |
| 15:27.20 | kharwell | seanbright: I believe the original memory is left as is and not freed |
| 15:29.41 | seanbright | got it |
| 15:29.41 | seanbright | thanks |
| 15:30.05 | seanbright | so 'foo = realloc(foo, ...);' is a bug |
| 15:31.32 | kharwell | seems it would be so yes unless there was another pointer to the original memory |
| 15:31.36 | seanbright | right |
| 15:37.17 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-qlvcfuxjanpqwfyf) |
| 15:37.17 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:38.08 | tsearle | If you call PJSIP_HEADER in a normal dialplan context you'll be operating on the caller's (incoming) channel which may not be what you want. To operate on the callee's (outgoing) channel call PJSIP_HEADER in a pre-dial handler. |
| 15:38.11 | tsearle | *me cries* |
| 15:38.31 | seanbright | yup. that bit me too early on. |
| 15:38.51 | tsearle | well I have all this nice exec(SIPAddHeader) in agi |
| 15:39.18 | tsearle | so I guess I now need to set a _VARIABLE channel vars |
| 15:39.32 | tsearle | and look at that in a pre-dial |
| 15:39.45 | tsearle | I realy don't want to have to invoke agi twice, heh |
| 15:39.54 | seanbright | well we can change how asterisk works if you want |
| 15:40.12 | seanbright | not really though |
| 15:47.47 | *** join/#asterisk-dev sh_smith (foobar@cpe-76-174-26-91.socal.res.rr.com) |
| 15:58.39 | tsearle | is there any good way to make a channel variable array (like the _SIPHEADER[0-XXX] in the dialplan? |
| 16:00.58 | tsearle | basicly a way from the incoming context to pass a list to the pre-dial handler |
| 16:06.32 | tsearle | ok PUSH(_LIST, "header") should do the trick I guess |
| 16:11.10 | *** join/#asterisk-dev stkoch (~stefan@p20030085AE137B00DE5360FFFE7FBA5C.dip0.t-ipconnect.de) |
| 16:12.58 | stkoch | Hi, how to detect within a asterisk channel driver if asterisk or provider is self genrating dial tones (like within DIAL() call the 'r' option is set or not) ? |
| 16:17.44 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:17.44 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:29.07 | cresl1n | stkoch: I don't know of a way to do it within the dialplan |
| 16:35.13 | stkoch | cresl1n: I have ported this driver to ast11/ast13: https://github.com/kochstefan/asterisk_channel_lantiq |
| 16:35.47 | stkoch | If the provider plays an error message like invalid number I hear the ringtone because it's played by the lantiq firmware |
| 16:36.54 | stkoch | So I though that the best thing would to detect 'r' setting within DIAL, an other option would to add an config option to disable the tone generating by firmware |
| 16:37.22 | cresl1n | if the lantiq firmware is overwriting inband media, you'll have to detect it somewhere in the lantiq, no? |
| 16:40.05 | stkoch | cresl1n: I hear both the error message 'invalid number' and ringing tone |
| 16:42.50 | stkoch | cresl1n: could I detect within the channel that inband media is played? |
| 16:43.26 | cresl1n | I don't know if I understand the problem |
| 16:49.42 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-136-223.red.bezeqint.net) |
| 16:49.42 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 16:50.25 | stkoch | cresl1n: thanks |
| 17:03.25 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-229-241.w92-135.abo.wanadoo.fr) |
| 17:04.09 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 17:04.09 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 17:11.12 | kharwell | file: unfortunately the fix you put in for the libasteriskssl didn't work. It appears DESTDIR is empty at the time of the check |
| 17:11.27 | tsearle | when setting _VARIABLE in the dial plan, it will become VARIABLE (w/o) underscore in the pre-dial handler correct? |
| 17:11.27 | file | oh geez |
| 17:11.33 | file | tsearle: yes |
| 17:11.44 | file | kharwell: I GIVE UP |
| 17:13.13 | file | reverts are up |
| 17:13.13 | kharwell | ASTLIBDIR does have the needed path though? |
| 17:13.25 | file | I'm giving up on it for now :P |
| 17:14.29 | file | I'll pawn it off on gtjoseph |
| 17:14.35 | tsearle | SET VARIABLE PUSH(_SIP_HEADERS, \t) "X-VCC-Destination: sip:3200000001@127.0.0.1;transport=tcp;lr" |
| 17:14.41 | tsearle | I'm sending that in AGI |
| 17:14.54 | gtjoseph | what are you pawning off??? |
| 17:15.07 | tsearle | but SIP_HEADERS is empty string in predial |
| 17:15.09 | file | gtjoseph: the stupid annoying libasteriskssl issue |
| 17:15.23 | gtjoseph | gee thanks |
| 17:19.30 | tsearle | actually it seems like push isn't working at all |
| 17:19.41 | tsearle | am I doing something wrong in the syntax? |
| 17:21.28 | file | has never used PUSH |
| 17:23.39 | tsearle | my challenge is I want to set an arbitrary number of headers in agi before calling Dial, this was easy in chan_sip |
| 17:23.55 | tsearle | I'm trying to use push, pop + predial handler to emulate that |
| 17:24.09 | tsearle | if you have an idea of an easier way, please tell me :-P |
| 17:30.53 | *** join/#asterisk-dev oej (~oej@212.181.100.70) |
| 17:30.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:31.34 | file | not off the top of my head I'm afraid |
| 17:32.24 | tsearle | well, I'm going to assume PUSH is broken, and build the tab delimited list in the AGI |
| 17:32.30 | tsearle | see if that goes better |
| 17:33.55 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-13.wall.uls.co.za) |
| 17:53.57 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-184-179-14-87.ph.ph.cox.net) |
| 17:59.30 | tsearle | well POP seems to be working, having some trouble with the delimitor though, guess I'll dig tomorrow |
| 18:17.44 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-184-179-14-87.ph.ph.cox.net) |
| 18:31.50 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-184-179-14-87.ph.ph.cox.net) |
| 19:16.22 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d009dcb8dd576f72f3b.ipv6.abo.wanadoo.fr) |
| 20:48.33 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 21:18.02 | seanbright | so what exactly is binaural synthesis? |
| 21:18.05 | seanbright | and why should i care? |
| 21:22.37 | gtjoseph | If the listener is using a stereo capable codec and device and is In a multi-party bridge, the code will make speakers sound as though they are in different locations |
| 21:26.00 | seanbright | ohhh |
| 21:26.03 | seanbright | ok, that's pretty fancy |
| 21:27.18 | gtjoseph | It's a POC and part of Frank Haase's and and Dennis Guse's dissertations. |
| 21:28.00 | gtjoseph | Taken to its fullest potential, it could be pretty snazzy when combined with video |
| 22:45.23 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 22:45.23 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:57.08 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 23:57.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |