| 00:00.54 | *** join/#asterisk _Catatronic (~catatroni@184.75.214.163) |
| 00:23.27 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 00:28.56 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 00:35.28 | *** join/#asterisk jkroon (~jkroon@165.16.204.172) |
| 01:01.14 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 01:03.39 | *** join/#asterisk tuxd00d (~tuxd00d@ip68-106-11-138.ph.ph.cox.net) |
| 01:24.04 | *** join/#asterisk giesen (~ggiesen@2001:19f0:0:1019:5400:ff:fe25:bda6) |
| 01:37.56 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 01:45.43 | *** join/#asterisk RovingWriter (~RovingWri@unaffiliated/rovingwriter) |
| 01:57.24 | *** join/#asterisk shuishui (~chirpin-2@114.221.18.152) |
| 02:07.13 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:33.21 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 02:42.31 | *** join/#asterisk MrTAP1 (~MrT@unaffiliated/mrtap) |
| 04:09.29 | *** join/#asterisk SoBlindWolf (~SoBlindWo@go.pcshost.co) |
| 04:15.52 | *** join/#asterisk gerhard7_ (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 04:26.12 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 04:51.21 | *** join/#asterisk shuishui (~chirpin-2@114.221.18.152) |
| 05:59.32 | *** join/#asterisk shuishui (~chirpin-2@114.221.18.152) |
| 06:21.03 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 06:47.05 | *** join/#asterisk boris_t (~boris_t@95.183.44.106) |
| 07:29.10 | *** join/#asterisk sekil (~sekil@cable-89-216-224-242.dynamic.sbb.rs) |
| 07:30.29 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 07:33.05 | *** join/#asterisk shuishui (~chirpin-2@114.221.18.152) |
| 07:50.52 | *** join/#asterisk Rac-on (jasper@bambi.rac-on.nl) |
| 08:09.31 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
| 08:14.11 | *** join/#asterisk pawiecki (~pawiecki@89.238.53.32) |
| 08:19.19 | *** join/#asterisk pchero_work (~pchero@109.70.54.56) |
| 08:35.06 | *** join/#asterisk defsdoor (~andy@cpc120600-sutt6-2-0-cust177.19-1.cable.virginm.net) |
| 08:46.54 | *** join/#asterisk shuishui (~chirpin-2@114.221.18.152) |
| 09:22.44 | *** join/#asterisk shuishui (~chirpin-2@114.221.18.152) |
| 10:10.32 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 10:26.41 | *** join/#asterisk lankanmon (~LKNnet@CPE64777dd7e053-CM64777dd7e050.cpe.net.cable.rogers.com) |
| 11:24.01 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 11:49.51 | *** join/#asterisk BoBeR182 (~BoBeR182@gateway/tor-sasl/bober182) |
| 12:14.33 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 12:35.08 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 12:41.38 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 12:42.56 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 12:43.01 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 12:50.48 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 13:03.44 | *** join/#asterisk dakudos (~dakudos@c-73-203-6-107.hsd1.co.comcast.net) |
| 13:08.50 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 13:10.04 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:10.04 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 13:15.04 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 13:28.19 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 13:47.05 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 14:08.01 | *** join/#asterisk bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:08.02 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:14.28 | *** join/#asterisk DanB (~DanB@clt-195.192.205.247.ip-anschluss.net) |
| 14:15.34 | *** join/#asterisk kharwell (kharwell@nat/digium/x-htryzrbtlqpmuxor) |
| 14:15.34 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:19.50 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:19.50 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:21.24 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:21.24 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:22.47 | *** join/#asterisk pawiecki (~pawiecki@router.dir.pl) |
| 14:23.55 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 14:29.13 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-nbxqcqefvetsudjx) |
| 14:29.13 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 14:32.56 | BoBeR182 | Hello |
| 14:33.33 | BoBeR182 | I can't set my voicemail greeting or anything, because my asterisk server does not seem to recognize when I push buttons on the dail pad of linphone |
| 14:33.54 | [TK]D-Fender | set the right dtmfmode in your peer to match |
| 14:34.13 | *** join/#asterisk happy-dude (uid62780@gateway/web/irccloud.com/x-agphafhtgpgyouns) |
| 14:36.45 | BoBeR182 | how would I find what I need to copy? |
| 14:37.13 | [TK]D-Fender | "copy"? |
| 14:37.17 | [TK]D-Fender | set the right mode |
| 14:37.25 | [TK]D-Fender | Go find out what linphone is using and SET IT |
| 14:37.46 | [TK]D-Fender | this is 1 value in your peer |
| 14:38.11 | [TK]D-Fender | Read the sample config, and check your linphone settings & docs |
| 14:38.17 | BoBeR182 | I'm using freepbx |
| 14:38.59 | BoBeR182 | DTMF with RFC4733 is what linphone uses |
| 14:39.32 | [TK]D-Fender | take it to their channel then |
| 14:39.45 | [TK]D-Fender | you have to obey their drop-downs, etc to fill this in |
| 14:40.01 | [TK]D-Fender | We can't just tell you a parameter name when their GUI builds them all for you |
| 14:40.11 | [TK]D-Fender | ~freepbx |
| 14:40.11 | infobot | [~freepbx] FreePBX is unable to be supported here. It is made up of complex dialplans and scripts which can't be easily supported by people who aren't deeply involved. Try joining #freepbx and asking there |
| 14:40.48 | BoBeR182 | hmm, it already set to RFC 4733 in the extension options |
| 14:40.59 | BoBeR182 | but I will ask in their channel |
| 14:48.47 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 14:50.50 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 15:12.02 | *** join/#asterisk DanB (~DanB@clt-195.192.205.247.ip-anschluss.net) |
| 15:40.44 | *** join/#asterisk oroborous (~snek@185.82.202.242) |
| 15:47.17 | oroborous | Hello! When speaking about VOIP protocols, how is the tariff signaled? For example, how can a system tell if a number it wants to connect to has a bigger tariff than an usual-rate one? Are the rates communicated between carriers before a route is available? |
| 15:52.11 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 15:52.38 | [TK]D-Fender | Depends on the protocol. H.323's mechanism is well documented. SIP is more of a "suggestion" |
| 15:52.50 | [TK]D-Fender | * doesn't really manage either AFAIK |
| 15:54.47 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 15:59.41 | Samot | oroborous: No. They are not. |
| 15:59.41 | *** join/#asterisk miralin (~Thunderbi@194.8.128.62) |
| 16:00.10 | Samot | ATT does not tell CenturyLink, on the fly, the cost of their route. |
| 16:00.22 | Samot | They tell them before hand so CenturyLink can make that choice. |
| 16:03.06 | Samot | Tariffs have nothing to do with transport method outside of one of the parties deciding that "H.323 is more than SIP" |
| 16:03.24 | Samot | So H.323 vs SIP has nothing to do with it. |
| 16:06.06 | oroborous | Sure, I was generally speaking, so I can make an idea of the the whole process |
| 16:06.13 | Samot | oroborous; What you are asking about more or less Least-Cost Routing where the carrier sending the call looks at what routes they have are the least-cost and sends it there. |
| 16:06.32 | Samot | Carriers share rate decks |
| 16:06.51 | Samot | ATT will tell CenturyLink this is how much it costs for X destination. |
| 16:07.02 | Samot | The other carriers will tell CenturyLink that as well. |
| 16:07.19 | Samot | Then CenturyLink decides how and where to send the calls. |
| 16:07.36 | Samot | Route A may be cheaper but has audio issues but Route C is a little more but doesn't. |
| 16:07.46 | Samot | So use Route C. |
| 16:07.50 | *** join/#asterisk dtascom (~dtascom@static-47-180-162-26.lsan.ca.frontiernet.net) |
| 16:09.27 | Samot | The only way the method of transport (SIP/IP or SS7/Copper, etc) impacts the rates is if the receiving carrier decides "You know what, I rather have all my stuff over IP so I'm going to make the copper/TDM/POTS routes most costly for them to send to" |
| 16:09.52 | Samot | Then the other side goes "Oh well we're going to send IP to them since it's cheaper" |
| 16:11.21 | *** join/#asterisk [sID] (~sid@logv.pl) |
| 16:12.38 | Samot | oroborous: The whole process is a groups of standards that are followed but can be overridden between two carriers based on their own interconnection setup. |
| 16:13.05 | [sID] | Samot: Hi |
| 16:13.14 | [sID] | How can I analyze connection with AMD in dial level? |
| 16:13.21 | [sID] | I have a dial then someone receives and should be analyzed |
| 16:15.46 | oroborous | Samot: thank you very much, it was very helpful :) |
| 16:20.12 | [TK]D-Fender | [sID], "core show application dial" |
| 16:21.06 | [sID] | [TK]D-Fender: I have this case |
| 16:21.08 | [sID] | http://forums.asterisk.org/viewtopic.php?f=1&t=90374 |
| 16:21.24 | [sID] | I have to analyze before answered |
| 16:21.57 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 16:22.09 | [TK]D-Fender | Your second one makes no sense |
| 16:22.30 | [TK]D-Fender | And neither of those show any SETTINGS for how you are tuning AMD |
| 16:22.37 | Samot | Wait. |
| 16:22.39 | Samot | Hang on. |
| 16:22.47 | Samot | Let's address what that is first. |
| 16:23.01 | Samot | Because, no AMD cannot figure out what is on the other side before the call is answered. |
| 16:23.08 | Samot | How would that be possible? |
| 16:23.13 | [TK]D-Fender | Is there a way to run AMD during an outgoing call, before the call being answered? <- and NO. |
| 16:23.24 | Samot | How could it tell if it was a human or a machine before the other side picked up? |
| 16:23.36 | Samot | That's the whole point of AMD |
| 16:23.37 | [TK]D-Fender | There is no background processing. You can run AMD after the call is answered, but before the 2 ends are BRIDGED (which is what your 1st sample wwas doing) |
| 16:23.45 | Samot | To tell if it's a machine or human when it is _answered_ |
| 16:23.59 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
| 16:24.18 | [sID] | hmm |
| 16:24.52 | [sID] | So I have to transfer the received connection to another context in which AMD will listen and analyze? |
| 16:25.06 | Samot | You're making an outbound call? |
| 16:25.10 | [sID] | yes |
| 16:25.13 | Samot | Like a person is making the call? |
| 16:25.22 | Samot | Or the system is originating the call? |
| 16:25.41 | [sID] | system is originating the call |
| 16:25.44 | Samot | OK |
| 16:25.52 | Samot | so you have to send the call, have it answered.. |
| 16:25.55 | Samot | Run AMD |
| 16:25.57 | Samot | Then do something. |
| 16:26.07 | [sID] | When he sees 200 OK, he makes a transfer to the agent |
| 16:26.07 | Samot | Based on the AMD results. |
| 16:26.14 | Samot | No. |
| 16:26.25 | Samot | You have to DETECT first |
| 16:26.29 | Samot | you just can't send |
| 16:26.36 | [TK]D-Fender | * calls out. The call gets answered. Before bridging run AMD |
| 16:26.36 | Samot | You have to see if AMD finds a machine or a human |
| 16:26.41 | [TK]D-Fender | you are already doing this in your 1st example |
| 16:26.44 | Samot | Then you can send to your agent if its a human |
| 16:27.02 | Samot | AMD needs audio |
| 16:27.09 | Samot | Or something. |
| 16:27.38 | [sID] | Ok, but how do I redirect to another dial/ |
| 16:27.39 | [sID] | ? |
| 16:27.43 | [TK]D-Fender | There is no redirect |
| 16:27.52 | [sID] | :| |
| 16:28.06 | Samot | You use a local channel to dial out |
| 16:28.08 | [TK]D-Fender | Your description is BAD |
| 16:28.22 | Samot | That local channel switches from being and outbound channel.. |
| 16:28.32 | Samot | To an INBOUND channel once the other side answers. |
| 16:28.32 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 16:28.40 | Samot | Effectively giving you an IVR |
| 16:28.45 | Samot | So you treat the call as such |
| 16:28.46 | Samot | DIAL |
| 16:28.56 | [TK]D-Fender | If you are trying to AUTOMATE a call out, check if it's human, then if it is THEN call someone else then you're mostly there with this first letg as it is |
| 16:29.01 | Samot | The callee and the agent will be bridged. |
| 16:29.08 | Samot | Right. |
| 16:29.16 | Samot | So if the response is HUMAN |
| 16:29.16 | [TK]D-Fender | And your Extensions should be the code to dial the target in the case of being "human" |
| 16:29.24 | Samot | You Dial() your agent. |
| 16:29.31 | Samot | Then those two channels are bridged. |
| 16:29.35 | Samot | Like a normal inbound call. |
| 16:29.37 | [sID] | What should an exemplary dialplan look like? |
| 16:29.45 | Samot | google can help with that |
| 16:29.51 | [TK]D-Fender | Dial(SIP/whatever) |
| 16:29.57 | [TK]D-Fender | what part of "dial" are you having trouble with>? |
| 16:30.01 | Samot | This is well documented out there. |
| 16:30.02 | [TK]D-Fender | there are TWO halves to this |
| 16:30.09 | [TK]D-Fender | the calling OUT, and the calling of your AGENT |
| 16:30.11 | Samot | This is basically how all outbound dialers work on Asterisk. |
| 16:30.24 | [TK]D-Fender | these are SEPARATE dialplan pieces |
| 16:30.38 | Samot | Yup. |
| 16:30.58 | Samot | 1) Asterisk is calling a destination and handling that call. AMD and such |
| 16:31.10 | Samot | 2) Asterisk is calling an agent |
| 16:31.15 | [TK]D-Fender | http://forums.asterisk.org/viewtopic.php?f=1&t=90374 <- Originate to the FIRST sample code here. |
| 16:31.17 | Samot | Based on 1 |
| 16:31.33 | [sID] | http://wklej.org/id/3285226/ |
| 16:31.34 | [TK]D-Fender | and the TARGET to different dialplan to dial out to wherever |
| 16:31.55 | Samot | No. |
| 16:31.58 | Samot | Not at all |
| 16:32.07 | Samot | If Asterisk is making the call.. |
| 16:32.12 | Samot | There should be an ORIGINATE |
| 16:32.23 | [TK]D-Fender | Samot, I believe that's the target if the first is human |
| 16:32.35 | [TK]D-Fender | And yes, we are working on that premise of being an Originated call |
| 16:32.37 | Samot | Why is there AMD in there? |
| 16:32.49 | [TK]D-Fender | AMD in the first sample, not this latest |
| 16:32.51 | Samot | Why would that be the dialplan to call the agent with AMD |
| 16:33.01 | Samot | Look at his last paste |
| 16:33.04 | [TK]D-Fender | this last PB should be the "if human" part to bring in |
| 16:33.15 | Samot | <PROTECTED> |
| 16:33.15 | Samot | <PROTECTED> |
| 16:33.20 | Samot | ^^ AMD to me |
| 16:33.27 | [TK]D-Fender | Oh... yeah, that part is dumb |
| 16:33.34 | Samot | But look at the Dial() |
| 16:33.37 | Samot | + |
| 16:33.40 | [TK]D-Fender | I stopped when the rest looked intact as a second half |
| 16:33.41 | Samot | That's the OUT |
| 16:33.56 | Samot | The last paste was how the calls are sent out |
| 16:34.00 | [TK]D-Fender | Everything is "out" with this loose a dictionary so far... |
| 16:34.32 | Samot | same => n,Dial(SIP/+${EXTEN}@${OP},60) <-- That's not dialing an agent. |
| 16:34.51 | Samot | Unless all the agents are on remote devices not connected to Asterisk. |
| 16:35.00 | Samot | That's making the outbound call. |
| 16:35.08 | [TK]D-Fender | [sID], So far you have not clearly said HOW you expect this to process. |
| 16:35.09 | [sID] | So I have the parameter gM (analisechamada-amd) |
| 16:35.09 | [sID] | Give context where AMD is? |
| 16:35.25 | Samot | [sID]: You are not using Originate |
| 16:35.31 | Samot | Which is what you should be doing. |
| 16:35.32 | [TK]D-Fender | <[TK]D-Fender> [sID], So far you have not clearly said HOW you expect this to process. <---------------- |
| 16:35.53 | [TK]D-Fender | describe EXACTLY how you expect the start of the whole process to happen and the flow. |
| 16:36.16 | [sID] | wait wait |
| 16:36.32 | [sID] | calmly |
| 16:36.49 | [TK]D-Fender | <[TK]D-Fender> describe EXACTLY how you expect the start of the whole process to happen and the flow. <-------------- |
| 16:37.06 | [sID] | ok |
| 16:37.27 | [TK]D-Fender | Pay attention to the word "EXACT". I mean it. what is the first action to TRIGGER the start of whatever you're looking to do and walk through the processing you want to have happen in EXACT order |
| 16:39.05 | [sID] | I have a portago softphone that makes a call by registering a sip account. |
| 16:39.06 | [sID] | It chooses the connection and falls into the voicemail and the call wants to disconnect |
| 16:39.23 | [sID] | The correct redirection to the agent |
| 16:39.48 | [TK]D-Fender | you are skipping ahead |
| 16:39.57 | [sID] | My system makes a transfer as soon as it sees that it is ANSWERED |
| 16:40.14 | [TK]D-Fender | START OVER |
| 16:40.42 | [sID] | So I need to have voice mail info in advance |
| 16:40.48 | Samot | What? |
| 16:40.49 | [TK]D-Fender | you have a USER with a softphone that DECIDES to place a call? Is this the start? |
| 16:40.52 | Samot | You are not being clear. |
| 16:41.10 | Samot | How did voicemail get involved? |
| 16:41.17 | [TK]D-Fender | LINEAR <- learn how to describe things in simple direct order. |
| 16:41.29 | [TK]D-Fender | I should not hear "voicemail until half-way through the whole damn process |
| 16:41.48 | [TK]D-Fender | you have no confirmed the EXACT action that starts this and how that is triggered. Nor the NEXT step exactly |
| 16:41.58 | [TK]D-Fender | You can't have voicemail before a call is EXECUTED |
| 16:42.03 | [sID] | I'm hard to explain because I do not know English well. |
| 16:42.05 | [sID] | :| |
| 16:42.05 | [TK]D-Fender | Your description SKIPS everything important |
| 16:42.09 | Samot | OK. |
| 16:42.10 | Samot | Step 1 |
| 16:42.16 | Samot | How is the call made? |
| 16:42.16 | [TK]D-Fender | ^^^^^^^^^^^^ |
| 16:42.18 | Samot | ^^^^^ |
| 16:42.24 | Samot | Answer that and just that. |
| 16:43.10 | Samot | Step 1 is "How does this process start. What starts it." |
| 16:43.15 | [sID] | It is called portago softphone |
| 16:43.20 | Samot | OK |
| 16:43.25 | Samot | So let me expand |
| 16:43.27 | Samot | Is a PERSON |
| 16:43.35 | Samot | Or the PBX making the call? |
| 16:43.55 | [sID] | It runs a program written in C ++ |
| 16:43.59 | Samot | OK |
| 16:44.15 | [TK]D-Fender | wrong details |
| 16:44.22 | Samot | Stop |
| 16:44.26 | [TK]D-Fender | is this a FUCKING PERSON using the softphone TELLING it to dial? |
| 16:44.54 | [TK]D-Fender | what TRIGGERS the whole fucking start of this process? |
| 16:44.55 | *** join/#asterisk shootbird (~quassel@205.185.122.214) |
| 16:44.57 | oroborous | :)) |
| 16:45.12 | [sID] | Do not get upset, calm down |
| 16:45.25 | Samot | [sID]: I'm going to ask one more time. |
| 16:45.32 | [TK]D-Fender | You don't seem to understand the concept of "what STARTS this whole process" |
| 16:45.37 | [sID] | Automat? |
| 16:45.43 | Samot | How is the call started? Does a REAL person make a call or is the PBX doing it automatically? |
| 16:45.51 | [TK]D-Fender | THINK IN A STRAIGHT LINE. DO NOT SKIP STEPS IN YOUR DESCRIPTION. |
| 16:46.15 | [sID] | PBX |
| 16:46.18 | Samot | OK |
| 16:46.22 | Samot | So this is SOFTWARE doing it |
| 16:46.26 | Samot | Not a PERSON |
| 16:46.26 | [sID] | Pbx implements this connection |
| 16:46.32 | Samot | So this is SOFTWARE doing it? |
| 16:46.32 | [sID] | not a PERSON |
| 16:46.35 | Samot | OK |
| 16:47.05 | Samot | HOW does the software send the call to Asterisk |
| 16:47.12 | Samot | Does it use AMI? |
| 16:47.25 | Samot | Or does it generate Callfiles? |
| 16:47.31 | [TK]D-Fender | <[sID]> Pbx implements this connection <- HOW |
| 16:47.34 | [sID] | Sends the invite as it does every softphone |
| 16:47.41 | [TK]D-Fender | DETAILS. A call doesn't happen by MAGIC |
| 16:47.51 | Samot | Oh FFS. |
| 16:48.01 | Samot | This is acting like an automated person running a softphone |
| 16:48.04 | [TK]D-Fender | no, that is the PHONE calling your SERVER <- |
| 16:48.11 | [TK]D-Fender | that is not the server DECIDING to start somethign |
| 16:48.14 | Samot | No no no.. |
| 16:48.23 | Samot | This is basically a device making a call to Asterisk |
| 16:48.26 | Samot | Like normal. |
| 16:48.29 | Samot | So.. |
| 16:48.35 | Samot | It generates an INVITE |
| 16:48.50 | Samot | So it's an automated phone basically. |
| 16:48.57 | [TK]D-Fender | is it? |
| 16:49.05 | [sID] | yes |
| 16:49.09 | [sID] | !! |
| 16:49.13 | [sID] | :) |
| 16:49.13 | [TK]D-Fender | so the USER didn't tell it to do this? |
| 16:49.15 | Samot | It's generating INVITES |
| 16:49.19 | Samot | Right |
| 16:49.26 | [sID] | right |
| 16:49.31 | [TK]D-Fender | how did it decide that that moment was a good moment to call? Or what to call? |
| 16:49.32 | Samot | It's sending a normal SIP call to Asterisk |
| 16:49.37 | Samot | Like your polycom. |
| 16:50.18 | Samot | It doesn't matter how it decides when to send a call |
| 16:50.27 | Samot | HOW it sends the call to Asterisk is what matters. |
| 16:50.42 | Samot | Sending a normal SIP INVITE is just like you calling for your deskphone. |
| 16:50.42 | [sID] | I use this https://www.portsip.com/portgo-softphone/ of this library to make a connection to a PBX asterisk |
| 16:50.54 | Samot | How you're going to make this work, don't know. |
| 16:50.56 | [TK]D-Fender | It may matte if we find some kind of separation from the "calling" user in case of some insane BS |
| 16:51.10 | Samot | It sends an INVITE |
| 16:51.12 | [TK]D-Fender | because with a description this shit... I'm not ruling this out |
| 16:51.13 | Samot | That's all that matters. |
| 16:51.17 | Samot | It sends an INVITE |
| 16:51.19 | Samot | It sends an INVITE |
| 16:51.22 | [sID] | Samot: And so it is done |
| 16:51.40 | [TK]D-Fender | yes, but I have heard of libs that don't have a HUMAN on the other end |
| 16:51.52 | Samot | OK |
| 16:52.02 | [TK]D-Fender | it's jsut there to trigger things and pass off, not with a direct audio interface like a more basic softphone |
| 16:52.12 | [TK]D-Fender | basically a non CPE SIP dialer |
| 16:52.20 | [TK]D-Fender | just in case this thing is a stupid POS |
| 16:52.27 | [TK]D-Fender | I trust nothing |
| 16:52.32 | Samot | So basically it sends an INVITE like an normal call |
| 16:52.36 | [TK]D-Fender | so far |
| 16:52.41 | Samot | Which will have to be answered.. |
| 16:52.45 | [TK]D-Fender | [sID], is taht dialer on a USER'S PC? |
| 16:52.52 | Samot | Then an Originate is going to be needed to send the call to the destination |
| 16:52.55 | [TK]D-Fender | Are they there with a HEADSET connected via that softphone? |
| 16:52.59 | Samot | And then to do AMD |
| 16:53.03 | Samot | And then connect to an agent. |
| 16:53.10 | Samot | If that is the way it's supposed to go |
| 16:53.16 | [TK]D-Fender | If so then our 1st example was pretty much fine from the start |
| 16:53.29 | [TK]D-Fender | (minus having any settings at all) |
| 16:54.34 | [sID] | This application is registered under SIP account and makes connections. When he sees that he is being redirected to the agent. |
| 16:55.02 | [TK]D-Fender | Where is this REDIREDCT? |
| 16:55.15 | [TK]D-Fender | Again, is that portsip thing on a USERS PC? |
| 16:55.27 | [sID] | To agent under another sip account |
| 16:55.47 | [TK]D-Fender | YES OR NO? |
| 16:56.02 | [sID] | No users PC.. |
| 16:56.06 | [sID] | server |
| 16:56.19 | [TK]D-Fender | Samot, ... I hate being right |
| 16:57.13 | [TK]D-Fender | I had to ask 10 times to find out there isn't a human on that portsip side... |
| 16:57.27 | [sID] | Dialler SIP 1000 -> make call 123456789 -> PBX -> ANSWERED -> REDIRECT to Agent another SIP 2000 |
| 16:57.44 | *** join/#asterisk jkroon (~jkroon@165.16.204.163) |
| 16:57.49 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 16:58.28 | [sID] | The dialer performs a call like any other softphone installed on windows or another system |
| 17:00.29 | [TK]D-Fender | [sID], "core show application dial" <- AFTER you complete your macro and allow the call to bridge there is ANOTHER dial setting where yuo can tell it to take that caller and put them somewhere else in your dialplan |
| 17:05.40 | [sID] | Ok, thanks for trying it now. |
| 17:18.40 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 17:19.03 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 17:23.16 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 17:30.58 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 17:37.50 | *** join/#asterisk danielyk (~danielyk@p4FDDBF4F.dip0.t-ipconnect.de) |
| 17:40.08 | *** join/#asterisk retentiveboy (~retentive@c-73-82-30-193.hsd1.ga.comcast.net) |
| 17:43.09 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 17:43.09 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 17:44.14 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 17:46.56 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 17:47.59 | *** join/#asterisk almostworking (~almostwor@unaffiliated/almostworking) |
| 17:49.32 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 17:49.50 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 17:52.32 | *** join/#asterisk zamba (marius@flage.org) |
| 17:54.41 | startledmarmot | file: is there currently any demo of the screen sharing functionality in 15? |
| 17:57.04 | [TK]D-Fender | ? |
| 17:58.47 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 18:02.39 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 18:07.50 | file | startledmarmot: the client stuff is not available |
| 18:07.58 | file | which is really where it is done |
| 18:08.18 | startledmarmot | yeah - was curious if I'd missed it somewhere |
| 18:09.40 | startledmarmot | been playing with the sfu bits quite a lot; a+ work there |
| 18:09.55 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 18:10.03 | file | 'tis a good foundation |
| 18:25.00 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 18:40.22 | *** join/#asterisk masterkush (~masterkus@110-44-125-23.vianet.com.np) |
| 18:41.06 | kaus33k | any one here |
| 18:41.20 | kaus33k | hello |
| 18:45.54 | file | I'm sure someone is here. |
| 18:46.02 | kaus33k | oh hey |
| 18:47.05 | kaus33k | i was wondering that some one can help me for my project with their valuable suggestions |
| 18:47.26 | file | if you ask a question someone in here may answer |
| 18:48.13 | kaus33k | so my project is to basically forward a call to PSTN using asterisk server |
| 18:48.38 | kaus33k | so any one can provide me some suggestions |
| 18:48.49 | [TK]D-Fender | Call from where? |
| 18:48.59 | [TK]D-Fender | details matter. |
| 18:49.07 | [TK]D-Fender | from where? How? To where? How? |
| 18:49.23 | kaus33k | from an Ip phone to PSTN |
| 18:49.32 | BoBeR182 | like you have a incoming DID? |
| 18:49.35 | [TK]D-Fender | to PSTN HOW? |
| 18:49.43 | [TK]D-Fender | * has lots of ways to get there |
| 18:50.10 | [TK]D-Fender | physical lines on-site with a PC card. Or a gateway device. Or you could use an ITSP |
| 18:50.20 | [TK]D-Fender | and 'IP phone" needs ot be clear on the language it speaks |
| 18:50.22 | kaus33k | though i have ordered a PSTN card to be attached to my server |
| 18:50.49 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 18:50.49 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 18:51.25 | [TK]D-Fender | Depends on that card |
| 18:51.31 | [TK]D-Fender | What exactly did you buy? |
| 18:52.45 | kaus33k | so in my project i have setup an VOIP environment for IP phones which is working great but not i want to route calls to PSTN network from internal VOIP phones |
| 18:53.18 | kaus33k | so is the PSTN card necessary? cant we use something else? |
| 18:53.21 | [TK]D-Fender | And you're not giving details |
| 18:53.26 | [TK]D-Fender | WHAT CARD? |
| 18:53.30 | [TK]D-Fender | WHAT PHONES? |
| 18:53.48 | [TK]D-Fender | it matter that they are compatible with * |
| 18:54.10 | *** join/#asterisk sekil (~sekil@cable-89-216-224-242.dynamic.sbb.rs) |
| 18:55.27 | kaus33k | lets forget about cards... just suggest me the ways how can i call to PSTN from my internal Asterisk Server suing IP Phones |
| 18:55.45 | [TK]D-Fender | I just told you |
| 18:55.47 | kaus33k | can you tell me more about an gateway devide? |
| 18:55.53 | kaus33k | device* |
| 18:55.55 | [TK]D-Fender | <[TK]D-Fender> * has lots of ways to get there |
| 18:55.55 | [TK]D-Fender | <[TK]D-Fender> physical lines on-site with a PC card. Or a gateway device. Or you could use an ITSP |
| 18:56.02 | [TK]D-Fender | depends what kind you want |
| 18:56.07 | [TK]D-Fender | Depends what lines you have |
| 18:56.14 | [TK]D-Fender | You aren't giving ANY useful information |
| 18:56.15 | BoBeR182 | you can set up a SIP trunk with a provider like flowroute |
| 18:56.25 | BoBeR182 | then you can call PTSN lines from an IP phone |
| 18:56.32 | BoBeR182 | you will be charged by min per call |
| 18:57.06 | kaus33k | what if i dont use SIP trunk providers? |
| 18:57.29 | [TK]D-Fender | What do yuo WANT to use for it? |
| 18:57.31 | BoBeR182 | you want to do this for free? |
| 18:57.40 | kaus33k | not free |
| 18:59.26 | [TK]D-Fender | wonders how hard it can be to answer direct questions... |
| 19:00.02 | kaus33k | i read an article where it has been written that Asterisk server needs a PRI card attached where we can attached our digital telephones lines and can configure with dahdi to call over digital telephones lines using VOIP phones |
| 19:00.22 | [TK]D-Fender | Do you HAVE a PRI? |
| 19:00.48 | [TK]D-Fender | normally only larger businesses have PRI's |
| 19:00.56 | kaus33k | not basically but i will have one |
| 19:01.11 | kaus33k | may have one |
| 19:01.23 | [TK]D-Fender | will? |
| 19:01.24 | [TK]D-Fender | may? |
| 19:01.36 | [TK]D-Fender | You seem to have a SERIOUS issue having ANY details at all. |
| 19:01.38 | kaus33k | yeah may |
| 19:01.53 | [TK]D-Fender | You can't go asking for advise with NOTHING to tell us about what you have or want |
| 19:02.01 | [TK]D-Fender | MAKE UP YOUR MIND |
| 19:02.32 | [TK]D-Fender | All of this vague talk is a complete waste of our time |
| 19:03.02 | kaus33k | basically i am doing an intern on IP telephony using asterisk where i have used SIP to communicate between IP phones and it worked in case for SIP |
| 19:03.06 | [TK]D-Fender | The specifics completely change the list of solutions |
| 19:04.02 | kaus33k | so now i am asked to configure asterisk server to route calls to and from Digital telephony(landlines) |
| 19:04.19 | kaus33k | i mean in and out |
| 19:05.38 | kaus33k | i hope now you get what i am trying to say |
| 19:05.40 | [TK]D-Fender | And we have no solid answer as to what we're calling OUT or how |
| 19:06.36 | BoBeR182 | OUT probably means normal landline type phones |
| 19:06.46 | kaus33k | yes |
| 19:06.49 | [TK]D-Fender | You have not clearly stated exactly what kind of lines and how many you have. You have not confirmed what this hardware you "ordered" is. |
| 19:06.54 | BoBeR182 | kaus33k, get a SIP trunk, add it and some outbound rules |
| 19:07.00 | BoBeR182 | you will have to pay per minute |
| 19:07.01 | [TK]D-Fender | "normal" doesn't mean SHIT |
| 19:07.20 | [TK]D-Fender | "normal" is not a thing |
| 19:07.40 | [TK]D-Fender | there are DIFFERENT kinds of physical line technologies to talk to telcos |
| 19:07.51 | [TK]D-Fender | GET AN ANSWER FOR THIS |
| 19:08.14 | sekil | kaus33k: digital telephony means either ISDN or SIP nowadays.. |
| 19:08.27 | [TK]D-Fender | head-desks |
| 19:09.23 | sekil | kaus33k: so like [TK]D-Fender said...an answer needs a question as to what are going to use |
| 19:10.27 | kaus33k | ok lets us consider i have a telephone line provided by ISDN to be attached to my server. I have configured asterisk aserver for VOIP phones as now i want to communicate to ISDN using IP phones |
| 19:12.25 | sekil | kaus33k: so go buy appropriate ISDN card (Digium or Sangoma are best bet) and configure it |
| 19:12.54 | kaus33k | oh |
| 19:13.17 | kaus33k | is there another way rather than using ISDN card? |
| 19:13.30 | kaus33k | but not SIP trunking |
| 19:14.05 | sekil | kaus33k: to buy a gateway device.. |
| 19:14.41 | kaus33k | would you like to elaborate more about gateway device? |
| 19:14.54 | *** join/#asterisk tzafrir (~tzafrir@212.29.194.37) |
| 19:17.47 | sekil | kaus33k: yes...buy one ..there's many vendors.. |
| 19:18.07 | [TK]D-Fender | What KIND of ISDN? |
| 19:18.11 | [TK]D-Fender | BRI != PRI |
| 19:18.59 | sekil | (08:12:25 PM) sekil: kaus33k: so go buy appropriate ISDN card (Digium or Sangoma are best bet) and configure it |
| 19:19.01 | [TK]D-Fender | <kaus33k> would you like to elaborate more about gateway device? <- they make magical boxes yuo talk voip to and then you plug your lines into them. The end. |
| 19:19.34 | kaus33k | dont you have to configure gateway device? |
| 19:19.48 | sekil | kaus33k: are you kidding with us? |
| 19:19.56 | sekil | kaus33k: of course you do |
| 19:20.05 | kaus33k | ok ok |
| 19:20.20 | [TK]D-Fender | <[TK]D-Fender> What KIND of ISDN? |
| 19:20.20 | [TK]D-Fender | <[TK]D-Fender> BRI != PRI |
| 19:20.36 | *** join/#asterisk RovingWriter (~RovingWri@unaffiliated/rovingwriter) |
| 19:20.37 | kaus33k | i am basically a newbie for asterisk... please dont mind me |
| 19:20.47 | [TK]D-Fender | <kaus33k> though i have ordered a PSTN card to be attached to my server <- Why do we not have a MODEL # for what you bought? |
| 19:21.36 | Samot | 3:13:18 PM K<kaus33k> is there another way rather than using ISDN card? |
| 19:21.36 | Samot | 3:13:32 PM K<kaus33k> but not SIP trunking |
| 19:21.39 | Samot | ^^^ No. |
| 19:21.48 | kaus33k | TLANI4R |
| 19:22.03 | Samot | The gateway device will convert it to SIP |
| 19:22.18 | Samot | So you'll be "trunking" from Asterisk to the gateway device. |
| 19:22.48 | [TK]D-Fender | kaus33k, that isn't somethign you can plug into your * server |
| 19:22.59 | [TK]D-Fender | So what are you expecting to do with it? |
| 19:23.14 | kaus33k | one of my friend suggested it to me |
| 19:23.26 | kaus33k | and i said ok |
| 19:23.46 | [TK]D-Fender | Well you don't seem to have any idea what you're doing at all... |
| 19:23.56 | [TK]D-Fender | and can't tell on sight that piece of hardware has no place in a PC |
| 19:24.02 | kaus33k | yeah basically in case of ISDN |
| 19:24.06 | [TK]D-Fender | https://www.theticshop.com/tlani4r-analog-trunk-module-4-hkz-with-clip-for-hipath-3300-3500.html |
| 19:24.14 | [TK]D-Fender | Does this PoS look like a PC component? |
| 19:24.56 | [TK]D-Fender | hope you can cancel that order.... |
| 19:25.02 | Samot | The card is not for PC or servers as such |
| 19:25.07 | Samot | That's a waste. |
| 19:25.29 | Samot | It states it is for specific hardware. |
| 19:25.35 | kaus33k | yap i have canceled it |
| 19:25.56 | Samot | ~book |
| 19:25.56 | infobot | Asterisk: The Definitive Guide, 4th Edition (ISBN 1-4493-3242-0) available at http://oreilly.com/catalog/0636920025894 - Asterisk: The Definitive Guide is released under a Creative Commons License (http://creativecommons.org/licenses/by-nc-nd/3.0/us/) and a version is available for reading online at http://www.asteriskdocs.org/ or see ~buybook |
| 19:26.07 | [TK]D-Fender | <[TK]D-Fender> <[TK]D-Fender> What KIND of ISDN? |
| 19:26.07 | [TK]D-Fender | <[TK]D-Fender> <[TK]D-Fender> BRI != PRI |
| 19:26.08 | Samot | http://wiki.asterisk.org |
| 19:26.14 | Samot | Those are were you should start. |
| 19:26.20 | [TK]D-Fender | GET THE ANSWER |
| 19:26.51 | kaus33k | ok thank you |
| 19:27.33 | Samot | Well, unless his host is lying.. |
| 19:27.40 | Samot | Japan which means PRI |
| 19:28.02 | Samot | Because we built the phone network there after we blew it all up really well. |
| 19:29.00 | Samot | There are like three countries in the world that use T-Carrier which means PRI |
| 19:29.07 | Samot | US, Canada and Japan. |
| 19:29.24 | Samot | Guess why those other two are T-Carrier along side the US. |
| 19:29.26 | [TK]D-Fender | this is still assuming PRI at all |
| 19:29.29 | [TK]D-Fender | we don't have an answer |
| 19:29.31 | Samot | Dude |
| 19:29.32 | Samot | FFS |
| 19:29.34 | Samot | T-CARRIER |
| 19:29.35 | [TK]D-Fender | and I've asked this a dozen times |
| 19:29.38 | Samot | JAPAN |
| 19:29.42 | Samot | OK |
| 19:29.44 | [TK]D-Fender | just like I asked a dozen times for the model of card he ordered |
| 19:29.49 | Samot | Japan doesn't do E-Carrier |
| 19:29.54 | Samot | E-Carrier is how BRI is done. |
| 19:30.30 | [TK]D-Fender | Who said anything about japan? |
| 19:30.44 | Samot | 3:27:34 PM <Samot> Well, unless his host is lying.. |
| 19:30.44 | Samot | 3:27:41 PM <Samot> Japan which means PRI |
| 19:31.33 | [TK]D-Fender | Good idea in concept. I want a simple answer to a simple question I had to ask 10 times |
| 19:31.41 | Samot | OK. |
| 19:32.48 | Samot | I mean if you want to get technical.. |
| 19:32.54 | Samot | All that was mentioned was ISDN |
| 19:32.59 | Samot | ISDN != PRI |
| 19:33.02 | Samot | Or BRI |
| 19:33.26 | Samot | Because ISDN could be a DS0 |
| 19:34.03 | [TK]D-Fender | Yes, it could be the shittiest single channel alone... |
| 19:34.10 | Samot | Well |
| 19:34.19 | Samot | If you're going to latch on to things. |
| 19:34.25 | [TK]D-Fender | I had a 56k leased line at my company when I started here... |
| 19:34.29 | Samot | You jumped from ISDN to mean PRI |
| 19:34.37 | [TK]D-Fender | I was at least starting with common reasonable basics. |
| 19:34.42 | [TK]D-Fender | but we got nothing |
| 19:34.45 | Samot | Right |
| 19:34.52 | Samot | So when I saw that he was from Japan |
| 19:34.58 | Samot | And Japan is T-Carrier |
| 19:35.01 | [TK]D-Fender | Or so his host reports |
| 19:35.05 | Samot | The answer is f'ing PRI |
| 19:35.06 | Samot | Right |
| 19:35.08 | [TK]D-Fender | assuming no bouncing, etc |
| 19:35.11 | [TK]D-Fender | what whatever. |
| 19:35.14 | Samot | Just like he said ISDN and you assumed PRI |
| 19:35.16 | [TK]D-Fender | I don't want a guessing game |
| 19:35.22 | [TK]D-Fender | we've wasted so much time on BS already |
| 19:35.26 | Samot | But you just did it yourself. |
| 19:35.38 | Samot | See the point. |
| 19:35.46 | Samot | ISDN is not automatically PRI |
| 19:35.57 | Samot | Just like the host doesn't automatically mean that's where they are from. |
| 19:36.24 | [TK]D-Fender | <Samot> ISDN is not automatically PRI <- I know. |
| 19:36.29 | [TK]D-Fender | I've stated that a dozen times already |
| 19:36.44 | [TK]D-Fender | <[TK]D-Fender> <[TK]D-Fender> <[TK]D-Fender> What KIND of ISDN? |
| 19:36.44 | [TK]D-Fender | <[TK]D-Fender> <[TK]D-Fender> <[TK]D-Fender> BRI != PRI |
| 19:36.51 | [TK]D-Fender | Let's QUINTUPLE repost it... |
| 19:37.09 | [TK]D-Fender | (aside from the previous hand-typed reformmatings of my original request |
| 19:37.14 | Samot | So you assume it's only one of those two options. |
| 19:37.18 | Samot | When there are more on the table. |
| 19:37.31 | [TK]D-Fender | Yes, in theory it could be DS0, but I got NOTHING |
| 19:37.34 | [TK]D-Fender | So whatever |
| 19:37.35 | sekil | didn't Japan had a J-carrier or something |
| 19:37.41 | [TK]D-Fender | it didn't lead to getting any kind of answer |
| 19:37.56 | sekil | it was some dialect if I remember |
| 19:37.59 | [TK]D-Fender | And we're runnign on an assumption based on a host we see |
| 19:38.20 | [TK]D-Fender | Wait till the guy finds some WORDS and learns how to communicate and have a clue of what he's got. |
| 19:48.25 | *** join/#asterisk vstemen (~vince@ip68-12-165-208.ok.ok.cox.net) |
| 19:48.30 | *** join/#asterisk davidbowlby (~textual@99-67-53-141.lightspeed.clmboh.sbcglobal.net) |
| 19:49.18 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:49.18 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 20:02.47 | *** join/#asterisk stoopkid (uid137696@gateway/web/irccloud.com/x-lkttmigawgiosdnk) |
| 20:09.11 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 20:11.12 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 20:11.12 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 20:11.59 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 20:45.51 | *** part/#asterisk slima (~slima@unaffiliated/slima) |
| 20:55.30 | [TK]D-Fender | And we're not getting that answer either... |
| 20:55.37 | [TK]D-Fender | packs up to head home... |
| 21:06.56 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 21:06.56 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 21:17.31 | *** join/#asterisk miralin (~Thunderbi@91.237.94.8) |
| 21:24.25 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 21:24.25 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 21:28.31 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 21:28.32 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 21:37.21 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 21:41.46 | lvlinux | If I have Asterisk setup for Realtime extensions, I still need extensions.conf with the "switch => ...." lines for the contexts I want to be realitime, correct? |
| 21:42.13 | lvlinux | (Assuming I don't specify that extensions.conf is static realtime.) |
| 21:42.18 | file | Realtime extensions like that can cause deadlocks. |
| 21:42.26 | lvlinux | deadlocks? |
| 21:42.36 | lvlinux | what do you mean? |
| 21:43.12 | file | As in, Asterisk deadlocks? |
| 21:43.21 | file | There is a master ticket on JIRA for it |
| 21:43.47 | lvlinux | oh |
| 21:43.48 | file | It also tightly couples your Asterisk to the database, so database issues will ripple to it |
| 21:44.18 | lvlinux | So what then, is the proper way to allow the dialplan to be based on a DB? |
| 21:44.33 | file | Define based on. |
| 21:44.36 | lvlinux | (At least for certain contexts is what I need) |
| 21:45.07 | lvlinux | well I'd like to be able to specify a context that had extensions in it that can be modified/deleted/added on the fly via a database. |
| 21:45.57 | lvlinux | Like entering a new DID, and what happens when it is dialed on a web interface that makes entries in the database. Then Asterisk uses that info without having to do dialplan reload. |
| 21:46.14 | file | func_odbc can pull data from the database and act on it. |
| 21:46.37 | file | You write common logic in normal dial plan and pull dynamic data that way. |
| 21:46.54 | file | That's what others do. |
| 21:47.12 | lvlinux | But can I supply completely new extensions via func_odbc? I knew I could use it for dynamic data within an extension. |
| 21:47.28 | file | You can use a pattern match... |
| 21:47.48 | MrTAP | My instances of Asterisk pretty much rely on func_odbc to obtain any user-specific info |
| 21:47.52 | lvlinux | hmm, ok yes I guess that would work. |
| 21:47.53 | MrTAP | including what to do with a DID and how to route it |
| 21:48.12 | file | It's not about storing the instructions per se in the database, it's about storing the information that common logic can use to do things |
| 21:49.12 | MrTAP | AMI would also allow programmatic changes to the dial plan |
| 21:49.57 | lvlinux | I've never yet messed with AMI or AGI. (not for more than 10 minutes or so anyway...) |
| 21:50.50 | lvlinux | I think func_odbc will meet my needs though, just need to think about the setup a bit differently than I had in mind originally. I assumed using realtime extensions was the "proper" way to do it, but not if it's prone to issues. |
| 21:50.54 | Samot | Ideally, you don't want a lot of dialplan. |
| 21:51.08 | lvlinux | Yes that's what I'm trying to escape from :) |
| 21:51.24 | MrTAP | No you build your static dial plan with all your common needs and then customize exact details with func_odbc queries |
| 21:51.26 | Samot | Well writing new extensions, even in the db is the same. |
| 21:51.49 | Samot | The bigger the DB the longer the query. |
| 21:51.53 | lvlinux | Yes that's true. |
| 21:51.55 | MrTAP | Gosub is very useful if that's not something you're already familiar with |
| 21:52.02 | Samot | ^^^ |
| 21:52.10 | lvlinux | Yes I use gosub quite a bit. |
| 21:52.15 | Samot | GoSub is a magical thing. |
| 21:52.28 | lvlinux | I've been trying to migrate my old macros to GoSub too :) |
| 21:52.29 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 21:52.59 | lvlinux | So are there any particular issues with using sip peers via realtime, or static realtime? |
| 21:53.13 | *** join/#asterisk _r0ck_p3arl_ (~admin@203.149.66.146) |
| 21:53.30 | MrTAP | I use realtime sip peers but if the DB stops responding Asterisk follows suit |
| 21:54.18 | Samot | I mean... |
| 21:54.26 | Samot | It all depends on what you really need. |
| 21:54.29 | Samot | I have a mix. |
| 21:54.36 | Samot | I store somethings in AstDB |
| 21:54.58 | Samot | I use setvar (or set_var) for device peers |
| 21:55.17 | Samot | So those vars are set on the channel that device peer uses. |
| 21:55.19 | file | Yes, chan_sip blocks all other UDP traffic while querying the database |
| 21:55.50 | lvlinux | what about PJSIP (which is what I use)? |
| 21:55.50 | Samot | I've never used Real-Time for this stuff. |
| 21:55.56 | Samot | For? |
| 21:56.16 | Samot | You mean does it block UDP traffic, I'm not sure. |
| 21:56.22 | Samot | file: |
| 21:56.33 | MrTAP | if DB goes down Asterisk won't respond to any SIP traffic with chan_sip |
| 21:56.56 | file | PJSIP doesn't by default, it has a pool of resources for handling inbound traffix |
| 21:56.56 | file | And the data layer it uses has a vastly more configurable and tweakable cache layer |
| 21:57.23 | Samot | I, personally, have never saw the need for Real-Time. |
| 21:57.25 | MrTAP | file ya'll gotta stop finding odd bugs with pjsip so I can trust it enough to switch over ;) |
| 21:57.49 | Samot | MrTAP: I wouldn't hold my breath. |
| 21:58.05 | MrTAP | chan_sip is the beast I know, but pjsip while a lot of nice stuff is still too scary to use in prod |
| 21:58.07 | Samot | MrTAP: The more it is deployed and the more it is used will result in more bugs. |
| 21:58.18 | Samot | Chan_SIP was the same way |
| 21:58.24 | MrTAP | Oh I know |
| 21:58.30 | MrTAP | Been using Asterisk since the pre 1.0 days |
| 21:58.42 | Samot | So PJSIP is going to have bugs found for a while. |
| 21:58.52 | Samot | Specially has it gets into more and more larger deployments |
| 21:59.01 | Samot | And specific types of deployments |
| 21:59.19 | Samot | Some guys at providers have been in here about issues PJSIP has caused that no one else has found. |
| 21:59.39 | Samot | Because they are using it in a environment many aren't. |
| 22:00.31 | MrTAP | Yep I'm well aware and read the changelogs each time there's a release to keep up with what kinds of things are being patched |
| 22:02.26 | lvlinux | The reason I've been thinking of realtime for sip peers is to make it simple to add/delete phones on a pbx system. I know I could just parse the pjsip.conf text file but DB sip peers seemed to be a more scalable solution. But I don't know what I should do now. |
| 22:02.45 | file | there are consequences to tightly coupling anything to a database |
| 22:02.54 | lvlinux | yeah i reckon so. |
| 22:02.55 | file | it's just the way it is |
| 22:03.26 | MrTAP | lvlinux: you could always keep your info in database and simply regenerate your pjsip.conf each time a change is made |
| 22:03.32 | MrTAP | depends how often you're making changes |
| 22:03.38 | lvlinux | yuck though. |
| 22:03.44 | lvlinux | reminds me of freepbx lol |
| 22:03.57 | file | see, I don't consider that yuck |
| 22:04.07 | file | the database is still the central authority and storage of the information |
| 22:04.12 | Samot | Nor do I. |
| 22:04.17 | file | but something else uses that information to configure the software |
| 22:04.19 | MrTAP | yeah it's robust and keeps you away from relying on database but still having the benefits of it |
| 22:04.26 | file | indeed |
| 22:04.30 | Samot | You're asking about ways to make automation better... |
| 22:04.33 | file | database down? no problem, stuff still goes |
| 22:04.37 | Samot | Then balk at the way others do it |
| 22:04.43 | file | backup process locks the table for some reason for a prolonged period of time? that's okay |
| 22:04.59 | Samot | Also.. |
| 22:05.08 | Samot | This is what #include is for. |
| 22:05.19 | MrTAP | +1 for #include |
| 22:05.24 | Samot | I keep my users in their own extensions file. |
| 22:05.29 | lvlinux | yes I do that as well. |
| 22:05.42 | Samot | You can do the same with the peers. |
| 22:05.47 | Samot | Plus.. |
| 22:06.38 | Samot | AMI can edit/update/add to those conf files |
| 22:07.01 | lvlinux | oh? I didn't know that. Maybe I need to look into doing it that way. |
| 22:09.03 | lvlinux | I guess I need to study up on AMI. |
| 22:09.15 | Samot | UpdateConfig |
| 22:10.18 | lvlinux | How can I tie in AMI to a web interface though? |
| 22:10.33 | Samot | Well.. |
| 22:10.50 | Samot | You write stuff that will call on AMI commands and trigger them how they are needed when the GUI processes things. |
| 22:10.54 | Samot | Like anything else. |
| 22:10.55 | *** join/#asterisk startledmarmot (~startledm@2605:e000:845c:0:5529:b587:8cb2:f8af) |
| 22:11.04 | Samot | AMI is an old school API |
| 22:11.14 | Samot | Or can be that way. |
| 22:12.18 | lvlinux | I see there is "PAMI" php ami interface. That might work... |
| 22:12.40 | MrTAP | Yep it gets the job done |
| 22:14.08 | Samot | But really... |
| 22:14.22 | Samot | The most management you should be doing is just to the users. |
| 22:14.32 | Samot | Your dialplan shouldn't be updating all the time. |
| 22:15.04 | MrTAP | Yeah my uses for AMI is to check a peer's status, log members in and out of queues, and to delete SIP peers from memory when I make a change in the realtime db. |
| 22:15.24 | MrTAP | Dial plan is 100% static here |
| 22:15.52 | file | MrTAP: have you... seen the page about caching in PJSIP land? |
| 22:15.58 | Samot | All my clients run through a simple GoSub for inbound calls. |
| 22:16.04 | Samot | Internal or external.. |
| 22:16.20 | Samot | That 10 lines of GoSub sets them up for the rest of the dialplan. |
| 22:16.22 | MrTAP | I haven't looked thoroughly at pjsip because I don't trust it to be as robust as chan_sip so far |
| 22:16.50 | lvlinux | Yeah my dialplan for this one is static. This is for something totally different than what I was needing for the dialplan. Basically all I'm needing this for is to be able to write a simple interface where a "network admin/office manager" person can just log in to a little web interface and add or delete a phone from the system. That's it. |
| 22:17.04 | file | it's actually at the data layer, which is a core API and may see other things use it in the future for new stuff developed... but https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching is a good read on what you can look forward to |
| 22:17.29 | Samot | lvlinux: When you say "phone" do you mean a device or an extension (device/user)? |
| 22:17.42 | MrTAP | Opened the tab and will read it once I have time, thanks |
| 22:18.33 | lvlinux | Samot: on this system, they are one and the same. One phone per user. No hotdesking or anything special. |
| 22:18.41 | Samot | OK |
| 22:18.47 | Samot | So then that means you do have to update dialplan |
| 22:19.01 | lvlinux | not with pjsip :) |
| 22:19.12 | Samot | Because adding a "new extension" means it has to be dialable. |
| 22:19.19 | Samot | Well how does one dial that? |
| 22:19.34 | Samot | Do you have a pretty generic dial routine that pulls data from somewhere? |
| 22:19.56 | lvlinux | All the phones register to 1XXX. Then using pattern matching they can all be easily dialed by the extension itself. |
| 22:20.09 | Samot | Oh |
| 22:20.17 | Samot | That's different. |
| 22:20.38 | Samot | That's a single "account" with multiple AORs. |
| 22:20.50 | lvlinux | no just a single AOR. |
| 22:20.56 | Samot | Well multiple contacts. |
| 22:21.09 | Samot | They're all 1000 |
| 22:21.17 | lvlinux | Single contact per user/extension. |
| 22:21.19 | MrTAP | DIal plan could check if a SIP peer matching that name exists, if so dial it. If not, does a VM box with that name exist? If so connect, if not return a 404. No need to update the dial plan as long as extension numbering follows a pattern |
| 22:21.21 | Samot | K. |
| 22:21.31 | MrTAP | Samot: I think lvlinux has _1XXX or something in his dialplan |
| 22:21.36 | lvlinux | yes |
| 22:21.47 | lvlinux | phones are 1201 1202 1203, etc. |
| 22:21.51 | MrTAP | which is how I implement what I just described |
| 22:21.53 | Samot | So this is an isolated box. |
| 22:22.06 | lvlinux | isolated? what do you mean? |
| 22:22.29 | Samot | Or you're talking about a particular customer on that box that has a specific need. |
| 22:23.10 | lvlinux | yes, just a small single location with 40-50 phones. |
| 22:23.36 | Samot | OK |
| 22:23.52 | Samot | So you can have them all live in one file |
| 22:23.57 | lvlinux | yes |
| 22:24.03 | Samot | Or if they are going to be adding/deleting these on the fly and a lot |
| 22:24.21 | Samot | You can use the #include trick and put a peer in its own file |
| 22:24.39 | lvlinux | hmm now that's a thought. |
| 22:24.40 | Samot | So that's the only file you are updating when they are updating/adding/removing that user/device. |
| 22:24.47 | Samot | As I said before |
| 22:24.56 | Samot | I keep my clients in their own files. |
| 22:25.02 | Samot | So they can be updated like that |
| 22:25.08 | Samot | Without breaking the other clients. |
| 22:25.13 | lvlinux | oh, you meant one client per file----i see. |
| 22:25.19 | Samot | Well |
| 22:25.29 | Samot | A client could have 3 or 20 devices |
| 22:25.32 | Samot | Queues |
| 22:25.34 | Samot | IVRs |
| 22:25.36 | Samot | Etc. |
| 22:25.49 | Samot | But more so... |
| 22:25.58 | Samot | I don't register my devices to Asterisk. |
| 22:26.27 | lvlinux | Kamailio? |
| 22:26.32 | Samot | Yup. |
| 22:26.46 | Samot | It's how I can have 3 people with extension 100 |
| 22:27.12 | Samot | Because they still need a peer on the system for certain things to work. |
| 22:27.20 | MrTAP | Samot: or switch to pjsip :) |
| 22:27.22 | Samot | But the peer doesn't matter at that level. |
| 22:27.27 | Samot | For that? |
| 22:27.28 | Samot | Why? |
| 22:27.31 | Samot | I don't need to. |
| 22:27.33 | MrTAP | But I also run Kamailio when I want multiple AORs on a single SIP peer |
| 22:27.45 | Samot | It's not about multiple AORs. |
| 22:28.03 | Samot | It's about more control. |
| 22:28.06 | file | it's multiple contacts on a single AOR, to be pedantic |
| 22:28.14 | Samot | Sorry |
| 22:28.16 | MrTAP | granted |
| 22:28.17 | Samot | You're correct. |
| 22:28.33 | Samot | I don't have people that want multiple CONTACTS on an AOR |
| 22:28.37 | Samot | ^^^ SEE FILE |
| 22:28.53 | Samot | It's a very rare request. |
| 22:29.29 | Samot | But things like Speed Dial.. |
| 22:29.33 | Samot | Asterisk is global. |
| 22:29.38 | Samot | For the most part. |
| 22:29.44 | Samot | It's a pain to deal with. |
| 22:30.15 | Samot | Now a company can have "Company Speed Dials" and "User" speed dials. |
| 22:30.22 | Samot | Blacklist, PIN codes. |
| 22:30.30 | Samot | Digit manipulation.. |
| 22:30.37 | Samot | Better handling of failures. |
| 22:30.38 | MrTAP | Ehh I don't have that issue. Contexts keep things nice and segregated for my uses. And pickupgroup, spygroup, etc are very useful for that. |
| 22:30.58 | Samot | Yeah.. |
| 22:31.07 | Samot | But I can handle a 408 timeout two different ways |
| 22:31.14 | Samot | Based on the type of timeout it is |
| 22:32.06 | Samot | I can handle actual SIP responses without Asterisk shoving for different response codes into one HANGUPCAUSE |
| 22:32.16 | Samot | *four |
| 22:32.30 | MrTAP | Yep, that's certainly a mild PITA to overcome |
| 22:32.56 | Samot | Plus.. |
| 22:33.09 | Samot | That's where all the digit manipulation is done for dialing for the most part. |
| 22:33.27 | Samot | So when it hits Asterisk, it's the final set of digits. |
| 22:33.56 | lvlinux | Does ARI allow adding/deleting/modifying endpoints? |
| 22:33.57 | Samot | They send 10 for an outbound call.. |
| 22:34.03 | Samot | It's 11 when it hits Asterisk for the media. |
| 22:34.17 | Samot | They send 7 it hits with the 1+Area Code already prepended |
| 22:34.34 | MrTAP | Ah see I do all that manipulation within Asterisk itself with the help of func_odbc, but that's all preference. Either way would be equally as effective |
| 22:34.43 | Samot | Well. |
| 22:34.47 | Samot | It takes load off Asterisk. |
| 22:34.52 | MrTAP | Yep it does |
| 22:34.54 | file | PJSIP has push configuration stuff in ARI. |
| 22:35.00 | file | or rather, the data layer does |
| 22:35.01 | MrTAP | I use Kam to load balance and failover, but let Asterisk do all the hard work |
| 22:35.06 | Samot | Allowing Asterisk to do more call stuff. |
| 22:35.23 | lvlinux | So mostly you are using Asterisk as a media server sounds like. |
| 22:35.35 | Samot | As a voice server. |
| 22:35.36 | Samot | Yes. |
| 22:35.46 | lvlinux | yeah voice server would be more accurate. |
| 22:35.49 | Samot | I have ones for "media applications" |
| 22:35.58 | Samot | VoiceMail, Outbound dialers... |
| 22:36.10 | Samot | I have three set up for PBX |
| 22:36.27 | Samot | In a Multi-tenant format |
| 22:36.59 | Samot | Hence Kamailio doing a lot of the user side stuff |
| 22:37.48 | Samot | If they are just using SIP Trunks or basic service..they sit on Kamailio |
| 22:37.59 | Samot | And they use the a "media gateway" when calls happen. |
| 22:38.08 | Samot | So I can control the media between me and the PSTN |
| 22:38.10 | Samot | and them. |
| 22:38.24 | file | oh neat, a call queue with callback that called me back... only to put me on hold... instead of to an agent... such fun |
| 22:39.20 | Samot | The less "extra" stuff Asterisk does.. |
| 22:39.29 | Samot | The more "call" stuff Asterisk does. |
| 22:39.49 | Samot | Allowing me to get more out of Asterisk for call capacity and processing |
| 22:39.57 | lvlinux | file: how useful lol |
| 22:40.06 | MrTAP | file: they appreciate your patience but not at the expense of theirs :) |
| 22:40.19 | file | it's a bank, so one should not be surprised |
| 22:54.54 | *** join/#asterisk startledmarmot (~startledm@2605:e000:845c:0:94b4:a027:9221:e456) |
| 22:59.02 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 23:05.10 | *** join/#asterisk billxx (49958984@gateway/web/freenode/ip.73.149.137.132) |
| 23:08.30 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 23:13.39 | *** join/#asterisk karelk (~karel@31.10.131.59) |
| 23:24.45 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 23:25.09 | *** part/#asterisk kharwell (kharwell@nat/digium/x-htryzrbtlqpmuxor) |
| 23:25.28 | *** join/#asterisk startledmarmot (~startledm@107.14.57.128) |
| 23:30.40 | *** join/#asterisk startledmarmot (~startledm@cpe-23-242-200-251.socal.res.rr.com) |
| 23:39.36 | *** join/#asterisk kilopo (3eaa7498@gateway/web/freenode/ip.62.170.116.152) |
| 23:39.43 | kilopo | Hi at all |
| 23:40.36 | kilopo | I'm a newbie in VoIP and Asterisk, I'm study for an open source pbx based on asterisk like FreePBX |
| 23:41.35 | kilopo | I've probably a stupid question... Why i can buy a SIP VoIP phone with more than one SIP account configurable? Need for what? |
| 23:41.36 | [TK]D-Fender | FreePBX is normally just an ADD-ON GUI for configuring * |
| 23:41.52 | [TK]D-Fender | Though they do also have an ISO that lets you deply a full setup easily |
| 23:42.19 | [TK]D-Fender | <kilopo> I've probably a stupid question... Why i can buy a SIP VoIP phone with more than one SIP account configurable? Need for what? <- why can you buy one like that? |
| 23:42.50 | [TK]D-Fender | Maybe you need your phone to register to multiple servers. Or have multiple identities (like a receptionist answering for multiple companies), etc |
| 23:43.24 | kilopo | Hi Fender, just because i've saw in market more telephone with 2 SIP account |
| 23:43.28 | [TK]D-Fender | Maybe you're using the phone with a platform that supports SLA (Shared Line Appearances) |
| 23:43.40 | kilopo | ah ok! clear |
| 23:43.55 | [TK]D-Fender | there are a lot of very easy ideas sopmeone could have for doing this |
| 23:44.15 | kilopo | for example to register multiple extension?! |
| 23:45.33 | Samot | Right. |
| 23:45.42 | Samot | I could have my personal extension. |
| 23:45.50 | Samot | And have my "support" extension as well |
| 23:46.08 | [TK]D-Fender | [TK]D-Fender> Maybe you need your phone to register to multiple servers. Or have multiple identities (like a receptionist answering for multiple companies), etc <------ |
| 23:46.09 | Samot | It can make for easier call management on the phone. |
| 23:46.28 | Samot | Just like 1 SIP account can use all the line buttons on the phone. |
| 23:46.40 | Samot | "Call Waiting" just lights up those lines. |
| 23:46.49 | Samot | Instead of shoving it all on one. |
| 23:46.53 | [TK]D-Fender | Depends how the phone treats things |
| 23:47.04 | Samot | This day and age. |
| 23:47.06 | Samot | It is. |
| 23:47.18 | [TK]D-Fender | Polycom allows mutliple calls per line-key |
| 23:47.22 | Samot | Yes. |
| 23:47.33 | Samot | But it also allows for multiple line appearances. |
| 23:47.34 | [TK]D-Fender | so treating each as only 1 call is an option, not forced |
| 23:47.51 | kilopo | <Samot> "Call Waiting" just lights up those lines. <- mmm i'm not understand this example.. could you explain me? |
| 23:47.54 | Samot | How many calls a line key can take isn't the same as how many line key appearances the account to take. |
| 23:47.57 | [TK]D-Fender | Yup. Different phones say each button = 1 call, split them up however you like, but when you're out, you're out |
| 23:47.58 | Samot | OK |
| 23:48.04 | Samot | So you're on the phone... |
| 23:48.07 | [TK]D-Fender | Even a crappy IP 301 can support 10 calls. |
| 23:48.18 | Samot | If you only have Line 1 enabled... |
| 23:48.25 | Samot | The second call will blink the button. |
| 23:48.42 | [TK]D-Fender | or 2 regs @ 5-call each |
| 23:49.03 | Samot | So naturally you have to put the first call on hold.. |
| 23:49.19 | [TK]D-Fender | kilopo, So be aware of how each brand you consider actually treats its lines & buttons |
| 23:49.22 | Samot | But if you want to jump between them, you have to hold, press the button again, hold, press the button again |
| 23:49.27 | Samot | With two line appearances.. |
| 23:49.32 | Samot | Each call is on it's own line. |
| 23:50.03 | Samot | Phones will push new calls to the new open appearance for that SIP account on the phone. |
| 23:50.07 | Samot | If those all are in use.. |
| 23:50.14 | Samot | It will still doubling up on them. |
| 23:50.26 | Samot | So if you have 3 line appearances.. |
| 23:50.34 | Samot | And 4th call comes in.. |
| 23:50.46 | Samot | It will be on the 1st line. |
| 23:50.56 | Samot | So line 1 would have two calls on it |
| 23:51.04 | Samot | Line 2 and Line 3 would have 1 call each |
| 23:51.13 | Samot | But you have a total of five calls going. |
| 23:51.38 | Samot | How many are active or on hold will depend on the nature of the call. |
| 23:52.32 | *** join/#asterisk shymega (~shymega@torbaytechjam/shymega) |
| 23:52.44 | kilopo | ah ok! i suppose that i understand now: if i've 2 SIP account configurable, when 2 calls incoming, i can blink 2 different lines and i can push one line and call, push another line and automatically the first line go in hold... |
| 23:52.48 | kilopo | ...right? |
| 23:54.09 | [TK]D-Fender | That's one way of treating it |
| 23:55.11 | kilopo | yep fender, i understand that there are many method. It depend how you program... |
| 23:55.32 | kilopo | But this scenario for me is very interesting |
| 23:56.22 | kilopo | because I've a VoIP trunk with 2 line from my ISP |
| 23:57.11 | kilopo | I would like to use them "at the same time" you know |
| 23:57.42 | [TK]D-Fender | Remember that the phone "lines" have nothing to do with how many calls be on your server at a time |
| 23:57.44 | kilopo | so i need a phone with at least 2 SIP account right? |
| 23:57.55 | [TK]D-Fender | they just determine how your phone handles it's calls. |
| 23:58.02 | [TK]D-Fender | and no. |
| 23:58.25 | [TK]D-Fender | You can have 100 different providers each giving you a different phone # (DID) that people could call you on. |
| 23:58.33 | [TK]D-Fender | This doesn't say anything about the kind of phone you need |
| 23:58.33 | kilopo | <[TK]D-Fender> Remember that the phone "lines" have nothing to do with how many calls be on your server at a time <- ok... |
| 23:58.45 | [TK]D-Fender | that phone choice will determine how many calls you can be on total. |
| 23:59.00 | [TK]D-Fender | it doesn't matter than you have 100 providers each giving you a potential "line" |
| 23:59.32 | kilopo | but if i have two incoming calls, and i had configure just one extension, for example "101" |
| 23:59.38 | [TK]D-Fender | You could do that |
| 23:59.46 | [TK]D-Fender | and then be able to swp between 2. |