| 00:02.41 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 00:19.56 | *** join/#asterisk infobot (ibot@rikers.org) |
| 00:19.56 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.15.0 (2017/04/07), 11.25.1 (2016/12/08), Standard: 14.4.0 (2017/04/07); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
| 00:56.32 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 01:00.04 | *** join/#asterisk drathir (~kamiljk8@unaffiliated/drathir) |
| 01:22.52 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 02:20.17 | *** join/#asterisk genpaku (~genpaku@107.191.100.185) |
| 03:08.41 | *** join/#asterisk cryptic (~cryptic@67-8-35-31.res.bhn.net) |
| 04:40.26 | *** join/#asterisk vstemen (~vince@ip68-227-96-101.ok.ok.cox.net) |
| 05:41.12 | *** join/#asterisk UncleKiwi (~UncleKiwi@unaffiliated/unclekiwi) |
| 05:42.15 | UncleKiwi | hi there I am attempting to do a xfer using *2 after recieving a call that was dialed with t |
| 05:42.26 | *** join/#asterisk jetlag (~jetlag@c-71-226-222-56.hsd1.nj.comcast.net) |
| 05:42.37 | UncleKiwi | but Asterisk does not seem to recieve the *2 |
| 05:42.41 | UncleKiwi | or # |
| 05:50.22 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:54.32 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 05:59.26 | UncleKiwi | solved |
| 06:04.52 | *** join/#asterisk vince1 (~vince@ip68-227-96-101.ok.ok.cox.net) |
| 06:23.17 | *** join/#asterisk detha (~detha@unaffiliated/detha) |
| 06:43.05 | *** join/#asterisk DanB (~DanB@clt-195.192.207.163.ip-anschluss.net) |
| 06:49.22 | *** join/#asterisk jkroon (~jkroon@165.16.204.37) |
| 07:03.47 | *** join/#asterisk jetlag (~jetlag@c-71-226-222-56.hsd1.nj.comcast.net) |
| 07:08.45 | *** join/#asterisk evilman_work (~evilman@87.244.6.228) |
| 07:17.38 | *** join/#asterisk hehol (~hehol@130.180.55.250) |
| 07:19.08 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
| 07:25.25 | *** join/#asterisk pchero_work (~pchero@109.70.54.56) |
| 07:52.52 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
| 08:10.05 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 08:14.31 | *** join/#asterisk Haris (~haris@unaffiliated/haris) |
| 08:14.32 | Haris | hello all |
| 08:14.53 | Haris | I asked last time. but forgot. what's the hangupcause 34 for on https://www.voip-info.org/wiki/view/Asterisk+variable+hangupcause ? |
| 08:15.06 | Haris | is this normal or abnormal behaviour from telco end ? |
| 08:19.56 | *** join/#asterisk Eloy_ (~Eloy@5.149.168.66) |
| 08:22.13 | [sID] | 503 (Service Unavailable) |
| 08:24.41 | Haris | can this be attributed to TELCO end sip proxy issue ? |
| 08:24.55 | Haris | -- Executing [s@macro-dialout-trunk:24] NoOp("SIP/2006-0000023e", "Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 34") in new stack |
| 08:25.37 | Haris | pasting 4 lines of log ? |
| 08:26.09 | Haris | pasting more on pastebin |
| 08:26.39 | Haris | https://pastebin.ca/3813291 |
| 08:27.36 | Haris | this usually happens when the remote sip proxy is being restarted after a config change or if this was asteris, then when config is being reloaded on asterisk, right ? |
| 08:28.13 | *** join/#asterisk Chainsaw (~chainsaw@gentoo/developer/chainsaw) |
| 08:32.36 | Samot | -- Called SIP/TeleCard/03310421229 |
| 08:32.36 | Samot | <PROTECTED> |
| 08:32.36 | Samot | <PROTECTED> |
| 08:32.42 | Samot | That's pretty clear. |
| 08:35.49 | *** join/#asterisk sh0ne (~sh0ne@77.105.41.173) |
| 08:49.18 | [sID] | Haris: This means that you have service unavailable. |
| 09:06.29 | *** join/#asterisk TSM (259d25e2@gateway/web/freenode/ip.37.157.37.226) |
| 09:09.16 | Haris | that's not my Q |
| 09:09.22 | Haris | My Q was, what could be causing it ? |
| 09:09.50 | Haris | could it be asterisk reload of config or an intermediate proxy going down for a reload of config or something alike or none of these ? |
| 09:10.00 | Samot | The carrier is causing it. |
| 09:10.02 | Samot | You should talk to them. |
| 09:10.05 | Haris | ok |
| 09:10.15 | Haris | they are killing me |
| 09:13.05 | UncleKiwi | Hi Samot |
| 09:14.54 | UncleKiwi | when caller-A calls to Asterisk over FXO and then Asterisk Dials SIP/sip-provider/0123213123,20mt |
| 09:15.49 | UncleKiwi | at this point the person recieving the call at 0123213123 should be able to push # and do a transfer |
| 09:16.16 | UncleKiwi | I seem to be able to an exten and play tt-weasles |
| 09:16.23 | UncleKiwi | but not dial a sip extention |
| 09:16.40 | UncleKiwi | that calls a sip peer |
| 09:16.58 | Samot | Right. |
| 09:17.13 | Samot | Because you don't allow them the right to use transfer. |
| 09:17.14 | UncleKiwi | when i try it says Called SIP/1003\ |
| 09:17.49 | UncleKiwi | how do you mean |
| 09:17.51 | UncleKiwi | ? |
| 09:17.55 | UncleKiwi | how do i do that |
| 09:18.03 | UncleKiwi | i have set this up in the past and it worked a charm |
| 09:18.31 | Samot | SIP/sip-provider/0123213123,20mt <-- right there. |
| 09:18.39 | Samot | m = music on hold to play until call is answered |
| 09:18.45 | UncleKiwi | yes |
| 09:18.50 | UncleKiwi | and then the t |
| 09:19.06 | UncleKiwi | the t allows the number that is called to initiate the xfer |
| 09:19.09 | Samot | Yeah, t is for the called party |
| 09:19.12 | Samot | I was mixing those up. |
| 09:19.14 | Samot | Not T |
| 09:19.14 | UncleKiwi | exacto |
| 09:19.17 | Samot | OK |
| 09:19.29 | UncleKiwi | thats what i want |
| 09:19.30 | Samot | So do you have the # setup in features.conf? |
| 09:19.35 | UncleKiwi | but it wont work |
| 09:19.40 | UncleKiwi | yes |
| 09:19.43 | UncleKiwi | i dot |
| 09:19.45 | UncleKiwi | i do |
| 09:20.10 | Samot | So show a call this happens on.. |
| 09:20.16 | Samot | The transfer not working. |
| 09:20.30 | UncleKiwi | how do i show you |
| 09:20.35 | Samot | ~pb |
| 09:20.35 | infobot | [pastebin] 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. |
| 09:21.17 | UncleKiwi | so just ser verbose to high and send you the console output |
| 09:23.49 | Samot | Yes |
| 09:27.30 | Rac-on | isnt that pretty much the answer to all questions in this channel? |
| 09:28.53 | UncleKiwi | https://pastebin.com/7nHAZyvJ |
| 09:29.20 | Samot | Rac-on: You mean, "Show us a debug?" |
| 09:29.51 | Rac-on | Samot: yes, crank up verbose, capture console output, put it in a pastebin |
| 09:29.55 | Samot | -- Blind transferring SIP/pstn2-0000001a to '803' (context default) priority 1 |
| 09:29.57 | Samot | ^^^ |
| 09:30.00 | Samot | That's why |
| 09:30.06 | Samot | The transfer is happening.. |
| 09:30.34 | UncleKiwi | wow that was fast |
| 09:30.41 | UncleKiwi | please explain |
| 09:30.46 | Samot | <PROTECTED> |
| 09:30.46 | Samot | <PROTECTED> |
| 09:30.46 | Samot | <PROTECTED> |
| 09:30.51 | Samot | That's all I can tell you |
| 09:31.00 | Samot | You decided not to show the entire call |
| 09:31.22 | Samot | == Spawn extension (default, 803, 2) exited non-zero on 'SIP/pstn2-0000001a' |
| 09:31.26 | UncleKiwi | that was all there was |
| 09:31.40 | Samot | ^^^ it exited at priority 2 in the context on that extension. |
| 09:32.21 | Samot | Rac-on: Yeah, it's crazy to want to see debugs of issues so you know exactly what is going on. |
| 09:32.24 | UncleKiwi | why did it exit |
| 09:32.28 | Samot | I don't know. |
| 09:32.45 | Samot | Look at your default context at priority 2 of the 803 extension. |
| 09:32.54 | Rac-on | Samot: we should put it up as a welcome message for first-joiners, would save a lot of time ; |
| 09:33.55 | UncleKiwi | were you picked on at school Rac-on ? |
| 09:34.49 | Rac-on | cuddles UncleKiwi. |
| 09:34.58 | UncleKiwi | ahaha |
| 09:38.06 | UncleKiwi | same => n,Dial(SIP/rena,90) |
| 09:38.23 | UncleKiwi | that would be priority 2 |
| 09:39.19 | Samot | What is priority 1? |
| 09:40.07 | UncleKiwi | exten => _803!,1,Set(CDR(newdate)=${STRFTIME(${EPOCH},,%d/%m/%y %H:%M:%Si)}) |
| 09:40.24 | UncleKiwi | its some stuff i need for call logging |
| 09:41.09 | Samot | _803! <-- Why do you need that? |
| 09:41.15 | Samot | Isn't the extension being dialed 803? |
| 09:41.25 | UncleKiwi | yes |
| 09:41.37 | Samot | OK |
| 09:41.41 | UncleKiwi | is the ! a problem |
| 09:41.42 | Samot | so is the 803 device registered? |
| 09:41.49 | UncleKiwi | yes its is registered |
| 09:41.56 | Samot | I don't know why you need to have a pattern match for it. |
| 09:41.58 | UncleKiwi | it rings |
| 09:41.59 | Samot | That's all. |
| 09:42.00 | Rac-on | is the 'rena' peer registered? |
| 09:42.02 | UncleKiwi | it workings |
| 09:42.08 | UncleKiwi | works |
| 09:42.11 | UncleKiwi | yes |
| 09:42.14 | Samot | So what is the actual issue? |
| 09:42.24 | Samot | You said the transfer wasn't working. |
| 09:42.25 | Samot | It is. |
| 09:42.29 | Samot | So what is the issue? |
| 09:42.50 | UncleKiwi | for this blind transfer procedure it will not ring |
| 09:43.12 | UncleKiwi | as the recipient of the caller-A |
| 09:43.24 | UncleKiwi | given in the example |
| 09:43.26 | Samot | -- Called SIP/rena |
| 09:43.28 | Rac-on | a sip debug or tcpdump might help. it fails when calling the rena peer |
| 09:43.30 | Samot | ^^^ So when it does that |
| 09:43.34 | Samot | The phone doesn't ring? |
| 09:43.53 | Samot | Yeah, need a SIP debug |
| 09:44.06 | UncleKiwi | when i try blind transfer to it in the given example |
| 09:44.15 | UncleKiwi | but if ia call it internally it will work |
| 09:56.58 | drmessano | Show us the body |
| 09:57.26 | drmessano | No Corpse, no autopsy |
| 09:57.41 | Samot | 5:43:52 AMÂ <Samot>Â Yeah, need a SIP debug |
| 10:00.29 | *** join/#asterisk sekil (~sekil@109-93-199-144.static.isp.telekom.rs) |
| 10:00.53 | UncleKiwi | i tired and feeling defeated |
| 10:01.05 | UncleKiwi | maybe i should leave it until tomorrow |
| 10:01.07 | Samot | Tried what? |
| 10:01.11 | Samot | What did you try? |
| 10:01.33 | UncleKiwi | sorry im tired |
| 10:01.38 | UncleKiwi | not tried |
| 10:01.39 | UncleKiwi | ahaha |
| 10:02.13 | Samot | I got up at like 4:30am |
| 10:02.18 | UncleKiwi | wow |
| 10:02.38 | UncleKiwi | yeah i have been working like 17 hours days |
| 10:03.00 | UncleKiwi | probably should take a break |
| 10:03.12 | Samot | Well you pinged me at like 5am |
| 10:03.13 | Samot | for this |
| 10:03.23 | UncleKiwi | wow sorry |
| 10:03.30 | UncleKiwi | ok i'll make an effort |
| 10:03.35 | Samot | So now I'm telling you I need a SIP debug. |
| 10:03.36 | Samot | Yeah |
| 10:03.40 | UncleKiwi | its like 10am here |
| 10:03.45 | UncleKiwi | `0pm here |
| 10:03.46 | Samot | Don't ping someone personally and then go "Yeah, I can't do this" |
| 10:03.48 | UncleKiwi | 10 |
| 10:04.00 | Samot | SIP debug |
| 10:04.06 | UncleKiwi | Samot you were talking with others so you were awake already |
| 10:04.06 | Samot | Make the transfer attempt |
| 10:04.42 | UncleKiwi | sure |
| 10:16.40 | Samot | Come on. |
| 10:16.46 | Samot | This takes like 5 minutes. |
| 10:18.00 | UncleKiwi | i think i need to leave it there is too many public ip's and stuff in the debugs |
| 10:18.08 | UncleKiwi | i can see SIP/2.0 400 Bad Request |
| 10:18.16 | Samot | Then forget it. |
| 10:18.22 | Samot | You pinged me. |
| 10:18.29 | Samot | And I've had to fight to get this stuff. |
| 10:18.37 | Samot | So yeah, figure it out. |
| 10:18.45 | UncleKiwi | cheers |
| 10:34.40 | *** join/#asterisk sekil (~sekil@109-93-199-144.static.isp.telekom.rs) |
| 10:38.39 | *** join/#asterisk sekil (~sekil@109-93-199-144.static.isp.telekom.rs) |
| 10:38.48 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:1f0:56cd:f053:b6da) |
| 11:03.03 | *** join/#asterisk genpaku (~genpaku@107.191.100.185) |
| 11:20.41 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 11:25.39 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
| 11:39.41 | *** join/#asterisk Rini (uid196547@gateway/web/irccloud.com/x-jouzffrsuoafyvbv) |
| 11:45.56 | *** join/#asterisk scgm11_ (~scgm11@r186-50-185-64.dialup.adsl.anteldata.net.uy) |
| 12:00.17 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 12:20.10 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 12:31.04 | *** join/#asterisk scgm11_ (~scgm11@r186-50-185-64.dialup.adsl.anteldata.net.uy) |
| 12:54.08 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 12:57.37 | *** join/#asterisk mahlon (~mahlon@martini.nu) |
| 13:12.52 | *** join/#asterisk tuxian (~tuxian@194.12.3.78) |
| 13:17.09 | *** join/#asterisk scgm11_ (~scgm11@r186-50-185-64.dialup.adsl.anteldata.net.uy) |
| 13:24.18 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 13:25.28 | *** join/#asterisk scgm11_ (~scgm11@r186-49-44-133.dialup.adsl.anteldata.net.uy) |
| 13:35.44 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 13:43.32 | *** join/#asterisk smkelly (~smkelly@mykonos.smkelly.org) |
| 13:44.49 | *** join/#asterisk overyander (~jeff@12.49.160.131) |
| 13:51.06 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 13:53.04 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 13:54.43 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-dykiozqnpqmrdowt) |
| 13:54.43 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 14:07.13 | *** join/#asterisk u0m3 (~u0m3@86.120.97.11) |
| 14:12.53 | *** join/#asterisk newtonr (~newtonr@173-21-147-197.client.mchsi.com) |
| 14:12.53 | *** mode/#asterisk [+o newtonr] by ChanServ |
| 14:18.11 | *** join/#asterisk kharwell (kharwell@nat/digium/x-sswsoyhzezwhbaiv) |
| 14:18.11 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:30.55 | *** join/#asterisk scgm11_ (~scgm11@r186-52-149-239.dialup.adsl.anteldata.net.uy) |
| 14:36.26 | *** join/#asterisk twanny796 (~user@62.173.4.85) |
| 14:36.39 | *** join/#asterisk StucKman (~mdione@195.200.189.206) |
| 14:36.47 | twanny796 | please remind how to restrict an extesion to call internal only? |
| 14:36.58 | twanny796 | from the freepbx webgui? |
| 14:37.09 | StucKman | is there any way to correlate the 4 channels of a call that has this looks? |
| 14:37.30 | [TK]D-Fender | ~freepbx |
| 14:37.30 | 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:37.33 | [TK]D-Fender | twanny796, ^^^ |
| 14:37.38 | StucKman | exten #1 -> SIP server -> trunk -> SIP server -> exten #2 |
| 14:37.42 | StucKman | in the logs, I mean |
| 14:38.03 | StucKman | I notice that all Call-IDs, tags, Tos, Contact, etc change |
| 14:38.25 | [TK]D-Fender | call ID on the call between your servers should map |
| 14:38.48 | twanny796 | [TK]D-Fender: ok, long time since we spoke! |
| 14:39.02 | twanny796 | bye |
| 14:39.34 | StucKman | [TK]D-Fender: I see 4 invites in the log and all have different Call-ID headers |
| 14:40.27 | StucKman | I'm calling from one extensio to one external number wich ends up in another extension |
| 14:40.28 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 14:43.33 | [TK]D-Fender | those are 3 separate calls |
| 14:43.42 | [TK]D-Fender | the INNER set should match |
| 14:43.52 | [TK]D-Fender | because the invite between your server is wha it is |
| 14:43.57 | [TK]D-Fender | those callid's match |
| 14:52.24 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 14:52.34 | StucKman | http://linkode.org/kzLlLpCm9uejZ4R1T8pcz7 |
| 14:52.55 | StucKman | those are the 4 invites |
| 14:53.31 | StucKman | now, there is some terminologie I don't know, so I'm not sure this should be explained |
| 14:54.02 | StucKman | treu, we're using a third party solution, but I'm not sure if this is due to that solution or to how A* works |
| 14:55.19 | [TK]D-Fender | INVITE sip:XXXXXXXX@trunk.phoneprovider.com:5060 SIP/2.0 |
| 14:55.37 | [TK]D-Fender | if you;'re going through an ITSP then you're dead in the water most likely |
| 14:55.42 | StucKman | the second invite, yes |
| 14:55.45 | [TK]D-Fender | your description did NOT mention that |
| 14:55.49 | StucKman | ITSP? |
| 14:55.54 | [TK]D-Fender | Then you have no end -to-end |
| 14:55.58 | StucKman | I have no idea what are those |
| 14:56.00 | [TK]D-Fender | they are in the middle along with the PSTN |
| 14:56.03 | igcewieling | StucKman: expect at least 2 invites. The first will be rejected. |
| 14:56.09 | igcewieling | ~itsp |
| 14:56.09 | infobot | [~itsp] An ITSP is an Internet Telephony Service Provider (or VoIP telephone company). They allow you to either SEND calls to the PSTN (this is called termination), RECEIVE calls from the PSTN (called origination), or both. Some offer fixed rates, others $/min. Enter ~itsplist-us (USA) or ~itsplist-ca (Canada) for a listing of popular ITSPs. |
| 14:56.13 | [TK]D-Fender | PHONE PROVIDER |
| 14:56.17 | igcewieling | StucKman: sounds like you need to read the Asterisk book. |
| 14:56.28 | StucKman | ugh |
| 14:57.03 | StucKman | ok, but at least it's ok that there are two invites before I reach the ITSP? |
| 14:57.25 | StucKman | I would say my SIP server is NAT'ing the calls *I have networking background) |
| 14:58.18 | [TK]D-Fender | StucKman> I would say my SIP server is NAT'ing the calls *I have networking background) <- doesn't say anything |
| 14:58.42 | [TK]D-Fender | <StucKman> ok, but at least it's ok that there are two invites before I reach the ITSP? <- do you see the calls? |
| 14:58.52 | [TK]D-Fender | phone calls * = 1 invite |
| 14:59.01 | [TK]D-Fender | * calls provider = 1 invite |
| 14:59.13 | [TK]D-Fender | Provider goes through pstn to othe provider |
| 14:59.24 | [TK]D-Fender | other provider calls * #2 = 1 invite |
| 14:59.28 | igcewieling | [TK]D-Fender: what about the initial rejected invite which includes a nonce? |
| 14:59.36 | StucKman | well, I'm calling a number in the same system |
| 14:59.37 | [TK]D-Fender | * 2 calls other local SIP peer = 1 invite |
| 14:59.39 | StucKman | let me explain |
| 14:59.51 | StucKman | i have my internal number anda external one |
| 14:59.51 | [TK]D-Fender | you have a provider in the middle |
| 15:00.01 | *** part/#asterisk igcewieling (~ewieling@speedy-02.nyigc.net) |
| 15:00.05 | StucKman | I'm calling another external number that's tied to a nother internal one |
| 15:00.08 | [TK]D-Fender | <StucKman> i have my internal number anda external one <- "number" doesn't mean anything |
| 15:00.11 | [TK]D-Fender | WHERE you send it does |
| 15:00.12 | StucKman | not sure I'm clear :( |
| 15:00.51 | [TK]D-Fender | WHERE are you sending the call? if you are calling a PHONE PROVIDER and calling out to a real-world numebr then you are done. You have no call ID to trace |
| 15:01.03 | [TK]D-Fender | They are in the middle and that information is lost |
| 15:01.09 | StucKman | so the traffic goes first to my SIP server, then to the ITSP, which comes back to my SIP server and finally the destination |
| 15:01.42 | StucKman | [TK]D-Fender: but I'm also loosing info between the invites received and sent from my SIP server |
| 15:02.05 | StucKman | both to the ITSP and to the final extension |
| 15:02.06 | [TK]D-Fender | huh? |
| 15:02.23 | StucKman | and I'm not even sure itÅ what A* normally does or this solution is just crazy |
| 15:02.36 | [TK]D-Fender | How do you LOSE this? |
| 15:02.39 | [TK]D-Fender | You call your provider |
| 15:02.43 | [TK]D-Fender | that is a SIP call |
| 15:02.46 | [TK]D-Fender | the packets HAPPEN |
| 15:02.50 | StucKman | yes |
| 15:02.52 | [TK]D-Fender | What is there to LOSE? |
| 15:02.58 | StucKman | info |
| 15:03.02 | [TK]D-Fender | Your description is getting WORSE |
| 15:03.07 | StucKman | yes, I know, sorry |
| 15:03.20 | StucKman | In my head is more or less clear |
| 15:03.30 | [TK]D-Fender | Go get a coffee and collect your thoughts |
| 15:03.36 | [TK]D-Fender | because this is heading downhill.... |
| 15:03.44 | StucKman | ok, step back |
| 15:03.50 | StucKman | did you see the 4 invites? |
| 15:04.09 | StucKman | hmm, I can add some info |
| 15:06.24 | StucKman | I'm making a mess by masking everything |
| 15:06.42 | StucKman | is it OK to put the invites as they are, with IPs and all? |
| 15:09.00 | [TK]D-Fender | yes |
| 15:09.10 | [TK]D-Fender | set an expiry of 5 mins on it or whatever |
| 15:10.17 | StucKman | https://paste.debian.net/932726/ |
| 15:11.44 | StucKman | first invite is from client#1 to SIP server, 2nd from SIP server to ITSP, 3rd from ITSP back to my SIP server, because the number corresponds back to me, and 4th goes to client #2 |
| 15:11.48 | StucKman | do I make sense now? |
| 15:12.00 | [TK]D-Fender | You're going through a provider |
| 15:12.10 | StucKman | yes, |
| 15:12.15 | [TK]D-Fender | you are not directly calling the other serve |
| 15:12.25 | [TK]D-Fender | you are nOT going to see the same ID's on both ends |
| 15:12.30 | [TK]D-Fender | that is GONE |
| 15:12.31 | StucKman | that I have no idea what that means |
| 15:12.37 | StucKman | ok |
| 15:13.04 | [TK]D-Fender | <PROTECTED> |
| 15:13.11 | [TK]D-Fender | What is your probelm understnading this? |
| 15:13.23 | [TK]D-Fender | there is NO link between the two at that point |
| 15:13.32 | [TK]D-Fender | the packet doesn't go from server A to server B. |
| 15:13.39 | [TK]D-Fender | those are 2 1000000% separate things |
| 15:13.46 | StucKman | but is it normal that I also lose correlation between the 1st and 2nd INVITEs on one hand, and 3rd and 4th on the other? |
| 15:13.56 | [TK]D-Fender | huh? |
| 15:14.09 | [TK]D-Fender | EVERY call on * is a SEPARATE call |
| 15:14.15 | [TK]D-Fender | ~b2bua |
| 15:14.16 | infobot | [b2bua] a Back 2 Back User Agent. Additional information is available on wikipedia: http://en.wikipedia.org/wiki/Back-to-back_user_agent |
| 15:14.17 | [TK]D-Fender | ^ |
| 15:14.20 | [TK]D-Fender | it is NOT a proxy |
| 15:14.24 | StucKman | so I basically have 4 calls there? |
| 15:14.36 | [TK]D-Fender | your CDR can track that a channel was BRIDGED but that does NOT carry in the packets |
| 15:14.53 | StucKman | my problem is not the packets |
| 15:14.57 | StucKman | the call works fine |
| 15:15.02 | [TK]D-Fender | So you can track that those 2 calls on the first side were bridged.... |
| 15:15.07 | StucKman | I'm just trying to make sense of the logs |
| 15:15.14 | StucKman | yes, how? |
| 15:15.18 | [TK]D-Fender | but you're not going to tie the REMOTE end to this |
| 15:15.32 | StucKman | that I kinda can live without |
| 15:15.41 | [TK]D-Fender | CEL, Bridge channel variables. |
| 15:15.44 | [TK]D-Fender | etc |
| 15:15.55 | [TK]D-Fender | LOOK at a call while bridged |
| 15:16.09 | StucKman | does that appear in the full logs? |
| 15:16.13 | [TK]D-Fender | you can run macros before that happens as well to record them somewhere |
| 15:16.22 | [TK]D-Fender | You see what's in the logs |
| 15:16.25 | [TK]D-Fender | you shouldn't be asking |
| 15:16.44 | [TK]D-Fender | X answered Y <- that shows CHANNELS answering, but not SIP ID's |
| 15:16.50 | StucKman | well, I'm asing becasuse I don't know |
| 15:16.54 | [TK]D-Fender | You'd clearly have to parse a TON of shit to do it that way |
| 15:17.00 | [TK]D-Fender | so depends what you are trying to track |
| 15:17.01 | StucKman | yeap |
| 15:18.28 | StucKman | ok, let's back a little |
| 15:18.45 | StucKman | what is this called? C-000711b0 |
| 15:19.03 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:1f0:56cd:f053:b6da) |
| 15:19.05 | Samot | Channel ID |
| 15:19.07 | [TK]D-Fender | right now it's a bunch of letters |
| 15:19.10 | StucKman | ok |
| 15:19.12 | Samot | wiki.asterisk.org |
| 15:19.30 | [TK]D-Fender | because you pasted a useless little chunk with nothing providing context |
| 15:19.33 | StucKman | so I got this two channels, from client#1 to SIP and from SIP to ITSP |
| 15:19.40 | Samot | Right. |
| 15:19.54 | StucKman | a) when are the channels bridged? |
| 15:19.55 | Samot | Phone -> PBX and PBX -> Provider |
| 15:20.04 | Samot | When the call is answered. |
| 15:20.08 | [TK]D-Fender | <StucKman> a) when are the channels bridged? <- when it ANSWERS |
| 15:20.16 | StucKman | and b) what does suck thing look like in the logs? |
| 15:20.36 | [TK]D-Fender | <[TK]D-Fender> X answered Y <- that shows CHANNELS answering, but not SIP ID's |
| 15:20.40 | StucKman | [TK]D-Fender: don't be pedantic, please |
| 15:20.52 | Samot | What are you trying to get again? |
| 15:21.05 | StucKman | trying to follow a full call in the full logs |
| 15:21.28 | Samot | First, you can't. |
| 15:21.37 | Samot | You will see how Asterisk handles the call.. |
| 15:21.46 | Samot | You'll see the call flow through the dialplan |
| 15:21.48 | StucKman | yes, I will see only my side, I know |
| 15:22.13 | Samot | Asterisk doesn't log it ALL |
| 15:22.19 | StucKman | put that way, I have two full calls in those 4 INVITEs |
| 15:22.21 | Samot | So again, no you can't. |
| 15:22.32 | StucKman | well, it logs a lot |
| 15:22.36 | Samot | You would need to run debugs to see this type of information. |
| 15:22.39 | Samot | Yes. |
| 15:22.41 | StucKman | not only the dialplan, but the sip messages too |
| 15:22.46 | Samot | It logs what is happening to call in the dialplan |
| 15:22.51 | Samot | And some sip stuff |
| 15:22.55 | StucKman | yeap |
| 15:22.57 | Samot | But if you want to see all the dialog |
| 15:23.01 | Samot | and SIP messages.. |
| 15:23.03 | StucKman | but not bridging? |
| 15:23.08 | Samot | You need to have the sip debug enabled. |
| 15:23.10 | Samot | Yes. |
| 15:23.14 | Samot | It logs they are bridged. |
| 15:23.17 | [TK]D-Fender | <[TK]D-Fender> <[TK]D-Fender> X answered Y <- that shows CHANNELS answering, but not SIP ID's |
| 15:23.20 | Samot | Says so |
| 15:23.21 | [TK]D-Fender | 3 TIME NOWS |
| 15:23.29 | Samot | Asterisk is a SIP router |
| 15:23.31 | Samot | Or a proxy |
| 15:23.37 | [TK]D-Fender | NEITHER |
| 15:23.41 | [TK]D-Fender | ~b2bua |
| 15:23.41 | infobot | b2bua is probably a Back 2 Back User Agent. Additional information is available on wikipedia: http://en.wikipedia.org/wiki/Back-to-back_user_agent |
| 15:23.43 | Samot | er |
| 15:23.45 | [TK]D-Fender | ^ |
| 15:23.45 | StucKman | [TK]D-Fender: sorry, it was not making sense, let me check |
| 15:23.48 | Samot | isn't* |
| 15:23.54 | StucKman | no tmaking sense to me* |
| 15:24.15 | [TK]D-Fender | SIP/provider-12345 answered SIP/sometwit-67890 |
| 15:24.21 | [TK]D-Fender | ^^^^^ |
| 15:24.31 | [TK]D-Fender | It TELLS you 2 channels just bridged |
| 15:24.51 | StucKman | aha, and it's prefixed with one of the channels IDs |
| 15:25.00 | StucKman | cool, that helps a lot |
| 15:25.15 | Samot | [2017-05-16 11:24:54] VERBOSE[12433][C-0003ce48] bridge_channel.c: Channel SIP/sbc-cgw01-trunk-00057fc7 joined 'simple_bridge' basic-bridge <0c3082f0-d692-443c-83b1-753b7dc4abcf> |
| 15:25.15 | Samot | [2017-05-16 11:24:54] VERBOSE[12432][C-0003ce48] bridge_channel.c: Channel SIP/7007002038-00057fc6 joined 'simple_bridge' basic-bridge <0c3082f0-d692-443c-83b1-753b7dc4abcf> |
| 15:25.29 | Samot | It's pretty clear in the logs when channels gets bridged. |
| 15:25.53 | StucKman | cool! |
| 15:26.00 | Samot | Did you not look? |
| 15:26.08 | Samot | It would have been right there... |
| 15:27.13 | StucKman | Samot: I have 1600+ lines of logs just for this call, it's dense |
| 15:27.27 | StucKman | I have 7 pages printed |
| 15:27.58 | [TK]D-Fender | 1600 line from the INVITE out to the ANSWER? |
| 15:28.24 | Samot | That's impossible. |
| 15:28.27 | StucKman | 1600+ lines of painfully extracted lines from the full log |
| 15:29.13 | Samot | Then that means you are log a bunch of garbage |
| 15:29.19 | Samot | s/log/logging/ |
| 15:29.34 | [TK]D-Fender | or maybe a very busy server |
| 15:29.44 | Samot | 1600+ lines for one call? |
| 15:30.05 | Samot | That's a lot of dialplan for a single call from an endpoint to the ITSP trunk |
| 15:30.06 | StucKman | well, for two, really, the outgoing and the incoming |
| 15:30.25 | Samot | Phone -> PBX and PBX -> ITSP |
| 15:30.33 | Samot | Should not require 1600+ lines |
| 15:30.56 | Samot | That's "here are my digits, oh they match and dial this trunk peer" |
| 15:31.12 | StucKman | not here |
| 15:31.16 | StucKman | welcome to my life |
| 15:31.30 | StucKman | the dial plan is motly done by the third party |
| 15:31.50 | StucKman | and we have it hooked to our CRM |
| 15:31.52 | [TK]D-Fender | Dialplan doesn't matter |
| 15:31.58 | [TK]D-Fender | <[TK]D-Fender> 1600 line from the INVITE out to the ANSWER? |
| 15:32.20 | [TK]D-Fender | you only had to look from the DIAL issued till the ANSWER |
| 15:32.55 | *** join/#asterisk hdon (~hdon@68.110.137.138) |
| 15:33.29 | StucKman | I'm trying to automatize the extraction of the logs related to a call |
| 15:33.40 | StucKman | in totall should be like 700, 800 lines |
| 15:52.02 | *** join/#asterisk bof23 (~Thunderbi@185.13.183.107) |
| 15:55.36 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 16:00.53 | mub | if you have such an active asterisk server, you should have a small dummy server with redundant configuration that you can spin up for testing things like this |
| 16:01.23 | mub | imo it's terrible trying to debug asterisk issues on a server where everyone is placing calls |
| 16:02.21 | mub | s/debug/troubleshoot/ |
| 16:13.25 | *** join/#asterisk Kobaz (~kobaz@its.kobaz.net) |
| 16:13.35 | Kobaz | soooo, 35 active channels and 65% cpu |
| 16:13.38 | Kobaz | something's not quite right |
| 16:26.31 | Kobaz | do_monitor is the highest contender |
| 16:28.43 | *** join/#asterisk igcewieling (~ewieling@speedy-02.nyigc.net) |
| 16:47.04 | StucKman | ok, that was educating |
| 16:57.15 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 17:36.01 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 17:51.26 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 18:08.26 | *** join/#asterisk tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 18:09.08 | *** join/#asterisk malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:09.08 | *** mode/#asterisk [+o malcolmd] by ChanServ |
| 18:12.52 | *** join/#asterisk Janos (~Janos@190.171.120.15) |
| 18:14.40 | *** join/#asterisk sekil (~sekil@cable-89-216-223-60.dynamic.sbb.rs) |
| 18:16.11 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
| 18:39.00 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 18:41.49 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 18:59.53 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 19:02.19 | *** join/#asterisk Janos (~Janos@190.171.120.15) |
| 19:02.50 | Janos | hey there, got an interesting scenario I'm pretty sure it's possible but no idea how to handle |
| 19:05.16 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 19:05.20 | Janos | got two asterisk A and B sending calls to each other, behind those asterisks there are sip devices with 3 digit extensions like XXX, in order to overcome this extension clash prefixes are used so that when A sees a patter 3XXX it sends the call to be and B removes the 3 and sends the call to the correct device. B does the same for the 6XXX pattern |
| 19:07.04 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 19:08.59 | Janos | everything worked apparently, and a call from 240@B to 223@A works, but when 305@B tries to call 223@A it does not |
| 19:11.16 | *** join/#asterisk Oatmeal (~Suzeanne@c-68-45-30-44.hsd1.in.comcast.net) |
| 19:13.09 | *** join/#asterisk miralin (~Thunderbi@85.115.248.226) |
| 19:19.59 | *** join/#asterisk miralin (~Thunderbi@195.209.246.194) |
| 19:20.47 | Samot | Janos: So you dialed 6305? |
| 19:20.55 | Janos | correct |
| 19:21.03 | Janos | I have tracked down the issue and the problem presents itself when the device exists on both A and B |
| 19:21.06 | Samot | What do the logs show? |
| 19:21.25 | Janos | and seems to be related to peer selection |
| 19:21.26 | Samot | What do you mean it exists on A and B? |
| 19:21.37 | Samot | You have the same device registered on both systems? |
| 19:23.04 | Janos | no two different devices with the same name |
| 19:23.25 | Janos | this is the significant log line |
| 19:23.26 | *** join/#asterisk matt_ (~matt@ccpc-buzzer.bath.ac.uk) |
| 19:26.01 | Janos | the call that does work shows this |
| 19:26.02 | Janos | [May 16 12:02:27] VERBOSE[25444] chan_sip.c: Found peer 'dm-cac' for '240' from 100.10.35.2:5060 |
| 19:26.21 | Janos | and the one that does shows this |
| 19:26.23 | Janos | [May 16 11:57:43] VERBOSE[25444] chan_sip.c: Found peer '305' for '305' from 100.10.35.2:5060 |
| 19:27.01 | Janos | in the working scenario, the peer is correctly identified dm-cac |
| 19:27.09 | Janos | which is asterisk B |
| 19:27.29 | Janos | in the second scenario, the peer identified by asterisk A is 305 instead which is a phone |
| 19:28.02 | *** join/#asterisk matrix1233 (~matrix123@41.230.60.99) |
| 19:28.19 | Janos | so to the first call, config applied is the one for peer dm-cac, but in the second call the config applied is the one for peer 305 |
| 19:28.26 | Janos | all this in asterisk A |
| 19:29.02 | Janos | in the end asterisk A respond with a 401 to asterisk B for the call that does not work, because the config for peer 305 requires authentication |
| 19:30.03 | Janos | I guess the question in the end is, how can I tell asterisk A that everything that comes from ip 100.10.35.2 should be tied to peer dm-cac, no matter what from header comes in the SIP protocol |
| 19:32.02 | Janos | the sip debugging for the call that works looks like this |
| 19:32.11 | Samot | Why are you authing INVITEs between the two PBX systems? |
| 19:33.46 | Janos | that's the thing, I'm not, there is no auth between them and that's how to first call works |
| 19:34.37 | Janos | but on the second one, asterisk is match the calling peer with the FROM header (I think) instead of the IP where the call is coming from |
| 19:38.14 | *** join/#asterisk Martin` (~martin@shell.ipv6.octocore.net) |
| 19:41.11 | Janos | in the call that does work I get the following sip debug (among other things) |
| 19:41.14 | Janos | INVITE sip:6223@A SIP/2.0 |
| 19:41.58 | Janos | From: "Jhon Doe" <sip:240@B>;tag=HASH |
| 19:42.08 | Samot | ~pb |
| 19:42.08 | 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. |
| 19:42.16 | Samot | Show the whole thing, not just snippets of lines |
| 19:42.26 | Janos | sure, one sec |
| 19:46.24 | Janos | this is the sip debug for the working call |
| 19:46.25 | Janos | https://paste.debian.net/932766/ |
| 19:49.52 | Janos | this is the one for the not working call |
| 19:49.54 | Janos | http://paste.debian.net/932767/ |
| 19:51.05 | Samot | Found peer '305' for '305' from 100.10.35.2:5060 |
| 19:51.12 | Janos | yup that's the thing |
| 19:51.12 | Samot | Totally matched on the IP |
| 19:51.36 | Janos | Found peer 'dm-cac' for '240' from 100.10.35.2:5060 |
| 19:51.44 | Samot | The system may not like the fact it thinks it's calling itself. |
| 19:54.31 | Janos | peer B is called dm-cac in A, on the working call it match correctly to this peer, but on the non-working call it actually matches peer 305 which also exists in A but does not have the IP 100.10.35.2 but a 192.168.5.x |
| 19:55.03 | Samot | You probably are going to have to handle those calls differently. |
| 19:56.54 | Janos | My guess is that asterisk first tries to match the peer in sip.conf according to the SIP FROM header, in the non-working case From: "Jane Dow" <sip:305@100.10.35.2>;tag=as16a76bc8 |
| 19:57.12 | Janos | and then if that does not work it tries to match by peer ip address |
| 19:57.24 | Janos | and that explains why it does not work and it's all good |
| 19:58.24 | Janos | but the question is if it's possible to somehow force IP peer matching for these calls or any other idea actually :P |
| 20:01.16 | Janos | well I guess I should have read the docs and save myself some debugging :P |
| 20:01.16 | Janos | https://github.com/asterisk/asterisk/blob/master/configs/samples/sip.conf.sample#L90 |
| 20:01.25 | Janos | right there is what I just said |
| 20:08.45 | *** join/#asterisk jkroon (~jkroon@165.16.204.163) |
| 20:20.01 | *** join/#asterisk marlinc (~marlinc@1.0.0.127.13.204.167.185.in-addr.arpa) |
| 20:20.58 | Janos | well looks that if I switch all my sip users from type=friend to type=peer problem would be solved |
| 20:22.13 | *** join/#asterisk matrix1233 (~matrix123@41.230.60.99) |
| 20:23.06 | Janos | but then it looks like I would loose the ability to ask for user authentication ... not good |
| 20:24.04 | Janos | just one question remains, how does sip handle a call from user@example1.com to user@example2.com ... need to read up on sip I guess |
| 20:28.04 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
| 20:39.34 | *** join/#asterisk jkroon (~jkroon@165.16.204.163) |
| 20:42.16 | *** join/#asterisk pdugas (~retentive@c-73-82-30-193.hsd1.ga.comcast.net) |
| 20:46.37 | *** join/#asterisk TSM2 (5aff361d@gateway/web/freenode/ip.90.255.54.29) |
| 20:47.21 | TSM2 | is there a way to route DAHDI channels directly out to a remote trunk? |
| 20:50.38 | malcolmd | what kind of dahdi channels? |
| 20:50.42 | malcolmd | what kind of remote trunk? |
| 20:54.09 | TSM2 | ISDN BRI or PRI, basically making * work like a TA |
| 20:59.02 | malcolmd | well...if you're just cross-connecting channels, there's the dacs and dacsrbs channel definitions in /etc/dahdi/system.conf. that doesn't do anything but cross-connect the channels. there's no routing up into asterisk for call handling or number routing. if you do bring them up into asterisk, then just put the groups of channels you care about into contexts in asterisk's dial plan that you then push to the Dial application that calls |
| 20:59.02 | malcolmd | out some other group of channels. |
| 20:59.16 | malcolmd | but i'm probably not correctly understanding what you're wanting to do. |
| 21:00.50 | TSM2 | PRI > dahdi > asterisk > sip trunk > asterisk > client |
| 21:01.25 | Samot | Match the digits being passed by the PRI via DAHDI |
| 21:01.33 | Samot | Dial() out the SIP trunk |
| 21:03.00 | Samot | PRI -> Asterisk then you tell it what to do. |
| 21:03.01 | TSM2 | so using a custom extension for dial() |
| 21:03.05 | malcolmd | /etc/dahdi/system.conf (to configure dahdi at the card level) -> /etc/asterisk/chan_dahdi (to configure asterisk to use the dahdi hardware) + /etc/asterisk/pjsip.conf (to setup the sip trunk) + /etc/asterisk/extensions.conf (to tell asterisk how to process calls and what to dial) -> your client |
| 21:03.13 | Samot | Is this FreePBX? |
| 21:03.17 | Samot | Is so, wrong channel. |
| 21:04.14 | Samot | Because you're going to get the right advice, in concept, but you're not going to get the right methods to do it. |
| 21:04.31 | TSM2 | just wondering both ways, it seems it would be easier with a custom context as I dont think its easy to do from freepbx gui the way im thinking anywa |
| 21:04.50 | Samot | It's even easier via the GUI. |
| 21:05.07 | malcolmd | ah, sorry, i'm not familiar with using freepbx to accomplish such things. Samot's right. I can explain the concept at the Asterisk level, I can't explain what you might do in FreePBX. |
| 21:05.29 | TSM2 | malcolmd: nps |
| 21:05.44 | Samot | malcolmd: What he wants is the same process I gave him. |
| 21:06.00 | Samot | Match the digits the PRI is sending over the DAHDI channel. |
| 21:06.12 | Samot | Then Dial() the SIP trunk peer. |
| 21:07.23 | Samot | In FreePBX that's just making an Inbound Route with a destination set to the Trunk the call needs to go out. |
| 21:07.30 | Samot | Done. |
| 21:08.20 | TSM2 | Samot: but dont you have to match by DID/CID on inbound route while I would want to match on DAHDI channel group |
| 21:08.30 | Samot | malcolmd: In your defense he wasn't clear at all. |
| 21:08.48 | Samot | TSM2: It's pattern matching. |
| 21:09.19 | Samot | If the PRI is going to send 4 digits to the PBX |
| 21:09.36 | Samot | You still need an inbound route for those 4 digits to tell it where to go. |
| 21:09.38 | TSM2 | or more |
| 21:09.51 | Samot | OK. |
| 21:10.05 | Samot | Digit length can be anything. |
| 21:10.15 | Samot | The concept is still the same. |
| 21:10.33 | Samot | Calls from the PRI hit Asterisk. |
| 21:10.35 | Samot | Period. |
| 21:10.44 | malcolmd | w/ PRI, your groups should either be an individual PRI or the sum of all PRIs. channel allocation by dialed number isn't normal use of a PRI. so, you're really just matching based on dialed number, based on caller id, or based on group (a whole PRI or all PRIs that you put into a group). |
| 21:10.45 | TSM2 | yup, hmm I was hoping I was just able to match the channel group but your way would work |
| 21:10.46 | Samot | You have to tell Asterisk what to do with those calls. |
| 21:12.02 | malcolmd | you can put a group into a context and have a pattern match on that context for whatever you want and send it to wherever you want. i'm probably just confusing the issue because i'm not operating at the freepbx level, so i should probably keep my mouth shut. |
| 21:12.06 | Samot | Even with DAHDI Channel DIDs you need Inbound Routes. |
| 21:12.11 | TSM2 | could another way be pushing the dahdi channels to a custom context then do stuff in there |
| 21:12.40 | TSM2 | malcolmd: im not just looking at the fpbx level, i wanted to find out both ways |
| 21:12.53 | Samot | It's the same concept. |
| 21:13.13 | Samot | Map the DAHDI Channels to the same DID |
| 21:13.26 | Samot | So all the channels look to be coming from that DID |
| 21:13.44 | Samot | er to that DID, and route based on that |
| 21:28.29 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 21:31.54 | TSM2 | doing the DAHDI Channel map I would loose the real DID unfortunately, I need to play with some custom contexts and see what I can pass though a trunk |
| 21:40.50 | [TK]D-Fender | TSM2 |
| 21:40.50 | [TK]D-Fender | is there a way to route DAHDI channels directly out to a remote trunk? <- of course |
| 22:32.13 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 23:00.03 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-mqzajygstwdlyxlf) |
| 23:17.48 | *** part/#asterisk kharwell (kharwell@nat/digium/x-sswsoyhzezwhbaiv) |
| 23:32.04 | *** join/#asterisk matrix1233 (~matrix123@41.230.60.99) |
| 23:51.24 | *** join/#asterisk Janos (~Janos@190.171.120.15) |