| 00:22.58 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:22.59 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 00:38.51 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 01:31.41 | *** join/#asterisk-dev Marquis42 (~mrbmw@c-68-43-254-216.hsd1.mi.comcast.net) |
| 01:43.59 | *** join/#asterisk-dev droemel (~droemel@p4FCACEAD.dip.t-dialin.net) |
| 02:09.40 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 02:09.40 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 04:22.04 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 06:18.46 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 06:32.45 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:32.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:39.35 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 09:19.54 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 09:19.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:22.50 | oej | Hello folks |
| 09:35.16 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-180-203-73.hsd1.tn.comcast.net) |
| 09:35.16 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 10:09.35 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 10:09.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:20.03 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 10:44.21 | *** join/#asterisk-dev jmls (~jmls@217.144.151.2) |
| 11:20.55 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:35.35 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:35.35 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:02.28 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 12:02.50 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:13.48 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 12:55.20 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-tjwnivgsispwyint) |
| 13:01.12 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 13:01.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:05.33 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:05.34 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:44.51 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-tkoakmyfciuutftw) |
| 13:44.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:49.07 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:49.07 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:04.00 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 14:32.37 | oej | Afternoon folks |
| 14:34.29 | mjordan | oej: afternoon! |
| 14:34.46 | oej | Matt: Have you checked out the pinefrog-1.8 yet? |
| 14:34.54 | mjordan | oej: saw your e-mail about the RTCP work. Last weekend got away from me - hoping to get some time later this week/weekend to take a look |
| 14:34.56 | oej | The basics are working |
| 14:34.58 | mjordan | awesome |
| 14:34.59 | oej | Ok. |
| 14:35.18 | oej | There some issue with RTT; but that's not releated to pinefrog. I'll just go ahead and blame file. |
| 14:35.22 | mjordan | had to get the early spring garden in, which involved a lot of roto-tilling and building potato cages. Turns out that takes a lot longer than I thought |
| 14:35.32 | oej | Good focus. |
| 14:35.47 | oej | Too early here though. Have some seeds indoors, but outside is still covered with snow. |
| 14:35.55 | mjordan | I'm rather hoping that we don't have to build a table of RTCP endpoints |
| 14:36.39 | mjordan | oej: we've got onions and carrots already sprouting up. Growing season here is looong. Summer tends to be tricky, as we sometimes get very little rain and the heat is brutal |
| 14:41.06 | file | mmm shrapnel |
| 14:41.53 | mjordan | tasty |
| 14:42.42 | oej | Last summer we got too much rain and to little heat. Not good for gardening. |
| 14:43.44 | mjordan | there's a sweet spot. I have learned a profound respect for farmers after trying to grow, well, anything. About half of what we planted ended up being food for the bugs (luckily, that still meant we had a lot of food) |
| 14:44.34 | mjordan | depressing to go to bed with collards in the garden, only to come out in the morning and find skeletal stalks. Those caterpillars can eat a plant *fast* |
| 14:46.22 | oej | Yes, that's part of it all. You learn what to grow, where to grow it and how. |
| 14:46.34 | oej | We have a problem with snails, spanish killer snails we call them. |
| 14:47.01 | oej | Growing stuff in pots helps, so we had tomatoes and dill in pots instead of in the ground to protect from these snails. |
| 14:47.33 | oej | There are also combinations of plant that helps protection. Marigolds have a strong smell that can help in the vegetable patch. Garlic too. |
| 14:47.38 | mjordan | yup |
| 14:47.55 | mjordan | we did marigolds, nasturtiums |
| 14:47.58 | mjordan | this year we're adding garlic |
| 14:48.05 | oej | Cool. |
| 14:48.29 | oej | I love the marigolds. Unfortunately these spanish snails love it too, so I can't grow it any more. |
| 14:48.40 | mjordan | heh |
| 14:48.49 | mjordan | never good when the pests enjoy the pest control |
| 14:49.20 | *** join/#asterisk-dev LieutPants (~LieutPant@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:49.20 | *** mode/#asterisk-dev [+o LieutPants] by ChanServ |
| 14:49.59 | leifmadsen | ASTERISK-20259 |
| 14:50.00 | LieutPants | [ASTERISK-20259] [Status: In Progress] [Assigned: lathama] Update Doxygen Configuration for make progdocs - https://issues.asterisk.org/jira/browse/ASTERISK-20259 |
| 14:51.09 | mjordan | leifmadsen: thanks for bringing back the bot :-) |
| 14:51.10 | oej | Safari can't handle jira still… That's bad. |
| 14:51.19 | leifmadsen | yes, safari is bad |
| 14:51.19 | mjordan | huh. SVN cert? |
| 14:51.25 | mjordan | bah |
| 14:51.26 | mjordan | not svn, SSL |
| 14:51.45 | oej | Yes, it asks for SSL cert and fails to recognize the one I have. Installed it for Hydra (early SCF) |
| 14:52.02 | oej | And there's no way around it. |
| 14:52.11 | *** join/#asterisk-dev LieutPants (~LieutPant@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:52.11 | *** mode/#asterisk-dev [+o LieutPants] by ChanServ |
| 14:52.16 | leifmadsen | welp, we'll see how long this lasts :) |
| 14:52.21 | oej | I think that should be turned off. Does anyone use SSL client certs for jira? |
| 14:52.27 | leifmadsen | I have it running as a nohup and it should attempt to reconnect after 120 seconds.... |
| 14:52.29 | file | yes. |
| 14:52.43 | leifmadsen | SSL is definitely used with JIRA |
| 14:52.52 | mjordan | oej: does it only happen with safari? |
| 14:52.52 | oej | client certs? For what? |
| 14:52.59 | oej | Only with safari. |
| 14:53.28 | oej | I know that we use server-side SSL certs and SSL. |
| 14:53.38 | leifmadsen | if I remember right it's used for keeping internal things secure so everything can share the same jira instance |
| 15:19.02 | mjordan | elguero: thanks for the work on ASTERISK-21173 and ASTERISK-21035 |
| 15:19.03 | LieutPants | [ASTERISK-21035] [Status: Closed] [Assigned: elguero] [patch] - features.conf in static realtime requires distinct cat_metric for each parking lot - https://issues.asterisk.org/jira/browse/ASTERISK-21035 |
| 15:19.03 | LieutPants | [ASTERISK-21173] [Status: Closed] [Assigned: elguero] [patch] example sippeers sql hasn't been adapted for ipv6 and causes chan_sip to generate a warning message - https://issues.asterisk.org/jira/browse/ASTERISK-21173 |
| 15:23.38 | elguero | mjordan: no problem, keep doing what I can to help |
| 15:28.12 | mjordan | it's definitely appreciated :-) |
| 15:29.06 | Qwell | oej: Can you not remove the old cert? |
| 15:29.21 | Qwell | It's not necessary, unless you're one of like 20 people. |
| 15:29.52 | oej | Well, since SCF doesn't exist any more I guess I can. I think it's used on the wiki if I have it so it was ease-of-use. |
| 15:30.03 | oej | and that site actually works right. |
| 15:30.29 | Qwell | wiki doesn't require certs (for the people that need them) the same way JIRA does |
| 15:30.57 | oej | But if you have a cert, it uses it. The wiki was the reason for the cert in the first place. |
| 15:31.02 | Qwell | actually, I don't think it uses it |
| 15:31.06 | Qwell | hrm |
| 15:31.10 | oej | Maybe it changed. |
| 15:31.31 | leedm777 | oej: Yeah, I think that changed when the wiki went public. |
| 15:31.34 | Qwell | maybe - either way, you can remove it |
| 15:31.53 | oej | I just need to check that svn doesn't use the same cert store. |
| 15:32.08 | Qwell | They're different certs |
| 15:33.09 | oej | I only have certs from Digium SVN CA in there. |
| 15:35.33 | oej | It still requires a client certificate |
| 15:37.12 | oej | If I cancel it just hangs |
| 15:38.08 | oej | features.c:1060: warning: 'adsi_announce_park' defined but not used |
| 15:38.10 | oej | In 1.8 |
| 15:39.13 | leedm777 | oej: I see that, too. Other browsers just let you hit cancel and go onto the site. Not sure why Safari behaves differently. |
| 15:39.57 | oej | Firefox doesn't ask for a client cert |
| 15:40.12 | leedm777 | Firefox uses its own internal certificate store |
| 15:40.34 | leedm777 | and none of the browsers will pop up the client cert dialog if you have no certs installed |
| 16:08.01 | mjordan | Oh white space... [Mar 13 11:06:43] WARNING[31289]: ami:166 event_callback: Requirement AsteriskCause: No route to destination does not match AsteriskCause: No route to destination |
| 16:37.06 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:48.04 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:48.04 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:50.49 | *** join/#asterisk-dev rgagnon (~rgagnon@d24-57-198-219.home.cgocable.net) |
| 16:51.01 | *** part/#asterisk-dev rgagnon (~rgagnon@d24-57-198-219.home.cgocable.net) |
| 17:33.56 | mjordan | opticron: re device state: why would you not be able to boil it down to a single topic/message, if part of that message includes who originated the device state? |
| 17:42.49 | opticron | it could all be put in a single cache, but keeping it separate makes things clearer |
| 17:43.09 | mjordan | and also redundant |
| 17:43.40 | opticron | I'd have to assign an EID as "this is the EID for aggregate messages, don't use this message for generating aggregates" |
| 17:43.45 | mjordan | if I'm a remote system and I update device 300 on the local system, and the local system also updates device 300, I have two different device states sitting in the cache. What is the actual device state for 300? |
| 17:44.22 | opticron | a combination of the two depending on what the states are |
| 17:44.29 | mjordan | I don't think that's simpler |
| 17:45.51 | opticron | look at this from the perspective of a server that doesn't generate states for a device |
| 17:46.03 | mjordan | such as? |
| 17:46.25 | opticron | server A gets a state for device 1 from server B and another for the same device from server C |
| 17:46.51 | opticron | the overall state of the device is the combination of those two |
| 17:47.10 | mjordan | that's fine. That still doesn't mean you have to have multiple caches |
| 17:48.07 | mjordan | those device state updates don't happen simultaneously - you update from B, then you update from C. If the concept of the device is 'local' and 'remote', you still have to aggregate states for a single object in memory, as both of those are 'remote' |
| 17:49.06 | opticron | I agree, it does not require the use of two different caches, but right now the existence of two caches is the delineation between aggregate state and server-specific state |
| 17:50.00 | mjordan | If B and C both told me a device is busy, I may want to keep that separate from my view of the device. That's fine. But having two different device objects is a bad idea |
| 17:50.13 | mjordan | now, if I have a hint on the device, I have to search both caches |
| 17:50.39 | mjordan | why not just have a local state/remote state for a device? |
| 17:51.12 | mjordan | creating an awkward data model to satisfy application level policies leads to shenanigans |
| 17:51.24 | file | and rage |
| 17:54.27 | opticron | why would a hint on the device necessitate searching both caches? the only things that touches the server specific topic/cache are the aggregator and the cross-server distribution mechanisms |
| 17:56.36 | leifmadsen | hey I got some doc updates for repotools and but don't have my commit access setup. Easy change for someone who might be willing to commit for me: http://pastebin.com/vmVZB3Y2 |
| 17:56.39 | mjordan | Built in aggregation is an implementation decision |
| 17:56.56 | opticron | hmmm |
| 17:57.02 | mjordan | It is entirely conceivable that local/remote device state could be exposed to the dialplan |
| 17:57.06 | mjordan | even if it isn't today |
| 17:57.27 | mjordan | creating a data model that hampers the implementations that future developers may try to create == chan_sip |
| 17:57.33 | file | would prefer aggregation to be more pluggable, since it's business logic with sane defaults really |
| 17:57.41 | mjordan | exactly |
| 17:57.47 | mjordan | distributed queue agents comes to mind |
| 17:58.01 | leifmadsen | did I hear distributed queue agents?! |
| 17:58.08 | mjordan | "If Agent A is busy on Server 1, he's busy for me as well. If Server 2 say's he's busy, screw that I want to call him" |
| 17:58.28 | mjordan | leifmadsen: shhh |
| 17:58.32 | opticron | starts tweaking all of the things |
| 17:58.36 | file | leifmadsen, YOU HEAR NOTHING |
| 17:58.42 | leifmadsen | true story |
| 17:58.44 | leifmadsen | I am only reading |
| 17:58.51 | mjordan | leifmadsen: I can take care of it after a meeting |
| 17:59.02 | leifmadsen | k |
| 17:59.05 | opticron | on the plus side, what I currently have is passing the only two integration tests I know of that use device state |
| 17:59.08 | leifmadsen | I should make the pastebin live longer than 10 mins I think |
| 17:59.35 | leifmadsen | mjordan: http://pastebin.com/AYUiP8JY <-- last for a day |
| 18:05.48 | Qwell | No need to nickserv. Just connect with a password. |
| 18:06.36 | Qwell | oh, bot doesn't support that, I guess. That's silly. |
| 18:32.20 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 18:41.35 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-jyxbtnmjihenjelh) |
| 18:42.14 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:42.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:29.15 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 22:25.51 | snuff-work | file: ping? |
| 22:25.58 | file | pong |
| 22:26.54 | snuff-work | looking into the callerid again little more.. we dont even pass in a ast_chan to our res_sip.. so how would we get the callerid info to there? |
| 22:27.34 | snuff-work | or more so.. what way were we thinking of doing it.. |
| 22:28.42 | file | you can extend things with an API to modify tdata to include callerid information, and one to interpret an rdata and react... then modules for the different methods |
| 22:28.54 | file | they can be called from within chan_gulp, or wherever else |
| 22:35.10 | snuff-work | k.. its sounding little over my head ;) maybe i might see about making a remote-party-id header reader in pjsip itself.. they dont seem to be overly complex to write up parse headers looking over some of the examples |
| 22:38.35 | file | yeah doing all of that stuff I suspect will end up being the hardest part |
| 22:38.47 | file | the API and how it gets used we can discuss and come to a decision on afterwards |
| 23:43.51 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-tkoakmyfciuutftw) |