| 00:43.14 | Kobaz | M16796 |
| 00:43.17 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/General 0016796: Crash when destroying sip channels reported by kobaz https://issues.asterisk.org/view.php?id=16796 |
| 00:43.18 | Kobaz | i love you guys |
| 00:43.24 | Kobaz | where do i send the cakes and cookies |
| 00:49.02 | *** join/#asterisk-dev goldenear (~goldenear@2a01:e35:2e58:8df0:21c:b3ff:fec6:943a) |
| 00:57.56 | *** join/#asterisk-dev xpot-mobile (~xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 01:42.24 | *** join/#asterisk-dev rvhi (~chatzilla@udp219966uds.hawaiiantel.net) |
| 01:42.58 | rvhi | any bug marshal here? I found the issue with bug ID 0016754 |
| 01:53.31 | snuff-work | yes? |
| 02:18.59 | Kobaz | hmmm |
| 02:19.04 | Kobaz | when are channel datastores supposed to be freed |
| 02:55.10 | Kobaz | never mind |
| 03:16.24 | *** join/#asterisk-dev pyite (~dschreibe@unaffiliated/pyite) |
| 03:16.27 | pyite | jsmith-away: yooo |
| 03:48.59 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 06:09.41 | *** join/#asterisk-dev fiddur (~fiddur@192.121.104.121) |
| 07:06.14 | *** join/#asterisk-dev techie (~root@unaffiliated/techie) |
| 07:40.27 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 07:40.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:43.55 | *** join/#asterisk-dev mpe (~mpe@gate.ipvision.dk) |
| 07:45.39 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 07:45.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:31.06 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:46.22 | *** join/#asterisk-dev Amorsen (~Amorsen@94.127.50.7) |
| 09:06.15 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:06.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:11.47 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:11.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:12.44 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:12.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:20.00 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:20.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:20.45 | oej | Good morning folks |
| 10:03.18 | *** join/#asterisk-dev d-k-t (~D@112.202.232.46) |
| 10:38.22 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 10:38.23 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:09.44 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 11:13.12 | *** join/#asterisk-dev michael-i (~michael-i@141.41.40.185) |
| 11:20.30 | michael-i | Hi everyone. After moving from DAHDI 2.2.0.2 to 2.2.1 on Asterisk 1.6.1.14, my Blackfin build is no longer loading tonezones. It always complains: "Unable to play dialtone on channel 1, do you have defaultzone and loadzone defined?" |
| 11:21.40 | michael-i | I noticed that the zone ioctl was refactored quite a bit between those versions and I'm wondering if it is to blame. I'm also using custom drivers in this build which were developed using 2.2.0.2. Anything I should update or look at? I really appreciate any pointers. |
| 11:24.52 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 11:33.22 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 11:33.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:17.09 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 12:22.30 | *** join/#asterisk-dev caio1982_ (~caio1982@CAcert-br/caio1982) |
| 12:34.56 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:34.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:38.20 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.24.62.66) |
| 13:21.53 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 13:21.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:48.50 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:49.47 | *** join/#asterisk-dev vrban (~chatzilla@p50997436.dip0.t-ipconnect.de) |
| 14:06.51 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 14:24.24 | *** join/#asterisk-dev moy (~moy@74.12.129.100) |
| 14:27.16 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:27.16 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:34.28 | *** join/#asterisk-dev mnt_real (~sinan@bas1-montreal43-1177754737.dsl.bell.ca) |
| 14:41.37 | *** join/#asterisk-dev ccesario (~ccesario@189-19-6-236.dsl.telesp.net.br) |
| 14:52.01 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:52.01 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:02.06 | Kobaz | hmmm |
| 15:02.22 | Kobaz | sometimes SoftHangup on a local channel doesn't hang up both legs |
| 15:02.30 | Kobaz | on a single local channel leg.. ie: hanging up Local/...;2 |
| 15:02.45 | Kobaz | i'll have to write some more tests to get a simple case |
| 15:10.41 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:10.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:18.10 | Kobaz | if I ast_calloc some space for an AST_RWLIST_HEAD do i need to run AST_LIST_HEAD_INIT() on it? |
| 15:19.49 | Kobaz | AST_RWLIST_HEAD(found_groups_list, found_group); |
| 15:19.49 | Kobaz | struct search_data_store { struct found_groups_list found_groups_head; }; |
| 15:20.44 | Kobaz | so then i make some pointers, and calloc some space for a search_data_store, which has the list head struct |
| 15:21.05 | Kobaz | AST_LIST_HEAD_INIT doesn't like operating on a list head defined like that |
| 15:36.36 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 15:36.36 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:38.38 | *** join/#asterisk-dev steliosk (~Stelios@ipa107.2.tellas.gr) |
| 15:43.28 | *** join/#asterisk-dev philipp64 (~chatzilla@63.224.43.239) |
| 15:54.57 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:54.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:57.47 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:57.47 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:58.02 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:17.07 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:32.48 | pyite | jsmith: yo |
| 16:35.56 | Kobaz | SHARED has a bug |
| 16:37.10 | Kobaz | if you set SHARED(foo,SIP/123)... and read ${SHARED(foo)} on SIP/123.... you don't get the variable... but if you read ${SHARED(foo,SIP/123)} it works |
| 16:42.54 | putnopvut | didn't even know there was a function called SHARED |
| 16:44.36 | Corydon76-dig | putnopvut: it's a space for sharing variables between channels, without enabling full write access to another channel's variable namespace |
| 16:45.00 | putnopvut | mkay |
| 16:47.10 | leifmadsen | I didn't know either :) |
| 16:47.16 | putnopvut | Kobaz: looking at the code, it's not obvious why that would cause a problem. |
| 16:47.17 | Corydon76-dig | The idea was "this is a volatile namespace" |
| 16:47.32 | putnopvut | shared_write appears to write the data to SIP/123's shared_variable datastore. |
| 16:47.45 | kpfleming | the issue is that he misunderstood how it works |
| 16:47.56 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 16:47.58 | kpfleming | or the function is not properly supplying the 'current' channel name when none is supplied |
| 16:47.59 | putnopvut | Is it a different instance of a channel for device SIP/123? |
| 16:48.03 | Kobaz | yeah |
| 16:48.20 | Kobaz | kpfleming: correct, not properly supply the current channel name |
| 16:48.21 | kpfleming | SIP/123 is not a channel name |
| 16:48.27 | Kobaz | well |
| 16:48.29 | Kobaz | that was an example |
| 16:48.29 | kpfleming | SIP/123-0945878 is a channel name |
| 16:48.31 | Kobaz | SIP/123-234234 |
| 16:48.42 | kpfleming | did you use the full channel name in both places? |
| 16:48.54 | Kobaz | <PROTECTED> |
| 16:48.54 | Kobaz | <PROTECTED> |
| 16:48.54 | Kobaz | <PROTECTED> |
| 16:49.06 | Kobaz | third line is empty... second line has the variable |
| 16:49.18 | kpfleming | and what was the name of the channel this ran on? |
| 16:49.23 | Kobaz | IAX2/branch-779 |
| 16:49.36 | kpfleming | then that sounds like a bug in SHARED |
| 16:49.40 | Kobaz | yeap |
| 16:49.53 | kpfleming | there is an easy workaround though :-) |
| 16:49.55 | Kobaz | yeah |
| 16:49.58 | Kobaz | i'm using it |
| 16:50.13 | putnopvut | If there's a bug in the SHARED code, it is certainly not obvious. |
| 16:50.24 | Kobaz | i'll sift through it later and fix the bug if you guys don't beat me to it |
| 16:50.42 | Kobaz | trying to get all this crap written for monday |
| 16:51.00 | Kobaz | this is on 1.6.0.22 |
| 16:51.22 | putnopvut | Ah, I was looking at the trunk code. |
| 16:51.52 | Kobaz | yeah, sorry |
| 16:52.15 | Corydon76-dig | putnopvut: still not obvious |
| 16:57.52 | Kobaz | i dunno either... my stuff is pretty complex, it's a mixture of agi and dialplan.. it might have to do with the mix |
| 16:59.49 | Kobaz | it's definitly something to do with it |
| 16:59.56 | Kobaz | regular channel variables aren't working properly either |
| 17:01.13 | Kobaz | like... I'm using AGI(agi://..), and later on in the call flow, i use Bridge to hijack the channel in AGI |
| 17:01.54 | Kobaz | so the AGI sets some variables, exits... and when the caller to Bridge() hangs up... the caller channel continues on in the dialplan after the AGI() call... and none of the variables that I set before the agi exists, are available |
| 17:02.50 | Kobaz | SHARED(xx,channel) is available when running the agi... but as soon as i exit the agi, those variables are gone |
| 17:03.07 | Kobaz | and from within the agi SHARED(xx) doesn't work... when running on the channel with the variable |
| 17:03.16 | Kobaz | i'll have to write some test cases... it's really nutty |
| 17:15.43 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 17:31.37 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 17:31.42 | *** join/#asterisk-dev m_c_le (~marcello@2001:470:1f0b:d4b:2e0:4dff:fe6c:9372) |
| 17:33.46 | m_c_le | hi |
| 17:34.02 | m_c_le | short question |
| 17:34.08 | m_c_le | who can i spilt a bridged channel into two separat channels to put them to conference? |
| 17:43.22 | *** join/#asterisk-dev xpot-mobile (~xpot@173-14-232-121-Utah.hfc.comcastbusiness.net) |
| 18:08.35 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:08.36 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:25.00 | Kobaz | m_c_le: that's more of a question for #asterisk... but you can use AMI Redirect |
| 18:25.25 | Kobaz | m_c_le: this is for developer talk... like if you're working on the source code of asterisk itself... not writing dialplan, or making phone calls |
| 19:16.04 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:19.38 | m_c_le | i know |
| 19:19.57 | m_c_le | that a developer question |
| 19:20.43 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 19:20.44 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:22.04 | m_c_le | i'd like to implemt this in chan_sccp |
| 19:27.31 | m_c_le | Kobaz: any hints for me? |
| 19:39.31 | Kobaz | m_c_le: does Redirect not work for that channel type? |
| 19:40.51 | m_c_le | Kobaz: i'd like to implement it for chan_sccp and manage the channels my self |
| 19:41.24 | m_c_le | Kobaz: so i can kick, mute participants from the phone scrren |
| 19:42.38 | Kobaz | i'm not familiar with sccp... but is that part of the protocol? |
| 19:43.26 | m_c_le | Kobaz: yes |
| 19:43.50 | Kobaz | okay... |
| 19:43.59 | Kobaz | take a look at the code for the ami redirect command |
| 19:44.23 | Kobaz | it supports taking two channels. and moving them somewhere at the same time |
| 19:46.22 | m_c_le | ok, it uses ast_async_goto |
| 19:49.04 | m_c_le | but, do i need exten and context? |
| 19:49.29 | m_c_le | i dont want to go to a exten in dialpaln |
| 19:58.23 | Corydon76-dig | m_c_le: #asterisk, please |
| 19:58.53 | kpfleming | this seems like a legit question for this channel |
| 19:59.08 | m_c_le | Corydon76-dig: ok, thx for helping a developer |
| 19:59.11 | kpfleming | he's wanting to learn how to modify chan_sccp to redirect two channels into a conference room, using the C API |
| 19:59.19 | Corydon76-dig | Oh, okay |
| 19:59.31 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@96.57.203.22) |
| 19:59.46 | Corydon76-dig | Use the dialplan to redirect to the conference, then |
| 20:00.28 | kpfleming | yes, you'd probably need to have chan_sccp act as a dialplan registrar itself, creating a context and extensions for all defined SCCP devices |
| 20:00.33 | kpfleming | those would only be used for conferencing |
| 20:00.41 | m_c_le | isnt it posible to put both channels into ast_bridge_join without using dialplan? |
| 20:01.12 | Corydon76-dig | Almost anything is possible. We're telling you the easiest way |
| 20:01.29 | kpfleming | if you are writing this for trunk/1.6.2, you can use the bridging api like app_confbridge does |
| 20:01.47 | m_c_le | but the easiest way isnt always the best |
| 20:02.17 | m_c_le | what i did is |
| 20:02.26 | m_c_le | using chan1 and chan2 |
| 20:02.45 | m_c_le | chan2 is the bridged channel of chan1 |
| 20:03.26 | m_c_le | created a temporary channel and used ast_channel_masquerade |
| 20:03.59 | m_c_le | my question, do i need ast_do_masquerade |
| 20:04.26 | TheDavidFactor | is there any documentation on the options for the configure script that you run before make when you install asterisk from source? |
| 20:04.30 | Corydon76-dig | Yes, because the second channel starts out as a slave to the first (i.e. without its own thread) |
| 20:04.59 | Corydon76-dig | You need to masquerade into it to give it control enough to talk to the conferencing app |
| 20:05.15 | m_c_le | ok |
| 20:05.17 | m_c_le | thx |
| 20:05.23 | kpfleming | The_Boy_Wonder: only configure --help |
| 20:05.40 | Corydon76-dig | kpfleming: wrong The |
| 20:05.46 | kpfleming | oops |
| 20:05.47 | kpfleming | yeah |
| 20:06.46 | TheDavidFactor | kpfleming: ok, thanks! |
| 20:06.50 | m_c_le | Corydon76-dig: i will try this. the outcome you will see in the next chn_sccp-b release |
| 20:07.56 | Corydon76-dig | Not something I use, but okay |
| 20:15.39 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 20:15.39 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 20:27.50 | wedhorn | having a look at some atomicity, and I'm confused. The atomic declarations seem to be in lock.h but are also included in extconf.c (but don't appear to be used) |
| 20:33.24 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 21:01.14 | Kobaz | The_Boy_Wonder: ./configure --help ? |
| 21:01.30 | The_Boy_Wonder | ? |
| 21:01.35 | Kobaz | er |
| 21:01.45 | file | The_Boy_Wonder: you don't exist. |
| 21:01.50 | Kobaz | that was for TheDavidFactor |
| 21:01.50 | The_Boy_Wonder | :( |
| 21:02.01 | Kobaz | i just hit tab on The |
| 21:02.06 | Kobaz | it seems he left |
| 21:03.37 | wedhorn | on the atomicity, also, there is some difference between those in extconf.c and lock.h |
| 21:04.11 | kpfleming | the extconf stuff is only used for the tools in the utils directory, so is really not important |
| 21:04.15 | Kobaz | the atomicity... in your city.... in your ciiiitttttyyy |
| 21:10.31 | wedhorn | kpfleming: thanks, just deleted the 100 odd relevant lines from extconf.c and seems to compile fine - also looks like there may be a bunch of other stuff in there that doesn't actually do anything |
| 21:10.45 | kpfleming | yep |
| 21:10.58 | kpfleming | probably only needed when certainly compile-time options are set |
| 21:11.03 | kpfleming | and none of it is really used |
| 21:13.51 | wedhorn | kpfleming: the atomic stuff isn't in extconf.h, and I can't see any other reference to extconf.c, and there are no other references to the code in extconf.c |
| 21:14.17 | wedhorn | unless it's really well obfuscated, it appears unused |
| 21:15.04 | Kobaz | it would be cool if extconf was a big more general |
| 21:15.07 | kpfleming | no, but the code that uses extconf.c also brings in other modules from main, and those modules have extern references to many functions |
| 21:15.31 | Kobaz | like a general config file interceptor... because stuff like app_voicemail, directly uses the realtime stuff if it's configured |
| 21:15.37 | Kobaz | that should probably all be transparent |
| 21:15.49 | kpfleming | that has nothing to do with extconf at all |
| 21:15.55 | Kobaz | extconfig |
| 21:16.17 | Kobaz | oh... extconf is different from extconfig? |
| 21:25.30 | wedhorn | ok kpfleming, thanks |
| 21:39.50 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 21:56.49 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 21:56.49 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:10.32 | *** join/#asterisk-dev moy (~moy@74.12.129.100) |
| 22:27.49 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 22:59.40 | marv | What is the intention of the macro_fixup() in app_macro.c? Why does it clear all the macro related channel variables? |
| 23:02.34 | Corydon76-dig | marv: It occurs when a channel running inside a Macro is masqueraded |
| 23:02.47 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 23:03.36 | Corydon76-dig | In that case, the Macro never really returns, so the fixup is to do cleanup of those variables, so that other parts of Asterisk don't behave as if they were still inside a macro that is no longer running |
| 23:04.05 | marv | I have a macro that tries a Dial, and goes to Voicemail if that fails. What I'm seeing is, if a sip attended transfer happen and the user presses the transfer key to complete it before the other end answers, and the other end never answers, the call goes to the wrong voicemail because it's args are from the macro it started it, and not the macro it's in now. |
| 23:06.38 | marv | Corydon76-dig: What I think is happening is macro_fixup clears the variables before do_masq() copies them. If it hadn't cleared them, the args would have been copied and things would have worked, but because it cleared them, the channel only has the macro args it's old struct channel and not it's new struct channel |
| 23:07.39 | Corydon76-dig | That doesn't make any sense. The old one doesn't have any variables, because in a masquerade, you get a completely empty channel |
| 23:07.45 | marv | and since svn blame blames you for that part of the code, i'm glad you answered me, Corydon76-dig. Looking at your log and the bug numbers, and it looks like whatever you changed was to find a blind xfer issue. |
| 23:08.09 | marv | "fix" a blind xfer issue i mean |
| 23:09.03 | Corydon76-dig | If you can propose a different solution that doesn't cause 13363 to regress, I can look at it |
| 23:10.22 | Corydon76-dig | 13363 is the other issue in that commit, which is the real reason for the fix, and yes, it appears to be related to attended transfers |
| 23:10.25 | marv | eh? My understanding was the original call's guts are being copied into the struct for the second call of the guy who answered, who made the second call in order to call the guy he's transferring to |
| 23:11.23 | Corydon76-dig | No, it shouldn't be. The masquerade is to give a slave channel a controlling thread |
| 23:12.07 | Corydon76-dig | So that the original slave channel can redirect the original master channel to the 3rd channel |
| 23:12.35 | marv | I thought in the attended xfer case, the masq was from one thread to another (with 4 total channels involved in the call, two separate calls really until the transfer) |
| 23:12.38 | Corydon76-dig | You shouldn't ever be masquerading one real channel into another. |
| 23:13.15 | Corydon76-dig | Only a real channel into a newly created channel |
| 23:14.14 | marv | the channel we're being copied into can't be newly created, otherwise we couldn't jump inside app_dial while the line was ringing |
| 23:15.37 | Corydon76-dig | Which masquerade are you talking about? |
| 23:15.53 | Corydon76-dig | The builtin_atxfer inside res/res_features? |
| 23:17.53 | marv | I don't actually know where it's initiated from in the code. I would imagine inside chan_sip. What I'm doing is initiating a second call on my polycom and then using it's transfer button. I'm not hitting the features.conf defined code to do an attended transfer. |
| 23:18.14 | marv | I should mention I'm using 1.4.29. I should also thank you for your help some for :) |
| 23:18.36 | Corydon76-dig | Then attempt_transfer in chan_sip.c |
| 23:21.23 | marv | yeah that's looks right. I'm pretty sure peerc can be a channel with it's own thread, and so can peerb |
| 23:22.40 | Corydon76-dig | So is this an attended transfer (no answer on 3) or consultative transfer (answer on 3)? |
| 23:23.01 | Corydon76-dig | It differs on how the masquerade is performed |
| 23:24.11 | marv | attended. I hit the transfer key a second time (which hangs up the polycom) before answering the transferred to phone. In fact i never answer it, i let it roll to voicemail. |
| 23:26.23 | Corydon76-dig | But if you're answering, you're the slave channel, so you should not have a thread |
| 23:26.49 | Corydon76-dig | Right? This isn't a case where you call somebody and then transfer them to someone else |
| 23:27.25 | Corydon76-dig | If you placed the call, you have a thread. If you receive a call, you don't. |
| 23:29.37 | marv | (using attempt_transfer's variables) peerb (thread) calls peera (no thread), who hits transfer (creating peerc (thread)) and calls peerd (nothread). I hit transfer a second time, and asterisk masqs peerb (thread) into peerc's (thread) structure, and hangsup peera, and the original peerc is a zombie, and peerb in peerc's skin is now ringing peerd. |
| 23:31.12 | Corydon76-dig | You have it reversed. peerb is the destination. |
| 23:31.25 | Corydon76-dig | peerc is the source |
| 23:31.42 | Corydon76-dig | peerb becomes a zombie |
| 23:32.17 | marv | ok |
| 23:32.57 | Corydon76-dig | and I'm pretty sure a calls b, not b calls a |
| 23:33.07 | Gugge | https://issues.asterisk.org/view.php?id=16021 who wants to rewiew this one? :) |
| 23:33.27 | Corydon76-dig | b and c go to the same device (your phone) |
| 23:34.25 | Corydon76-dig | Well, wait. b and d go to the same device (your phone) in an attended transfer |
| 23:35.52 | marv | I'm not sure if I agree with your version or not. (this is a bit confusing). I may just turn on debug and do it again to be sure. |
| 23:36.06 | Corydon76-dig | d is NULL because c hasn't answered you yet |
| 23:36.22 | Corydon76-dig | d would be your device, if c had answered |
| 23:36.41 | Corydon76-dig | so in an attended transfer, you really only have 3 channels involved |
| 23:37.15 | Corydon76-dig | So c (no thread) is masqueraded into b (no thread) |
| 23:38.06 | Corydon76-dig | So once the masquerade goes through, a is still bridged to the same pointer, but it's now c that it's actually talking to |
| 23:39.53 | Corydon76-dig | So the fixup should never be called on a, but only on b and c |
| 23:40.11 | Corydon76-dig | So a's macro variables are pristine |
| 23:40.52 | Corydon76-dig | They still have b's variables set, though, not c's, which I think is your complaint, correct? |
| 23:41.24 | Corydon76-dig | a never had c's voicemail settings, because a never rang c, only b |
| 23:41.45 | Corydon76-dig | and the masquerade doesn't really work against a, only b and c |
| 23:42.18 | Corydon76-dig | While it's not ideal for your situation, I don't see how the fixup code could possibly have caused the issue you're having |
| 23:45.32 | marv | I'm still setting up a set to get my variables right, but yeah, something close to that. But I think something slightly more complicated is going on. |
| 23:45.46 | Corydon76-dig | B inherited those variables from A, but they're overwritten when B calls C. So the variables are on two channels that don't make any difference whatsoever when it comes to A advancing in the dialplan |
| 23:46.20 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 23:46.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:48.14 | Corydon76-dig | The only thing that I think would really help you out is the link-id in trunk |
| 23:49.16 | Corydon76-dig | Actually, B has the original variables, but D is calling C, so the original variables would have a chance to make it to C. Still irrelevant for your use case. |
| 23:49.36 | Corydon76-dig | (B and D are 2 channels associated with your device) |
| 23:50.32 | Corydon76-dig | Well, except that D is NULL, because C isn't bridged. But D would be your device, if C had answered and gotten bridged |
| 23:59.27 | marv | I'm compiling 1.4 HEAD just in case my tree has something in it that's interfering. |