| 00:11.18 | *** join/#asterisk war9407 (war@pool-173-72-178-211.clppva.fios.verizon.net) |
| 00:21.09 | *** join/#asterisk infobot (ibot@208.53.50.136) |
| 00:21.09 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.23.1 (2018/09/20) 16.0.0-rc3 (2018/09/20), Standard: 15.6.1 (2018/09/20); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
| 00:38.31 | *** join/#asterisk r0ckp3arl_ (~admin@203.149.66.146) |
| 02:35.55 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 02:46.48 | *** join/#asterisk duo_ubuntu (b61ecc7e@gateway/web/freenode/ip.182.30.204.126) |
| 04:30.54 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
| 04:55.23 | *** join/#asterisk luckman212_ (luckman212@unaffiliated/luckman212) |
| 05:01.27 | *** join/#asterisk luckman212_ (luckman212@unaffiliated/luckman212) |
| 05:08.06 | *** join/#asterisk duo_ubuntu (b61ecdf2@gateway/web/freenode/ip.182.30.205.242) |
| 05:36.34 | *** join/#asterisk jkroon (~jkroon@165.16.204.162) |
| 05:40.53 | *** join/#asterisk luckman212 (luckman212@unaffiliated/luckman212) |
| 05:45.51 | *** join/#asterisk sibyakin (~sibyakin@188.162.228.107) |
| 05:49.04 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:54.51 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 06:32.34 | *** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net) |
| 06:50.39 | *** join/#asterisk war9407 (war@pool-70-106-229-104.clppva.fios.verizon.net) |
| 07:25.15 | *** join/#asterisk jkroon (~jkroon@165.16.203.126) |
| 07:32.00 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 07:50.11 | *** join/#asterisk mou (~donwillia@37.97.50.103) |
| 08:05.47 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 08:20.10 | *** join/#asterisk DanB (~DanB@clt-195.192.206.178.ip-anschluss.net) |
| 08:58.42 | *** join/#asterisk miralin (~Thunderbi@194.8.128.67) |
| 09:55.52 | *** join/#asterisk Mr_Pleb_Mgoo (~jakeb@103.46.212.49) |
| 10:21.55 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
| 10:48.28 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 12:10.02 | *** join/#asterisk sahmed (~sahmed@37.19.10.33) |
| 12:11.14 | sahmed | anyone experience "503 Service Unavailable" during browse http://doxygen.asterisk.org/ |
| 12:12.44 | file | it's been brought up on the dev list awhile ago, http://lists.digium.com/pipermail/asterisk-dev/2018-September/076983.html |
| 12:13.42 | sahmed | could not understand if I search anything on google just point out those links |
| 12:15.04 | sahmed | ok understood the issue, thanks @file |
| 12:43.13 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 13:08.34 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:16.12 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 13:22.17 | *** join/#asterisk scroll2 (sid313090@gateway/web/irccloud.com/x-eriuyigddvipdmjj) |
| 13:49.29 | *** join/#asterisk AsteriskRoss (259d3426@gateway/web/freenode/ip.37.157.52.38) |
| 14:00.26 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 14:00.33 | *** join/#asterisk kharwell (kharwell@nat/digium/x-zwvnkbexigppsldr) |
| 14:00.33 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:20.52 | *** join/#asterisk n8n8 (~n8@208.69.84.142) |
| 14:26.03 | n8n8 | Hi all. I'm in a bit of a bind, my customers cannot make outbound calls this morning. I have a complicated setup. I believe the issue is related to my realtime config. The delta in my environment is that for about 2 hours last night asterisk would have been connected to my read-only replica database, which is where realtime would access the pjsip configs, as well as update them. After I restored the switch, I've restarted asterisk, and it is now talking to the |
| 14:26.03 | n8n8 | primary RW db server for realtime. Inbound calls all seem to be working, but when an endpoint tries to dial out, it is always being told it is unauthorized. What I need the most help with is how to troubleshoot why asterisk/pjsip is determining the endpoint is unauthorized. The endpoints are able to register, and receive calls, just not send... |
| 14:27.36 | *** join/#asterisk Da-Geek (~Da-Geek@81.145.134.175) |
| 14:28.29 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-gscgjgtkwjllzbhq) |
| 14:28.30 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:45.42 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-ltnhavzqmfevviwa) |
| 14:45.42 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 15:05.53 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
| 15:09.10 | igcewieling | I can set the values of multiple dialplan variables at the same time using ARRAY when using AGI. Can I GET values of multiple variables at the same time? |
| 15:12.03 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:12.03 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 15:17.18 | Samot | With AGI? |
| 15:17.42 | Samot | I mean you could break out into an AGI script to write code that would set all them via a loop... |
| 15:17.59 | Samot | But I don't think Asterisk has the concept of arrays in that regard. |
| 15:18.17 | *** join/#asterisk Han (~han@unaffiliated/han) |
| 15:26.04 | sibiria | igcewieling: if you're already in an AGI application you most certainly have handier options for pulling variables |
| 15:26.42 | sibiria | i'm trying to figure out what you actually want to do |
| 15:26.51 | sibiria | you want to read multiple variables, so why not just read them? |
| 15:30.27 | n8n8 | anyone have any thoughts as to why an endpoint would be able to register with pjsip, and be able to receive calls, but not be able to make them? When they try to call they are getting an unauthorized response... |
| 15:30.56 | Samot | n8n8: Show a failed called with the log and pjsip logger enabled. |
| 15:31.51 | igcewieling | sibiria: nothing all that important. Having a zillion GETs and SETs can cause excessive AGI debug output. I've reduced the issue by using ARRAY with SET when setting variables. I was wondering if I could do the same for GETing variable. |
| 15:32.21 | *** join/#asterisk stefanauss (~stefanaus@host222-246-static.59-217-b.business.telecomitalia.it) |
| 15:32.29 | sibiria | igcewieling: ah, no, you can't in any other way than concatenating the channel variables yourself and then parsing them afterwards |
| 15:33.16 | sibiria | as Samot pointed out, the asterisk dial plan "language" doesn't really have a concept of arrays in that sense |
| 15:33.38 | igcewieling | My SETs look like SET VARIABLE ARRAY(MASTER_CHANNEL(sm_call[1][start_timestamp]),MASTER_CHANNEL(sm_call[1][call_direction]),MASTER_CHANNEL(sm_call[1][btn]),MASTER_CHANNEL(sm_call[1].... |
| 15:33.38 | sibiria | the ARRAY function really only translates to MSet() effectively. same thing |
| 15:33.54 | igcewieling | I create my own arrays. |
| 15:34.06 | igcewieling | that wasn't my question |
| 15:34.15 | Samot | No. |
| 15:34.24 | Samot | There is nothing to do the opposite of what ARRAY does. |
| 15:34.39 | igcewieling | *nod* I accept that. |
| 15:34.41 | sibiria | only thing you can do is to build your own CSV string and then deparse it |
| 15:34.50 | sibiria | that will be one "function call" |
| 15:36.33 | Samot | Well..... |
| 15:37.05 | Samot | If in the first part you SET six different VARS with ARRAY and in the second part you want to GET those VARs..... |
| 15:37.30 | Samot | Why do you need a mass GET? |
| 15:37.37 | Samot | You can just call on them. They're set. |
| 15:37.49 | sibiria | he wants to reduce the log output by not issuing 20 gets in a row |
| 15:38.21 | Samot | But they are already SET.. |
| 15:38.28 | n8n8 | Here is a snapshot of the full log with at least one test call being made (live system, lots of things trying). https://pastebin.com/U7SuYmux |
| 15:38.32 | Samot | So wouldn't just doing ${VAR} be getting it? |
| 15:38.48 | sibiria | he probably wants them in his AGI script, and an AGI instance doesn't automatically import channel variables |
| 15:38.49 | n8n8 | I suspect there is some kind of data corruption in the realtime tables.... |
| 15:38.59 | sibiria | you need to make a Get call for each one |
| 15:39.32 | sibiria | so one way would be to build that string in the dialplan in advance |
| 15:39.39 | sibiria | f.e. by Set(BLAH=${abc};${def};${ghi};etc.) |
| 15:39.50 | sibiria | and then Get it from the AGI script and split it accordingly |
| 15:40.04 | sibiria | result: one Get, not 20 Gets |
| 15:40.17 | Samot | Look at his set... |
| 15:40.24 | Samot | He's setting MASTER_CHANNEL vars. |
| 15:40.42 | Samot | So he would need two SETs. |
| 15:41.09 | *** join/#asterisk stefanauss (~stefanaus@host222-246-static.59-217-b.business.telecomitalia.it) |
| 15:42.07 | Samot | https://www.irccloud.com/pastebin/l3XUbjDD/ |
| 15:42.18 | Samot | n8n8: The issue is the other side. |
| 15:42.26 | Samot | Your PBX is sending back a 401 |
| 15:42.48 | Samot | Instead of re-sending the INVITE with auth headers the other side is just ACKing the 401. |
| 15:43.31 | Samot | User-Agent: Grandstream GXP2160 1.0.7.97 <-- So look at the Grandstream. |
| 15:44.08 | n8n8 | Samot: this worked yesterday... and the phones didn't change, d |
| 15:44.20 | n8n8 | sorry about the extra d... |
| 15:44.24 | Samot | OK. |
| 15:44.29 | Samot | Have you rebooted the phone? |
| 15:45.05 | n8n8 | not the NKB one, but I have had some ppl reboot them, and no change. The configs are centrally managed, and fetched on reboot |
| 15:45.19 | n8n8 | the passwords match ps_auth and the config files |
| 15:45.40 | n8n8 | the phones can register, just not call out... |
| 15:45.45 | Samot | Well you got other issues as well |
| 15:46.06 | Samot | https://www.irccloud.com/pastebin/h9z7nxEi/ |
| 15:46.28 | n8n8 | yes, I saw the OWC thing with the internal server error, but that seems isolated to them, everyone is having the auth issue |
| 15:46.28 | Samot | I see a bunch of SUBSCRIBEs then 401s and when the SUBSCRIBE is resent with proper auth headers.... |
| 15:46.35 | Samot | You're returning 500 Server Errors. |
| 15:47.04 | Samot | n8n8: You sent the grandstream phone a 401 challenge. That's what should happen. |
| 15:47.38 | Samot | The phone sent back an ACK |
| 15:47.46 | Samot | Not a new INVITE |
| 15:48.07 | n8n8 | I believe the subscribe 401's have always been that way.... |
| 15:48.41 | Samot | What that you respond to a proper subcribe request with a 500 error? |
| 15:48.48 | Samot | Thats wrong. |
| 15:49.55 | Samot | So this issue is for one client? Or all users? |
| 15:50.01 | n8n8 | OK, I see what you mean about the ACK to the 401 on INVITE, but, most imporantly at this time is getting back to my working, if crappy, setup... |
| 15:50.08 | n8n8 | all users AFAICT |
| 15:50.14 | igcewieling | sibiria: This does not work in AGI GET VARIABLE ${abc} |
| 15:50.51 | igcewieling | AGI GET VARIABLE abc is correct, but it does not support something like AGI GET VARIABLE abc,myvar2 |
| 15:51.01 | Samot | So all users are not replying to 401 challenges on INVITEs? |
| 15:51.13 | n8n8 | That seems to be the case. |
| 15:51.26 | igcewieling | this is a minor optimization I thought about, not some important feature I desperatly need. |
| 15:51.29 | Samot | They arent sending new INVITES? |
| 15:51.37 | n8n8 | Samot: Correct |
| 15:52.18 | sibiria | igcewieling: yes i know, neither the dial plan onr AGI was ever spec'd to have a notion of arrays. it's why i told you the only way to avoid having to issue loads of GETs is to build a CSV string in the dial plan, and then split it up in the AGI script |
| 15:53.39 | n8n8 | so far as I know, no config has been changed, only a 2 hr window of realtime state being "lost" while asterisk was pointed at the readonly replica DB. |
| 15:54.26 | Samot | So phones have been rebooted? |
| 15:54.51 | n8n8 | Many have, yes, but they'd pull the same config as before the DB pointing issue. |
| 15:56.38 | Samot | Are the phones pulling their profiles from you? |
| 15:57.20 | n8n8 | yes. I generate them, and my PBX DB config at the same time (when I deploy them). These generally do not change. |
| 15:57.29 | Samot | Ok. |
| 15:57.35 | n8n8 | If they do, it is explicit and done by me. |
| 15:57.45 | Samot | So have yoy used a older profile and have them pull that? |
| 15:57.58 | Samot | Because the phones are the issue |
| 15:58.42 | n8n8 | there is only one profile for each phone, and none were changed in the last few days. each phone has its own MAC addr named config file. |
| 15:58.55 | Samot | Do yoy have access to a phone? |
| 15:58.59 | n8n8 | yes |
| 15:59.04 | Samot | Check it |
| 15:59.29 | n8n8 | that is the NKB_7162004262_104 phone. |
| 15:59.42 | Samot | They could have made a pull request during your window of error and screwed up their settings |
| 16:00.42 | n8n8 | the phone configs are static files, not generated on request. |
| 16:01.47 | Samot | Ok look man |
| 16:01.52 | Samot | The phones are the issue |
| 16:02.09 | Samot | Either look at one to see what is up or dont |
| 16:02.25 | Samot | They are not handling the 401 properly |
| 16:05.26 | n8n8 | I'm not sure what I'm going to look for in the phone config. Most settings are left to defaults, my configs are very small, and do not touch most settings. I've just factory defaulted one phone, and it should grab its config, but I do not expect a change in behavior. I know that my overall setup has some problems, I am just trying to get back to a working state. I get where you are coming from with pointing at the phones, but if this one comes back from a facto |
| 16:05.26 | n8n8 | ry default + reprovision and still does not work, I think there is something deeper going on |
| 16:08.10 | Samot | n8n8: What have you actually done with a phone that is having this issue? Troubleshooting wise? What steps have been taken? |
| 16:11.15 | n8n8 | Samot: so far, I've watched the pjsip logs, and run packet captures. I've tested inbound calls, and done/undone small DB config changes to observe different behaviors. The most interesting so far has been to add an entry to endpoint_identifier_ip to see a different query flow |
| 16:11.31 | n8n8 | Also, turned on db query logging for this database. |
| 16:11.57 | n8n8 | From a phone side, I'm really not sure what else to modify / test. I'm completely open to suggestions |
| 16:12.50 | *** join/#asterisk twanny796 (~Twanny@195.158.111.16) |
| 16:13.08 | n8n8 | I'm trying not to get too carried away with changing things without restoring them back to where they were, as yesterday everything was working.... |
| 16:13.37 | n8n8 | This phone is almost ready to re-provision.... the grandstreams take such a long time to reset & boot |
| 16:15.37 | *** join/#asterisk twanny796 (~Twanny@195.158.111.16) |
| 16:17.43 | Samot | Have you tried your own phone? |
| 16:18.01 | Samot | Do you have issues calling out the system from a test phone? |
| 16:19.37 | n8n8 | Samot: factory default and reprovision complete. the phone I rebuilt is: NKB_7162004262_102 here is the log data from a test call on that phone (on my desk next to me): https://pastebin.com/TcbARHRi |
| 16:20.09 | n8n8 | yes, this phone cannot be called out of. I'll catch an inbound to it and paste that so you can see |
| 16:23.24 | Samot | Did you use your profile? |
| 16:23.57 | Samot | Yeah, you did. You said. |
| 16:23.58 | n8n8 | Here is the inbound call to this phone. https://pastebin.com/R23H6ABc |
| 16:24.21 | Samot | So now factory default and manually set the creds up |
| 16:24.48 | Samot | Inbound and outbound ate not the same |
| 16:24.48 | n8n8 | ok |
| 16:24.54 | Samot | Are* |
| 16:32.17 | n8n8 | Samot: hand provisioning does the same thing |
| 16:32.59 | Samot | After a factory reset? |
| 16:33.22 | n8n8 | correct. I just put in the sip server, username and password |
| 16:33.30 | Samot | Show the call |
| 16:34.03 | n8n8 | ok. I there a way to isolate the call in the logger? |
| 16:34.59 | Samot | pjsip set logger ? |
| 16:35.14 | Samot | To get all the options but yes you can limit it to an IP/contact etc |
| 16:35.43 | n8n8 | https://pastebin.com/pdszg3tT |
| 16:36.03 | n8n8 | ah, so host will limit to just one client IP... |
| 16:36.53 | n8n8 | sorry to put you through all the extra junk in there then |
| 16:40.43 | n8n8 | Here is a dump of the logs with pjsip limited to just my IP, but this time I let the phone time out to the fast busy tones: https://pastebin.com/mvb6S2v7 in case that provides any more info |
| 16:42.17 | Samot | Show the AOR setup for this device. |
| 16:42.54 | Samot | I'm unsure why all these Grandstreams are not sending a new INVITE when challenged. |
| 16:43.13 | Samot | You've always challenged them before right? |
| 16:43.47 | n8n8 | here you go: https://pastebin.com/hb1VuRF3 |
| 16:44.33 | n8n8 | I'm honestly not sure I've always challenged them before. That's why I'm trying to dig into the realtime tables in the DB. What settings would affect that? |
| 16:45.00 | Samot | Well do the endpoints have an auth setting? |
| 16:45.41 | n8n8 | in their config or in the ps_endpoints config? |
| 16:45.50 | n8n8 | their being the XML file for the phone |
| 16:46.07 | Samot | In their PJSIP config |
| 16:46.15 | Samot | Have they always had an auth setting? |
| 16:48.04 | n8n8 | well, nothing should have been changed. I know that we didn't run anything to change the data in the realtime tables. I'm really not sure what asterisk gets up to with realtime though |
| 16:48.26 | Samot | You're not answering my question. |
| 16:48.45 | Samot | I'm asking if you've always auth challenged your end users for outbound calls. |
| 16:49.38 | n8n8 | I don't know. I'm checking the DB table now to see what is in there and checking my config gen code to see what it puts in there |
| 16:50.08 | Samot | You don't know you're own security setup for outbound call requests? |
| 16:51.01 | n8n8 | not off the top of my head. I built this system a few years ago.... |
| 16:51.19 | Samot | Uhm. |
| 16:51.26 | Samot | OK. |
| 16:52.24 | n8n8 | we're a small WISP. VOIP is an additional feature customers demanded. I was too cheap to buy a system, so I built a multi-tenent one, that has worked pretty well. Most of our security is managed by firewalls as wo own the network |
| 16:52.30 | n8n8 | we* |
| 16:52.45 | Samot | OK |
| 16:53.14 | Samot | Well I can't see anything wrong with the 401 challenge. |
| 16:53.39 | Samot | Outside of the fact the phones are ACKing it instead of re-sending a new INVITE with auth headers. |
| 16:54.12 | Samot | I don't use Real-Time because, why. It's not really a benefit overall. |
| 16:55.15 | n8n8 | I had big plans to put a web-UI and self service on top of this, and web+db is familiar to me. Perhaps I could have done all of it with flat files.... |
| 16:55.52 | n8n8 | it looks like I've always been populating the auth field |
| 16:56.42 | n8n8 | could some other setting precluded the auth from being looked at? when I messed with the endpoint_identify_ip table, I saw a change in behavior |
| 16:59.06 | Samot | Do you have a non grandstream? |
| 17:00.01 | n8n8 | no... when I took the auth value out of ps_endpoints, outbound worked. |
| 17:00.08 | Samot | Yes |
| 17:00.19 | n8n8 | something must have been overriding / ignoring that... |
| 17:00.27 | Samot | Because youre not challenging them anymore |
| 17:00.33 | Samot | Dude |
| 17:00.45 | n8n8 | I get that. the question is why wasn't I |
| 17:00.51 | Samot | The phones were not responding to the auth challenge right |
| 17:01.03 | n8n8 | that I also understand |
| 17:01.36 | Samot | Because now youre just open for fraud |
| 17:02.23 | n8n8 | I'm clearing the field to restore service. I agree, and I'll figure out the correct way to have the auth working |
| 17:02.53 | n8n8 | what I'd like to understand is how I would have had that populated, but it was apparently being ignored.... |
| 17:03.27 | Samot | Well who said it was? |
| 17:03.43 | Samot | Who is to say that yesterday they were responding to auth challenges right |
| 17:04.37 | n8n8 | No, I think that yesterday there were no auth challenges for reasons TBD, and that for some reason pjsip decided to start sending them |
| 17:04.46 | n8n8 | that's my current theory |
| 17:05.06 | n8n8 | as that config field is clearly being populated |
| 17:06.04 | n8n8 | I think there is something in the pjsip identifiers |
| 17:06.37 | n8n8 | that was preventing authentication. (I'm not saying it was correctly set up, just that it might have been there) |
| 17:08.33 | igcewieling | If I had this issue, I'd manually generate the pjsip conf file from the realtime DB so we can get all the database bs out of the way. |
| 17:08.55 | n8n8 | Samot: In any case. I really appreciate you're taking the time to go through all this with me. I'd be glad to send you some beverages of your choice. |
| 17:09.16 | n8n8 | My problem is not the DB, but which data to look for in it. |
| 17:09.19 | Samot | What igcewieling said |
| 17:10.17 | Samot | And I would also update from a know bug/security vulnerability version to something current. |
| 17:10.23 | Samot | 13.17 had some serious bugs |
| 17:10.28 | n8n8 | I've been a DB guy for far longer than I have asterisk (as I'm sure that's apparent by now....) |
| 17:10.36 | n8n8 | oh, that's good to know.... |
| 17:10.43 | Samot | Not to mention the RTP bleed issue that was fixed for all previous version before 13.17 |
| 17:10.47 | Samot | Including 11 |
| 17:10.51 | n8n8 | I wonder how many of them I depend upon |
| 17:11.13 | Samot | Well the current version is 13.23.1 |
| 17:11.28 | Samot | You're on a version that is almost 2 years old. |
| 17:12.19 | n8n8 | I'll build and get that into my test env... as I said, I put this together some time ago, and pretty much locked it behind our firewalls.... I guess it's time to update. |
| 17:12.26 | Samot | Well |
| 17:12.52 | Samot | The "set it up, forget about it and let it run" plan works great until something happens. |
| 17:13.44 | Samot | And you find out you are now seriously behind in releases and that support for an out of date system becomes rare to find. |
| 17:13.51 | n8n8 | Well, it has always worked better for asterisk than it has a great many other things I depend upon.... * is some solid software in my experience |
| 17:14.01 | Samot | I'm not say it's not solid. |
| 17:14.05 | n8n8 | it being set and forget |
| 17:14.07 | Samot | I've used it for over a decade. |
| 17:14.18 | Samot | But that doesn't mean it shouldn't be kept current. |
| 17:14.30 | Samot | Or at least in a state where it's not open to bugs and security holes. |
| 17:14.53 | Samot | Or in a state where you can't remember a thing about the setup because you've left it sitting for 2 years. |
| 17:15.19 | Samot | Hard to troubleshoot something that is broken if you can't remember how it worked correctly in the first place. |
| 17:16.34 | Samot | Otherwise you end up with a client base that can't make outbound calls for half the day because you weren't sure how it was working correctly or supposed to be working correctly. |
| 17:16.57 | *** join/#asterisk degenerate (~degenerat@S0106cc2de0099182.no.shawcable.net) |
| 17:17.15 | n8n8 | agreed. I've just been burnt by so many other packages over the years when an upgrade breaks something, that I'm always reluctant. but this just goes back to having solid test infrastructure in place.... the problem with being a small business owner.... its really tricky to be as thorough as one should |
| 17:18.00 | Samot | I am a small business owner running a voice network for multiple small ITSPs/MSPs.... |
| 17:18.23 | Samot | On top of 90% of their networking. |
| 17:19.19 | Samot | Unfortunately, I've had to make a rule about dealing with WISPs overall. |
| 17:19.33 | Samot | "We want to add voice to our services" |
| 17:19.47 | Samot | And that right there is the most planning or thought they put into it. |
| 17:21.37 | Samot | I mean outside of the fact they generally have zero voice experience among them.... |
| 17:22.23 | Samot | It usually turns out the network is setup poorly and really can't support voip or they don't actually have enough bandwidth / coverage to support the needs for voip. |
| 17:27.53 | *** join/#asterisk jameswf (uid27319@gateway/web/irccloud.com/x-ahaahjopujwjvrgn) |
| 17:27.54 | n8n8 | Sorry, had a phonecall. I know I don't have enough voice experience, bit I can say that my network has been supporting voice for 8+ years pretty well. I had to learn a lot at the beginning, but I've got law firms, call centers, and a fair number or other businesses (we're 95% business customers) using VOIP without issue over my net. My weakness is in the intricacies of the asterisk config. My biz partner hacked some freepbx's together to meet initial demand, an |
| 17:27.54 | n8n8 | d they've been the source of many of my headache's |
| 17:28.52 | n8n8 | that's why I stood up my multi-tenant asterisk system. to get out of reverse engineering freepbx... |
| 17:35.31 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 17:35.31 | Samot | I use rather highly customized versions of freepbx |
| 17:36.38 | Samot | And in a "multi-tenant" setup |
| 17:39.45 | igcewieling | I use Bicomm PBXware, (multi-tennant version) which is a non-FreePBX GUI for Asterisk for "hosted" customers. |
| 17:41.58 | Samot | I also use a proxy so the users don't directly register to Asterisk/FreePBX |
| 17:42.25 | Samot | Which makes the peers on the PBX side just something there for states/tracking. |
| 17:43.42 | Samot | For the SIP trunk or plain, simple "voip" accounts (resi/soho) the PBX is mainly just used to pass the call through so I can have media control. |
| 17:44.12 | Samot | And voicemail for resi/soho |
| 17:44.26 | Samot | Everything else for them is dealt with outside of the PBX. |
| 17:45.28 | igcewieling | *nod* that makes a lot of sense if you have lots of registrations. |
| 17:45.56 | Samot | I just turned up a hotel yesterday that added 107 |
| 17:46.43 | Samot | Based on current new sales, I should have close to 1,000 new users before the end of the year. |
| 17:47.24 | igcewieling | Out of 286 peers, 6 of them register. Most of the peers are Adtran SIP/Analog gateways (Netvanta or Total access) so there is often a dozen "lines" per peer. |
| 17:47.48 | Samot | Well it's not just registrations. |
| 17:47.49 | igcewieling | Sometimes I wish I had your sales people, Samot |
| 17:48.07 | Samot | You still have to deal with SIP pings, etc. |
| 17:48.25 | igcewieling | I'm curious how you handle call routing when you don't send calls to the PBX |
| 17:48.36 | Samot | I do send calls to the PBX |
| 17:48.41 | igcewieling | every single one? |
| 17:48.47 | Samot | Yes. |
| 17:49.11 | Samot | They are either a SIP trunk/resi/soho which means it's going to the PSTN or voicemail |
| 17:49.33 | igcewieling | what about inbound calls? |
| 17:49.33 | Samot | Or they are "hosted" and they are calling each other and I need to track states for BLF and other monitoring. |
| 17:49.52 | Samot | PSTN -> Switches -> PBX -> Proxy -> Devices |
| 17:50.10 | igcewieling | Switches = Ethernet Switches not Telephony Switches? |
| 17:50.17 | Samot | Softswitches |
| 17:50.36 | Samot | My PBXes sit between proxy/switches |
| 17:51.52 | Samot | I still make peers for those that needed |
| 17:51.58 | Samot | Mainly for the hosted side. |
| 17:52.09 | Samot | So the calls can be controlled and handled by that peer. |
| 17:52.18 | Samot | For calls from the proxy to the PBX |
| 17:52.28 | igcewieling | Our hosted stuff is an entirely different box from our main call routing box. |
| 17:52.29 | Samot | And send calls to that peer to the proxy... |
| 17:52.45 | Samot | My main routing box is a pair of softswitches |
| 17:53.01 | Samot | The routing that is on the PBX is internal for that PBX/users. |
| 17:53.11 | igcewieling | You are able to match incoming packets to the correct peer on Asterisk since all the packets are coming from the IP of your proxy? |
| 17:53.20 | Samot | Yes. |
| 17:53.27 | Samot | It's called "friend" for Chan_SIP |
| 17:53.32 | Samot | username,ip |
| 17:54.09 | igcewieling | I have no idea what you mean |
| 17:54.25 | Samot | When use setup a chan_SIP peer with the type=friend |
| 17:54.30 | Samot | And host=ip |
| 17:54.46 | igcewieling | don't you mean host=ip_of_your_proxy ? |
| 17:54.49 | Samot | When multiple calls from that IP come, Asterisk will match the peers based on username first |
| 17:54.52 | Samot | Yes. |
| 17:55.03 | Samot | Then it will match against the IP |
| 17:55.08 | igcewieling | how many friends do you have with the same IP? |
| 17:55.13 | Samot | All of them. |
| 17:55.38 | Samot | It will look at the peer name/user first |
| 17:55.41 | Samot | Then the IP |
| 17:55.51 | Samot | So I can name the peers whatever I want. |
| 17:56.21 | Samot | Because the proxy will go "Oh user 100@domain1 is peer 901001 on the PBX, let me fix my from user to that" |
| 17:56.38 | Samot | And when it hits the PBX it looks the from is now 901001@domain1 |
| 17:58.03 | Samot | And when a call from the PBX hits the proxy for 901001@domain1 it goes "Oh that's really 100@domain1 let me send it to that AOR/location" |
| 17:58.24 | igcewieling | is AFK on a call |
| 18:09.38 | *** join/#asterisk kharwell (kharwell@nat/digium/x-dfvjsofbpisexvag) |
| 18:09.38 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 18:09.59 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 18:19.37 | igcewieling | Samot: Have you tried running kamailio on the same box as Astersik? |
| 18:19.53 | Samot | Recently? No. |
| 18:20.02 | igcewieling | I'll need 4 kamailio hosts, one for each of our main Asterisk servers. |
| 18:20.04 | Samot | Because I have multiple Kamailio boxes for failover. |
| 18:20.09 | Samot | Why? |
| 18:20.20 | igcewieling | for redundancy of course. |
| 18:20.38 | Samot | But why do you need one for each Asterisk box? |
| 18:20.42 | igcewieling | seems kind of pointless to have 4 call routing boxes when they all go through 1 single proxy. |
| 18:21.49 | Samot | You shouldn't need one per Asterisk box, how many you want for failover is your call. |
| 18:22.12 | igcewieling | right now we failover between 4 asterisk boxes. |
| 18:22.13 | Samot | A single Kamailio box can handle 1,000's of sessions without breaking a swear. |
| 18:22.15 | Samot | A single Kamailio box can handle 1,000's of sessions without breaking a sweat. |
| 18:23.23 | igcewieling | the HARDWARE can fail. |
| 18:23.31 | Samot | I understand that. |
| 18:23.35 | Samot | But four boxes? |
| 18:23.52 | Samot | That's neither here no there. |
| 18:24.12 | Samot | How many you want to run in the failover is a variable that can change. |
| 18:24.28 | Samot | However, you will need a central MySQL server. |
| 18:24.42 | igcewieling | *nod* I currently run 4 main call routing servers, with 3 of them normally active. |
| 18:24.43 | Samot | so they can all use that for their backend. |
| 18:25.01 | igcewieling | I don't need an mysql server for this |
| 18:25.19 | Samot | You need a central DB for them to access. |
| 18:25.25 | Samot | With all the same information. |
| 18:25.25 | igcewieling | WHY? |
| 18:25.32 | Samot | Because it requires a DB backend |
| 18:25.33 | igcewieling | The peers are not registering |
| 18:25.42 | Samot | Sure but other things are in there. |
| 18:25.45 | Samot | Like your domains |
| 18:25.48 | Samot | The attributes |
| 18:25.52 | Samot | The routes you want to use |
| 18:26.00 | Samot | The subscribers (users/domains) |
| 18:26.04 | Samot | If you're using that |
| 18:26.11 | Samot | If this is for call routing you need to be able to route the calls |
| 18:26.18 | Samot | So that is in a backend |
| 18:26.22 | igcewieling | the routes are handles in the asterisk dialplan. |
| 18:26.31 | Samot | Then what is the point of the kamailio box? |
| 18:26.37 | igcewieling | exactly!!!!! |
| 18:26.45 | Samot | OK |
| 18:26.46 | Samot | Dude. |
| 18:26.53 | Samot | Asterisk as a softswitch is not right |
| 18:26.57 | Samot | You should be using Kamailio |
| 18:27.05 | Samot | I thought you were asking because you were looking to actually migrate. |
| 18:27.18 | igcewieling | everyone tells me that, but none of them have compelling reasons except for registration |
| 18:27.22 | Samot | Or some sort of softswitch/sbc |
| 18:27.28 | Samot | Call routing |
| 18:27.34 | Samot | Because Asterisk is NOT a switch. |
| 18:27.47 | igcewieling | I'm trying to find a reason to spend the time to setup Kamailio since everyone tells me how much it is needed. |
| 18:27.57 | Samot | Because it makes things easier. |
| 18:28.02 | Samot | Takes load off of Asterisk |
| 18:28.09 | Samot | Does the job more properly |
| 18:28.14 | igcewieling | I don't need to take load of the Asterisk servers. |
| 18:28.17 | Samot | OK |
| 18:28.23 | Samot | Then why did you ask? |
| 18:28.33 | Samot | Because it seems no matter what valid reasons, you're going to reject them. |
| 18:29.20 | igcewieling | Those are valid reasons for you. If I had dozens or hundreds of registrations I might feel differently. |
| 18:29.33 | Samot | I have peers as well |
| 18:29.47 | Samot | Still does a lot of the routing and call management |
| 18:29.48 | *** join/#asterisk salviadud (~ralfalfa@187-167-69-132.static.axtel.net) |
| 18:29.58 | Samot | Handles the IP auth |
| 18:30.10 | Samot | Verifies the fromuser, etc. |
| 18:30.35 | Samot | Deals with the sip pings for those that are behind NAT |
| 18:30.47 | Samot | Deals with NAT repair |
| 18:31.03 | Samot | Proxying the media so no matter what Asterisk box the call comes from, to the end user it's all the same IP. |
| 18:31.04 | igcewieling | Each time I look at Kamailio I realize I'm trying to re-implement all the stuff I've already implemented in Asterisk dialplan |
| 18:31.09 | Samot | Right |
| 18:31.25 | Samot | But in a more manageable and really, better way. |
| 18:31.31 | Samot | Because it's like what it was designed for. |
| 18:31.34 | Samot | But cool. |
| 18:31.46 | Samot | Asterisk as a switch did wonders with A2Billing. |
| 18:31.52 | Samot | They're still kicking, right? |
| 18:32.30 | igcewieling | no idea, I don't care anything about A2billing, we use OmniBill for billing and use CDRs from the carrier rather than our own CDRs |
| 18:32.40 | sibiria | i think kamailio and similar software are great tools, but certainly not needed for all scenarios. we do hundreds of thousands outbound calls a month originating from our system, and for our use case kamailio or some other SIP proxy would be more of an obstacle |
| 18:32.46 | Samot | Well I use my own CDRs. |
| 18:32.53 | Samot | Because, I have a lot of carriers. |
| 18:33.09 | Samot | I'm not playing the "lets consolidate these usage reports to get our billing done" |
| 18:33.52 | Samot | sibiria: How is it an obstacle? |
| 18:34.06 | Samot | How is a SIP Proxy/SBC an ostacle? |
| 18:34.09 | Samot | How is a SIP Proxy/SBC an obstacle? |
| 18:34.28 | sibiria | Samot: for us it would be one more piece of software to maintain, that wouldn't be needed for our platform to do its job |
| 18:34.38 | Samot | OK. |
| 18:34.50 | Samot | So we got 4 Asterisk boxes running for call routing. |
| 18:34.59 | Samot | I have two kamailio boxes, one is failover. |
| 18:35.02 | Samot | Does the same job. |
| 18:35.08 | Samot | How is that more hardware? |
| 18:35.21 | sibiria | if we were to use multiple carriers, or direct routing to this or that operator, i would be looking into kamailio as the first thing on the agenda |
| 18:35.33 | Samot | Oh and the kamailio box can handle more call volume and routing vs Asterisk with the same resources. |
| 18:35.41 | sibiria | but we only do simple app2phone stuff originating from our own platform |
| 18:37.02 | sibiria | or rather, the stuff we do is sort of complicated, but on SIP/asterisk level it's just running various dial plans on recipient numbers |
| 18:41.36 | igcewieling | Mostly my main call routing (non-freepbx) boxes accept a call, runs an AGI, runs dialplan based on the channel variable the AGI set. Only 500 lines or so of AEL |
| 18:42.20 | igcewieling | 2,500ish lines of PHP AGI |
| 18:44.11 | sibiria | fastagi i hope :P |
| 18:45.25 | igcewieling | no, but if the system load increases enough the first thing I'll try it turning it into FastAGI |
| 18:45.46 | Samot | Except with Kamailio, call comes in, I tag it with all the needed user details, handle the call limits (if channels are limited), check blacklists for the user blocking calls, etc etc then I send the call to the PBX with some extra headers.... |
| 18:46.04 | Samot | 2500 lines of code. |
| 18:46.04 | sibiria | in this scenario PHP has the problem of being quite hungry on startup |
| 18:46.27 | Samot | But that also includes all the outbound, failover, firewalling and extra functionality .. |
| 18:46.37 | Samot | Not just handling the routing of inbound calls. |
| 18:47.37 | igcewieling | *nod* Where do you store your call forwarding info? |
| 18:47.55 | Samot | In a database? |
| 18:48.10 | igcewieling | the kamailio database? |
| 18:48.17 | Samot | Sure. |
| 18:48.28 | igcewieling | how does Asterisk access the forwarding info? |
| 18:48.43 | Samot | It depends on the setup |
| 18:48.48 | Samot | See you don't have "registered" users |
| 18:48.59 | Samot | So in the SIP trunk world, why would Asterisk need it? |
| 18:49.36 | Samot | In those scenarios Asterisk is acting more like a media system than anything else. |
| 18:49.47 | Samot | Kamailio handles all that end user stuff. |
| 18:50.29 | Samot | In a hosted scenario, I let them setup CF via feature codes or use AstDB to set it |
| 18:50.34 | Samot | And then do it at the PBX level. |
| 18:50.50 | igcewieling | *nod* I think the issue is my reluctance to throw out 8 years of work to switch to Kamaililo |
| 18:51.05 | Samot | You can do more |
| 18:51.07 | Samot | Easier |
| 18:51.10 | Samot | More manageable |
| 18:51.17 | Samot | with less. |
| 18:51.26 | Samot | Asterisk is a B2BUA |
| 18:51.30 | Samot | Not a switch/proxy |
| 18:51.35 | Samot | It is not as scalable. |
| 18:51.40 | igcewieling | I already have a full GUI for managing call routing |
| 18:51.54 | Samot | Why do you think there are so many Kamailio+Asterisk designs out there? |
| 18:52.15 | robmal | igcewieling: Can you show some pics? |
| 18:52.24 | robmal | BTW. hi :-) |
| 18:52.33 | Samot | And it's not about a GUI |
| 18:52.40 | Samot | I'm not talking about management in that way |
| 18:53.01 | Samot | I'm talking about managing the actual routing and the results of the request |
| 18:53.06 | igcewieling | robmal: do you have a preferred imagebin? |
| 18:53.15 | Samot | Instead of getting back a 503 and then having to Dial() out again |
| 18:53.25 | Samot | Thus tearing down and setting up a new channel in Asterisk.. |
| 18:53.41 | Samot | Kamailio just goes "Oh, do I have another route for this? Cool, let me send it there" |
| 18:53.51 | Samot | Asterisk thinks the call is still just in progress.. |
| 18:53.53 | Samot | 1 channel |
| 18:54.09 | Samot | That doesn't have to be stopped and created again with each failure. |
| 18:54.35 | robmal | igcewieling: Any will do. |
| 18:54.57 | Samot | Being able to do more with the actual transaction and dialog then just INVITEs when it hits the box. |
| 19:14.41 | *** join/#asterisk LoKoMurdoK (~LoKoMurdo@fedora/LoKoMurdoK) |
| 19:16.08 | *** join/#asterisk stefanauss (~stefanaus@160.97.54.39) |
| 19:26.05 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 19:33.30 | *** join/#asterisk miralin (~Thunderbi@194.8.128.67) |
| 19:51.33 | *** join/#asterisk adeel (~adeel@2602:ffc1:1:face:e495:1b1e:9ed2:bc33) |
| 20:11.59 | *** join/#asterisk NightMonkey_ (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 20:23.08 | *** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net) |
| 21:24.24 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 21:30.50 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 22:08.51 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 22:16.06 | *** part/#asterisk kharwell (kharwell@nat/digium/x-dfvjsofbpisexvag) |
| 22:17.30 | *** join/#asterisk kunwon1 (~kunwon1@unaffiliated/kunwon1) |
| 22:50.39 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 22:50.40 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
| 23:27.11 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 23:27.11 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
| 23:31.38 | *** join/#asterisk Juggie (~Juggie@unaffiliated/juggie) |
| 23:32.11 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 23:32.11 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
| 23:57.23 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |