| 00:01.21 | pabelanger | patch up: https://reviewboard.asterisk.org/r/2906/ |
| 00:01.40 | dwayne | when using SIP TLS / SRTP with Asterisk 1.8, shouldn't the SDP m= line use SRTP instead of RTP ? |
| 00:02.14 | dwayne | oops, sorry wrong channel ... I'll ask in #asterisk |
| 00:15.51 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 00:30.45 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 00:35.47 | pabelanger | what is the different between /channels/id/hold and /channels/id/moh |
| 00:35.55 | pabelanger | it looks like they are basically the same thing |
| 00:42.56 | *** join/#asterisk-dev suneye (~atcmmi@116.7.103.132) |
| 01:07.30 | pabelanger | I'm not seeing any events when I toggle mute / unmute or hold / unhold |
| 01:07.38 | pabelanger | anybody know why? |
| 01:09.24 | *** join/#asterisk-dev bkruse (~Adium@24.42.229.8) |
| 01:09.38 | *** part/#asterisk-dev bkruse (~Adium@24.42.229.8) |
| 01:16.28 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 01:56.07 | *** join/#asterisk-dev suneye (~atcmmi@119.139.62.205) |
| 02:09.26 | opticron | dwayne, it'll specify RTP/SAVP instead of RTP/AVP |
| 02:10.15 | dwayne | opticron, thanks for clarifying. |
| 02:17.00 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:17.33 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:41.42 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 04:18.08 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 05:18.38 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:19.12 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:32.00 | *** join/#asterisk-dev otherwiseguy (otherwiseg@nat/redhat/x-hsflmdloulmpjxhg) |
| 07:17.57 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-cofwolusbsponmeb) |
| 07:19.44 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 07:33.03 | *** join/#asterisk-dev danjenkins (~danjenkin@80.1.94.250) |
| 07:49.28 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:a1d9:f794:9cb9:6b7d) |
| 08:20.18 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 09:20.53 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 09:22.10 | *** join/#asterisk-dev suneye (~atcmmi@119.139.62.205) |
| 09:39.27 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 09:39.28 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 10:18.28 | *** join/#asterisk-dev danjenkins (~danjenkin@80.1.94.250) |
| 10:21.27 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 10:42.44 | *** join/#asterisk-dev barbosa2 (~juliano.b@177-069-248-123.static.ctbctelecom.com.br) |
| 11:02.33 | *** join/#asterisk-dev otherwiseguy (otherwiseg@nat/redhat/x-vwzgoisukdndoecm) |
| 11:04.16 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:04.16 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:08.42 | *** join/#asterisk-dev kesselklopfer79 (~kesselklo@astaro.starface.de) |
| 11:11.52 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:11.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:21.58 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 11:28.08 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 11:35.10 | *** join/#asterisk-dev oron (~oron_lapt@local.xorcom.com) |
| 11:48.54 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 11:50.53 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 11:50.53 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:18.54 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 12:19.26 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:22.29 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:22.52 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:28.22 | *** join/#asterisk-dev oron (~oron_lapt@local.xorcom.com) |
| 12:35.36 | *** join/#asterisk-dev zigg (~matt@unaffiliated/zigg) |
| 12:38.41 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:45.16 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:46.24 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:46.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:52.55 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-gqdnwqovkvtmgqxi) |
| 12:52.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:53.38 | file | hi mjordan! |
| 12:58.30 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:58.31 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:01.43 | mjordan | file: hi! |
| 13:01.48 | mjordan | file: and now off to work I go |
| 13:01.53 | file | RUN! |
| 13:02.01 | mjordan | staggers |
| 13:02.07 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-gqdnwqovkvtmgqxi) |
| 13:07.05 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:07.05 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:11.12 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 13:11.12 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 13:20.10 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-gynqdalzvnrzrsdh) |
| 13:20.51 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:20.51 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:37.25 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:37.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:44.43 | *** part/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:03.20 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-vgyoldyuyzspalft) |
| 14:09.41 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:09.41 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:12.53 | putnopvut | I face a dilemma. In chan_sip, if we receive a 200 OK for an initial INVITE that contains no usable streams, we need to send an ACK, followed immediately by a BYE. What should the hangupcause be in such a case? Should it be AST_CAUSE_NORMAL_CLEARING since the call was answered and then hung up? Or should it be something like AST_CAUSE_BEARERCAPABILITY_NOTAVAIL since the far end had no compatible codecs? |
| 14:13.55 | leifmadsen | I like the latter I think? |
| 14:14.15 | leifmadsen | my gut tells me the latter |
| 14:14.24 | leifmadsen | seems more fruitful in terms of information about what actually happened |
| 14:15.24 | putnopvut | That's how I was leaning as well. |
| 14:15.38 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:15.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:16.16 | wdoekes | +1 |
| 14:16.22 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-rfgcdyrtgzznegqj) |
| 14:16.22 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:19.36 | wdoekes | so, I have a problem: my queue thinks that my uncached realtime SIP members are offline, because their state is UNAVAILABLE. I changed that to UNKNOWN when p->is_realtime, but now the device cache caches IN_USE, but not UNKNOWN |
| 14:20.30 | leifmadsen | wdoekes: we ran into a similar problem... you can somewhat "fix it" by doing a 'sip show peer <foo> load' |
| 14:20.54 | leifmadsen | we have some logic that does some loading via AMI for queues and peers in the queue |
| 14:21.11 | leifmadsen | I think we also created a patch that does something like what you're doing |
| 14:21.13 | leifmadsen | let me look |
| 14:21.35 | Juggie | you did. |
| 14:21.39 | Juggie | didn't you write it? :) |
| 14:22.12 | leifmadsen | Juggie: nope, and as I suspected it wasn't for queue |
| 14:22.14 | leifmadsen | it was for meetme |
| 14:22.18 | Juggie | ah. |
| 14:22.20 | Juggie | right |
| 14:22.27 | leifmadsen | wrong again Juggie! |
| 14:22.28 | wdoekes | the sip show peer load doesn't re-enable it for me.. probably because my peers are uncached |
| 14:22.29 | leifmadsen | turn down the suck |
| 14:22.29 | Juggie | i coudn't really remember.... |
| 14:22.36 | Juggie | but i knew it was a similar issue. |
| 14:22.59 | leifmadsen | wdoekes: ah, so we're a bit different in that we're using cached peers |
| 14:23.11 | leifmadsen | and I think they need to be cached for queue stuff to work correctly, as you're finding out |
| 14:23.16 | leifmadsen | for device state, etc |
| 14:24.03 | wdoekes | I'm not sure about the *needs* yet, but this is trickier to fix than I initially thought |
| 14:24.12 | Marquis42 | Yup, although in the past I've used Custom device states instead of using SIP peers. But you need to have a way of setting those somehow based on actual availability of the peers. |
| 14:25.14 | wdoekes | I could disable the device state cache.. or allow UNKNOWN to overwrite the IN_USE.. or create a new state |
| 14:30.44 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-69-214.user.veloxzone.com.br) |
| 14:43.27 | pabelanger | So |
| 14:43.43 | pabelanger | I believe I need a new subversion cert, who can help me out? |
| 14:46.24 | file | That mjordan dude can. |
| 14:46.29 | mjordan | ducks and runs |
| 14:46.31 | Qwell | Yours doesn't expire for quite some time, IIRC. |
| 14:47.21 | file | Qwell, but what if you don't RC? |
| 14:48.04 | pabelanger | well, I'll need to be abandoned I guess. Can't seem to locate the key any more |
| 14:48.16 | putnopvut | Did you check under the welcome mat? |
| 14:48.29 | Qwell | file: first time for everything |
| 14:48.39 | mjordan | pabelanger: I can re-issue it to you. Shoot me an e-mail so I know where to send it |
| 14:48.47 | pabelanger | no, I did check my USB private keys dongle |
| 14:50.15 | file | revokes ALL THE CERTS |
| 14:55.14 | leedm777 | pabelanger: did you figure out the deal with the two dials? One is for dialing a channel and putting it into a Stasis app. The other is a convenience for dialing and putting into a bridge with an existing channel. |
| 14:55.40 | pabelanger | mjordan, Yup, got it thanks |
| 14:55.45 | file | I actually don't like /dial >_> |
| 14:56.23 | mjordan | neither do I |
| 14:56.35 | pabelanger | leedm777, Ya, I figured it out. I was more looking at it from reworking the action part of the URL, but I'll hold off until I get more of the toggle actions up on review board |
| 14:56.40 | leedm777 | Then let's kill it, before it's too late. |
| 14:56.54 | mjordan | We'll at least need /indicate before we could do that. |
| 14:57.17 | mjordan | And I feel like we'd need quite the discussion before we take it out behind the woodshed and perform an old yeller operation |
| 14:57.27 | pabelanger | well, I don't like /channel/id/continue I think that should be /exit :D |
| 14:57.47 | mjordan | hands pabelanger his pedantry award |
| 14:58.44 | leedm777 | pabelanger: maybe. the name has been really weird since we added the ability to goto a CEP. |
| 14:58.52 | leedm777 | maybe it should just be /goto |
| 14:59.12 | pabelanger | Yup, I'm opened to something else |
| 14:59.21 | pabelanger | other then continue |
| 14:59.24 | file | leedm777, that sort of gets muddied if you don't specify a goto |
| 14:59.50 | leedm777 | file: and continue gets muddled if you do. |
| 14:59.55 | file | indeed |
| 15:00.00 | file | 'tis overloaded |
| 15:00.08 | Qwell | I was told to. :( |
| 15:00.21 | leedm777 | Qwell: don't worry. we all blame mjordan. |
| 15:00.35 | Qwell | oh, well, carry on then |
| 15:05.07 | pabelanger | Qwell, I heard you got fired up at the astricon party man |
| 15:05.39 | pabelanger | last time I see you, you were doing shots of crown at the bar |
| 15:06.32 | file | that reminds me... |
| 15:07.05 | file | putnopvut, YOU |
| 15:10.19 | wdoekes | for the interested: the channel that causes the SIP device state info to be updated after hangup, has the DISABLE_DEVSTATE_CACHE flag, so the channel doesn't go back to UNKNOWN after IN_USE. it seems odd that that the no-cache flag is only set when hanging up the call. and if no-cache is set, shouldn't it at least clear older entries? |
| 15:11.37 | file | the flag is supposed to be set for the lifetime of the channel, so that it is never in the cache to begin with |
| 15:12.27 | wdoekes | did I mention I was using local channels? |
| 15:13.53 | wdoekes | (although.. let me confirm this with a digium version first before I send you on a goose chase) |
| 15:15.43 | wdoekes | (ok, confirmed, clean ast 11 suffers from the same issue) |
| 15:16.29 | wdoekes | (where with clean I mean I only patched it to return UNKNOWN when p->is_realtime in sip_devicestate) |
| 15:18.08 | pabelanger | gebus, I segfaulted GCC by compiling asterisk |
| 15:18.09 | pabelanger | http://pastebin.com/jgtj5jg7 |
| 15:18.44 | leifmadsen | asterisk is too powerful for gcc now |
| 15:19.14 | putnopvut | file: why have I incurred your wrath? |
| 15:19.21 | file | putnopvut, see jabber! |
| 15:20.48 | mjordan | wdoekes: hm... Local channels aren't ever cached. I'm curious how it propagated over to the SIP channel however. Maybe a masquerade copied the flag errantly? |
| 15:22.19 | mjordan | I do enjoy how gcc immediately blamed your hardware. We should do that. Catch SIGSEV, write out to ferror "your machine sucks" then re-signal |
| 15:22.28 | mjordan | ferror/stderror |
| 15:22.43 | Marquis42 | mjordan: haha |
| 15:23.37 | file | "An error has been detected with chan_sip, you should replace your hardware." |
| 15:23.45 | file | and then... Digium could go into the hardware business |
| 15:23.54 | file | #brilliant |
| 15:24.20 | mjordan | makes a note to talk to sruffell |
| 15:26.18 | sruffell | heh |
| 15:36.41 | wdoekes | mjordan: [2013-10-15 17:35:31] WARNING[6535][C-00000000]: channel.c:6955 ast_do_masquerade: XXX-WJD: orig->clone: Local/ID12@ctx-00000000;1->SIP/account-00000001 cache=1->0 |
| 15:36.58 | wdoekes | isn't it errantly *not* copying it? |
| 15:38.15 | wdoekes | disregard that.. I'm going home |
| 15:39.36 | leifmadsen | heh |
| 15:43.18 | file | I'm not sure I like a general /indicate... |
| 15:46.48 | mjordan | file: I'm not sure either |
| 15:47.15 | mjordan | I think my fear is having /ringing, /progress, /busy, /congestion, /ISDN_concept showing up as operations on a channel |
| 15:48.25 | file | nods |
| 15:48.50 | pabelanger | okay, peeps. Why do we have /channels/:id/hold and /channels/:id/moh, from what I see, they do the samething in asterisk. couldn't we just merge the two functions together? |
| 15:50.19 | file | erm, no, the end result in some situations may be the same... but they are different |
| 15:50.19 | mjordan | pabelanger: yeah, I'm not a fan either. Unfortunately, they are two separate things. Hold implies something will be sent back to your phone (signaling wise). MoH is completely independent and is just Asterisk playing music for you. Your phone never has its media path restricted. |
| 15:50.34 | mjordan | It'd be nice if we could combine them, but I'm not sure we can |
| 15:51.08 | pabelanger | okay |
| 15:51.14 | pabelanger | so, let me think |
| 15:51.59 | pabelanger | what about something like /endpoints/:id/hold and /channels/:id/hold, to explicitly control where the hold happens |
| 15:52.13 | pabelanger | that seems to be the difference right? |
| 15:52.26 | mjordan | You can't really hold the endpoint |
| 15:52.39 | mjordan | An endpoint may have one or more channels associated with it |
| 15:52.52 | mjordan | i.e., a DAHDI trunk (once we actually get that part in there) |
| 15:52.57 | leifmadsen | ARI == Asterisk RESTful Interface ? |
| 15:53.05 | mjordan | Asterisk REST Interface |
| 15:53.06 | leifmadsen | I can't actually find it defined on wiki.asterisk.org very easily :) |
| 15:53.12 | leifmadsen | mjordan: thanks, I was unsure about 'ful' |
| 15:53.13 | leifmadsen | :) |
| 15:53.18 | mjordan | it probably says RESTful in some places, but I've been going through and updating things |
| 15:53.29 | mjordan | the interface is RESTful; it is a REST interface |
| 15:53.29 | leifmadsen | https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Documentation |
| 15:53.33 | leifmadsen | that page likely needs some love |
| 15:53.35 | mjordan | drat |
| 15:53.56 | leifmadsen | oddly enough, I see ARI everywhere, but it not defined in the most common pages :) |
| 15:54.43 | leifmadsen | bah! |
| 15:54.45 | leifmadsen | I edited your edit |
| 15:54.50 | leifmadsen | and now I'm redundant |
| 15:55.08 | leifmadsen | fixed |
| 15:56.49 | file | mjordan, I'm doing dtmf separately for sure. |
| 16:03.25 | pabelanger | die die! |
| 16:06.27 | *** join/#asterisk-dev gtjoseph (~gtj@unaffiliated/gtj) |
| 16:07.31 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 16:17.39 | danjenkins | while you're all on here - i configured ast 12 on mac and did make menu select and then did make install and i got this: https://gist.github.com/danjenkins/5383f2a9b57b705de038 - what did i do wrong? - i blame leedm777 entirely ;) |
| 16:18.16 | leedm777 | danjenkins: what have you done :-O |
| 16:18.26 | danjenkins | leedm777: :( |
| 16:18.29 | file | what the... |
| 16:18.42 | danjenkins | oh good, so it wasnt a simple mistake |
| 16:19.00 | danjenkins | i think thats a sign to move on to debian so i can play with ast 12 ;) |
| 16:19.18 | file | the half a thread got tired |
| 16:19.38 | danjenkins | what? @file |
| 16:19.53 | file | danjenkins, Macs only have half a thread #troll |
| 16:20.04 | file | the rest is in the cloud |
| 16:20.09 | danjenkins | file: :x |
| 16:20.16 | leedm777 | danjenkins: I keep telling file it's about simplicity. it's got the good half of the thread. |
| 16:22.16 | danjenkins | i think file did something to my mac while i was at astricon, first of all my demo didnt work, now this! |
| 16:24.36 | danjenkins | ive got to leave work now - let me know if you want me to open an issue on the tracker for mac install issues - makes me sad, im going to have to use a VM! |
| 16:26.42 | danjenkins | ah this looks promising https://groups.google.com/forum/#!msg/astrometry/9P3Tg2PLg1Q/WuQEJbmp9v4J |
| 16:48.23 | file | what _does_ the fox say? |
| 17:01.24 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 17:20.33 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-jspdayfamnnbyioy) |
| 17:28.19 | leifmadsen | file: it says, "kill me, because this song is stupid": |
| 17:28.20 | leifmadsen | :) |
| 17:28.38 | file | lies |
| 17:29.06 | leifmadsen | I don't believe in doing development on your base machine anyways :) |
| 17:29.18 | leifmadsen | so if you're going to spin up a VM, it might as well be Linux, then you can avoid the headaches |
| 17:35.15 | leifmadsen | anyone know danjenkins github username? |
| 17:35.28 | leifmadsen | I want to follow his realtime stuff |
| 17:36.27 | sgriepentrog | https://github.com/danjenkins |
| 17:36.48 | leifmadsen | oh I know where I went wrong... |
| 17:37.03 | leifmadsen | I did a search for danjenkins, but I was on the kickstandproject page, and it was only searching in the local repo |
| 17:38.02 | sgriepentrog | And you probably actually want https://github.com/holidayextras |
| 17:42.52 | pabelanger | mjordan, /channel/:id/answer and /channel/:id/hold are changing the state of the channel? |
| 17:43.35 | mjordan | answer certainly does |
| 17:43.50 | mjordan | I would say hold does, although in the guts of Asterisk, hold has never really been a channel state |
| 17:45.17 | mjordan | think about it this way: in both operations, the channel now has different things available to it. With the case of Answer, you may terminate Ringing indications, start billing, and generally push something back to the channel that tells the device that there is an audio path from the device to Asterisk. That is definitely a change in channel state. |
| 17:45.33 | mjordan | With hold, you're altering the state of the media. Hold implies that the device itself is informed that the media path is restricted |
| 17:45.53 | mjordan | Since in ARI media path == channel, changing Hold is changing the state of the channel in some fashion |
| 17:48.35 | pabelanger | what about /mute, is that local to asterisk or sent to the far end? |
| 17:48.43 | file | local |
| 17:49.16 | pabelanger | ok |
| 17:49.43 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 17:51.08 | pabelanger | really trying to figure out a way to have only hold or moh. Think that is going to be confusing to people |
| 17:51.13 | pabelanger | but, will think about it more |
| 17:51.17 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:51.17 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:51.46 | file | I don't think there's a way to do it without confusing people, besides removing one of them |
| 17:51.51 | pabelanger | right |
| 17:51.56 | file | because no matter what you are going to expose it, and then you are going to have to explain the difference |
| 17:52.14 | pabelanger | ya, that's why I was asking if hold was a state |
| 17:52.24 | pabelanger | where you could just POST the /channel and modify it |
| 17:52.29 | pabelanger | but, not sure that is the right way either |
| 17:52.38 | pabelanger | okay, moving on |
| 17:53.14 | pabelanger | Since DELETE /channels/:id is to hang up a channel, I propose POST /channel/:id should be to answer. Then we can drop the explicit /answer flag |
| 17:54.03 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 17:55.10 | file | erm, you mean a new /channel instead of /channels too? |
| 17:55.53 | pabelanger | no |
| 17:55.57 | pabelanger | that was a typo |
| 17:56.07 | pabelanger | <PROTECTED> |
| 17:56.09 | file | then that's confusing... since a POST on /channels is for originating a channel |
| 17:56.30 | file | then if you specify an :id now it's answering a specified channel... |
| 17:57.09 | pabelanger | well, same logic, but for dial then |
| 17:57.19 | file | huh? |
| 17:57.37 | pabelanger | <pabelanger> Since DELETE /channels/:id is to hang up a channel, I propose POST /channel/:id should be to dial. Then we can drop the explicit /dial flag |
| 17:58.01 | file | there's a thread on the app-dev list about just removing /dial |
| 17:58.06 | pabelanger | lol |
| 17:58.13 | file | but that still doesn't remove originating using POST /channels |
| 17:58.18 | file | (and rightly shouldn't) |
| 17:59.02 | pabelanger | so, if dial is removing, and you cannot originate POST /channel/:id I think answer is a good use for it |
| 17:59.34 | pabelanger | trying to keep things in a toggle logic for POST / DELETE |
| 17:59.46 | pabelanger | and the toggle for hangup is answer |
| 18:00.02 | file | I don't agree with that... that seems confusing to me. |
| 18:00.31 | file | if we didn't use POST /channels for origination then yes, but having without an id be originate a call and having it with an id be answer seems... conflicting |
| 18:01.11 | pabelanger | what happens if you add DELETE /channels would that be to hang up all channel or cancel the origination? |
| 18:01.35 | file | you can't currently cancel an origination, and I don't think you can do a DELETE on /channels |
| 18:02.06 | sgriepentrog | shoudln't you be able to delete a /channel/id returned from origination? |
| 18:02.13 | pabelanger | can't today, but we could add something. Depending on what we want it to do |
| 18:02.25 | file | of course. |
| 18:03.15 | file | sgriepentrog, should be able to actually! |
| 18:04.13 | file | can't say I've tried it with my patch... |
| 18:30.25 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 18:34.30 | pabelanger | I mentioned this yesterday, but it is possible that some events are not published when using the ARI? For example, I don't see any bridge events for hold / unhold |
| 18:37.20 | file | it is possible that the flow and usage is such that the normal place where such events are published is not hit, yes |
| 18:43.46 | mjordan | Hold/Unhold should be a channel event, and it may not be conveyed over ARI. Stasis messages don't necessarily always have to be published over any interface |
| 18:43.55 | mjordan | decoupling ftw |
| 18:52.34 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 19:00.01 | mjordan | jsmith: ping |
| 19:10.09 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 19:18.53 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:18.54 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 19:22.14 | putnopvut | Playing with swagger-ui for the first time. What's the URI that I point it to in order to get the big list of operations I can perform and such? I know the API key is the username:password of the ARI user. |
| 19:22.45 | file | http://<ip address>:8088/ari/api-docs/resources.json |
| 19:22.54 | putnopvut | Excellent. Thanks |
| 19:28.32 | leifmadsen | hawt, I need to set that up too |
| 19:31.40 | file | it's nifty |
| 19:32.54 | leifmadsen | mostly need to set it up so I can show off the API stuff to my boss |
| 19:33.01 | leifmadsen | then he can have JIPM over the new stuff |
| 19:34.31 | sgriepentrog | JIPM? |
| 19:36.04 | leifmadsen | it's best you don't know |
| 19:42.22 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:42.22 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:51.12 | jsmith | mjordan: pong |
| 20:13.11 | mjordan | jsmith: sorry, meeting'd. Mind if I PM you? |
| 20:13.21 | jsmith | mjordan: Not at all |
| 20:14.23 | file | PM = project manage! |
| 20:14.26 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 20:14.33 | mjordan | or project mismanage :-P |
| 20:17.43 | malcolmd | wait, wait, that's my department |
| 20:21.07 | jsmith | malcolmd: Project or product? |
| 20:21.11 | jsmith | ducks and hides? |
| 20:21.18 | malcolmd | the mismanagement bit :D |
| 20:21.28 | jsmith | malcolmd: Good call! |
| 20:22.08 | malcolmd | swing and a miss! |
| 20:22.47 | file | duck, duck, GOOSE! |
| 20:26.06 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 20:34.20 | *** join/#asterisk-dev oron (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 20:59.19 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:20.16 | *** join/#asterisk-dev AlexForster (~AlexForst@63.139.112.162) |
| 21:24.19 | tm1000 | mjordan: can you fix my name on https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2013 :-) |
| 21:24.21 | tm1000 | nagy* |
| 21:30.23 | malcolmd | fixed |
| 21:31.11 | *** join/#asterisk-dev otherwiseguy (~otherwise@bzq-218-90-50.red.bezeqint.net) |
| 21:33.58 | tm1000 | whoo malcolmd <3 |
| 21:34.08 | malcolmd | yargh! :D |
| 21:34.25 | mjordan | tm1000: eek, sorry |
| 21:34.40 | tm1000 | mjordan: I shake your hand and everything and this is my payment |
| 21:34.41 | tm1000 | hahaha |
| 22:05.20 | danjenkins | ive only had 45 views on my astricon presentation this year, i was into the hundreds by this time last year! people obviously don't appreciate the star wars lego slides |
| 22:07.29 | sruffell | heh…I only heard good things about that presentation. |
| 22:07.37 | danjenkins | that was very off topic, i blame tm1000 entirely talking about the astridevcon wiki ;) |
| 22:08.06 | danjenkins | thanks sruffell ! |
| 22:18.02 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-zqbeulumpqeouyzy) |
| 22:18.26 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 22:23.43 | roderickm | danjenkins: where is the presentation published? |
| 22:28.41 | roderickm | ah, found it in a tweet… http://www.slideshare.net/danjenkins/bringing-realtime-voip-metrics-to-2013 |
| 22:32.55 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 23:17.02 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-rfgcdyrtgzznegqj) |
| 23:45.39 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |