| 00:11.39 | *** join/#asterisk tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 00:23.35 | *** join/#asterisk J0hnSteel (~J0hnSteel@92.55.116.178) |
| 00:34.47 | *** join/#asterisk freebs (~freebs@unaffiliated/freebs) |
| 03:03.48 | *** join/#asterisk ChannelZ (channelz@burner.com) |
| 03:06.29 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 03:13.05 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 03:48.33 | *** join/#asterisk shootbird (~quassel@205.185.122.214) |
| 04:03.42 | *** join/#asterisk tompaw (~tompaw@tompaw.xxx) |
| 04:26.55 | *** join/#asterisk rwb (~Thunderbi@65.183.151.239) |
| 04:34.36 | *** join/#asterisk vstemen (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 04:37.06 | *** join/#asterisk freebs (~freebs@unaffiliated/freebs) |
| 04:52.59 | snadge | whats this retransmission timed out after 32 seconds bullshit ;) |
| 04:53.12 | snadge | when i look into it.. its fuckwads |
| 05:01.37 | Samot | What? |
| 05:02.20 | snadge | sip scanners.. im just getting grumpy because i've been on this all morning |
| 05:03.03 | Samot | What do sip scanners have to do with re-transmission timeouts? |
| 05:07.00 | *** join/#asterisk MaliutaLap (~nobusines@unaffiliated/maliuta) |
| 05:15.22 | *** join/#asterisk MaliutaLap (~nobusines@unaffiliated/maliuta) |
| 05:20.27 | igcewieling | Samot: they generate them |
| 05:21.00 | Samot | I was more prodding for if there was an actual issue he was looking for help with. |
| 05:21.12 | Samot | Because they aren't the only thing that generates that. |
| 05:21.15 | drmessano | So block them |
| 05:21.46 | Samot | So hence my question, because his initial statements only were about re-transmission errors.. |
| 05:22.02 | Samot | Then he made a statement about sip scanners and nothing related the two statements. |
| 05:23.40 | drmessano | You're asking for a lot |
| 05:25.02 | Samot | I know. |
| 05:25.04 | Samot | I'm sorry. |
| 05:25.21 | Samot | I know how you are about commitments. |
| 05:45.46 | snadge | yeah i personally dont know why sip scanners are causing retransmission timeouts.. but i have modified my script to work on these pbxs, and blocked them |
| 05:46.14 | snadge | and then there was one remaining culprit.. from africa somewhere, seychelles |
| 05:46.23 | snadge | and i manually blocked them.. now console silence.. like it should be ;) |
| 05:47.13 | snadge | we used to have an application layer firewall.. but its gone.. and now i have to kludge around it with iptables hacks |
| 05:48.13 | snadge | pretty common problem really.. how do you allow connections from anywhere on the internet, but still block dickheads |
| 05:49.29 | snadge | it would be nice if dickheads set a dickhead ip flag.. and you could just filter against that ;) |
| 05:51.41 | drmessano | You set up iptables to look for excessive invites and registers from any given IP and then block them |
| 05:51.45 | drmessano | It's pretty simple |
| 05:52.28 | snadge | thats the part i haven't gotten around to.. already blocking failed auths of course, with fail2ban |
| 05:52.42 | drmessano | fail2ban is useless |
| 05:52.47 | snadge | and with a pbx that is much easier than our core servers.. as they won't have dialers attached to them etc |
| 05:52.49 | drmessano | Just do it in iptables alone |
| 05:53.11 | igcewieling | snadge: you could allow them to auth and dump them into a jail context. |
| 05:55.05 | igcewieling | iptables to block some sip scanners: http://pastebin.com/V1uSb6GK |
| 05:55.09 | snadge | fail2ban at least stops brute force password attempts, but yes, it is pretty useless otherwise.. but im also using it to filter out user agents (with iptables string matching) |
| 05:55.28 | Samot | snadge: It's not real time. |
| 05:55.42 | Samot | By the time it determines a brute force attack, they could already be in. |
| 05:56.21 | snadge | its close enough to realtime.. the resolution is seconds |
| 05:56.36 | snadge | i'd be super impressed if someone could brute force a password within a few seconds :p |
| 05:57.19 | Samot | I guess it would depend on the strength of your password. |
| 05:57.41 | snadge | passw0rd |
| 05:57.50 | snadge | its secure.. because it has a 0 for an o |
| 05:58.24 | snadge | nobody would ever think of that ;) |
| 05:59.24 | drmessano | It's a waste of system resources |
| 05:59.32 | drmessano | For something you can stop with iptables |
| 05:59.58 | drmessano | rather than parsing logs of prior requests then telling iptables to block |
| 06:00.18 | drmessano | cringeworthy |
| 06:01.46 | igcewieling | there's no reason not to do both |
| 06:02.12 | drmessano | fail2ban would be redundant in any given case |
| 06:02.22 | igcewieling | I agree that fail2ban is not all that useful, but it won't prevent you from pre-filtering with string matches. |
| 06:02.58 | drmessano | If I am matching in iptables, there's absolutely no need for fail2ban |
| 06:03.15 | igcewieling | drmessano: unless someone changes their scanner's useragent |
| 06:03.35 | drmessano | I don't just look for useragetns |
| 06:03.37 | drmessano | I don't just look for useragents |
| 06:03.38 | drmessano | So no |
| 06:04.10 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 06:04.30 | drmessano | The useragent is secondary to looking for INVITE and REGISTER attempts, really.. |
| 06:04.34 | igcewieling | snadge is or at least would. |
| 06:05.10 | drmessano | I would wager I can't the excessive requests before the useragent strings in any given case |
| 06:05.20 | drmessano | s/can't/catch/ |
| 06:05.38 | snadge | iptables will only log though.. it wont actually block anything? |
| 06:05.44 | igcewieling | feel free to share the iptables rules |
| 06:05.45 | drmessano | Yes it will |
| 06:05.47 | snadge | unless you statically block something of course |
| 06:06.00 | drmessano | igcewieling: I showed you an example the other day |
| 06:06.11 | drmessano | snadge: No, it's dynamic |
| 06:06.45 | igcewieling | that doesn't help snadge |
| 06:06.55 | snadge | i think i see the logic.. whether its auth failures, scanning, or whatever.. you're getting > threshold requests from a specific ip in each case |
| 06:07.04 | igcewieling | I don't care what you do, I was trying to help snadge |
| 06:08.32 | drmessano | http://pastebin.com/fmF9dpxt |
| 06:09.16 | drmessano | That's a snip. I have a big list of useragents as well, but that's been shared ad nauseum |
| 06:09.37 | drmessano | You would need to just the hitcounts accordingly |
| 06:09.57 | drmessano | adjust |
| 06:10.01 | igcewieling | nice. It might not help with a slow scan, but most people are too impatient to do that. |
| 06:10.11 | drmessano | Right |
| 06:10.18 | igcewieling | multiple levels of security is the only security which works. |
| 06:10.23 | drmessano | Slow scans don't risk killing chan_sip |
| 06:10.31 | drmessano | and even if |
| 06:10.48 | drmessano | THAT is where you play the odds with the useragent stuff |
| 06:11.00 | drmessano | If it's slow, hopefully it's a known UA and that will nuke it |
| 06:12.25 | igcewieling | *nod* We have so few registered users (most are static IPs) I might be able to block almost all registrations on our main call server. |
| 06:15.47 | drmessano | i can also tell you that as far as clients with a bunch of endpoints, and the whole site bouncing and matching the hitcount.. I tweaked and tweaked on different boxes, and even if I had it too tight and killed a site, it would fix itself in under 5 mins. Because as the retries started backing off, within a few minutes it was well below the limit. |
| 06:17.01 | drmessano | I don't know how often you might expect to lose a whole site with a bunch of endpoints, but I did something like 1.5x the actual number of registrations and I had to keep bouncing the connection to piss off iptables |
| 06:17.06 | drmessano | So the logic seems sound |
| 06:18.35 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 06:25.33 | igcewieling | I'd not thought of that issue. |
| 06:34.15 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
| 07:30.36 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 07:56.46 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 07:57.12 | *** join/#asterisk pchero_work (~pchero@2a00:c80:1072::152e) |
| 08:14.16 | *** join/#asterisk samwierema (~samwierem@095-097-255-066.static.chello.nl) |
| 08:20.34 | *** join/#asterisk defsdoor (~andy@cpc35-sutt4-2-0-cust184.19-1.cable.virginm.net) |
| 08:35.19 | *** join/#asterisk sekil (~sekil@cable-89-216-194-219.dynamic.sbb.rs) |
| 08:54.27 | *** join/#asterisk MaliutaLap (~nobusines@unaffiliated/maliuta) |
| 09:16.30 | *** join/#asterisk AviiNL (~AviiNL@37.235.86.246) |
| 09:26.41 | *** join/#asterisk Iamnach0 (~Iamnacho@ip24-252-4-195.om.om.cox.net) |
| 09:54.44 | *** join/#asterisk sotoz (~textual@095-097-255-066.static.chello.nl) |
| 09:55.04 | sotoz | Hello |
| 09:55.44 | sotoz | What is the best way to set the callerID through the ARI? |
| 09:56.59 | sotoz | I use 'POST /channels/create' |
| 10:00.09 | *** join/#asterisk friedrich (~friedrich@aextron.de) |
| 10:00.58 | sotoz | Is setting the `${CALLERID(all)}` a proper way to go? |
| 10:02.32 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 10:14.10 | sotoz | well, that solved it |
| 10:43.18 | *** join/#asterisk asaas_sk (d9491e82@gateway/web/freenode/ip.217.73.30.130) |
| 10:56.17 | asaas_sk | Hey guys, could you please help me with my problem? I can not receive calls with sipML5 client and I believe I made some mistake in Asterisk configuration. To not flood this channel, I described my problem here https://drive.google.com/open?id=0B4RiFRpl1QYJbENLTDkwVFcxVXM |
| 11:10.06 | *** join/#asterisk AdNauseum (uid126405@gateway/web/irccloud.com/x-isyudjbwyduahgmh) |
| 11:28.29 | *** join/#asterisk evil_gordita (robert@70.188.41.127) |
| 11:30.53 | *** join/#asterisk vstemen (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 11:46.24 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 13:02.27 | stefan27 | (asaas_sk's problem seems to be that his 1001 sip peer has transport udp not wss) |
| 13:12.31 | *** join/#asterisk MrMojit0 (~MrMojit0@hoofddorp.cn.nl) |
| 13:13.02 | *** join/#asterisk josecapurro (~jcapurro@host-242.172.52.190.copaco.com.py) |
| 13:14.54 | *** join/#asterisk sotoz (~textual@095-097-255-066.static.chello.nl) |
| 13:20.29 | *** join/#asterisk Rini (uid196547@gateway/web/irccloud.com/x-ifsxdvrnatczarmh) |
| 13:25.55 | *** join/#asterisk puzzled (~puzzled@5ED2CF0E.cm-7-3d.dynamic.ziggo.nl) |
| 13:30.18 | *** join/#asterisk zappaFan (~chatzilla@100.red-88-26-250.staticip.rima-tde.net) |
| 13:31.35 | zappaFan | Hi there people, going crazy here, the CID NAME and CID NUM are getting transposed when trying to connect asterisk with a beronet |
| 13:32.00 | zappaFan | CID : "603" <beronetISDN>") in new stack |
| 13:32.01 | zappaFan | <PROTECTED> |
| 13:32.03 | zappaFan | <PROTECTED> |
| 13:32.58 | zappaFan | this is affecting how the CDR looks and have been trying a couple configs at beronet's side but no luck |
| 13:33.23 | zappaFan | this is my asterisk config: |
| 13:33.28 | zappaFan | [beronetISDN] |
| 13:33.30 | zappaFan | defaultuser=beronetISDN |
| 13:33.31 | zappaFan | secret=beronetISDN |
| 13:33.33 | zappaFan | host=10.7.10.10 ;192.168.4.74 |
| 13:33.35 | zappaFan | type=friend |
| 13:33.36 | zappaFan | context=nivel_beronet |
| 13:33.38 | zappaFan | disallow=all |
| 13:33.39 | zappaFan | allow=alaw |
| 13:33.40 | zappaFan | allow=ulaw |
| 13:33.42 | zappaFan | nat=no |
| 13:33.44 | zappaFan | canreinvite=no |
| 13:33.45 | zappaFan | dtmfmode=rfc2833 |
| 13:33.47 | zappaFan | insecure=port,invite |
| 13:33.47 | WIMPy | You Asterisk config is irrelevant. |
| 13:33.51 | WIMPy | ~pb |
| 13:33.52 | infobot | somebody said pastebin was a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few: http://pastebin.ca, http://channels.debian.net/paste, http://paste.lisp.org, http://bin.cakephp.org/; or install pastebinit with yum or aptitude. |
| 13:33.55 | zappaFan | any ideas? |
| 13:34.15 | WIMPy | Have you checked the Beronet Support channels? |
| 13:34.51 | WIMPy | has always wondered who would buy that product, BTW. |
| 13:35.06 | zappaFan | have checked the documentation, but sucks big time |
| 13:37.11 | WIMPy | Just out of interest: How much more do you pay for the gateway functionality? |
| 13:37.56 | voipmonk | http://wiki.beronet.com/index.php/FAQ#Why_is_my_Callerid_.22berofix.22.2F_or_the_SIP_Authentication_Name_instead_of_the_real_ISDN_Callerid_.3F |
| 13:38.20 | voipmonk | ? Is this what you are looking for? |
| 13:38.24 | zappaFan | I'm actually configuring this for a client, don't know how much is he paying |
| 13:38.38 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 13:39.33 | zappaFan | thanks voipmonk, I've already been there but haven't been able to make it work with what they recommend |
| 13:40.47 | WIMPy | And where do they put the calling *LINE* ID? |
| 13:43.11 | WIMPy | (not that I've ever found out where it's supposed to go on Asterisk :-( ) |
| 13:45.12 | Samot | In what chan_SIP? callerid= |
| 13:46.03 | WIMPy | No, That's the *CALLER* ID. |
| 13:46.47 | WIMPy | And my question is about Asterisk and it's functions, not a specific channel. |
| 13:47.38 | Samot | So you're talking about LIDB dips... |
| 13:48.01 | WIMPy | What? |
| 13:48.06 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 13:48.18 | Samot | Line Informat Database |
| 13:48.22 | Samot | Line Information Database |
| 13:49.07 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:49.27 | WIMPy | No, I talking about Calling *USER* ID vs. Calling *LINE* ID. |
| 13:50.23 | WIMPy | Like if a user sennds a number that doesn't belong to the line he's calling from. |
| 13:51.51 | WIMPy | I would have thought it would be CALLERID(ani), but at least chan_sip disagrees, making that a diversion numner. |
| 13:52.10 | WIMPy | But as nothing much is documented, I have no idea if that's a bug or not. |
| 13:52.54 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 13:53.24 | Samot | For PRI? |
| 13:54.18 | WIMPy | >>And my question is about Asterisk and it's functions, not a specific channel. |
| 13:54.20 | zappaFan | k, so my friend just solved it. on asterisk side we declared it as type peer, specified the IP and on the beronet side, you don't need to register the server or put info of any kind regarding the sip account of the trunk. |
| 13:54.43 | zappaFan | for the callerid you need to select new source and new destination and you're all set |
| 13:55.06 | Samot | PRI is kinda important. |
| 13:55.12 | zappaFan | thanks for those who helped |
| 13:55.18 | Samot | Considering it seems to have it's own callerid variables. |
| 13:55.51 | WIMPy | They come in via SIP as well. |
| 13:55.56 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:56.57 | Samot | I just grab ${CALLERID(name)} and ${CALLERID(num)} when calls come in. |
| 13:58.08 | WIMPy | You're missing half of it then. |
| 13:58.16 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 13:58.31 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 13:58.44 | Samot | What else am I missing? |
| 13:59.13 | WIMPy | The Calling Line ID. |
| 13:59.40 | *** join/#asterisk tsearle (~tsearle@37.19.10.34) |
| 13:59.51 | Samot | Huh? |
| 13:59.59 | tsearle | hello I have a doubt ref call transfer |
| 14:00.17 | Samot | CID and CLID are the same. |
| 14:00.28 | Samot | Caller Line Identification. |
| 14:00.44 | tsearle | pjsip endpoint a calls endpoint b, dial command in context alpha |
| 14:01.08 | WIMPy | No. They are not. I just explained that. |
| 14:01.18 | tsearle | if endpoint B sends a refer, and B has a default context of beta, does the dialplan get invoked in alpha or beta? |
| 14:01.37 | WIMPy | They can be the same. But they don't have to. |
| 14:01.57 | Samot | How are they different? |
| 14:02.23 | Samot | Because if what I've been basing my knowledge on is wrong, I want to correct it. |
| 14:02.34 | WIMPy | >>Like if a user sennds a number that doesn't belong to the line he's calling from. |
| 14:02.57 | Samot | You get the line information for that number. |
| 14:03.03 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 14:03.21 | Samot | If they submitted line information. |
| 14:03.30 | WIMPy | No. It's not specified anywhere for Asterisk. |
| 14:03.54 | Samot | I have no issue changing my caller id to any number I want.. |
| 14:04.13 | Samot | And getting the CLID for that number when I call into Asterisk. |
| 14:04.22 | WIMPy | Most ITSPs send the Calling User ID in the from and the Callig Line ID in the PAI. But Asterisk won't handle that out of the box. |
| 14:04.51 | Samot | Right. |
| 14:05.03 | Samot | I send all caller id to my Asterisk boxes in PAI. |
| 14:05.11 | Samot | No issues. |
| 14:06.04 | Samot | I get a call from 3135551212, that's the number the dip looks up. |
| 14:06.18 | Samot | I don't care if it's actually the calling persons number on their account. |
| 14:06.29 | Samot | Its the number I was presented, so it's the number I look up. |
| 14:08.17 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 14:08.34 | *** join/#asterisk clopez (~tau@neutrino.es) |
| 14:08.59 | Samot | In some cases lookups to different sources for a single DID can return multiple CLID details. |
| 14:09.11 | Samot | Depending on what the LIDB source has in it. |
| 14:09.42 | WIMPy | I don't care about names at this point. |
| 14:10.22 | WIMPy | I just don't want the information lost or mangled. |
| 14:11.20 | WIMPy | Maybe I should just go and modify chan_sip to ensure that. |
| 14:11.42 | *** join/#asterisk gedia (~gd@hq.modulus.gr) |
| 14:11.56 | gedia | hello. I have an asterisk setup and asterisk seems to be ignoring an ACK sent by a NEC PBX device (and it's not a firewall issue). Any ideas where to start? I can't find anything wrong with the packet myself... packet: http://pastebin.com/ZhAVijEW dialog: http://pastebin.com/ZJzkHKWA |
| 14:12.45 | Samot | Garbage. |
| 14:12.55 | gedia | only weird thing is the Via header is in the middle of the packet... Could this be an issue? |
| 14:12.55 | Samot | Show the entire exchange. |
| 14:13.23 | gedia | Samot: was this addressed to me? |
| 14:13.27 | Samot | Yes. |
| 14:13.38 | Samot | One packet isn't going to tell us anything. |
| 14:13.49 | gedia | OK give me some time... thanks |
| 14:13.59 | *** join/#asterisk d00gster (~d00gster@unaffiliated/d00gster) |
| 14:15.14 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 14:16.22 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 14:22.12 | gedia | Samot: here's the entire dialog up to the ACK if you wanna take a look: http://pastebin.com/Qwn6sW2c |
| 14:25.25 | Samot | What is happening? |
| 14:25.42 | Samot | Who is originating the call and at what point during this does the ACK get lost? |
| 14:26.15 | [TK]D-Fender | Show the *-side SIP debug |
| 14:26.51 | Samot | ^^ That too |
| 14:28.04 | gedia | What happens is the call is established but the channel is destroyed after a few seconds, and I'm assuming it's because asterisk either doesn't receive the ACK to the OK it sent, or it rejects it as malformed... |
| 14:28.19 | Samot | Show the SIP debug from Asterisk |
| 14:28.22 | Samot | asterisk -rvv |
| 14:28.25 | Samot | sip set debug on |
| 14:28.30 | Samot | or pjsip set logger on |
| 14:28.38 | Samot | Whichever driver you are using. |
| 14:28.54 | gedia | Is there a way to turn SIP debug for a single endpoint? This asterisk has A LOT of endpoints and about 20 call setups a second right now |
| 14:29.58 | gedia | and it's chan_sip... |
| 14:30.26 | Samot | sip set debug peer <peer number/name> |
| 14:34.21 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
| 14:35.31 | AdNauseum | samot how the hell are you |
| 14:42.10 | *** join/#asterisk tuxian_ (~tuxian@194.12.3.78) |
| 14:42.36 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:42.36 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:46.04 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
| 14:47.15 | *** join/#asterisk kharwell (kharwell@nat/digium/x-jgwqtnjeexgwlfmw) |
| 14:47.15 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:05.38 | *** join/#asterisk sotoz (~textual@095-097-255-066.static.chello.nl) |
| 15:23.27 | Samot | Oh. |
| 15:25.11 | freebs | My |
| 15:26.45 | Samot | Don't you have a network to screw up by installing PFSense? |
| 15:26.51 | freebs | lmao |
| 15:27.11 | freebs | no they are all running beautifully |
| 15:27.26 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 15:31.19 | *** join/#asterisk hyegeek (~hakimian@wsip-72-214-228-246.ph.ph.cox.net) |
| 15:33.10 | Samot | For PFSense that means they are just up. |
| 15:34.30 | freebs | don't be a hater... |
| 15:42.57 | Samot | I'm not. |
| 15:43.03 | Samot | I'm just being 100. |
| 15:43.40 | Samot | Just remember, one day you'll grow up and you'll be able to use a big boy firewall. |
| 15:43.44 | Samot | Just think about that! |
| 15:45.41 | freebs | i've used lots... |
| 15:46.02 | *** join/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
| 15:46.17 | *** join/#asterisk jjrh (~weechat12@2607:f0b0:8:8035:56:c176:3528:e6f9) |
| 15:48.40 | Samot | Just too much to handle still. I get it. |
| 15:50.13 | Samot | It takes time to work up to handling the bigger stuff. |
| 15:50.21 | Samot | Just ask your mom. |
| 15:51.21 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-rndorqlrwjldjmxq) |
| 15:51.21 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 15:53.30 | *** join/#asterisk simplydrew (~simplydre@unaffiliated/simplydrew) |
| 15:58.14 | *** join/#asterisk ntz (~dpecka@opensuse/member/dpecka) |
| 15:58.17 | ntz | hello |
| 16:03.07 | ntz | stupid Q:, I have asterisk build on solaris and linux .... configuration is supposed to be same (& synced on both) but on one (solaris) is running udp/2727 (mgcp thingie which I even don't know with sure what it does) and on linux not but the .conf files are identical |
| 16:03.28 | *** join/#asterisk chendy (~alexc@121.35.208.212) |
| 16:03.48 | ntz | can I somehow know from the asterisk console what is the status of mgcp on linux node where it is not running ? eg is it failed, or didn't it attempt to start entirely ..... |
| 16:04.26 | *** join/#asterisk salviadud (~ralfalfa@189-211-190-134.static.axtel.net) |
| 16:05.00 | *** join/#asterisk ghoti (~paul@hq.experiencepoint.com) |
| 16:06.27 | *** part/#asterisk tsearle (~tsearle@37.19.10.34) |
| 16:06.30 | *** join/#asterisk sotoz (~textual@095-097-255-066.static.chello.nl) |
| 16:06.55 | ntz | at least, in core show applications it is not leasted anywhere |
| 16:07.13 | Samot | MGCP is a protocol.. |
| 16:08.32 | Samot | Kinda like H.323 |
| 16:08.41 | ntz | but I can't see it anywhehre ... core show threads nothing .... core show whatrever nothing |
| 16:08.42 | Samot | You would know if you were actually using it. |
| 16:08.49 | ntz | Samot: surely not |
| 16:09.01 | drmessano | freebs: Don't let him tease you. It's nice being to get a new power supply for your router at Walmart, which I assume is an annual thing when the cheap sleeve fans in chinese ATX power supplies die... |
| 16:09.18 | freebs | hahahaha |
| 16:09.26 | Samot | MGCP is like SIP. |
| 16:09.28 | freebs | oh you guyz! |
| 16:09.36 | Samot | In the fact... |
| 16:09.40 | ntz | Samot: I'd like to know, what it triggers to start on solaris node and why it is not starting on linux node when etc/asterisk were rsynced on both o.O |
| 16:09.40 | Samot | That you choose to use it. |
| 16:10.01 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 16:10.14 | Samot | What are you rsyncing? |
| 16:10.17 | Samot | Just conf files? |
| 16:10.18 | Samot | Data? |
| 16:10.21 | ntz | yep |
| 16:10.26 | ntz | just etc/asterisk |
| 16:10.44 | Samot | I believe MGCP needs to be installed. |
| 16:11.17 | ntz | I have build from same sources here with same build flags and ./configure and make config options |
| 16:11.34 | Samot | Then look at the boxes. |
| 16:11.40 | *** join/#asterisk [sr] (~kvirc@pal-213-228-163-73.netvisao.pt) |
| 16:11.43 | ntz | I did the build for myself .... |
| 16:11.44 | Samot | Does it actually load on the other box? |
| 16:11.49 | [sr] | hi WIMPy |
| 16:11.50 | Samot | Or do you just have .conf files? |
| 16:11.55 | ntz | no, that's what I am saying |
| 16:12.06 | [TK]D-Fender | Are you actually USING MGCP? |
| 16:12.16 | ntz | on solaris node there is mgcp (udp/2727) up and on linux node it is not |
| 16:12.25 | Samot | Do you need it? |
| 16:12.28 | [TK]D-Fender | I only hear of someone who actually has gear that requires it every couple of years |
| 16:12.31 | ntz | Samot: no, I don't |
| 16:12.37 | Samot | Then just disable it. |
| 16:12.40 | ntz | I'm sure |
| 16:12.40 | Samot | On both boxes. |
| 16:12.43 | [TK]D-Fender | then stop loading that channel driver and forget about it |
| 16:13.07 | ntz | well, I'd still like to explicitely know the status of mgcp on linux where it is not loaded |
| 16:13.12 | ntz | is it failed ? |
| 16:13.17 | [TK]D-Fender | huh? |
| 16:13.24 | Samot | Don't care. |
| 16:13.31 | ntz | or on solaris server where it is up, what started it when etc/asterisk is same |
| 16:13.33 | Samot | Don't even know if it's installed properly. |
| 16:13.33 | drmessano | He wants to know why it isn't loaded on the Linux box |
| 16:13.35 | drmessano | Who cares |
| 16:13.40 | drmessano | disable it |
| 16:13.47 | drmessano | Remove it |
| 16:13.52 | [TK]D-Fender | because either you didn't build it, or your modules.conf didn't load it |
| 16:14.03 | [TK]D-Fender | or you were missing a config and the whole module failed to start |
| 16:14.18 | ntz | [TK]D-Fender: isn't here some asterisk console command showing clearly the status of mgcp |
| 16:14.23 | [TK]D-Fender | just noload it an move on with importnat matters |
| 16:14.33 | [TK]D-Fender | ntz, Did you try? |
| 16:14.39 | [TK]D-Fender | mgcp <tab> |
| 16:15.03 | Samot | Why are we trying to figure out what a server isn't loading something that it's not supposed to be using anyways? |
| 16:15.12 | *** join/#asterisk igcewieling (~ewieling@ip98-170-211-145.pn.at.cox.net) |
| 16:15.15 | ntz | doing that .... nope, I was digging it from core* or modules command |
| 16:15.43 | Samot | Shouldn't you be looking at why the Solaris box is loading this when it shouldn't be? |
| 16:15.43 | *** join/#asterisk chendy (~alexc@113.116.62.14) |
| 16:16.25 | ntz | [TK]D-Fender: thanks !!!!! obviously the mgcp support ain't on linux whilst it's on solaris |
| 16:16.30 | ntz | weird |
| 16:16.43 | Samot | Shouldn't you be looking at why the Solaris box is loading this when it shouldn't be? |
| 16:16.50 | ntz | however I wonder why mgcp.conf were generated by make |
| 16:17.15 | ntz | Samot: this is not the issue .... I'll disable it |
| 16:17.22 | drmessano | You told make to generate configs |
| 16:17.35 | Samot | What's the issue? |
| 16:17.43 | ntz | my primary concern was to know, what's up with mgcp in linux where it was not running |
| 16:17.54 | Samot | But you don't use it. |
| 16:17.58 | Samot | It doesn't matter if it's running or not. |
| 16:18.06 | ntz | yeah, I don't even clearly know what it does |
| 16:18.28 | Samot | so why are you worrying about the box that's not loading the module it's not using? |
| 16:18.31 | drmessano | checks for AdNauseums host mask |
| 16:18.36 | Samot | Sounds like it's working right. |
| 16:18.42 | Samot | Shouldn't you be looking at why the Solaris box is loading this when it shouldn't be? |
| 16:18.46 | Samot | ^^^ So I go back to that |
| 16:18.57 | drmessano | Don't do "make samples" |
| 16:19.17 | ntz | Samot: well, I'm kinda pedantic so now, before releasing our builds for our consumers I'd like to disable services that we don't use and that are up by default |
| 16:19.35 | drmessano | mgcp.conf doesn't get magically created |
| 16:20.14 | Samot | 11:09:29 AM S<Samot> MGCP is like SIP. |
| 16:20.22 | Samot | ^^ Like it's a protocol for VoIP. |
| 16:20.32 | Samot | Just like IAX, SCCP, etc. |
| 16:21.20 | [TK]D-Fender | Except far worse. The PBX is expected to be the full call-handling engine for everything |
| 16:21.22 | ntz | http://susepaste.org/view/raw/93415145 |
| 16:21.30 | ntz | ^^ olay, this explains that |
| 16:21.33 | [TK]D-Fender | other protocols are more P2P and intelligent |
| 16:22.25 | Samot | MGCP was like ooo look how this is different that H.323 |
| 16:22.29 | Samot | MGCP was like ooo look how this is different than H.323 |
| 16:22.30 | ntz | we're missing the mgcp support on linux but as far as our primary platform was/is solaris, we've synced (probably) mgcp.conf from solaris to linux and that confused me ..... howevever I'll go now to review the linux built logs because the building is nearly the same |
| 16:22.41 | Samot | You DON'T NEED IT |
| 16:22.47 | Samot | So it's not "missing |
| 16:22.49 | Samot | So it's not "missing" |
| 16:23.25 | ntz | Samot: I WANT MY BUILDS SUPPORTING SAME FEATURES |
| 16:23.30 | ntz | giggles |
| 16:23.36 | Samot | Then disable it on Solaris. |
| 16:23.40 | ntz | yeah |
| 16:23.46 | ntz | all clear, thanks guys for help |
| 16:24.36 | *** join/#asterisk fstd (~fstd@unaffiliated/fisted) |
| 16:24.41 | [TK]D-Fender | DISABLE ON ALL SIDES AND YOU'LL HAVE THE SAME FEATURES |
| 16:24.46 | [TK]D-Fender | #solved |
| 16:24.55 | Samot | ^^^ |
| 16:26.59 | *** join/#asterisk genpaku (~genpaku@107.191.100.185) |
| 16:27.07 | Samot | drmessano: |
| 16:27.43 | drmessano | ? |
| 16:27.45 | Samot | Have you heard about Toll Free LCR? |
| 16:27.58 | drmessano | Nope |
| 16:28.05 | Samot | ThinQ just launched it. |
| 16:28.08 | drmessano | Are they like Indie Rock? |
| 16:28.25 | *** join/#asterisk fstd (~fstd@unaffiliated/fisted) |
| 16:28.38 | Samot | Basically they update the Toll Free LRN to point to one of their RespORG partners.... |
| 16:28.54 | Samot | Allowing you to LCR you inbound Toll Free. |
| 16:29.09 | drmessano | Thats awesome |
| 16:29.10 | WIMPy | o.O |
| 16:29.25 | Samot | I'm about to test it over the next couple weeks. |
| 16:29.57 | Samot | I am concerned about LRN updates on the fly. |
| 16:30.35 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
| 16:31.02 | Samot | It seems you can control the routes and opt for auto route updates.. |
| 16:32.39 | Samot | So I''m hoping it works... |
| 16:32.45 | Samot | Because yeah, that would be awesome. |
| 16:34.21 | Samot | They're saying they can give rates at like $0.007 for TF calls. |
| 16:34.57 | drmessano | Dang |
| 16:34.58 | Samot | They're blended is $0.014 so I'm guessing that would be the "unknown" source cost. |
| 16:35.29 | Samot | Yeah, like I said it would be awesome if it works flawlessly. |
| 16:36.16 | Samot | http://www.thinq.com/toll-free-least-cost-routing/ <--- Check it out |
| 16:37.04 | Samot | Looks like ATT, CenturLink, L3 and Verizon are the carriers. |
| 16:37.20 | *** join/#asterisk fstd (~fstd@unaffiliated/fisted) |
| 16:37.31 | Samot | s/CenturLink/CenturyLink/ |
| 16:41.20 | drmessano | Yeah I saw that |
| 16:42.43 | Samot | So that means ATT, CenturyLink and Verizon will be my choices. |
| 16:47.13 | *** join/#asterisk jjrh (~weechat12@2607:f0b0:8:8035:796f:592e:3a21:a6eb) |
| 16:50.08 | *** join/#asterisk genpaku (~genpaku@107.191.100.185) |
| 16:51.10 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 16:51.37 | ntz | one last question, is it worth to learn how asterisk ACLs work (access to services over tcp/ip) or should I make a iptables/ipfilter (linux/solaris) do a job ? |
| 16:52.58 | ntz | I have to state out, that actually asterisk is doing everything what we need, I'm only trying to brush our deployed servicesw |
| 17:00.59 | *** join/#asterisk libardi (~libardi@189.61.226.79) |
| 17:13.37 | [TK]D-Fender | iptables prevents actual attacks. ACLS still let * communicate with the other side, just includes a built-in restriction list |
| 17:14.20 | [TK]D-Fender | Technically for firewalling (active blocks) vs white-listing or.. kinda either really, it's best to filter at the iptables level first as that eliminates processing load from * entirely |
| 17:16.14 | ntz | fair !!!! |
| 17:16.24 | ntz | understood and taking that |
| 17:17.21 | *** join/#asterisk tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 17:29.25 | *** part/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
| 17:33.43 | *** join/#asterisk igcewieling (~ewieling@162-236-85-155.lightspeed.moblal.sbcglobal.net) |
| 17:49.06 | igcewieling | hugs his backup internet connection |
| 17:50.44 | *** join/#asterisk friedrich (~friedrich@aextron.de) |
| 18:18.45 | *** join/#asterisk fstd (~fstd@unaffiliated/fisted) |
| 18:33.22 | *** join/#asterisk freebs (~freebs@unaffiliated/freebs) |
| 18:36.56 | *** join/#asterisk bof22 (~Thunderbi@ARennes-650-1-8-74.w90-32.abo.wanadoo.fr) |
| 18:42.07 | *** join/#asterisk vince1 (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 18:46.25 | *** join/#asterisk jeffspeff (~Jeff@12.49.160.131) |
| 18:46.27 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 18:48.09 | *** join/#asterisk vstemen (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 18:48.34 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 18:49.34 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 18:50.48 | *** join/#asterisk Shred00 (~brian@pc.interlinx.bc.ca) |
| 18:51.52 | Shred00 | there seem to be any number of "caller-id reputation" websites out there now, such as http://callername.com, etc. i wonder if anyone has written a bad-reputation-call-blocker mechanism for asterisk using one of these websites. |
| 19:00.20 | *** join/#asterisk vstemen (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 19:03.11 | *** join/#asterisk BlackMaria (~BlackMari@dsl.198.58.156.210.ebox.ca) |
| 19:07.24 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
| 19:15.58 | *** join/#asterisk vstemen (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 19:26.29 | *** join/#asterisk vince1 (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 19:28.07 | *** join/#asterisk thiagoc_ (~thiagoc@unaffiliated/thiagoc) |
| 19:36.05 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
| 19:38.00 | *** join/#asterisk acmd (~acaron@mx.md.bonnyville.ab.ca) |
| 19:39.55 | acmd | ello, looking for help if anyone is available, haivng issues with multicast paging |
| 19:44.20 | *** join/#asterisk vstemen (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 19:46.37 | gedia | OK I think I found the issue. An ACK to a 200 OK should contain the same branch= parametre as the original INVITE, right? |
| 19:56.42 | *** join/#asterisk vstemen (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 19:58.17 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 20:13.37 | *** join/#asterisk camerin (hoax@elite.bshellz.net) |
| 20:14.11 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 20:21.24 | *** join/#asterisk vince1 (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 20:34.49 | igcewieling | gedia: sounds like you might have a router running SIP ALG |
| 20:36.42 | *** join/#asterisk Nugget (~nugget@mezger.macnugget.org) |
| 20:37.52 | *** join/#asterisk vince1 (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 20:40.34 | *** join/#asterisk ghost75 (~quassel@p200300C783C20C00505400FFFE6A8831.dip0.t-ipconnect.de) |
| 20:41.04 | ghost75 | if session-timers=refuse is set, will session-expires parameter still be used? |
| 20:51.47 | *** join/#asterisk genpaku (~genpaku@107.191.100.185) |
| 20:52.55 | *** join/#asterisk jathan (~jathan@arcmty01.izabc.com) |
| 20:52.56 | *** join/#asterisk vince1 (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 20:56.35 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 20:58.39 | *** join/#asterisk vstemen (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 20:59.08 | *** part/#asterisk kharwell (kharwell@nat/digium/x-jgwqtnjeexgwlfmw) |
| 21:01.01 | *** join/#asterisk Milos_ (~Milos@pdpc/supporter/student/milos) |
| 21:03.34 | gedia | igcewieling: Hmm, seems unlikely since I get private IPs in the packets... |
| 21:03.43 | gedia | Samot: are you still here? |
| 21:04.11 | gedia | igcewieling: Plus, I now noticed asterisk itself will use a new branch for an ACK to a 2xx... so it must be something else... |
| 21:04.30 | Samot | ? |
| 21:04.42 | gedia | Anyway I've uploaded the entire log with sip debug on to http://pastebin.com/5VbV4v6P if anyone could take a look |
| 21:05.00 | gedia | Problem is, asterisk ignores ACKs and OKs from a NEC PBX device... |
| 21:05.21 | gedia | Samot: I finally managed to gather some logs, and filter out the noise (I think) |
| 21:05.27 | jathan | Hi everyone. I have enabled the TLS connection for Asterisk but service cannot start because the next error: |
| 21:05.39 | jathan | --- == TLS/SSL ECDH initialized (secp256r1), faster PFS cipher-suites enabled == TLS/SSL certificate ok[Feb 24 15:04:10] ERROR[1119]: tcptls.c:637 handle_tcptls_connection: Problem setting up ssl connection: error:00000000:lib(0):func(0):reason(0)[Feb 24 15:04:10] WARNING[1119]: tcptls.c:723 handle_tcptls_connection: FILE * open failed! |
| 21:06.19 | gedia | I can't figure out why asterisk is ignoring the ACKs and keeps retransmitting. It has hundreds of endpoints and only this one is exhibiting this behaviour...+ |
| 21:07.08 | jathan | I have searched how to solve this problem: http://forums.asterisk.org/viewtopic.php?p=208885, https://community.freepbx.org/t/problem-setting-up-ssl-connection-error-00000000-lib-0-func-0-reason-0/37900 |
| 21:07.56 | jathan | But it is not working. Could someone help me please? |
| 21:17.05 | josecapurro | jathan: are the certificate file permissions OK? Can those be readable by Asterisk? |
| 21:18.13 | josecapurro | jathan: *Are those readable by Asterisk? |
| 21:20.56 | *** join/#asterisk vince1 (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 21:27.37 | Samot | gedia: You have it backwards. |
| 21:29.21 | gedia | Samot: right, I figured that later, I was misled by a post at stackoverflow |
| 21:29.25 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 21:29.42 | gedia | Samot: did you have the time to check the log? anything suspicious? |
| 21:29.42 | Samot | The NEC isn't responding to the 401 challenge properly |
| 21:30.25 | gedia | Samot: If you're looking at the second invite, it's a retransmission. The third invite is the one with the authentication... |
| 21:30.30 | Samot | Asterisk isn't ignoring anything. |
| 21:30.34 | Samot | That's not how it works. |
| 21:30.45 | Samot | You're sending an INVITE |
| 21:30.53 | Samot | Asterisk is sending back a 401 Challenege. |
| 21:30.55 | Samot | Asterisk is sending back a 401 Challenge. |
| 21:30.58 | gedia | right... |
| 21:31.11 | Samot | You should be sending the INVITE again |
| 21:31.15 | Samot | With AUTH details. |
| 21:31.18 | Samot | Which you are not. |
| 21:31.27 | Samot | You are resending the original INVITE |
| 21:31.42 | gedia | It does... further down... With CSeq: 2 |
| 21:32.44 | gedia | line 136 |
| 21:33.08 | Samot | This is so redacted it's not worth reading. |
| 21:33.36 | Samot | This is a network issue. |
| 21:33.51 | Samot | And you've cleared out all the network related stuff. |
| 21:34.44 | Samot | If Asterisk is re-transmitting packets to the NEC it means it didn't get a reply from the NEC for the original packet. |
| 21:35.18 | Samot | Maybe it never got to the NEC. Maybe the NEC sent it back to the wrong place. |
| 21:35.38 | gedia | well, everything has been substituted consistently. in fact I think it's easier to understand this way.... NN.NN.NN.NN is the IP NEC appears to be coming from after NAT, AA.AA.AA.AA is asterisk's IP, 192.168.254.160 is NEC's private IP etc |
| 21:36.05 | Samot | So the NEC and the PBX are not local? |
| 21:36.20 | gedia | of course not, it's over the internet |
| 21:36.42 | Samot | I'm not going to assume you're boxes are not local to each other. |
| 21:36.46 | Samot | You have to explain that crap. |
| 21:36.51 | gedia | why would I censor the public IPs if they all were private? |
| 21:37.43 | Samot | Contact: <sip:nec-username@192.168.254.160:5060> |
| 21:37.49 | *** join/#asterisk Dovid (~dovid@ool-3f8fe4fa.dyn.optonline.net) |
| 21:37.53 | Samot | o=- 0 0 IN IP4 192.168.254.160 |
| 21:38.00 | Samot | c=IN IP4 192.168.254.152 |
| 21:38.17 | gedia | now we're talking :-P what sort of crap is that? |
| 21:38.23 | Samot | Everything the NEC is sending has the private IP in the areas it should have the public IP |
| 21:38.50 | Samot | See it makes a different to know if that is supposed to be there or not. |
| 21:38.56 | Samot | Locally, it's fine. |
| 21:39.05 | Samot | Remote, completely wrong. |
| 21:39.16 | Samot | Fix how the NEC is sending it's messages and NAT |
| 21:39.21 | gedia | Well, it doesn't know what its public IP is, since it's behind NAT and the public IP is dynamically assigned by the ISP.... if you watch more closely, asterisk performs nat traversal.... |
| 21:39.43 | Samot | Your SDP has the wrong information. |
| 21:39.49 | Samot | Your contact header has the wrong information. |
| 21:39.51 | hyegeek | Samot, we had a NEC phone system years ago and spent weeks proving to NEC that their phones were doing it wrong. The final result from NEC? We're not going to fix it. |
| 21:41.21 | Samot | The only public IP being used for the NEC in all of this is that it's the source IP of the message. |
| 21:41.37 | Samot | The message itself says the phone is all private IPs which is not good. |
| 21:42.26 | gedia | Again, NAT traversal... This asterisk has about 1500 endpoints and all include their private IP in the header field... |
| 21:42.43 | Samot | OK, it's a NAT issue then |
| 21:43.15 | Samot | The SIP message has private IPs in it. |
| 21:43.28 | Samot | Asterisk doesn't fix that crap |
| 21:43.44 | Samot | It doesn't assume the source IP is the actual IP of where the phone is. |
| 21:44.30 | Samot | That message could go through 3 hops and the last hop is differently not the location of the phone. |
| 21:44.37 | gedia | well, maybe I didn't make myself clear. asterisk transmits to NN.NN.NN.NN which is the public IP: <--- Transmitting (NAT) to NN.NN.NN.NN:5060 ---> |
| 21:44.47 | Samot | That's the SOURCE |
| 21:44.55 | Samot | That has no bearing on the ACTUAL device. |
| 21:45.05 | igcewieling | heh, hackers are learning "User-Agent: Cisco-SIPGateway/IOS-12.x" |
| 21:45.10 | Samot | All my devices go through an SBC |
| 21:45.17 | Samot | The source of the message is always the SBC IP |
| 21:45.34 | Samot | It's NOT the device IP. |
| 21:45.40 | Samot | That's in the SIP message which Asterisk uses. |
| 21:45.41 | gedia | it's not a NAT issue.... did I not mention that the call works fine (with bidirectional audio) before the channel is killed by asterisk a few seconds later? |
| 21:45.48 | Samot | OK. |
| 21:46.00 | Samot | The messages are being lost |
| 21:46.02 | drmessano | Sounds like a re-invite |
| 21:46.05 | Samot | Asterisk isn't getting replies. |
| 21:46.08 | Samot | It could be that |
| 21:47.03 | gedia | That's not the device IP. The NEC doesn't have any IP endpoints, all are either propriatary or analogue... and even if it were, those devices operate as B2BUAs, they don't expose the internal telephony network to their peers... |
| 21:47.15 | Samot | device = endpoint |
| 21:47.19 | Samot | It doesn't matter what that endpoint is |
| 21:47.22 | Samot | Phone, ATA, PBX |
| 21:47.24 | gedia | Well it is getting them, they are in the logs. one ACK for each 200 OK. I've counted them |
| 21:48.13 | Samot | How many seconds does a call stay up, MAX? |
| 21:48.18 | drmessano | Do you have directmedia=no for that peer? |
| 21:49.49 | Samot | Is Asterisk behind NAT? |
| 21:50.08 | gedia | drmessano: nope |
| 21:50.19 | gedia | Samot: no, asterisk listens to public IP |
| 21:50.45 | drmessano | gedia: You need to set it |
| 21:50.47 | Samot | Is the endpoint connected to Asterisk behind NAT? |
| 21:50.58 | Samot | Because yea, directmedia should be no |
| 21:52.08 | Samot | Where is this call going? Out to the PSTN via a provider or another endpoint on Asterisk? |
| 21:52.29 | gedia | out to the PSTN via SIP peer |
| 21:53.03 | Samot | Go set directmedia=no |
| 21:53.13 | Samot | On those peers. |
| 21:54.01 | gedia | I already said it's set to no |
| 21:54.34 | drmessano | You said "nope" |
| 21:54.57 | Samot | 4:48:21 PMÂ <drmessano>Â Do you have directmedia=no for that peer? |
| 21:55.03 | Samot | 4:50:12 PMÂ <gedia>Â drmessano: nope |
| 21:55.05 | drmessano | So which is it? |
| 21:55.48 | gedia | Sorry, I mean yes, it's set to no... |
| 21:56.13 | gedia | as in "DirectMedia : No" is what I get when I do sip show peer nec-username |
| 21:56.34 | Samot | How many seconds does a call stay up, MAX? |
| 21:56.34 | gedia | I really don't know why I said that :-D |
| 21:57.11 | gedia | Well asterisk is nice enough to calculate it for me: Packet timed out after 28544ms with no response |
| 21:57.22 | Samot | You said the calls work.. |
| 21:57.25 | Samot | For a period of time |
| 21:57.30 | Samot | How long is that period of time? |
| 21:57.40 | Samot | That you have your bi-directional audio? |
| 21:58.47 | gedia | I can't really say because I don't have physical access to the NEC... about 25 seconds if I had to guess from the logs... |
| 21:59.12 | Samot | What do the people using the NEC say? |
| 21:59.20 | Samot | Have you made a test call through the NEC? |
| 21:59.53 | *** join/#asterisk Milos (~Milos@pdpc/supporter/student/milos) |
| 22:00.23 | Samot | How do you know you have bi-directional audio? |
| 22:00.25 | gedia | the entire log I posted is a test call through the NEC, I was on the phone with one of the people using it, telling them to make a test call and wait until it was prematurely terminated... |
| 22:00.35 | Samot | Where did they call?! |
| 22:00.37 | Samot | You? |
| 22:00.38 | gedia | because I was on the phone with the person making the call |
| 22:00.43 | gedia | No. Their mobile... |
| 22:00.57 | Samot | So they called from their desk phone to their mobile.. |
| 22:01.03 | gedia | yes... |
| 22:01.04 | Samot | And they told you they could hear themselves?! |
| 22:01.08 | gedia | yes... |
| 22:01.11 | Samot | Dear god |
| 22:01.20 | Samot | That's a faulty test. |
| 22:01.24 | Samot | You should be involved in that |
| 22:01.30 | Samot | Did you record the audio on Asterisk? |
| 22:01.37 | Samot | Capture it at all to VERIFY? |
| 22:02.02 | gedia | I'm not driving 10 km from here to fix their broken NEC... I've already spent a lot of time trying to help them out... |
| 22:02.15 | Samot | You could have captured that call on the Asterisk server. |
| 22:02.23 | Samot | Validated that audio was happening |
| 22:02.27 | Samot | Had them call your mobile. |
| 22:02.37 | gedia | No, it don't have a process in place to do that, there are regulatory restrictions... |
| 22:02.40 | Samot | Anything that would have let YOU verify there was actually audio. |
| 22:02.52 | Samot | They could have called you |
| 22:02.54 | Samot | Simple. |
| 22:03.19 | gedia | well you're right with this one... I was just convinced it would be something obvious, I didn't expect this... |
| 22:03.20 | Samot | 28-30s drop after a call is connected.... |
| 22:03.25 | Samot | ^^ drmessano |
| 22:03.32 | Samot | Obvious reasons? |
| 22:03.42 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 22:03.42 | Samot | NAT. |
| 22:04.04 | Samot | That's pretty much the default RTP time out. |
| 22:04.09 | Samot | Or close to it. |
| 22:04.49 | gedia | no the real question here is why asterisk retransmits when it has received a perfectly good ACK. |
| 22:04.51 | Samot | It could be their firewall/router. |
| 22:05.47 | Samot | X-Asterisk-HangupCause: No user responding |
| 22:05.49 | Samot | ^^^^^^ |
| 22:08.50 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 22:11.22 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 22:19.19 | *** join/#asterisk tripleslash (~triplesla@unaffiliated/imsaguy) |
| 22:21.29 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 22:22.04 | *** join/#asterisk vstemen (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 22:32.08 | drmessano | 30s = NAT |
| 22:39.57 | Samot | Yeah. |
| 22:40.27 | Samot | The initial INVITE gets a 401 and it responses back TWO more times with the same INVITE which asterisk drops. |
| 22:40.40 | Samot | Then it finally sends the INVITE with the auth. |
| 22:41.28 | Samot | There's no immediate reply to the 200 OK Asterisk sends showing the call answer.. |
| 22:41.46 | Samot | So Asterisk had to re-transmit that message again. |
| 22:42.25 | Samot | gedia: I know what is happening. |
| 22:42.43 | Samot | gedia: The reasons your ACKs are being ignored is because they are to messages that already timed out. |
| 22:43.18 | Samot | Asterisk is sending you a message, waiting 2 seconds and sending it again. |
| 22:43.33 | Samot | The NEC is getting the message, replying but it takes longer than 2 seconds... |
| 22:44.30 | Samot | gedia: This is where the people with the NEC need to look at their network. |
| 22:44.35 | Samot | Because this is a NAT issue. |
| 22:46.28 | jathan | josecapurro: Thanks a lot. They have 600 priveleges on root. |
| 23:02.17 | Samot | Well apparently he didn't really want the answer to his question. |
| 23:03.27 | *** join/#asterisk GameGamer43 (sid5533@gateway/web/irccloud.com/x-ilklnkfcingwytdv) |
| 23:05.40 | *** join/#asterisk ddickenson (sid179041@gateway/web/irccloud.com/x-mlzlypylyimdrtjg) |
| 23:09.34 | *** join/#asterisk dan_j (sid21651@gateway/web/irccloud.com/x-lhuwiahfldgdkfqe) |
| 23:12.45 | *** join/#asterisk vince1 (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 23:30.53 | *** join/#asterisk Chotaire (chotaire@oahu.chotaire.net) |
| 23:35.12 | *** join/#asterisk kunwon1 (~kunwon1@unaffiliated/kunwon1) |
| 23:40.25 | *** join/#asterisk corretico (~corretico@186.96.84.175) |
| 23:46.43 | *** join/#asterisk chris349 (~office@104-12-70-21.lightspeed.miamfl.sbcglobal.net) |
| 23:46.54 | chris349 | Is it worth using PJSIP instead of chan_sip? |
| 23:48.23 | chris349 | I got the registration timeout issue fixed, but now what happens is my router goes down and when it comes back up inbound calls are rejected with a no matching endpoint found error... I restart asterisk and it starts to work again |
| 23:51.46 | Samot | Are you using PJSIP now? |
| 23:52.01 | chris349 | Yes and it seems to be unreliable |