| 00:12.11 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 01:26.49 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 02:33.32 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 02:33.32 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 02:49.16 | *** join/#asterisk-dev philippel_ (uid10480@gateway/web/irccloud.com/x-jxxvtzkugmrjqzgo) |
| 02:52.13 | *** join/#asterisk-dev X-Rob_ (sid14615@gateway/web/irccloud.com/x-firpycyqidmrakfm) |
| 03:04.00 | *** join/#asterisk-dev GameGamer43 (sid5533@gateway/web/irccloud.com/x-vsouuvorwlvemeke) |
| 03:21.32 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 03:22.46 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c00::f03c:91ff:fe6e:6894) |
| 04:54.33 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 05:46.12 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 05:59.59 | *** join/#asterisk-dev ayrjola (~ayrjola@80.248.109.102) |
| 06:15.22 | KristianMedK | k |
| 06:25.50 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 06:35.53 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:a5ca:1bf2:bf22:eef7) |
| 07:07.03 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:07.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:07.16 | oej | Morning folks |
| 08:45.27 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:45.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:53.59 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:04.06 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 12:19.28 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-3-44.dhcp.nwtn.ct.charter.com) |
| 12:23.50 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:31.53 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:31.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:32.01 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-ubudopklklwkcrmz) |
| 13:51.22 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:51.22 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:59.32 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-oodmockqmbfpxgpa) |
| 13:59.32 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:01.21 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-nlnvrwtgrkoupran) |
| 14:01.21 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:06.31 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:07.43 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-hxtpmxrwhrlpyrgq) |
| 14:13.41 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-kdrhrgdrvwnphzfg) |
| 14:14.28 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-dzgweavdlcwhcjlp) |
| 14:16.08 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-mrnziuyptsfohdmq) |
| 14:31.20 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:40.21 | newtonr | oej, ping on ASTERISK-24251 |
| 14:48.12 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-qaunyrvczjscivoq) |
| 14:48.55 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-vqmpvihmygjjryfe) |
| 14:49.28 | oej | Pong newtonr |
| 14:49.34 | oej | What's upp? |
| 14:49.36 | oej | up? |
| 14:50.44 | newtonr | oej, howdy! that issue needs your patch |
| 14:51.09 | oej | The patch that mjordan removed? I blame file. |
| 14:51.37 | newtonr | yeah we can't do inline patches :D |
| 14:51.42 | newtonr | file, all your fault! |
| 14:51.48 | file | factual |
| 14:52.20 | mjordan | felt bad about that |
| 14:59.58 | oej | ha ha. I will remember this and use it for a very long time... |
| 15:00.15 | oej | Now If I was a bug marshal I would have slapped myself harder for that inline patch... |
| 15:00.20 | oej | ;-) |
| 15:00.45 | oej | Gotta rush. Thanks for the reminder Newtonr. I'll take the action point, as long as file takes the blame and everyone is happy. |
| 15:04.10 | *** part/#asterisk-dev datachomper (~russ@nat/digium/x-lxuvmawdcquxffts) |
| 15:04.24 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-ufpasjccdkmgoxis) |
| 15:05.20 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:05.20 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:20.37 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-ywscmivkwydcwgzt) |
| 15:32.46 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 15:40.08 | newtonr | oej, thanks! :) |
| 16:07.01 | gtjoseph | Can someone give a quick review to https://reviewboard.asterisk.org/r/4078/ ? It fixes a SEGV in the unit tests. |
| 16:14.34 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:37.08 | bklang | mjordan: (pinging you because you're the last to modify it): If I have corrections for a Wiki page, how do I go about submitting them? Page in question: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Standard+Channel+Variables |
| 16:39.50 | mjordan | just a comment on the appropriate wiki page is cool. The comments accept formatting changes as well, so you can style them up in there if you'd like (raw text is cool too however). If you have a chunk of changes you'd like to make, that rnewton or someone can hook you up with edit access |
| 16:40.58 | bklang | ok, I'll comment for now, though I think there may be several other changes eventually. For example ${CHANNEL} isn't really well explained, but I'd need to do some research on what was in 1.8 vs. 11 before making changes |
| 16:48.41 | bklang | hm, the example in configs/extensions.conf.sample is also wrong. I guess I need to file an issue on that? |
| 16:52.48 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 16:52.48 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:17.16 | mjordan | bklang: yeah, that one - since it's in source - needs an issue |
| 17:17.20 | mjordan | which I see you made :-) |
| 17:21.48 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 18:08.12 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-yaedjlknudgvrrse) |
| 19:12.30 | mjordan | YAY! Tests finally posted. |
| 19:12.52 | mjordan | I look forward to no one looking at that review :-P |
| 19:14.28 | pabelanger | ARI question: How tricky would implementing the Transfer() command be? |
| 19:14.41 | mjordan | depends on what you mean by "Transfer" |
| 19:14.51 | mjordan | you want to initiate a channel driver level transfer? |
| 19:14.58 | pabelanger | Request the remote caller be transferred to a given extension |
| 19:15.13 | pabelanger | for SIP |
| 19:15.15 | mjordan | by extension, do you mean dialplan? |
| 19:15.21 | mjordan | or do you mean to an arbitrary SIP URI? |
| 19:15.26 | pabelanger | ya, SIP URL |
| 19:15.30 | pabelanger | URI* |
| 19:15.41 | pabelanger | for the purpose of discussion |
| 19:15.58 | mjordan | not super-duper hard, since it just defers it to the channel driver. |
| 19:16.18 | mjordan | In some ways, however, it's kind of an ugly concept. Or at least an ugly name. |
| 19:16.44 | mjordan | pabelanger: are you looking to use it for load balancing? |
| 19:16.57 | pabelanger | mjordan, somewhat |
| 19:17.06 | pabelanger | for now, I am using the Transfer() app |
| 19:17.09 | pabelanger | and /continue |
| 19:17.13 | mjordan | yup yup |
| 19:17.18 | pabelanger | but wanted to see how to do it all in ARI |
| 19:17.37 | mjordan | pabelanger: if you look at app_transfer, it's pretty small. Generally, you just check to see if the channel driver supports the transfer virtual method, then invoke it |
| 19:17.41 | mjordan | you would do something similar in ARI. |
| 19:17.47 | pabelanger | and since /continue does not work with labels, my dialplans are super crazy / ugly |
| 19:17.58 | pabelanger | okay, that is what I suspect |
| 19:18.07 | pabelanger | so, something like a /transfer method would be exposed in ari |
| 19:18.28 | mjordan | pabelanger: https://wiki.asterisk.org/wiki/display/AST/Create+a+new+resource+with+ARI |
| 19:18.47 | mjordan | you wouldn't need a whole new resource mind you |
| 19:18.47 | pabelanger | Maybe I'll hack on it at astricon next week |
| 19:18.50 | pabelanger | right |
| 19:18.56 | mjordan | but what you could do is add a new operation to /channels |
| 19:18.59 | mjordan | run 'make ari-stubs' |
| 19:19.02 | mjordan | find your handy dandy callback |
| 19:19.15 | mjordan | get the channel |
| 19:19.16 | mjordan | and then call the ->transfer virtual method appropriately |
| 19:19.38 | mjordan | but yeah, we can talk about it more at AstriCon |
| 19:20.04 | pabelanger | Okay, so on the right path. Just to make sure it is named properly to keep everybody happy |
| 19:20.39 | mjordan | right right. One thing to throw in the back of your head: transfer doesn't really feel like a transfer, so much as a "this is not the thing you were looking for" |
| 19:20.54 | mjordan | rather, redirect/forward. It's a bit of an ugly hack that it is also sometimes a transfer |
| 19:20.59 | mjordan | depending on when it is called |
| 19:21.09 | mjordan | I think we'd probably not want the API to behave in the same fashion |
| 19:21.24 | pabelanger | redirect is fine |
| 19:21.41 | mjordan | which means, then - should /continue simply accept a 'remote destination'? |
| 19:21.44 | pabelanger | but I get what you are saying |
| 19:21.46 | mjordan | something to mull over |
| 19:21.49 | file | redirect is a little muddied as well... since it can mean dialplan |
| 19:21.54 | file | mjordan, yeah |
| 19:21.55 | mjordan | NAMING IS HARD |
| 19:22.11 | leifmadsen | names! |
| 19:22.46 | file | renames leifmadsen to duck |
| 19:23.48 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:23.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:28.20 | leifmadsen | [11:23] .:leifmadsen:. I like ducks |
| 19:38.37 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:b84e:b3f:b822:f842) |
| 19:55.37 | opticron | if anyone wants to take a look at PJSIP module loading stuff: https://reviewboard.asterisk.org/r/4062/ |
| 19:56.52 | mjordan | opticron: it just makes me sad |
| 20:04.57 | opticron | for want of a real module loader? |
| 20:15.23 | Corydon76 | What, no load priorities? |
| 20:15.34 | Qwell | or nonoptreq? |
| 20:15.57 | Qwell | Corydon76: loadpri only works if the module is actually supposed to load |
| 20:16.11 | Corydon76 | Ah, yes, the Red Hat hack for shipping a broken compiler |
| 20:18.05 | Corydon76 | Qwell: only if the module doesn't request for its own dependencies to be loaded upon load |
| 20:19.50 | leifmadsen | Trappy McTrapperton, Esq |
| 20:21.34 | Corydon76 | I guess that was a branch that never made it in |
| 20:21.59 | Qwell | res_stasis_* uses nonoptreq to pretty good effect |
| 20:22.36 | Corydon76 | Ah, that was it |
| 20:23.16 | Corydon76 | Non-optional requirements |
| 20:23.35 | Qwell | Corydon76: You're right though that it was added for RH b0rkedness. |
| 20:23.41 | Qwell | optional API stuff |
| 20:24.13 | Corydon76 | Elegant solution. I wish we could have saved it. |
| 20:25.16 | Qwell | oh, that got removed in 12. wtf. |
| 20:26.20 | Corydon76 | In favor of automatic stubs |
| 20:27.31 | Corydon76 | To be fair, the auto-stub code is far nicer than the stub code that preceded the optional api stuff |
| 20:28.14 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 20:50.31 | opticron | in pjsip land, it's not safe to assume that only one dialog is using a given connection-oriented transport, is it? |
| 20:53.16 | putnopvut | opticron: I'm not 100% sure if PJSIP re-uses connections for different dialogs with the same destination or not. |
| 20:53.26 | putnopvut | I would not assume that it doesn't, though, if that makes sense. |
| 20:59.34 | jameswf | Im guessing SWP is internal... |
| 21:01.02 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-255-171-52.mci.googlefiber.net) |
| 21:03.09 | opticron | putnopvut, that's the answer I was hoping for, because it makes implementation of what I'm working on quite a bit simpler for data lifetime issues |
| 21:05.41 | mjordan | hm. Apparently swagger doesn't believe in semantic versioning, as the change from 1.1 to 1.2 is _very_ breaking |
| 21:06.49 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:10.16 | gtjoseph | wow, the bamboo UI is so slow chrome is killing it. |
| 21:15.02 | file | opticron, multiple dialogs may go over the same transport |
| 21:49.01 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:20.19 | newtonr | jameswf, I don't know if anyone responded to you. SWP issue are internal issues used by Digium for workflow tracking. They can be safely ignored. |
| 22:23.21 | jameswf | newtonr: there were some pjsip tickets marked as duplicates of then had a SWP id |
| 22:24.15 | newtonr | Yeah, many issues will have an SWP clone in our internal queue. |
| 22:39.31 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 22:48.18 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-oodmockqmbfpxgpa) |
| 23:22.42 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-hxtpmxrwhrlpyrgq) |