| 00:02.12 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:801b:4c0b:2bb9:37d3:be92) |
| 00:02.13 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 00:08.57 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-giqxzkshzlfzhash) |
| 00:29.46 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:801b:f09a:4401:2d9f:c8f7) |
| 00:29.46 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:40.10 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 01:55.07 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 02:06.49 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 03:19.50 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 03:48.05 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:801b:3818:33fd:184c:68fc) |
| 03:48.05 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 03:51.27 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:801b:8d7b:a84:51fd:97b1) |
| 03:51.28 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 05:15.15 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:801b:e58d:eaa0:8c74:f922) |
| 05:15.15 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 05:25.52 | *** join/#asterisk-dev Demon_VoIP (~demon@eoks.ivanovo.ru) |
| 05:58.41 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:801b:b587:6959:4e7b:c5d2) |
| 05:58.42 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 06:55.53 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:37.07 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 07:51.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:55.19 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 08:16.01 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::10de) |
| 08:56.24 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 09:05.39 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 09:37.43 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:42.50 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 10:08.18 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 10:08.18 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:55.52 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 12:55.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 13:14.19 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-13.wall.uls.co.za) |
| 13:52.50 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:08.09 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-veoptmlcioumhovw) |
| 14:08.09 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:10.09 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-hxpdwvfbodoxigyt) |
| 14:10.09 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:17.13 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-phttlyynszskymwr) |
| 14:17.14 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:21.19 | tsearle | good afternoon |
| 14:21.48 | tsearle | was looking at https://wiki.asterisk.org/wiki/display/AST/Setting+up+PJSIP+Realtime |
| 14:22.06 | tsearle | I see there for sourcery.conf it puts identify= in a separate config section |
| 14:22.30 | tsearle | however the sample config file included with asterisk puts indentify= directly in the [res_pjsip] section |
| 14:23.39 | tsearle | should configs/samples/sorcery.conf.sample be updated to align with the wiki? |
| 14:29.21 | gtjoseph | looks |
| 14:33.19 | gtjoseph | tsearle: yeah, the wiki is correct. i'll update the sample. thanks for the catch. |
| 14:33.34 | tsearle | you're welcome |
| 14:35.21 | tsearle | btw, just a question ref sorcery, for realtime I only care about endpoint, aor, and identify, can I dropp auth, contact, and domain from the config in that case? |
| 14:36.35 | gtjoseph | absolutely |
| 14:37.21 | gtjoseph | they'll default to pjsip.conf if not specified (or astdb in contact's case) |
| 14:37.47 | tsearle | cool |
| 14:38.14 | gtjoseph | See this page for info on caching... https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching |
| 14:38.54 | gtjoseph | there's also another one for performance but i'm trying to find it :) |
| 14:39.55 | gtjoseph | https://wiki.asterisk.org/wiki/display/AST/Performance+Tuning |
| 14:43.55 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 14:49.04 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:49.04 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:02.09 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-alxmgtuwqujppomb) |
| 15:02.09 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:44.32 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-cqfstshuhpmsgzoi) |
| 15:44.32 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 17:06.02 | gtjoseph | new stream api: can a stream be part of more than 1 topology? |
| 17:06.09 | gtjoseph | file answered "no" |
| 17:06.20 | gtjoseph | is it worth then storing a pointer to the stream topology on the stream for easier retrieval? |
| 17:07.02 | file | I don't think you'd have a case where you would have a stream and not have either the topology it is from already, or easy access to the topology |
| 17:07.22 | gtjoseph | kk |
| 17:11.38 | gtjoseph | ast_stream_topology_copy has to be a deep clone then, correct? |
| 17:12.00 | file | yes |
| 17:12.24 | gtjoseph | mind if i change some function names? :) |
| 17:12.35 | file | provided they are logical, no |
| 17:47.59 | gtjoseph | @file: since streams aren't ao2_objects we could get into a situation where a stream has been added to a topology and subsequently freed without removing from the topology. |
| 17:48.39 | file | we can't enforce not doing that, but the documentation for topologies should make it clear that once a stream is in a topology you can't free it |
| 17:49.01 | gtjoseph | if we don't want to me them ao2_objects, we may have to store the topology on the stream so that when ast_stream_destroy is called we can check that it's not part of a topology |
| 17:49.29 | file | yeah, that's an option |
| 17:49.50 | gtjoseph | it jsut sounds like an oipportunity for segfaults |
| 17:59.15 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.222.253) |
| 18:01.45 | rmudgett | We don't miss an opportunity for that... :D |
| 18:50.17 | gtjoseph | @file: about ast_stream_topology_set, if the index provided is beyond the current last_index+1 what should the behavior be?\ |
| 18:51.23 | file | hum, I'd say it should match SDP behavior - that is, you can't have empty stream pointers |
| 18:51.56 | file | soooo, error with a message? |
| 18:52.27 | gtjoseph | or just append it silently |
| 18:52.51 | file | meh :P |
| 18:53.20 | gtjoseph | ok error but maybe a _append_stream api added. |
| 18:53.27 | gtjoseph | nevermind :) |
| 18:54.03 | file | yes, that would be fine |
| 18:54.55 | gtjoseph | so i'm thinking set MUST replace an existing entry (replace) and you use _add to append. |
| 18:55.35 | gtjoseph | no one's going to call get_count just sp they can call set with the last index. |
| 18:55.43 | gtjoseph | they' djust call append |
| 18:55.49 | gtjoseph | sorry..._qadd |
| 18:55.51 | gtjoseph | _add |
| 18:56.10 | gtjoseph | i'm going to rename a little :) |
| 18:56.34 | file | well |
| 18:56.36 | file | it depends |
| 18:56.41 | gtjoseph | ok? |
| 18:57.02 | file | if you received an SDP you'd potentially know the position of a stream, and that'd be reflected in a topology |
| 18:57.15 | file | so even on initial you could call set, and for subsequent ones |
| 18:57.18 | file | it dependssssss |
| 18:57.30 | gtjoseph | but there can't be gaps so... |
| 18:57.48 | file | like I said, it depends on the implementation |
| 18:57.59 | file | I think allowing set to replace (or add at the specific index) is fine |
| 18:58.02 | gtjoseph | ok |
| 18:58.28 | gtjoseph | but only add at specific index if it's the end of the vector |
| 18:58.43 | file | yes |
| 18:58.44 | gtjoseph | rather last_entry + 1 |
| 18:58.51 | gtjoseph | ok |
| 19:01.10 | gtjoseph | think maybe we should return the stream that WAS at the index instead of destroying it blindly? |
| 19:01.47 | file | no? |
| 19:02.08 | gtjoseph | ok. |
| 19:02.27 | gtjoseph | normally a replace function returns the previous value |
| 19:02.31 | gtjoseph | but that's fine |
| 19:02.42 | file | I think until this gets used by putnopvut in SDP land keeping it simple for now is the best choice of action, if the API feels wrong or isn't quite right when it's put into practice we can adjust |
| 19:02.51 | gtjoseph | sounds good |
| 19:06.52 | gtjoseph | for topology_make ... "The format capabilities reference is NOT stolen by this function" you mean that it IS bumped yes? |
| 19:07.39 | file | yes |
| 19:08.57 | gtjoseph | and you want it in format_cap "preference" order, yes? |
| 19:09.30 | file | I don't understand the question |
| 19:10.04 | gtjoseph | topology_make fills the topology vector from an ast_format_caps structure |
| 19:10.16 | file | oh, yes |
| 19:10.21 | gtjoseph | there are 2 vectors in format_caps |
| 19:10.40 | gtjoseph | so "yes" to preference? |
| 19:10.46 | file | yes |
| 19:18.45 | gtjoseph | "A helper function that given a set of formats creates a topology with the required streams to satisfy them" is a little ambiguous. A stream doesn't have "a" format, it has a format_caps structure which contains a list of formats. So "required streams" (plural) is a litle confusing. |
| 19:19.50 | file | a stream has a type |
| 19:19.54 | file | a media format has a type |
| 19:20.17 | gtjoseph | the input format caps divided up into streams by type? |
| 19:20.19 | file | yes |
| 19:20.42 | file | that's the streams required to 'carry' media given the formats present |
| 19:21.59 | gtjoseph | hmmm. ref counting ... |
| 19:22.17 | file | of? |
| 19:22.38 | gtjoseph | when you do ast_stream_set_formats, you bump the caps structure but not the formats |
| 19:22.45 | gtjoseph | are the formats not ao2? |
| 19:23.20 | file | the format cap holds a reference |
| 19:23.31 | gtjoseph | ok |
| 19:23.37 | file | it is perfectly safe to simply bump it up |
| 19:29.19 | gtjoseph | Can there actually be a format with type UNKNOWN? |
| 19:29.34 | file | no |
| 19:56.56 | gtjoseph | file: still around? What do you want the streams to be named? |
| 19:57.13 | file | for _make? |
| 19:57.16 | gtjoseph | yep |
| 19:57.23 | file | the name of the type? |
| 19:57.27 | file | seems sane |
| 19:57.53 | gtjoseph | works for me |
| 19:58.11 | file | I'm also partial to characters from Star Trek Voyager |
| 19:59.16 | gtjoseph | Ok, let's see... 7of9, Neelix, Kim, Paris, Janeway |
| 19:59.34 | gtjoseph | actually we only need 4 |
| 20:00.46 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d004d91e0060b5847b1.ipv6.abo.wanadoo.fr) |
| 20:07.45 | gtjoseph | @file: let's go back to bumping format caps. i don't think we need to since we're actually creating a new format_cap for each stream. |
| 20:07.59 | file | that's fine |
| 20:19.41 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-tzlcykodqryaybtm) |
| 20:19.41 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 20:53.33 | gtjoseph | @file: there's no setter for stream->num. On purpose? |
| 20:54.17 | file | yes, that's a value as part of being in a topology so I didn't think it should be publicly exposed and just be set by topology |
| 20:54.56 | gtjoseph | it has a getter though |
| 20:55.03 | file | yes |
| 20:55.08 | file | it is useful outside |
| 20:55.19 | file | but nothing outside should ever need to set it |
| 20:55.37 | gtjoseph | so topology add/set should set it? to what, just the vector index? |
| 20:55.44 | file | yup |
| 20:56.10 | gtjoseph | ok. the comment does say "unique to the channel it's on" |
| 20:57.16 | gtjoseph | there's also no definition for removing a stream from a topology |
| 20:59.22 | file | unique to the topology it is on |
| 20:59.36 | file | and you can change the state of a stream to removed |
| 20:59.51 | file | completely removing would require a completely new topology |
| 21:00.16 | gtjoseph | gotcha |
| 21:00.19 | file | and it would be up to the user of the API to do that, and change any state association they have internally as a result |
| 21:01.06 | file | I hate you Confluence so much |
| 21:01.34 | gtjoseph | i made a name change or 2 to the ast_stream part, added ast_stream_clone, and null pointer checking to the existing stuff. do you want that as an update to your initial review or as part of mine for topology? |
| 21:01.49 | file | I don't really care |
| 21:02.04 | gtjoseph | ok, i'm going to do it in mime |
| 21:02.08 | gtjoseph | mine |
| 21:03.54 | *** join/#asterisk-dev klow (~klow@66.114.139.162) |
| 21:06.45 | seanbright | happy friday you beautiful sons of bitches |
| 22:00.44 | seanbright | rmudgett: my understanding is that switching from an int to an enum would break abi |
| 22:02.11 | seanbright | well, _could_ break abi. apparently compilers are free to use smaller-than-int sized values for enums |
| 22:02.14 | seanbright | but i might be wrong |
| 22:08.57 | rmudgett | I wasn't saying to change the type of the parameter. Just to note that should pass the enum value. |
| 22:20.20 | seanbright | rmudgett: there is no enum |
| 22:20.42 | seanbright | at least not in 13 |
| 22:21.12 | rmudgett | The new enum described in the review comment: enum ast_pbx_outgoing_sync |
| 22:21.28 | seanbright | ok, so create the enum |
| 22:21.29 | rmudgett | It eliminates using defines. |
| 22:21.36 | seanbright | but leave the function arg as an int |
| 22:21.39 | seanbright | got it |
| 22:25.12 | seanbright | would it kill you if i flipped that comparison around? |
| 22:25.40 | seanbright | 0 < synchronous to synchronous > 0? |
| 22:32.11 | seanbright | meh... better just leave it |
| 22:44.17 | rmudgett | seanbright: Looked at it again. Minor nits. |
| 22:44.29 | rmudgett | Otherwise looks good. |
| 22:45.15 | seanbright | nits!? you have NITS? |
| 22:45.15 | seanbright | k |
| 22:46.18 | rmudgett | Might be better to describe the values for synchronous using the enum names. |
| 22:48.39 | seanbright | k |
| 22:48.50 | seanbright | there a way to monospace stuff in doxygen? |
| 22:49.03 | seanbright | like "blah blah `failed@context` etc etc?" |
| 22:52.07 | rmudgett | Don't know |
| 23:00.52 | seanbright | where is the doxygen site these days? doxygen.asterisk.org is old as dirt |
| 23:21.43 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 23:30.38 | rmudgett | file might know. I get live doxygen from my SlickEdit. |
| 23:34.02 | file | negative |
| 23:35.05 | file | I can offer a ferrero rocher if that helps though |
| 23:35.54 | rmudgett | file: Looks like the v13 branch version is permanently messed up because of the 13.12.2 change merge. |
| 23:36.36 | file | this sounds like something I'll care about Monday :P |
| 23:36.48 | rmudgett | git describe now finds that tag |
| 23:50.28 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-alxmgtuwqujppomb) |