| 00:39.01 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 01:19.11 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 01:23.48 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 01:23.48 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:35.39 | coreyfarrell | does anyone have an idea of the performance between ao2_find with a string key vs AST_RWLIST traversal? with refdebug disabled... would it just be a question of how many entries are expected in the list or container? |
| 01:37.24 | rmudgett | coreyfarrell: Well the ao2_find performance is going to depend on the container type. list/hash/rbtree |
| 01:38.44 | coreyfarrell | hmm, I've honestly always just used ao2_container_alloc, I would want to use the one best to do lookups by string key. |
| 01:39.32 | rmudgett | ao2_container_alloc creates a hash container. Once the key selects a bucket then it is a list search. |
| 01:39.47 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-lmukmqbmbmzqitri) |
| 01:40.42 | rmudgett | ao2_containsers do have a larger node-to-node overhead than the list macros. |
| 01:41.45 | rmudgett | The overhead would be slight as the ao2_containers have a node object pointing to the object stored. |
| 01:45.15 | rmudgett | The overall performance will depend on the number of entries in the container and if the node traversal overhead has any significant effect. |
| 01:48.47 | coreyfarrell | so I'm working on a new module loader, I'm trying to make unregistration of things thread safe. for example to prevent the race between a channel entering Monitor and res_monitor unloading. |
| 01:49.38 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-ypjjogfggtwhvgsi) |
| 01:49.38 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:55.43 | coreyfarrell | one thing that would make this much easier is if the objects that are registered are ao2 objects. using ao2_find isn't really a major requirement, but reference counted lifetime of the registered objects is. this way if one thread unregisters while another is trying to use the object, it will delay freeing the object. |
| 01:58.53 | coreyfarrell | so I'm not sure if hash/rbtree lookup would partly compensate for the overhead caused by ao2_ref, or if it would just be that much more overhead. |
| 02:00.24 | rmudgett | Well getting it right is much better than just doing it fast. :) |
| 02:02.33 | coreyfarrell | yeah, so my new module loader automatically unregisters most things (cli, apps, dialplan, manager actions, sorcery, half dozen others). then I realized that almost all of them could be subject to a lock order deadlock :( |
| 02:04.08 | coreyfarrell | the only ones that I think are safe during unregister is sorcery wizards and manager actions (both use ao2 for the registered items). |
| 02:14.35 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-ypjjogfggtwhvgsi) |
| 02:25.16 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 02:55.01 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 03:17.33 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-eshkwhnyltswthra) |
| 03:17.33 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:41.02 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 03:41.02 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:46.39 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 04:46.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:00.47 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:09.43 | *** part/#asterisk-dev oron (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 07:18.03 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:22.22 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:22.22 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:53.22 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:17.49 | *** join/#asterisk-dev oej (~oej@2a03:f0c0:1001:1000:8827:e149:b104:265) |
| 08:17.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:29.38 | stefan27 | Hi... |
| 10:29.41 | *** join/#asterisk-dev MrTAP (~MrT@76-10-185-74.dsl.teksavvy.com) |
| 10:51.27 | *** join/#asterisk-dev oej (~oej@2a03:f0c0:1001:1000:8827:e149:b104:265) |
| 10:51.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:02.14 | *** join/#asterisk-dev oej (~oej@2a03:f0c0:1001:1000:8827:e149:b104:265) |
| 11:02.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:22.17 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:22.17 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:49.08 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-giqcxsimwnlntyhq) |
| 11:49.08 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:52.20 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 11:52.21 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 11:53.57 | stefan27 | Hi... New kind of seg-fault: http://pastebin.com/xiZtCPgx I have not created JIRA yet, but it looks like bridge_basic.c in function bridge_move, bridge_channel is 0x0 even though ast_assert(bridge_channel != NULL); was executed 2 lines above... What does ast_assert do if condition is false?? also why isn't the assert within the ao2_lock/unlock scope? |
| 11:55.37 | file | the fix for that went in half an hour ago |
| 11:56.09 | file | https://issues.asterisk.org/jira/browse/ASTERISK-25003 |
| 11:57.10 | stefan27 | ??? |
| 11:57.40 | stefan27 | what a coincident |
| 11:57.59 | stefan27 | Hasn't that 'bug' been around for ages? |
| 11:58.08 | stefan27 | I discovered it 2 hours ago |
| 11:58.42 | stefan27 | Thanks file |
| 12:00.00 | file | ages is relative, it only exists within 12+ |
| 12:02.33 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:05.06 | stefan27 | which is the first 13.x release that will have that commit? |
| 12:05.41 | file | 13.4.0 |
| 12:12.53 | mjordan | I measure my bug times in years. |
| 12:13.04 | stefan27 | what does ast_assert(0) do btw? |
| 12:13.09 | *** join/#asterisk-dev oej (~oej@217.142.152.56) |
| 12:13.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:13.16 | mjordan | fail |
| 12:13.26 | mjordan | it will always throw an assertion |
| 12:13.48 | mjordan | that's useful when something has taken a wrong path, and you want to assert without re-evaluating the condition |
| 12:14.04 | mjordan | note that assertions don't show up unless you compile with -dev-mode, and preferably, DO_CRASH |
| 12:16.21 | stefan27 | Not familiar with C assertions... without -dev-mode ast_assert(0) returns and control is giving to next statement? |
| 12:16.52 | stefan27 | and nothing is logged anywhere? |
| 12:16.56 | mjordan | stefan27: No, without -dev-mode, ast_asserts don't exist. It's a macro that is #defined to nothing |
| 12:17.06 | stefan27 | Aha |
| 12:28.15 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 13:06.10 | mjordan | yay, that's one: https://bamboo.asterisk.org/bamboo/browse/AST-ATSF-C632TE-583 |
| 13:06.19 | mjordan | c'mon 64-bit machine, papa needs a new pair of shoes |
| 13:07.33 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-esdiwhlyrwxgfvhg) |
| 13:08.28 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 13:08.54 | stefan27 | You get a new pair of shoes if those tests pass? |
| 13:09.03 | stefan27 | :) |
| 13:09.37 | mjordan | pretty much! |
| 13:10.11 | mjordan | true story: I've been walking around barefoot at Digium for the past week |
| 13:13.12 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-jceooxpmbzvixiek) |
| 13:18.59 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-livbmhrbiperktmk) |
| 13:41.28 | DivideBy0 | mjordan: did you read "Born To Run" or just become "Barefoot Matt" on a whim |
| 13:45.10 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-giqcxsimwnlntyhq) |
| 14:08.30 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-bciqwkfhvgyhpzgl) |
| 14:09.33 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-uopjrlovqdletcnw) |
| 14:09.33 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:19.23 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 14:50.37 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-tkhqdemcmwjysyau) |
| 15:20.57 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-gdlvkhyidkmhmuji) |
| 16:52.08 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 16:52.08 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 18:14.19 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-buegsoogrtetszvw) |
| 18:15.59 | jameswf | has anyone done anything with Asterisk and ssdp? |
| 18:29.40 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-nvnxbznnvdzzflqa) |
| 18:41.00 | mjordan | jameswf: I haven't heard of anything using that |
| 18:47.17 | jameswf | mjordan: google didn't seem overly helpful. you would think asterisk and upnp would be natural friends |
| 18:47.58 | file | why so? |
| 18:49.08 | jameswf | because nat and firewalls suck, granted they have gotten better but they still suck |
| 18:49.08 | gtjoseph | the ability to open holes in firewalls maybe? |
| 18:50.03 | file | shrugs |
| 18:51.02 | jameswf | I was contemplating a node/python/php thing but if the wheel has been invented why redo all the work |
| 18:55.43 | gtjoseph | jameswf: are you thinking for rtp, sip or both? |
| 18:56.50 | jameswf | I would imagine in most cases both |
| 18:57.28 | jameswf | sip on tcp may be ok, that said sip on udp is rarely the issue. |
| 18:59.11 | gtjoseph | yeah it's usually rtp that's the issue. this might be a good candidate for a res_pjsip_upnp module. |
| 19:00.19 | mjordan | gtjoseph: Update the address/port in the RTP stack based on upnp information? |
| 19:00.36 | gtjoseph | nope, the other way round |
| 19:00.53 | gtjoseph | update the router/firewall dynamically to open the RTP ports |
| 19:06.55 | jameswf | this is by no means fool proof. Smart admins will have this crap turned off. but smart admins are probably not the ones who need this. This should make most calls through consumer routers seamless |
| 19:09.35 | *** join/#asterisk-dev MrTAP (~MrT@76-10-185-152.dsl.teksavvy.com) |
| 19:17.26 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-atpdssqnshzhchnk) |
| 19:38.37 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:38.37 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:44.29 | seanbright | so i'm pretty sure i know the reason that opus passthrough is not working - ASTERISK-24779 - but i am not sure what the appropriate fix is |
| 19:45.08 | seanbright | the rtpmap line in the SDP coming from one endpoint looks like: a=rtpmap:125 opus/48000/2 |
| 19:45.22 | seanbright | but when it is copied to the outgoing channel, it ends up like this: a=rtpmap:125 opus/48000 |
| 19:46.03 | seanbright | and from what i can tell, there is no way to persist the 'param' (pjsip's lingo) in the relevant rtp structures |
| 19:47.20 | seanbright | plus generate_rtpmap_attr in res_pjsip_sdp_rtp.c explicitly sets that value to the empty string |
| 19:50.02 | seanbright | i was thinking of adding a new function, similar to ast_rtp_codecs_payloads_set_rtpmap_type_rate, that would set the encoding parameters |
| 19:50.28 | seanbright | but that information doesn't appear to trickle down to generate_rtpmap_attr |
| 19:51.05 | seanbright | or maybe something like ast_rtp_lookup_sample_rate2 that instead looks up encoding parameters? seems a bit hacky though. |
| 19:55.26 | seanbright | anyway. looking for guidance if anyone has time. |
| 19:55.32 | mjordan | huh |
| 19:55.41 | mjordan | I'm pretty sure that used to work, too, which is odd. |
| 19:55.46 | mjordan | did we just hack something into chan_sip? |
| 19:56.07 | seanbright | yes |
| 19:56.32 | mjordan | blech. |
| 19:56.32 | file | I vaguely recall... something... nah, that was VP8 |
| 19:56.43 | seanbright | if (opus) { /* take on a 2 */ } else { /* don't */ } |
| 19:56.59 | mjordan | seanbright: yeah. We could shove that into something else too. |
| 19:57.00 | seanbright | s/take/tack/ |
| 19:57.26 | seanbright | mjordan: easy enough to hack in, but it feels dirty |
| 19:57.27 | mjordan | ponders. |
| 19:57.30 | mjordan | it is dirty |
| 19:57.39 | mjordan | it's also Opus, which decided to be interesting in a way that no one else was |
| 19:57.42 | seanbright | ideally encoding parameters would be copied from one invite to another in a passthrough situation |
| 19:57.50 | mjordan | yeah |
| 19:57.59 | mjordan | a format attribute pass through module |
| 19:58.14 | file | that's actually number of channels |
| 19:58.17 | mjordan | alas, I think those just add format attributes for a format, and doesn't change the RTP attribute |
| 19:58.26 | seanbright | file: i'm using RFC terminology |
| 19:58.45 | seanbright | a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>] |
| 19:58.50 | file | ah |
| 19:58.53 | seanbright | from RFC 4566 |
| 19:59.53 | seanbright | yeah, the format attribute modules have their own set of issues... if course i don't remember what they were |
| 20:00.06 | seanbright | i don't think you can get an ast_format * from them based on their interface |
| 20:00.13 | seanbright | i'd have to go back and look |
| 20:01.45 | kharwell | mjordan: regarding null app causing a crash is that being reopened? |
| 20:02.05 | seanbright | mjordan: file: https://gist.github.com/seanbright/5bf22b0b6deb9edc98b6 |
| 20:02.18 | seanbright | that was the format attr module problem i had |
| 20:02.30 | seanbright | unrelated to this i guess |
| 20:02.52 | mjordan | kharwell: Nope, that's getting backported |
| 20:02.57 | mjordan | or cherry-picked, as it were. |
| 20:03.25 | seanbright | mjordan: so would hacking to "/2" in via generate_rtpmap_attr() from res_pjsip_sdp_rtp.c actually be acceptable? |
| 20:03.27 | file | yay cherry picked |
| 20:03.33 | file | seanbright, I'd be fine with it myself |
| 20:03.40 | kharwell | mjordan: aah okay I saw the review(s) pop back up and thought something was wrong |
| 20:03.48 | seanbright | file: you are a crazy s.o.b. |
| 20:03.51 | seanbright | ok |
| 20:04.28 | file | meh - I prefer not to sweat the small stuff |
| 20:05.21 | kharwell | file: what about small to medium size stuff? |
| 20:05.34 | file | that's silly |
| 20:06.04 | mjordan | seanbright: I'm good with it as well. |
| 20:06.19 | mjordan | It's ugly, but it's a one off for something that isn't well represented elsewhere. |
| 20:15.58 | seanbright | ugh... SIP/2.0 200 Ok |
| 20:16.01 | seanbright | linphone blows |
| 20:16.09 | seanbright | lowercase 'k' |
| 20:16.10 | seanbright | pfffft |
| 20:23.27 | mjordan | lol |
| 20:24.13 | file | seanbright, be sad |
| 20:40.38 | gtjoseph | mjordan: we were applying git fixes to 1.8 no? |
| 20:41.15 | mjordan | er |
| 20:41.17 | mjordan | is that a git fix? |
| 20:41.25 | mjordan | I probably should have read it more carefully if so :-) |
| 20:41.36 | gtjoseph | yep. if you run make progdocs you have problems |
| 20:41.42 | gtjoseph | with modified files |
| 20:41.48 | gtjoseph | that shouldn't be |
| 20:42.15 | gtjoseph | jeez the title says "Make progdocs play nice with git" |
| 20:42.33 | mjordan | heh |
| 20:42.37 | mjordan | been a long day |
| 20:42.41 | mjordan | sorry gtjoseph :-P |
| 20:42.49 | gtjoseph | :) |
| 21:04.40 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-uopjrlovqdletcnw) |
| 21:43.14 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 21:47.08 | ipengineer | Had asterisk crash and create a dump file a little while ago and thought I would share⦠This one I guess is rtp related: https://gist.github.com/zconkle/e26db78ab1572ae0fb18 |
| 21:50.52 | coreyfarrell | is it possible to compile 1 specific file in main? For example if ccss.c is currently failing to compile but I still want to see if message.c will compile and inspect 'message.i'. |
| 21:53.42 | coreyfarrell | hmm, just figured it out, 'make main SRC=message.c' :) |
| 21:56.04 | *** join/#asterisk-dev newtonr (~RustyNewt@173-21-90-203.client.mchsi.com) |
| 21:56.04 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 23:16.53 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 23:17.40 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-bciqwkfhvgyhpzgl) |
| 23:34.40 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 23:55.28 | *** join/#asterisk-dev leedm777 (~leedm777@216.186.181.138) |
| 23:59.11 | *** join/#asterisk-dev snuff-work (~blatus@203.87.61.22) |
| 23:59.12 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |