| 00:19.20 | *** join/#asterisk paulgrmn_ (~paulgrmn@184.75.212.68) |
| 01:05.35 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 01:27.36 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 01:52.00 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 02:50.21 | *** join/#asterisk jmordica (680391a0@gateway/web/freenode/ip.104.3.145.160) |
| 02:51.49 | jmordica | hi all, I'm running asterisk 16 latest on centos 6. opus transcoding requires glibc 2.14 (but centos 6 has 2.12 as default). I can compile and use glibc 2.14 and get asterisk running but it breaks other things.. Is there a way to tell the opus module to use a custom path for the updated glibc lib? |
| 02:51.59 | jmordica | instead of the default libc path? |
| 03:01.45 | jmordica | Or can i compile and install the binary hard coding the libc path? |
| 03:21.07 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 03:50.41 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@176.98.158.240) |
| 06:15.16 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
| 06:38.45 | *** join/#asterisk ircarcs (~quassel@169.9.159.77.rev.sfr.net) |
| 07:09.30 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:f857:ff46:4e73:cc93) |
| 07:41.42 | *** join/#asterisk jkroon (~jkroon@105.12.2.128) |
| 07:44.51 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 07:53.35 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
| 08:41.31 | *** join/#asterisk Chotaire (chotaire@unaffiliated/chotaire) |
| 08:55.43 | *** join/#asterisk aness (~aness@cm-84.209.49.44.getinternet.no) |
| 08:58.30 | *** join/#asterisk Oatmeal (~Suzeanne@2600:8802:1500:5f5:5d8a:a150:d54b:6970) |
| 09:01.39 | *** join/#asterisk sp00fed (4ebc739b@gateway/web/freenode/ip.78.188.115.155) |
| 09:01.45 | sp00fed | hi all |
| 09:02.04 | sp00fed | i need help about recovering .gsm files from a formatted disk,anyone care to help? |
| 09:08.21 | sp00fed | ok,before that,is there anyone alive? |
| 09:10.37 | bhuddah | yes. |
| 09:10.50 | bhuddah | but file recovery is not the speciality here i guess. |
| 09:26.50 | sp00fed | yep,i guess so too,but maybe someone knows of a recovery software that recognizes .gsm files,just a hope ;) |
| 09:29.55 | *** join/#asterisk aberrios (545cd2cd@gateway/web/freenode/ip.84.92.210.205) |
| 09:31.29 | aberrios | hey all, currently looking at Ast 16.3.0 and ConfBridges SFU support. Pretty nifty. Having some trouble though with Asterisk sending the stream back out to parties. Everything seems ok with video_mode=follow_talker but video_mode=sfu does not seem to start any video traffic. Audio is fine though. |
| 09:32.29 | aberrios | Also.. is this normal?? Confbridge seems to add two announcer channels into the conference (no matter how many parties, tho I guess that's irrelevant). |
| 09:38.55 | file | due to the way channels have to be handled, normal to have two |
| 09:38.57 | file | and what client? |
| 09:40.54 | aberrios | SIP.js |
| 09:41.20 | aberrios | asterisk looks to be receiving video okay from the client |
| 09:42.04 | file | there's extra work that has to be done on the client side to provide the extra media streams and such |
| 09:43.43 | aberrios | the client can see the remote streams, but there does not seem to be video traffic coming, only audio. In sfu mode.. In follow_talker everything works great. |
| 09:44.12 | file | what is the configuration? |
| 09:44.24 | file | (PJSIP endpoint configuration) |
| 09:44.49 | aberrios | ```[webrtc_client] type=endpoint aors=webrtc_client auth=webrtc_client dtls_auto_generate_cert=yes webrtc=yes ; Setting webrtc=yes is a shortcut for setting the following options: ; use_avpf=yes ; media_encryption=dtls ; dtls_verify=fingerprint ; dtls_setup=actpass ice_support=yes ; media_use_received_transport=yes ; rtcp_mux=yes context=default disallow=all allow=vp8,opus bundle=yes max_audio_streams=5 max_video_streams=5 direct_ |
| 09:44.52 | aberrios | gah |
| 09:45.18 | file | seems fine, so dunno what it would be |
| 09:45.28 | file | we use the functionality every day |
| 09:46.09 | file | not with SIP.js mind you |
| 09:46.18 | aberrios | is there a way to debug video traffic egressing asterisk? |
| 09:46.31 | aberrios | guess I could wiresharek it |
| 09:46.57 | file | rtp set debug on will also show it, and you can distinguish the traffic based on payload ID |
| 09:48.20 | aberrios | ah yes,, rtp debug might give me some pointers. |
| 09:49.08 | file | you'd also want to double check the SDP and ensure that the added streams were negotiated and accepted |
| 09:51.19 | aberrios | iirc on Friday i saw that they were, thanks. :+1: |
| 09:51.37 | aberrios | been a whole weekend and beer since then,, best double check |
| 10:20.02 | *** join/#asterisk jkroon (~jkroon@105.12.2.128) |
| 10:38.30 | *** join/#asterisk ircarcs (~quassel@169.9.159.77.rev.sfr.net) |
| 10:49.31 | *** join/#asterisk mou (~donwillia@37.97.50.103) |
| 10:57.19 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 11:00.28 | *** join/#asterisk emsjessec (~emsjessec@96.56.225.51) |
| 11:08.11 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 11:24.10 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 11:37.16 | *** join/#asterisk gerhard7 (~gerhard7@89.200.41.74) |
| 11:42.40 | *** join/#asterisk miralin (~Thunderbi@81.177.58.137) |
| 11:54.20 | *** join/#asterisk Chotaire (chotaire@unaffiliated/chotaire) |
| 12:14.54 | *** part/#asterisk vn971 (~quassel@2a02:7aa0:1619::bac5:9483) |
| 12:23.22 | *** join/#asterisk jkroon (~jkroon@105.12.2.128) |
| 12:33.22 | jkroon | if you receive an incoming SIP 100 Trying for a Call-Id which you did not generate (ie, someone is spoofing INVITEs from your IP), how would asterisk respond to that? |
| 12:33.26 | jkroon | (chan_sip) |
| 12:34.21 | file | it'd likely ignore it |
| 12:35.25 | jkroon | ok, ignoring asterisk, what should be the right response? |
| 12:38.04 | file | you can't really do anything... so... nothing? |
| 12:38.26 | jkroon | so there is no way to tell the remote side that the Call-Id is invalid? |
| 12:38.35 | jkroon | and that the call should be CANCELed? |
| 12:39.10 | file | no idea |
| 12:42.06 | *** join/#asterisk ghoti (ghoti@dev-160.experiencepoint.com) |
| 12:49.13 | seanbright | if someone is spoofing, why would they care about a negative response? |
| 12:50.42 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 12:53.22 | jkroon | seanbright, i care if they're spoofing me. |
| 12:53.38 | Samot | Do you get anything after the 100 Trying? |
| 12:54.07 | jkroon | so: attacker: INVITE: premium@somewhere ... upstream: 100 Trying, asterisk ignored? ... upstream 200 OK ... since attacker controls recipient spoofs an ACK ? |
| 12:54.27 | jkroon | Samot, this is a hypothetical question that's been raised to me and i realised i don't know. |
| 12:54.39 | Samot | Well 100 Trying is a provisional response. |
| 12:54.46 | Samot | Which is a reply to an INVITE. |
| 12:56.49 | Samot | Do any other provision responses follow? Because there should be some. |
| 12:57.05 | jkroon | likely, eventually we'll get a 200 OK. |
| 12:57.15 | jkroon | which needs to be ACKed. |
| 12:57.45 | Samot | So how are they spoofing your IP? |
| 12:58.02 | Samot | What is the reason this hypothetical question was posed? |
| 12:58.46 | jkroon | so: given that our provider IP is know, as well as ours, is it possible for an attacker to abuse that knowledge to make calls for our cost via the upstream provider? question posed by an investor. |
| 12:59.04 | Samot | No. |
| 12:59.24 | *** join/#asterisk as3ty_ (uid332392@gateway/web/irccloud.com/x-woevzamcqrdhnvma) |
| 12:59.39 | jkroon | now i started thinking, if the attacker can spoof an INVITE from our IP to that of the provider, and they're using host based auth ... how would the INVITE not get processed? |
| 12:59.40 | Samot | I mean really the answer can be yes.. |
| 13:00.01 | Samot | But that would lead to more hypothetical's. |
| 13:00.09 | Samot | Just like a discussion on MiTM attacks. |
| 13:00.26 | Samot | How did they get this? How do you reply to an INVITE that doesn't exist in memory? |
| 13:00.38 | Samot | How will they actually sustain a call to cost you money? |
| 13:01.10 | jkroon | provider would receive the INVITE, and respond with 100 Trying, 180 Ringing, possibly 183 Progress or other provisionals ... and then pass 200 OK. |
| 13:01.29 | *** join/#asterisk jgowdy (sid239878@gateway/web/irccloud.com/x-svnzttfawuccaukd) |
| 13:01.44 | Samot | So they're going to not only spoof your source IP they are going to spoof everything down to the Record Route? |
| 13:01.51 | jkroon | if the attacker can somehow coordinate an ACK to that 200 OK, then the call is established, if the provider doesn't bother with dropping a call without rtp ... |
| 13:01.52 | *** join/#asterisk DanFromUK (sid21651@gateway/web/irccloud.com/x-ximmtffovxypjrhy) |
| 13:01.53 | Samot | That would take the call completely out of their control? |
| 13:01.59 | *** join/#asterisk tris (tristan@camel.ethereal.net) |
| 13:02.14 | Samot | Uhm, if your provider isn't dropping calls that lack audio get a new provider. |
| 13:02.21 | Samot | No audio = No Call |
| 13:03.06 | Samot | Also since Asterisk will have no memory of this INVITE how can it process the replies? |
| 13:03.09 | jkroon | ok, so even if they drop a call with no audio after say 30s ... let's assume in the initial INVITE they put CDP that describes an IP under their control for RTP, if they guess symmetric RTP they can start generating RTP ... |
| 13:03.26 | Samot | Who's given the 200 OK? You? |
| 13:03.36 | jkroon | no, upstream, the INVITE went to them. |
| 13:03.36 | Samot | If that is the case, your RTP details are in the 200 OK |
| 13:04.01 | jkroon | upstream RTP is in the 200 OK, "my" RTP details are in the initial spoofed INVITE. |
| 13:04.02 | *** join/#asterisk drmessano (drmessano@pdpc/supporter/active/drmessano) |
| 13:04.14 | Samot | And do they have your IP? |
| 13:04.16 | Samot | And your ports? |
| 13:04.28 | Samot | So even if they have your IP, they won't have ports. |
| 13:04.38 | Samot | There won't be any RTP ports on the system for this. |
| 13:04.47 | Samot | Again, this is like MiTM attacks. |
| 13:04.55 | jkroon | they don't need. CDP doesn't require the RTP to go to the same IP as where the SIP frame came from. |
| 13:04.58 | Samot | You can sit here all day and give hypothetical's. |
| 13:05.21 | Samot | OK so now they are signalling through you but sending the RTP somewhere else.. |
| 13:05.22 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:05.22 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 13:05.26 | jkroon | so let's assume attacker is on IP C, then in the SDP in the initial INVITE he can put an RTP address of C:some_port. |
| 13:05.29 | Samot | You see how slippery this is getting? |
| 13:05.41 | Samot | How many times have you heard of this happening? |
| 13:05.45 | jkroon | Samot, which is why i posed the question. |
| 13:05.57 | Samot | Hypothetical's are pointless. |
| 13:06.00 | jkroon | Samot, in principle it's simpler to hack some unsuspecting PBX. |
| 13:06.07 | jkroon | fine, thanks Samot. |
| 13:06.20 | Samot | The answer for your investor is no. |
| 13:06.23 | Samot | Plain and simple. |
| 13:09.15 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 13:09.37 | Samot | The way you've described it so far the spoofer would never get the 200 OK and they would time out themselves. |
| 13:09.47 | Samot | Because they never got the provisioning response of 100 Trying. |
| 13:10.48 | Samot | I send an INVITE, it expects a reply. If that INVITE is crafted to spoof your IPs then all those replies would go to your IP not mine so I would never get the replies. By that logic, I would end up with a timeout for my INVITE attempt. |
| 13:13.14 | Samot | This is why they just rely on admin's having poor security and password requirements. |
| 13:13.27 | Samot | s/admin's/admins/ |
| 13:14.32 | jkroon | Samot, if I'm not expecting back those, and know when to ACK the 200 OK (by virtue of the call coming to me somewhere else), then in theory I believe it's possible to establish a call. And that's dangerous. |
| 13:14.44 | Samot | No. |
| 13:14.56 | Samot | I make a call from my phone, it's sending an INVITE. |
| 13:15.02 | Samot | It now expects a REPLY |
| 13:15.11 | file | you need to see the data from the responses in order to have all the information needed |
| 13:15.15 | Samot | If the replies are going to your IP and not mine...my device will timeout |
| 13:16.15 | jkroon | thanks file! Now that is more sensible, so there is data in the 200 OK which I need in order to generate the ACK in other words? Hard to guess information? |
| 13:16.36 | jkroon | Samot, not if it's designed to not time out. you're assuming "standards compliancy" here. |
| 13:17.01 | Samot | OK so the INVITE doesn't time out |
| 13:17.07 | Samot | So it sits there waiting for a reply |
| 13:17.08 | file | randomly generated tag information, and the ACK is also supposed to go to the Contact in the 200 OK |
| 13:17.13 | Samot | Which it never gets because it went to another IP |
| 13:18.09 | Samot | Because the originator of the INVITE (me) never got replies for the request, such as 200 OK, the originator (me) will never connect the call. |
| 13:18.12 | jkroon | file, ok, that makes sense thank you. and with randomly we really mean not predictable. |
| 13:18.16 | Samot | No 200 OK, no call. |
| 13:18.38 | file | yes. |
| 13:18.47 | jkroon | Samot, consider this as a multi-party thing, so: A=us (victim), B=upstream provider, C=attacker. |
| 13:18.55 | Samot | I AM. |
| 13:19.10 | jkroon | if C can get a call through B, seemingly from A, to itself (B number, for which it gets paid). |
| 13:19.16 | Samot | A = Originator of call, B = Destination of INVITE, C = where replies go |
| 13:19.29 | Samot | How does A know the call is established? |
| 13:19.36 | jkroon | so B will route the call to various other parties and eventually things connect, from B onwards ... |
| 13:19.47 | jkroon | it controls the end destination of the call, ie, it's to a number it controls. |
| 13:19.49 | Samot | How does the originator of the INVITE know the call is established? |
| 13:20.00 | Samot | If it doesn't get replies? |
| 13:20.41 | Samot | Just think about a legit call from a user, if a NAT issue stops the 200 OK getting back to them they can't establish their call. |
| 13:20.43 | jkroon | HE CONTROLS THE DESTINATION OF THE CALL, IE, THE SERVICE PROVIDER WILL ROUTE THE CALL TO IT VIA THE PSTN |
| 13:21.01 | Samot | No dude. |
| 13:21.06 | Samot | The Provider is the destination. |
| 13:21.12 | jkroon | he can then answer the call, anda second or so later, generate the ACK, but according to file some information from the 200 OK will be required to action that ACK. |
| 13:21.17 | Samot | SIP is a Request <> Reply transaction. |
| 13:21.35 | jkroon | the provider will generate a new INVITE to another provideer etc etc ... |
| 13:21.48 | Samot | You're missing the forest for the trees. |
| 13:22.06 | jkroon | so from our direct upstream it'll go to another provider, and follow the chain until eventually it gets back to a system under the control of the attacker. |
| 13:22.41 | jkroon | ok Samot i'm not going to engage with you further on this. file already answered my question in a much more sensible manner, thank you file. |
| 13:22.52 | Samot | OK. |
| 13:25.13 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
| 13:26.17 | jkroon | file, thanks, do you perhaps know what the general timeout is that a peer would wait after generating the 200 OK for an applicable ACK before dropping the call? |
| 13:27.09 | file | Timer B. 32 seconds. |
| 13:27.17 | jkroon | perfect, appreciate. |
| 14:03.51 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-khqnhkwtocdwupwd) |
| 14:03.51 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:04.46 | wonderworld | is sngrep able of running several days in a row for debugging a specific peer? |
| 14:07.56 | Samot | It will run for as long as you run it. The only limitations are the buffer size and your HDD space. |
| 14:08.38 | Samot | If you're capturing and writing to a pcap, for the HDD space. Otherwise just having output scroll, that is the buffer size for sngrep. |
| 14:08.54 | Samot | I think it defaults to 2000 packets or something around there. |
| 14:15.09 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-wfmesalqklrivokn) |
| 14:15.09 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:15.59 | tpdmoore | i'm using realtime sip peers, i am setting vmexten and mailbox via realtime, but there's another mailbox showing up in 'sip show peer' that ends in '@default' - i suspect this is caused by some default setting i'm not familiar with, anyone can point me towards it? |
| 14:16.38 | [TK]D-Fender | if you didnt' specify then it puts default |
| 14:17.06 | tpdmoore | i specified the same string in both 'mailbox' and 'vmexten' - and that is present, but there's a second mailbox listed that i did not specify |
| 14:17.49 | [TK]D-Fender | Could be a chached mistake |
| 14:17.55 | [TK]D-Fender | cached |
| 14:18.26 | tpdmoore | it is still there after restarting asterisk |
| 14:24.43 | wonderworld | Samot: thanks |
| 14:43.47 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-ixbblcbkueazdgdp) |
| 14:43.47 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 14:48.29 | *** join/#asterisk paulgrmn_ (~paulgrmn@184.75.212.68) |
| 15:05.17 | *** join/#asterisk furrymcgee (~furrymcge@lippydanger.jumpingcrab.com) |
| 15:32.19 | *** join/#asterisk mducharme (uid303982@gateway/web/irccloud.com/x-azmdhudfxucembrq) |
| 16:00.20 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
| 16:17.21 | *** join/#asterisk jkroon (~jkroon@105.4.7.163) |
| 16:37.45 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 18:16.12 | *** join/#asterisk mducharme (uid303982@gateway/web/irccloud.com/x-qwsjloilguxqkamy) |
| 18:27.26 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 18:50.10 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@176.98.158.240) |
| 18:54.06 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 19:09.50 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 19:15.52 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
| 20:12.13 | *** join/#asterisk josefig (~josefig@unaffiliated/josefig) |
| 20:13.00 | josefig | hello team, one question, is it possible add more than 1 pattern for dialplan? such as _1[21-43][94-44],n,DIAL(SIP/XYZ/${EXTEN}) ? |
| 20:13.28 | [TK]D-Fender | that is 1 pattern |
| 20:13.48 | [TK]D-Fender | which is logically broken |
| 20:13.57 | [TK]D-Fender | You need to go read the page on * patterns again |
| 20:14.21 | josefig | what i want to do is extensions from 121 to 143 and from 244-294 |
| 20:14.27 | josefig | sorry i see my mistake :P |
| 20:14.41 | [TK]D-Fender | [21-43] represents ONE digit. it allows 2, 1 through 4, and 3. The middle of course makes the exterior redundant |
| 20:15.08 | [TK]D-Fender | that's just the 2nd charater of your pattern |
| 20:15.17 | [TK]D-Fender | the 3rd follows the same kind of logic |
| 20:15.25 | Ellenor | why not just _1XX and _2XX ? |
| 20:15.36 | [TK]D-Fender | [] doesn't represent multiple characters. |
| 20:16.00 | [TK]D-Fender | <Ellenor> why not just _1XX and _2XX ? <- because there are obviously values that aren't to be considered valid |
| 20:16.43 | josefig | Ellenor, because my customer has extensions which are not included in the range and in addition extensions within the range that are from different group. |
| 20:18.08 | Ellenor | josefig: I hope you're good at writing Tcl or Perl scripts to generate extensions |
| 20:18.29 | josefig | i think i will add one entry for _1[21-43],n,Dial(...) and another one for _2[44-94],n,Dial(...) |
| 20:18.39 | josefig | Ellenor, hehe no worries, i have the script already to do that. |
| 20:18.58 | seanbright | yes, when i need to script something the first tool i reach for is tcl |
| 20:20.02 | [TK]D-Fender | josefig, no |
| 20:20.15 | [TK]D-Fender | [TK]D-Fender> [21-43] represents ONE digit. it allows 2, 1 through 4, and 3. The middle of course makes the exterior redundant |
| 20:21.56 | josefig | i see, the XXX are left. |
| 20:22.09 | josefig | opened the documentation :> |
| 20:22.23 | Ellenor | That's why you write Tcl |
| 20:24.01 | [TK]D-Fender | <josefig> what i want to do is extensions from 121 to 143 and from 244-294 <- this should require a minimum of 4 patterns to accomplish |
| 20:24.26 | [TK]D-Fender | 5 rather |
| 20:29.19 | [TK]D-Fender | checks out to head home |
| 20:40.50 | *** join/#asterisk droidasaur (~dr0id454u@pool-173-48-26-198.bstnma.fios.verizon.net) |
| 20:59.50 | *** join/#asterisk Oatmeal (~Suzeanne@2600:8802:1500:5f5:5d8a:a150:d54b:6970) |
| 21:06.39 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 21:07.07 | *** join/#asterisk pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 21:14.54 | *** join/#asterisk pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 21:23.16 | wdoekes | seanbright ð§ |
| 21:32.29 | *** join/#asterisk tinhei (~tinhei@tinhei.ovh) |
| 21:42.26 | *** join/#asterisk pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 22:03.36 | *** join/#asterisk salviadud (~ralfalfa@187-162-213-198.static.axtel.net) |
| 22:06.49 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 22:30.50 | *** join/#asterisk tuxd00d (~tuxd00d@unaffiliated/tuxd00d) |
| 22:38.02 | *** join/#asterisk overyander (~overyande@209.141.208.197) |
| 23:01.14 | *** join/#asterisk Chotaire (chotaire@unaffiliated/chotaire) |