| 00:01.05 | mjordan | hm. |
| 00:01.06 | mjordan | boo. |
| 00:01.19 | mjordan | wait a second. |
| 00:01.32 | mjordan | Were those the changes that were the moving of the format out of subclass? |
| 00:05.26 | coreyfarrell | well actually all I meant was that adding format to ast_frame was not meant to be |
| 00:05.51 | coreyfarrell | was probably sent to you in the same patch. |
| 00:05.56 | mjordan | yeah, I think so |
| 00:06.05 | mjordan | I can put the changes for frame.c back into the diff |
| 00:06.13 | coreyfarrell | it's others too |
| 00:06.34 | mjordan | looking at them, those appear to just be memory cleanup of formats that may have been ref bumped on statically allocated frames |
| 00:06.39 | coreyfarrell | codecs/ex_*.h, include/asterisk/slin.h are the ones off the top of my head |
| 00:06.44 | mjordan | hm. |
| 00:06.46 | coreyfarrell | yup |
| 00:06.54 | mjordan | I think I removed that deliberately, actually |
| 00:07.12 | mjordan | I don't think all of the statically allocated work is done, since with those patches there were still ref leaks from some areas |
| 00:07.31 | mjordan | I was trying to not pull too much into the rename patch; unfortunately, some of the files crept by me in the initial post |
| 00:07.39 | coreyfarrell | last I checked without those patches we get fracks |
| 00:07.49 | mjordan | really... hm. |
| 00:08.00 | coreyfarrell | anyways that's fine we can consider it later, or not... we can get this review in though |
| 00:08.27 | mjordan | I think we have to do something about the static frames |
| 00:08.37 | mjordan | and I think your patch was a major jump in the right direction |
| 00:08.50 | mjordan | there's some, such as those frames that are used during translation cost calculation, that are kind of a mess still |
| 00:08.57 | mjordan | (at least, I think so) |
| 00:09.04 | coreyfarrell | yes on doing something about static frames, to be determined on my changes |
| 00:09.11 | mjordan | If possible, since this patch is already rather large, I'd prefer to hold off |
| 00:09.27 | coreyfarrell | yup that's fine we're not making things worse by not including that stuff |
| 00:09.29 | mjordan | I think it'll be a bit easier to review the frame work if it isn't bundled with this 4 page horror |
| 00:09.53 | coreyfarrell | especially since the trunk merge crept into the diff between diff's |
| 00:10.35 | coreyfarrell | easier to test before and after to see if we're making things better or worse with the frame changes |
| 00:11.00 | mjordan | yeah |
| 00:25.48 | coreyfarrell | so our first unit test crash is in tests/test_channel_feature_hooks.c - test_features_channel_interval |
| 00:33.56 | mjordan | ooo |
| 00:35.48 | mjordan | I suspect that it is still what I guessed however. That test is doing the same thing as the CDR/CEL tests: making faked out channels to push them in and out of bridges |
| 00:36.03 | coreyfarrell | I think because chan_alice doesn't have any formats, though it could be chan_bob not having formats |
| 00:36.15 | mjordan | everyone is a culprit! |
| 00:36.34 | mjordan | Really, we should be tolerant of that in the bridging framework. Ideally you would never have that happen, but 'never' is a strong word |
| 00:37.15 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 00:38.15 | coreyfarrell | do we have any comparisons of coverage for testsuite vs unit tests? |
| 00:41.52 | coreyfarrell | actually doesn't we probably can't drop this unit test in favor of the testsuite, even if we could other tests will blow up just the same. |
| 00:42.01 | coreyfarrell | doesn't matter that is |
| 00:44.52 | mjordan | yeah. The bridging framework really does need to be able to handle that |
| 00:44.56 | mjordan | or whatever is currently seg faulting |
| 00:45.07 | mjordan | IIRC, the current code will spam you with an ERROR message |
| 00:46.25 | mjordan | goes to grab some dinner |
| 01:05.22 | coreyfarrell | looks like we're fracking on startup now.. :( |
| 01:09.14 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 01:09.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:25.00 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 02:01.23 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 02:01.23 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 12 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 02:05.42 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 02:05.42 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 12 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 02:55.12 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 03:33.42 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 03:54.19 | *** join/#asterisk-dev ipengineer (~zconkle@108-206-120-218.lightspeed.mckntx.sbcglobal.net) |
| 06:11.33 | *** join/#asterisk-dev oej (~Adium@109.70.54.56) |
| 06:11.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:44.47 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 06:54.09 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:4565:9628:8eff:a854) |
| 07:19.35 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:19.35 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:24.43 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 07:44.04 | Stefan27 | in asterisk 1.2 i could modify source code to raise special events by adding/modifying a line such as manager_event(EVENT_FLAG_SYSTEM, "PeerStatus", "Peer: SIP/%s\r\nPeerStatus: Registered\r\n", peer->name); anywhere in chan_sip.c ? This seems to have changed in ast 12. How is that accomplished now? is static void send_manager_peer_status(struct mansession *s, struct sip_peer *peer, const |
| 07:44.04 | Stefan27 | char *idText) used for the same purpose? |
| 07:46.11 | *** join/#asterisk-dev oej (~Adium@109.70.54.56) |
| 07:46.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:46.15 | oej | Morning folks! |
| 07:48.09 | Stefan27 | It seems more complicated now, parts of events-raising was moved to statis._system.c ? I couldn't quite figure out the new structure by looking at https://reviewboard.asterisk.org/r/2631/diff/3-4/ |
| 07:48.23 | Stefan27 | hi oej |
| 07:49.08 | Stefan27 | stasis_system.c* |
| 08:09.42 | oej | I don't know much about stasis… Still on Asterisk 1.8 :-) |
| 08:14.27 | Stefan27 | I think I just misunderstood what changed. manager_event() still works but they removed all calls to it from chan_sip.c |
| 08:16.20 | Stefan27 | reverse engineering is difficult |
| 08:41.37 | oej | ;-) |
| 08:41.50 | oej | What is it you're trying to do? |
| 08:58.52 | Stefan27 | our company uses asterisk1.2 but made 25 small patches to the code to change some behaviour, now they want to upgrade asterisk and so we need to go through each patch to see if it will be needed or not in the new asterisk. this means lots of cross-checking in source-files comparing (ast1.2-orig , ast1.2-patched, ast12.3-orig) -- mostly in the file chan_sip.c . Some patches are not needed |
| 08:58.52 | Stefan27 | because they solved issues which no longer exists |
| 09:00.49 | Stefan27 | needless to say, a lot of things have changed from version 2 to 12... many more lines to code for one |
| 09:45.57 | *** join/#asterisk-dev oej (~Adium@109.70.54.56) |
| 09:45.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:56.14 | *** join/#asterisk-dev stevePearPear (~stevePear@203.117.37.54) |
| 10:46.57 | oej | stefan27: Yes, that seems like a good amount of work. |
| 10:47.11 | oej | I have a few more patches to my Asterisk 1.8 that I need to forward port. |
| 11:43.57 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 11:49.15 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-tovxqxeuundclcvh) |
| 12:10.43 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:14.16 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:17.52 | *** join/#asterisk-dev snuff-work (~snuffy@101.171.222.108) |
| 12:17.52 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:33.49 | *** join/#asterisk-dev oej (~Adium@109.70.54.56) |
| 12:33.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:51.19 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 13:05.12 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 13:35.54 | file | whoops, silly merging |
| 13:36.09 | coreyfarrell | file: at least it failed on the first automerge :P |
| 13:36.49 | file | 'tis because of a prop conflict, but I'm okay with that |
| 13:37.11 | coreyfarrell | a conflict between the automerge props? |
| 13:37.44 | file | I don't think I put mine in a different prop, so it conflicted and sadness occurred |
| 13:38.36 | coreyfarrell | too bad mjordan isn't here I'd troll him about git again :) |
| 13:39.01 | file | I'm over the trolling about git. It's the same thing over and over, but it doesn't change reality. :P |
| 13:39.03 | leifmadsen | git git, the wonderful fruit... |
| 13:40.02 | file | goes to get glasses and yogurt |
| 13:40.55 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-jywuoyetutlwbopm) |
| 13:41.07 | file | the flavor for today is... raspberry! |
| 13:43.03 | WIMPy | Tastes like yester-year. |
| 14:06.29 | jsmith | file: I approve |
| 14:06.48 | jsmith | file: Although, the fresh blueberries and blackberries yesterday were delicious :-) |
| 14:06.57 | file | I bet |
| 14:06.59 | jsmith | doesn't yet have any ripe raspberries in his garden |
| 14:08.32 | Corydon76-home | Loosely typed variables are teh suck (in AEL) |
| 14:11.57 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:11.57 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:12.40 | Corydon76-home | Heh, maybe we can rope mjordan into becoming the new master of AEL (or cry bitter tears into his beer trying) |
| 14:14.02 | jsmith | Corydon76-home: Yet another reason to use ARI instead of dialplan :-p |
| 14:14.18 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-qujkplcopwzpfzkx) |
| 14:14.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:14.30 | Corydon76-home | Speak of the devil |
| 14:14.31 | mjordan | Corydon76-home: thanks for catching that stuff with AEL |
| 14:14.37 | mjordan | waves |
| 14:14.54 | file | mjordan, can you provide a thought on my attributes review? |
| 14:15.00 | mjordan | yup, that's next on my list today |
| 14:15.10 | mjordan | file: Is there something specific? Or just do a review? |
| 14:15.53 | file | I'd like someone else to provide a comment on coreyfarrell's thought of moving a bit of logic into the core |
| 14:15.56 | Corydon76-home | mjordan: Digium used to have a savant named Steve Murphy who dealt with all things expression related in Asterisk, for which the rest of the developers were grateful, as it is a deep rabbit hole of insanity. |
| 14:16.34 | mjordan | Well, he did write AEL. |
| 14:17.12 | mjordan | So if you are the creator of a ball of an existential coding horror that drives developers to claw their eyes out... yeah. |
| 14:17.16 | Corydon76-home | Well, no, he wrote the fully functional AEL2 off of a concept that Mark Spencer pioneered in AEL1, which didn't work very well. |
| 14:17.21 | mjordan | oic. |
| 14:17.27 | mjordan | Well. I still stand by statement. |
| 14:17.34 | mjordan | :-) |
| 14:17.44 | mjordan | As exhibit A, I yield 'extconf.c' |
| 14:18.08 | Corydon76-home | I think if Steve had written AEL from his own conception, strongly typed variables would have been part of the plan. |
| 14:18.55 | mjordan | There's just a lot of fundamental stuff that is wrong in there. And it isn't all AEL's fault. The PBX core does an "interesting" job of letting external PBX modules provide dialplan information |
| 14:19.11 | Corydon76-home | Because it's those weakly typed dialplan variables that mostly act as strings, unless you force them to be arithmetic, which is the horror |
| 14:20.13 | Corydon76-home | Right, at one time, Steve thought he could change the core to be a properly built syntax tree |
| 14:21.07 | mjordan | I'm not sure Asterisk should be in the business of providing languages. I'd rather have it be good at delivering channels to languages to go deal with, with a well defined (and sane) C API that lets those languages interface with the core that performs actions on those channels |
| 14:21.34 | mjordan | The reality is: our community is not overflowing with language developers |
| 14:21.43 | mjordan | and there are many communities that are quite good at that job |
| 14:22.07 | Corydon76-home | I'll be thankful that res_perl never made its way into the core |
| 14:22.08 | file | I'd rather be good at providing primitives, nice interfaces for others, and a solid SIP foundation. |
| 14:22.27 | Marquis42 | +INF |
| 14:22.28 | mjordan | Corydon76-home: +1 |
| 14:22.47 | Marquis42 | file: As a heavy user and sometimes contributor to Asterisk, that is EXACTLY what I want. :) |
| 14:23.03 | file | Marquis42, I know it's exactly what you want. :D |
| 14:23.13 | Corydon76-home | mjordan: Google that monstrosity, if you're curious. I've heard people who ran res_perl restarted their instances on a regular basis due to HORRIBLE memory leaks |
| 14:23.52 | file | don't. just don't. |
| 14:23.53 | mjordan | heh |
| 14:23.55 | mjordan | I did. |
| 14:23.59 | mjordan | I am not surprised at any of it. |
| 14:24.33 | Corydon76-home | AEL, by comparison, actually looks like a good idea. |
| 14:24.45 | Corydon76-home | and I say that knowing that AEL was a horrible idea |
| 14:24.46 | mjordan | ironically, I'd much rather see a pbx_python, or a more integrated pbx_lua, or yes, even pbx_perl. Implementation, however, does matter. |
| 14:26.06 | jameswf | looks for res_python |
| 14:26.20 | Corydon76-home | and I also say AEL was a horrible idea, knowing that I contributed some of the elegant workarounds for bugs in it |
| 14:26.55 | mjordan | there's no pbx_python yet. It does run into an interesting issue where the python interpreter is single threaded, and does not enjoy being made multi-threaded. |
| 14:28.38 | jameswf | I like my python threads like an ugly sister..... Single and Blocking... |
| 14:28.39 | sgriepentrog | each call could operate as a separate python instance... |
| 14:29.37 | mjordan | Kind of. You still have a global instruction lock. This has a good write up of the issues you have embedding Python in a multi-threaded app - http://www.linuxjournal.com/article/3641?page=0,2 |
| 14:30.52 | Corydon76-home | Lua is probably the best idea, but where it failed was in the way that it had to pass arguments to applications as strings |
| 14:31.02 | jameswf | mjordan: you realize that article is 14 years old |
| 14:31.09 | mjordan | yes, and it hasn't changed |
| 14:31.12 | mjordan | :-) |
| 14:31.13 | jameswf | there has to be improvements in 14 years |
| 14:31.36 | jameswf | then again in 16 years my teenager has only gotten worse |
| 14:31.39 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 14:31.50 | mjordan | Go take a peek at the Python 2.7 documentation: https://docs.python.org/2/extending/extending.html |
| 14:31.53 | mjordan | I can't speak for Python 3 |
| 14:32.01 | ipengineer | file: FYI that patched worked like a champ! |
| 14:32.18 | file | ipengineer, handy dandy |
| 14:32.36 | mjordan | But you'll note there aren't major API differences between what that article references and 2.7. The fundamental idea of a global interpreter lock hasn't changed. You _can_ try to load multiple interpreter instances, but there are drawbacks with that in a multi-threaded environment as well. |
| 14:32.44 | ipengineer | Thanks once agin |
| 14:34.29 | Corydon76-home | mjordan: Eh, we'll just replace all mutexes with rwlocks. Nothing can go wrong... go wrong... go wrong... |
| 14:34.29 | jameswf | can we have res_go |
| 14:34.41 | jameswf | I think that's the new hotness |
| 14:34.41 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:34.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:34.47 | mjordan | Corydon76-home: :-) |
| 14:34.53 | mjordan | rust > go |
| 14:34.57 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-kbwggryfblkuabqv) |
| 14:34.58 | Qwell | jameswf: it's all about node.js now |
| 14:35.19 | Corydon76-home | How about pbx_swift (not to be confused with res_swift)? |
| 14:35.31 | file | Dropbox switched from Python to Go actually - and just released a few libraries |
| 14:35.40 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 14:35.56 | mjordan | I'm not terribly blown away by either Swift or Go. |
| 14:35.57 | jameswf | Qwell: I compiled node.js this weekend... for something that seems so unassuming it was a looooooooooooong compile |
| 14:35.59 | jsmith | jameswf: What about res_node_js? |
| 14:36.16 | jsmith | ducks and hides |
| 14:36.18 | mjordan | Go is missing some basic functionality of generics and encourages downcasting to a common base type object. Ew. |
| 14:36.59 | jameswf | res_php |
| 14:37.01 | mjordan | Swift feels like Apple woke up and realized how horrible Objective-C was, and decided they needed their own Java/C#/Go-esque language as well. |
| 14:37.02 | Qwell | mjordan: it's not a real language unless it has === |
| 14:37.04 | file | has turned today from Thursday to Friday as they both share a common Day class |
| 14:37.04 | jameswf | ducks |
| 14:37.26 | mjordan | Go also doesn't have operator overloading, which is a nice tool for an OO language |
| 14:38.25 | mjordan | the best part about Swift is how excited iOS developers got. "We get a real language!" Yes, and you've been eating shit for years happily. You just now realized that what you were doing was the programming equivalent of torture? And you're happy that your torturer finally released you? |
| 14:38.27 | mjordan | Sheesh. |
| 14:38.42 | Corydon76-home | res_ook |
| 14:38.46 | Corydon76-home | runs |
| 14:38.56 | mjordan | Qwell: ew. |
| 14:39.17 | Qwell | mjordan: Apple fanboys have Munchausen. |
| 14:39.30 | Qwell | no, wrong one. |
| 14:39.35 | Marquis42 | mjordan: I <3 Go. It's different from your standard OO language for sure, and there are some things that aren't perfect, but I like it a lot. |
| 14:39.39 | Qwell | ...I always get those two confused. I give up. |
| 14:39.46 | Marquis42 | Swift, OTOH, makes me want to throw up in my mouth. |
| 14:40.13 | Qwell | (totally meant Stockholm) |
| 14:40.41 | putnopvut | Rewrite Asterisk in Rust...now! |
| 14:40.53 | mjordan | putnopvut: what could go wrong? |
| 14:40.56 | WIMPy | was already wondering how riding canon balls fits in here. |
| 14:40.57 | putnopvut | nothing |
| 14:40.58 | jameswf | When can we see Asterisk in Rails |
| 14:41.33 | gtjoseph | COBOL FTW |
| 14:41.41 | jameswf | Basica |
| 14:42.01 | jameswf | my first language was basic.... those were the days |
| 14:42.05 | Corydon76-home | Eh, the basic work was done in res_perl already. We just need to work out the bugs. |
| 14:42.26 | Corydon76-home | I nominate anybody but me to work on that. |
| 14:43.11 | jameswf | I nominate Qwell: the patron saint of lost causes... |
| 14:43.12 | mjordan | or... Stasis. |
| 14:43.16 | mjordan | or rather, pbx_stasis. |
| 14:43.22 | mjordan | and let the masses pick the language they want. |
| 14:43.37 | putnopvut | I pick whitespace! |
| 14:43.43 | putnopvut | <PROTECTED> |
| 14:43.57 | putnopvut | That was a TCP server implementation |
| 14:44.04 | mjordan | +1 |
| 14:44.20 | WIMPy | Just reduce Asterisk to a library and let people chose where to include it. |
| 14:44.49 | Corydon76-home | WIMPy: you know that's how Asterisk was made to run (poorly) on Windows, right? |
| 14:45.03 | WIMPy | Nope |
| 14:45.09 | jameswf | http://en.wikipedia.org/wiki/Binary_lambda_calculus |
| 14:45.38 | Corydon76-home | Yeah, everything in the core was made into a library, and then there was a thin wrapper that loaded and ran it |
| 14:45.48 | ipengineer | In marks patch to fix MWI subsciption (https://reviewboard.asterisk.org/r/3344/) what is the best way to subscribe to a mailbox? Previously I had the mailbox set in the aor and ps_endpoints tables. No matter what combination I either get “AOR 201 has no configured mailboxes. MWI subscription failed” or “Endpoint '200' already configured for unsolicited MWI for mailbox '200'. Denying MWI subscription to 200” |
| 14:46.13 | Corydon76-home | I don't believe any of the modules were unload'able, though |
| 14:46.34 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-ckveigmfsudcldmm) |
| 14:47.26 | putnopvut | ipengineer: If you want to have your devices subscribe to the mailbox, you have to specify the mailbox in the AOR, and only the AOR. |
| 14:49.20 | jameswf | speaking of voicemail.... I keep looking at my list of things to do and see write a voicemail implementation... then I come to my senses..... someone with more beer in their fridge should get on that.... |
| 14:49.43 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:49.44 | ipengineer | putnopvut: So with that configuration I get “Endpoint ‘200’ already configured for unsolicited MWI for mailbox '200@main’. Denying MWI subscription to 200” |
| 14:51.58 | putnopvut | Do you have a mailbox= line for endpoint 200? |
| 14:52.39 | pabelanger | jameswf, plan to do something in the next month or so. Should be straightforward for my needs, as I don't need MWI. |
| 14:52.44 | putnopvut | Specifically a mailbox=200@main line for endpoint 200? |
| 14:53.11 | ipengineer | putnopvut: no only on the aor |
| 14:53.15 | ipengineer | putnopvut: https://gist.github.com/zconkle/98493cab765675de0b53 |
| 14:54.13 | pabelanger | jameswf, How ever, I don't think it would be hard to write a script to generate a NOTIFY message on top of pjproject |
| 14:55.43 | mjordan | pabelanger: this already does that for you, and is independent of the channel driver implementation: https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Mailboxes+REST+API |
| 14:55.48 | putnopvut | ipengineer: the error message is saying that an endpoint called "200" is trying to subscribe to MWI. The paste you just linked me to is showing stats for an endpoint called 201 |
| 14:56.13 | ipengineer | putnopvut: same problem for both endpoints. I have this 201 in front of me |
| 14:56.55 | ipengineer | putnopvut: I just added the NOTICE to the comment |
| 14:57.22 | putnopvut | okay, refreshing... |
| 14:57.42 | pabelanger | mjordan, how does a mailbox related to a SIP peer? I assume there is some sort of configuration setup? |
| 14:58.06 | mjordan | pabelanger: how does a sip peer normally relate itself to a mailbox? :-) |
| 14:58.34 | pabelanger | okay, so you setup mailbox=foo in sip.conf / pjsip.conf then |
| 14:58.36 | putnopvut | ipengineer: brb. meeting |
| 14:58.41 | ipengineer | k |
| 14:59.07 | mjordan | yup. In which case, you would issue PUT /mailboxes/foo?newMessages=2 |
| 14:59.12 | mjordan | and blinky light goes off |
| 14:59.37 | pabelanger | Any way to pass the sip credentials into a mailbox with pre-creating the sip settings? |
| 14:59.47 | mjordan | I don't understand that question |
| 15:01.11 | pabelanger | I don't think it is possible |
| 15:01.43 | file | don't think what is possible? |
| 15:02.22 | pabelanger | but, wanted to generate a SIP NOTIFY (mailbox I guess) without asterisk having knowledge of the SIP peer. I'd like to just pass the information about where to send the notify too. EG: PUT /mailbox/alice@example.org?newMessages=2 |
| 15:07.18 | *** join/#asterisk-dev moy (~moy@198.199.91.192) |
| 15:13.52 | ipengineer | putnopvut: When you return just so you know the MWI subscriptions are working those notices are just being thrown every couple seconds for every subscription |
| 15:19.42 | file | the mailbox resource does not allow you to specify specific devices, as the core does not work like that. |
| 15:26.09 | pabelanger | file, Ya, thats what I suspected |
| 15:26.44 | pabelanger | basically, I didn't want my voicemail server to know about SIP accounts. However, still need something to fire off MWI |
| 15:27.39 | mjordan | you probably need something other than Asterisk then, since Asterisk not knowing about SIP accounts would be rather counterproductive for most of its use cases |
| 15:28.48 | pabelanger | Right, like I said. The voicemail functionality is basically and IVR run on asterisk, but MWI is triggered using something else. |
| 15:29.10 | putnopvut | ipengineer: that's really strange. Those two things (the subscriptions working, and the NOTICE message being emitted) should be mutually exclusive. I'm having a look at the code to see if there's something stupid happening. |
| 15:30.06 | ipengineer | Ok. Let me know if I can do anything on this end |
| 15:34.55 | putnopvut | ipengineer: so here's a question for you. Did endpoint sip201_baaaaac once have a mailbox set on it when Asterisk started up? And if it did, did you remove the mailbox and just do issue a 'pjsip reload' or 'module reload res_pjsip.so' in order to apply the new endpoint configuration? |
| 15:35.34 | ipengineer | Yes it had it. I did not reload or restart. But the message changed so I figured it took hold. Let me issue a reload |
| 15:37.46 | ipengineer | so after a module reload res_pjsip.so I still get the same message. After doing a full “reload” I am no longer seeing it. I initially didnt think I was seeing the MWI subscriptions but it was my device |
| 15:39.43 | putnopvut | Yeah, so it sounds like what I would expect (as the person that has viewed the code) but not what I would expect as a user. The problem is that res_pjsip_mwi, at startup goes through endpoint configuration and sets up unsolicited MWI for all endpoints with mailboxes configured on them. That's fine. What's not so fine is, there is no way currently, outside of a reload of res_pjsip_mwi.c, to update this list of unsolicited M |
| 15:39.43 | putnopvut | WI if endpoint configuration changes or if new endpoints are added. |
| 15:40.14 | putnopvut | What's needed is for res_pjsip_mwi to have a sorcery observer so that when endpoint configuration changes, the container of unsolicited MWI can be updated appropriately, and you won't see this mess any more :) |
| 15:40.31 | file | and profit. |
| 15:40.38 | putnopvut | Yeah, profit |
| 15:41.20 | ipengineer | putnopvut: Ok makes sense. So even creating new endpoints and setting things correctly will need a reload issued until an observer can be put in place |
| 15:43.19 | file | you'll always need a reload to reload pjsip.conf |
| 15:43.36 | ipengineer | file: they are realtime |
| 15:44.14 | file | ah, you'll still need a reload to update the pubsub stuff - the sorcery stuff doesn't constantly poll your database |
| 15:45.31 | ipengineer | file: so anytime we add or update an extension we should issue: “module reload res_pjsip.so”? |
| 15:46.30 | file | I'd issue a reload on res_pjsip_mwi.so |
| 15:46.36 | ipengineer | ok |
| 15:46.48 | file | it's the one that needs to be made aware of the update, other stuff will get it as needed |
| 15:47.12 | file | but in the case of state stuff without constantly polling or expiring stuff it has to be told |
| 15:47.31 | mjordan | good lord. Trying to find when an API was added to OpenSSL is maddening. |
| 15:47.46 | putnopvut | I find most OpenSSL documentation to be maddening |
| 15:48.23 | file | I find OpenSSL to be maddening |
| 15:48.48 | coreyfarrell | Qwell, jsmith, jameswf: I actually did start a res_v8 like a year ago (v8 is the engine node.js is based on). seemed to be "ok", but I assumed that C++ would not be wanted in asterisk so I stopped. |
| 15:49.21 | mjordan | even more maddening: 1.0.0 has the offending API that broke the build, but 1.0.0-fips does not |
| 15:49.52 | file | this is why friends don't let friends use OpenSSL |
| 15:50.17 | ipengineer | file: Ok. Now where putnopvut was talking about placing an observer on res_pjsip_mwi that will no longer be necessary correct? |
| 15:51.26 | file | it is useful for automatically doing it when res_pjsip is reloaded |
| 15:51.39 | mjordan | wtf. 0.9.8 has ec.h, but 1.0.0-fips on CentOS does not? |
| 15:51.58 | mjordan | Suddently, I feel extraordinarily good about Asterisk's versioning |
| 15:52.13 | ipengineer | file: Ok makese sense. Thx |
| 15:52.47 | file | mjordan, Achievement Unlocked: Experience the hellishness of OpenSSL feature variability. |
| 15:55.05 | Corydon76-home | Hence why configure scripts test for functionality rather than testing for versions |
| 15:56.12 | mjordan | yeah, I think that's about the only thing to do here. *YAY*. |
| 15:57.23 | coreyfarrell | mjordan: http://upstream-tracker.org/ - probably less useful for openssl than most libraries but still has useful information |
| 16:48.44 | mjordan | Unbreak the build: https://reviewboard.asterisk.org/r/3709/ |
| 16:57.30 | mjordan | Does anyone want to take another look at r3698 after Corydon76-home's findings? |
| 16:59.19 | mjordan | rmudgett: do you mind committing https://reviewboard.asterisk.org/r/3633/? If we make RCs of Asterisk 11 right now, we'd end up breaking some people |
| 17:12.23 | rmudgett | mjordan: I was waiting on the reporter to test my alternate patch. The Q.931 section he referenced pointed out that we were no longer complying. If we don't send any digits in the SETUP the switch doesn't have to send a progress indication ie for inband information available (i.e. dialtone). |
| 17:12.41 | pabelanger | know issue with asterisk 11 coredumping on startup? |
| 17:12.42 | pabelanger | http://pastebin.com/jHKLVLcu |
| 17:13.29 | mjordan | pabelanger: no, there is no issue for that. Looks like your asterisk.conf is invalid. |
| 17:15.23 | mjordan | rmudgett: is there any risk to the patch you've proposed? Or are we really just wanting confirmation? |
| 17:15.52 | rmudgett | mjordan: I was just wanting confirmation. I've only just compiled it. |
| 17:16.06 | mjordan | :-( |
| 17:25.05 | pabelanger | figured it out, asterisk 11 looks to use more memory then 1.8, so had to increase my swap size |
| 17:36.15 | pabelanger | okay, I lied |
| 17:36.24 | pabelanger | using the default samples I cannot get it to work |
| 17:36.37 | file | what is the processor? |
| 17:37.49 | pabelanger | model name: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz |
| 17:38.03 | file | should be fine... are you virtualized at all? |
| 17:38.08 | pabelanger | yes |
| 17:38.12 | pabelanger | kvm |
| 17:38.39 | file | try disabling NATIVE_BUILD in menuselect |
| 17:38.49 | pabelanger | please standby |
| 17:40.20 | pabelanger | Yup |
| 17:40.25 | pabelanger | now it works |
| 17:43.58 | pabelanger | So, the issue is with GCC detecting the CPU properly? |
| 17:44.28 | file | it's probably detecting it fine, KVM just might not like whatever GCC has decided to do |
| 17:45.18 | pabelanger | Hmm, something changed in asterisk I think, since this worked 1.8. |
| 17:45.23 | pabelanger | time for svn blame |
| 17:46.23 | file | yes, it did change, ages ago and there was a discussion on -dev I believe about it |
| 17:47.04 | file | but I don't remember the details as it was so long ago |
| 17:47.34 | file | in a galaxy far far away |
| 17:48.21 | mjordan | sighs |
| 17:49.43 | file | mjordan, quite |
| 17:49.45 | mjordan | pabelanger: https://issues.asterisk.org/jira/browse/ASTERISK-20128 |
| 17:50.01 | mjordan | with a proposed solution that did not work for everyone on https://issues.asterisk.org/jira/browse/ASTERISK-21967 |
| 17:50.18 | mjordan | you're running a pretty ancient version of 1.8 if you haven't run into that yet :-) |
| 17:50.39 | mjordan | The old compilation behaviour resulted in Asterisk simply not building at all on certain machines, and there was no way to make it compile |
| 17:50.59 | mjordan | So we went with a 'stop guessing' method, which unfortunately means that now we have a completely different problem |
| 17:51.06 | mjordan | but at least you can do something about it in menuselect |
| 17:51.30 | mjordan | alas, no one has yet provided a patch that (a) does not reproduce the old broken behavior or (b) is better than we what we have today and also fixes the problems people are seeing |
| 17:51.32 | mjordan | \o/ |
| 17:51.51 | mjordan | That would be a very sarcastic \o/ |
| 17:54.57 | pabelanger | 1.8.7.1 with backports baby! |
| 17:55.12 | pabelanger | okay, for now will update build system |
| 17:55.30 | pabelanger | will have to dive in deep and read the history of the issues |
| 17:55.35 | pabelanger | I remember it now |
| 17:59.58 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-frxdirlkrbkgkwkt) |
| 18:08.54 | putnopvut | mjordan: out of curiosity, do you know how many lines of code are being removed in review 3698? |
| 18:13.02 | mjordan | nope. I didn't count it. code.asterisk.org should tell us when it goes in |
| 18:14.49 | putnopvut | okay, was just wondering if you had done that analysis already or not. |
| 18:16.09 | putnopvut | It's got to be 15000+ |
| 18:19.15 | pabelanger | any ideas with my SDP is invalid to asterisk 11? |
| 18:19.16 | pabelanger | http://pastebin.com/sejeGbru |
| 18:21.14 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 18:26.18 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 18:27.38 | mjordan | pabelanger: where it the CRLF separating the SIP message headers from the message body? |
| 18:28.04 | putnopvut | Yeah, there needs to be a blank line between the final SIP header and the message body. |
| 18:34.16 | mjordan | WebRTC: you only have to be interoperable with the browsers! Unless that browser doesn't support it, in which case you have to interoperate with a plugin. Oh yeah, and different SIP stacks, which behave differently with each browser. |
| 18:36.42 | mjordan | the best part is, that SDP was 'simple' when you think of all the other things that could have been put into it. |
| 18:37.15 | mjordan | that's a single audio stream. Imagine a conference that was bundling 4 or more audio streams together. |
| 18:37.19 | mjordan | ew. |
| 18:46.34 | pabelanger | mjordan, putnopvut: between line 18 and 19 right? |
| 18:46.48 | putnopvut | pabelanger: yes |
| 18:48.28 | pabelanger | okay, looks like kamailio might be the issue |
| 18:52.41 | jsmith | pabelanger: Oh? |
| 18:56.26 | pabelanger | okay fixed |
| 18:56.38 | pabelanger | configuration error between 3.3 and 4.1 |
| 18:56.59 | pabelanger | putnopvut, mjordan: such beer, many drinks |
| 19:00.31 | putnopvut | is ready for the three-day weekend |
| 19:06.18 | jsmith | is going to have to come back to work on Monday just to take a break |
| 19:07.06 | pabelanger | AVPF is specific to webrtc right? |
| 19:07.28 | file | it predates WebRTC, but it is used by it |
| 19:09.39 | pabelanger | Is there such thing as a RTP/AVPF to RTP/AVP proxy? |
| 19:10.04 | pabelanger | actually, I think mediaproxy-ng is what I am looking for |
| 19:12.46 | file | there's encryption to do as well... and ICE negotiation... |
| 19:12.51 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:12.51 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:28.42 | jameswf | will just leave this here... http://pbxinaflash.com/community/index.php?threads/piaf3-with-fedora-20.15090/page-2#post-98056 |
| 19:43.05 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 20:07.55 | coreyfarrell | file: is diff 3 of your mf-attributes review just a merge of latest media_formats-reviewed-trunk or am I looking for other changes? |
| 20:08.09 | file | just a merge |
| 20:16.59 | coreyfarrell | file: so I'm not sure this is an issue, is it ok to ao2_bump a const parameter (ast_format_attribute_set for example)? feels a bit dirty.. I know technically we're not actually modifying the 'struct ast_format' part of it, so maybe that's what matters? |
| 20:17.54 | file | it's fine to do it |
| 20:17.57 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-hncdnfiaearlyvfm) |
| 20:18.19 | leedm777 | mjordan: hi! |
| 20:18.20 | mjordan | leedm777: welcome! So, we've always had the notion in ARI that originating a channel into a Stasis application creates an implicit subscription to it |
| 20:18.36 | mjordan | in fact, we have code in the origination handling in ARI that explicitly checks to see if you're sending the channel into an app |
| 20:18.40 | mjordan | and if so, we subscribe |
| 20:18.53 | leedm777 | okay. |
| 20:19.04 | mjordan | which is a bit interesting, because that app may not be Stasis... but whatever. |
| 20:19.12 | mjordan | it does it anyway! |
| 20:19.22 | mjordan | However, if the channel you are creating is a Local channel, you technically get two channels |
| 20:19.32 | mjordan | one of which goes into the application you've specified, the other off to dialplan |
| 20:19.43 | coreyfarrell | file: ok thanks.. enjoy your weekend! |
| 20:19.47 | mjordan | you get subscribed to one half of the Local channel pair you've just created, the other is off doing mysterious things |
| 20:20.08 | leedm777 | with you so far. |
| 20:21.31 | mjordan | now then. Theoretically, we can easily subscribe to both halves before we send the dialplan bound half off |
| 20:22.00 | mjordan | in fact, we can do it directly when we do the origination |
| 20:22.23 | mjordan | this is "nice", because now when you create a Local channel for your Stasis application, you get events about what the other half is doing off in dialplan land |
| 20:22.30 | mjordan | The real question is: is this a breaking change? |
| 20:22.41 | mjordan | or rather, is this a bug? |
| 20:22.59 | leedm777 | that is interesting. |
| 20:23.03 | mjordan | I think we can safely say that it isn't breaking, since the events you're getting are above & beyond what you normally get, but they aren't changing what you got before |
| 20:23.17 | leedm777 | make sense. |
| 20:23.17 | mjordan | Arguably, however, this was an oversight |
| 20:23.56 | leedm777 | hm. |
| 20:23.58 | mjordan | generally, if you created a SIP channel and sent it off to your Stasis application, you would expect to get events for it. The same would be said for any channel you created; Local channels are just extra fun since one Local channel always implies 2 |
| 20:24.53 | mjordan | a part of me kind of wants to just bite the bullet and make it a backwards compatible change regardless by providing (yet another) query parameter to POST /channels |
| 20:24.58 | mjordan | that says "please subscribe me" |
| 20:25.02 | leedm777 | yeah, I agree. This feels very much like a "backwards-compatible bug fixes" where "bug fix is defined as an internal change that fixes incorrect behavior" |
| 20:25.07 | mjordan | unfortunately, we need to keep the implicit subscription when it goes to your app |
| 20:25.35 | leedm777 | I wouldn't go that far. |
| 20:25.37 | mjordan | in the interest of expediency, I'd be happy to label this as a bug fix personally as well however :-) |
| 20:25.45 | leedm777 | it really does seem like it's an oversight. |
| 20:25.49 | mjordan | leedm777: what, more query parameters aren't good? :-P |
| 20:26.04 | leedm777 | MOAR PARAMS!!!! |
| 20:26.05 | file | I'd say bug fix :P |
| 20:26.19 | mjordan | \o/ |
| 20:26.21 | leedm777 | I would say the extra param should only be allowed if you name it ?cowbell |
| 20:26.38 | file | JustFixIt(tm) |
| 20:26.58 | mjordan | leedm777: thanks. Trying very hard to stick to semantic versioning. |
| 20:27.27 | leedm777 | Yeah. You still get all the events you got before; but now you're also getting the events you should have gotten before. |
| 20:44.34 | *** join/#asterisk-dev sgriepentrog (~sgriepent@50.247.43.97) |
| 20:46.11 | *** join/#asterisk-dev Qwell (north@pdpc/sponsor/digium/Qwell) |
| 20:46.11 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 20:54.04 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 21:10.32 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 21:23.42 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 21:41.39 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 21:57.32 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 22:23.00 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 22:34.10 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-jywuoyetutlwbopm) |
| 22:45.29 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 22:45.29 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:26.32 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:29.24 | ipengineer | Was pjsip header functionality ever shipped? https://reviewboard.asterisk.org/r/2858/ No such application 'PJSIP_HEADER’, No such application 'PJSIPAddHeader' |
| 23:30.23 | ipengineer | Ahh its a SET forgive me. I was looking at something else in the Wiki |
| 23:39.31 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:39.31 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:50.10 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |