| 00:28.39 | coreyfarrell | rmudgett: just noticed how pointless it was that I didn't use ao2_weakproxy_find to implement ast_sorcery_retrieve_by_module_name. |
| 00:52.21 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 01:37.59 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.172) |
| 01:38.33 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:f465:ad9b:6dc1:2c0a) |
| 01:38.33 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 02:48.49 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 03:08.24 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 03:43.42 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 05:07.25 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 05:09.47 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 06:38.52 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 06:50.21 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 06:50.46 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:44.36 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.166) |
| 08:14.10 | *** join/#asterisk-dev Bordr (~Bordr@c-24-9-55-138.hsd1.co.comcast.net) |
| 08:47.12 | *** join/#asterisk-dev Bordr_ (~Bordr@c-24-9-55-138.hsd1.co.comcast.net) |
| 09:05.02 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 10:31.31 | *** join/#asterisk-dev dustinm (~dustinm@68.ip-149-56-14.net) |
| 11:07.51 | *** join/#asterisk-dev darkunderlord (uid242683@gateway/web/irccloud.com/x-xipnyijevljbfikg) |
| 11:39.24 | *** join/#asterisk-dev tsearle (uid256864@gateway/web/irccloud.com/x-terdywfiawwdvysj) |
| 11:39.25 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 11:40.02 | tsearle | x-chat no longer available in ubuntu, trying out this irccloud |
| 11:41.49 | gtjoseph | how about hexchat? |
| 11:46.34 | tsearle | let me check that out |
| 11:50.03 | *** join/#asterisk-dev tsearle (~tsearle@2a02:2788:1004:636:69bc:eb5c:82d2:f282) |
| 11:50.03 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 11:50.34 | tsearle | better! thanks :-) |
| 11:52.45 | coreyfarrell | isn't hexchat just x-chat renamed? |
| 11:53.14 | tsearle | it looks more minimalistic than x-chat |
| 11:55.32 | seanbright | you ever get that feeling that ao2 has spun out of control? |
| 11:55.36 | seanbright | like whoa |
| 11:56.01 | gtjoseph | :) |
| 11:56.03 | coreyfarrell | I feel like that's directed at me! |
| 11:56.19 | seanbright | slightly |
| 11:56.23 | seanbright | indirectly |
| 11:56.23 | file | seanbright: yes. |
| 11:57.25 | gtjoseph | i keep thinking that we should look for an open-source alternative to ao2 but never get around to it |
| 11:58.43 | seanbright | well, i think we use it as a crutch sometimes. like 'it would be hard to define the lifetime of this thing, so let's just punt' |
| 11:59.15 | seanbright | not shitting on it, it obviously has value |
| 11:59.33 | coreyfarrell | seanbright: do you have something against the recent changes or are you talking generically? |
| 11:59.41 | seanbright | generically |
| 11:59.56 | seanbright | i don't really understand the weak proxy thing (and don't explain it - it's too early) |
| 12:00.05 | seanbright | so mostly i just ignore the ao2 related reviews |
| 12:00.44 | coreyfarrell | weak proxy is complicated. that's the "it's too early" explanation. |
| 12:01.11 | seanbright | yup |
| 12:01.41 | seanbright | i have nothing constructive to say on the matter, it all just seems complicated |
| 12:01.51 | seanbright | also: happy wednesday |
| 12:06.00 | seanbright | does c++ have any reference counting mechanism? (just curious) |
| 12:06.24 | coreyfarrell | I believe you can do it with class templates. |
| 12:06.51 | coreyfarrell | and assignment operators.. |
| 12:08.42 | coreyfarrell | but afaik nothing built-in if that's what you were asking. |
| 12:08.51 | seanbright | yeah, that is what i was asking |
| 12:13.18 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-ynvwebbwpziwkqoi) |
| 12:13.18 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:13.21 | coreyfarrell | automatic memory management is more of a C# thing. |
| 12:46.08 | seanbright | so the code generated by gperf (perfect hash generator) is GPLd, is that asterisk compatible? |
| 12:46.48 | gtjoseph | that was on my list to try. as i remember, it was. |
| 12:48.20 | seanbright | actually... |
| 12:48.32 | seanbright | "gperf is under GPL, but that does not cause the output produced by gperf to be under GPL. The reason is that the output contains only small pieces of text that come directly from gperf's source code â only about 7 lines long, too small for being significant â, and therefore the output is not a âwork based on gperfâ (in the sense of the GPL version 3)." |
| 12:48.42 | seanbright | so that is fantastic |
| 12:50.03 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 12:50.03 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 12:59.53 | coreyfarrell | gcc has similar exception for libgcc and libstdc++ |
| 13:21.59 | *** join/#asterisk-dev jkroon (~jkroon@vc-nat-gp-n-41-13-84-128.umts.vodacom.co.za) |
| 13:31.55 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-pwvtrriiuevdwers) |
| 13:31.55 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:55.38 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:55.39 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:12.10 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:12.10 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:14.55 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 14:26.53 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:26.53 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:29.00 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ixaretvexmdyhczx) |
| 14:29.00 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:48.14 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-rxiilzdkbzfueefz) |
| 14:48.14 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:51.02 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 14:51.10 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 14:52.04 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:52.04 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:54.31 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 14:59.28 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 15:04.41 | *** join/#asterisk-dev joshelson (~joshelson@208.186.235.212) |
| 15:11.16 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-xhfigybtjdftdeqx) |
| 15:19.09 | JunK-Y | question: in chan_sip.c (i know seanbright will not like me!), it seems the only way to change the RTP SSRC is by queueing AST_CONTROL_SRCCHANGE, right? |
| 15:21.19 | JunK-Y | cause a peer is sending INVITE with offer 0 9, i'm sending response with 9 0 and sending g722 which seems to be ignored by that peer. Manufacturer says I need to change the SSRC when changing the payload. Not too sure where changing that without breaking the planet |
| 15:26.10 | seanbright | wonders why his name is now synonymous with chan_sip |
| 15:26.22 | seanbright | (i don't know the answer to your question) |
| 15:27.05 | cresl1n | seanbright in sanskrit means "chan_sip god" |
| 15:27.19 | rmudgett | wonders if seanbright is now taking all the blame for chan_sip |
| 15:28.49 | rmudgett | JunK-Y: The SSRC does not need to change when changing the payload types. |
| 15:29.18 | jameswf | +1 for making @seanbright the chan_sip slave. You must resolve all outstanding issues by Friday 9am |
| 15:29.48 | JunK-Y | where do we decide if we're going into `RTP P2P` or non-P2P in the code? can't find any info from https://wiki.asterisk.org/wiki/display/AST/Bridges (probably the wrong place!) |
| 15:29.49 | jameswf | no one apposed, motion carries |
| 15:31.14 | JunK-Y | rmudgett: This is what RFC 3550 is saying, but RFC 7160 proposed to change it when the clock rate is changing. |
| 15:33.28 | *** join/#asterisk-dev dtascom (~dtascom@static-47-180-162-26.lsan.ca.frontiernet.net) |
| 15:34.00 | rmudgett | I don't think there has been any attempt to implement the changes for that RFC yet. |
| 15:36.16 | JunK-Y | rmudgett: my goal is simply to change the SSRC when the payload type is changing and see if it's working for that device. |
| 15:37.21 | rmudgett | Then simply queueing an AST_CONTROL_SRCCHANGE will do that. |
| 15:41.18 | JunK-Y | right now, the only place queuing that frame is when receiving the ACK. where the payload type change occurs exactly? |
| 15:46.56 | rmudgett | When SIP SDP signaling to change RTP and when those RTP changes happen are loosely coupled. There can be a delay between when SIP SDP signaling changes the setup and the RTP stream arrives affecting the change. |
| 15:48.55 | JunK-Y | i mean without any SDP change. simply a payload type change (only the RTP changes from 0 to 9). |
| 15:59.24 | rmudgett | You should look in res_rtp_asterisk.c:ast_rtp_read() |
| 16:01.25 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 16:01.27 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-wzksizwcugjihbdy) |
| 16:01.27 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 16:10.21 | JunK-Y | i'll re-dig into that function. thanks rmudgett |
| 16:11.47 | JunK-Y | also, dumb question, why an audiohook force the transcoding? for example, I called VOLUME() and now the payload sent to the problematic device is 0 and not 9 anymore. |
| 16:13.13 | file | audiohook has to transcode in order to perform actions on the underlying media |
| 16:28.22 | coreyfarrell | how can I look at the bug tracker that came before JIRA? I want to see the bug associated with: enhance SIP_PEER function to return additional items (bug #4816) |
| 16:30.01 | file | it doesn't exist anymore, but if you put that into JIRA It should go to the right thing - as they were all imported |
| 16:30.19 | file | maybe |
| 16:30.20 | file | there's a way |
| 16:30.47 | file | got it |
| 16:30.49 | coreyfarrell | oh yes that worked, the URL without the ASTERISK- redirected to the correct url |
| 16:30.56 | file | "Mantis ID" = 4816 |
| 16:31.00 | file | yeah |
| 16:31.22 | file | you're in the wild west though so expect content to be... |
| 16:31.33 | file | not that useful at times |
| 16:32.18 | coreyfarrell | doesn't matter, I'm just closing an old bug that was complaining about a behavior change between 1.6 and 1.8. |
| 17:03.00 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 17:03.01 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 17:22.30 | coreyfarrell | am I correct to assume that SIP over TCP and TLS are stable/first class transports in chan_pjsip? |
| 17:28.11 | file | yes |
| 17:38.23 | seanbright | let's pretend my dtls ephemeral patch didn't exist for a second |
| 17:38.43 | seanbright | if we were discussing how to configure it, what are some good ideas you guys could come up with? |
| 17:42.31 | file | this is a trap |
| 17:43.17 | seanbright | it's not |
| 17:43.23 | seanbright | i don't like the way it is configured |
| 17:43.29 | seanbright | i don't like gtjoseph's suggestion |
| 17:43.43 | seanbright | i'm looking for a "clean room" approach |
| 17:43.58 | file | personally speaking - a new option to turn it on, and in the case of the webrtc option it automatically get set on (I lean on the side of I don't think an explicit certificate really needs to be provided and everyone did it because that's the only way we had) |
| 17:45.03 | file | but, that's just me |
| 17:45.16 | seanbright | so something like "dtls_ephemeral = yes" |
| 17:45.28 | gtjoseph | what didn't you like about my approach? |
| 17:45.30 | file | yes |
| 17:45.39 | seanbright | gtjoseph: the fallback stuff |
| 17:45.45 | seanbright | it's not "your" approach that i don't like |
| 17:45.54 | seanbright | i just don't like how it is configured right now in the patch |
| 17:46.19 | seanbright | file: so if someone does "dtls_ephemeral = yes" and "dtls_cert_file = something.pem" what should the behavior be? |
| 17:46.35 | gtjoseph | gotcha. the simple parameter you just listed is ok |
| 17:46.42 | file | that's an invalid configuration in my book, so it should fail with an error |
| 17:47.09 | gtjoseph | I would have said explicit file overrides ephemeral |
| 17:47.52 | gtjoseph | but am ok with fail |
| 17:47.52 | seanbright | but then you would have to document that |
| 17:47.56 | seanbright | fail fast is easier and less error prone |
| 17:48.05 | seanbright | ok, that is the approach i will take |
| 17:48.13 | seanbright | in terms of 13 & 14 - cherry pick? |
| 17:48.25 | gtjoseph | sure |
| 17:48.31 | seanbright | okie |
| 17:48.39 | file | test coverage would be nice, and shouldn't be that bad |
| 17:48.41 | seanbright | i hate cherry picking backwards |
| 17:48.44 | seanbright | but i will do it |
| 17:48.48 | seanbright | test coverage!? |
| 17:48.50 | file | just need to see if there's a fingerprint |
| 17:48.51 | seanbright | UHHHHGG |
| 17:48.52 | kharwell | does the option need to be in the channel driver configs? Or would it be silly to put someplace like rtp.conf? |
| 17:49.07 | file | kharwell: DTLS stuff is always configured in the channel driver |
| 17:49.37 | seanbright | we're all ok with "dtls_ephemeral?" |
| 17:49.41 | seanbright | think users will be? |
| 17:49.54 | seanbright | dtls_auto_generate_cert? |
| 17:50.08 | seanbright | dtls_i_like_big_bugs_and_i_cannot_lie |
| 17:50.10 | file | auto_generate_cert is more descriptive, probably better |
| 17:50.15 | gtjoseph | yep |
| 17:50.20 | seanbright | roger that |
| 17:50.30 | gtjoseph | maybe auto generate server cert |
| 17:50.30 | file | likes the word ephemeral as a word regardless |
| 17:50.38 | seanbright | i agree |
| 17:50.45 | seanbright | i like saying it more than typing it though |
| 17:50.54 | seanbright | another new fav: orthagonal |
| 17:51.59 | file | ooh |
| 18:01.43 | seanbright | default? |
| 18:05.00 | kharwell | I'd say default it in master. If you have it the file override instead of an error though then things would just work and it shouldn't break people's systems now or when they upgrade |
| 18:15.46 | gtjoseph | yeah it can't default to on because if you specify a file it'll error unless you explicitly set it to off. |
| 18:34.07 | rmudgett | file: No 14 version for https://gerrit.asterisk.org/#/c/6669/ |
| 18:34.11 | rmudgett | ?? |
| 18:34.54 | seanbright | it was an oversight |
| 18:35.03 | seanbright | OR |
| 18:35.07 | seanbright | we don't support 14 anymore |
| 18:35.11 | seanbright | OR |
| 18:35.15 | seanbright | i'll shut up and mind my own business |
| 18:42.56 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0084aca5aadf0fb469.ipv6.abo.wanadoo.fr) |
| 18:44.11 | file | rmudgett: I could... but I wanted to draw a line :P |
| 18:44.36 | file | cause we can't keep adding stuff to 14 if we're trying to do a final release :P |
| 19:04.07 | *** join/#asterisk-dev joshelson (~joshelson@204.237.221.84) |
| 19:12.10 | seanbright | my voice is much deeper on video |
| 19:14.38 | file | hrms |
| 19:14.44 | file | you mean on the audio stream of a video |
| 19:29.32 | seanbright | that is correct |
| 19:32.00 | file | #pedantic |
| 19:41.57 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 19:43.17 | *** join/#asterisk-dev joshelson (~joshelson@206.205.80.228) |
| 20:03.09 | seanbright | leifmadsen: please draw asterisk's architecture in detail |
| 20:03.24 | leifmadsen | seanbright: calls --> asterisk --> calls |
| 20:03.34 | seanbright | ding ding ding |
| 20:03.38 | leifmadsen | calls --> asterisk(chan_sip) --> ? |
| 20:03.43 | leifmadsen | ducks |
| 20:03.55 | seanbright | i only use chan_console |
| 20:03.59 | leifmadsen | you're doing it right |
| 20:04.09 | leifmadsen | protocols just make it more complicated than it needs to be |
| 20:04.14 | seanbright | so true |
| 20:04.57 | file | is there an RFC for this lack of protocol? |
| 20:05.10 | leifmadsen | RFCs are too complicated |
| 20:05.22 | leifmadsen | contains too many implementation details |
| 20:05.36 | file | oic |
| 20:22.21 | cresl1n | chan_blockdiagram |
| 20:36.12 | seanbright | file: better? https://gerrit.asterisk.org/#/c/6671/2/res/res_pjsip.c |
| 20:36.38 | file | seemingly! |
| 20:36.49 | seanbright | huzzah |
| 20:49.36 | seanbright | this ipv6 dundi patch is getting a ton of traction |
| 20:49.45 | seanbright | i like it when things are lobbed over the fence |
| 20:50.02 | file | yeah, we need to do clean up on the older stuff |
| 21:06.38 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 21:06.38 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:11.17 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:991c:9c02:8d5e:92a9) |
| 22:11.17 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:20.03 | rmudgett | When https://gerrit.asterisk.org/#/c/6750/ and other branch versions get merged, I will be able to push up my CDR performance patch series. 6 patches for 4 branches :) |
| 22:43.43 | *** join/#asterisk-dev joshelson (~joshelson@64.55.128.243) |
| 23:06.14 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 23:09.56 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-ixaretvexmdyhczx) |