| 02:01.11 | *** join/#asterisk-bugs Deeewayne (n=dwayne@75.76.254.162) |
| 02:01.11 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 03:20.57 | *** join/#asterisk-bugs _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 04:08.28 | *** join/#asterisk-bugs _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 04:12.57 | *** join/#asterisk-bugs _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 05:35.38 | *** join/#asterisk-bugs _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 06:20.05 | *** join/#asterisk-bugs Hatrix (n=Hatrix@213.201.24.127.static.user.ono.com) |
| 17:52.58 | *** join/#asterisk-bugs infobot (i=ibot@rikers.org) |
| 17:52.58 | *** topic/#asterisk-bugs is Asterisk Bugs Discussion -=- http://issues.asterisk.org/ -=- http://asterisk.org/developers/bug-guidelines - Discussions not related to reported issues should be in #asterisk -=- Test bugs marked Ready For Testing! -=- http://xkcd.org/583/ |
| 18:40.46 | leifmadsen | Corydon76-dig: ping |
| 18:42.12 | Corydon76-dig | pong |
| 18:43.02 | leifmadsen | Corydon76-dig: I'm just testing 13140, and was looking for an example, but I think I just figured it out. (Feel free to elaborate on any particular tests I should perform if you wish.) |
| 18:43.19 | Corydon76-dig | Cool |
| 18:51.15 | *** join/#asterisk-bugs |Cybex| (n=John@80.100.126.176) |
| 18:54.19 | *** join/#asterisk-bugs BlargMaN00 (n=blarg@12.234.16.130) |
| 18:54.24 | leifmadsen | Corydon76-dig: ok, so everything I've tested works fine, but I don't think I'm hitting any of the more advanced tests which are the reason for this new function. Can you give me some ideas as to tests to run that would cause the MASTER_CHANNEL() function to return something different than ${HANGUPCAUSE} ? |
| 18:57.14 | Corydon76-dig | leifmadsen: think about dialling more than one at a time |
| 18:57.36 | leifmadsen | which I just did -- the MASTER_CHANNEL() function documentation doesn't really give any examples or usage info |
| 18:57.42 | Corydon76-dig | leifmadsen: and at least one is busy, nonexistent, or other, and another channel answers |
| 18:58.01 | leifmadsen | is there multiple arguments I can pass to the function to get the status of a particular channel? |
| 18:58.09 | leifmadsen | (which seems to be the purpose of the function) |
| 18:59.06 | Corydon76-dig | Okay, another use of MASTER_CHANNEL... to get the name of the dialling channel in the macro phase of the target channel |
| 18:59.39 | leifmadsen | you mean with M() flag of dial() ? |
| 18:59.41 | Corydon76-dig | So you dial, with a macro... you run ${MASTER_CHANNEL(CHANNEL)} and you get the name of the originating channel |
| 18:59.49 | Corydon76-dig | Right |
| 19:00.14 | leifmadsen | (this is the same functionality I was looking for a while back I think for an ABE customer :)) |
| 19:00.40 | leifmadsen | well... not quite -- I was looking for the same variable name on the stack of variables, but I think this would have worked with what I was trying to do |
| 19:01.00 | leifmadsen | anyways, just setting up that other test now -- but this all seems to be working fine from what I can see |
| 19:02.47 | leifmadsen | I'm trying to think of something that would be useful inside a Local channel |
| 19:03.03 | leifmadsen | oh -- maybe the same sort of test would be good |
| 19:05.36 | leifmadsen | Corydon76-dig: ok, so all that seems to be good. Would it be useful / warranted to have an option of how many levels back to go? |
| 19:06.22 | leifmadsen | i.e. Dial(Local...) --> Dial(SIP...,,M(getOrigChannel)) --> Output original Dial() |
| 19:06.37 | leifmadsen | (output original channel that executed Dial(), rather) |
| 19:06.45 | Corydon76-dig | leifmadsen: I have no idea how that would be useful or how I would write it |
| 19:07.04 | leifmadsen | hey, just throwing it out there :) I will comment on the original issue |
| 19:09.50 | Corydon76-dig | Okay, I have an idea of how I could write it, but to be sure, I'd have to know why that would be helpful |
| 19:12.02 | leifmadsen | I was just thinking of it because I called a Local channel that did a Dial() to a SIP channel, and since it was returning the Local channel that originated (as it should), I got thinking about whether someone would want to know the channel that called the Local channel. It's still a separate feature request from the original issue. I was just brainstorming. I have no reason why that would be useful. |
| 19:12.41 | Corydon76-dig | Well, I think knowing the channel that called the Local channel would definitely be useful, too |
| 19:13.05 | Corydon76-dig | I just don't see how knowing anything about the Local channel would be, though |
| 19:13.30 | Corydon76-dig | I'd want MASTER_CHANNEL to transcend that structure, always |
| 19:26.09 | leifmadsen | Corydon76-dig: that's what I'm saying though -- using M() from the Dial inside the Local channel returns the Local channel, not the originating channel (2 layers back) |
| 19:26.26 | Corydon76-dig | leifmadsen: that needs to be fixed, then |
| 19:28.21 | leifmadsen | Corydon76-dig: see note I just added to 13140 for an example of what I mean |
| 20:07.04 | *** join/#asterisk-bugs seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 20:07.04 | *** mode/#asterisk-bugs [+o seanbright] by ChanServ |
| 20:19.18 | *** join/#asterisk-bugs leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:19.18 | *** mode/#asterisk-bugs [+o leifmadsen] by ChanServ |
| 20:36.13 | *** join/#asterisk-bugs lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 21:59.34 | *** join/#asterisk-bugs lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 21:59.46 | Corydon76-dig | codefreeze-lap: ping |
| 22:00.06 | codefreeze-lap | Corydon76-dig: hey, how goes? |
| 22:00.22 | Corydon76-dig | Not bad, have a bugnote for you to look at |
| 22:00.36 | Corydon76-dig | M15557~108618 |
| 22:02.07 | codefreeze-lap | Dequoting? |
| 22:02.29 | Corydon76-dig | Yeah, but the last bugnote is something particular to AEL |
| 22:03.56 | Corydon76-dig | and really, it's a question of "what do you think it should do?" |
| 22:04.32 | codefreeze-lap | OK, yes, it's an ugly world when your language is context dependent... |
| 22:05.49 | codefreeze-lap | And that is right: SHOULD it keep the quotes? |
| 22:07.11 | Corydon76-dig | The difficulty was why I wanted to ask your opinion on the matter |
| 22:08.27 | *** join/#asterisk-bugs freddyk (n=freddy@host44-174-dynamic.51-82-r.retail.telecomitalia.it) |
| 22:08.35 | freddyk | leifmadsen: ping |
| 22:08.47 | codefreeze-lap | The real question to me is IF we decide to keep the quotes, will that prevent MSet from spotting that comma? |
| 22:09.03 | Corydon76-dig | Yes, it will |
| 22:09.19 | Corydon76-dig | although it will also kill the quotes at the same time |
| 22:10.55 | codefreeze-lap | Corydon76-dig: my, my. I was going to write "that's MSet's problem", but.... are we "hitting the wall" of the context dependent world here? |
| 22:11.39 | Corydon76-dig | Well, part of the problem is that we're running up into the wall of backwards compatibility |
| 22:13.08 | Corydon76-dig | What I really wanted to ask was, "Is there any reason why AEL is calling MSet explicitly instead of Set?" |
| 22:13.41 | codefreeze-lap | Corydon76-dig: good question.... I'd have to investigate that one. |
| 22:13.41 | Corydon76-dig | Is it just to avoid the ambiguity of two different behaviors of Set, based upon a config variable? |
| 22:14.27 | Corydon76-dig | because I can't think of a situation where we really want the behavior of MSet from AEL, but instead we're likely to ALWAYS want the new behavior of Set and never the old. |
| 22:15.02 | Corydon76-dig | In which case, do we need another Set application that doesn't depend upon that variable? |
| 22:15.19 | Corydon76-dig | i.e. "Set1" or something like that? |
| 22:16.48 | codefreeze-lap | Corydon76-dig: warning: you caught me pretty cold on this issue. I'll just have to sit with it for a little while to give you any dependable answers! |
| 22:19.51 | Corydon76-dig | codefreeze-lap: I think "Set1" is the way to go, and LMK if you find a problem with that approach |
| 22:20.17 | Corydon76-dig | My suspicion is that you're NEVER setting multiple variables in a single line from AEL |
| 22:20.34 | Corydon76-dig | If that's true, then always doing a Set1 is preferable to MSet |
| 22:29.34 | leifmadsen | freddyk: pong |
| 22:30.42 | leifmadsen | RealSet() :) |
| 22:34.19 | Corydon76-dig | leifmadsen: SSet would be the other possible name. |
| 22:40.14 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:40.14 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 22:46.53 | freddyk | leifmadsen: i've found another bug in chan_sip at transmit_register |
| 22:47.00 | freddyk | going to post tomorrow in the morning |
| 22:47.08 | freddyk | bug details and patch |
| 22:47.40 | lmadsen | ok |