| 02:27.00 | *** join/#asterisk-dev _Vile (~vile@freeswitch/developer/vile) |
| 04:41.56 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 04:41.56 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:18.10 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.34) |
| 07:21.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 07:22.07 | *** join/#asterisk-dev _Vile (~vile@freeswitch/developer/vile) |
| 07:25.26 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 07:44.02 | *** join/#asterisk-dev perseiver (~gopalanay@122.160.98.244) |
| 07:44.33 | perseiver | Is it possible to connect Asterisk with MEDIA streaming Server? Any luck |
| 08:30.00 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.56) |
| 11:16.17 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 12:35.09 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 14:00.33 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:00.33 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:38.57 | pchero_work | Hi, I would like to check the this issue, but it says "Something wrong". https://issues.asterisk.org/jira/browse/ASTERISK-25698?jql=text%20~%20%22No%20joint%20capabilities%20for%20%27audio%27%20media%22 |
| 14:39.03 | pchero_work | Can anyone see this ticket? |
| 14:42.35 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-exyeopbymctuzxcv) |
| 14:42.35 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:57.58 | seanbright | jira seems angry at the moment |
| 14:58.35 | seanbright | or maybe just with that particular ticket |
| 15:02.11 | seanbright | pchero_work: i moved the output to an attachment and it seems faster now |
| 15:02.23 | seanbright | not sure if that was what was causing the problem or not |
| 15:02.27 | seanbright | but it seems better |
| 15:05.09 | pchero_work | seanbright: Ah, I can see it now. Thank you. :) |
| 15:10.34 | file | that's generally the problem - large comments make it sad |
| 15:30.15 | *** join/#asterisk-dev wakko (~wakko@252.100.15.51.rev.tty.ninja) |
| 15:44.08 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-oviqojibczjbalok) |
| 15:44.08 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:57.51 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-wbkjopjvegsnpjjx) |
| 15:57.51 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:07.34 | *** join/#asterisk-dev Deeewayne (~dwayne@2605:a601:a2a0:73f:89b0:669b:cccb:b0be) |
| 16:07.34 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:59.26 | wakko | are _all_ AMI events supposed to travel on stasis, or are they only the result of messages ? i wrote a module, but i can only get VarSet from ast_manager_get_topic(). It looks like there is a ast_manager_get_generic_type() used by manager.c:ast_manager_publish_event() that is almost never called |
| 17:01.47 | wakko | i.e looking at AMI's Newchannel event, it's produced from a channel snapshot change message, and directly thrown as a ast_manager_event_blob without passing thru stasis |
| 17:04.55 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 17:04.55 | *** topic/#asterisk-dev is 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 |
| 17:06.21 | file | generally messages are created, one way or another, as a result of a message on stasis |
| 17:06.43 | wakko | hum... i think stasis_cache_update_type should implement .to_ami |
| 17:06.53 | file | it can't |
| 17:07.05 | wakko | why ? |
| 17:07.12 | file | the message type is the result of a snapshot being updated, and that action can result in more than 1 AMI message |
| 17:07.25 | wakko | right |
| 17:07.27 | file | it also depends on the previous message |
| 17:07.39 | file | to_ami is for converting a given message into 1 AMI message |
| 17:07.49 | wakko | i see |
| 17:07.52 | file | the to_ami API isn't really designed for this case |
| 17:08.28 | file | which is why it is implemented the way it is |
| 17:08.38 | file | (the cache update) |
| 17:08.50 | wakko | why does it depends on the previous message ? aren't old_snapshot and new_snapshot enough to produce AMI messages ? |
| 17:09.07 | file | old_snapshot is from the previous message, comparing them both is enough |
| 17:09.32 | file | stasis_cache_update_type is also used for different messages, so you can't put a to_ami on it |
| 17:09.33 | wakko | so the "real" probleme is that to_ami cannot produce more than one message |
| 17:09.57 | file | you'd have to define another interface to allow such a thing to happen in combination with it |
| 17:10.05 | wakko | got it |
| 17:10.45 | wakko | so the only way to gather AMI events from inside asterisk is by placing a custom_hook ? |
| 17:11.42 | file | yes |
| 17:34.44 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 17:34.44 | *** topic/#asterisk-dev is 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 |