| 05:31.44 | *** join/#asterisk-doc RobH (n=RobH@cpe-72-184-129-136.tampabay.res.rr.com) |
| 09:16.46 | *** join/#asterisk-doc codefreeze-lap (n=murf@216.166.159.235) |
| 15:19.38 | *** join/#asterisk-doc snuff-home (i=snuff@C-59-101-239-68.bur.connect.net.au) |
| 15:47.14 | *** join/#asterisk-doc Alric (n=nbowyer@masq.hyperusa.com) |
| 15:59.42 | ctooley | is very happy with performance of the routing engine now... 800K calls in 2.5 hours so far and 70 failed route attempts. Without tuning the database and without 2 bug fixes that we think will drop that number to near zero |
| 16:18.45 | Alric | Hello! |
| 16:25.50 | jsmith-teaching | Well if it isn't Alric! |
| 16:25.53 | jsmith-teaching | Alric: How goes? |
| 16:32.12 | *** join/#asterisk-doc ctooley (n=ctooley@209.33.110.169) |
| 16:36.06 | Alric | Pretty good |
| 16:36.49 | Alric | Off to lunch! |
| 17:43.12 | ctooley | well, we've pushed past the 100cps limit. We're holding steady with 200K calls processed at 110cps and zero failures. |
| 17:43.51 | ctooley | I think we'll be able to find the real limit of asterisk's SIP implementation in terms of pure SIP messages per second. |
| 17:44.09 | ctooley | We'll see how this test runs out to 10M calls. |
| 17:53.09 | lmadsen | ctooley: wow... what'd you change? |
| 17:53.31 | lmadsen | I have a scenario that I'm trying to figure out how to pass a variable though in... |
| 17:54.19 | ctooley | lmadsen, give us the details |
| 17:54.47 | ctooley | lmadsen, We've improved some things on the Griffin side of the fence that has helped a lot. |
| 17:55.27 | ctooley | Basically we really hadn't/haven't reached Asterisk's limits, we just ran out of the ability to test it. |
| 17:56.12 | lmadsen | 101 --> 100 |
| 17:56.12 | lmadsen | answer |
| 17:56.12 | lmadsen | 101 hits * for blind transfer (asterisk transfer) |
| 17:56.12 | lmadsen | 101 dials 901 |
| 17:56.12 | lmadsen | a GOTO_ON_BLINDXFR is set which after the blind transfer is completed tells 101 to go to the same destination as 100 (conference 100) |
| 17:56.14 | lmadsen | however... the problem is that I can't seem to figure out how to capture the digits that were dialed for the blind transfer (901) and have that in a variable at the GOTO_ON_BLINDXFR destination |
| 17:56.48 | lmadsen | here is the dialplan |
| 17:56.49 | lmadsen | http://pastebin.ca/1012928 |
| 17:57.06 | lmadsen | I wonder if there is a variable that keeps the extension that was dialed... |
| 17:57.24 | ctooley | lmadsen, let me see if I understand this correctly, 901 is another extension or a meetme? |
| 17:57.27 | lmadsen | basically I need to know what extension 100 was transferred to in the GOTO_ON_BLINDXFR dest |
| 17:57.38 | lmadsen | 901 is a meetme |
| 17:57.47 | lmadsen | it'll make a bit more sense if you see the dialplan |
| 17:57.48 | lmadsen | I think |
| 17:57.49 | lmadsen | :) |
| 17:58.01 | ctooley | and you want to automatically have 100 connected to 901 as well? |
| 17:58.21 | lmadsen | 100 is transferred to 901 -- that works |
| 17:58.45 | ctooley | err you want 101 transferred to 901 too? |
| 17:58.53 | lmadsen | but after the transfer, 101 (who called 100) goes to the same destination of csr,7,1 but gets there via the GOTO_ON_BLINDXFR |
| 17:59.01 | lmadsen | yes, that is the ultimate goal |
| 17:59.04 | lmadsen | it GETS there |
| 17:59.11 | lmadsen | but it doesn't know what extension number was dialed |
| 17:59.16 | lmadsen | thus CONFNO is blank |
| 18:00.45 | lmadsen | the key is really to know what extension number 101 was transferred to |
| 18:01.01 | lmadsen | once 100 is put into csr,7,1 |
| 18:01.05 | lmadsen | after the transfer completes |
| 18:01.28 | ctooley | how does it ever get to csr,7,1 in the first place? |
| 18:01.36 | lmadsen | GOTO_ON_BLINDXFR |
| 18:01.57 | lmadsen | that says, "after 101 has performed the transfer, goto this location" |
| 18:02.02 | lmadsen | which it does |
| 18:02.14 | lmadsen | but I don't know where 101 transferred 100 to |
| 18:02.18 | ctooley | aha, magic variable. |
| 18:02.24 | lmadsen | aye |
| 18:02.36 | lmadsen | so I was hoping for another magic variable that I could parse on... |
| 18:02.49 | lmadsen | or some other method of capturing the extension number 100 was transferred to |
| 18:03.29 | ctooley | gimme a few minutes to mock it up and see if I can figure it out... they'll always be SIP or you need true dialplan variables? |
| 18:03.48 | ctooley | (SIP Header variables are handy) |
| 18:05.11 | lmadsen | hrmmm... not positive... I guess it has to be cross-tech compatible, but more than likely SIP.... |
| 18:06.55 | lmadsen | seems like this should be in a variable that is somehow associated with GOTO_ON_BLINDXFR... like a BLINDXFR_DEST or something |
| 18:07.18 | lmadsen | hehe... I always want the ideal though |
| 18:14.54 | ctooley | can you register a softphone to my server so I can test it? |
| 18:15.05 | ctooley | I have an idea, but I need to test something. |
| 18:24.03 | ctooley | :) might take longer to mock up than fix. |
| 18:24.44 | lmadsen | hahaha no kidding |
| 18:25.06 | ctooley | but, this server needed upgraded to 1.4.19.1 anyway. |
| 18:25.14 | ctooley | Connected to Asterisk SVN-branch-1.4-r46142M currently running on phone2 (pid = 6584) |
| 18:25.30 | ctooley | it's a little behind.... since VON in Boston a year and half ago or so. |
| 18:25.33 | lmadsen | ya... I'm running 1.4. vanilla branch |
| 18:25.40 | lmadsen | so should be the same thing |
| 18:25.49 | ctooley | yeah, 1.4.19.1 is building. |
| 18:26.14 | lmadsen | did you make a coding change? |
| 18:26.30 | lmadsen | I have this mocked up here... so if it's just dialplan, I could cp/pst to test |
| 18:26.57 | ctooley | I havent' yet, I need to see what everything is showing up as first. |
| 18:27.27 | lmadsen | gotcha |
| 18:28.23 | ctooley | DOH! noticed a different issue. |
| 18:28.53 | lmadsen | oh? |
| 18:30.40 | jsmith-teaching | ctooley: Great news on the scalability front... Glad to hear those testing boxes are getting used ;-) |
| 18:30.52 | ctooley | :) |
| 18:33.45 | lmadsen | ctooley: weird... just said it wasn't a valid conf |
| 18:34.30 | ctooley | yeah, forgot to create a conference number. :) |
| 18:34.41 | lmadsen | weird... should just be dynamic... |
| 18:34.49 | lmadsen | shouldn't need to pre-create them |
| 18:34.58 | lmadsen | the 'd' flag is set... |
| 18:35.12 | ctooley | hmmm dunno |
| 18:36.24 | ctooley | But, I don't think that CONFNO is going to get set for you, on the transferring leg because the only one going to the conference is the transferred leg. |
| 18:37.07 | lmadsen | ya... there is the transferred leg, and then the transferrer leg... the problem is not knowing what the transferrer dialed... but I don't think you can do this with stock asterisk |
| 18:37.12 | lmadsen | at least I don't see a way |
| 18:37.41 | lmadsen | although adding the functionality probably wouldn't be too hard for someone who can program |
| 18:38.40 | ctooley | I think you could probably do it with an "applicationmap" |
| 18:39.43 | lmadsen | hrmmm... wonder how you might do that... |
| 18:40.05 | ctooley | can you call a Macro from there instead of an application? |
| 18:40.47 | ctooley | Note: You can use the Goto() application to jump anywhere into the extensions conf, or Macro if you would like to be returned to the other party after macro execution, or use Transfer() for e.g. a pre-defined transfer target could be hard-coded into features.conf |
| 18:40.54 | jsmith-teaching | ctooley: I don't see why not... |
| 18:41.19 | lmadsen | hrmmmm |
| 18:54.46 | lmadsen | ya... you can only apply the applicationmap to one side of the call unfortuantely... |
| 18:54.51 | lmadsen | so I'm not sure how to actually transfer the other side |
| 18:55.02 | lmadsen | I'm just gonna tell this guy its not possible |
| 18:59.32 | Alric | Yo |
| 18:59.43 | Alric | Hate that this window doesn't light up when something happens. |
| 19:14.19 | jsmith-teaching | Alric: I hate it when you don't respond ;-) |
| 19:22.51 | lmadsen | me too |
| 19:23.00 | Juggie | i hate it when all people do that |
| 19:23.11 | Juggie | i also hate people who i know have cell phones but never have them on, or never bring them with them |
| 19:45.32 | Alric | I have my cell phone on me 90% of the time. |
| 19:45.52 | Alric | The problem is everyone seems to call in the 10% its on my nightstand. |
| 19:46.02 | Alric | And thus "I never have my cell with me" |
| 19:46.26 | ctooley | Alric, would you like a second cell phone to cover that 10% of the time? I have to carry 2 of them and I'd gladly give one up. |
| 19:47.31 | Alric | no |
| 19:47.46 | Alric | Thank you for the generous offer, but being unreachable is nice sometimes |
| 19:47.56 | Alric | About 10% of the time, actually ;) |
| 19:48.44 | ctooley | I am lucky in that I live in the middle of nowhere so when I don't feel like answering the phone I "don't have service here". |
| 19:50.06 | ctooley | Which is actually why they got me the backup cell phone on a different provider. But, they made the mistake of getting me a Sprint phone when mine is Verizon. Since they're both PCS they get service in the same areas. If they'd have been thinking they'd have gotten a GSM phone, that would have ensured I'd have not had coverage on that phone anywhere. |
| 20:14.41 | Alric | I just have Verizon |
| 20:37.12 | Alric | Welcome back from the classroom |
| 20:40.10 | lmadsen | is going to be a condo owner very soon |
| 20:40.37 | lmadsen | a place that I put an offer in at the beginning of the week but was rejected, just called back and re-offered |
| 20:40.51 | file | lmadsen: lame :( |
| 20:41.00 | lmadsen | seems anti-lame |
| 20:41.21 | lmadsen | overlooking the skydome... I will be even closer to IT360 next year, heh |
| 21:08.39 | lmadsen | http://tinyurl.com/69nc3j |
| 22:37.18 | ctooley | file, ping |
| 22:37.54 | file | pong |
| 22:38.00 | ctooley | [May 9 22:32:06] WARNING[2326]: rtp.c:1140 ast_rtp_read: RTP Read error: Bad file descriptor. Hanging up. |
| 22:38.09 | ctooley | Getting that on our "route" channels occasionally |
| 22:38.33 | ctooley | the channels shouldn't have any RTP, they're never answered and it's SIPP sending the calls so I know it's not setting up any RTP |
| 22:39.01 | file | still gets setup with the dialog |
| 22:40.34 | ctooley | It doesn't seem to be having any adverse effects on the actual route requests or responses so I don't think it's a big deal, but don't really like seeing errors. |
| 22:43.31 | ctooley | [May 9 22:35:32] WARNING[15914]: app_deadexternalivr.c:424 eivr_comm: SIP/51344-c4281dd0: Child process went away |
| 22:43.35 | ctooley | Those are the ones that suck |
| 22:47.44 | ctooley | We're still trying to figure out why the asterisk side of the TCP connection isn't buffering the data on the socket even though the router side of the connection has torn down the connection. That data should be buffered and asterisk should be able to read it. |