| 00:19.45 | *** join/#asterisk infobot (ibot@208.53.50.136) |
| 00:19.45 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.22.0 (2018/07/12), Standard: 15.5.0 (2018/07/12); 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:35.20 | *** join/#asterisk jkroon_ (~jkroon@165.16.204.164) |
| 00:40.48 | *** join/#asterisk aoeui (~aoeui@unaffiliated/aoeui) |
| 01:32.34 | Kobaz | hmm, is there a way to turn off connectedline updates on a specific peer (chan_sip) |
| 01:32.38 | Kobaz | not seeing an option for that |
| 01:52.41 | Samot | Dont use the function in dialplan? |
| 01:56.55 | Kobaz | there's more to it than that |
| 02:00.05 | Kobaz | bust-da-pcaps |
| 02:00.05 | *** join/#asterisk sibyakin (~sibyakin@83.234.69.145) |
| 02:01.29 | Kobaz | i'm not using CONNECTEDLINE functions at all, and asterisk is sending an UPDATE after my itsp does a REINVITE |
| 02:01.40 | Kobaz | carrier returns 500 internal server error |
| 02:01.53 | Kobaz | the call lasts for about another minute, and 5 internal server errors later, the call drops |
| 02:02.18 | Kobaz | i'm wanting to do an experiment to not send the UPDATE and see if the call still drops |
| 02:03.01 | Kobaz | http://kobaz.net/misc/sippy.png |
| 02:03.24 | Kobaz | it's all kind of fscked up |
| 04:20.23 | *** join/#asterisk jkroon__ (~jkroon@165.16.204.165) |
| 05:23.57 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 06:08.09 | *** join/#asterisk jkroon__ (~jkroon@165.16.204.170) |
| 06:18.00 | *** join/#asterisk jkroon_ (~jkroon@165.16.204.168) |
| 06:21.08 | *** join/#asterisk jkroon__ (~jkroon@165.16.204.171) |
| 06:25.38 | *** join/#asterisk jkroon_ (~jkroon@165.16.204.172) |
| 06:30.09 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 06:40.08 | *** join/#asterisk jkroon__ (~jkroon@165.16.204.166) |
| 06:41.54 | *** join/#asterisk allizom (~Thunderbi@95.235.160.157) |
| 06:45.52 | *** join/#asterisk cryptic (~cryptic@142.196.170.87) |
| 07:01.43 | *** join/#asterisk jkroon__ (~jkroon@165.16.204.169) |
| 07:05.57 | *** join/#asterisk Sepultura (~Sepultura@unaffiliated/sepultura) |
| 07:25.28 | *** join/#asterisk sibyakin (~sibyakin@83.234.69.145) |
| 08:41.54 | *** join/#asterisk angryuser (~greg@LNeuilly-656-1-71-123.w92-154.abo.wanadoo.fr) |
| 08:59.48 | *** join/#asterisk kayfox (~kayfox@orca.zerda.net) |
| 09:05.26 | *** join/#asterisk Asgaroth (~Asgaroth@212.2.172.228) |
| 09:28.03 | *** join/#asterisk allizom (~Thunderbi@95.235.160.157) |
| 09:30.03 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 09:31.34 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 09:42.01 | *** join/#asterisk jkroon (~jkroon@165.16.204.166) |
| 10:14.03 | *** join/#asterisk Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 10:14.20 | *** join/#asterisk evilman_work (~evilman@87.244.6.228) |
| 10:14.35 | *** join/#asterisk DanQuinney (sid18169@gateway/web/irccloud.com/x-infylwbotzyvpmqa) |
| 10:20.00 | *** join/#asterisk _abc_ (~usre@unaffiliated/ccbbaa) |
| 10:20.16 | _abc_ | Beep. When is this channel even slightly responsive? ;-) |
| 10:20.53 | _abc_ | Are there any recipes to make * calls android to android sip with video? Anywhere in the * docs? I can only find older docs, apparently it was possible with patches since 1.4, I assume it is "in" permanently now? |
| 10:22.21 | *** join/#asterisk nighty- (~nighty@s229123.ppp.asahi-net.or.jp) |
| 10:31.26 | file | you enable video in the respective channel driver config file, and then use it |
| 10:45.49 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 10:47.41 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 11:24.07 | *** join/#asterisk exuberocity (~exuberoci@rrcs-162-155-56-66.central.biz.rr.com) |
| 11:24.55 | *** join/#asterisk allizom (~Thunderbi@95.235.160.157) |
| 11:31.03 | *** join/#asterisk Asgaroth (~Asgaroth@212.2.172.228) |
| 12:12.19 | *** join/#asterisk qakhan (~qakhan@50-204-254-11-static.hfc.comcastbusiness.net) |
| 12:16.50 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
| 12:17.32 | qakhan | Good Morning all, I receive spam calls from rendom numbers, like Test1, 101, 29 etc..... when i answer the call there is no one. when i do sip show channels. I get this output. https://pastebin.com/C6zPTueL |
| 12:29.05 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 12:29.54 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
| 12:36.43 | _abc_ | file: thanks |
| 12:36.55 | *** part/#asterisk _abc_ (~usre@unaffiliated/ccbbaa) |
| 12:37.57 | *** join/#asterisk mitrax (mitrax@LFbn-NCY-1-325-94.w83-196.abo.wanadoo.fr) |
| 12:40.07 | mitrax | what parameter(s) usually cause an asterisk based ipbx to answer the call immediately with no ring tone for the caller until someone picks up? not sure if the problem is on my side or my itsp's |
| 12:42.55 | *** join/#asterisk sibyakin (~sibyakin@83.234.69.145) |
| 12:44.09 | file | Answer() in the dialplan? |
| 12:54.52 | *** join/#asterisk jeffspeff (~jeffspeff@209.141.208.197) |
| 12:56.15 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 13:11.24 | sibiria | mitrax: the problem is likely that, like file says, your dialplan goes to Answer()s immediately instead of waiting a bit first |
| 13:11.45 | sibiria | a 2 second wait before Answer() usually gives enough time for at least one rign signal to get back |
| 13:21.21 | *** join/#asterisk scgm11_ (~scgm11@r186-50-104-161.dialup.adsl.anteldata.net.uy) |
| 13:26.09 | mitrax | yeah my mistake, i had a hold music configured by default for the target group for incoming calls... (dialplan is generated by wazo), thanks! |
| 13:28.56 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 13:39.54 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 13:41.46 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 13:42.35 | *** join/#asterisk sinaowolabi (~Sina@41.58.109.117) |
| 13:43.22 | *** join/#asterisk Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 13:53.57 | Kobaz | anyone use odbc and have any tidbits on debugging this: getting odbc warnings/errors: ONN ERROR: func=PGAPI_SetConnectAttr, desc='', errnum=216, errmsg='Couldn't set unsupported connect attribute 113' |
| 13:54.07 | Kobaz | odbc works, but, that prints at least once a day in the odbc logs |
| 13:59.20 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 13:59.45 | *** join/#asterisk qakhan (~qakhan@50-204-254-11-static.hfc.comcastbusiness.net) |
| 13:59.56 | qakhan | I receive spam calls from rendom numbers, like Test1, 101, 29 etc..... when i answer the call there is no one. when i do sip show channels. I get this output. https://pastebin.com/C6zPTueL |
| 14:01.37 | sibiria | and that's how it is if you allow incoming calls from the entire world |
| 14:02.09 | qakhan | how can we stop it? |
| 14:04.39 | sibiria | if you're on chan_sip, allowguest=no, but this may not suit your setup |
| 14:05.12 | qakhan | yes, i already setup allowguest=no |
| 14:06.28 | *** join/#asterisk jeffspeff (~jeffspeff@12.49.160.131) |
| 14:06.30 | Samot | Well, running a sip debug would help. |
| 14:06.39 | Samot | Actually looking for the calls. |
| 14:07.05 | Samot | Seeing what they are sending to you, where they are coming from. Then you start banning them. |
| 14:07.51 | sibiria | qakhan: did you restart after changing allowguest? :P |
| 14:08.06 | qakhan | I already setup fail2ban on the server which blocks the iP addresses. |
| 14:08.12 | qakhan | sibiria yes |
| 14:08.22 | sibiria | also, this option obviously only works if you are using chan_sip, not for pjsip |
| 14:08.48 | qakhan | reload is very important, yes i am using SIP |
| 14:08.53 | qakhan | no pjsip |
| 14:09.06 | Samot | OK, fail2ban is a poor security measure for this. |
| 14:09.16 | Samot | It has to read *log files* |
| 14:09.24 | Samot | So that means it already happened. |
| 14:10.04 | Samot | Sure they stop me from making *future* attempts but if I already got the 5 International calls out that I needed..who cares? |
| 14:10.08 | qakhan | Samot how can i ban them? what other security is available for this kind of calls |
| 14:10.15 | Samot | Uhm, iptables. |
| 14:10.38 | Samot | The same security that Linux boxes have been using for years for things like this. |
| 14:11.04 | qakhan | so all these bans will be manual |
| 14:11.06 | qakhan | right? |
| 14:11.11 | Samot | Absolutely not. |
| 14:11.12 | sibiria | no, you can automate it |
| 14:11.23 | Samot | iptables is a firewall |
| 14:11.37 | *** join/#asterisk kharwell (kharwell@nat/digium/x-xjiesloxsmbuwblr) |
| 14:11.37 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:11.47 | Samot | It has chains, rules, pre-mangling |
| 14:12.02 | qakhan | is there any script/software available for that |
| 14:12.03 | Samot | It can do threshold limits, connection tracking.. |
| 14:12.06 | Samot | Google. |
| 14:12.29 | Samot | "sip iptables rules" |
| 14:15.01 | qakhan | ok let me check. so just to clear myself, do i need to see IP address of source in sip debug? |
| 14:15.13 | Kobaz | qakhan: sip scanners |
| 14:15.43 | Kobaz | qakhan: zombie machines are looking for open sip proxy/gateways/etc to make high rate calls |
| 14:16.28 | qakhan | i checked that, they dont register extens with my server. |
| 14:16.38 | Kobaz | qakhan: it sounds like you need to drop anonymous handling for sip calls... and put in some decent access controls in your iptables |
| 14:16.48 | Kobaz | limit by ip (if you can) what hosts can make calls |
| 14:17.06 | qakhan | i have complex passwords for extensions |
| 14:17.14 | Kobaz | yeaaaah that doesn't matter |
| 14:17.21 | dan_j | Hi. |
| 14:17.34 | Kobaz | your peer could have a million character password... if it gets leaked then game over |
| 14:17.38 | sibiria | allowguests=no and defined peers/friends should be enough to keep the attempts out |
| 14:18.03 | Samot | 10:06:32 AM <Samot> Well, running a sip debug would help. |
| 14:18.03 | Samot | 10:06:41 AM <Samot> Actually looking for the calls. |
| 14:18.07 | dan_j | Regarding the Call ID that appears in the logs (eg C-00002380), can that be stored in a MySQL Database alongside CDR records? |
| 14:18.14 | Kobaz | right... yeah log entries... show us dem logs |
| 14:18.22 | Samot | Not logs |
| 14:18.25 | Samot | DEBUGS |
| 14:18.31 | Samot | The actual SIP messages. |
| 14:18.41 | Kobaz | sip messages go to the logs |
| 14:18.49 | Kobaz | if set up correctly |
| 14:18.56 | Samot | Only if you leave SIP debug running |
| 14:19.03 | Samot | But then the messages are not consistant. |
| 14:19.06 | Samot | But then the messages are not consistent. |
| 14:19.11 | Kobaz | that is a prerequisite, yeap |
| 14:19.15 | Samot | They get broken up |
| 14:19.29 | Samot | So you can't just "look" at a full message intact. |
| 14:19.58 | Kobaz | i don't have any issues with sip dumps being split |
| 14:20.06 | Samot | OK. |
| 14:20.21 | Kobaz | i'm sure it's possible, but anyway asterisk needs sip per-dialogue logging anyway |
| 14:20.26 | Kobaz | to seperate files |
| 14:20.32 | sibiria | dan_j: that's the call identifier. you can get it through the CHANNEL variables, named callid |
| 14:20.56 | Samot | dan_j: That's the log id. |
| 14:21.11 | Samot | dan_j: The actual Call-ID header would not have that. |
| 14:21.18 | sibiria | in asterisk terms, "call identifier" |
| 14:21.26 | Samot | I get that |
| 14:21.29 | Kobaz | Samot: he wants to log the call-id (asterisk's call-id) in cdr |
| 14:21.33 | Samot | But in SIP terms Call-ID means something. |
| 14:21.36 | Samot | I know. |
| 14:21.44 | Samot | I could tell by the example he wanted. |
| 14:21.47 | sibiria | he asked for the call identifier (C-xxxxxxxx) |
| 14:21.51 | Samot | I get that |
| 14:21.55 | Samot | JFC. |
| 14:22.00 | Kobaz | i'm not sure if cdr logs that |
| 14:22.00 | Samot | Call-ID is an actual SIP header. |
| 14:22.12 | Samot | I get that Asterisk has a "call identifier" for the logs |
| 14:22.26 | Kobaz | speaking of logging... i'm going to be adding to my own logging the actual sip-call id |
| 14:22.31 | *** join/#asterisk u0m3 (~u0m3@86.120.80.34) |
| 14:22.40 | Samot | I was explicitly explaining the difference. |
| 14:23.03 | Kobaz | it'll be wildly helpful when doing deeper sip investigations... the call id only shows up in the asterisk console when the dialogue completely dies (like sip retransmission failures) |
| 14:23.36 | sibiria | it's all loggable through cdr_custom |
| 14:24.14 | sibiria | and adaptive_odbc as well |
| 14:24.22 | sibiria | for your rdbms logging needs |
| 14:25.54 | *** join/#asterisk giesen_ (~ggiesen@ego.giesen.me) |
| 14:26.06 | Kobaz | for all your late night rdms adventures |
| 14:26.57 | sibiria | dan_j: btw., before storing the call identifier, keep in mind that just like the channel id it's a rolling counter that will reset when you restart asterisk |
| 14:27.03 | sibiria | ie. it's not u.... and there he disconnects |
| 14:27.57 | *** part/#asterisk eric_hill (~eric_hill@wsip-184-180-163-60.ks.ks.cox.net) |
| 14:40.47 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-ogrddhnyiufzgbmx) |
| 14:40.47 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:52.59 | qakhan | this is the sip debug i got https://pastebin.com/rHWDQWJw |
| 14:54.02 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-dehcyyhthpsnfcvt) |
| 14:54.03 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 14:54.54 | Samot | Yup, just as I thought. |
| 14:55.15 | Samot | 195.154.31.13 703 58b4cef448e9e14 (nothing) No Rx: INVITE <guest> |
| 14:55.28 | Samot | So when you see this in the "channels" list, it is a SIP channel. |
| 14:55.35 | Samot | In this context the channel is not a "call" |
| 14:55.57 | Samot | It is the SIP thread handling that transaction. |
| 14:56.23 | Samot | Didn't you not see how you are sending back 401 Unauthorized's to them? |
| 14:56.43 | Samot | And that those 401's time out? |
| 14:56.59 | Samot | It's a one way sniff attack and Asterisk is not authorizing them. |
| 14:57.55 | qakhan | is there anyway we can block these sniff attacker |
| 14:59.20 | igcewieling | qakhan: SIPS, but there is no REASON to do that. |
| 14:59.52 | igcewieling | Nobody is going to sniff a SIP password in cleartext, since they are not transmitted in cleartext. |
| 15:00.33 | qakhan | then how come my phones are getting spam calls, like test1, 1001, 703 etc.... |
| 15:00.48 | qakhan | when i answer the call there is no one |
| 15:01.01 | igcewieling | qakhan: because you've not told your phone to only accept calls from the PBX. |
| 15:01.43 | qakhan | i entered my * IP address in SIP setting in the phone |
| 15:02.07 | igcewieling | With Polycom phones the setting is voIpProt.SIP.strictUserValidation="1". by many phones accept connections from anywhwere |
| 15:02.36 | igcewieling | qakhan: chances are that is for outgoing. |
| 15:03.09 | igcewieling | What specific phone are you using? |
| 15:03.25 | igcewieling | You realize this is a common problem, right? |
| 15:03.36 | qakhan | the issue i am facing, are calls coming through the * or directly to phones (IP calls) |
| 15:03.58 | qakhan | i am using polycom and yealink |
| 15:04.37 | igcewieling | well, add the setting to the polycom and move on with life. |
| 15:05.34 | qakhan | <qakhan> the issue i am facing, are calls coming through the * or directly to phones (IP calls) |
| 15:06.06 | igcewieling | qakhan: I already told you they are coming direct, unless you have specific evidence on the PBX showing that is not the casd. |
| 15:06.22 | igcewieling | that polycom setting should be standard on all your setups. |
| 15:07.16 | Samot | So both the PBX and the phones are getting hit with calls? |
| 15:07.43 | Samot | That means your network is not setup right |
| 15:07.51 | Samot | You're letting 5060 in from the world. |
| 15:08.15 | igcewieling | I suspect is is more of a case crappy nat |
| 15:08.16 | Samot | If the PBX and the phones are on the same local network and getting those calls, then it's the NETWORK being hit not the PBX. |
| 15:08.34 | qakhan | no, i dont see these calls in *. i was not sure about 195.154.31.13 703 58b4cef448e9e14 (nothing) No Rx: INVITE <guest> |
| 15:08.46 | igcewieling | qakhan: that is not a call |
| 15:08.51 | Samot | It's an INVITE |
| 15:08.52 | qakhan | therefore i asked about it. |
| 15:09.02 | qakhan | ok i understand now. |
| 15:09.03 | Samot | That I just said the PBX was rejecting. |
| 15:09.10 | igcewieling | As Sam said, maybe the entire network is being attacked. |
| 15:09.14 | Samot | Your network firewall and NAT rules are not setup right. |
| 15:09.15 | qakhan | my * and phones are over the internet |
| 15:09.29 | Samot | So is Asterisk and the phones on the same network? |
| 15:09.41 | qakhan | no, over the internet |
| 15:09.48 | Samot | So Asterisk is hosted |
| 15:09.52 | qakhan | yes |
| 15:09.58 | Samot | So it's two attacks. |
| 15:10.05 | Samot | The network where the phones are is being scanned |
| 15:10.10 | Samot | And your PBX is being scanned |
| 15:10.17 | Samot | In both cases, it's poor firewalling |
| 15:11.00 | Samot | The PBX should not be open to anything but your providers and where the phones are located |
| 15:11.07 | *** join/#asterisk elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 15:11.16 | Samot | And where the phones are located, only the PBX should have access over SIP. |
| 15:11.30 | Samot | There is no need to have them opened to the world. |
| 15:13.22 | qakhan | ok |
| 15:14.07 | *** join/#asterisk tuxd00d (~tuxd00d@unaffiliated/tuxd00d) |
| 15:14.22 | *** join/#asterisk salviadud (~ralfalfa@187-167-69-132.static.axtel.net) |
| 15:14.29 | qakhan | so should i use iptables for * or some hardware firewall |
| 15:15.39 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 15:17.01 | Samot | Well if it's in a DC that you can put another server/firewall appliance in, yes. |
| 15:17.09 | Samot | So you can secure your whole network. |
| 15:17.15 | Samot | Otherwise, iptables. |
| 15:19.38 | igcewieling | It is still a good idea to use strict user validation |
| 15:22.03 | qakhan | igcewieling any option in yealink? |
| 15:24.23 | igcewieling | never used them |
| 15:24.39 | igcewieling | this is a common problem, so they should have some sort of setting for it. |
| 15:24.47 | [TK]D-Fender | some think they're OK. Many end up with issues about how they function. |
| 15:25.15 | [TK]D-Fender | I'd simply avoid |
| 15:26.14 | igcewieling | I found Polycom meets my needs so there is no reason to consider anything else. |
| 15:26.49 | igcewieling | If a customer wants a cordless phone, I use VTech |
| 15:29.20 | [TK]D-Fender | I've use Aastra for certain applications that Polycom wasn't a good competitor for, and have recently taken on one of the newest Grandstream models , again for a specific application. |
| 15:34.45 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:34.45 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 15:41.05 | *** join/#asterisk BeachBall (~BeachBall@unaffiliated/beachball) |
| 15:41.45 | tuxd00d | Yealinks are okay. They work. Easy to provision. |
| 15:42.32 | BeachBall | I'm trying to have my asterisk accept an analog call and forward it to a H323 polycom unit. I have the default h323.conf, and using s,1,Dial(H323/IP of Polycom) ... is this how it's suppose to be done? |
| 15:49.15 | igcewieling | Not many people use H323 anymore so you'll have trouble finding people who are familiar with it. |
| 15:49.37 | BeachBall | that's all we use |
| 15:49.55 | Samot | Wow. |
| 15:50.05 | BeachBall | and it's a pain, because we can't call or receive from sip devices |
| 15:50.33 | BeachBall | and most of our gear is end of life >:) |
| 15:50.51 | Samot | Yeah well H232 lost out a long time ago |
| 15:53.24 | *** join/#asterisk imcdona (~imcdona@2607:f0d8:20:1001:30bd:d471:2b1e:a682) |
| 15:53.33 | igcewieling | there is no sip firmware for the device? |
| 15:53.40 | BeachBall | there is |
| 15:54.10 | BeachBall | but we don't have anything setup for it |
| 15:54.59 | BeachBall | it's almost lunch time.... new question, do I eat kraft dinner, or tomato soup? |
| 15:55.06 | BeachBall | :P |
| 15:57.08 | BeachBall | i should re-think how i'm doing it |
| 16:33.25 | *** join/#asterisk scgm11_ (~scgm11@r186-50-104-161.dialup.adsl.anteldata.net.uy) |
| 16:39.36 | *** join/#asterisk sinaowolabi (~Sina@41.58.109.117) |
| 17:05.04 | *** join/#asterisk scgm11_ (~scgm11@r186-50-104-161.dialup.adsl.anteldata.net.uy) |
| 17:44.12 | *** join/#asterisk scgm11_ (~scgm11@r186-50-104-161.dialup.adsl.anteldata.net.uy) |
| 17:46.52 | *** join/#asterisk clarjon_1 (~clarjon1@unaffiliated/clarjon1) |
| 17:49.34 | *** join/#asterisk Billy2 (~Billy2@208-85-2-206.static.as40244.net) |
| 17:50.27 | *** join/#asterisk scgm11_ (~scgm11@r186-50-104-161.dialup.adsl.anteldata.net.uy) |
| 17:52.07 | Billy2 | hey all, could anyone point me in the right direction for determining if any calls are coming in over our PRI connection? We recently ported our numbers to a SIP provider and want to make sure all the numbers are actually moved. The "messages" log doesn't seem to indicate which connection incoming calls are hitting |
| 17:59.45 | jpsharp | You should be able to see if the calls are coming in via SIP/channel or DAHDI/channel |
| 18:17.05 | *** join/#asterisk scgm11_ (~scgm11@r186-50-104-161.dialup.adsl.anteldata.net.uy) |
| 18:17.23 | Kobaz | anyone have any issues where MixMonitor randomly stops recording a few seconds into a call? |
| 18:17.32 | Kobaz | with no errors/warnings in the console |
| 18:17.48 | Kobaz | 30 minute call, and MixMonitor ended normally (so it says) on hangup |
| 18:22.38 | *** join/#asterisk aoeui (~aoeui@unaffiliated/aoeui) |
| 18:22.47 | *** join/#asterisk scgm11_ (~scgm11@r186-50-104-161.dialup.adsl.anteldata.net.uy) |
| 18:27.51 | Samot | Is it a 30 minute recording? |
| 18:27.57 | Kobaz | 6 seconds |
| 18:38.48 | *** join/#asterisk jjrh (~weechat12@2607:f0b0:7:8031::177) |
| 18:46.52 | Kobaz | other recordings were going on just fine simultaneously |
| 18:47.00 | Kobaz | so it's not like the whole mixmonitor module crapped out |
| 18:47.13 | Kobaz | does mixmonitor use autoservice? |
| 18:47.32 | Kobaz | i can check into that... i noticed autoservice ended pretty earily into the call |
| 18:48.40 | Kobaz | ah... i found another call that had a full recording saved, and it also has autoservice stopping pretty earily on |
| 18:50.20 | *** join/#asterisk scgm11_ (~scgm11@r186-50-104-161.dialup.adsl.anteldata.net.uy) |
| 19:18.30 | *** join/#asterisk sinaowolabi (~Sina@41.58.109.117) |
| 19:34.45 | *** join/#asterisk SebastienThiry (~Thunderbi@109.134.17.12) |
| 19:50.28 | *** join/#asterisk miralin (~Thunderbi@194.8.128.63) |
| 19:57.16 | *** join/#asterisk scgm11_ (~scgm11@r186-50-104-161.dialup.adsl.anteldata.net.uy) |
| 20:04.09 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
| 20:05.23 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
| 20:15.55 | *** join/#asterisk scgm11_ (~scgm11@r186-52-201-28.dialup.adsl.anteldata.net.uy) |
| 20:20.48 | *** join/#asterisk allizom (~Thunderbi@95.235.160.157) |
| 20:23.38 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 21:29.00 | imcdona | What is the best way to debug PJSIP's DNS resolution? |
| 21:29.21 | *** join/#asterisk tehgooch (tehgooch@unaffiliated/tehgooch) |
| 21:29.49 | imcdona | I think that I've found a bug whereby pjsip DNS breaks when you have ::1 set as a resolver in /etc/resolve.conf need to confirm with testing though |
| 21:59.57 | *** join/#asterisk jeffspeff (~jeffspeff@209.141.208.197) |
| 22:07.45 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 22:57.00 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:a19e:ce1:1295:4c19) |
| 23:30.48 | *** part/#asterisk kharwell (kharwell@nat/digium/x-xjiesloxsmbuwblr) |
| 23:47.55 | *** join/#asterisk zopsi (~zopsi@dir.ac) |
| 23:50.18 | *** join/#asterisk zopsi (~zopsi@dir.ac) |
