| 00:19.52 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 01:10.38 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:10.39 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 01:36.55 | *** join/#asterisk-dev droemel (~droemel@p4FCAD4BA.dip.t-dialin.net) |
| 02:16.40 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-uyxzqlkmotsedose) |
| 02:20.02 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-hobskmothjvjvevg) |
| 02:32.48 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 02:32.48 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 02:33.09 | pabelanger | please update http://doxygen.asterisk.org/ with asterisk 10, 11, 12 |
| 02:33.11 | pabelanger | kthxbye |
| 05:06.55 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:06.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:02.49 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 06:02.50 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 06:03.25 | wedhorn | snuff-work: you wanted to discuss some stuff... |
| 06:09.48 | snuff-work | oh yer :) |
| 06:10.07 | snuff-work | we need to find a way to merge calls |
| 06:10.41 | wedhorn | firstly, why? second, probably easier to wait for the new bridging |
| 06:10.43 | snuff-work | aka ph1 calls ph2.. puts ph2 on hold.. calls ph3.. 'join' |
| 06:11.00 | wedhorn | ala conference |
| 06:11.10 | snuff-work | mm |
| 06:11.58 | snuff-work | i guess.. another round about way for me to do it is to transfer person into conf room |
| 06:12.16 | snuff-work | transfer.. the other thing :) |
| 06:12.53 | snuff-work | if i'm on a call.. press trnsfr.. call another exten.. i can't finish the xfer until the person answers me.. |
| 06:13.13 | WIMPy | Thing with using conferences is the missing possibility to get people out again. |
| 06:13.17 | wedhorn | okay, haven't had that one |
| 06:13.28 | snuff-work | also i got my phone into a weird state with that.. |
| 06:14.14 | wedhorn | WIMPy: my plan would be to retain control of the legs within skinny, so you can use the softbuttons to move then out, or kill them |
| 06:14.34 | WIMPy | Sound good. |
| 06:14.48 | wedhorn | snuff-work: have you tried holding the call first? |
| 06:15.12 | snuff-work | nope i can try.. |
| 06:16.29 | snuff-work | ok it worked.. slight issue with the callerid though |
| 06:16.35 | snuff-work | if i hold 1st.. |
| 06:17.18 | snuff-work | i start calling 2nd person.. hit the 'transfer'.. but when those 2 calls are joined.. their callerid doesn't update.. |
| 06:17.54 | wedhorn | yep, had a play and noticed various issues |
| 06:19.28 | wedhorn | also we don't seem to show the correct softkey set |
| 06:19.53 | wedhorn | also, pressing end call completes the transfer |
| 06:20.19 | snuff-work | mm many issues to solve then :( |
| 06:20.33 | wedhorn | all look fairly trivial |
| 06:20.47 | wedhorn | probably the biggest issue is how it should operate |
| 06:20.51 | snuff-work | i trust ur judgement :) |
| 06:21.12 | wedhorn | hehe, glad someone does, cause I sure don't.... |
| 06:21.32 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 06:21.42 | wedhorn | thinking, press transfer, if call isn't on hold, hold it. Set up new call |
| 06:21.46 | snuff-work | the callerid updating stuff.. u merged into ur fragement branch right? |
| 06:21.53 | wedhorn | this seems to be about right at the moment |
| 06:22.37 | WIMPy | You could delay the hold action until the 2nd call proceeds as the Profisets do. |
| 06:23.02 | wedhorn | press transfer again for a blind xfer (indicate with prompt), press transfer yet again to toggle back to assisted xfer |
| 06:23.28 | wedhorn | dial number |
| 06:23.42 | wedhorn | if blind, push off, else continue ringing |
| 06:24.29 | wedhorn | if you push transfer while still ringing, becomes a blonde xfer (assume that's a last second blind xfer) |
| 06:24.40 | snuff-work | cisco doesn't have a diff between blind and attended.. |
| 06:24.57 | wedhorn | not really worried what cisco do.... |
| 06:25.23 | wedhorn | if call is answered, press transfer to complete |
| 06:25.52 | wedhorn | end call anywhere along the line hangs up the 2nd call leg and leaves you with the original call on hold |
| 06:26.14 | wedhorn | seems reasonable to me so far |
| 06:26.38 | wedhorn | but what if the handset is hung up? |
| 06:27.11 | wedhorn | we can complete the xfer, or hangup the second call and have the original on hold (with device onhook) |
| 06:27.18 | wedhorn | ??? |
| 06:27.26 | snuff-work | i think that's fair.. |
| 06:27.52 | snuff-work | keep the 1st call that was on hold alive even if u onhook |
| 06:28.17 | WIMPy | Or make it configurable? |
| 06:28.55 | WIMPy | You find a 'transfer on hangup' option almost everywhere. |
| 06:29.05 | wedhorn | go WIMPy, easy answer when faced with a choice, do both |
| 06:29.50 | WIMPy | There's even a 3rd (wich I personally don't like): End both calls on hangup. |
| 06:31.19 | WIMPy | Or rather "all calls". |
| 06:31.22 | snuff-work | bb in 2 minutes need reset |
| 06:34.10 | wedhorn | I think I'll ignore the 3rd option |
| 06:36.07 | WIMPy | Sounds reasonable to me. |
| 06:37.04 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 06:37.04 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 06:42.39 | wedhorn | snuff-work: we need to get some of the patches committed. There are 6 on jira at the moment plus a couple others I'm playing with |
| 06:43.04 | wedhorn | Any chance on getting some testing and feedback on them? |
| 06:45.46 | snuff-work | give me the list.. again will try to re-look / apply them |
| 06:46.17 | snuff-work | nm.. i will check it myself.. |
| 06:46.38 | snuff-work | what patches are already added to ur branch? |
| 06:52.06 | wedhorn | anyone know how to share a filter on jira? |
| 06:52.24 | snuff-work | i just list all stuff related to chan_skinny |
| 06:52.33 | snuff-work | that isn't closed |
| 06:53.27 | wedhorn | yep, I've got one. There are 6 items, all current patches by either you or me |
| 06:53.35 | wedhorn | but was going to share it with you |
| 06:53.46 | snuff-work | k |
| 06:53.53 | wedhorn | but can't... |
| 06:54.18 | wedhorn | anyway, all 6 of the open skinny items need some testing and then committing |
| 06:57.08 | snuff-work | k will see what i can do.. bogged down in ccm stuff to do with other site atm.. |
| 06:57.33 | wedhorn | no worries, understand. |
| 06:58.17 | snuff-work | other site will hopefully move off the EVIL alcatel in the coming week.. as it cost us 2 1/2 hrs of isdn porting fail.. (refused to bring up the newer isdn line) |
| 06:58.18 | wedhorn | we are sort of making things hard for ourselves, eg the callid stuff has redirect in one of the patches, which is probably relevant to xfer |
| 06:58.22 | snuff-work | last night |
| 06:59.58 | snuff-work | mm.. how can a mouse trackpad these days have a 95mb driver :( |
| 07:00.08 | snuff-work | not that adsl2 cares.. |
| 07:03.10 | snuff-work | think i may want to make the 'gpickup' into 'pickup'.. to match what ccm does.. |
| 07:03.38 | snuff-work | familiarity is key to acceptance ;) |
| 07:04.03 | wedhorn | softkey templates ... |
| 07:04.56 | snuff-work | that is on my list.. |
| 07:06.41 | snuff-work | think i have some proto code somewhere for that.. or start of.. |
| 07:12.11 | wedhorn | need permission to share filters on jira... |
| 07:12.22 | wedhorn | but this'll work: https://issues.asterisk.org/jira/issues/?jql=project%20%3D%20ASTERISK%20AND%20issuetype%20in%20standardIssueTypes%28%29%20AND%20component%20in%20%28%22Channels%2Fchan_skinny%22%2C%20%22Channels%2Fchan_skinny%2FNewFeature%22%29%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Triage%2C%20%22Waiting%20for%20Feedback%22%29 |
| 07:15.42 | snuff-work | the skinny debug stuff.. |
| 07:15.50 | snuff-work | packet ? sjub ? |
| 07:16.36 | wedhorn | keepalives? |
| 07:17.09 | wedhorn | is confused |
| 07:17.14 | snuff-work | yer |
| 07:17.23 | snuff-work | u said i needed skinny debug somethin on |
| 07:17.33 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 07:17.33 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 07:17.44 | wedhorn | yeah, packet (timing at the end of received keepalive message) |
| 07:18.34 | snuff-work | k told em all to reset |
| 07:18.36 | wedhorn | timing is in comparison to your configured keepalive (default is 120 sec I think) |
| 07:18.54 | snuff-work | got some of these.. |
| 07:18.55 | snuff-work | [2013-03-19 18:18:36] WARNING[11129]: chan_skinny.c:7564 get_input: Skinny Client sent less data than expected. Expected 4 but got 0. |
| 07:18.55 | snuff-work | [2013-03-19 18:18:36] WARNING[11129]: chan_skinny.c:7568 get_input: Skinny Client was lost, unregistering |
| 07:19.11 | snuff-work | i thought u integrated that msg with more info into this branch.. or not ? |
| 07:20.26 | wedhorn | not sure, that looks like a tcp reset rather than packet fragmentation |
| 07:20.53 | snuff-work | well will leave this going overnight on debug packet.. |
| 07:21.09 | snuff-work | now as usual i gotta run ;) |
| 07:21.15 | wedhorn | no need really, just need a few |
| 07:21.18 | wedhorn | have a good one |
| 07:26.58 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 07:32.07 | *** join/#asterisk-dev schmidts (~schmidts@vie-91-186-159-076.dsl.sil.at) |
| 07:32.09 | schmidts | good morning |
| 07:51.47 | *** join/#asterisk-dev oej (~Adium@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 07:51.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:00.19 | *** join/#asterisk-dev niluje (~niluje@bdv75-4-82-227-67-242.fbx.proxad.net) |
| 08:27.31 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:113c:faef:9095:8761) |
| 09:56.30 | *** join/#asterisk-dev niluje (~niluje@bdv75-4-82-227-67-242.fbx.proxad.net) |
| 10:45.22 | *** join/#asterisk-dev jmls (~jmls@217.144.151.2) |
| 11:53.18 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:33.38 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:33.39 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 12:55.18 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-msuotwktsulhxwfd) |
| 13:44.41 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-cfkqwlmxmryarohy) |
| 13:59.26 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:59.26 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:03.02 | Katty | GOOD MORNING CUP--err DEVCAKES. |
| 14:18.53 | oej | :-) |
| 14:18.57 | oej | Good afternoon |
| 14:19.16 | oej | File - i do need to brainstorm with the RTP part of your mind for a bit |
| 14:19.22 | file | do tell |
| 14:19.38 | oej | In the RTP stack, we notice packet loss |
| 14:19.52 | oej | What would happen if we inserted a frame and sent it over the bridge? |
| 14:20.12 | oej | IT would be delayed, but would we cause harm? |
| 14:20.29 | file | it depends... PROBABLY not |
| 14:21.07 | oej | With FEC, that's what you do. Normally with a jitter buffer so there's some forced latency to play with and playout can happen in orderly 20 ms spacing |
| 14:21.17 | oej | But even without jitter buffer it would help stuff like recordings. |
| 14:21.37 | file | yeah, should be fine |
| 14:21.45 | oej | I have recordings that have 45 frames per second instead of 50, so the sound is like a disney cartoon |
| 14:22.40 | oej | Ok, if you have no direct objections I'll look into that part of the code. In many cases, people just insert a copy of the previous frame. |
| 14:24.51 | oej | There's some examples of the various techniques - audio files - here: http://www.voiptroubleshooter.com/problems/plc.html |
| 14:25.30 | file | nods |
| 14:33.59 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:33.59 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:38.19 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:38.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:45.51 | *** join/#asterisk-dev kesselklopfer79_ (~kesselklo@astaro.starface.de) |
| 14:50.04 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:50.04 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:00.55 | kesselklopfer79_ | is it the right way to patch res_agi in function static enum agi_result launch_asyncagi(struct ast_channel *chan, char *argv[], int *efd) in line setup_env(chan, "async", fds[1], 0, 0, NULL); to get the arguments of AGI(agi:async,arg1,arg2.....) ? |
| 15:05.06 | *** join/#asterisk-dev barbosa2 (~juliano.b@177-069-248-123.static.ctbctelecom.com.br) |
| 15:15.03 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:15.03 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:19.00 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:19.00 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:36.00 | kesselklopfer79_ | yes it seems to work :) |
| 15:39.09 | *** join/#asterisk-dev ulogic (421e6b4f@gateway/web/freenode/ip.66.30.107.79) |
| 15:39.30 | pabelanger | kesselklopfer79_, svn diff |
| 15:39.35 | pabelanger | and pastebin it |
| 15:43.12 | ulogic | In a SIP INVITE packet in the To: header there is a line= attribute. Where does that get set? I tried searching the all the source code for "line= |
| 15:43.27 | ulogic | but it doesn't exactly leap out at you |
| 15:45.06 | file | I don't think we set that... |
| 15:45.18 | Qwell | Do you have an example packet? |
| 15:45.33 | pabelanger | 900 active SIP dialogs |
| 15:45.34 | pabelanger | boo |
| 15:45.38 | ulogic | Using SIP realtime, if you change the context of a user, it doesn't take effect unless you do a SIP PRUNE followed by SIP LOAD username REALTIME |
| 15:46.21 | ulogic | After doing that the line= attribute is blank until the client reregisters. |
| 15:48.32 | ulogic | good headers: |
| 15:48.35 | ulogic | INVITE sip:3131@192.168.1.100:2074;line=pb35gymm SIP/2.0 |
| 15:48.59 | Qwell | pastebin the entire packet |
| 15:50.16 | file | probably the contact URI |
| 15:53.00 | ulogic | http://pastebin.com/g10kp0aj |
| 15:53.32 | Qwell | That's to Asterisk... |
| 15:53.49 | file | Qwell, no it isn't :P the INVITE that is |
| 15:54.09 | Qwell | I totally read Norfield as Nortel. |
| 15:56.09 | Katty | i totally read norfield as garfield. |
| 15:56.24 | leifmadsen | I totally read garfield as gladwell |
| 15:57.24 | ulogic | Are you saying that the line= attribute is not coming from asterisk? |
| 15:58.11 | Qwell | ulogic: I was wrong. |
| 16:01.04 | ulogic | In the wireshark capture, the initial invite from extension 2181 does not have the line= attribute. It is only present when the invite is forwarded to extension 3131 |
| 16:01.57 | file | it's the contact as received from the device registering, it's possible either the code that reads/writes it into the database is stripping off part of the value OR that the schema doesn't have that field large enough to store it all |
| 16:02.55 | ulogic | Can you point me to where in sip.c the INVITE packet is assembled? |
| 16:04.00 | file | not off the top of my head... and that would not be the place to start |
| 16:04.05 | file | start by isolating the issue |
| 16:04.27 | file | check the table to make sure it's large enough to store it fully, and check the value in the database to see if the value there is correct |
| 16:07.22 | ulogic | The full contact is varchar(35) but it does contain some trailing garbage |
| 16:08.38 | ulogic | sip:3131@192.168.1.100:2074^3Bline= |
| 16:09.15 | file | so, it's not long enough to store it |
| 16:09.27 | ulogic | I could increase the max column length, but what is that ^3B |
| 16:09.45 | file | 256 is probably safe |
| 16:10.16 | ulogic | I'll give that a shot and see if it cures the problem. |
| 16:15.11 | Qwell | ulogic: ^3B is encoding a semicolon in realtime. |
| 16:15.29 | ulogic | Thanks everybody, the problem was that the column was too short and the full contact was getting truncated |
| 16:17.01 | ulogic | SIP show peer 3131 load now shows: Reg. Contact : sip:3131@192.168.1.100:2074;line=y0q9zhin |
| 16:36.00 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:36.29 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:00.54 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:00.54 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 17:14.29 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:15.42 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 18:03.17 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:03.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:02.54 | opticron | leedm777, I've finally encountered the race condition I've been worrying about for a while regarding stasis_forward_message and dispatching events to a callback after they've received their "final" message |
| 19:03.16 | leedm777 | that's unfortunate. |
| 19:03.18 | opticron | while writing the unit test for device state stuff |
| 19:05.05 | opticron | the hack I have in my code right now uses stasis_subscription_is_subscribed() to check subscription status of the sub just before the actual dispatch, but that makes message forwarding O(n^2) instead of O(n) on the number of subscriptions |
| 19:05.14 | opticron | and is wrong |
| 19:08.18 | leedm777 | thinking |
| 19:11.37 | opticron | we *could* reduce the cost of the sub_is_subscribed check by making it check whether ->topic is NULLed (this means NULLing the topic on unsubscription which we don't currently do) |
| 19:13.04 | leedm777 | possibly. that may mean introducing a lock on the subscription itself, since it's no longer immutable. |
| 19:13.12 | opticron | right :/ |
| 19:13.53 | opticron | alternatively, remove the topic subscription list copying and lock the entire operation |
| 19:14.07 | leedm777 | that was my second thought. |
| 19:14.09 | opticron | for publishing messages |
| 19:15.54 | leedm777 | So I'm guessing that one thread has copied the subscribers list and is in the middle of dispatching; another thread barges in and unsubscribes, which sends out the unsubscribe message. the first thread dispatches its message late, and the world ends. |
| 19:16.27 | opticron | yep |
| 19:16.58 | opticron | accessing freed memory is no fun |
| 19:18.02 | leedm777 | if only that data pointer were an AO2 object... |
| 19:18.38 | file | eh oh 2! |
| 19:19.14 | leedm777 | file: is that how you say it in Canadian? |
| 19:19.50 | file | maybe. |
| 19:20.03 | file | ah oh deux! |
| 19:23.13 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 19:24.06 | leedm777 | opticron: given the options, I'd prefer to null out subscription->topic and add the extra lock. |
| 19:25.09 | opticron | ok, I'll work toward that |
| 19:26.54 | leedm777 | opticron: I wonder if it would be cleaner to null it out in dispatch_exec if stasis_subscription_final_message(). |
| 19:28.11 | leedm777 | declares threads to be hard |
| 19:28.13 | opticron | that's on the other side of the threadpool |
| 19:28.31 | file | do not drown in the pool ;( |
| 19:33.00 | snuff-home | lol |
| 19:44.07 | *** join/#asterisk-dev mvanbaak_ (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 19:44.07 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 20:30.46 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-piosabxpxeyqmhni) |
| 20:47.06 | *** part/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 22:03.55 | *** join/#asterisk-dev mjordan (~mjordan@164.sub-70-197-136.myvzw.com) |
| 22:03.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 22:09.29 | file | Psst putnopvut |
| 22:09.42 | putnopvut | file: sup?! |
| 22:10.17 | file | Can you take a quick gander at outbound registration in relation to your outbound auth code while still fresh on your mind? |
| 22:10.30 | putnopvut | file: Actually, I've had a look already. |
| 22:10.46 | file | Yay |
| 22:10.51 | putnopvut | As long as you don't put anything in the regc's auth_sess field, the callback should be called when a 401/407 is received. |
| 22:11.01 | putnopvut | There, you can do what you need outbound-auth-wise |
| 22:11.12 | file | Thought so |
| 22:38.54 | snuff-work | wedhorn: 2 crashes in 2 hours :( |
| 22:39.07 | snuff-work | one on call pickup.. one on registration/keepalive |
| 22:40.53 | wedhorn | snuff-work: crashes are bad... |
| 22:41.04 | wedhorn | any ideas where? |
| 22:45.28 | snuff-work | http://pastebin.ca/2336146 and http://pastebin.ca/2336147 |
| 22:45.51 | snuff-work | the 2nd of the 2.. was not long after i enabled the skinny debug packet.. |
| 22:45.57 | snuff-work | 1st was trying to pickup a call |
| 22:49.07 | wedhorn | the second one is to do with the code in my new branch |
| 22:49.43 | snuff-work | adding ur v3 of pickupconf |
| 22:50.26 | wedhorn | regarding the first, didn't we see an issue with rtp a couple weeks ago? |
| 22:50.44 | snuff-work | mm.. |
| 22:52.46 | snuff-work | like i said.. trying with ur v3 patch for that.. |
| 22:53.50 | snuff-work | mm.. even with v3 patch applied.. i can still crash the whole thing |
| 22:54.07 | snuff-work | just pickup phone hit the gpickup n boom |
| 22:57.01 | wedhorn | okay, and gpickup from onhook? |
| 22:57.54 | snuff-work | same.. goes boom |
| 22:57.58 | snuff-work | not greys |
| 22:58.24 | wedhorn | and the boom is due to rtp? |
| 22:58.34 | snuff-work | http://pastebin.ca/2336160 |
| 22:58.41 | snuff-work | when onhook.. appears not |
| 22:58.53 | snuff-work | as shown above |
| 22:59.41 | wedhorn | can you print a couple of things from gdb |
| 22:59.49 | wedhorn | sub->callid |
| 22:59.59 | wedhorn | sub->line |
| 23:00.00 | wedhorn | l |
| 23:00.05 | wedhorn | l->device |
| 23:02.26 | snuff-work | on which.. last 1 or rtp ones? |
| 23:04.37 | snuff-work | on the last gdb output... the 'sub->line' = deaddead |
| 23:05.11 | wedhorn | last |
| 23:05.24 | wedhorn | sub has been killed ... |
| 23:06.21 | snuff-work | http://pastebin.ca/2336161 |
| 23:06.29 | snuff-work | full output of all sub values |
| 23:09.27 | wedhorn | okay at line 7332 in your pickup code |
| 23:10.03 | wedhorn | we've got c=sub->owner, pickup(c), hangup(c), set_connected(sub) |
| 23:10.25 | wedhorn | if the pickup fails, we hangup the original sub |
| 23:11.05 | snuff-work | so ur talking |
| 23:11.06 | snuff-work | <PROTECTED> |
| 23:11.06 | snuff-work | <PROTECTED> |
| 23:11.06 | snuff-work | <PROTECTED> |
| 23:11.08 | snuff-work | that part? |
| 23:11.12 | wedhorn | yep |
| 23:12.06 | wedhorn | have a look at the directed pickup of skinny at https://reviewboard.asterisk.org/r/2393/diff/#2 |
| 23:13.53 | wedhorn | line 4865 (new code) |
| 23:14.16 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 23:14.16 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 23:14.41 | snuff-work | k |
| 23:14.54 | wedhorn | further change would be to move the setsubstate connected to the line after ast_hangup(c) (line 4869) |
| 23:17.03 | snuff-work | k.. so what do u want me to do.. take the line 4865 ish code.. adapt slightly.. and put into my code @ 7330ish |
| 23:17.05 | snuff-work | ? |
| 23:18.11 | wedhorn | do the pickup |
| 23:18.53 | wedhorn | if c == sub->owner there wasn't a masquerade, so failed to pickup. Just do a dumpsub |
| 23:19.17 | wedhorn | else hangup c, and setsubstate connected |
| 23:19.36 | wedhorn | then unref c |
| 23:20.13 | snuff-work | so set substate is in or out of if.. ? |
| 23:20.25 | snuff-work | else |
| 23:20.50 | snuff-work | i'll leave it out like ur other code.. |
| 23:20.58 | snuff-work | give 2 secs will see if it blows up |
| 23:22.44 | snuff-work | ok.. i can now hit gpickup.. without it dying horribly.. but |
| 23:23.01 | snuff-work | hit it once.. comes back.. |
| 23:23.15 | snuff-work | try gpickup again.. gets a zombie chan.. |
| 23:25.08 | *** join/#asterisk-dev mjordan (~mjordan@173.227.23.10) |
| 23:25.09 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 23:25.23 | snuff-work | so after the 2 group pickup attempts.. i have zombies |
| 23:25.28 | snuff-work | both are listed as up chans |
| 23:26.55 | snuff-work | both never go away |
| 23:27.37 | wedhorn | snuff-home: the setsubstate should be in the else |
| 23:27.40 | snuff-work | * will segfault of course if i try to unload skinny module @ that ponit |
| 23:29.20 | snuff-work | even after 1 attempt at pickup.. |
| 23:29.24 | snuff-work | i've created a zombie |
| 23:29.43 | snuff-work | i have put the setsub into else |
| 23:30.57 | wedhorn | okay, try this |
| 23:30.58 | wedhorn | ast_pickup_call(c); |
| 23:30.59 | wedhorn | ast_hangup(c); |
| 23:30.59 | wedhorn | if (c != sub->owner) { |
| 23:30.59 | wedhorn | setsubstate(sub, SUBSTATE_CONNECTED); |
| 23:30.59 | wedhorn | } |
| 23:33.06 | wedhorn | if it works, I don't know why dumpsub is hanging up the channel |
| 23:33.16 | wedhorn | isn't... |
| 23:33.37 | snuff-work | ok.. if i put it outside.. boom |
| 23:33.46 | snuff-work | the hangup = segfault |
| 23:35.04 | wedhorn | which version of outside? |
| 23:35.21 | snuff-work | ur last incarnation |
| 23:35.37 | snuff-work | if it is within the else.. ast at least lives.. |
| 23:35.54 | snuff-work | otherwise.. u get ur dead line |
| 23:36.02 | snuff-work | like my earlier bt |
| 23:36.39 | wedhorn | the last incarnation doesn't have an else .... |
| 23:37.18 | snuff-work | re-read.. |
| 23:37.45 | snuff-work | the one that saved * from blowing up entirely was having th hangup within else |
| 23:38.05 | wedhorn | okay, and this one? |
| 23:38.08 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:38.08 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:38.12 | snuff-work | if it is not within the else.. like the last u posted.. i get the same segfault as orignally |
| 23:38.25 | wedhorn | ast_pickup_call(c); |
| 23:38.27 | wedhorn | ast_hangup(c); |
| 23:38.27 | wedhorn | if (c != sub->owner) { |
| 23:38.27 | wedhorn | setsubstate(sub, SUBSTATE_CONNECTED); |
| 23:38.27 | wedhorn | } |
| 23:38.27 | wedhorn | ast_channel_unref(c); |
| 23:38.30 | snuff-work | aka.. no zombie channel.. but no ast etiher |
| 23:39.14 | snuff-work | that u just posted = segfault |
| 23:39.25 | snuff-work | like the code before other changes |
| 23:41.50 | wedhorn | ast_pickup_call(c); |
| 23:41.51 | wedhorn | ast_hangup(c); |
| 23:41.51 | wedhorn | if (sub->owner && c != sub->owner) { |
| 23:41.51 | wedhorn | setsubstate(sub, SUBSTATE_CONNECTED); |
| 23:41.51 | wedhorn | } |
| 23:41.52 | wedhorn | ast_channel_unref(c); |
| 23:42.12 | wedhorn | ^^^ ??? |
| 23:43.06 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 23:43.06 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 23:44.21 | wedhorn | actually, that's probably not good either |
| 23:44.30 | wedhorn | we need to test before hangup |
| 23:44.32 | snuff-work | i swear.. its all to do with hangup |
| 23:45.06 | snuff-work | like i said.. if we have the hangup inside the else.. it doesn't take * down.. but does leave orphan up channel |
| 23:45.13 | snuff-work | in *.. not on phone |
| 23:45.23 | wedhorn | ast_pickup_call(c); |
| 23:45.24 | wedhorn | if (c != sub->owner) { |
| 23:45.24 | wedhorn | ast_hangup(c); |
| 23:45.24 | wedhorn | setsubstate(sub, SUBSTATE_CONNECTED); |
| 23:45.24 | wedhorn | } else { |
| 23:45.24 | wedhorn | ast_hangup(c); |
| 23:45.25 | wedhorn | } |
| 23:45.27 | wedhorn | ast_channel_unref(c); |
| 23:45.38 | wedhorn | at least the test shouldn't blow up * |
| 23:46.00 | snuff-work | we'll see.. i reckon it still will.. |
| 23:48.35 | snuff-work | ok seems to stay alive atm.. |
| 23:52.38 | snuff-work | mm.. didn't seem to die that time.. yey |