| 01:36.34 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-ojpjeukiodrtkxud) |
| 03:00.59 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 05:03.16 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:32.22 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-adyudnjxlkfhesdv) |
| 06:44.08 | *** join/#asterisk-dev jkroon (~jkroon@dustpuppy.is.co.za) |
| 07:00.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:14.47 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:17.52 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:17.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:35.12 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:10.38 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 08:34.18 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 08:45.39 | *** join/#asterisk-dev oej (~oej@host-95-195-214-151.mobileonline.telia.com) |
| 08:45.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:13.36 | *** join/#asterisk-dev oej (~oej@host-95-195-214-151.mobileonline.telia.com) |
| 09:13.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:53.41 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-jklujasjqtneztlk) |
| 13:32.15 | *** join/#asterisk-dev libardi (~kvirc@189.61.225.190) |
| 13:44.15 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-mqtuotgnidxtxlbn) |
| 13:44.15 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:07.37 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-vztpaqqugnpfjeml) |
| 14:17.04 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ykmlklcvitaxukvz) |
| 14:23.39 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:23.55 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:26.07 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:26.07 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:27.22 | cresl1n | waves |
| 14:31.13 | file | wobbles |
| 14:54.27 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-esnyufcpgjyabxky) |
| 16:36.04 | *** join/#asterisk-dev babak_ (uid19622@gateway/web/irccloud.com/x-dwtnwjhwpcudukgw) |
| 16:45.16 | file | I'm submitting these things myself, having gates run is silly |
| 16:50.57 | file | well, that's a bit more manageable |
| 17:21.25 | tm1000 | Is the INT_MAX for parking hard coded somewhere or is it system dependent (32bit v 64bit) |
| 17:21.44 | tm1000 | We have issues with people using their DIDs as lots and slots causing all sorts of issues |
| 17:21.58 | tm1000 | ex: 19512594700 through 19512594709 |
| 17:29.51 | file | system dependent |
| 17:31.50 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d000033e834690778d2.ipv6.abo.wanadoo.fr) |
| 17:53.57 | rmudgett | Using a normalized phone number as a parking slot is not going to work because phone numbers do not fit into an int. |
| 17:56.21 | rmudgett | AMI originate has unintended requirements because of how it handles context/exten/priority header values. It requires them to be present and not empty. Which is wrong when you want to use the application/data headers. |
| 18:22.44 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 18:22.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:45.11 | file | rmudgett, are you going to do anything with your global config options caching? |
| 18:46.30 | gtjoseph | rmudgett, also if alice doesn't call bob, there's only a local bridge, not a real bridge so BridgeAdd doesn't find it. |
| 18:55.30 | tm1000 | rmudgett: file Thanks for the explanation on long numbers. Some users just refuse to listen |
| 18:56.33 | tm1000 | file: rmudgett is the int used signed or unsigned |
| 18:56.40 | tm1000 | I should just go look at the code. |
| 18:56.47 | tm1000 | looks to be signed |
| 18:57.01 | rmudgett | It doesn't matter since a phone number is much larger than an unsigned int. |
| 18:58.11 | tm1000 | yeah. whoops |
| 18:58.32 | rmudgett | file: I'm not doing anything with that patch at this time. I will get it updated. That patch actually didn't improve performance as much as I thought. |
| 18:58.38 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-218-79.w92-135.abo.wanadoo.fr) |
| 18:59.10 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 19:00.06 | rmudgett | gtjoseph: I don't understand your comment. Yes alice needs to call bob to get a bridge. That test is just doing it twice. Once for the alice;2 side and once for the alice;1 side. |
| 19:00.37 | gtjoseph | then i didn't understand your comment either. is there an alternative? |
| 19:01.16 | rmudgett | Have the originate answer go somewhere else in dialplan. Such as sending alice;1 to a wait exten. |
| 19:02.28 | gtjoseph | not sure I follow but i'll dig a little |
| 19:03.02 | rmudgett | Originate Local/bob@default answer target waitforit@default:1 |
| 19:03.30 | rmudgett | Instead of sending alice;1 to bob@default:1 |
| 19:03.49 | rmudgett | when bob@default:1 answers for the alice;2 side |
| 19:04.40 | rmudgett | The Channel header Local/bob@default is where alice;2 executes dialplan |
| 19:05.03 | rmudgett | The Context/Exten/Priority headers specify where alice;1 will go into dialplan |
| 19:05.33 | rmudgett | If you also specify bob@default:1 again... |
| 19:07.12 | gtjoseph | i think it would be easier to just rip out all the Local channel code and start over. :) |
| 19:08.06 | gtjoseph | anyway i have no idea what you are talking about but i'll give it a shot. :) |
| 19:08.57 | rmudgett | AMI originate: Channel: Local/bob@default CEP=bob@default:1 |
| 19:09.36 | rmudgett | The channel creates Local/alice-0000000;1 and Local/alice-00000000;2 |
| 19:10.02 | gtjoseph | why would an originate on bob create alice channels? |
| 19:10.31 | gtjoseph | are you saying that bob's dial plan Dials alice? |
| 19:10.48 | rmudgett | Originate then ast_calls(alice;1) which cause alice;2 to execute dialplan at bob@default:1 |
| 19:11.22 | rmudgett | Sorry: As in your test. I meant Channel: Local/alice@default |
| 19:11.35 | gtjoseph | Ah, ok |
| 19:11.59 | gtjoseph | let's see if that creates a bridge... |
| 19:12.25 | rmudgett | The dialplan at alice@default dials(Local/bob@default) |
| 19:12.45 | gtjoseph | i'm removing that though correct? |
| 19:13.02 | gtjoseph | it'll never get executed |
| 19:13.06 | rmudgett | The dial creates Local/bob@default-00000001;1 and Local/bob@default-00000001;2 |
| 19:13.42 | gtjoseph | i'm removing that correct?? |
| 19:14.14 | rmudgett | Just change the CEP in the originate to something else such as waitforit@default:1 |
| 19:14.36 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-ecbexbiozonamnxj) |
| 19:14.43 | rmudgett | That will eliminate the extra bob channels in the chain I showed in the review. |
| 19:14.49 | gtjoseph | what? which originate? |
| 19:15.06 | rmudgett | The first originate for alice@default |
| 19:15.10 | gtjoseph | you just had me change the first one to bob |
| 19:15.31 | gtjoseph | scroll up. :) |
| 19:15.53 | rmudgett | I have been trying to go through the steps the code is going through and getting alice and bob mixed up. :) |
| 19:16.14 | gtjoseph | imagine what you're doing to me then :) |
| 19:16.53 | rmudgett | The channel chain in the review is what will result when the call is setup. |
| 19:17.16 | gtjoseph | in the original scenario |
| 19:17.19 | gtjoseph | yes? |
| 19:17.42 | rmudgett | The 00000000 local channel sequence numbers is the order the local channel pairs are created and connected in that chain. |
| 19:17.50 | rmudgett | Yes the original alice originate |
| 19:18.02 | gtjoseph | yep i know about the sequence numbers |
| 19:19.07 | gtjoseph | i think what you said about originating alice's channel to bob's CEP works |
| 19:20.52 | gtjoseph | so now these are the channels... |
| 19:20.54 | gtjoseph | Channel: Local/alice@default-00000000;1 |
| 19:20.54 | gtjoseph | Channel: Local/alice@default-00000000;2 |
| 19:20.54 | gtjoseph | Channel: Local/bob@default-00000001;1 |
| 19:20.54 | gtjoseph | Channel: Local/bob@default-00000001;2 |
| 19:20.54 | gtjoseph | Channel: Local/bridgeadd@default-00000003;1 |
| 19:20.55 | gtjoseph | Channel: Local/bridgeadd@default-00000003;2 |
| 19:20.57 | gtjoseph | Channel: Local/charlie@default-00000002;1 |
| 19:20.59 | gtjoseph | Channel: Local/charlie@default-00000002;2 |
| 19:21.11 | gtjoseph | look better? |
| 19:23.09 | gtjoseph | I think I can also originate charlie's cahannel directly to beidgeadd's CEP |
| 19:25.19 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 19:25.19 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:25.48 | gtjoseph | ah, no i can't |
| 19:32.02 | rmudgett | I responded to your updated review. Just a minor tweak would do it. |
| 19:42.52 | gtjoseph | rmudgett: did you mean to wait for both of bob's channels instead of alices because only 1 of alice's cahnnels ever joins a bridge |
| 19:44.23 | rmudgett | According to the code up on review there are two alice channels and both will join a bridge. There are two bridges that will get created. |
| 19:44.25 | gtjoseph | in fact, bob only has 1 channel joining the bridge as well |
| 19:44.46 | gtjoseph | yes but i'm changing it as we discussed above |
| 20:05.01 | rmudgett | gtjoseph: How many bridges were you wanting in the test? |
| 20:05.25 | rmudgett | The test still has some race conditions in it. |
| 20:05.39 | gtjoseph | well, i only really need 1 but the second one is transient |
| 20:05.46 | gtjoseph | where's the race? |
| 20:06.20 | rmudgett | Answer has a built in delay of 500 ms. |
| 20:06.43 | gtjoseph | i can force it to 0 |
| 20:06.57 | gtjoseph | i have to look again |
| 20:07.02 | rmudgett | The race comes when charlie;2 answers and plays hello. In the mean time charlie;1 is joining the bridge via bridgeadd |
| 20:07.31 | rmudgett | The hello could conceivably be cut off |
| 20:08.31 | rmudgett | What you would want to do is have charlie;2 join the bridge via bridgeadd and then have charlie;1 play hello |
| 20:08.41 | gtjoseph | so if I force Answer(0) on both bob and charlie, that should do it. |
| 20:10.19 | gtjoseph | rmudgett: yes? |
| 20:10.44 | rmudgett | no? |
| 20:11.21 | gtjoseph | what do you mean no? |
| 20:11.33 | gtjoseph | forcing Answer(0) won't fix it? |
| 20:12.20 | rmudgett | You need to swap the behaviors of charlie channels |
| 20:12.35 | rmudgett | Though answer(0) for bob would be good |
| 20:13.50 | gtjoseph | as in... |
| 20:13.51 | gtjoseph | <PROTECTED> |
| 20:13.51 | gtjoseph | <PROTECTED> |
| 20:13.51 | gtjoseph | <PROTECTED> |
| 20:13.51 | gtjoseph | <PROTECTED> |
| 20:13.51 | gtjoseph | <PROTECTED> |
| 20:13.53 | gtjoseph | <PROTECTED> |
| 20:13.55 | gtjoseph | <PROTECTED> |
| 20:13.57 | gtjoseph | <PROTECTED> |
| 20:13.59 | gtjoseph | <PROTECTED> |
| 20:14.01 | gtjoseph | <PROTECTED> |
| 20:16.07 | rmudgett | no. It would be good to get rid of the application part and just do it in dialplan |
| 20:16.57 | gtjoseph | that just makes the dialpln more complex |
| 20:17.24 | rmudgett | Just looked in the code and you cannot have an answer delay less than 500ms |
| 20:17.34 | gtjoseph | figures |
| 20:22.39 | gtjoseph | so i'm confused about your earlier statement then. the answer was in the path of the playback so the playback should have been delayed by 500ms and not cutr off |
| 20:23.23 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-cnivlrnjaagaxcfy) |
| 20:23.45 | gtjoseph | rmudgett: ^^ |
| 20:25.00 | rmudgett | I'm working on an updated patch. |
| 20:27.09 | gtjoseph | i should just have used a few sipp scenarios instead of local frickin channels. |
| 20:31.36 | rmudgett | No need for sipp when local will do. :D |
| 20:31.53 | gtjoseph | i can't wait to see your patch |
| 20:32.01 | gtjoseph | :) |
| 20:48.37 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 20:48.37 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:51.48 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-cxuhlrwstjgfrxrd) |
| 21:15.03 | gtjoseph | rmudgett: did you come up with something? |
| 21:15.20 | rmudgett | Just posting |
| 21:15.56 | rmudgett | posted |
| 21:17.03 | gtjoseph | BridgeAdd with a full channel name defeats part of the test but ok. |
| 21:18.54 | rmudgett | That particular functionality is a call into a well tested routine anyway. |
| 21:19.27 | gtjoseph | ok, so what does this do... |
| 21:19.28 | gtjoseph | exten = alice,1,NoOp() |
| 21:19.28 | gtjoseph | <PROTECTED> |
| 21:19.29 | gtjoseph | <PROTECTED> |
| 21:20.06 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 21:20.06 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 21:21.17 | file | it's that cresl1n guy |
| 21:21.27 | gtjoseph | i'm having a hard time seeing how your version is any better than the last version I posted. |
| 21:21.33 | cresl1n | hidey ho! |
| 21:21.47 | cresl1n | what's for dinner file? |
| 21:21.54 | file | cresl1n, pizza |
| 21:22.22 | cresl1n | You have chosenâ¦. |
| 21:22.24 | cresl1n | wisely. |
| 21:22.32 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-mfpkmcsjawkrtxfn) |
| 21:22.34 | file | cresl1n, no 50 cent frosty |
| 21:22.52 | cresl1n | that's good too |
| 21:23.43 | rmudgett | gtjoseph: My version swaps the role of charlie;1 and charlie;2. |
| 21:24.03 | rmudgett | It also eliminates entirely the bridgeadd@default call. |
| 21:31.50 | rmudgett | The reason I swapped charlie ;1 and ;2 is to get the ;2 into the bridge before ;1 starts sending audio. |
| 21:43.21 | rmudgett | The test doesn't really need to check the audio paths. It just needs to look for the AMI BridgeEnter events for the three channels. |
| 21:44.14 | gtjoseph | was on the phone, sorry. whatever it takes to get the review committed is fine with me. :) |
| 21:44.40 | gtjoseph | so now you can +1 it yourself :) |
| 22:14.10 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-fidcqwveaonffmpt) |
| 22:14.10 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 23:19.55 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 23:33.15 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-mfpkmcsjawkrtxfn) |