00:14.19 | *** join/#asterisk TandyUK (~admin@TandyUK/staff/James) |
00:21.10 | *** join/#asterisk _mwoodj_ (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
00:36.26 | *** join/#asterisk TandyUK (~admin@TandyUK/staff/James) |
02:23.34 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
02:58.13 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
03:07.54 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
03:29.16 | *** join/#asterisk Cory (Cory@unaffiliated/cory) |
04:08.59 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@91.240.66.145) |
04:38.35 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
04:59.12 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
05:33.36 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
06:09.24 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
06:16.24 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
06:26.11 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
06:36.01 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
06:48.28 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
06:49.05 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
07:04.33 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
07:19.46 | *** join/#asterisk tris (tristan@camel.ethereal.net) |
07:25.03 | *** join/#asterisk jkroon (~jkroon@165.16.203.52) |
07:27.47 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
07:56.39 | *** join/#asterisk ashka` (~postmaste@pdpc/supporter/active/ashka) |
08:37.26 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
08:57.02 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
09:07.39 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
09:53.10 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
10:30.50 | *** join/#asterisk TandyUK2 (~admin@TandyUK/staff/James) |
10:52.14 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
10:53.12 | *** join/#asterisk aness (~aness@cm-84.209.49.44.getinternet.no) |
11:33.55 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
12:28.15 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
12:36.04 | jkroon | any ideas why asterisk (chan_sip) would respond with 404 in response to an OPTIONS package? |
12:36.09 | jkroon | *packet. |
12:37.48 | Samot | What does the 404 say? |
12:37.50 | Samot | Not Found? |
12:37.54 | Samot | No User? |
12:38.47 | jkroon | https://pastebin.com/ZgSKviGp\ |
12:39.33 | Samot | OK Asterisk is not replying. |
12:39.52 | jkroon | sorry, ULS VoIP Switch is asterisk. |
12:39.53 | Samot | Or did you modify the Server: header? |
12:40.02 | jkroon | We modified the header, local_ip is us. |
12:40.18 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
12:40.23 | file | OPTIONS is treated as an INVITE, so since there is a lack of a user in the request URI it would make the extension "s", and then it would check the dialplan if that exists |
12:40.32 | Samot | ^^^ That. |
12:41.26 | jkroon | ok, so create exten s,1,Hangup(some nasty code to indicate access denied) and it should solve it. I try. |
12:41.50 | Samot | Well is the remote IP valid? |
12:42.30 | jkroon | yes, there is a type=friend, host=${remote_ip} configured. |
12:42.45 | Samot | OK so the other side isn't sending a user in their keep alive |
12:42.50 | Samot | That is actually normal. |
12:42.50 | jkroon | in sip.conf, but if there is dialplan involvement for exten=s, that's not there. |
12:43.00 | Samot | So before you write nasty dialplan about access denied... |
12:43.10 | jkroon | Samot, no they're not, and unlike asterisk the do care about the response code :( |
12:43.24 | Samot | The other side doesn't care because it got a reply. |
12:43.32 | Samot | And a reply = other side alive. |
12:43.56 | jkroon | in theory, the other side is however refusing to proceed with other aspects until such time as they receive a 200 OK. |
12:44.09 | Samot | It's an OPTIONS. |
12:44.21 | Samot | What more needs to be processed? |
12:45.09 | jkroon | Samot, you're dealing with people that in some cases barely passed grade 7 (not sure what the US or other equivalent would be, but that's basically primary school) |
12:45.27 | seanbright | in the US that is an undergraduate degree |
12:45.29 | Samot | You mean you? Or the end users? |
12:45.37 | jkroon | seanbright, at age 13? |
12:45.46 | jkroon | no, we're dealing with another provider here. |
12:46.00 | Samot | So this is another provider? |
12:46.03 | jkroon | yes. |
12:46.11 | Samot | Who is sending you keep alives? |
12:46.18 | seanbright | i used to be funny... |
12:46.25 | seanbright | but looks aren't everything |
12:46.42 | jkroon | Samot, call it an "aliveness check" rather than keepalive. |
12:46.50 | Samot | Sure. |
12:46.51 | Samot | OK |
12:46.56 | Samot | None of my providers do that. |
12:47.04 | Samot | They'll reply to my keep alives |
12:47.08 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
12:47.09 | Samot | But they don't send keep alives. |
12:47.09 | jkroon | ie, we each have multiple servers on either end, and both sides needs to be aware which hosts on the remote side is alive. |
12:47.30 | Samot | OK so you are hosing servers with this provider? |
12:47.32 | jkroon | Samot, in this case we're both really considered providers, so peers is perhaps a better term. |
12:47.52 | Samot | So these are both YOUR servers? |
12:47.54 | jkroon | no, we've got our own environment, but the bosses have established a bi-directional voice peering agreement. |
12:48.05 | jkroon | no, local_ip are ours, remote_ip are theirs. |
12:48.16 | Samot | What do they run? |
12:48.22 | jkroon | sorry, i guess i'm being thoroughly confusing. |
12:48.28 | Samot | You are. |
12:48.37 | jkroon | Samot, i honestly have no idea and they're not very forthcoming. |
12:48.47 | Samot | So your provider is sending you keep alives |
12:49.00 | jkroon | hehehe, they're checking that they can reach our hosts. |
12:49.22 | Samot | I get what they are doing. |
12:49.22 | jkroon | think of this as a peering between SP1 and SP2 where they're SP1 and we're SP2. |
12:49.26 | Samot | I don't get why they are doing it. |
12:49.32 | Samot | It's a waste of resources on their side. |
12:49.35 | jkroon | rather than client + SP. |
12:50.30 | Samot | So they are sending you keep alives and because you're sending back a 404 they stop sending you calls? |
12:50.53 | Samot | Of course. |
12:51.49 | *** join/#asterisk jkroon (~jkroon@165.16.203.52) |
12:51.54 | Samot | So they are sending you keep alives and because you're sending back a 404 they stop sending you calls? |
12:52.17 | jkroon | precisely. they consider that a fault condition. |
12:52.32 | jkroon | wish i knew what they were running internally. |
12:53.41 | Samot | So they only allow one IP?! |
12:53.45 | Samot | JFC |
12:55.15 | *** join/#asterisk jkroon (~jkroon@165.16.203.52) |
12:55.22 | Samot | Are you good now? |
12:55.46 | jkroon | no clue ... suspected hardware issue here (laptop keeps rebooting sporadially) |
12:55.58 | Samot | So they only allow one IP?! |
12:56.07 | Samot | Your provider only sends calls to one IP? |
12:59.23 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
13:00.52 | jkroon | we've convinced them now to send to two, but they'll always send to one first, then the other. |
13:01.44 | jkroon | and they'll skip over whatever is flagged as "down" due to no or non-200 response to OPTIONS. |
13:02.13 | Samot | Well that's insanity. |
13:02.17 | Samot | That is poor. |
13:02.19 | jkroon | why? |
13:02.25 | jkroon | what would you propose? |
13:02.36 | Samot | Because some people don't need to respond to OPTIONS/Keepalives. |
13:02.41 | Samot | Or want to. |
13:02.47 | Samot | Again, none of my providers send keepalives. |
13:02.56 | Samot | They don't care if my system is up or down. |
13:03.13 | jkroon | i actually like that they care. |
13:03.16 | Samot | They send calls to the IPs I tell them and that includes a list of IPs to rollover. |
13:03.20 | Samot | No. |
13:03.25 | Samot | That has nothing to do with it. |
13:03.28 | jkroon | get the call to a server that is alive in the shortest timeframe. |
13:03.29 | Samot | It's a poor way to do it. |
13:03.34 | bailroc | holy hanna, |
13:03.39 | bailroc | this positron is killing me |
13:03.52 | Samot | jkroon: I come from Voice Providers, real ones don't do this. |
13:04.06 | Samot | It's a waste of system resources. |
13:04.15 | jkroon | they rather delay trying to find the next available server? |
13:04.24 | Samot | What delay? |
13:04.35 | jkroon | INVITE ... time out ... try INVITE to next server. |
13:04.45 | Samot | I can take down my primary switch right now |
13:04.45 | bailroc | only 4 of the SIP phones will associate with the PBX right now. what can I look for to associate them? (this to cryptic?) |
13:04.57 | Samot | There will be almost zero delay in moving to the secondary |
13:05.06 | jkroon | bailroc, are there NAT gateways or firewalls in the way? |
13:05.16 | bailroc | nope |
13:05.24 | jkroon | so same LAN? |
13:05.36 | bailroc | Yes. |
13:05.50 | jkroon | bailroc, does tcpdump see the traffic you're expecting? |
13:05.50 | Samot | What do you mean "associate them"? |
13:05.59 | jkroon | Samot, he means REGISTER with. |
13:06.00 | bailroc | It's an old system, I built a FreePBX system, but they company hasn't implemented it yet. |
13:06.15 | bailroc | jkroon: correct. |
13:06.45 | bailroc | jkroon: will do one now but I just had 4 of them registered, not they too are no longer registered. |
13:06.53 | bailroc | not=now |
13:07.20 | Samot | So they registered and now they are not registered? |
13:07.33 | jkroon | Samot, ok, good idea or not, besides the point. remote side is expecting response of 200 on OPTIONS. |
13:07.42 | bailroc | yes, and all calls go directly to mailbox or followme. |
13:07.57 | Samot | bailroc: Do you see them attempting to register again |
13:08.10 | Samot | jkroon: Then you need to make sure Asterisk responds with a 200 OK |
13:08.15 | bailroc | doing dump, 1 min. |
13:08.22 | Samot | So adding nasty dialplan that says "access denied" is the wrong answer. |
13:08.43 | jkroon | adding an exten => s to the context for the remote side doesn't seem to help in any way. |
13:09.47 | file | that's the extent of what I recall from chan_sip |
13:09.59 | jkroon | sip debug revealed the issue. |
13:10.08 | Samot | jkroon: Do you register? |
13:10.12 | jkroon | not sure why i didn't try that first, i feel like an idiot now. |
13:10.24 | Samot | What was the issue? |
13:10.33 | jkroon | Samot, no. [peer] / type=friend / host=1.2.3.4 / context = abc |
13:10.35 | Samot | And where did those option messages that you posted earlier come from? |
13:10.44 | jkroon | on incoming OPTIONS it looks for s@default |
13:10.53 | jkroon | Samot, those were sniffed with sngrep |
13:11.03 | Samot | OK why are you using type=friend? |
13:11.11 | Samot | For something you are peering with? |
13:11.37 | jkroon | peer = send calls to, user = receive calls from, friend = both. |
13:11.43 | Samot | NO |
13:11.47 | Samot | You just need PEER |
13:11.52 | Samot | There is no USER |
13:12.09 | jkroon | you're right. |
13:12.58 | Samot | So Asterisk thinks there is a USER associated with the PEER |
13:13.04 | Samot | When you use friend. |
13:13.07 | Samot | And there isn't. |
13:13.09 | Samot | It's just a peer. |
13:14.44 | jkroon | just FYI, asterisk also does To: <sip:${remote_ip}> if you set qualify=yes for this peer (which I've done for two reasons: (1) to confirm that their side responds correctly; and (2) to confirm connectivity) |
13:15.32 | jkroon | anyway, why is asterisk using a context different than that shown in sip show peer for the given peer? |
13:16.58 | Samot | You only have one peer with them for this host right? |
13:17.10 | jkroon | correct. |
13:17.13 | Samot | host=1.2.3.4 <-- only one peer has this? |
13:17.17 | jkroon | yes |
13:17.40 | jkroon | asterisk -rx "sip show peers" | grep 1.2.3.4 confirms |
13:18.08 | jkroon | creating a [default] context with exten => s,1,Hangup(21) solves the issue. |
13:18.29 | jkroon | but i still find it odd that i need to create a completely different context than what's specified in the peer config. |
13:18.46 | jkroon | to me indicates it's treating the incoming OPTIONS like a guest, instead of as the peer. |
13:19.17 | sibiria | i wonder how this maps out for pjsip |
13:20.03 | jkroon | sibiria, if you're suggesting I try pjsip ... i'd love to, but we've bumped into a few stoppers for us which we first need to get sorted out. |
13:20.06 | Samot | And it sends back a 200 OK? |
13:20.13 | Samot | What stoppers? |
13:20.20 | jkroon | Samot, correct @ 200 OK. |
13:20.21 | sibiria | jkroon: i'm mostly curious for my own behalf since we're moving to pjsip soon |
13:20.46 | jkroon | Samot, mostly to do with the way we deal with CDRs, it's not an asterisk issue per sé but rather the way in which some external stuff is being handled. |
13:20.50 | sibiria | but since in your case, it goes into the context of [default] (so to speak)... i wonder what pjsip will do |
13:20.56 | jkroon | sibiria, you multi-homed? |
13:21.08 | sibiria | jkroon: we're still on chan_sip only |
13:21.33 | jkroon | sibiria, no, if you do "ip ad sh" or "ifconfig" - do you have multiple interfaces with outbound routes on the host? |
13:21.56 | sibiria | no we don't multihome. we're on a single uplink |
13:21.57 | Samot | And how does PJSIP impact CDRs? |
13:22.00 | jkroon | for that matter, do you have multiple ip addresses assigned on the host? Say back end vs front end ... or any other such stuff? |
13:22.07 | jkroon | sibiria, so you'll be fine. |
13:22.08 | file | PJSIP does authentication/matching before any care is given to the request itself, so it would get matched based on IP and then should end up at the correct context |
13:22.18 | jkroon | Samot, i'd have to ask the guys that blocked the CR. |
13:22.40 | Samot | What CR? |
13:22.45 | jkroon | change request. |
13:23.16 | file | in fact it looks like the PJSIP implementation has specific logic to handle this case and doesn't require touching the dialplan |
13:23.18 | jkroon | anyway, thanks for te help Samot - you've given rise to another internal CR (type = friend to type = peer). |
13:23.35 | Samot | Wait, you guys are using friend for all your peers?! |
13:23.36 | jkroon | file, that's good to know. I'll make a note of that. |
13:23.50 | jkroon | Samot, i did a quick scan and there are a few more that has the same problem yes. |
13:24.27 | Samot | Wow. |
13:24.28 | bailroc | making an outgoing call registered the phones to the network.. |
13:24.33 | bailroc | all is well |
13:24.44 | Samot | I mean outside of the fact that Chan_SIP is on the way out the door.... |
13:24.55 | Samot | It's 2019. How can people still not understand how Chan_SIP works? |
13:25.44 | jkroon | Samot, i think you can take the attitude and put it somewhere. chan_sip is an overly complex beast and I seriouly doubt there is any one individual that actually grasps all the nuances. |
13:25.57 | Samot | OK. |
13:25.58 | jkroon | we all WANT to move to PJSIP. |
13:25.59 | Samot | Sure. |
13:26.10 | Samot | PJSIP has nothing do with this. |
13:26.59 | jkroon | it might just be that the original guys doing the deployements had some misunderstanding ... that skipped through years and templates were wrong, so it just needs to be fixed and that has now been raised. so someone here will sort it out after performing QA and then it's all sorted. |
13:27.47 | jkroon | documentation has improved over the last 10+ years when the first deployments were made. so frankly, most of those that I found now that was type=friend came from 2008, that's 11 years. |
13:28.14 | jkroon | once QA is done, the change goes through, and it's sorted, no harm done. |
13:28.32 | Samot | Yes, friend was a way to have both a peer and a user without having to configure them both. |
13:28.52 | Samot | But it's never needed with you're just peering. A user is never needed. |
13:28.58 | Samot | Before 2008, after 2008.. |
13:29.05 | jkroon | which funny enough we need for the majority of our sip endpoints, so for 99% of them it's actually correct to have type=friend. |
13:29.14 | Samot | Endpoints are different. |
13:29.17 | Samot | They aren't peering. |
13:29.21 | Samot | They are REGISTERING |
13:29.32 | Samot | With the host=dynamic I'm sure |
13:29.35 | Samot | That requires a USER |
13:29.39 | jkroon | correct. |
13:31.51 | Samot | Well if Chan_SIP is a complex beast for your guys. |
13:31.57 | Samot | PJSIP might break them. |
13:34.23 | Samot | For example, your trunks to your providers... |
13:34.33 | Samot | The actual PJSIP endpoints do not do the qualify. |
13:34.46 | Samot | The PJSIP AORs do the qualify. |
13:34.58 | Samot | And a single PJSIP endpoint could use multiple PJSIP AORs. |
13:43.59 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
13:52.28 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-mhcdhtihdgsnaktd) |
13:52.28 | *** mode/#asterisk [+o bford] by ChanServ |
13:57.05 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
14:06.10 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
14:10.18 | *** join/#asterisk mukeshtilwani (67e97767@gateway/web/freenode/ip.103.233.119.103) |
14:10.57 | mukeshtilwani | Hi everyone |
14:11.23 | mukeshtilwani | After changing parameter "media_address" in sip.conf to any valid IP, we are getting one way or no voice issues on few calls. Sometimes voice passes successfully, we would like to know why this is happening and resolution for same. |
14:15.24 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
14:15.27 | file | why are you setting the option? |
14:18.42 | mukeshtilwani | any valid public media server IP |
14:19.19 | mukeshtilwani | Telco IP |
14:20.13 | file | the option is for specifying an IP address that chan_sip will place into the SDP, which tells the other side where to send media |
14:20.31 | file | if it is not an IP that Asterisk can receive media on, then bad stuff will happen |
14:23.29 | mukeshtilwani | Thank you for response. Could you please tell me then why it sometimes working fine.. |
14:23.51 | file | because it depends upon the remote side as to what they do - they may detect media is coming from a different place, and correspondingly send their media to there |
14:26.15 | mukeshtilwani | ok, as per defination in sip.conf, it is "Note that this does not change the listen address for RTP, it only changes the ; advertised address in the SDP. The Asterisk RTP engine will still listen on ; the standard IP address." |
14:26.28 | file | yes. |
14:27.39 | mukeshtilwani | i wanted to advertize different media_address, while it should use standard media address. Is it possible? |
14:28.01 | file | I don't understand what you mean by that |
14:28.40 | file | media_address as you mentioned will change what is placed into the SDP, but will not use that local address for sending from |
14:28.49 | mukeshtilwani | well, i wanted to advertize a different media_address in SDP, without any voice issues |
14:29.16 | file | does the IP address you are specifying in media_address route back to Asterisk? |
14:29.32 | file | that is: will packets sent to it get to Asterisk |
14:29.43 | file | mukeshtilwani: I do not provide private support |
14:29.49 | mukeshtilwani | ok |
14:29.57 | mukeshtilwani | yes |
14:30.12 | file | then you'd need to look at the flowing RTP traffic to understand what precisely is happening within your environment |
14:30.55 | mukeshtilwani | does the IP address you are specifying in media_address route back to Asterisk? No |
14:31.10 | file | then it is unlikely to work |
14:31.25 | file | you provide, in SDP, to the remote end where you want them to send media |
14:31.37 | file | if you tell them somewhere else... then they may send it somewhere else |
14:32.26 | mukeshtilwani | yes |
14:33.26 | mukeshtilwani | when i used and changed the media_address then out of 10 calls 4-5 calls successfully connected without any media issues... |
14:34.04 | file | the remote side does not have to use what is in the SDP |
14:34.06 | mukeshtilwani | we are looking for other failure calls to work |
14:34.09 | file | they may choose not to. |
14:34.53 | file | but generally you can't just set media_address to some random IP address and have it work, unless the remote side always ignores what you say |
14:36.02 | mukeshtilwani | you are absolutely right...few telcos are passing calls, but few are not.. |
14:37.08 | mukeshtilwani | however, which parameter in SDP define that other party ignores whatever we are sending.. |
14:37.14 | file | none. |
14:37.24 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-gtcjhsaimzpwpdkl) |
14:37.24 | *** mode/#asterisk [+o rmudgett] by ChanServ |
14:37.26 | file | you don't specify it or control it in SDP, that's policy and behavior of the remote side |
14:38.34 | mukeshtilwani | ok..thanks for support...much apreciated your help.. |
14:43.53 | wdoekes | "which parameter in SDP define that other party ignores whatever we are sending" -> it helps if you send an RFC1918 IP. that may persuade some endpoints to ignore it because it's clearly unreachable, and may trigger nat detection |
14:46.49 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
14:49.09 | mukeshtilwani | ok |
14:49.48 | Samot | Is the RTP supposed to flow through Asterisk? |
14:50.15 | Samot | Or are you sending the RTP to another server to handle it? |
14:56.25 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
14:59.38 | *** join/#asterisk pruonckk (~pruonckk@office-ita.brdsoft.com.br) |
15:25.09 | mukeshtilwani | Is the RTP supposed to flow through Asterisk? no |
15:25.53 | Samot | Well why do you need to set the media_address? |
15:42.39 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
15:43.37 | *** join/#asterisk troyt (zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) |
15:52.30 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
15:56.03 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
16:00.52 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
16:12.44 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
16:24.27 | *** join/#asterisk pruonckk (~pruonckk@office-ita.brdsoft.com.br) |
16:35.46 | *** join/#asterisk NWATechSupport (~JHCG@wsip-72-204-193-12.ks.ks.cox.net) |
16:37.04 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
16:38.23 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
16:45.35 | mukeshtilwani | Well why do you need to set the media_address? well, i was check new features of Asterisk and found this one..when I used it then i saw some calls working fine and other failing due to one way or no audio issues.. |
16:45.57 | mukeshtilwani | its just curosity why some calls worked and why not others... |
16:47.44 | mukeshtilwani | fyi, I have seen calls of more then 1 hours, in those senarios.. |
16:53.25 | Samot | And when it's not set, do you have these random issues? |
16:56.23 | mukeshtilwani | No, if it is not set Asterisk passes calls perfectly.. |
16:57.08 | mukeshtilwani | In change log of Asterisk 16, it says :- sip.conf.sample - note that media_address does not change listen address, just the SDP |
16:57.52 | mukeshtilwani | here listen address will be signaling address only? |
16:58.54 | *** join/#asterisk rpifan (~rpifan@dslb-178-000-177-094.178.000.pools.vodafone-ip.de) |
16:59.26 | Samot | Correct. |
17:01.39 | mukeshtilwani | well, in sip.conf asterisk 15 it says :- Note that this does not change the listen address for RTP, it only changes the ; advertised address in the SDP. The Asterisk RTP engine will still listen on ; the standard IP address. |
17:02.03 | Samot | Do you need to send the media to another media_address? |
17:02.05 | Samot | Yes or no? |
17:03.48 | mukeshtilwani | I wanted to advertise a different media address only...no matter wheather it relay from asterisk or peer to peer communication... |
17:06.20 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
17:08.05 | *** join/#asterisk stevedav_ (~stevedavi@197.155.252.3) |
17:10.45 | Samot | Is that IP address on the same Asterisk box? |
17:17.09 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
17:23.43 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
17:29.02 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
17:34.33 | *** join/#asterisk rpifan_ (~rpifan@dslb-178-000-177-094.178.000.pools.vodafone-ip.de) |
17:46.12 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
17:48.03 | *** join/#asterisk degenerate (~degenerat@S0106cc2de0099182.no.shawcable.net) |
17:58.24 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
18:06.51 | *** join/#asterisk Maliuta_ (maliutamat@gateway/shell/matrix.org/x-xewqdejdbaxppaxe) |
18:09.35 | *** join/#asterisk pruonckk (~pruonckk@office-ita.brdsoft.com.br) |
18:28.52 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
18:32.17 | *** join/#asterisk scgm11_ (~scgm11@r186-49-66-240.dialup.adsl.anteldata.net.uy) |
18:40.06 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
18:58.05 | *** join/#asterisk miralin (~Thunderbi@81.177.58.137) |
18:59.36 | *** join/#asterisk LoKoMurdoK (~LoKoMurdo@fedora/LoKoMurdoK) |
18:59.54 | *** join/#asterisk pruonckk (~pruonckk@office-ita.brdsoft.com.br) |
19:03.37 | *** part/#asterisk jpsharp (~jsharp@linode.fivecats.org) |
19:05.48 | *** join/#asterisk jkroon (~jkroon@165.16.203.106) |
19:08.33 | *** join/#asterisk jkroon (~jkroon@165.16.203.106) |
19:15.50 | Maxxed | i'm looking to redirect an inbound call based on caller id string to a different context.. can one of you guys point me in the right direction? |
19:26.58 | *** join/#asterisk kevinnn (ae4c1654@gateway/web/freenode/ip.174.76.22.84) |
19:27.17 | kevinnn | hi all, how can I originate multiple calls from cli? |
19:27.26 | kevinnn | at the same time |
19:27.40 | kevinnn | seems that I can only call console dial once |
19:27.59 | kevinnn | every other attempt to call that function just seems to do nothing until that first call is stopped |
19:30.02 | kevinnn | any help at all would be appreciated... |
19:31.57 | [TK]D-Fender | "console dial" is not "originate |
19:32.13 | [TK]D-Fender | they are completely separate things |
19:39.22 | kevinnn | https://dictionary.cambridge.org/us/dictionary/english/originate |
19:39.33 | kevinnn | [TK]D-Fender: not sure what you mean by that |
19:40.00 | [TK]D-Fender | Originate is a very specific Asterisk term |
19:40.27 | [TK]D-Fender | So if you meant some dictionary meaning separate from the fact it's a special terms specifically with what you;'re using you could understand the confusion... |
19:40.55 | kevinnn | [TK]D-Fender: to rephrase... how can I initiate multiple calls from cli? |
19:40.55 | [TK]D-Fender | console dial is a single call at a time period because it's acting as the audio interface. |
19:41.05 | [TK]D-Fender | You can't have multiple audio calls from CLI like that at a time |
19:41.14 | kevinnn | ... really? |
19:41.28 | [TK]D-Fender | not with CLI having the AUDIO. |
19:41.45 | [TK]D-Fender | (as in the sound card attached to the server)\ |
19:42.37 | [TK]D-Fender | This is the difference between the interactive "console channel", vs a channel that is started by calling out to a device and upon answer having the call tossed into the dialplan for processing |
19:42.51 | kevinnn | okay... so how can I call multiple extensions at the same time? |
19:42.53 | [TK]D-Fender | The latter being "channel originate" |
19:43.26 | [TK]D-Fender | ^ |
19:44.16 | [TK]D-Fender | https://wiki.asterisk.org/wiki/display/AST/Channels |
19:44.33 | kevinnn | hmm, don't see console channel as an option |
19:44.52 | kevinnn | No such command 'console channel' |
19:44.59 | [TK]D-Fender | I did not say that |
19:45.04 | [TK]D-Fender | <[TK]D-Fender> The latter being "channel originate" |
19:45.28 | [TK]D-Fender | there is no multiple "console dial" with the server sound interface being used for audio |
19:46.26 | kevinnn | so I have a couple of these set up: exten => 1103,1,Page(SIP/1003,A(/var/www/music/Song)) |
19:46.38 | kevinnn | how do I set off multiple of these at once? |
19:47.05 | kevinnn | Before I was just doing: console dial 1103@from-internal |
19:47.10 | [TK]D-Fender | [TK]D-Fender> The latter being "channel originate" <--- |
19:47.49 | [TK]D-Fender | Read the page I linked you |
19:48.59 | kevinnn | hmm |
19:49.09 | kevinnn | what is <tech/data> |
19:49.45 | [TK]D-Fender | The same thing you could pass Dial() |
19:49.46 | [TK]D-Fender | (SIP/1003 |
19:50.07 | kevinnn | so instead of console dial 1103@from-internal |
19:50.29 | kevinnn | I would do channel originate extension 1103@from-internal |
19:50.31 | kevinnn | ? |
19:51.29 | [TK]D-Fender | Did you read the instructions? |
19:52.21 | [TK]D-Fender | You didn't even read what I just pasted back.... |
19:52.39 | [TK]D-Fender | Go properly read the page I linked... |
19:54.22 | kevinnn | im reading, my apologies |
19:57.52 | kevinnn | [TK]D-Fender: can I create a dummy SIP/hello on the fly? |
19:58.06 | kevinnn | without restarting asterisk or anything |
19:58.13 | [TK]D-Fender | that isn't a "dummy" |
19:58.21 | [TK]D-Fender | it will call whatever you tell it to call. |
19:58.34 | *** join/#asterisk pruonckk (~pruonckk@189.40.85.152) |
19:58.41 | [TK]D-Fender | So re-imagine the actualy flow |
19:59.06 | kevinnn | channel originate SIP/dummy extension 1103@from-internal |
19:59.07 | [TK]D-Fender | what gets called? What happens then? |
19:59.12 | kevinnn | this didn't work... |
19:59.19 | [TK]D-Fender | "dummy" isn't a thing |
19:59.53 | kevinnn | Do I have to create a SIP device in sip.conf for this specific purpose? |
20:00.07 | [TK]D-Fender | no |
20:00.11 | [TK]D-Fender | [TK]D-Fender> So re-imagine the actual flow |
20:00.36 | kevinnn | okay so 1103@from-internal gets called |
20:00.42 | kevinnn | exten => 1103,1,Page(SIP/1003,A(/var/www/music/Song)) |
20:00.49 | kevinnn | which is a Page |
20:01.01 | [TK]D-Fender | Maybe Page isn't needed at all <-------------- |
20:01.25 | [TK]D-Fender | You need to actually think about what is on each end of this |
20:02.00 | kevinnn | exten => 1104,1,Page(SIP/1003&SIP/1004,A(/var/www/music/Song)) |
20:02.11 | kevinnn | for 1104 I think I need a page right? |
20:02.46 | kevinnn | if I want the song to play on all the devices simultaneously? |
20:04.00 | kevinnn | [TK]D-Fender |
20:04.01 | [TK]D-Fender | Each originate is its own channel |
20:04.18 | kevinnn | right... |
20:04.20 | [TK]D-Fender | There is nothing technically syncing any of these together |
20:04.32 | [TK]D-Fender | they could be CLOSE..... |
20:04.38 | [TK]D-Fender | or less than..... |
20:04.59 | kevinnn | hmmm, page seems to be good enough though, I don't notice much of a de-sync |
20:05.09 | [TK]D-Fender | I just saw you 2nd sample |
20:05.21 | [TK]D-Fender | that one DOES send audio simulataneously |
20:05.27 | [TK]D-Fender | Your first singled out 1 device |
20:05.38 | [TK]D-Fender | So we've shifted tracks now |
20:06.06 | kevinnn | ya, some extensions have multiple devices |
20:06.13 | kevinnn | sorry I should have been more clear |
20:06.49 | [TK]D-Fender | unless you do it all in one then each of them will be independent |
20:07.02 | [TK]D-Fender | 1104 does do 2 at once, so at leeast those 2 will be synced |
20:07.15 | [TK]D-Fender | (should) |
20:07.26 | [TK]D-Fender | but those will be different than any others you launch |
20:07.58 | kevinnn | that is fine, often the extensions will not conflict device wise. the audio played will also vary from extension to extension |
20:08.27 | kevinnn | so there is no need to synchronize between channels |
20:09.43 | [TK]D-Fender | Since I'm getting the impression you will take a long while before coming to the idea: You don't seem to need page period |
20:10.05 | [TK]D-Fender | Originate each call out TO the device and dump them into a PLAYBACK <- |
20:11.23 | kevinnn | [TK]D-Fender: that might perhaps be more efficient but for the this particular use case I cannot modify extensions.conf |
20:11.38 | kevinnn | extensions.conf is all I am given... |
20:13.52 | kevinnn | is it not possible to do with the given extensions configuration? |
20:14.02 | kevinnn | [TK]D-Fender |
20:14.29 | *** join/#asterisk hexanol (~hexanol@69.156.197.18) |
20:15.31 | [TK]D-Fender | Something has to be on the "left side" |
20:15.43 | [TK]D-Fender | Consider a Local channel. |
20:17.57 | *** join/#asterisk donuthole (~babbage_@80.111.186.87) |
20:18.23 | kevinnn | [TK]D-Fender: I am not quite sure what that means... |
20:18.46 | kevinnn | I'd just like to make multiple extensions go off at once... |
20:18.56 | kevinnn | I don't understand why that could be so impossible to do |
20:20.50 | [TK]D-Fender | stop saying "just" and look at the tool |
20:22.02 | kevinnn | I read the guide that you linked and I am still not sure what I should put in the SIP/Alice slot |
20:22.10 | [TK]D-Fender | go Originate a LOCAL channel to have something on the LEFT side... so that you can toss it towards that other dialplan. |
20:22.17 | [TK]D-Fender | <[TK]D-Fender> Something has to be on the "left side" |
20:22.18 | [TK]D-Fender | <[TK]D-Fender> Consider a Local channel. |
20:22.24 | kevinnn | oh |
20:22.26 | kevinnn | local |
20:22.30 | kevinnn | okay let me try that |
20:24.11 | *** part/#asterisk hexanol (~hexanol@69.156.197.18) |
20:25.19 | kevinnn | [TK]D-Fender: okay sorry, i must be missing something, is a local channel something I have to set up? |
20:26.51 | kevinnn | like inside of sip.conf? |
20:27.42 | donuthole | I'm having trouble with outbound SIP calling. Full details at https://pastebin.com/Je8k81s3. I'm getting the error "es_pjsip_outbound_authenticator_digest.c:144 digest_create_request_with_auth_from_old: Unable to create request with auth. No auth credentials for any realms in challenge." but as far as I can tell I do have the correct realm configured. Details in the paste. |
20:28.56 | donuthole | Any help appreciated. |
20:30.12 | donuthole | Internal SIP calls from the same phone to internal extensions (e.g. the "hello world" example config on 100) seem to work OK. |
20:30.58 | donuthole | (I indluded pjsip logging in the paste, apologies if it is too voluminous) |
20:32.04 | [TK]D-Fender | kevinnn, https://wiki.asterisk.org/wiki/display/AST/Local+Channel <---------------- |
20:33.04 | donuthole | I'm running Asterisk version 13.14.1~dfsg-2+deb9u4 (on, unsurprisingly, Debian Linux) |
20:33.33 | [TK]D-Fender | donuthole, [blueface_endpoint] <- you very clearly didn't put an AUTH in there |
20:33.54 | [TK]D-Fender | donuthole, You made a section you COULD have referenced in your endpoint, but you didn't actually use it |
20:34.10 | kevinnn | [TK]D-Fender: the command does not recognize "Local" |
20:34.26 | [TK]D-Fender | kevinnn, I have no idea what you're actually issuing |
20:34.32 | donuthole | So I just set outbound_auth = blueface_auth in the [bluefacer_endpoint] section? |
20:34.48 | [TK]D-Fender | or auth |
20:35.16 | kevinnn | [TK]D-Fender: I did this: Local/200 |
20:35.32 | [TK]D-Fender | kevinnn, And what is that supposed to reference? |
20:35.35 | kevinnn | and it says no such extension/context |
20:35.46 | [TK]D-Fender | kevinnn> and it says no such extension/context <- it means it |
20:35.46 | kevinnn | [TK]D-Fender: nothing? |
20:35.52 | [TK]D-Fender | ... |
20:36.05 | [TK]D-Fender | Local channel = DIALPLAN <------------- |
20:36.06 | kevinnn | I can't add any extensions or anything |
20:36.15 | kevinnn | my use case doesn't allow me to |
20:36.27 | [TK]D-Fender | Go find something else to call then |
20:36.38 | [TK]D-Fender | SOMETHING has to answer |
20:36.58 | kevinnn | hmm, can it be another extension? |
20:37.10 | kevinnn | and can another extension answer for multiple calls? |
20:37.13 | [TK]D-Fender | <[TK]D-Fender> SOMETHING has to answer |
20:38.00 | kevinnn | so for example I have 1105/from-internal, I am fairly confident that no one ever uses it |
20:38.21 | kevinnn | could I just use this everytime I call channel? |
20:38.25 | [TK]D-Fender | And how is that going to react to being called? |
20:38.35 | [TK]D-Fender | how about when you issue a dozen things like this towards it? |
20:39.08 | kevinnn | I don't know how it'll react... |
20:39.10 | donuthole | [TK]D-Fender, aha, yes, that changes things. Now I get a 403 instead. REGISTER worked with the same auth section, though. |
20:39.14 | kevinnn | it is an extension |
20:39.20 | kevinnn | like the others |
20:40.05 | [TK]D-Fender | It's going to get called. |
20:40.15 | [TK]D-Fender | How can you not know what it will do? |
20:41.27 | kevinnn | [TK]D-Fender: so you are telling me that this command: channel originate 1102/from-internal extension 1103@from-internal will call both 1102 and 1103? |
20:41.36 | kevinnn | why? that makes no sense to me |
20:42.19 | [TK]D-Fender | Why did you think that was a valid thing to pick in the first place? |
20:42.56 | kevinnn | [TK]D-Fender: what should I pick? for console dial I only had to input the extension I wanted to dial |
20:43.03 | kevinnn | this one for some reason requires two |
20:43.15 | [TK]D-Fender | BECAUSE IT'S DIFFERENT |
20:43.43 | kevinnn | [TK]D-Fender: okay I understand they are different... |
20:43.45 | [TK]D-Fender | You can't issue multiple Console Dial's. Forget about that little bit of experience completely. |
20:43.50 | [TK]D-Fender | It does NOT apply to your goal |
20:44.03 | kevinnn | okay it is forgotten |
20:44.18 | donuthole | [TK]D-Fender, now the call fails with 403; details in https://pastebin.com/hVQvLGug |
20:44.47 | [TK]D-Fender | Originate CALLS the LEFT side. The thing has to ANSWER. Got that? Paying attention? Whatever that thing is has to get treated as though it ANSWERED. THEN it will do the thing on the RIGHT side. |
20:45.34 | kevinnn | [TK]D-Fender: okay I follow, does asterisk have any dummy device that automatically answers? |
20:45.41 | [TK]D-Fender | your "page" side already inserts the audio, so the LEFT side has to be something that isn't required to do anything other than answer. |
20:46.51 | [TK]D-Fender | donuthole, Contact: <sip:asterisk@192.168.122.105:5060> |
20:47.10 | [TK]D-Fender | donuthole, You are calling out to the internet and presenting a LOCL IP for your contact. Your NAT setup is wrong |
20:47.27 | kevinnn | [TK]D-Fender: so I should just set up an extension that simply answers. I think I can do that. is there anything else I should be looking out for? |
20:47.33 | [TK]D-Fender | donuthole, Which is an immediate reason for them to reject you |
20:48.00 | donuthole | ack, obviously presenting an RFC1918 address at their external interface isn't going to be a popular move. |
20:48.26 | [TK]D-Fender | kevinnn, You should ahve read the instructions since I pointed you to the page repeatedly. I've told you how this works. |
20:48.40 | [TK]D-Fender | kevinnn, SOMETHIGN has to act as a channel on the LEFT side. |
20:50.29 | *** join/#asterisk rpifan (~rpifan@dslb-178-000-177-094.178.000.pools.vodafone-ip.de) |
20:59.15 | *** join/#asterisk mindthelion (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
20:59.17 | *** join/#asterisk tripleslash (~triplesla@unaffiliated/imsaguy) |
21:08.22 | *** join/#asterisk jeffspeff (~jeffspeff@12.49.160.131) |
21:09.04 | [TK]D-Fender | packs up to head home |
21:09.41 | donuthole | [TK]D-Fender, thanks for your help. To enable RTP properly I'm going to need to set up rtp.conf correctly, but with a port range consistent with the configuration of my firewall. For that to work well I should move the configuration of my firewall to Ansible. That's going to take a while. |
21:10.05 | donuthole | That's going to take a while, so I won't be back today. However, thank you for your help! |
21:10.22 | donuthole | Oh, they left. |
21:25.39 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
22:01.16 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
22:06.54 | *** join/#asterisk josefig (~josefig@unaffiliated/josefig) |
22:07.13 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
22:07.44 | josefig | hi, i know this is not the channel but maybe you can help me, it is based on asterisk and maybe someone from you have used before. It's about issabel pbx using call center module. |
22:12.20 | pchero | what's the issue? |
22:12.39 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
22:13.43 | *** part/#asterisk donuthole (~babbage_@80.111.186.87) |
22:15.28 | kevinnn | So I ran this command in the asterisk cli: channel originate Local/4000@from-internal extension 1103@from-internal |
22:15.39 | kevinnn | here's my declaration for 4000 and 1103 |
22:16.04 | kevinnn | exten => 1103,1,Page(SIP/1003&SIP/1004,A(/var/www/music/Song)) |
22:16.20 | kevinnn | exten => 4000,1,Answer |
22:16.36 | kevinnn | for some reason it doesn't page SIP/1003&SIP/1004 |
22:16.40 | kevinnn | I don' |
22:16.47 | kevinnn | I don't quite understand why |
22:16.57 | kevinnn | any help would be so greatly appreciated |
22:17.27 | [TK]D-Fender | When either side of the call ends, BOTH end |
22:18.51 | kevinnn | [TK]D-Fender: hey! you're back |
22:19.07 | kevinnn | okay so I just have to get 4000 to wait indefinitely? |
22:20.24 | [TK]D-Fender | or long enough. |
22:21.15 | kevinnn | hmm, is there even a way to make it wait indefinitely? |
22:21.21 | kevinnn | I don't see a way |
22:21.30 | [TK]D-Fender | Wait. |
22:21.33 | [TK]D-Fender | Keep waiting |
22:21.37 | [TK]D-Fender | Done |
22:22.01 | kevinnn | wait requires a parameter |
22:22.35 | kevinnn | or at least the guide says so |
22:22.40 | kevinnn | https://www.voip-info.org/asterisk-cmd-wait/ |
22:26.08 | kevinnn | [TK]D-Fender |
22:27.24 | [TK]D-Fender | <[TK]D-Fender> Keep waiting <- |
22:27.48 | kevinnn | [TK]D-Fender: how do I keep waiting? |
22:28.06 | [TK]D-Fender | wait MORE. |
22:28.08 | [TK]D-Fender | wait AGAIN |
22:28.31 | [TK]D-Fender | wait ENOUGH |
22:28.44 | kevinnn | So I can't wait indefinitely? |
22:29.01 | [TK]D-Fender | WAit. wait again, keep waiting again. |
22:29.33 | kevinnn | I am totally lost, show me what waiting indefinitely would look like in code |
22:30.09 | [TK]D-Fender | You are totally lost because you shouldn't even be stuck on "indefinitely" |
22:31.03 | kevinnn | okay I'll just wait 1000 seconds |
22:31.16 | kevinnn | lets hope that that is enough |
22:31.18 | [TK]D-Fender | <[TK]D-Fender> or long enough. |
22:31.18 | kevinnn | also |
22:31.24 | [TK]D-Fender | <[TK]D-Fender> wait ENOUGH |
22:31.56 | kevinnn | can multiple things dial 4000? |
22:32.15 | kevinnn | like can I use it in multiple channel originate calls? |
22:32.41 | [TK]D-Fender | If you're referring to starting a local channel you can start as many as you want |
22:33.36 | kevinnn | <PROTECTED> |
22:33.40 | kevinnn | <PROTECTED> |
22:33.46 | kevinnn | will that be okay? |
22:33.55 | kevinnn | will it dial both 1103 and 1102 |
22:34.01 | kevinnn | if I call them like 1 second apart |
22:34.13 | [TK]D-Fender | time between doesn't matter |
22:34.14 | kevinnn | given that 4000 waits for 1000 |
22:34.38 | kevinnn | so I can call them? |
22:34.43 | kevinnn | just like that? |
22:34.55 | [TK]D-Fender | You can call whatever you want as many times as you want |
22:35.03 | [TK]D-Fender | * will start a local chennel when you tell it to |
22:35.12 | kevinnn | okay I understand |
22:35.30 | [TK]D-Fender | If you put a SIP device there instead it would call it, and the device would handle it however it handles that number of calls. |
22:36.53 | kevinnn | okay I did this: exten => 4000,1,Answer exten => 4000,2,Wait(1000) |
22:36.59 | kevinnn | and it still did not dial 1103 |
22:37.07 | [TK]D-Fender | And you' |
22:37.11 | [TK]D-Fender | ve shown nothing |
22:37.24 | [TK]D-Fender | PASTEBIN <- |
22:37.27 | [TK]D-Fender | ~pb |
22:37.28 | infobot | from memory, pastebin is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few: http://pastebin.ca, http://channels.debian.net/paste, http://paste.lisp.org, http://bin.cakephp.org/; or install pastebinit with yum or aptitude. |
22:38.15 | kevinnn | https://pastebin.com/khEp19dQ |
22:38.26 | [TK]D-Fender | ... |
22:38.29 | [TK]D-Fender | the CALL <-------------- |
22:38.39 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
22:39.25 | kevinnn | channel originate Local/4000@from-internal extension 1103@from-internal |
22:39.33 | [TK]D-Fender | ... |
22:39.36 | [TK]D-Fender | ........... |
22:40.01 | kevinnn | https://pastebin.com/MDd1Z8y7 |
22:40.12 | kevinnn | here's my full extensions.conf |
22:40.14 | [TK]D-Fender | ................ |
22:40.44 | kevinnn | please help me... what are you looking for |
22:40.47 | kevinnn | oh the output? |
22:40.52 | kevinnn | like from the console |
22:41.00 | kevinnn | when I run the command? |
22:41.09 | [TK]D-Fender | THE FUCKING ATTEMPT |
22:41.12 | [TK]D-Fender | YES |
22:41.17 | [TK]D-Fender | CLI. Show it FAIL <------------ |
22:43.24 | *** join/#asterisk pruonckk (~pruonckk@4-137-11-177.raimax.com.br) |
23:04.16 | [TK]D-Fender | goes to look for a good recipe for crickets... |
23:12.34 | *** join/#asterisk pruonckk (~pruonckk@4-137-11-177.raimax.com.br) |
23:33.56 | life_of_e | Go for any recipes with dark chocolate. The polyphenols will be good for you. |
23:46.28 | *** join/#asterisk pruonckk (~pruonckk@4-137-11-177.raimax.com.br) |
23:52.43 | *** join/#asterisk pchero (~pchero@dhcp-077-249-058-090.chello.nl) |