00:42.08 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
00:55.29 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
01:29.12 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
01:40.36 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
02:12.23 | *** join/#asterisk ih8wndz (jwpierce3@001.srv.trnkmstr.com) |
03:32.52 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
03:41.23 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
04:05.56 | *** join/#asterisk javi404 (~quassel@unaffiliated/javi404) |
04:25.51 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
04:26.48 | *** join/#asterisk tm1000 (sid6728@gateway/web/irccloud.com/x-cuqhedcsotyffzcd) |
04:26.48 | *** mode/#asterisk [+o tm1000] by ChanServ |
04:49.56 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
05:19.19 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
05:29.34 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
06:04.41 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
06:28.33 | *** join/#asterisk [sID] (~sid@185.238.74.101) |
06:32.17 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
06:36.12 | *** join/#asterisk ircarcs (~quassel@169.9.159.77.rev.sfr.net) |
06:45.04 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
06:56.34 | *** join/#asterisk rpifan (~rpifan@dslb-188-103-076-226.188.103.pools.vodafone-ip.de) |
07:18.53 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
07:27.24 | *** join/#asterisk jkroon (~jkroon@165.16.203.52) |
07:42.24 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
07:43.54 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
08:28.15 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@176.98.158.240) |
08:39.56 | *** join/#asterisk miralin (~Thunderbi@81.177.58.137) |
08:59.42 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
09:30.11 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
09:33.55 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
09:42.19 | *** join/#asterisk Downlots (~Downlots@185.73.41.1) |
10:10.57 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
10:12.37 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
10:20.26 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
10:36.51 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
11:07.45 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
11:19.07 | *** join/#asterisk jkroon (~jkroon@165.16.203.52) |
11:23.07 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
11:23.25 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
11:23.27 | *** join/#asterisk jkroon (~jkroon@165.16.203.52) |
11:28.07 | *** join/#asterisk jkroon (~jkroon@165.16.203.52) |
11:28.56 | *** join/#asterisk stevedav_ (~stevedavi@197.155.252.3) |
11:40.10 | *** join/#asterisk jkroon (~jkroon@165.16.203.52) |
11:59.27 | sibiria | what's g.722 support like on the US PSTN? |
11:59.53 | sibiria | one major voip provider here in europe has had g.722 PSTN in beta for about a year or so, with support across several cellular operators |
12:00.13 | sibiria | (support still spotty, though) |
12:35.26 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
12:44.15 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
12:45.49 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
13:18.31 | *** join/#asterisk jkroon (~jkroon@165.16.203.52) |
13:31.56 | *** join/#asterisk andrebarbosa (uid341412@gateway/web/irccloud.com/x-laecbbawozlpdomm) |
13:34.23 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
13:38.04 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
13:40.17 | *** join/#asterisk scgm11_ (~scgm11@r186-50-111-53.dialup.adsl.anteldata.net.uy) |
13:52.25 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
13:52.25 | *** mode/#asterisk [+o cresl1n] by ChanServ |
14:03.25 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-nifhmxnyataceruz) |
14:19.07 | *** join/#asterisk scgm11_ (~scgm11@r186-50-111-53.dialup.adsl.anteldata.net.uy) |
14:23.00 | *** join/#asterisk scgm11__ (~scgm11@r186-50-111-53.dialup.adsl.anteldata.net.uy) |
14:28.56 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-lbmluthczrlrlqlg) |
14:28.56 | *** mode/#asterisk [+o bford] by ChanServ |
14:47.11 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
14:48.18 | *** join/#asterisk scgm11_ (~scgm11@r186-50-111-53.dialup.adsl.anteldata.net.uy) |
14:50.57 | sibiria | will pjsip always show a floating point value with three-digit fraction for latency even when the fraction happens to be exactly 0? |
14:51.37 | sibiria | (for pjsip show contacts/endpoints) |
14:51.42 | file | probably |
14:54.44 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-bvregujezsjozqiy) |
14:54.44 | *** mode/#asterisk [+o rmudgett] by ChanServ |
14:54.50 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
14:58.47 | *** join/#asterisk degenerate (~degenerat@S0106cc2de0099182.no.shawcable.net) |
14:59.38 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
15:02.05 | *** join/#asterisk scgm11_ (~scgm11@r186-50-111-53.dialup.adsl.anteldata.net.uy) |
15:03.24 | wonderworld | i have a problem with an ISDN PTMP line attached to asterisk with libpri/DAHDI. when both B-channels are in calls and a third call comes in on the D-channel, libpri signals CAUSE 34 (No circuit/channel available. ). this doesn't produce the expected BUSY tone signal for the caller with many telcos. i need to send out CAUSE 17 (BUSY). is this possible to configure this from asterisk side or do i have to recompile libpri? |
15:03.46 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
15:34.34 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
15:34.54 | *** join/#asterisk kuku (~kuku@d47-69-128-28.col.wideopenwest.com) |
15:35.45 | kuku | What is the current best program for windows to do screen pops with windows ( ideally it would pass the unique callid to a url ) ? |
15:36.22 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
15:40.37 | Samot | ? |
15:41.08 | Samot | Windows as in the OS Windows? Or windows as in a browser window? |
15:52.06 | *** join/#asterisk WizJin (~WizJin@150.129.106.234) |
15:59.52 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
16:03.57 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
16:05.56 | *** join/#asterisk Guest9103 (b92009fa@gateway/web/freenode/ip.185.32.9.250) |
16:12.10 | *** join/#asterisk rpifan (~rpifan@dslb-188-103-076-226.188.103.pools.vodafone-ip.de) |
16:12.37 | Guest9103 | Ok so how would I go with this: I have two trunks where one is connected on the LAN dedicated and one is external. The external is sending the SIP Contact and SDP address as an internal address causing a range of issues. |
16:12.54 | Guest9103 | When I set the externip, it works, but the internal trunk fails because it started using an external IP for a LAN connection. |
16:13.26 | Guest9103 | Setting the fromdomain on the trunk does not update the contact header address, of course. I do not know how to tackle this |
16:13.53 | Guest9103 | Can I set the externip as a trunk setting? |
16:14.49 | [TK]D-Fender | fromdomain has nothing to do with contact header |
16:14.50 | seanbright | appropriate localnet settings should stop the replacements from occuring |
16:14.55 | [TK]D-Fender | ^ |
16:15.11 | seanbright | localnet=192.168.10.0/24 |
16:15.15 | seanbright | or whatever your local network is |
16:15.25 | seanbright | and you can specify that multiple times to cover multiple ranges |
16:16.12 | Guest9103 | Should I still set an externip? |
16:16.20 | Guest9103 | or just go with the locals? |
16:16.30 | seanbright | you would still set the externip |
16:16.54 | Guest9103 | Ok, one last question. If the trunk is 192.168.1.1 but the asterisk has the interface on 192.168.2.1, which network shall I cover in the localnet? |
16:17.01 | Guest9103 | My interface or the destination trunk's net? |
16:17.03 | seanbright | chan_sip will look at the address you are sending traffic to. if it is covered by the "localnet" settings, it won't massage the headers and SDP |
16:17.21 | seanbright | if it is not covered by the localnet settings, it will substitute where appropriate |
16:18.03 | seanbright | 192.168.1.1 is not an externally routable IP, so i don't know what we're talking about |
16:18.14 | Guest9103 | the LAN trunk |
16:18.32 | seanbright | why does the lan one matter? |
16:18.43 | Guest9103 | Hold on, will produce a pastebin |
16:18.46 | seanbright | ok, let me put it another way |
16:19.05 | seanbright | well, no, i already put it the right way |
16:19.21 | seanbright | localnet should define your local network (where you don't want manipulation of header/SDP to occur) |
16:19.30 | seanbright | localnet is short for "local net" |
16:19.36 | seanbright | or "local network" |
16:19.46 | Guest9103 | Ok, basically I set the localnet for the LAN trunk. Then the externip wont interphere with the signaling on that one? |
16:19.57 | seanbright | you set the localnet for the local network |
16:20.29 | Guest9103 | The thing is I have two local NICs, where one of them is sending traffic towards the external sip trunk. That is the one I need externip to modify the headers on. |
16:20.51 | [TK]D-Fender | So define both localnets |
16:21.15 | *** part/#asterisk andrebarbosa (uid341412@gateway/web/irccloud.com/x-laecbbawozlpdomm) |
16:21.17 | seanbright | if asterisk is sending to an IP that is not covered by localnet, it will translate |
16:21.24 | seanbright | assuming externip is also set |
16:21.36 | Guest9103 | Ok, check! |
16:23.19 | Guest9103 | That makes sense, so basically if a NIC is not covered by the localnet setting, it will apply translation with externip in regard |
16:24.03 | seanbright | NIC is not relevant |
16:24.07 | seanbright | but otherwise, sure |
16:24.44 | seanbright | replace "NIC" with "address" and then your statement would be correct |
16:25.29 | Corydon76 | Yeah, don't think about your local address, but the remote address. |
16:25.45 | wonderworld | I have a problem with an ISDN PTMP line attached to asterisk with libpri/DAHDI. When both B-channels are in use and a third call comes in on the D-channel, libpri signals CAUSE 34 (No circuit/channel available. ). This doesn't produce the expected BUSY tone signal for the caller with many telcos. I need to send out CAUSE 17 (BUSY). is it possible to configure this from an asterisk config file or do i have to recompile |
16:25.46 | wonderworld | libpri? |
16:26.00 | Guest9103 | seanbright: thanks anyway. It works great. |
16:26.08 | seanbright | anyway? ok |
16:26.10 | seanbright | no problem |
16:28.46 | *** join/#asterisk Hoops (~Hoops@ppp-199-167-117-19.storm.ca) |
16:31.01 | Guest9103 | hehe, I tend to use "anyway" here and there. You can blame me for that. I am much grateful for the help. |
16:34.23 | Guest9103 | Now out of curiosity. What if one have two addresses with an external destination, how would one sort that? |
16:34.42 | Guest9103 | In that case you'd need an external IP for each trunk. Some kind of border controller/proxy you say? |
16:35.01 | seanbright | externip is YOUR external IP |
16:35.17 | Guest9103 | Sure, but I have two externip's on server X. |
16:35.26 | seanbright | if you have multiple external IPs, yes, you would need something between asterisk (proxy, sbc, whatever) and the internet |
16:36.06 | seanbright | you might be able to do something with chan_pjsip if you are multihomed, but i dunno |
16:36.10 | seanbright | with chan_sip i doubt it |
16:36.12 | Guest9103 | But I can have how many local IPs as I want, due to localnet. |
16:37.04 | seanbright | i don't think that i understand your configuration |
16:37.13 | seanbright | and i don't want to spend any more time trying to understand it |
16:38.29 | seanbright | 99% of people have an asterisk server and 10 phones on an internal network (192.168.10.0/24). asterisk has an internal IP (192.168.10.10), a WAN IP (1.1.1.1) and an ITSP IP (2.2.2.2) |
16:38.33 | seanbright | externip=1.1.1.1 |
16:38.39 | seanbright | localnet=192.168.10.0/24 |
16:38.40 | Guest9103 | Good good. This is just a theoretical setup now, the last one. As I said: out of curiosity |
16:38.49 | seanbright | and you're done |
16:39.41 | seanbright | and now i'm going away. byeeeeeeeeeeeeeEE. |
16:40.37 | Guest9103 | byeeeeeeeeeeeeeEE |
16:40.47 | sibiria | don't leave us. stay a while, stay forever |
16:44.03 | Samot | Guest9103: What is the issue here? If the one peer is over a LAN and the other is over a WAN, then you add that LAN to your local network setttings. |
16:44.25 | Samot | So when it uses that peer, it considers it local and won't use your external IP details. |
16:45.18 | Guest9103 | No issue, the issue is solved! |
16:48.22 | kuku | @Samot - windows as in desktop application is needed for Windows OS ( regardless if browser window is open ) |
16:48.50 | Samot | kuku: what about Mac's? |
16:48.55 | Samot | Don't care about those? |
16:49.14 | Samot | What you are describing are subscription services. |
16:49.34 | Samot | You want something like YouTube or other Social media sites...right? |
16:51.14 | kuku | If a user picks up a phone - I want a screen pop with the customer info on the screen |
16:51.27 | kuku | ( opening up a url with a parameter of the caller id or the unique call id |
16:52.24 | Samot | OK but it shouldn't matter if they have a browser open, right? |
16:52.29 | Samot | That's what I'm getting at. |
16:54.36 | Samot | Triggering the notice from Asterisk is the easy part. |
16:54.47 | Samot | The hard part is the listening side that is getting the notice. |
16:57.32 | Samot | So to do what you want, have a notification alert pop up even with the browser closed is still going to require a subscription service. |
16:57.52 | Samot | Allowing the browser to subscribe to the evens and run something in the background to listen. |
16:59.30 | *** join/#asterisk ivaat (~taavi@unaffiliated/ivaat) |
16:59.33 | Samot | This is generally why things like FOP2 or other CRM/Queue Agent software has them logged into a browser or an app for this stuff. So when it's opened and running, so is the event listener for these events and can act on it. |
16:59.47 | ivaat | hi |
17:10.12 | *** join/#asterisk TandyUK (~admin@TandyUK/staff/James) |
17:13.26 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
17:18.34 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
17:21.40 | ivaat | has anyone done load balancing with asterisk? |
17:25.37 | *** join/#asterisk miralin (~Thunderbi@81.177.58.137) |
17:31.55 | Samot | Alone? No. Not possible. |
17:32.05 | Samot | With a SIP proxy before them, sure. |
17:32.08 | Samot | Common thing. |
17:36.27 | ivaat | Samot: whats the common software used for sip proxy? |
17:36.57 | Samot | Kamailio, OpenSIPs are popular FOSS ones. |
17:38.16 | ivaat | thank you |
17:38.36 | ivaat | but ever thnked to use nginx for example? it does support udp |
17:51.20 | Samot | No. Don't confuse a _web_ load balancer with a _sip_ load balancer. |
17:51.30 | Samot | It's more than just supporting UDP. |
17:53.28 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
18:04.21 | ivaat | well nginx in terms of load balancing is not just web load balancer :) |
18:04.27 | ivaat | but ok.. i have to read about |
18:04.38 | ivaat | thanks |
18:04.38 | seanbright | a sip proxy does a lot more than forward udp packets |
18:05.00 | file | SIP as a protocol also embeds lots of details about routing within itself |
18:12.43 | Samot | ^^ |
18:12.52 | seanbright | >> |
18:13.06 | Samot | nginx isn't going to have the various options for balancing SIP requests. |
18:20.29 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
18:32.46 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
19:03.19 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
19:10.32 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
19:14.21 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
19:18.01 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
19:23.11 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
19:33.48 | *** join/#asterisk gugaua (~gugaua@unaffiliated/gugaua) |
19:34.37 | *** join/#asterisk jkroon (~jkroon@165.16.203.106) |
19:38.00 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
19:39.17 | *** join/#asterisk scgm11__ (~scgm11@r186-50-111-53.dialup.adsl.anteldata.net.uy) |
19:43.40 | *** join/#asterisk pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
19:47.45 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
19:48.54 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
20:11.09 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
20:20.27 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
20:51.58 | wonderworld | I have a problem with an ISDN PTMP line attached to asterisk with libpri/DAHDI. When both B-channels are in use and a third call comes in on the D-channel, libpri signals CAUSE 34 (No circuit/channel available. This doesn't produce the expected BUSY tone signal for the caller with many telcos. I need to send out CAUSE 17 (BUSY). is it possible to configure this from an asterisk config file or do i have to patch sources? |
20:53.17 | seanbright | wonderworld: 3rd time's a charm |
21:05.07 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
21:11.00 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
21:11.36 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
21:11.37 | wonderworld | seanbright: sorry if it was too spammy, but i have been googling for 2 days now and can't find a solution. this chan is my only hope. |
21:12.20 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
21:13.39 | wonderworld | this is a telephone system where many old people call in in need for assistance. because code 34 is returned they hear announcements from the telco like "this line is out of service" |
21:20.39 | Reinhilde | seanbright: you wouldn't perchance have the experience to tell me what I could be doing wrong if loading chan_sip causes asterisk to hang? |
21:20.39 | Samot | wonderworld: The problem is, 34 is correct. |
21:21.22 | Samot | There are no channels left, how would it return a state if there is no channel to check a state for? |
21:21.25 | Reinhilde | wonderworld: call your old people and tell them an out of service line just means you've run out of phones |
21:21.35 | Reinhilde | Samot: It gets a call on the D channel |
21:21.55 | wonderworld | i know, but it's terrible for the users and every telco implements it differntly |
21:22.02 | Samot | But if there are only 2 B channels and they are in use.. |
21:22.03 | wonderworld | some callers hear an anouncement |
21:22.08 | wonderworld | some callers hear nothing |
21:22.09 | Samot | That means there are ZERO channels left. |
21:22.23 | Reinhilde | Samot: it still sees the call, it just doesn't get to answer it unless it hangs up one of the B |
21:22.26 | Samot | Therefore Asterisk doesn't care about BUSY/NOANSWER because NO CHANNEL |
21:22.35 | Samot | I know how these work. |
21:22.48 | Samot | I was explaining that Hangup Cause 34 is the proper RESPONSE to this. |
21:22.49 | Reinhilde | wonderworld: call the telco and get them to rewrite it to cause 17 |
21:23.03 | Samot | ??? |
21:23.12 | Reinhilde | Samot: it's actually not. |
21:23.17 | Reinhilde | Busy line is busy line. This is busy line |
21:23.26 | Samot | There are no channels for it to select |
21:23.30 | wonderworld | Reinhilde: it depends on the telco of the calling person which announcement they hear |
21:23.34 | Samot | Therefore they are no available channels. |
21:23.46 | Samot | s/they/they're/ |
21:23.48 | wonderworld | Reinhilde: I would have to ask all telcos |
21:23.50 | Samot | er. |
21:23.54 | Samot | FFS today |
21:23.55 | Reinhilde | ding |
21:23.58 | Samot | there are |
21:24.05 | Reinhilde | Samot: check your blood sugars |
21:25.31 | Reinhilde | wonderworld: you need a PRI, not a BRI |
21:26.30 | Reinhilde | if you want to have enough lines to take calls only to refuse them with a "sorry, we're currently overflowing with calls, we'll call you back in a bit" |
21:26.43 | wonderworld | is the decision of the hangup cause done by dahdi or libpri? |
21:26.58 | Reinhilde | wonderworld: no, it's done by (in Samot's speculation) the caller's telco |
21:27.02 | seanbright | Reinhilde: not a clue. i avoid chan_sip when possible. |
21:27.29 | seanbright | dns resolution, port binding failure, <insert some other possibility here> |
21:27.38 | wonderworld | Reinhilde: no it's not, i logged libpri and asterisk is sending out 34 |
21:27.43 | Samot | Samot's speculation is based on years in the US telco industry. |
21:27.45 | wonderworld | every telco reacts differntly to that |
21:27.49 | Samot | ^^^ |
21:27.52 | seanbright | turning on debug logging might get you some more info. otherwise a backtrace of what is going on during the stall. |
21:28.44 | Reinhilde | seanbright: on 16 the stall clears eventually but it does still happen |
21:29.13 | seanbright | does it clear after a consistent amount of time? and if so, what is that amount of time? |
21:29.18 | Reinhilde | haven't tested |
21:29.23 | Reinhilde | i'm not going to, the system partially works now |
21:29.31 | seanbright | glad i could help |
21:29.34 | seanbright | switch to pjsip |
21:29.38 | Samot | ^ That |
21:29.43 | Samot | And partially works? |
21:29.57 | Samot | Wouldn't you want it at fully works? |
21:30.04 | seanbright | don't aim that high |
21:30.06 | Reinhilde | i would |
21:30.08 | Reinhilde | but |
21:30.37 | Reinhilde | [Apr 15 21:28:10] NOTICE[1188]: chan_sip.c:15974 sip_reg_timeout: -- Registration for 'collider2000@sip.supervoip.com' timed out, trying again (Attempt #3) (I know, dellmont sarl, but it didn't do this before the stall problem) |
21:31.06 | Samot | So either they aren't getting the register request |
21:31.10 | Samot | or you're not getting a reply |
21:31.13 | seanbright | it's possible that chan_sip is doing something on the module loader thread on startup |
21:31.14 | Reinhilde | i'm not getting a reply |
21:31.18 | Samot | Did you confirm with them they are getting it? |
21:31.29 | Reinhilde | i know not if they're getting it |
21:31.34 | Reinhilde | i know port 5060 is open inbound |
21:31.52 | Samot | Have you used something like tcpdump or sngrep to see things before they hit Asterisk? |
21:32.05 | seanbright | sngrep is wonderful |
21:32.05 | Samot | Such as the reply to your register request? |
21:35.13 | seanbright | dumb question because i know next to nothing about ISDN - if you only have 2 provisioned B channels, why is upstream sending a third call? |
21:35.37 | Samot | That is actually a decent question. |
21:35.46 | Samot | They should see all the channels in use. |
21:36.25 | wonderworld | seanbright: no idea, but it happens |
21:36.38 | Samot | Did you try asking your provider? |
21:37.03 | wonderworld | yes, they said we should send out BUSY 17 to get the correct tone |
21:37.28 | wonderworld | as i understand the call never reaches the dialplan so i cant set PRI_CAUSE |
21:37.39 | Samot | How often is this happening? |
21:37.41 | wonderworld | when doing it manualy for tests it worked fine |
21:37.55 | wonderworld | a call with PRI_CAUSE set to 17 plays busy |
21:38.15 | wonderworld | but i can't find a way to manipulate the CAUSE before the dialplan |
21:38.21 | Samot | How often is this happening? |
21:38.28 | wonderworld | but i can see 34 is sent out when logging libpri |
21:38.58 | wonderworld | a couple of times a day |
21:39.02 | wonderworld | they have 2 b channels |
21:39.11 | wonderworld | when 3 people want to call in it's over |
21:39.26 | Samot | So old people are calling in... |
21:39.32 | Samot | Getting weird errors. |
21:39.42 | wonderworld | right |
21:39.49 | Samot | How many outbound calls are they making from this location? |
21:39.52 | seanbright | wonderworld: any interesting log messages when this happens? |
21:40.21 | wonderworld | i see nothing on the CLI in asterisk with debug 100 |
21:40.30 | wonderworld | but with pri debug on |
21:40.37 | wonderworld | i get the signalling from the telco |
21:40.38 | Samot | Because if this is happening daily and multiple times a day the real solution is: Get more lines. |
21:41.08 | wonderworld | Samot: they would, but the telco can't port the number from a ptmp to a ptp line |
21:41.17 | wonderworld | it's a maze of horrors :) |
21:41.21 | Samot | Do they need PRI? |
21:41.28 | seanbright | wonderworld: with debug = 100 do you see any debug messages at all? not just from chan_dahdi but from anything? |
21:41.28 | Samot | Can't they go SIP? |
21:41.40 | wonderworld | they want to switch to voip soon |
21:41.48 | wonderworld | seanbright: yes i do, |
21:41.56 | seanbright | ok |
21:42.25 | seanbright | i don't see anything in libpri that sets that cause code, but i am not that familiar with the code |
21:42.33 | seanbright | you might need to add your own debug statements and recompile |
21:42.55 | seanbright | you're running latest everything i assume? |
21:42.58 | wonderworld | https://pastebin.com/1uCATkMX |
21:43.06 | wonderworld | this is the signalling of the 3rd call coming in |
21:43.29 | wonderworld | yes, i feared i had to recompile. tried to understand the code but wasn't able to |
21:43.33 | Reinhilde | i legitimately have more problems with my sip client than with asterisk, right now |
21:44.53 | file | I think sig_pri is what does it if I recall, but I haven't been in that world in years |
21:44.59 | file | (channels/sig_pri.c) |
21:47.41 | Reinhilde | i get this, but CallCentric is saying that my "phone" is registered and that its useragent is Asterisk: [Apr 15 21:44:52] NOTICE[1188]: chan_sip.c:15974 sip_reg_timeout: -- Registration for '17778682391@callcentric.com' timed out, trying again (Attempt #3) |
21:48.10 | seanbright | wonderworld: i _think_ i see where it is happening |
21:48.49 | wonderworld | seanbright: that would be marvelous |
21:48.55 | seanbright | wonderworld: what version of asterisk are you running - specifically |
21:49.10 | seanbright | if you say anything with "freepbx" in it i am kicking you |
21:49.13 | seanbright | just saying... |
21:49.39 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
21:49.50 | Reinhilde | seanbright: does it really matter, though? He's asked it all in asterisk terms |
21:50.03 | seanbright | if i am going to supply a patch, yes it really matters |
21:50.39 | wonderworld | this is from the debian stable packages. ast 13.4.1 | pri 1.4.15 | DAHDI 2.11.1 i can upgrade the system to latest everything if required. |
21:50.48 | seanbright | hmm |
21:50.53 | Reinhilde | wonderworld: you'll need to recompile from source |
21:51.07 | Reinhilde | are you comfortable editing C source? |
21:51.18 | wonderworld | editing is no problem. |
21:51.30 | seanbright | wonderworld: Reinhilde has got you, good luck |
21:51.46 | Reinhilde | oh great, i didn't ask for this ;_; |
21:51.53 | wonderworld | seanbright: i wouldn't mind to hear your suggestion as well :) |
21:52.14 | seanbright | Reinhilde: no? huh. weird. |
21:52.43 | seanbright | https://github.com/asterisk/asterisk/blob/master/channels/sig_pri.c#L5910 |
21:52.51 | seanbright | pretty certain that is what you will want to change |
21:53.09 | seanbright | change PRI_CAUSE_NORMAL_CIRCUIT_CONGESTION to PRI_CAUSE_USER_BUSY |
21:53.20 | seanbright | recompile. reinstall. bob's your uncle. |
21:54.03 | wonderworld | seanbright: thank you VERY MUCH |
21:54.12 | seanbright | if that is _not_ the place - you want to look for any place that pri_hangup() is being called (in asterisk) and we are passing PRI_CAUSE_NORMAL_CIRCUIT_CONGESTION |
21:54.26 | wonderworld | i understand and will try this |
21:54.31 | wonderworld | great |
21:54.34 | seanbright | god speed |
21:54.54 | Reinhilde | thank heavens, seanbright, i was far too much of a retard to understand wonderworld's problem but was going to try anyway |
21:55.09 | seanbright | wonderworld: could be this line as well: https://github.com/asterisk/asterisk/blob/master/channels/sig_pri.c#L5972 |
21:55.30 | seanbright | the lines numbers will probably differ slightly in asterisk 13 |
21:56.00 | wonderworld | i'll just patch them all. guess i don't want to send out random weird announcements at all. |
21:56.15 | Reinhilde | lol |
21:56.59 | seanbright | so i think the answer to my 'dumb question' earlier about ISDN - maybe they will send additional calls if you have call waiting? |
21:57.19 | seanbright | and if that is the case, maybe the easiest thing to do would be to have them turn off call waiting |
21:57.29 | seanbright | 'them' being the carrier |
21:57.34 | wonderworld | seanbright: ok. i will try that one first |
21:57.43 | wonderworld | lol, didn't think about that |
21:57.56 | Reinhilde | Samot: ^ |
21:58.32 | seanbright | it beats having to maintain your own local branch of asterisk |
21:58.49 | seanbright | ok, i have to go home. good luck. |
21:59.56 | Samot | Wait, wonderworld callwaiting is on this? |
22:00.06 | wonderworld | i don't know |
22:00.14 | Samot | Should find out. |
22:00.14 | wonderworld | might be the root cause |
22:00.47 | kuku | @samot - I'm just looking for a simple windows program that will connect to asterisk and listen for connections to that extensions( specified) and open up a browser when something comes in. |
22:01.17 | kuku | There used to be a lot of programs 10 years ago that did just that - you put in a login/pass and your extensions and when you got the call it opened up a window. |
22:03.01 | life_of_e | You can use just about any IM client that supports XMPP, you just have to run an XMPP server |
22:03.17 | life_of_e | Instant pop-up toaster message |
22:07.15 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
22:08.58 | Samot | kuku: There are things that do that now but they require the browser to be active and open. You expressly said the browser doesn't have to be open. |
22:09.01 | *** join/#asterisk miralin (~Thunderbi@81.177.58.137) |
22:09.29 | Samot | I even explained then about FOP2 and other CRMs requiring agents to login to app/web to listen for calls. |
22:09.38 | Samot | This isn't Windows OS specific. |
22:09.44 | Samot | This is generally browser based. |
22:13.09 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
22:13.35 | wonderworld | kuku: a tiny daemon in python could do that i guess. |
22:14.26 | wonderworld | have it listen on a port and just let it do system(firefox URL) if it receives input from asterisk |
22:14.49 | wonderworld | asterisk could just netcat the urls out from the dialplan |
22:20.06 | *** join/#asterisk salviadud (~ralfalfa@187-162-213-198.static.axtel.net) |
23:06.40 | *** join/#asterisk LoKoMurdoK (~LoKoMurdo@fedora/LoKoMurdoK) |
23:09.46 | *** join/#asterisk paulgrmn (~paulgrmn@c-68-34-113-42.hsd1.mi.comcast.net) |
23:23.10 | *** join/#asterisk paulgrmn_ (~paulgrmn@184.75.212.68) |
23:25.54 | Reinhilde | [pjproject] Compiling lib libpj-x86_64-unknown-linux-gnu.a |
23:25.56 | Reinhilde | Makefile:136 : la recette pour la cible « /root/asterisk-16.1.1/third-party/pjproject/source/pjlib/lib/libpj-x86_64-unknown-linux-gnu.a » a échouée |
23:25.58 | Reinhilde | make[2]: *** [/root/asterisk-16.1.1/third-party/pjproject/source/pjlib/lib/libpj-x86_64-unknown-linux-gnu.a] Erreur 2 |
23:26.00 | Reinhilde | Makefile:20 : la recette pour la cible « pjproject » a échouée |
23:26.39 | Reinhilde | what have i done? |
23:32.27 | Samot | Can't say, it's not in English so no clue. |
23:37.55 | Reinhilde | Samot: the recipe for whatever libpj-x86_64-unknown-linux-gnu.a crashed, error 2, the recipe for pjproject has stopped |
23:37.58 | Reinhilde | i'll rerun it in lang c for youi |
23:38.18 | Reinhilde | ... or not |
23:38.50 | Reinhilde | [pjproject] Compiling lib libpj-x86_64-unknown-linux-gnu.a |
23:38.52 | Reinhilde | Makefile:136: recipe for target '/root/asterisk-16.1.1/third-party/pjproject/source/pjlib/lib/libpj-x86_64-unknown-linux-gnu.a' failed |
23:38.54 | Reinhilde | make[2]: *** [/root/asterisk-16.1.1/third-party/pjproject/source/pjlib/lib/libpj-x86_64-unknown-linux-gnu.a] Error 2 |
23:38.56 | Reinhilde | Makefile:20: recipe for target 'pjproject' failed |