| 00:25.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.186) |
| 00:35.14 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 01:25.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.253) |
| 01:35.13 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 02:25.16 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.193) |
| 02:35.15 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:06.34 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-vptatsmihvfzttpo) |
| 03:16.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.28) |
| 03:35.26 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:45.34 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.28) |
| 04:35.11 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 05:13.21 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.236) |
| 05:14.05 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@193.33.185.132) |
| 05:35.11 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:35.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 07:07.26 | *** join/#asterisk-dev coreyf1513 (~cfarrell@2001:4830:117f:3:4cdc:3087:38f8:15f3) |
| 07:24.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@94.228.240.93) |
| 07:35.10 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 07:35.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.211) |
| 07:36.31 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@94.228.240.93) |
| 07:44.14 | *** join/#asterisk-dev vlad_starkov (~vlad_star@94.228.240.93) |
| 07:49.04 | *** join/#asterisk-dev vlad_starkov (~vlad_star@94.228.240.93) |
| 07:52.59 | *** join/#asterisk-dev MrTAP (~Trev@S010610bf48e6f880.gv.shawcable.net) |
| 07:54.17 | MrTAP | I have a fix for a long time Asterisk bug involving static realtime peers. Could someone with the ability to accept my patch take a look at it? https://issues.asterisk.org/jira/browse/ASTERISK-17523 |
| 07:55.15 | *** join/#asterisk-dev vlad_starkov (~vlad_star@94.228.240.93) |
| 08:06.49 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:80ba:2bf4:d6bd:1c08) |
| 08:08.53 | *** join/#asterisk-dev vlad_starkov (~vlad_star@94.228.240.93) |
| 08:13.11 | *** join/#asterisk-dev vlad_starkov (~vlad_star@94.228.240.93) |
| 08:23.25 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:35.10 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 09:06.15 | skrusty | morning |
| 09:20.06 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:20.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:22.05 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 09:22.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:35.18 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 09:52.10 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:07.48 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:12.42 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@195.218.175.34) |
| 10:13.19 | *** join/#asterisk-dev vlad_st__ (~vlad_star@195.218.175.34) |
| 10:35.18 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 11:22.14 | *** join/#asterisk-dev asilva (~asilva@gandalf.ai.unesp.br) |
| 11:22.19 | *** part/#asterisk-dev asilva (~asilva@gandalf.ai.unesp.br) |
| 11:35.12 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 11:40.20 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 12:16.39 | oej | Afternoon folks! |
| 12:35.11 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:50.18 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:23.00 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 13:35.10 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 13:37.08 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 13:42.34 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.248) |
| 13:48.15 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:49.24 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 13:51.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.178) |
| 13:52.18 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 14:07.09 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-abbvapmoushuwcwm) |
| 14:36.17 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 14:36.17 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:45.14 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 14:59.00 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:59.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:07.42 | jsmith | waves |
| 15:08.34 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-wtczliffcnvbovnt) |
| 15:08.35 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:3e97:eff:fe14:ef66) |
| 15:14.20 | leifmadsen | jsmith: ohai |
| 15:14.27 | jsmith | \o/ |
| 15:18.53 | *** join/#asterisk-dev reconwireless (uid10170@gateway/web/irccloud.com/x-ayqspiklsoflxczu) |
| 15:19.46 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-nndsbgusjmkzurcl) |
| 15:19.46 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:31.12 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-frvplfiyvzdtalhg) |
| 15:41.50 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 16:09.17 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 16:42.48 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 16:51.41 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 16:51.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:52.33 | *** join/#asterisk-dev jmls (~julian@77.107.171.82) |
| 16:52.44 | jmls | wdoekes: ping |
| 16:52.48 | wdoekes | pong |
| 16:52.58 | wdoekes | but I'm about to run |
| 16:53.19 | jmls | hey. does your commits for the realtime update imply that it's been broken since 1.8 ? ;) |
| 16:55.17 | putnopvut | jmls: probably even before that. |
| 16:55.38 | wdoekes | yes, but it isn't a problem for anyone, since no one used multi-update |
| 16:56.00 | wdoekes | (with postgres) |
| 16:56.30 | wdoekes | not even you, until you ran into the va_args bug |
| 16:56.44 | wdoekes | *gone* |
| 16:57.12 | jmls | and the va_args bug is platform-specific ? Works for example on intel, but not arm ? |
| 16:58.01 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.30) |
| 17:01.49 | putnopvut | jmls: yes, we were relying on undefined behavior to work in our favor. The raspberry pi is doing something perfectly legal and exposed the bug. |
| 17:04.22 | jmls | therefore I must probably be the only person to use realtime postgres voicemail on a pi :) *grins* |
| 17:04.34 | jmls | nothing like pushing the envelope .. |
| 17:05.12 | MrTAP | is anyone around that can consider committing a fix for a 3+ year old realtime problem? my proposed fix is already in the bug tracker. |
| 17:09.27 | pabelanger | MrTAP, you'll need to get the code up on reviewboard.asterisk.org for more exposure |
| 17:10.34 | MrTAP | As I understand it, a regular joe schmoe like me doesn't have access to do so and needs to rely on someone else to post to reviewboard? |
| 17:11.46 | elguero | MrTAP: what is the issue number? |
| 17:11.52 | MrTAP | 17523 |
| 17:12.54 | pabelanger | MrTAP, ideally, no. reviewboard needs some serious work to allow external users to register to it. I believe mjordan can create accounts manually |
| 17:17.48 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-iqmivlthrtybapva) |
| 17:21.43 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-daiwqknnhprckbtc) |
| 17:21.43 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:28.27 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.38) |
| 17:34.01 | gtjoseph | jrose_atDigium: Nice writeup on TOS. I think i'm leaning towards option 3 with support for the symbolics. |
| 17:36.10 | jrose_atDigium | Yeah, that's what I'm currently thinking we'll end up going with. |
| 17:40.16 | MrTAP | Thanks elguero and pabelanger. any suggestions as to action I can take directly to make some progress? I don't think there's much of a point in me trying to get an account on reviewboard, since I'm not likely to need it often/ever again |
| 17:40.47 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.31) |
| 17:45.22 | elguero | MrTAP: I would probably mention it on the asterisk-dev if you have contributed a patch to an issue. Developers in the community may take a look and provide some help. That would be another way of getting some exposure. |
| 17:45.50 | elguero | MrTAP: I looked over the patch and have put some comments on the issue tracker... take a look and I will look for your response there... thanks |
| 17:48.17 | MrTAP | elguero: okay, much appreciated. i will take a closer look as soon as customer's stop calling me :) |
| 17:49.01 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:49.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:49.22 | elguero | MrTAP: just realized I should clarify, when I said asterisk-dev, I meant the mailing list - although sometimes here works - but the mailing list has greater exposure |
| 17:51.23 | gtjoseph | tzafrir: Not understanding how RestartSec=1 help with the bad module scenario. It just puts asterisk into a tighter restart loop. |
| 17:52.45 | tzafrir | gtjoseph, as long as it's not 0, you won't end up with a constant restart. |
| 17:53.40 | tzafrir | safe_asterisk is also rather bad at handling restarts. Killing it may be a problem. With systemd killing the service would be easier. |
| 17:53.49 | tzafrir | Maybe just drop this line altogether? |
| 17:54.27 | gtjoseph | i'd keep it but bump it back up a little. attempting to restart at 1 second intervals just seems too short |
| 18:05.21 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:05.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:05.58 | seanbright | sruffell: hey guy |
| 18:25.16 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 18:40.59 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 18:40.59 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:41.11 | sruffell | seanbright: hello |
| 18:41.18 | sruffell | so.... |
| 18:41.20 | seanbright | heh |
| 18:41.42 | sruffell | If it is the jitter buffers, there is one thing that I might be able to do. |
| 18:42.17 | sruffell | I could allow codec_dahdi to return empty frames instead of wait…so it will add a couple ms of delay to the path…but it won't block the path. |
| 18:43.12 | seanbright | alright |
| 18:44.37 | file | I don't know if that'll work... cause while you are returning and not blocking the path the end result is still audio is delayed |
| 18:45.18 | sruffell | yeah…but at least the jitter buffers won't have a chance to accumulate audio at the end…for every frame given to codec_dahdi, one will be instantly returned…it just might not be for the audio that was passed in. |
| 18:45.50 | sruffell | at least those were my thoughts. The other thought, was to figure out if it's possible to eliminate adding and extra transcoding step when VOLUME is used. |
| 18:46.03 | sruffell | But I'm not that familar with the journey of a frame... |
| 18:46.19 | file | not... really |
| 18:46.34 | seanbright | i guess what i am trying to understand is how can codec_g729a.so do it? |
| 18:46.45 | seanbright | why is it seemingly only a hardware issue? |
| 18:47.18 | sruffell | codec_g729a instantly returns a transcoded frame for every frame given. codec_dahdi can not, since it must queue the frame for the hardware to pick up and then wait for an interrupt from the hardware. |
| 18:47.22 | file | it's synchronous, in the sense that you pass in audio and immediately get back something |
| 18:47.26 | file | and predictable |
| 18:49.32 | seanbright | i see |
| 18:50.14 | seanbright | making codec_dahdi synchronous isn't an option? |
| 18:50.15 | sruffell | although, something else I'm not sure about, is that this seems to have been accounted for since there are separate frameout and framein callbacks…but in practice, it seems like framein needs to do all the work. |
| 18:50.40 | file | sruffell, no way really for you to signal... and heck if I remember why they are separate |
| 18:50.45 | putnopvut | There's a default .frameout that is used if a translator does not provide an override. |
| 18:51.22 | sruffell | codec_dahdi is synchronous now (that is what that patch you tested does) but it still take several ms. The theory (from jcolp) is that when you have the VOLUME in the path, the 3 translations for each frame is causing extra delay at the ends of the audio path…and the jitter buffers do not like that. |
| 18:52.09 | sruffell | putnopvut: but it seems like the system doesn't like it when there isn't a one to one correlation between framein and frameout calls? |
| 18:53.07 | putnopvut | The translation code automatically calls frameout for every framein call, AFAIK |
| 18:53.42 | putnopvut | And I think it's tolerant, at least, of not being given a frame when calling a translator's frameout() callback. |
| 18:54.08 | file | profiling that may yield interesting results and confirm the hypothesis |
| 18:54.09 | putnopvut | Ooh, maybe not actually |
| 18:55.26 | sruffell | yeah…not too long ago ASTERISK-19643 was created to sort of enforce a more synchronous 1-to-1 behavior. |
| 18:56.13 | file | sruffell, do you know how long in reality that blocks? |
| 18:56.35 | sruffell | the only notes I have are about 2ms. I haven't measured it in a long time. |
| 18:57.23 | sruffell | my thought is that I can sort of prime the pump….so as to not have any delay…I give a new frame to the hardware…pick up the old frame….for the cost of returning a few dummy frames at the beginning of a transcoding session. |
| 18:57.33 | file | yup |
| 18:57.48 | sruffell | although I can't imagine this can be "default" behavior since it will then break the file translation again. |
| 19:04.11 | *** join/#asterisk-dev danjenkins_ (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 19:05.16 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 19:11.29 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.214) |
| 19:11.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.214) |
| 19:14.52 | seanbright | sruffell: well, i can test whatever you come up with |
| 19:15.05 | sruffell | kk |
| 19:15.18 | seanbright | based on what you've said, it sounds like i should plan to migrate away from the cards to software |
| 19:18.13 | sruffell | hmm…I don't know if I would say that quite yet. |
| 19:19.33 | sruffell | throughput is still better when the transcoding is offloaded to the DSP. |
| 19:28.16 | tzafrir | gtjoseph, actually, on my test system if asterisk restarts too fast (less than 2 seconds?), systemd will give up after two attempts or so |
| 19:28.53 | tzafrir | I found no way to control this rate or get notified about it. I figure that there is |
| 19:30.17 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.24) |
| 19:40.38 | wdoekes | tzafrir: StartLimitInterval |
| 19:42.26 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 19:44.31 | tzafrir | wdoekes, thanks |
| 19:47.50 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 19:59.09 | mjordan | putnopvut: opticron: I've been thinking about the device state dual cache problem some more. As a first step towards rectifying that situation, what if we made the concept of internal/external at least intrinsic to Stasis itself? |
| 19:59.27 | mjordan | That is, the default mechanism of publishing/subscribing would publish internal; subscribe to everything |
| 20:00.10 | mjordan | but the ast_eid would be part of the cached objects themselves, such that things can choose to publish an update that came from an external Asterisk system, and can choose to subscribe only to internal updates or only to external updates |
| 20:00.27 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.24) |
| 20:01.22 | mjordan | Internally, the best I can come up with for the cache is a hash of hash tables, where the first hash is the id of the object, and the second is the eid of the updater |
| 20:01.51 | mjordan | well |
| 20:02.11 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:02.11 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:02.30 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 20:03.12 | mjordan | it could be even a bit faster: a hash of structs, where the first entry is a pointer to the internal object representation, and the second is an ao2_container of external updates |
| 20:03.12 | mjordan | getting internal things is fast |
| 20:03.12 | mjordan | getting the combined or external is a bit slower, but at least doesn't require dumping the entire cache. You'd just have to get a an ao2_container back as opposed to the single item |
| 20:04.03 | putnopvut | mjordan: I'm catching up here... |
| 20:04.46 | mjordan | white boards would help, but alas, we have ASCII |
| 20:05.16 | *** join/#asterisk-dev dpeloquin (uid13057@gateway/web/irccloud.com/x-wmslanlybribyriz) |
| 20:05.30 | putnopvut | I like the idea of putting the internal/external burden on Stasis, since it allows for external state to exist for things other than device state. I'm curious if that, by definition, means a performance hit though? |
| 20:06.12 | mjordan | a very small one for internal. When doing an ao2 lookup of the item in the cache, you wouldn't get back the item - you'd get back a struct that has a pointer to the item |
| 20:06.16 | mjordan | so one extra dereference |
| 20:06.16 | file | ponders |
| 20:06.36 | gtjoseph | gui apply |
| 20:06.47 | mjordan | gtjoseph: nak |
| 20:06.57 | gtjoseph | :) |
| 20:06.59 | mjordan | stasis_cache_dump would probably take the biggest nit |
| 20:07.01 | mjordan | er, hit |
| 20:07.02 | mjordan | :-) |
| 20:07.12 | mjordan | But it's already super inefficient |
| 20:08.18 | mjordan | If the internal/external attribute was part of the stasis_message object itself, then the API changes very little. When you subscribe to something, you're informed if it is internal/external |
| 20:08.20 | putnopvut | Yeah, cache dumping should hopefully only be needed for cases where the cache is demanded (e.g. a CLI command for debugging) |
| 20:08.46 | mjordan | or when you get a state of something and you have to aggregate it together with its internal/external counterparts |
| 20:09.12 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-zypsoujgpdmmdkyt) |
| 20:12.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.24) |
| 20:15.02 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-pnimaxtqeppztrcw) |
| 20:15.08 | putnopvut | mjordan: well, my opinion is that if this could be done efficiently within stasis itself, it makes sense to take the burden off of the device state code. |
| 20:15.10 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 20:16.50 | mjordan | my thought is: this is going to become more common, not less |
| 20:17.00 | putnopvut | Agreed. |
| 20:18.11 | file | quite |
| 20:21.30 | mjordan | putnopvut: I like the res_pjsip_pubsub API. The only thing I think we may need - eventually - is the ability for one ast_sip_subscription_handler implementation to 'ask' for an event body for some other event name |
| 20:23.11 | file | we need two things... the ability to store persistent information, and that |
| 20:23.30 | putnopvut | mjordan: we're partially on the right path by having ast_sip_pubsub_generate_body_content() provide the necessary content type and subtype. The difficult part is supplying the necessary data in order to build a body. Sounds like handlers may need to cache the latest body in order to be able to provide it on demand? |
| 20:23.59 | mjordan | or they could generate the body on the fly when requested, but if they persisted it it would be less work |
| 20:24.10 | mjordan | stasis update comes in, generate body, cache it |
| 20:24.29 | putnopvut | Generating on the fly would be more difficult since bodies are typically generated from transient data from a stasis publication. |
| 20:24.36 | mjordan | yup |
| 20:24.52 | mjordan | although |
| 20:24.52 | mjordan | most of the stuff they generate things from are cached |
| 20:24.52 | mjordan | but that runs afoul of ... caching. |
| 20:25.14 | file | if you cache a cache... does it become uncached? |
| 20:25.29 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 20:31.26 | putnopvut | I almost just did a 'cat foo | less' on the command line and then caught how silly that was. |
| 20:34.26 | opticron | you're such a cat abuser |
| 20:35.20 | putnopvut | I said I caught myself :) |
| 20:35.55 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.24) |
| 21:06.02 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 21:10.28 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:2c1:cf01:2677:3ff:fe8f:2730) |
| 21:12.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.183) |
| 21:15.31 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 21:15.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:00.12 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:00.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.133) |
| 22:12.34 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.133) |
| 22:13.43 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 22:31.09 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 22:49.33 | *** join/#asterisk-dev danjenkins_ (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 23:13.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.169) |
| 23:28.24 | tm1000 | anyone well versed in modprobe that I can bug for a min, dont want to bother sruffell or tzafrir |
| 23:29.30 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-daiwqknnhprckbtc) |
| 23:30.21 | gtjoseph | tm1000: what do you need? |
| 23:30.38 | sruffell | lol |
| 23:32.20 | tm1000 | gtjoseph: got a customer here who, for god knows why, has both a sangoma pri and a digium pri |
| 23:32.46 | tm1000 | when I start wanrouter and run dahdi_scan I see the sangoma, but not the digium, until I modprobe the digium |
| 23:33.22 | tm1000 | maybe I should just ask in regular #asterisk… not a problem if so |
| 23:33.33 | tm1000 | wanrouter starts the dahdi service, fyi |
| 23:34.26 | sruffell | tm1000: probably the driver for the digium card isn't /etc/dahdi/modules |
| 23:35.01 | sruffell | <PROTECTED> |
| 23:35.14 | tm1000 | sruffell: I checked modules first, its enabled there |
| 23:35.36 | sruffell | hmm…so you just do /etc/init.d/dahdi restart, dahid_scan still doesn't show the digium card? |
| 23:37.51 | tm1000 | sruffell: going to check one second |
| 23:42.28 | tm1000 | sruffell: I think I figured it out, it was releated to what you said but higher up, dahdi was not getting started, sangoma was blocking it from started, so of course it never read the modules file |
| 23:43.02 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 23:45.42 | sruffell | ahh..cool |
| 23:48.58 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.230) |
| 23:48.59 | tm1000 | sruffell: didnt want to bother you too much with an "other guys" problem, if it was a digium issue I would have come to you instantly :-) |
| 23:50.29 | sruffell | lol…cool…cool. But you just said it was a general modprobe question. :) |
| 23:53.01 | tm1000 | sruffell: I was being tricky :-) |
| 23:53.03 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-wtczliffcnvbovnt) |