| 01:04.44 | *** join/#asterisk MICROburst1 (~Thunderbi@x4e3674ed.dyn.telefonica.de) |
| 01:37.06 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 01:58.21 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 02:23.57 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 03:20.27 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 05:32.30 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:34.26 | *** join/#asterisk Kaian (~kaian@212.81.221.228) |
| 05:39.14 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 05:44.31 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 06:30.06 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
| 06:43.19 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 07:16.43 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 07:18.51 | *** join/#asterisk pabe (~pabe@81.24.66.208) |
| 07:42.56 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 07:53.08 | *** join/#asterisk DodgeThis (~DodgeThis@149.90.102.246) |
| 07:55.20 | *** join/#asterisk jkroon (~jkroon@41.113.32.90) |
| 08:09.52 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |
| 08:35.08 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 08:43.26 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 09:01.07 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 09:19.10 | *** join/#asterisk ganbold (~ganbold@66.85.186.234) |
| 09:24.27 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
| 09:32.08 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 09:32.46 | *** join/#asterisk Downlots (~Downlots@185.73.41.1) |
| 09:53.26 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 09:53.26 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
| 10:04.15 | *** join/#asterisk jkroon (~jkroon@165.16.203.53) |
| 10:12.35 | *** join/#asterisk pabe (~pabe@81.24.66.208) |
| 10:17.15 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 10:51.06 | *** join/#asterisk evilman_work (~evilman@87.244.6.228) |
| 11:04.21 | *** join/#asterisk emsjessec (~emsjessec@pool-173-54-255-231.nwrknj.fios.verizon.net) |
| 11:04.37 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 11:27.58 | *** join/#asterisk aoeui (~aoeui@unaffiliated/aoeui) |
| 12:28.57 | *** join/#asterisk dacod (~dacod@201.47.74.146) |
| 12:32.40 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 12:49.19 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:40.01 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
| 13:46.39 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-bgheepykqpfdvbsz) |
| 13:46.39 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 13:50.33 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-xpnhjlaszeqqijyx) |
| 13:50.33 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:16.57 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-vahfaqqftzkirzya) |
| 14:16.57 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:32.41 | *** join/#asterisk jkroon (~jkroon@165.16.204.106) |
| 14:50.31 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 14:51.23 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 14:56.48 | *** join/#asterisk sekil (~sekil@109-93-176-109.dynamic.isp.telekom.rs) |
| 14:59.04 | *** join/#asterisk AsteriskRoss (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 15:01.55 | AsteriskRoss | Should the I option in a dial supress Connected Line updates even on Local Channels? I'm getting Connected Line when a call transfer happens after the Dial with the I option set |
| 15:15.46 | *** join/#asterisk sibiria (~sibiria@unaffiliated/sibiria) |
| 15:20.27 | gtjoseph | AsteriskRoss: what's the full scenario? Attended, Blind, Blond? and which party is getting the connected line when they shouldn't? |
| 15:23.36 | AsteriskRoss | Party A Calls -> Company A (local channel) -> Party B Answers call. Party B calls Party C then transfers the call (attended) |
| 15:23.49 | AsteriskRoss | Party A is seeing the Caller ID of Party C |
| 15:24.10 | AsteriskRoss | Dial option I is set on all Dial commands in the chain |
| 15:28.39 | gtjoseph | Hmmm. I would have thought that it should have been suppressed in that scenario. |
| 15:30.32 | AsteriskRoss | So did I, it only happens when the transfer happens, not when Party B first answers the call. However if I remove the 'I' from the Dial that calls Party B it does change Party A's Caller ID. Which it shouldn't as the Local channel dial contains the 'I' |
| 15:31.37 | gtjoseph | If you want to experiment a bit try playing with "trust_connected_line" and "send_connected_line" endpoint options. They may not be a good solution if you sometimes need connected line and sometimes not but it might give us more info. |
| 15:32.23 | gtjoseph | Also, are you using PAI or RPID and what are trust_id_inbound and trust_id_outbound set to? |
| 15:32.36 | AsteriskRoss | I've tried with 'trust_id_inbound' set to yes and no with no change |
| 15:33.11 | gtjoseph | try outbound on party A's endpoint. |
| 15:33.54 | gtjoseph | Do you set any privacy related fields on callerid in the dialplan? |
| 15:34.18 | gtjoseph | that _could_ affect things as well. |
| 15:36.38 | AsteriskRoss | We do some number formatting and set CALLERID(all) but that sets the inbound to Company A (Party A) Caller ID |
| 15:37.49 | gtjoseph | gotcha. well, i'd suggest setting everything callerid/connected line related to the most restrictive settings and see if you still get the connected line. If not, then back off one setting at a time and see which one allows it again. |
| 15:38.22 | AsteriskRoss | Ok i'll give it a go |
| 15:38.53 | gtjoseph | cool. it might not offer a permanent solution but it may give us more info on where to look. |
| 15:39.01 | AsteriskRoss | ok thank you |
| 16:04.29 | AsteriskRoss | After testing it looks like the connected line updates are always passed on transfer, even if the I option is set. I also tried setting CONNECTEDLINE(pres)=prohib before calling Party C and in the pre-call handler for Party C |
| 16:15.33 | gtjoseph | AsteriskRoss: Hmmm. It's kinda funny because I just finished working with the FreePBX team on an issue where connected line _wasn't_ being passed back to the original caller and it turned out that it was because the I option was set. |
| 16:16.28 | gtjoseph | Don't forget...the "pres" stuff only takes effect if the "trust" options are false. |
| 16:17.36 | AsteriskRoss | Ok, i'll re-test with those options set to false |
| 16:22.43 | *** join/#asterisk Hyper_Eye (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 16:31.52 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 16:35.04 | AsteriskRoss | No Change, as soon as call is transferred the Caller ID on party A changes |
| 16:39.36 | AsteriskRoss | I think it must be related to the Local/ channel being used. I will test this theory also tomorrow. Thanks again for your input |
| 16:40.20 | rmudgett | The Dial 'I' option only blocks connected line updates until the call is answered. |
| 16:43.59 | gtjoseph | Uhm, not in my testing. If the call is Alice -> Bob -> Charlie with Bob doing a blond transfer and I passed in the Dial to Charlie, neither Alice nor Charlie get connected line updates even when Charlie answers. |
| 16:44.30 | igcewieling | why don't you pastebin the cli outout showing that specific call? |
| 16:44.32 | gtjoseph | s/ in / "I in" / |
| 16:44.45 | gtjoseph | rats |
| 16:46.39 | rmudgett | There is also the relatively recent "send_connected_line" endpoint option that can be used to always block connected line updates to the endpoint. |
| 16:47.40 | gtjoseph | yep. see chat history :) |
| 16:52.35 | igcewieling | In case anyone finds it helpful, here are my iptables rules to block known bad user agents. https://pastebin.com/T2MFrLGj |
| 17:15.13 | *** join/#asterisk pa (~pa__@unaffiliated/pa) |
| 17:23.21 | *** join/#asterisk jym (~jymmm@unaffiliated/jymmm) |
| 17:27.15 | jym | I realize this is OT, but maybe someone has come across this or could lead me in the right direction... I have gVoice for years with no issues, but for the last 9 to 18 months or so, when my cellphone is off or in a dead zone, none of my other linked phones will ring or ring one time, and the callphone's VM will immediately answer the call without allowing any of the other phones to rings. This didn't used to be the case and I'm not su |
| 17:27.15 | jym | re what changed. Any thoughts or suggestions would be appreciated |
| 17:28.42 | *** join/#asterisk salviadud (~ralfalfa@187-162-213-198.static.axtel.net) |
| 17:31.28 | *** join/#asterisk sekil (~sekil@109-93-176-109.dynamic.isp.telekom.rs) |
| 17:36.19 | Samot | That's something for google voice specific forums/rooms. |
| 17:39.30 | jym | Samot: I kinda realized that, but I haven't seen anything like that other there, or a bunch of "me too" comments" but not specific, and I'm not exactly sure how to describe it in a way that makes sense. "SOMETHING" in the way that I suspect gVoice detects lines are busy/ringing/VM has changed, but I don't know what it was before (that worked) and what now has changed. |
| 18:07.50 | *** join/#asterisk alexandre9099 (~alexandre@unaffiliated/alexandre9099) |
| 18:31.09 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
| 18:39.49 | *** part/#asterisk jym (~jymmm@unaffiliated/jymmm) |
| 18:53.18 | *** join/#asterisk jeffspeff (~jeffspeff@12.49.160.131) |
| 19:34.25 | AsteriskRoss | Regarding the connected line updates, I do want updates to be sent when performing call transfers and pick up but not across accounts. So ideally the endpoint answering the call shouldn't send connected line updates, but wants to receive them if that makes sense? |
| 19:56.29 | avb | |
| 19:56.51 | avb | ups, sorry guys |
| 20:51.28 | *** join/#asterisk vandyk (~vandyk@189.63.145.212) |
| 20:52.20 | *** join/#asterisk rohitjha (uid363271@gateway/web/irccloud.com/x-nwtlkgjwsutzlpux) |
| 21:01.48 | *** join/#asterisk zapata (~zapata@2a02:1748:f71:380:b442:8f26:db71:9301) |
| 22:52.51 | *** join/#asterisk n8n8 (~n8@23.137.64.1) |
| 22:56.57 | n8n8 | I'm stuck on a pjsip problem. I've got 4 endpoints which can send and receive calls. The can send BLF and recieve MWI. But, when I put them in a queue, they show up as unavailable. When I open a call with any of them, queue show reports them as inuse. As soon as they hangup, they go back to unavailable. Any suggestions as to a good place to focus my attention would be most welcome |
| 22:59.03 | n8n8 | The problem is I cannot send calls to them in the queue. pjsip show endpoint also shows the state as unavailable, and shows contact as 'Created', where my other, fully working contacts show up as Unknown.... |
| 23:04.50 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-142-242.socal.res.rr.com) |
| 23:47.19 | *** join/#asterisk overyander (~overyande@209.141.208.197) |