| 00:05.27 | *** part/#asterisk kharwell (kharwell@nat/digium/x-smyftwngfbtbabda) |
| 00:21.25 | *** join/#asterisk Tamo (~Tamo@ec2-54-152-105-226.compute-1.amazonaws.com) |
| 00:35.22 | *** join/#asterisk fbnts_ (~fbnts@s099.spireinns.co.uk) |
| 01:01.42 | *** join/#asterisk miralin (~Thunderbi@194.8.128.50) |
| 01:06.07 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 01:24.44 | *** join/#asterisk albatros101 (c5e7ebf4@gateway/web/freenode/ip.197.231.235.244) |
| 01:25.00 | albatros101 | hi all |
| 01:25.48 | albatros101 | can you have duplicate sip accounts in your sip.conf file, and if you do witch one would it use the first or the second one |
| 01:30.57 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 01:38.58 | Samot | No. |
| 01:49.14 | albatros101 | cool thx |
| 01:56.30 | *** join/#asterisk fbnts_ (~fbnts@s099.spireinns.co.uk) |
| 02:58.40 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 03:01.47 | *** join/#asterisk [NC] (~nc@rv1.sabius.net) |
| 03:05.04 | *** join/#asterisk sparetire (~sparetire@unaffiliated/sparetire) |
| 03:06.05 | *** join/#asterisk bipolar (~bipolar@offsite.guru) |
| 03:17.45 | *** join/#asterisk jab416171 (~jab416171@c-76-27-96-12.hsd1.ut.comcast.net) |
| 03:39.16 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 03:55.52 | *** join/#asterisk puzzola (~puzzola@unaffiliated/puzzola) |
| 04:20.59 | *** join/#asterisk puzzola (~puzzola@unaffiliated/puzzola) |
| 04:23.09 | *** join/#asterisk MaliutaLap (~nobusines@unaffiliated/maliuta) |
| 04:24.08 | *** join/#asterisk Maliuta (~nobusines@unaffiliated/maliuta) |
| 04:29.57 | *** join/#asterisk MaliutaLap (~nobusines@unaffiliated/maliuta) |
| 04:31.09 | *** join/#asterisk MaliutaLap (~nobusines@unaffiliated/maliuta) |
| 05:02.02 | *** join/#asterisk Alblasco1702 (~Alblasco1@ip5456b46b.speed.planet.nl) |
| 05:23.20 | *** join/#asterisk wyoung (~wyoung@wesleyy.com) |
| 05:53.24 | *** join/#asterisk MrMojit01 (~MrMojit0@hoofddorp.cn.nl) |
| 06:00.07 | *** join/#asterisk fbnts_ (~fbnts@s099.spireinns.co.uk) |
| 06:15.14 | wyoung | \o/ |
| 06:21.29 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 06:28.15 | *** join/#asterisk overyander (~Jeff@12.49.160.131) |
| 06:29.34 | *** join/#asterisk file__ (uid178970@asterisk/developer-and-muffin-lover/file) |
| 06:29.34 | *** mode/#asterisk [+o file__] by ChanServ |
| 06:33.25 | *** join/#asterisk evilman_work (~evilman@87.244.6.228) |
| 06:34.52 | *** join/#asterisk rrittgarn (~rrittgarn@75-150-221-205-Illinois.hfc.comcastbusiness.net) |
| 06:37.07 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 06:40.34 | *** join/#asterisk KValchev (~KValchev@ns.atsoftconsult-bg.com) |
| 06:53.22 | *** join/#asterisk Hyper_Eye (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 07:02.23 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 07:18.55 | *** join/#asterisk defsdoor (~andy@cpc35-sutt4-2-0-cust184.19-1.cable.virginm.net) |
| 07:20.05 | *** join/#asterisk jkroon (~jkroon@dustpuppy.is.co.za) |
| 07:38.19 | *** join/#asterisk ChannelZ (channelz@burner.com) |
| 08:00.29 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 08:00.50 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 08:02.26 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
| 08:06.04 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
| 08:06.41 | *** join/#asterisk Tiffon (~name@unaffiliated/tiff0n) |
| 08:35.21 | *** join/#asterisk pchero_work (~pchero@2a00:c80:1072::10de) |
| 08:57.52 | *** join/#asterisk areski (~areski@15.red-83-33-189.dynamicip.rima-tde.net) |
| 09:08.30 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 09:36.12 | *** join/#asterisk Maliuta (~nobusines@unaffiliated/maliuta) |
| 09:51.35 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 09:59.13 | *** join/#asterisk cmendes0101 (~cmendes01@47-144-223-7.lsan.ca.frontiernet.net) |
| 10:08.39 | *** join/#asterisk areski (~areski@15.red-83-33-189.dynamicip.rima-tde.net) |
| 10:12.21 | *** join/#asterisk Kaian (~kaian@6.62-99-78.static.clientes.euskaltel.es) |
| 10:25.59 | *** join/#asterisk tuxian (~tuxian@194.12.3.78) |
| 10:28.02 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
| 10:32.05 | *** join/#asterisk cmendes0101 (~cmendes01@47-144-223-7.lsan.ca.frontiernet.net) |
| 10:32.46 | *** join/#asterisk areski (~areski@15.red-83-33-189.dynamicip.rima-tde.net) |
| 10:39.59 | *** join/#asterisk sekil (~sekil@cable-89-216-223-20.dynamic.sbb.rs) |
| 10:44.12 | *** join/#asterisk Guest56022 (~nobusines@unaffiliated/maliuta) |
| 10:44.22 | *** join/#asterisk Maliuta (~nobusines@unaffiliated/maliuta) |
| 10:45.09 | *** join/#asterisk MaliutaLap_ (~nobusines@unaffiliated/maliuta) |
| 10:56.22 | *** join/#asterisk libardi (~libardi@187.64.235.241) |
| 11:06.32 | *** join/#asterisk genpaku (~genpaku@107.191.100.185) |
| 11:15.01 | tparcina | When A talks to B, and then B does attendant transfer to C, after the transfer A and C can hear each other. |
| 11:17.12 | tparcina | I have captured network traffic and RTP stream is going between Asterisk and C. |
| 11:17.37 | tparcina | So, * is sending RTP stream to the C but C doesn't hear it. |
| 11:18.04 | tparcina | And * is receiving RTP stream from C, but A doesn't hear it. |
| 11:19.51 | tparcina | Sequence number of RTP stream from * to C has changed when call was transfered. |
| 11:20.47 | tparcina | Sequence number of RTP stream from C to * has not changed ever. And it's incremental during whole conversation (started with B and continued with A). |
| 11:21.15 | tparcina | What is wrong here? Why A can hear C, and why C can't hear A? |
| 11:26.01 | *** join/#asterisk jaflong (5bec7547@gateway/web/freenode/ip.91.236.117.71) |
| 11:27.08 | jaflong | Hi everyone |
| 11:27.12 | tparcina | Now I see that Synchronization Source identifier of * also changes when call is transferred. |
| 11:27.46 | tparcina | I guess that could explain why C can't hear A. |
| 11:27.57 | jaflong | any ideas why when I do a 'channel request hangup' that the hangup does not actualy spawn |
| 11:28.05 | *** join/#asterisk chendy (~alexc@119.123.114.77) |
| 11:29.33 | jaflong | i nornaly see something like this ' == Spawn extension (queue, 6444, 1) exited non-zero on 'SIP/pbx-01-00000068' |
| 11:30.10 | jaflong | however it is missing thus no sip bye is sent |
| 11:54.18 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 12:28.06 | chendy | | |
| 12:39.23 | *** join/#asterisk cmendes0101 (~cmendes01@47-144-223-7.lsan.ca.frontiernet.net) |
| 13:08.07 | *** join/#asterisk slav3_sergal (~frankthet@unaffiliated/slav3-kitten/x-0866809) |
| 13:26.31 | *** join/#asterisk cmendes0101 (~cmendes01@47-144-223-7.lsan.ca.frontiernet.net) |
| 13:36.31 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:44.59 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:46.16 | *** join/#asterisk thiagoc_ (~thiagoc@unaffiliated/thiagoc) |
| 13:56.11 | MacroMan | Why does asterisk try to play sound file with a .slin extension for alaw? |
| 13:56.23 | MacroMan | I thought the extension was sln16 |
| 13:58.01 | *** join/#asterisk Martin` (~martin@shell.ipv6.octocore.net) |
| 14:04.29 | [TK]D-Fender | it plays the best or cheapest translation for whatever the current codec is |
| 14:06.27 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
| 14:07.08 | tparcina | [TK]D-Fender: Do you know anything about "Mark" flags in RTP packet header? |
| 14:07.53 | [TK]D-Fender | nope |
| 14:08.28 | tparcina | [TK]D-Fender: I em having problems with attendant call transfer. |
| 14:09.06 | Samot | What is the issue you are having? |
| 14:09.15 | tparcina | I have compared successful with unsuccessful and the only difference I have noticed is that unsuccessful one doesn't have RTP Mark flag set up. |
| 14:09.44 | tparcina | Samot: When the call is transfered, non of the parties can't hear each other. |
| 14:10.16 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 14:10.18 | tparcina | Samot: And I can hear whole communication in network traffic I have captured. |
| 14:10.46 | Samot | Show a SIP debug. |
| 14:11.09 | Samot | From Asterisk. |
| 14:11.27 | tparcina | I don't have just SIP debug, I have several debugs combined. |
| 14:11.27 | Samot | What "Mark" flag? |
| 14:11.44 | tparcina | Samot: And it's quite big file. |
| 14:11.59 | tparcina | What part of it would be helpful? |
| 14:12.06 | Samot | asterisk -r |
| 14:12.10 | Samot | sip set debug on |
| 14:12.16 | Samot | Make call, do attended transfer. |
| 14:12.18 | Samot | Show it. |
| 14:12.38 | tparcina | It is not reproducible every time. |
| 14:12.44 | Samot | But what "Mark" flag? |
| 14:13.03 | tparcina | RTP packet has "Mark" flag. |
| 14:13.14 | Samot | Show it. |
| 14:13.27 | MacroMan | [TK]D-Fender, Yes I'm aware of that. It's using the alaw codec, but according to the logs it's trying to play 'sound-file.slin', which don't exist as files at all. The extension is actually .sln16 |
| 14:15.45 | tparcina | Samot: Here is the "Mark" flag - http://www.siptutorial.net/RTP/header.html |
| 14:16.36 | Samot | OK, m= is MEDIA |
| 14:17.07 | tparcina | Samot: And here you can read bit more about it: https://www.wireshark.org/lists/wireshark-users/201203/msg00049.html |
| 14:17.19 | Samot | Not "Mark" |
| 14:18.15 | *** join/#asterisk Deeewayne (~dwayne@c-68-32-120-188.hsd1.al.comcast.net) |
| 14:18.55 | Samot | So you do an attended transfer..... |
| 14:19.27 | Samot | Does the party transferring the call and the party being transferred to have audio between them? |
| 14:21.37 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 14:22.06 | Samot | ?? |
| 14:27.26 | tparcina | Samot: Yes. |
| 14:27.35 | tparcina | Samot: A calls B, and they talk. |
| 14:27.44 | tparcina | B calls C and they talk. |
| 14:28.07 | tparcina | B transfers A to C, and then A can't hear C and C can't hear A. |
| 14:28.08 | *** join/#asterisk newtonr (RustyNewto@nat/digium/x-sbqocbzdywcqfjih) |
| 14:28.09 | *** mode/#asterisk [+o newtonr] by ChanServ |
| 14:28.50 | Samot | Can B hear A after talking to C but before transferring? |
| 14:28.52 | tparcina | Samot: And tone/voice is going trough network (tcpdump has capture it). |
| 14:29.46 | tparcina | Samot: B doesn't return back to A, he immediately transfers to C (after B finishes call with C). |
| 14:29.55 | Samot | You should check that. |
| 14:30.41 | Samot | Because B is putting A on hold. Which is a Re-INVITE to change the SDP details. |
| 14:31.30 | tparcina | Samot: OK, but that is not the case how we are doing transfers here. |
| 14:31.41 | Samot | So? |
| 14:31.48 | Samot | It doesn't just the process of how a transfer works. |
| 14:32.02 | Samot | There are Re-INVITEs and new INVITEs. |
| 14:32.04 | tparcina | Samot: If it is working, or if it is not working, how will that help solving the issue I'm having? |
| 14:32.11 | Samot | All of which contain new SDP and Contact details. |
| 14:32.15 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 14:32.30 | Samot | Because it will determine if the Re-INVITE when holding them or taking them off hold is CORRECT |
| 14:32.41 | Samot | B put A on hold, talks to C |
| 14:32.50 | Samot | B picks up A to say "Transferring you" |
| 14:32.54 | Samot | But there's no AUDIO |
| 14:32.58 | tparcina | Samot: Maybe I have said it wrong. B doesn't put A on hold, but immediately tries to do attendant transfer. |
| 14:33.06 | Samot | There's would be a problem before the transfers. |
| 14:33.23 | Samot | Attended Transfer puts the part on HOLD |
| 14:33.44 | Samot | While you pick up another channel and dial the new party. |
| 14:34.18 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:34.18 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:37.20 | Samot | A calls B, B does *2 to do AXfer, A is put on hold. |
| 14:37.39 | Samot | B calls C, C answers, B does *4 to complete the transfer... |
| 14:38.05 | Samot | Channel A is bridged to Channel C and Channel B drops out. |
| 14:38.38 | Samot | During that process there are Re-INVITEs which update the SDP, Contact headers, etc. |
| 14:40.05 | Samot | Where are you capturing the call that has audio the whole time? |
| 14:44.29 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 14:49.25 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 14:51.00 | *** join/#asterisk Tristan-Speccy (~tristan@antares.whatbox.ca) |
| 14:52.40 | tparcina | Samot: I have captured the call between * and C. |
| 14:53.12 | tparcina | Samot: I hear that * is sending voice from A to C. But C doesn't hear it. |
| 14:53.35 | Samot | OK so that means the issue is a network/NAT issue. |
| 14:54.02 | tparcina | Samot: Why do you say that? |
| 14:54.07 | Samot | Do you hear C talking back to A? |
| 14:54.41 | tparcina | Samot: I have capture packets on * server. And I can hear what A is saying and I can hear what C is saying. |
| 14:54.58 | tparcina | Samot: Just A doesn't hear C and C doesn't hear A. |
| 14:55.12 | Samot | So is * sending the media to the right place? |
| 14:55.25 | tparcina | Samot: But both voices are coming to *. |
| 14:55.33 | Samot | That wasn't my question. |
| 14:55.46 | Samot | That means the devices are sending the media to the right place. |
| 14:55.55 | Samot | Is ASTERISK sending the media to the right place? |
| 14:55.57 | tparcina | Yes, I can see that * is sending voice from A to C's IP address. |
| 14:56.09 | Samot | Do it make it to C? |
| 14:56.33 | tparcina | Yes, * is sending media to the right place. |
| 14:56.39 | Samot | Does it MAKE IT? |
| 14:57.04 | *** join/#asterisk putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:57.04 | *** mode/#asterisk [+o putnopvut] by ChanServ |
| 14:57.41 | tparcina | I don't know. It is hard to do network capture on the workplace. |
| 14:57.53 | Samot | Is it going to the right port along with the right IP? |
| 14:58.21 | Samot | You have confirmed that the "inbound" to Asterisk is making it to Asterisk. |
| 14:58.41 | Samot | Have you done an RTP debug at all |
| 14:59.11 | tparcina | Samot: Yes, the RTP packet from A to C is going to the same address:port as the RTP packet from B to C has gone. |
| 15:01.34 | Samot | This is a networking issue. |
| 15:01.47 | tparcina | Samot: I have done rtp debug, but I didn't find anything wrong. |
| 15:01.55 | *** join/#asterisk Rini (uid196547@gateway/web/irccloud.com/x-hantbzomvldyagjy) |
| 15:02.06 | tparcina | Samot: What kind of networking issue? |
| 15:02.11 | Samot | Does it happen if A, B and C are all local users? |
| 15:02.54 | tparcina | Then again, I have things like this in RTP debug: DEBUG[406][C-0000a601] res_rtp_asterisk.c: Ignoring duplicate RTCP property on RTP instance '0x2296808' |
| 15:03.28 | tparcina | Samot: Don't know, local users don't do transfers. |
| 15:03.39 | Samot | So A is always over the PSTN? |
| 15:05.24 | tparcina | Samot: PSTN but we have SIP to our provider. |
| 15:05.53 | tparcina | Samot: A has PSTN number, but connects to us over our SIP provider. |
| 15:06.12 | Samot | I get that. |
| 15:06.21 | Samot | OK so A calls in.. |
| 15:06.30 | Samot | A is answered by Asterisk. |
| 15:06.48 | Samot | That channel has it's own RTP details for talking between the provider and the PBX. |
| 15:07.18 | Samot | PBX calls B, that has it's own RTP details. RTCP is also part of it. RTP always has two ports an even and an odd. |
| 15:07.46 | Samot | Now, B calls C, again it's own RTP ports. |
| 15:07.57 | Samot | In an attended transfer... |
| 15:08.15 | Samot | B can join A and C together and drop out. |
| 15:08.32 | Samot | OR B can join A and C together with him. |
| 15:08.49 | tparcina | B joins A and C and drops out. |
| 15:08.53 | tparcina | (in our case) |
| 15:08.54 | Samot | OK. |
| 15:08.58 | Samot | Either way... |
| 15:09.07 | Samot | A and C should be joined.. |
| 15:09.18 | Samot | Well no either way..in your case.. |
| 15:09.28 | Samot | A and C are joined, B drops out. |
| 15:09.46 | Samot | Are all the users local to the PBX? |
| 15:09.59 | tparcina | Samot: Unfortunately I have to go now. :( |
| 15:10.18 | tparcina | (pick up child from kids garden) |
| 15:10.26 | Samot | OK. |
| 15:10.44 | tparcina | If you are here tomorrow we can continue on this one. |
| 15:10.49 | tparcina | Thank you and bye. |
| 15:12.01 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-rkpjhrxufjrmonkj) |
| 15:12.01 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 15:13.20 | Samot | Hrm, i just read the scrollback. This is a networking issue.. |
| 15:24.20 | *** join/#asterisk kharwell (kharwell@nat/digium/x-giqxzkshzlfzhash) |
| 15:24.20 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:35.37 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 15:38.49 | *** join/#asterisk xibalba (~xibal_@unaffiliated/xibalba) |
| 15:39.07 | *** join/#asterisk lvlinux (~ruel@unaffiliated/lvlinux) |
| 15:39.56 | xibalba | hello, i'm trying to figure out if an asterisk server is handing off phone calls to a remote location or dialing a remote location and bridging the two call legs together. anyone have some guidance on how to tell ? |
| 15:40.40 | Samot | asterisk -rvvvvvvvvvvv |
| 15:40.58 | Samot | Make the call..see how the call is being processed. |
| 15:41.09 | xibalba | i'm using 'sip show channels' on both servers and i believe i see a call come into asterisk box A then a second call is made from Asterisk A to Asterisk B |
| 15:41.33 | xibalba | ok the only problem when i tried to run that is there are tons of calls going through this box per minute, so the console was impossible to read |
| 15:41.38 | xibalba | unless i was data from star trek |
| 15:42.59 | xibalba | is there a way to filter the console to one TN? |
| 15:43.03 | *** join/#asterisk dokma (~vlatko@cpe-94-253-161-138.zg.cable.xnet.hr) |
| 15:43.04 | igcewieling | no. |
| 15:43.28 | igcewieling | use wireshark or tcpump and look for where the RTP is flowing. |
| 15:43.53 | igcewieling | you could also look at the asterisk logs |
| 15:44.17 | [TK]D-Fender | xibalba, that's why God invented scroll-back buffers |
| 15:44.22 | igcewieling | btw, "handing off phone calls" is meaningless. There are at least 3 different things that could apply to. |
| 15:44.34 | dokma | In musiconhold.conf the filename to be played is the stuff in brackets? As in [music] plays music.mp3? |
| 15:44.46 | igcewieling | Using s 302 redirect, direct media, and not direct media |
| 15:44.56 | xibalba | igcewieling, sorry i'm not using he right terms. I want a 302 to essentially happen |
| 15:45.00 | dokma | I don't see any examples of specifying a file so I assume that must be it... |
| 15:45.00 | igcewieling | dokma: no. |
| 15:45.17 | igcewieling | xibalba: try using the Transfer dialplan app |
| 15:45.18 | [TK]D-Fender | that is the class name |
| 15:45.32 | xibalba | because I dont want the bandwidth used on the 1st server hwen dialing the 2nd server. It should do a 302 back to Level3 and the call should only use the bandwidth of the 2nd server (weird issue why right now) |
| 15:45.33 | dokma | igcewieling: ? |
| 15:45.39 | [TK]D-Fender | dokma, that is the class name <- |
| 15:45.40 | xibalba | ah-ha transfeR dial plan, thanks i'll look into it |
| 15:45.48 | dokma | ... |
| 15:45.52 | igcewieling | xibalba: you would be horrified at how often that doesn't work. |
| 15:45.58 | [TK]D-Fender | dokma, the sample config shows you how to point to to folder with files |
| 15:46.05 | dokma | I see that |
| 15:46.14 | dokma | But how to specify the file itself |
| 15:46.19 | [TK]D-Fender | you don't |
| 15:46.31 | [TK]D-Fender | if you want a single file then make a folder with only one file |
| 15:46.48 | xibalba | my problem is that the firewall currently in that datacenter is old and decrepid and running only 10mbit. they're hitting 9.5bit allot of the calls from the DC are transfered to agents at another office |
| 15:46.51 | dokma | I want to play one music file during the ring. |
| 15:46.56 | Samot | xibalba: Will Level3 accept a 3xx reply? |
| 15:47.00 | dokma | So I must make a folder for that one file? |
| 15:47.02 | [TK]D-Fender | <[TK]D-Fender> if you want a single file then make a folder with only one file <------------------------- |
| 15:47.13 | xibalba | but I'm seeing/trying to verify that the calls are going from L3 to the DC, then out the DC to L3 then back into the office, thus consuming extra b/w in the data center |
| 15:47.14 | dokma | That looks rather stupid... |
| 15:47.16 | igcewieling | xibalba: a 302 redirect has the best chance of working. |
| 15:47.17 | dokma | Thank you |
| 15:47.17 | xibalba | Samot, good question i presumed so |
| 15:47.23 | Samot | No.. |
| 15:47.36 | [TK]D-Fender | Not many people want the exact same single recording every time |
| 15:47.47 | Samot | Diversions are not really things carriers want. |
| 15:48.09 | [TK]D-Fender | imagine if you have to call someone many times a day and it's always the same song playing EVERY time. You'll start feeling like you're living in the movie Groundhog Day |
| 15:48.11 | dokma | Well I'll want different recordings for different languages later on. |
| 15:48.54 | dokma | So I'll need one folder per file in order to be able to specify which file to play for which calling codes? |
| 15:49.30 | [TK]D-Fender | yes |
| 15:50.55 | Samot | xibalba: Does Level3 offer failover destinations? |
| 15:51.28 | igcewieling | Samot: I'm pretty sure they don't. Level 3 is one of our carriers. |
| 15:51.47 | Samot | Well they probably won't accept 3xx |
| 15:51.56 | Samot | It's not their job to divert your calls. |
| 15:52.33 | Samot | And if they don't offer failover routes then sending a 408 type reply to trigger it.. |
| 15:52.36 | Samot | Won't help. |
| 15:52.40 | igcewieling | Samot: oh, I thought you meant carrier controlled failover destinations like setting the destination number in Level 3's routing tables. I don't think they offer that. |
| 15:52.58 | Samot | That's shocking. |
| 15:53.00 | igcewieling | a 302 is a standard SIP message. |
| 15:54.17 | xibalba | thanks guys, this gives me some good direction and items to check out. |
| 15:54.36 | Samot | I never said they weren't standard. |
| 15:55.22 | igcewieling | I know at least Verizon (SIP) does. I used to use it. |
| 15:55.31 | Samot | 3xx are redirect/diversions |
| 15:55.54 | Samot | Most carriers do not like having to redirect your calls to an unknown/untrusted destination... |
| 15:56.00 | igcewieling | *nod* Polycoms send it when they have forwarding on. |
| 15:56.09 | Samot | Sure, to the PBX |
| 15:56.15 | Samot | Not the carrier. |
| 15:56.19 | igcewieling | Samot: ah, I was redirecting to one of our own servers, maybe that's why it worked. |
| 15:56.31 | *** join/#asterisk areski (~areski@15.red-83-33-189.dynamicip.rima-tde.net) |
| 15:56.44 | igcewieling | specifically I was 302'ing fax calls to a seperate server. |
| 15:56.51 | Samot | Right. |
| 15:57.05 | Samot | 3xx are results of the endpoint saying "I don't want this call, I want to send it here" |
| 15:58.09 | Samot | Also how ATA and like devices get hacked. |
| 15:58.24 | igcewieling | xibalba: why not route calls direct? Are people calling the main location and are transferred to the other location? |
| 15:58.28 | Samot | And send calls to fraud/International locations. |
| 15:58.54 | igcewieling | Samot: if we didn't put the right diversion header with the correct BTN the carrier rejects the call. |
| 15:58.59 | igcewieling | Well, Verizon at least. |
| 15:59.14 | Samot | Right, because that means you have to handle the message first. |
| 15:59.18 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 15:59.22 | Samot | They are forcing you to handle the message before sending it back. |
| 15:59.31 | igcewieling | Level3, BTW, will allow the call and bill it to a "default" number on your level 3 account. |
| 15:59.35 | Samot | They just aren't accepting the message willy nilly. |
| 16:00.46 | xibalba | igcewieling, router calls direct? as in setup a trunk to that other system then do a 302 direct to it? that's a good idea, and as i'm going through the sip.conf gifle now i just noticed there is a trunk setup to that other system but it doesn't appear to be used in a dial plan |
| 16:01.20 | Samot | There are no 302's in Asterisk. |
| 16:01.21 | igcewieling | no, set up a trunk from your carrier to your 2nd location and route the calls direct to that pbx. |
| 16:01.35 | Samot | Call comes in from your carrier to PBX, you decide what to do with it. |
| 16:01.38 | igcewieling | Samot: the Transfer application sends a 302 |
| 16:01.46 | Samot | OK. |
| 16:01.54 | Samot | Why would the transfer app be used? |
| 16:02.03 | Samot | Why are we talking about routing calls shittly? |
| 16:02.04 | igcewieling | Samot: when you need to generate a 302. |
| 16:02.17 | Samot | Who's he sending the 302 too? |
| 16:02.42 | Samot | I thought you asked "why don't you route from the main PBX?" |
| 16:02.49 | Samot | Why would a 302 be involved in that?! |
| 16:02.56 | igcewieling | Don't know about this person, but when *I* used transfer a year or two ago it was generated on asterisk and sent to the carrier. |
| 16:04.12 | Samot | If the call is ending up on PBX B, why is it being sent to PBX A in the first place? |
| 16:04.28 | Samot | So you can do all this to avoid using PBX A and get the call to PBX B? |
| 16:04.37 | igcewieling | Samot: that is what I asked when I said "xibalba: why not route calls direct? Are people calling the main location and are transferred to the other location?" |
| 16:04.47 | Samot | OK. |
| 16:04.52 | Samot | Missed that one. |
| 16:04.56 | Samot | Good question. |
| 16:06.54 | xibalba | It's an auto-dialer for patient health care to remind them about yada yada....so this Genesys phone system gets an incoming XML/SOAP request from an App, dials out to the patient (from the data center), then works with the patient using a voice recognition system. If the patient pushes 0 then the system will call out to the Customer service reps pbx |
| 16:07.08 | xibalba | 99% of the time its the system dialing the patient |
| 16:07.38 | Samot | And based on their DTMF response it gets sent to the proper location? |
| 16:07.48 | xibalba | yes, currently only one DTMF response |
| 16:07.55 | Samot | You can't 302 that. |
| 16:07.56 | xibalba | 0 |
| 16:07.59 | Samot | You're already in the call. |
| 16:08.07 | Samot | Not only that, YOU made it. |
| 16:08.27 | xibalba | ah so you can't 302 a call you originated? only one thats incoming? |
| 16:08.35 | Samot | Right. |
| 16:08.39 | xibalba | didn't know that |
| 16:08.43 | Samot | It's a redirection/diversion. |
| 16:09.02 | Samot | 10:57:03 AMÂ <Samot>Â 3xx are results of the endpoint saying "I don't want this call, I want to send it here" |
| 16:09.24 | xibalba | missed that, ty |
| 16:09.36 | Samot | You have no choice but to dial that call from the PBX that originated the call. |
| 16:09.45 | Samot | Since that is where the DTMF response is going. |
| 16:10.23 | xibalba | even if i no longer require any other dtmf responses on the call after that? |
| 16:10.34 | Samot | Yes. |
| 16:10.39 | xibalba | ok |
| 16:10.44 | Samot | You originated the call. |
| 16:10.46 | Samot | They picked up. |
| 16:10.50 | Samot | You played a recording.. |
| 16:10.58 | Samot | They respond with DTMF |
| 16:11.09 | Samot | What do you do with that DTMF response? |
| 16:11.13 | Samot | If 0 dial X |
| 16:11.44 | Samot | If not 0 do something else like hangup. |
| 16:12.19 | *** join/#asterisk Kaian (~kaian@6.62-99-78.static.clientes.euskaltel.es) |
| 16:12.37 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 16:12.37 | xibalba | ok makes sense, thanks for taking the time |
| 16:12.58 | [TK]D-Fender | <xibalba> ah so you can't 302 a call you originated? only one thats incoming? <- originate the call. Dump it into the dial and Transfer() |
| 16:13.12 | [TK]D-Fender | dialplan* |
| 16:13.16 | Samot | That's what he's doing, kinda. |
| 16:13.30 | Samot | Originating the call, playing back a recording, waiting for DTMF |
| 16:13.37 | Samot | Then dialing the other PBX |
| 16:13.44 | [TK]D-Fender | ok, the call Transfer to toss it off |
| 16:13.51 | [TK]D-Fender | instead of Dial |
| 16:13.55 | Samot | OK |
| 16:14.02 | Samot | bxfer. |
| 16:14.05 | Samot | Get it. |
| 16:15.02 | Samot | He thought he could send a 302 as an in-dialog reply.. |
| 16:15.04 | Samot | Which, no. |
| 16:15.36 | [TK]D-Fender | What Does Transfer actually show? |
| 16:15.49 | Samot | I asked for a debug when he first asked. |
| 16:16.32 | Samot | 10:40:38 AM <Samot> asterisk -rvvvvvvvvvvv |
| 16:16.32 | Samot | 10:40:55 AM <Samot> Make the call..see how the call is being processed. |
| 16:17.26 | xibalba | i know Samot , can't do that right this moment. |
| 16:18.14 | [TK]D-Fender | Why not? Originate to your own phone, toss it to a random IP and just see what gets generated |
| 16:18.41 | [TK]D-Fender | actually.. you odn't even NEED to Originate. |
| 16:18.54 | [TK]D-Fender | just CALL to static dialplan that calls Transfer() |
| 16:18.55 | [TK]D-Fender | same thing |
| 16:21.08 | xibalba | there is no transfer() call in the current dial plans. |
| 16:22.01 | [TK]D-Fender | Go add one |
| 16:22.34 | *** join/#asterisk friedrich (~friedrich@aextron.de) |
| 16:22.37 | [TK]D-Fender | this is for you to call and test. This doesn't have to affect any other existing dialplan |
| 16:22.45 | [TK]D-Fender | If yuo want to see what generates just CALL IT |
| 16:23.13 | *** part/#asterisk igcewieling (~ewieling@ip98-170-211-145.pn.at.cox.net) |
| 16:26.53 | *** join/#asterisk miralin (~Thunderbi@194.8.128.50) |
| 16:28.15 | *** join/#asterisk miralin1 (~Thunderbi@194.8.128.50) |
| 16:28.32 | MacroMan | I'm looking for info on how to achieve prefixless local dialling, but I'm struggling to find info on Google. |
| 16:28.37 | MacroMan | Any advice? |
| 16:29.18 | [TK]D-Fender | Make your pattern match whatever you want. Dial your provider however you want |
| 16:29.29 | [TK]D-Fender | I don't see what there is to give "advice" on |
| 16:29.40 | *** join/#asterisk jkroon (~jkroon@uls-154-73-32-13.wall.uls.co.za) |
| 16:29.45 | [TK]D-Fender | I dial 7-digits from my phone and my dialplan sends 10 to my provider |
| 16:30.26 | [TK]D-Fender | There is nothing to Google, because Dial() calls whatever you pass it. |
| 16:31.29 | [TK]D-Fender | Don't want a prefix? Don't dial extra junk in the front. Don't make your extens in a way that expects extra filler |
| 16:41.51 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 16:42.23 | Samot | I make a killing in NM because of 7 digit dialing. |
| 16:43.43 | Samot | Mainly with motels/hotels. |
| 16:44.23 | Samot | Because they all have 25 year old PBXes, the telecoms still allow it but when they want to move to SIP, none of the SIP providers allow it. |
| 16:47.30 | MacroMan | Sorry, I'm just really new to Asterisk and I'm still learning the basics of the dialplan |
| 16:50.46 | Samot | MacroMan: Here's how it works, in a nutshell.. |
| 16:50.50 | [TK]D-Fender | You are the one putting whatever is going in between those brackets for the apps you call. |
| 16:51.08 | Samot | Each phone has it's own "dial plan", which is what types of digit patterns it will accept. |
| 16:51.27 | Samot | The the phone sends those digits to Asterisk. |
| 16:51.38 | Samot | You process them the way you want. |
| 16:52.10 | Samot | So if the phone sends NXXXXXX then you look for that pattern.. |
| 16:52.39 | Samot | And then handle as you wish. |
| 17:00.27 | MacroMan | I get that bit. I'm just trying to resolve mental conflicts around how to achieve my plan. |
| 17:01.20 | *** join/#asterisk miralin (~Thunderbi@194.8.128.50) |
| 17:01.45 | Samot | So what is the plan? |
| 17:01.59 | Samot | What do you want the user to be able to do? |
| 17:02.07 | Samot | That is "prefixless" |
| 17:02.44 | *** join/#asterisk tuxd00d (~tuxd00d@172.56.17.177) |
| 17:04.02 | MacroMan | It's OK I think I'm starting to get my head around stuff. By prefixless, I just meant dialling out over a trunk without a 9 first |
| 17:04.25 | *** join/#asterisk tristero (~al.f.zero@unaffiliated/transfinite) |
| 17:04.40 | MacroMan | So differentialting what should be a local SIP call or a call over my trunk |
| 17:05.20 | Samot | So you're saying that NXXXXXX would route locally on the pbx and over a SIP trunk to the PSTN? |
| 17:06.54 | [TK]D-Fender | They only reason you dial with a 9 in front is because you made your extn have a 9 in front |
| 17:07.02 | [TK]D-Fender | So remove it and stop dialing the 9 first |
| 17:13.52 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 17:16.18 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 17:16.37 | *** join/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
| 17:36.00 | *** join/#asterisk tuxd00d (~tuxd00d@98.180.132.25) |
| 17:37.27 | *** join/#asterisk blistov (~bens@S0106e03f490494e9.vs.shawcable.net) |
| 17:43.04 | blistov | Hey guys. Still fighting with this VoIP issue. SDP specifies I should be sending RTP from port A to trunk port B, but I immediately see (on my firewall) an ICMP Unreachable from my PBX. Immedaitely after that, the trunk continues sending back to port A and the PBX keeps sending to port B, but PFsense changes the outgoing stream from port A to port C. |
| 17:43.13 | blistov | Problem is intermittent, goes away for months at a time and then returns with no changes to our internal infrastructure |
| 17:43.13 | blistov | <blistov> I've been told to try many things, like using 1:1 NAT (didn't work), or setting up OUTBOUND NAT to the trunk provider, with STATIC PORT enabled (did nothing). I have no idea how PFsense is deciding to just change the outbound port. PBX keep ssending from port A as agreed upon in SDP, but PFsense stops routing it or changes it to port C. |
| 17:43.32 | blistov | PFsense guys insist this is an asterisk/Fpbx issue, and Fpbx guys insist it's a PFsense issue. |
| 17:43.39 | blistov | Any wild ass theories? |
| 17:49.53 | Samot | Did you turn off port randomization and SIP helpers? |
| 17:50.43 | *** join/#asterisk tuxd00d_ (~tuxd00d@196.52.18.55) |
| 17:56.14 | *** join/#asterisk tuxd00d (~tuxd00d@wsip-184-188-173-39.ph.ph.cox.net) |
| 17:56.29 | blistov | Samot: I setup manual outbound nat, with a rule for traffic destined for our trunk provider (by hostalias) for all ports within' the asterisk configured range, and later for all ports from 10000-650000 |
| 17:56.43 | blistov | No affect. SIP helpers... such at? |
| 17:56.54 | blistov | such as? I'm not running siproxd if that's what you mean. |
| 17:58.20 | *** join/#asterisk puzzola (~puzzola@unaffiliated/puzzola) |
| 17:59.23 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 18:06.34 | drmessano | SIP ALG |
| 18:06.38 | drmessano | Disable it |
| 18:06.44 | drmessano | PFSense is the WORST |
| 18:09.43 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 18:11.48 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 18:20.51 | Samot | By far. |
| 18:22.35 | *** join/#asterisk FinboySlick (~shark@74.117.40.10) |
| 18:24.23 | FinboySlick | I have a mystery stream of UDP data from the asterisk process to another host. (122 byte long, at 20ms intervals). It looks like audio but there's no RTP header on the packets. Is there a non-disruptive way for me to see which part of asterisk is causing it? |
| 18:24.43 | FinboySlick | (this is not a setup that I manage, I'm just a network admin trying to help a couple goofs) |
| 18:25.25 | FinboySlick | netstat confirms that asterisk is handling that socket. I just don't know what it is. |
| 18:26.09 | lorsungcu | FinboySlick: what's the other host? |
| 18:26.39 | FinboySlick | The audio core of a Metaswitch 2000. |
| 18:28.44 | FinboySlick | As stated before, it's probably audio. I just don't know which part of asterisk is sending it and why. |
| 18:29.01 | *** join/#asterisk igcewieling (~ewieling@ip98-170-211-145.pn.at.cox.net) |
| 18:29.11 | FinboySlick | And the lack of rtp header sort of has me puzzled. |
| 18:40.15 | *** join/#asterisk averythomas (~averythom@2604:6000:1523:4002:222:19ff:fe2b:48fa) |
| 19:15.24 | nemmeviu | FinboySlick: asterisk is the sender? |
| 19:16.38 | FinboySlick | Yes. |
| 19:17.12 | FinboySlick | I suspect that it's a specific sip channel, but there's no way to associate it with an udp port to confirm. |
| 19:17.43 | nemmeviu | FinboySlick: oww, nice trick |
| 19:19.27 | nemmeviu | FinboySlick: from the metaswitch you can see some data? |
| 19:20.49 | FinboySlick | nemmeviu: I don't have access to it, but i can dump the network all the way to the switch port and see the data, yes. It makes it out to the network. |
| 19:26.27 | *** join/#asterisk andresmujica (~andresmmu@ubuntu/member/andresmujica) |
| 19:26.44 | nemmeviu | FinboySlick: I do not know if what I'm going to say makes sense. |
| 19:26.52 | nemmeviu | FinboySlick: Comment this to hear your experience. |
| 19:27.07 | nemmeviu | FinboySlick: but you can make: |
| 19:28.35 | nemmeviu | FinboySlick: iptables -I OUTPUT -i iface -s METASWITCH -j LOG --log-prefix "not_start_conn: " |
| 19:28.58 | *** join/#asterisk areski (~areski@80.174.128.53.dyn.user.ono.com) |
| 19:29.09 | nemmeviu | FinboySlick: tcpdump -pnv -i iface udp and host METASWITCH -xX -s 2048 -w dump.pcap |
| 19:29.38 | FinboySlick | nemmeviu: Hmmm. Are you trying to suggest looking at the conntrack table to figure out which call this is related to? |
| 19:29.38 | nemmeviu | FinboySlick: then you can confirm if your device start this connection |
| 19:31.22 | nemmeviu | FinboySlick: yes, if is related and what device start the udp traffic |
| 19:33.52 | FinboySlick | OK. But there's no way for asterisk to say that say call 4CA168A0@192.168.0.40 has initiated an udp rtp stream to port 33252. |
| 19:36.35 | nemmeviu | FinboySlick: I imagined that it was always happening, then if you block the output, and turn on the tcpdump, you can get the next event |
| 19:36.40 | FinboySlick | turning on rtp debug, I do see: "Sent RTP packet to 192.168.0.14:33010 (type 00, seq 062427, ts 1877665072, len 000160)" So I know that asterisk is sending it. I just don't know what call initiated it. |
| 19:37.39 | FinboySlick | nemmeviu: Yeah, but that would sort of defeat the 'non-disruptive' aspect of my query. |
| 19:38.21 | FinboySlick | 192.168.0.14:33010 *is* the stream I'm hunting down, btw. |
| 19:38.34 | *** join/#asterisk zopsi (~zopsi@dir.ac) |
| 19:39.47 | nemmeviu | FinboySlick: oowwww.. nice! you're right. nice nice |
| 19:41.18 | FinboySlick | I still don't have a way to link it to a specific call though :P |
| 19:41.35 | *** join/#asterisk andresmujica (~andresmmu@ubuntu/member/andresmujica) |
| 19:44.18 | nemmeviu | FinboySlick: you comment that the header dont have RTP information, but the traffic is output from RTP ports? |
| 19:46.15 | *** join/#asterisk Demon_VoIP (~demon@109.60.222.253) |
| 19:46.25 | FinboySlick | Well, wireshark doesn't ID it as rtp (it does show other streams as RTP) I didn't specifically look at the hex data to check if there was indeed no RTP header. |
| 19:47.23 | FinboySlick | I do know that that stream has been playing for several weeks if not months, so it's not a 'normal' call. |
| 19:47.25 | *** join/#asterisk friedrich (~friedrich@aextron.de) |
| 19:47.41 | *** join/#asterisk defsdoor (~andy@cpc35-sutt4-2-0-cust184.19-1.cable.virginm.net) |
| 19:48.11 | nemmeviu | FinboySlick: nice! |
| 19:48.57 | nemmeviu | FinboySlick: thanks for this share my friend |
| 19:49.25 | FinboySlick | I haven't played with asterisk in years and years. I sort of missed it. |
| 19:55.56 | nemmeviu | FinboySlick: mister, maybe you can use: tcpdump -pnv -i iface host metaswitch_host -xX -s 2049 -w some_file.pcap |
| 19:56.33 | nemmeviu | FinboySlick: for 1 day, this can't make your server down, or broke something |
| 19:57.12 | nemmeviu | FinboySlick: than, you can see if this host make others connections, or other scans. is my brain limit |
| 19:59.35 | FinboySlick | <PROTECTED> |
| 20:01.34 | nemmeviu | FinboySlick: wwwnnn |
| 20:01.41 | nemmeviu | FinboySlick: now I understand |
| 20:01.48 | nemmeviu | FinboySlick: =( |
| 20:05.02 | FinboySlick | nemmeviu: It's off my hands now though. You might not have solved it but thanks for responding anyway. It's appreciated. |
| 20:05.57 | *** join/#asterisk sekil (~sekil@cable-89-216-223-20.dynamic.sbb.rs) |
| 20:07.03 | nemmeviu | FinboySlick: Thank you my friend! Success! |
| 20:08.14 | *** part/#asterisk FinboySlick (~shark@74.117.40.10) |
| 20:12.20 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 20:45.33 | *** join/#asterisk samwierema (~samwierem@82.169.167.198) |
| 20:47.55 | *** join/#asterisk Oatmeal (~Suzeanne@2001:558:600d:c:35f1:4a2f:63ab:d8ac) |
| 21:04.21 | *** join/#asterisk kayatwork (~kayfox@orca.zerda.net) |
| 21:20.24 | *** join/#asterisk jaybehijaybehi (~jaybehi@167.114.20.106) |
| 21:20.32 | jaybehijaybehi | hi |
| 21:21.02 | jaybehijaybehi | https://issues.asterisk.org/jira/browse/ASTERISK-26400 |
| 21:21.16 | jaybehijaybehi | app_queue: Queue member stops being called after AMI "Redirect" action for queues with wrapuptime |
| 21:21.23 | jaybehijaybehi | any patch for that or solution? |
| 21:21.50 | jaybehijaybehi | eee |
| 21:21.58 | file | anything would be on the issue. |
| 21:22.36 | jaybehijaybehi | Resolution: Unresolved |
| 21:43.02 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 22:00.51 | *** join/#asterisk wonderworld (~ww@ip-176-198-197-145.hsi05.unitymediagroup.de) |
| 22:05.54 | *** join/#asterisk NirS (~Nir_S@12.206.107.11) |
| 22:06.53 | NirS | Hi All |
| 22:06.59 | NirS | Greetings from ITExpo |
| 22:26.09 | *** join/#asterisk shootbird (~quassel@205.185.122.214) |
| 22:30.33 | *** join/#asterisk adeeln (~adeel@fw1.ridgeway.scc-zip.net) |
| 22:31.07 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 22:40.09 | *** join/#asterisk MaliutaLap (~nobusines@unaffiliated/maliuta) |
| 22:41.36 | *** join/#asterisk Maliuta (~nobusines@unaffiliated/maliuta) |
| 22:46.16 | *** join/#asterisk klow (~klow@66.114.139.162) |
| 22:58.57 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 23:08.48 | *** join/#asterisk klow (~klow@66.114.139.162) |
| 23:33.21 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 23:43.25 | *** join/#asterisk friedrich (~friedrich@aextron.de) |
| 23:44.12 | *** join/#asterisk tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 23:53.19 | *** join/#asterisk Oatmeal (~Suzeanne@2001:558:600d:c:35f1:4a2f:63ab:d8ac) |