| 00:18.11 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 03:38.08 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 07:03.34 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:09.12 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:797e:6663:1615:b584) |
| 07:35.28 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 07:35.28 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 07:36.35 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.115) |
| 07:39.22 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lstlambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 15:18.46 | *** join/#asterisk-dev infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 15:18.46 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 15:24.19 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-fqieovimammikitx) |
| 15:24.19 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:28.01 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-cfkfhutoaeybtwra) |
| 15:28.01 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:35.41 | seanbright | i uploaded a patch for him to test |
| 15:59.17 | *** join/#asterisk-dev andresalo (~andres.al@223.red-83-61-5.staticip.rima-tde.net) |
| 16:02.26 | *** join/#asterisk-dev spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |
| 16:31.35 | *** join/#asterisk-dev spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |
| 16:48.34 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.105) |
| 17:49.46 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 18:38.50 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-nan-1-1527-95.w90-93.abo.wanadoo.fr) |
| 19:33.14 | kharwell | what exactly are the ast_channel_nativeformats? It appears they are formats set after original negotiation. But then I see them get read, and/or set in other places |
| 19:33.42 | file | they're the negotiated formats, although formats is... erm |
| 19:33.57 | file | depending on the configuration of a PJSIP endpoint they may contain multiple formats, or a single format |
| 19:34.23 | kharwell | are they set only after applying negotiation or also up incoming? |
| 19:34.54 | kharwell | in set_caps the check is "if (session->channel && ast_sip_session_is_pending_stream_default(...))" |
| 19:35.07 | file | I think they're set when the channel is created and updated based on the result |
| 19:35.13 | file | and they only contain the formats for the first stream of each type |
| 19:35.21 | file | which is to preserve backwards compatibility |
| 19:37.45 | kharwell | hrm. So should those be set then just after "incoming". As in do I settle on the incoming joint codecs and then set the native with those? |
| 19:37.55 | kharwell | which may later get updated of course when applying |
| 19:38.34 | file | you can, essentially it should eventually reflect the actual negotiated codecs |
| 19:39.06 | kharwell | I guess the problem I'm running into is set_caps gets called from "incoming" and "applying". I'm trying to figure out what all needs to be set for each, or does everything need to happen for everything in that function |
| 19:39.52 | file | so technically incoming is not supposed to touch stuff if it can, while apply is where you update everything |
| 19:39.58 | file | it's two stage |
| 19:40.00 | kharwell | I'm wondering if that function, set_caps, should be split into two. One for incoming, and one for applying. And then what needs to be set then in each of those |
| 19:40.51 | kharwell | okay yeah so sounds like set_caps got a bit overloaded. I'm thinking I'll split it out. Should make things easier to follow and know what is exactly happening at what stage in the process |
| 19:41.24 | file | aye |
| 19:42.07 | kharwell | so in incoming then I'm thinking just get the codecs from the sdp, get them from the endpoint config, and then order them based upon the new pref option and that's pretty much it |
| 19:42.19 | kharwell | leave the rest to happen in "apply" |
| 19:42.24 | file | sounds like it |
| 19:42.29 | file | (famous last words) |
| 19:42.33 | kharwell | heh |
| 19:42.41 | gtjoseph | another t-shirt slogan... " so sounds like _______ got a bit overloaded" |
| 19:43.24 | file | it happens |
| 19:43.47 | kharwell | surely those 1000+ line functions are only doing one thing |
| 19:44.27 | gtjoseph | on a more serious note... should we just go ahead and remove any of the backwards compatibility stuff? |
| 19:44.37 | file | you can't |
| 19:44.48 | file | (in regards to nativeformats and stuff) |
| 19:44.52 | gtjoseph | in 18? |
| 19:44.54 | gtjoseph | no? |
| 19:45.05 | file | it's far reaching, it touches everywhere |
| 19:45.19 | gtjoseph | ok maybe asterisk 19 then |
| 19:45.24 | file | doubtful |
| 19:45.27 | file | when I say everywhere I mean everywhere |
| 19:45.39 | file | everything that interacts with media basically |
| 19:45.47 | file | generally has some interaction with the old stuff |
| 19:45.53 | gtjoseph | ok, 30 then |
| 19:46.09 | file | we could make progress and change stuff behind the scenes and move stuff over |
| 19:46.30 | gtjoseph | 40? |
| 19:46.44 | file | 19 is possible to a degree |
| 19:47.18 | file | I'd suspect to really transition everything away from the old nativeformats/readformat/writeformat is more likely later |
| 19:48.09 | kharwell | file: so next holiday weekend then? |
| 19:48.24 | seanbright | is it a "we can't deprecate them" thing or "it would be a lot of work" thing? |
| 19:48.35 | file | seanbright: it's a ton of work |
| 19:48.39 | gtjoseph | we should probably stop winding him up |
| 19:48.57 | seanbright | work that requires thinking or just grunt work? |
| 19:49.01 | file | both |
| 19:49.14 | seanbright | thinking work up front and then grunt work at the end? |
| 19:49.35 | file | thinking work up front, grunt work, then thinking as "well I didn't think of THAT" comes up |
| 19:49.42 | seanbright | gotcha |
| 19:49.47 | file | I've been down this road before when redoing media formats |
| 19:49.51 | kharwell | sounds like normal bug fixing |
| 19:49.59 | seanbright | i was thinking that before we cut 18 we should have a deprecation party |
| 19:50.22 | seanbright | if we can't remove shit for 4 years, i would like to deprecate things that suck sooner than later |
| 19:50.38 | kharwell | instead of AstriDevcon AstriDeprecateCon? |
| 19:50.51 | seanbright | basically |
| 19:50.59 | seanbright | at devcon it will be too late |
| 19:51.16 | file | with a party comes cake |
| 19:51.18 | file | mmm cake |
| 19:51.23 | seanbright | i will send everyone cake |
| 19:51.37 | seanbright | did someone say fudgy the whale? |
| 19:52.04 | seanbright | fudgie* |
| 19:53.35 | kharwell | It appears Fudgie has been around a while |
| 19:55.09 | kharwell | Also what about direct_media capabilities. I'm guess those get set after incoming as well? Or potentially sometime between incoming and applying? |
| 19:55.32 | seanbright | i do not envy you, kharwell |
| 19:55.41 | seanbright | sucks to draw the short straw |
| 19:56.22 | kharwell | apparently I was even the one that cut the straws |
| 19:56.35 | seanbright | rookie mistake. |
| 19:57.18 | seanbright | too soon to deprecate chan_audiosocket? |
| 19:57.21 | seanbright | (kidding) |
| 19:58.26 | seanbright | static realtime? |
| 19:58.41 | seanbright | normal realtime? |
| 19:58.48 | seanbright | i'll show myself out |
| 20:03.19 | file | Direct media gets set when told by rtp glue if I recall |
| 20:26.00 | kharwell | yeah gets setup by the glue. But can't tell if that happens after the initial setting of things on incoming. I'm pretty sure it is after. Cause before that all we have is the channel, and I don't think a bridge at that point |
| 20:26.23 | file | right |
| 20:27.14 | kharwell | plus it gets the caps from the native formats. Which are set potentially at incoming |
| 20:49.36 | *** join/#asterisk-dev spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |