| 05:44.18 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.99) |
| 06:17.39 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 08:44.54 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.117) |
| 09:02.03 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:e974:3bfa:e74a:f442) |
| 09:05.25 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:08.47 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lstlambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 10:57.13 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 13:54.32 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-yqxgegyzmuglphpk) |
| 13:54.32 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:00.34 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.99) |
| 15:22.26 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-kexyykexsqcmwvgd) |
| 15:22.26 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:38.05 | coreyfarrell | the new gerrit has a dark mode option in settings |
| 15:38.17 | gtjoseph | yep, that's what i use |
| 15:38.25 | kharwell | same |
| 15:38.41 | gtjoseph | actually the previous version had it as well |
| 15:38.58 | file | I think I'm one of the few who uses light mode across everything |
| 15:39.01 | gtjoseph | but you had to be using polygerrit |
| 15:39.16 | gtjoseph | too hard on my eyes especially at 4am :) |
| 15:40.18 | coreyfarrell | wonder why they don't use CSS `prefers-color-scheme: dark` to enable it by default. |
| 15:40.56 | gtjoseph | i wonder why they do a lot of things, or don't. |
| 15:41.02 | file | gtjoseph: I like sleep at that hour |
| 15:41.52 | gtjoseph | i'd like it at that hour as well |
| 15:41.59 | gtjoseph | doesn't seem to work out |
| 15:42.28 | gtjoseph | besides, who would keep you company that eraly? |
| 15:43.28 | seanbright | hmm. grid lines are too bright in dark mode. |
| 15:43.56 | gtjoseph | really? I don't see them bright at all |
| 15:44.22 | seanbright | visually jarring to me |
| 15:44.56 | gtjoseph | i guess it also depends on monitor brightness and contrast settings. |
| 15:45.46 | gtjoseph | i also run gmail in dark mode and the line are exactly the same |
| 15:50.08 | seanbright | https://i.imgur.com/KOggpZw.png |
| 15:50.17 | seanbright | left is what it is, right is what *I* think it should be |
| 15:50.25 | seanbright | i'll open an issue... |
| 15:50.41 | gtjoseph | ah |
| 19:07.21 | gtjoseph | anyone got opinions on my comments on https://gerrit.asterisk.org/c/asterisk/+/13065 ? |
| 19:07.59 | seanbright | i think #1 is a no-brainer |
| 19:08.33 | file | good thoughts! |
| 19:09.06 | seanbright | i don't understand the problem adequately to comment on the other 3 points |
| 19:09.35 | gtjoseph | Apparently the linphone client groups chats by the To header host. |
| 19:10.04 | gtjoseph | if it changes because the client changed ip addresses, then new messages aren't arranged correctly |
| 19:10.13 | seanbright | ah |
| 19:51.18 | kharwell | file: more bridging race condition info - alice calls bob, alice's session gets setup, bridging starts, native compat check fails, simple chosen, topologies compared, alice is done negotiating, bob still is thus inactive streams, comparison fails, re-invite sent to alice |
| 19:51.46 | kharwell | so it's bob's streams that are inactive due to negotiation not being complete on that leg yet |
| 19:52.25 | file | ah so it's to alice |
| 19:52.45 | kharwell | so when it goes to send the refresh for alice that leg is setup so no delay |
| 19:53.58 | file | I think that stream should be sendrecv |
| 19:54.06 | file | even though negotiation is not yet complete |
| 19:54.33 | kharwell | I believe the default is inactive. So maybe change to sendrecv on alloc? |
| 19:54.47 | file | I wouldn't go that far... because that may cause ripples |
| 19:54.57 | file | but when a PJSIP channel is originated I think the topology should be sendrecv |
| 19:55.08 | file | or rather, requested/dialed... |
| 19:55.24 | file | unless a requested topology is passed in |
| 19:55.52 | kharwell | chan_pjsip_new? |
| 19:55.58 | file | yeah |
| 19:57.38 | kharwell | what do you mean by passed in then? I see it's cloned from either pending or the endpoint.media->topology and then set on the channel |
| 19:58.05 | file | chan_pjsip_request_with_stream_topology |
| 19:58.14 | file | when you request a PJSIP channel, you can pass in a stream topology to use |
| 19:58.42 | file | in that case I don't think having it be sendrecv is correct, since something has been explicitly requested |
| 19:59.08 | file | so you'd need to determine what is occurring in this scenario, what case is being executed |
| 19:59.12 | kharwell | but if it is not passed in then it's NULL? |
| 19:59.33 | file | I think so, and then it is taken from the endpoint topology you mentioned |
| 20:00.15 | kharwell | hrm that function is passed a topo, but it appears to be created everytime prior by ast_stream_topology_create_from_format_cap |
| 20:00.20 | kharwell | so won't be NULL unless error |
| 20:00.44 | file | ast_stream_topology_create_from_format_cap sets it to sendrecv |
| 20:01.12 | kharwell | oh indeed it does |
| 20:01.13 | kharwell | hrm |
| 20:01.34 | file | so where oh where is ye ol' 0 coming from |
| 20:01.36 | kharwell | so then it's gotta be set explicitly to inactive someplace |
| 20:02.22 | kharwell | I'm only finding the one other spot in handle_negotiated_sdp_session_media (res_pjsip_session) |
| 20:02.48 | kharwell | which shouldn't be called yet and also the incoming sdp would have to be "inactive" |
| 20:02.54 | file | exactly. |
| 20:03.30 | file | you may want to trace it back up the request path - spit it out in chan_pjsip_new, follow it back up into the core |
| 20:03.32 | file | that kinda thing |
| 20:03.54 | kharwell | default is sendrecv right if not specified in sdp? |
| 20:04.00 | file | yes |
| 20:04.19 | kharwell | okay ya will have to track back more |
| 20:04.54 | file | PJSIP also exposes the first audio stream as sendrecv always for... reasons |
| 22:40.21 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-142-242.socal.res.rr.com) |
