01:14.58 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:e4e8:7859:db23:ab47) |
01:16.11 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:e4e8:7859:db23:ab47) |
01:16.44 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:e4e8:7859:db23:ab47) |
01:23.52 | *** join/#asterisk Bitcho (~jperez@unaffiliated/bitcho) |
01:31.05 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
01:45.43 | *** join/#asterisk deavmi (~quassel@165.255.253.203) |
02:03.42 | *** join/#asterisk setham (~textual@unaffiliated/setham) |
03:00.41 | *** join/#asterisk velix (~velix@unaffiliated/velix) |
03:00.48 | velix | Does "WaitTime" work when using AMI ? |
03:11.08 | velix | Can't I send Applications through AMI ? |
03:21.53 | velix | Hmm... callfiles are much beter. |
04:26.02 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
05:42.57 | *** join/#asterisk w10x12 (~w10x12@mab.sdf.org) |
05:48.31 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
05:48.54 | [TK]D-Fender | AMI isn't for "sending applications" |
06:42.05 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
07:30.22 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
08:22.09 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:e4e8:7859:db23:ab47) |
08:55.03 | *** join/#asterisk sysgrammer (~sysgramme@50.117.149.117) |
09:07.37 | *** join/#asterisk ganbold (~ganbold@202.21.108.8) |
09:11.27 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
11:30.43 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:e4e8:7859:db23:ab47) |
11:38.22 | *** join/#asterisk Alblasco1702 (~Alblasco1@ip5456b46b.speed.planet.nl) |
12:24.48 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:e4e8:7859:db23:ab47) |
12:59.49 | *** join/#asterisk vlt (~vlt@2a01:488:66:1000:57e6:5dd1:0:1) |
15:39.18 | *** join/#asterisk TandyUK (~admin@TandyUK/staff/James) |
15:55.54 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
16:12.42 | Kobaz | yoooo |
16:13.45 | *** join/#asterisk chandoo (~chandoo@pool-108-50-150-199.nwrknj.fios.verizon.net) |
16:14.35 | Samot | ????? |
16:14.43 | Kobaz | [TK]D-Fender: how's things |
16:15.31 | [TK]D-Fender | Kobaz, crazy times as I just did over 2 days of OT since the bell on Friday setting everyone up to work remote now.... |
16:16.25 | Kobaz | ah |
16:16.25 | Kobaz | yeah |
16:16.33 | Kobaz | w |
16:16.45 | Kobaz | wrong window |
16:26.41 | *** join/#asterisk deavmi (~quassel@165.255.253.203) |
16:31.24 | Samot | So VoIP.ms did the exact opposite of how things are heading and wouldn't you know, it's causing problems for their users. |
16:31.29 | Samot | Lol. |
16:33.07 | Kobaz | heh opposite? |
16:37.05 | Samot | Apparently VoIP.ms is forcing 10-digit CID numbers. |
16:37.17 | Samot | Which is the opposite of where things are heading in North America. |
16:37.52 | Samot | The use of 10-digit CID numbers is going away. It now causes too much confusing with International standard formats. |
16:37.53 | sibiria | what's the shortest MSISDN in USA/Canada? |
16:38.00 | sibiria | and ditto for stationary |
16:38.29 | Samot | It's going to require a full NANP format or a E.164 format. |
16:39.09 | Samot | sibiria: I guess it all depends. |
16:39.28 | Samot | I server a market where there are still only like 3 area codes for the entire state. |
16:39.46 | Samot | So the exchanges still support 7-digit dialing. NXX-XXXX |
16:40.01 | Samot | Because everyone is still pretty much in their local exchanges. |
16:40.08 | Samot | There isn't overlay. |
16:41.01 | Kobaz | oh right |
16:41.10 | Samot | So I allow them to send me 7 digits, I then prefix their 1+local area code |
16:41.25 | Kobaz | right |
16:41.27 | Samot | But for the most part US/Canada is 10 digit dialing. |
16:41.32 | Kobaz | yup |
16:41.48 | Samot | And while that's not changing, the CallerID can't be that anymore. |
16:42.21 | Samot | Because carriers are starting to present, specially mobile carriers, E.164 CallerID formats. |
16:43.03 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:e4e8:7859:db23:ab47) |
16:43.05 | Samot | So 10 digit CAllerID from Detroit MI looks like a Netherlands caller. |
16:43.14 | Samot | Because it's 313 area code. |
16:43.27 | Samot | 313NXXXXXX comes in as +313NXXXXXX |
16:44.45 | velix | I've set the CDR to log calls, which haven't been answered. But neither channelid, nor the called phonenumber (the extension) are stored in there. Anyone with an idea? |
16:46.36 | igcewieling | I find CallerID should be set to whatever allows the callee to call the number back from their calls list. |
16:47.43 | igcewieling | In my case for NANPA calls, that is 10 digit CallerID with a 1 prepended to it |
16:50.13 | sibiria | velix: use a custom format (through cdr_custom.conf) to get exactly all you need |
16:50.45 | velix | sibiria: I did, the fields are empty for unanswered calls. |
16:51.28 | sibiria | velix: some CDR data doesn't exist until the call is bridged. you may need to log other channel variables |
16:51.35 | sibiria | and supply other things in your call files |
16:51.55 | velix | sibiria: https://bpaste.net/XOUQ |
16:52.00 | velix | sibiria: Okay, I'll look up other stuff. |
16:52.06 | velix | Otherwise, I'll jsut archive the callfiles :) |
16:52.49 | velix | oops, that way the old enabled = no version. |
16:52.54 | velix | The real one is yes of course ;) |
16:55.39 | sibiria | i always do outward dialing by putting a few extra channel variables in the call file |
16:56.00 | velix | sibiria: Good idea, 1 sec |
16:56.32 | sibiria | e.g. cnid and recipient etc. |
16:57.36 | velix | yeah, good idea |
17:02.16 | velix | sibiria: Can I do this by SetCDRUserfield only or common SetVar? |
17:09.10 | sibiria | for a call file you specify this with SetVar |
17:09.20 | sibiria | Setvar: SOMETHING=blargh |
17:10.37 | *** join/#asterisk nimbius (~nimbius@2001:19f0:6001:449b:eb61:d3ab:56ad:3c46) |
17:10.46 | nimbius | hi asterisk, trying to use messageSend but getting Message: Message technology not found. |
17:11.08 | nimbius | nm |
17:11.12 | nimbius | more porting |
17:11.14 | *** part/#asterisk nimbius (~nimbius@2001:19f0:6001:449b:eb61:d3ab:56ad:3c46) |
17:12.52 | velix | sibiria: Yeah, I'm using Setvar, but there is SetCDRUserfield for the CDR as it seems. |
17:24.42 | sibiria | velix: yes you set a custom CDR variable for this |
17:24.57 | sibiria | Setvar: CDR(SOMETHING)=abc123 |
17:25.18 | sibiria | then you grab it with CDR(SOMETHING) |
17:25.58 | sibiria | use normal channel variables if you process this through your own hangup procedure |
17:26.18 | sibiria | at least that's how i go about it |
17:26.36 | velix | nice nice nice. |
17:27.38 | velix | Debian's Asterisk 16 is a mess with pre-configured config files. I've compiled A17 from scratch. Is there a minium configuration to start with? |
17:28.04 | Samot | enabled = no |
17:28.25 | Samot | velix: If you are trying to use csv CDRs why does the conf file have it disabled? |
17:28.37 | velix | Samot: I've just uploaded the old version, in my live version, this is enabled of course. |
17:28.43 | velix | Samot: It also already works thanks of sibiria idea. |
17:28.53 | velix | he's cold as ice. |
17:30.22 | sibiria | regarding minimum config, you asked this a few days ago and i recall giving a few advice |
17:30.34 | sibiria | what i mentioned is when using asterisk's default sample configs as the base |
17:30.48 | sibiria | the default setup is pretty reasonable compared to for example debian's package |
17:31.16 | velix | sibiria: No, I didn't, really. But thanks ;) |
17:31.30 | velix | I thought, Asterisk 17 was too hard to setup because of all the modules, but it wasn't. |
17:32.52 | sibiria | hm it wasn't you who asked? my memory's off then |
17:33.18 | velix | sibiria: I think, that's asked quiet often. Since there isn't a user repository for Asterisk :( |
17:33.22 | velix | There was in the past. |
17:33.22 | sibiria | but i'm sure you can find that discussion in your scrollback. it was just the other day |
17:33.41 | velix | good idea |
17:36.48 | *** join/#asterisk nimbius (~nimbius@2001:19f0:6001:449b:eb61:d3ab:56ad:3c46) |
17:36.53 | nimbius | well i thought i had it, kinda no. |
17:37.00 | nimbius | so im using MessageSend with the AMI |
17:37.10 | nimbius | and asterisk keeps telling me it cant find the endpoint on my trunk. |
17:38.44 | nimbius | : res_pjsip_messaging.c:681 msg_send: PJSIP MESSAGE - Could not find endpoint 'sip:<13107352345@mytrunk>' and no default outbound endpoint configured |
17:42.59 | Samot | nimbius: Show how you sending this with AMI |
17:43.17 | Samot | And the context that is trying to send this out the trunk |
17:46.07 | nimbius | im using ami via netcat. |
17:47.09 | nimbius | Samot: http://dpaste.com/0PBMKRZ |
17:48.08 | Samot | Hrm, I think we covered this recently.... |
17:48.17 | Samot | I don't mean with you I just mean this issue. |
17:50.52 | nimbius | interesting |
17:52.06 | Samot | pjsip:mytrunk/$1@mytrunk |
17:52.29 | Samot | Sorry |
17:52.37 | Samot | pjsip:mytrunk/sip:$1@mytrunk |
17:53.20 | nimbius | so the definition of the applications invocation has changed? |
17:54.23 | *** join/#asterisk stux16777216Away (stux2@grid9.quadspeedi.net) |
17:54.27 | Samot | Yes, when PJSIP was introduced 6 years ago. |
17:54.35 | Samot | PJSIP can be called various ways. |
17:54.45 | Samot | Unlike Chan_SIP. |
17:55.38 | nimbius | success. |
17:55.57 | nimbius | https://wiki.asterisk.org/wiki/display/AST/Asterisk+17+Application_MessageSend |
17:56.10 | nimbius | specifically the from definition :( |
17:58.51 | velix | Anyone with an idea, why "WaitTime" is ignored via AMI, but respected via Callfile? |
18:01.57 | [TK]D-Fender | velix, https://wiki.asterisk.org/wiki/display/AST/Asterisk+17+ManagerAction_Originate |
18:02.08 | [TK]D-Fender | velix, I don't see that in the spec at all.... |
18:02.51 | [TK]D-Fender | velix, It has a very obvious different name for the same purpose... |
18:03.02 | velix | Uh! Timeout |
18:03.12 | [TK]D-Fender | VERY FINE MANUALS! |
18:03.34 | velix | Sorry, I don't have any excuse this time. |
18:08.17 | vlt | Hello. I found out how to originate or redirect calls from CLI. But how can I connect two channels? |
18:08.40 | [TK]D-Fender | vlt, "bridge" |
18:10.04 | vlt | [TK]D-Fender: Thank you. There's no such command. Is this version specific (1.8.10 Ubuntu here)? |
18:10.30 | [TK]D-Fender | That is ancient garbage |
18:11.13 | vlt | I know, sorry :( Is there a way to bridge two channels on that machine? |
18:12.07 | vlt | Or I'll explain my X/Y problem ... |
18:12.18 | [TK]D-Fender | This is an AMI thing, not CLI |
18:12.26 | [TK]D-Fender | https://wiki.asterisk.org/wiki/display/AST/ManagerAction_Bridge |
18:12.38 | vlt | [TK]D-Fender: Thanks, I'll have a look at it. |
18:12.41 | [TK]D-Fender | Appears it at least exists in 1.8 |
18:23.51 | Kobaz | oh |
18:23.54 | Kobaz | speaking of pjsip |
18:24.15 | Kobaz | PJSIP_HEADER i guess, instead of SipAddHeader |
18:24.48 | Kobaz | seems reasonable |
18:32.05 | *** part/#asterisk nimbius (~nimbius@2001:19f0:6001:449b:eb61:d3ab:56ad:3c46) |
18:39.41 | velix | "Connected to Asterisk 17.3.0 currently running" <-- yeah! |
19:21.23 | *** join/#asterisk _ganapathi_ (~Ganapathi@49.207.182.134) |
19:22.00 | _ganapathi_ | [2020-03-22 19:20:33] WARNING[1493][C-00000009]: channel.c:1086 __ast_queue_frame: Exceptionally long voice queue length queuing to Local/10001092@kstychDialer-00000005;1 |
19:22.27 | _ganapathi_ | am getting exceptionally long voice queue error while making every SIP call once after upgrade asterisk to 17 version |
19:24.54 | _ganapathi_ | for few sec then only call initiating from sip |
19:26.49 | Samot | Is this Chan_SIP or PJSIP? |
19:28.31 | _ganapathi_ | chan_sip only |
19:34.22 | *** join/#asterisk stux|work (stux@endurance.xzibition.com) |
19:40.02 | Samot | That generally happens when the channel is deadlock or not destroyed properly. From what I recall. |
19:43.24 | Kobaz | yay deadlocks |
19:49.17 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
19:56.44 | vlt | [TK]D-Fender: I found out how to bridge (AMI) but don't get the desired result. I'll explain: |
19:57.44 | vlt | I'm originating two calls: SIP/me to extension 1 and SIP/me to extension 2 |
19:58.20 | vlt | Now I want extension 1 and 2 bridged and close both connections to SIP/me. |
19:58.39 | [TK]D-Fender | Why is SIP/me involved at all? |
19:59.13 | vlt | [TK]D-Fender: Both extensions require PIN entry first before I can bridge them. |
19:59.13 | [TK]D-Fender | You seem to be including something that doesn't sound like it's important to your goal at all |
19:59.26 | vlt | [TK]D-Fender: That's my x/y, yes :D |
19:59.50 | vlt | I'll prepare a CLI paste. |
20:03.44 | vlt | [TK]D-Fender: https://dpaste.org/ZTpa |
20:05.31 | vlt | My goal is to "connect" the channels behind extensions 002514@outgoing and 514@outgoing. |
20:06.32 | vlt | The latter is a local MeetMe application. |
20:06.41 | [TK]D-Fender | SIP/jones is a "phone", right? |
20:07.29 | vlt | "jones" is a gateway. |
20:08.35 | vlt | The originates to "SIP/0177...@jones" are to my mobile phone where I entered the PIN codes. |
20:09.29 | vlt | So now there are three connections via "jones", two of them to my mobile, one to the target I want to bridge to the local MeetMe. |
20:09.47 | [TK]D-Fender | I see 2 calls there, not 3 |
20:11.10 | [TK]D-Fender | #1 => call your cell, then put you into a Meetme. #2 => Call your cell AGAIN (call-waiting?) and dial out to someone else |
20:11.33 | vlt | Yes. Two simultaneous calls to my mobile. One of them connected to the local MeetMe, the other connected to a remote phone (via jones). |
20:11.57 | vlt | Yes, call on hold. |
20:12.19 | [TK]D-Fender | So far that's you + 1 other. When do we expect to see more? |
20:13.00 | vlt | [TK]D-Fender: I'm sorry if I fail to explain that well. |
20:13.48 | [TK]D-Fender | If in the end it is your cell + ONE other call then I see no need for meetme. |
20:13.54 | vlt | I want to "hangup" both calls to my mobile and bridge the other channels instead. |
20:14.36 | vlt | [TK]D-Fender: Others will join the MeetMe later |
20:14.50 | [TK]D-Fender | In the end that just puts SIP/03591351399514@jones,,T") into a meetme |
20:14.56 | [TK]D-Fender | alone |
20:15.00 | vlt | Perfect. |
20:15.03 | vlt | That's my goal. |
20:15.15 | [TK]D-Fender | Then the fact of sending 2 calls to your phone sonds to be a waste |
20:15.26 | vlt | I needed to enter the PIN first. |
20:15.38 | vlt | On both local and remote MeetMe. |
20:16.52 | Samot | So you're not bridging two calls together. |
20:17.04 | vlt | Maybe. |
20:17.05 | Samot | You're dumping them into a confbridge/meetme. |
20:17.15 | Samot | If you expect others to join this call. |
20:18.02 | vlt | I'm not absolutely sure about the nomenclature here. |
20:18.08 | Samot | OK |
20:18.18 | Samot | If you have A call B and C and want to drop A |
20:18.25 | Samot | You have to redirecto/transfer B to C |
20:18.42 | Samot | Once that is done, you have a call between B and C |
20:18.43 | vlt | Sounds good. |
20:18.51 | Samot | If you want D to join that call later they can't. |
20:19.09 | vlt | Samot: D will just dial the MeetMe room. |
20:19.18 | Samot | Then how does D talk to B and C? |
20:19.33 | vlt | D talks to the MeetMe room. |
20:19.40 | Samot | And how does B and C get that? |
20:19.42 | Samot | Do they care? |
20:19.48 | Samot | Are they part of the call? |
20:20.25 | vlt | does still not know what *exactly* a "call" is in this context |
20:20.32 | Samot | <PROTECTED> |
20:20.39 | Samot | Two or more parties talking together. |
20:20.48 | vlt | I'll take a step back, wait ... |
20:22.17 | *** join/#asterisk alexandre9099 (~alexandre@unaffiliated/alexandre9099) |
20:23.33 | vlt | We do this for years now: Someone in the main branch picks up their local SIP phone, calls the MeetMe exten, enters the PIN, initiates a second call from that phone to a remote branch, enters the PIN and then uses their "tranfer" key to "connect" both parties they just called. |
20:23.42 | vlt | Works perfectly fine. |
20:24.32 | vlt | I want to do this now from CLI/AMI because home office because covid-19 ... |
20:24.59 | Samot | OK. |
20:25.01 | vlt | What happens when the person on the SIP phone presess "trabsfer"? |
20:25.06 | vlt | *n |
20:25.14 | Samot | It redirects/transfers the call. |
20:25.32 | Samot | OK so you are A |
20:25.42 | vlt | Ok, so "bridge" might be the wrong command. |
20:25.58 | Samot | You dial the meetme extension, you enter your PIN... |
20:26.08 | vlt | ok |
20:26.27 | Samot | Now are you just dialing to start the call or do you already have another call on hold? |
20:26.57 | Samot | And that is the call you want to connect to the remote branch? |
20:27.16 | vlt | It doesn't matter if I call the remote branch first or the local meetme. Works both ways. |
20:27.30 | Samot | Let me ask this another way |
20:27.53 | vlt | Sure, I really appreciate your patience :* |
20:27.56 | Samot | Are you only calling the remote branch OR the meetme (which will then connect to the remote branch) because YOU just want to talk to someone? |
20:28.16 | Samot | Or are you doing this because YOU answered a call and they said "I need to speak to X"? |
20:28.27 | vlt | Neither. |
20:28.52 | Samot | Then what is the point of this? |
20:29.28 | Samot | You're neither calling the other party directly or transfering a call to them. So why do you need a meetme and pin codes? |
20:29.29 | vlt | I call a remote branche's *MeetMe* AND a local MeetMe to "connect" them. |
20:29.35 | Samot | OK |
20:29.36 | Samot | Why? |
20:30.21 | vlt | Each branchMeetMe has up to n participants. |
20:30.34 | vlt | They all call their local MeetMe. |
20:30.46 | Samot | OK |
20:30.53 | vlt | We connect all of them in a star pattern using only one line each. |
20:31.01 | Samot | So then B and C are actually two meetme rooms. |
20:31.11 | vlt | Yes. |
20:31.27 | Samot | So let me see if I follow this now. |
20:31.35 | vlt | Did you see my CLI paste? |
20:31.45 | vlt | https://dpaste.org/ZTpa |
20:31.47 | Samot | Group A in location A all call MeetMe A |
20:31.55 | Samot | B does the same. |
20:32.06 | vlt | Right. |
20:32.11 | Samot | Someone in Group A then calls someone in Group B |
20:32.23 | Samot | Then transfers that call into MeetMe A |
20:32.30 | vlt | I'll explain to provide a better picture: |
20:32.41 | Samot | Is that close? |
20:33.58 | vlt | Usually 10 minutes before a conference call, some assistent (in the main branch)'s task is to call all the other branches's MeetMe rooms, to enter each's PIN, transfer, rinse, repeat. |
20:34.29 | vlt | They themselves don't attend. |
20:34.47 | vlt | Their job is done as soon as the last transfer button was pressed. |
20:35.16 | vlt | Then we have our "main" MeetMe with a handful connections each to remote MeetMe rooms. |
20:35.51 | Samot | So why are you using MeetMe? |
20:36.01 | vlt | Instead of what? |
20:36.19 | [TK]D-Fender | Easy fix Originate to the Target, upon answer Dial() a local channel with a pre-answer Gosub. Have that local channel answer and hit the meetme, and the Gosub wait a few seconds and SendDTMF() for the pin, then allow the bridge to finish. |
20:36.21 | [TK]D-Fender | DONE. |
20:36.46 | Samot | Uhm |
20:36.49 | [TK]D-Fender | only 2 originate and your phone is not needed period |
20:36.51 | Samot | ConfgBridge. |
20:36.58 | Samot | ConfBridge |
20:37.07 | [TK]D-Fender | I was looking to see if COnfBridge offered a pin-less option |
20:37.15 | [TK]D-Fender | wasn't clear right off the instruction page. |
20:37.19 | [TK]D-Fender | but I was thinking of it |
20:38.07 | Samot | It does offer a pinless option. |
20:38.13 | [TK]D-Fender | Even better then |
20:38.14 | Samot | you just don't set them. |
20:39.43 | vlt | Damn, I absolutely underestimated the difficulty of just doing the same that happens every time the transfer button is pressed from CLI/AMI. |
20:39.48 | Samot | Also, you know, not using DAHDI for it. |
20:39.53 | Samot | So it doesn't have a user limt |
20:40.09 | Samot | But if you used ConfBridge you could have a single conference. |
20:40.10 | vlt | user limit? |
20:40.14 | Samot | They they all dial into |
20:40.28 | Samot | s/They/That/ |
20:40.56 | vlt | Samot: Insuffient external lines for all participants. |
20:41.07 | Samot | Uhm |
20:41.15 | Samot | You have PBXes at all the branches. |
20:41.25 | Samot | Use SIP to bridge them together. |
20:41.33 | Samot | You can literally call the PBXes over SIP |
20:42.37 | vlt | I know, but some branches have unreliable (for VoiP) connections. |
20:43.08 | vlt | This gets way more complicated than I had hoped. |
20:43.48 | Samot | Or you get a SIP provider. |
20:43.52 | Samot | Get a DID |
20:43.58 | Samot | Route that to the confbridge. |
20:44.01 | Samot | Done. |
20:44.16 | Samot | They can call the DID from where ever they are. |
20:44.21 | vlt | That's all more than I can do now in the short amount of time. |
20:44.38 | Samot | Perhaps. |
20:44.41 | vlt | If a SIP phone can transfer two calls why do I fail to do the same via CLI/AMI? |
20:45.07 | Samot | So do all the locations have an external channel limit? |
20:45.47 | vlt | Samot: Yes. I apprectiate your help. Very very much. But I'd rather not try to touch anything in this setup now. |
20:46.08 | vlt | Just transfer the calls. |
20:46.51 | Samot | OK. |
20:47.11 | Samot | So instead of having X people at A location call a local MeetMe room internally... |
20:47.21 | vlt | SIP/jones-00003275 and SIP/jones-00003276 seem to bridged now. |
20:47.43 | Samot | You now need to have X people call their office meetme room externally |
20:47.50 | Samot | Or have the PBX call them..whatever. |
20:48.00 | Samot | Either way, do you have enough external channels to do that? |
20:48.44 | vlt | Samot: You mean because of more work from home? |
20:49.09 | Samot | Well I'm guessing that is why you are messing with this |
20:49.15 | Samot | Everyone is in lockdown |
20:49.39 | Samot | The last two weeks for most of us as been "Oh shit, we need remote abilities" |
20:49.47 | vlt | Yes. I'll see to that that we spread (*cough*) the load on the external lines in a way that it works. |
20:51.27 | vlt | There will be people in the main branch that *could* do the job by picking up their local SIP phone but it's quite embarassing not to be able to do that. |
20:51.47 | vlt | SIP/jones-00003275 and SIP/jones-00003276 seem to bridged now. |
20:52.04 | Samot | That doesn't mean anything. |
20:52.06 | vlt | Anything I could try with `cahnnel transfer`? |
20:52.17 | Samot | Those are random channels |
20:52.36 | Samot | Each channel will always be SIP/jones-xXXXXXXXXX |
20:53.09 | vlt | https://dpaste.org/ZTpa should tell us which channel is which, shouldn't it? |
20:54.19 | Samot | There's multiple things in there. |
20:54.24 | Samot | you mean the show channels comand? |
20:54.29 | Samot | Yes it will show you active channels. |
20:54.56 | vlt | Samot: Yes, `show channels` and the "originate history" before it. |
20:58.08 | vlt | tries to disable the PIN code, then originate local MeetMe to remote Meetme, then enable PIN code again |
21:02.01 | vlt | WORKS! |
21:04.27 | vlt | [TK]D-Fender, Samot: Thank you for your help and patience! |
21:12.15 | vlt | No :-( |
21:12.51 | vlt | After disabling the PIN code I managed to connect the branches using just originate. |
21:13.00 | vlt | That part works well now. |
21:13.02 | vlt | But: |
21:13.41 | vlt | After re-enabling the PIN I can dial into the rooms without one. |
21:14.12 | vlt | Maybe as long as there are members in a meetme room it will not reload its config. |
21:14.37 | vlt | thinks hard |
21:15.52 | vlt | Maybe I'll manage to use "bridge" to connect a call to non-PIN-protected Meetme room to another. |
21:15.56 | vlt | I'll try that. |
22:21.18 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
22:27.13 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
22:48.24 | velix | Wow, now I'm confused. "Originate" doesn't work, but callfile works. The module has been loaded. |
22:50.33 | velix | No such command 'originate'. |
22:50.38 | velix | has it been dropped in v17 ? |
22:53.13 | velix | aaah. CHANNEL :D |
22:53.17 | velix | la la la |
23:03.52 | DanFromUK | Hi. Due to the current situation, I've been asked to urgently setup a confbridge system. Is there a way for a muted participant to dial a code to seek approval to unmute? |
23:04.36 | [TK]D-Fender | features.conf + your code |
23:04.40 | [TK]D-Fender | like always |
23:07.50 | DanFromUK | the feature code dialled by a non-admin could then cause interaction with an admin to approve? |
23:08.13 | Samot | Not that I'm aware of |
23:08.34 | [TK]D-Fender | that's the "your code" part |
23:08.44 | [TK]D-Fender | nothing "causes interaction with admin". |
23:08.49 | [TK]D-Fender | there is no "permission" interface |
23:08.55 | [TK]D-Fender | That's all on you |
23:09.19 | DanFromUK | via "my code", I could interact with the admin channel? using pure .conf syntax? |
23:10.20 | [TK]D-Fender | thill a useless term |
23:10.23 | [TK]D-Fender | still* |
23:10.33 | [TK]D-Fender | You punch a code and EXECUTE something |
23:10.42 | [TK]D-Fender | how you signal the "admin is up to YOU. |
23:10.50 | [TK]D-Fender | it isn't a THING, it's an end result |
23:11.14 | [TK]D-Fender | Do you make some magic light turn on at their desk? Do they ahve a web script you send a signal to? |
23:11.31 | [TK]D-Fender | how you come up with is your job |
23:12.02 | DanFromUK | my question is, do i need to create some form of AGI code for this, or would pure extension syntax be able to deal with this type of thing? |
23:12.27 | [TK]D-Fender | What part of "up to you" are you not understanding? |
23:12.46 | [TK]D-Fender | features.conf is the TRIGGER |
23:12.59 | [TK]D-Fender | Everything else is up to you to think of how you signal them |
23:16.25 | *** join/#asterisk Gugge (gugge@guggemand.dk) |
23:26.22 | velix | Yipee. Finall it's not me! "Unable to cancel schedule ID 0. This is probably a bug (res_rtp_asterisk.c: dtls_srtp_stop_timeout_timer, line 2809)." |
23:34.19 | DanFromUK | understood |