| 00:06.42 | *** join/#asterisk nickvsnetworking (~nickvsnet@203.176.184.10) |
| 00:10.04 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 00:30.15 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:108e:e3:8446:7eee:6fd5:8121) |
| 00:51.09 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 00:57.18 | *** join/#asterisk cp- (~cp-@b157153.ppp.asahi-net.or.jp) |
| 01:17.04 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 01:30.14 | *** join/#asterisk thansen4 (~thansen@192.74.130.86) |
| 02:04.18 | *** join/#asterisk wowaname (weechat@volatile/founder/wowaname) |
| 02:11.57 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 02:14.19 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 02:44.25 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 03:29.30 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 04:02.03 | *** join/#asterisk robink (~quassel@unaffilated/robink) |
| 04:38.52 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:06.04 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 05:13.47 | *** join/#asterisk cp- (~cp-@b157153.ppp.asahi-net.or.jp) |
| 05:15.47 | *** join/#asterisk cp- (~cp-@b157153.ppp.asahi-net.or.jp) |
| 05:17.45 | *** join/#asterisk cp- (~cp-@b157153.ppp.asahi-net.or.jp) |
| 05:41.58 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 06:04.13 | *** join/#asterisk Igneous (~Srain@14.248.82.95) |
| 06:06.28 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 06:08.42 | *** join/#asterisk miralin (~Thunderbi@94.233.241.29) |
| 06:09.19 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
| 06:18.40 | *** join/#asterisk tsal_ (~tsal@i59F4A3DA.versanet.de) |
| 06:22.17 | *** join/#asterisk Igneous (~Thunderbi@14.248.82.95) |
| 06:49.06 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 06:50.18 | FH_thecat | I had the following in my peer in sip.conf: |
| 06:50.22 | FH_thecat | disallow = all |
| 06:50.26 | FH_thecat | allow = ulaw,alaw,g722 |
| 06:50.39 | FH_thecat | but looks like this syntax does not work |
| 06:50.55 | FH_thecat | I had to change to one codec per line, ie |
| 06:50.55 | FH_thecat | allow = ulaw |
| 06:51.15 | FH_thecat | the weird thing is, it worked on other asterisk |
| 06:51.31 | FH_thecat | is this syntax invalid or not ? |
| 06:52.41 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 06:53.23 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:615b:a907:bdc9:d1cc) |
| 07:02.01 | *** join/#asterisk jkroon (~jkroon@2c0f:f720:fe0c:1:fc57:8296:4e8d:e1d4) |
| 07:06.18 | drc | Multiple codecs, comma-separated, in one allow or disallow? Valid syntax. |
| 07:20.36 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:615b:a907:bdc9:d1cc) |
| 07:27.51 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:615b:a907:bdc9:d1cc) |
| 07:35.59 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 07:48.18 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
| 07:58.17 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:108e:e3:8446:7eee:6fd5:8121) |
| 08:08.17 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 08:12.10 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 08:48.32 | *** join/#asterisk nickvsnetworking (~nickvsnet@1.152.106.81) |
| 09:06.55 | *** join/#asterisk steinbach (~id4rk@reactos/tester/id4rk) |
| 09:14.33 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 09:15.12 | *** join/#asterisk luckman212 (luckman212@unaffiliated/luckman212) |
| 09:21.30 | *** join/#asterisk AsteriskRoss (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 09:31.11 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 10:03.36 | *** join/#asterisk nickvsnetworking (~nickvsnet@103.31.113.82) |
| 10:11.35 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 10:19.47 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 10:21.05 | *** join/#asterisk AsteriskRoss (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 10:41.45 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:615b:a907:bdc9:d1cc) |
| 10:55.43 | *** join/#asterisk AsteriskRoss (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 11:02.35 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:615b:a907:bdc9:d1cc) |
| 11:12.31 | *** join/#asterisk gvs77 (~gvs77@85.234.217.236.static.edpnet.net) |
| 11:13.25 | gvs77 | I have a SIP door opener that I would like to route to a message or queue based on a time group, but it will need a number to dial when somebody rings it |
| 11:13.37 | gvs77 | What is the best way to route it to the time group? |
| 11:25.42 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 11:30.08 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 11:45.40 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-hfxirhsdvkzjrvjs) |
| 11:45.40 | *** mode/#asterisk [+o bford] by ChanServ |
| 11:46.02 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 11:55.50 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 12:05.52 | *** join/#asterisk dacod (~dacod@138.97.34.59) |
| 12:12.28 | *** join/#asterisk AsteriskRoss (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 12:13.00 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 12:24.08 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 12:56.54 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:01.19 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 13:15.05 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 13:42.52 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:615b:a907:bdc9:d1cc) |
| 13:45.01 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-wrjqywxuxprexjbj) |
| 13:45.53 | *** join/#asterisk AsteriskRoss (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 13:46.27 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:46.28 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:08.39 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-gbrqdkzscyrabzti) |
| 14:08.39 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:08.39 | *** join/#asterisk wearyhacker (uid435081@gateway/web/irccloud.com/x-vjmywjrpwsrgjvgp) |
| 14:18.35 | *** join/#asterisk AsteriskRoss (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 14:34.24 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:615b:a907:bdc9:d1cc) |
| 14:40.15 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 14:48.26 | *** join/#asterisk armin (~a@bsd.pm) |
| 14:51.43 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 15:03.00 | igcewieling | Any idea what might cause this? ":[2020-05-19 12:46:57] WARNING[14368] app.c: No audio available on SIP/vmax-00081d58??" ? |
| 15:29.47 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 15:42.28 | *** join/#asterisk chandoo (~chandoo@pool-100-1-166-161.nwrknj.fios.verizon.net) |
| 15:52.59 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |
| 16:02.02 | *** join/#asterisk rhollan (~androirc@v-72-5-54-188.unman-vds.premium-seattle.nfoservers.com) |
| 16:03.28 | rhollan | Does chan-mobile expect a MAP Bluetooth profile for SMS? |
| 16:05.54 | *** join/#asterisk bmg505 (~leon@8ta-146-140-67.telkomadsl.co.za) |
| 16:47.43 | igcewieling | "At Sangoma, Our Partners Are Our Family" Are they going to complain if I skip Christmas dinner? |
| 16:49.55 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 17:07.09 | *** join/#asterisk miralin (~Thunderbi@94.233.241.29) |
| 17:13.08 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 17:17.40 | *** join/#asterisk moy (sid47040@gateway/web/irccloud.com/x-mzxqebijtdporcky) |
| 17:22.02 | *** join/#asterisk X-Rob (X-Rob@gateway/web/irccloud.com/x-ourscaeqvpastwaw) |
| 17:26.03 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 17:26.53 | *** join/#asterisk GameGamer43 (sid5533@gateway/web/irccloud.com/x-rglmhiaaqjzhtawf) |
| 17:26.53 | *** mode/#asterisk [+o GameGamer43] by ChanServ |
| 17:30.05 | igcewieling | I currently have an Adder CATx 1000 IP KVM switch which appears to have died. 8-( Can anyone recommend better options to replace it? Otherwise, I'll replace it with another CATx IP. |
| 17:30.05 | *** join/#asterisk DannyA (~DannyA@cpe-74-64-125-9.nyc.res.rr.com) |
| 17:31.11 | DannyA | hey all. is there a way to differentia between a disconnect and a proper BYE from an endpoint? if i have a caller into my system, and my remote user loses their internet connection, but their backup connection will kick in within a few seconds, can i tell asterisk not to disconnect the caller if it got a disconnect vs a BYE, and the remote user has a chance to reconnect to the call? |
| 17:31.37 | seanbright | increase rtptimeout |
| 17:31.45 | *** join/#asterisk tuxd00d (sid401305@gateway/web/irccloud.com/x-pokooorrfqgotnhf) |
| 17:31.57 | seanbright | there is no such thing as a disconnect in SIP |
| 17:33.25 | igcewieling | DannyA: When the backup connection kicks in, does any IP change? |
| 17:35.51 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 17:38.01 | igcewieling | If it does not and there is no NAT involved, then you have a chance of keeping the call up. If there is NAT involved or the source IP changes when the backup connection kicks in, then you'll never "reconnect" the call automatically. |
| 17:39.57 | *** join/#asterisk miralin (~Thunderbi@94.233.241.29) |
| 17:42.38 | *** join/#asterisk gvs77 (~gvs77@85.234.217.236.static.edpnet.net) |
| 17:43.11 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 17:45.02 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 17:45.53 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:615b:a907:bdc9:d1cc) |
| 17:48.07 | DannyA | @igcewieling the IP will not be different |
| 17:48.37 | igcewieling | DannyA: No NAT involved? |
| 17:49.02 | DannyA | none |
| 17:51.28 | Samot | So this is some BGP based failover? |
| 17:51.31 | igcewieling | DannyA: I have a couple sites with 2 internet connections. Main connection goes from our customer to our datacenter router. Backup connection goes from our customer to some other ISP. I have a GRE tunnel from the router, out the backup ISP connection to the same router the Primary circuit terminates in. i.e. both the Main connection and the GRE tunnel terminate into the same router at each end. This allows us to use OSPF to aut |
| 17:51.31 | igcewieling | omatically failover. |
| 17:51.38 | Samot | OK. |
| 17:51.58 | Samot | Oh that wasn't DannyA replying. |
| 17:52.03 | DannyA | yes, BGP failover |
| 17:52.26 | DannyA | there's two connections: an MPLS into verizon, and the backup connection is cable with a vpn connection into the mpls |
| 17:52.28 | igcewieling | Audio returns as soon as connectivity returns via the GRE tunnel. |
| 17:53.23 | DannyA | how does it need to be configured within asterisk? |
| 17:56.31 | igcewieling | DannyA: the great thing about doing failover in a transparent way is that no changes need to be done on the endpoint or Asterisk. |
| 17:56.51 | igcewieling | I have no idea why it isn't working for you. |
| 17:56.51 | Samot | You'll just drop audio on the call for however long it takes to cut over |
| 17:57.34 | igcewieling | YUP! on most of my failover clients, it takes about 10 - 15 seconds for audio to failover. failback appears to happen without audio issues. |
| 17:58.58 | Samot | DannyA: What is the actual primary connect? Fiber? |
| 17:59.21 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 17:59.45 | igcewieling | DannyA: focus on the network/routing/vpn rather than Asterisk. |
| 18:01.16 | Samot | igcewieling: The actual WAN IP changes at the location. If it is a back up cable connection that has to VPN into the MPLS network. |
| 18:02.01 | DannyA | @igcewieling i haven't tested this yet, so its not "not working" i just wanted to get it set up to test :-) |
| 18:02.30 | DannyA | i always thought asterisk would interpret a disconnect from an endpoint as, disconnecting from the call, and it would then terminate the channel |
| 18:02.56 | DannyA | @Samot according to our IT manager it'll be the same IP |
| 18:03.21 | Samot | DannyA: I understand that but in order for that to happen the VPN must be up |
| 18:03.33 | DannyA | yes, its always running |
| 18:03.42 | Samot | If the failover happens and the cable connection doesn't have the VPN up for whatever reason.... |
| 18:03.45 | Samot | I understand that too. |
| 18:03.46 | DannyA | its just that the local adtran will switch to using the cable modem as its connection |
| 18:04.02 | Samot | So the VPN is a point of failure and can add latency |
| 18:05.14 | igcewieling | DannyA: a packet capture will tell you for sure. |
| 18:05.52 | DannyA | so interesting. so asterisk does not automatically kill the call for the "other" channel, just because the ____ channel gets disconnected |
| 18:05.59 | Samot | DannyA: The call will be in progress, Asterisk will send things to X IP... |
| 18:06.12 | file | if using UDP there is no connection. |
| 18:06.16 | Samot | When you hit your failover mark, Asterisk will be retransmitting those things... |
| 18:06.38 | Samot | Once your VPN is up and on the IP, it will start to respond |
| 18:06.51 | Samot | As long as Asterisk hasn't timed out on the restransmissions. |
| 18:07.10 | Samot | However, 3-5 seconds is also long enough for a human to think the call is dropped. |
| 18:07.35 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 18:08.58 | Samot | There is also NAT involved in this. |
| 18:09.19 | Samot | So there is a good chance the call is going to be dropped since the local network has to change paths/routes for this failover. |
| 18:10.24 | DannyA | interesting |
| 18:10.31 | DannyA | gonna call the IT guy now and see how we can test this |
| 18:12.04 | Samot | I have a feeling this will result in 481's on one or both sides. |
| 18:15.16 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 18:36.11 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:117b:d901:9852:bd8c:b297:991d) |
| 18:39.36 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 18:41.52 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 18:49.17 | Kobaz | how do you get call ids to show up in 16+ in the console |
| 18:49.53 | Kobaz | logger.conf [general] display_callids=yes affects the log file, but not the console |
| 18:50.33 | Kobaz | been spending a few hours running through logger.c to figure out how to get it to the console, but it might be a lack of functionality, Looks like it might be missing from 16 |
| 18:51.50 | *** join/#asterisk gvs77 (~gvs77@85.234.217.236.static.edpnet.net) |
| 19:18.46 | *** join/#asterisk led_belly (led_belly@gateway/vpn/protonvpn/ledbelly/x-06903193) |
| 19:27.10 | *** join/#asterisk rtfm (rtfm@unaffiliated/rtfm) |
| 19:38.26 | igcewieling | Kobaz: I never found a way. Best I could do is get the info out of CHANNEL() function. |
| 19:39.57 | Kobaz | aw |
| 19:40.07 | Kobaz | asterisk 11-13 i know for sure had it in the console |
| 19:40.17 | Kobaz | i gotta look through commits and see where it vanished |
| 19:41.14 | file | it's in the console for me? |
| 19:41.36 | file | [May 26 16:41:07] WARNING[2852244][C-00000001]: app_playback.c:497 playback_exec: Playback failed on Local/666@users-00000000;2 for /tmp/test |
| 19:41.38 | file | C-00000001 being the call id |
| 19:45.37 | Kobaz | right |
| 19:45.41 | Kobaz | if there's a failure |
| 19:45.47 | Kobaz | but what about normal ast_verb |
| 19:46.26 | Kobaz | asterisk -rvvv. Channel PJSIP/trunk-isoft-gw-1-00000006 joined 'simple_bridge' basic-bridge <388ef1a6-4913-4abd-8974-5a9eb29af0e9> |
| 19:46.35 | Kobaz | no asterisk call-id |
| 19:46.47 | file | verbose has never had them I believe, we don't include any of the deets |
| 19:46.55 | file | no date, no thread id, no call id |
| 19:48.24 | Kobaz | hmm, maybe that was my local patch |
| 19:48.32 | Kobaz | all my asterisk logs have it from 11 |
| 19:48.46 | file | dunno though, I don't remember that far back |
| 19:48.49 | Kobaz | hehe |
| 19:49.21 | Kobaz | the new logging is way more complex, taking me a while to go through all this |
| 19:49.33 | Kobaz | if i did want to include callid in ast_verb going to the console, what's a good place to look |
| 19:49.48 | file | all logging stuff is in logger.c |
| 19:49.51 | file | haven't touched it in ages |
| 19:52.05 | Kobaz | yeaaah, it does look that way |
| 19:52.08 | Kobaz | lots o levels |
| 19:52.10 | Kobaz | anyway |
| 19:52.20 | Kobaz | having a weird weird problem with pjsip |
| 19:52.21 | Kobaz | http://dpaste.com/2PJTWR6 |
| 19:52.34 | Kobaz | it's ignoring OK's from another host and dropping the call |
| 19:53.15 | Kobaz | There's like 5 SIP/2.0 200 OK's |
| 19:53.27 | Kobaz | and then pjsip is like uhhh sorry, drop |
| 19:53.48 | seanbright | the contact in the OK doesn't match the one in the invite |
| 19:55.35 | seanbright | which may have nothing to do with anything |
| 19:55.54 | seanbright | actually, that is meaningless |
| 19:56.00 | seanbright | i'll show myself out |
| 19:56.03 | Kobaz | hehe |
| 19:56.45 | Kobaz | hmm that could be it though? |
| 19:56.52 | Kobaz | lemme fix some stuff |
| 19:57.45 | seanbright | it is highly likely that i have put you on the wrong path |
| 19:57.55 | seanbright | so don't spend too much time on it |
| 19:58.11 | Kobaz | that did it |
| 19:59.10 | Kobaz | pjsip is definitely more picky |
| 19:59.49 | seanbright | or more correct |
| 20:01.50 | Kobaz | true |
| 20:02.21 | Kobaz | it was kind of nice that chan_sip took any old crap and was like OKAY |
| 20:03.00 | Kobaz | but that also make life difficult when traffic coming in from a proxy tries to authenticate against a local user via the 'From' header |
| 20:03.46 | Kobaz | and you can't really control it on a case by case basis whether to match auth user or the ip... fun times |
| 20:11.45 | Samot | What do you mean? |
| 20:13.03 | Kobaz | chan_sip conf match_auth_username |
| 20:13.05 | Kobaz | is global |
| 20:14.36 | Samot | OK, but in a case by case basis wouldn't global be bad? |
| 20:14.42 | Kobaz | right |
| 20:14.49 | Kobaz | hence... fun times with chan_sip |
| 20:19.36 | *** join/#asterisk hfb (~hfb@47.139.18.84) |
| 20:24.19 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 20:47.24 | *** join/#asterisk AsteriskRoss (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 20:57.46 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 20:58.42 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 20:59.36 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 21:00.33 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 21:01.16 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 21:11.00 | Kobaz | hmmm |
| 21:11.25 | Kobaz | any idea why a pjsip channel just hangs up after 30 seconds |
| 21:12.04 | Kobaz | oh, it could be another one of those mismatched ip things |
| 21:12.18 | Kobaz | bunch of OKs and then a BYE... gotta fix this on the other direction now |
| 21:20.04 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 21:21.58 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 21:27.13 | Kobaz | hmm, pjsip is sending contact sip:1.2.3.4:5060 |
| 21:27.49 | Kobaz | instead of user@ |
| 21:32.17 | *** join/#asterisk miralin1 (~Thunderbi@94.233.241.29) |
| 21:35.37 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
| 21:47.05 | *** join/#asterisk pedro__ (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 21:53.22 | seanbright | once you configure it properly everything should work |
| 21:53.31 | seanbright | there are some pages on the wiki that discuss configuring pjsip |
| 21:53.48 | seanbright | there is also a python script that tries to convert your sip.conf to pjsip.conf |
| 21:56.11 | Kobaz | yeah |
| 21:56.29 | Kobaz | actually it's looking like a network issue, my main sip proxy we're supposed to use stopped responding |
| 21:58.12 | Kobaz | It was just looking oddly similar to the last round, that I fixed by setting external addresses and the public ip |
| 21:58.38 | Kobaz | but this is completely different... the host is literally just not responding to sip options, etc... and randomly not sending us calls |
| 22:25.52 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:41e3:6c15:fbea:e6c5) |
| 22:26.14 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 22:36.54 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 22:58.34 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 23:19.43 | *** join/#asterisk dacod (~dacod@138.97.34.59) |
| 23:58.11 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:117b:d901:fc87:b582:9870:760) |