| 00:03.03 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 00:17.50 | *** join/#asterisk babak (uid19622@gateway/web/irccloud.com/x-yxotwedtlysfwlls) |
| 00:17.56 | *** join/#asterisk Samot_ (sid133316@gateway/web/irccloud.com/x-bsgjvrxxgffvlqwq) |
| 00:17.57 | *** join/#asterisk leftleg_ (sid291906@gateway/web/irccloud.com/x-ewxewjsayyqzrmgs) |
| 00:17.58 | *** join/#asterisk file (sid178970@asterisk/developer-and-muffin-lover/file) |
| 00:17.58 | *** mode/#asterisk [+o file] by ChanServ |
| 00:18.45 | *** join/#asterisk erichowey (uid462861@gateway/web/irccloud.com/x-somxolhsihdxrczi) |
| 00:19.20 | *** join/#asterisk drmessano (drmessano@pdpc/supporter/active/drmessano) |
| 00:19.27 | *** join/#asterisk hardwire (sid415742@gateway/web/irccloud.com/x-dtqyzhzqxhdivnlf) |
| 00:19.31 | *** join/#asterisk idtentee (sid101023@gateway/web/irccloud.com/x-ootlnxyivwgrxcwc) |
| 00:51.15 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 00:56.50 | *** join/#asterisk obrut (~obrut@static.108.201.69.159.clients.your-server.de) |
| 01:20.00 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 01:44.35 | *** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com) |
| 02:11.24 | *** join/#asterisk tsal (~tsal@i59F5F5AF.versanet.de) |
| 02:17.34 | *** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com) |
| 03:42.42 | *** join/#asterisk electronic_eel (~quassel@213.240.182.43) |
| 03:55.46 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 03:58.24 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 04:19.52 | *** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com) |
| 04:24.26 | *** join/#asterisk NightMonkey_ (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 04:25.33 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 04:31.26 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 04:43.11 | *** join/#asterisk vader- (sid163236@gateway/web/irccloud.com/x-umvbmdmudmpeargq) |
| 04:43.28 | vader- | hows it going guys and girls |
| 04:45.57 | vader- | Had a quick question, is there a good place to sell an Xorcom XR0004 - USB Asterisk Channel bank? |
| 04:45.58 | vader- | 8 FXS + 8 FXO Ports |
| 04:52.55 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 05:08.51 | drmessano | vader-: Yard sale, maybe |
| 05:10.55 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 05:11.38 | *** join/#asterisk gregs (sid160074@gateway/web/irccloud.com/x-nkvizzgepqvbboih) |
| 05:14.28 | drmessano | Latest user manual is 2009 |
| 05:14.29 | drmessano | wow |
| 05:16.42 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 05:25.05 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 05:27.00 | vader- | ya i think i bought it for a client in 2012, ant iwas like $1100 |
| 05:27.04 | vader- | and it |
| 05:27.23 | vader- | pulled it a few years ago and it's been shelved |
| 05:46.18 | igcewieling | admits to being unable to throw away a a chassis full of https://www.telephonecollectors.info/index.php/browse/bc-switching-library/tellabs/10948-tellabs-257x-d/file |
| 05:59.06 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 06:07.37 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 06:16.22 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 06:21.56 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 07:02.43 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 07:41.17 | *** join/#asterisk lankanmon (~LKNnet@cpeb4fbe4e331bd-cm64777d632380.cpe.net.cable.rogers.com) |
| 08:38.00 | *** join/#asterisk Andee (~Andee@fw2-ad-gw.orbital.net) |
| 08:39.59 | *** join/#asterisk Andee (~Andee@fw2-ad-gw.orbital.net) |
| 09:15.24 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 09:22.19 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 09:59.17 | grummund_ | Is there a standard way to set the incoming callerid "name" based on a lookup of the number? |
| 10:00.28 | grummund_ | or, how could it be done? |
| 11:02.37 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 12:17.47 | *** join/#asterisk Kritnich9 (~Kritnich@kritni.ch) |
| 12:18.42 | *** join/#asterisk cation21- (cation21@gateway/vpn/protonvpn/cation21) |
| 12:22.55 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 12:26.57 | *** join/#asterisk pfactum (~post-fact@vulcan.natalenko.name) |
| 12:29.03 | *** join/#asterisk sinaowolabi (~Sina@169.159.121.251) |
| 12:40.55 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 12:59.11 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 13:00.31 | *** join/#asterisk mrtnt (~martint@martint.data.ee) |
| 14:01.08 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 14:02.26 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 14:04.38 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 14:04.43 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 14:46.50 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 15:18.32 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-qggfhnyyxsstfuop) |
| 15:18.32 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:29.51 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-qncrjthhrahmedxd) |
| 15:29.51 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:35.26 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 16:01.02 | *** join/#asterisk akp55_ (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 16:02.06 | *** join/#asterisk ^MillerBoss (~biffies@gives.you.more.taste.at.only.96.calories.millerboss.com) |
| 16:16.42 | *** join/#asterisk overyander (~overyande@216.163.21.11) |
| 16:23.18 | *** join/#asterisk obrut (~obrut@static.108.201.69.159.clients.your-server.de) |
| 16:53.42 | *** join/#asterisk overyander (~overyande@216.163.21.11) |
| 16:57.15 | *** join/#asterisk sinaowolabi (~Sina@154.66.62.248) |
| 17:07.23 | *** join/#asterisk qakhan (~qakhan@50-204-254-11-static.hfc.comcastbusiness.net) |
| 17:08.46 | qakhan | Hi all, which takes priority. queue.conf vs app queue timeout ? |
| 17:09.18 | qakhan | i need to move call from Q1 to Q2 after 15 seconds |
| 17:15.39 | seanbright | i would assume that anything passed to a dialplan application that could override what was in that application's configuration file, would override what was in the configuration file. |
| 17:16.12 | seanbright | more succintly: app queue timeout would take priority |
| 17:20.14 | qakhan | thanks |
| 18:09.43 | qakhan | is it possible that we play a sound file to agent before Q connect a call to that agent? |
| 18:27.41 | *** join/#asterisk eXistenZ (~pectic@bzq-109-64-205-119.red.bezeqint.net) |
| 18:30.19 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |
| 19:25.23 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 19:29.51 | *** join/#asterisk ilius (~ilius@c-73-228-87-69.hsd1.ut.comcast.net) |
| 19:30.27 | ilius | Is this still the case with direct-media SRTP? https://community.asterisk.org/t/asterisk-direct-srtp/73695/4 |
| 19:30.55 | file | yes. |
| 19:31.26 | *** join/#asterisk waldo323 (~waldo323@d149-67-45-83.clv.wideopenwest.com) |
| 19:31.37 | ilius | Thank you file. Okay, I guess I'll have to make my main server deal with audio streams. Ha. :D |
| 19:40.26 | igcewieling | With so much NAT, direct media often isn't an option anyway. |
| 19:44.32 | ilius | Yeah. When I can, I like to offload the audio to different "media-only" servers to make sure audio is never dropped. |
| 19:56.42 | *** join/#asterisk mbecroft (mb@ak2.becroft.co.nz) |
| 20:01.43 | Kobaz | I have something fun for you guys |
| 20:03.11 | Kobaz | Recieve New Call (PJSIP).. Answer(), Playback(tt-monkeys), MusicOnHold .... no audio recieved at all, at any time on endpoint. Answer(), Wait(1), Playback(tt-monkeys), MusicOnHold... audio received right away |
| 20:03.18 | Kobaz | I'll paste up some logs in a few |
| 20:03.44 | Kobaz | Asterisk 16.15.0 |
| 20:03.53 | *** join/#asterisk Pectic (~pectic@bzq-79-183-199-109.red.bezeqint.net) |
| 20:07.09 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 20:08.07 | Kobaz | without going into the nitty gritty just yet: https://dpaste.org/FvPX |
| 20:08.53 | Kobaz | The main difference between the one that works and one that doesn't, is: > 0x7f64700f1ac0 -- Strict RTP switching to RTP target address XX.YY.44.103:4032 as source |
| 20:09.03 | Kobaz | Sorry, redid the paste: https://dpaste.org/9W8J#L20 |
| 20:09.25 | Kobaz | There is no RTP switching when the audio is played right away |
| 20:15.17 | Samot | Why are those two executing differently? |
| 20:17.01 | Kobaz | I have no idea |
| 20:17.15 | Samot | Well the Wait() executes at different priorities |
| 20:17.20 | Samot | And in different orders. |
| 20:17.27 | Kobaz | Right, I'm changing the flow between runs |
| 20:17.35 | Samot | Uhm. |
| 20:17.46 | Kobaz | The one with the pre Wait(1) works. and where I don't Wait(1), there's no audio |
| 20:17.54 | Samot | OK. |
| 20:18.01 | Kobaz | Wait(1) always works. Answer() Playback() in this case, never works |
| 20:18.27 | igcewieling | what happens when you put Wait before the answer? |
| 20:18.32 | Kobaz | good question |
| 20:19.08 | Kobaz | That works too |
| 20:19.37 | Kobaz | Also Background/Playback both fail in the same way |
| 20:19.52 | Kobaz | now.. RTP according to asterisk *is* going out in both scenarios |
| 20:20.07 | Kobaz | Sent RTP packet to XX.YY.44.103:4046 (type 00, seq 010530, ts 232625, len 000170) |
| 20:20.10 | igcewieling | if wait before the answer works, perhaps it is a call setup issue, not a media issue? |
| 20:20.14 | Kobaz | lots of those... in both cases |
| 20:20.34 | Kobaz | It does sound like call setup |
| 20:20.35 | Samot | A wait() after answer works |
| 20:20.45 | Samot | It's the wait() after Background |
| 20:20.57 | Kobaz | Wait(1) after Background makes no difference |
| 20:21.13 | Kobaz | Addiing a Wait(1) before Answer() or after Answer() makes media always 'flow' |
| 20:21.17 | Samot | In two examples you provide |
| 20:21.25 | Samot | Non-working has wait after background |
| 20:21.31 | Samot | The working has wait after answer |
| 20:21.48 | Kobaz | correct |
| 20:21.56 | Samot | And if you set teh wait before answer |
| 20:21.59 | Samot | It waits that long |
| 20:22.02 | Kobaz | Right, and also works |
| 20:22.06 | Samot | Just like it would after the answer |
| 20:22.09 | Samot | But before background |
| 20:22.15 | Samot | So again, could be a signaling issue |
| 20:22.22 | Samot | Have you looked at that? |
| 20:22.24 | Kobaz | Adding a Wait(1) after Background() does not do anything different |
| 20:22.30 | Kobaz | Yeah I've been looking at it |
| 20:22.33 | Kobaz | I think I'll do some text diffs |
| 20:22.45 | Kobaz | Just by eye, it looks the same, but... |
| 20:22.53 | Samot | OK |
| 20:22.54 | Kobaz | It would be telling if there were differences |
| 20:22.59 | Samot | So let me get this straight |
| 20:23.12 | Samot | You show an example of a non-working and a working |
| 20:23.26 | Samot | Both having things execute in different priorities |
| 20:23.38 | Samot | And you wanted us to look at that |
| 20:23.45 | Kobaz | That part should be irrelevant |
| 20:23.49 | Samot | When it was pointed out, you're now saying it doesn't matter. |
| 20:23.51 | Samot | OK |
| 20:23.53 | Kobaz | It's not a dialplan question |
| 20:24.01 | Samot | Then why did you show us dialplan? |
| 20:24.03 | Kobaz | This is RTP/media related |
| 20:24.17 | Kobaz | Because of: >>>>> > 0x7f64700f1ac0 -- Strict RTP switching to RTP target address XX.YY.44.103:4032 as source |
| 20:24.27 | Kobaz | I just wanted to start with the high level... if that stuck out at anyone |
| 20:24.45 | Samot | Well the two examples also have two different ports |
| 20:24.51 | Kobaz | there is no 'RTP switching' occuring without Wait(1) |
| 20:24.52 | Samot | 4032 and 4034 |
| 20:25.04 | Kobaz | Sure, because clients will cycle ports |
| 20:25.32 | Kobaz | I can have this client use a specific port, but it probably won't matter |
| 20:25.52 | Kobaz | good to rule out though |
| 20:27.13 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 20:28.08 | Samot | So the client isn't getting audio but Asterisk is sending it? |
| 20:28.29 | Kobaz | according to asterisk it's sending it... actually i haven't done a tcpdump |
| 20:28.31 | Kobaz | It probably is... |
| 20:28.54 | Kobaz | I've never run into a situation where asterisk says it's sending rtp and it's not actually sending rtp |
| 20:29.26 | Samot | OK the client is remote |
| 20:29.32 | Samot | This could be a NAT issue |
| 20:29.55 | Samot | The Wait() could be what is given the NAT time to catch up. |
| 20:30.01 | Kobaz | yeah |
| 20:30.27 | Kobaz | once it's 'caught up |
| 20:30.44 | Kobaz | media should be funtional I would think... |
| 20:30.50 | Samot | It is. |
| 20:31.03 | Kobaz | No i mean... without the early Wait() |
| 20:31.19 | Kobaz | Sometime during Playback or MusicOnHold it should 'catch up' |
| 20:31.30 | Kobaz | at least, it does with chan_sip |
| 20:32.21 | Kobaz | Like once chan_sip figures out the RTP, it does start working, in every other setup i've dealt with |
| 20:32.30 | Kobaz | You'll get no audio until the client sends RTP and then you're golden |
| 20:33.34 | Samot | So |
| 20:34.00 | Kobaz | I'm diffing the working/notworking SIP, and it's identical except for ports, nonce, callid, the usual |
| 20:34.03 | Samot | What you're saying is, if this was a chan_sip peer it would do the same thing until the phone sent RTP itself. |
| 20:34.06 | Kobaz | I'll paste those up in a second |
| 20:34.29 | Samot | Like put the call on hold and take it off hold? |
| 20:38.01 | Kobaz | I can test that |
| 20:39.35 | Kobaz | https://dpaste.org/Ns9P and https://dpaste.org/8di5 |
| 20:40.26 | Kobaz | yeah hold/unhold works (with the early Wait) |
| 20:40.35 | Samot | And without? |
| 20:41.11 | *** join/#asterisk Andrew (~Andee@94.101.148.71) |
| 20:41.18 | Kobaz | no go, without the early Wait |
| 20:42.59 | Kobaz | so friggin weird |
| 20:44.09 | Samot | ? |
| 20:45.17 | Kobaz | and yeah, tcpdump is showing rtp going out, when the client's not processing any |
| 20:45.45 | Samot | Which, in the industry, is what we call a NAT issue. |
| 20:45.55 | Kobaz | i really would be interested to know what's the difference, why in one situatation you get 'Strict RTP switching to RTP' and sometimes not |
| 20:46.26 | Kobaz | it could be nat, but something is happening different on the asterisk side |
| 20:46.27 | Samot | Your SIP debugs missed things |
| 20:46.36 | Samot | Like the actual ACKs to the 200 OKs. |
| 20:46.47 | Samot | They looked perfectly fine leaving Asterisk. |
| 20:46.56 | Samot | It was what happens after they leave Asterisk that was missing. |
| 20:47.04 | file | I've seen numerous people with weird issues with the MicroSip client, assuming it is Asterisk and discounting MicroSip is not wise |
| 20:47.12 | file | I'd start on the client first |
| 20:48.33 | Kobaz | And the ACK's are fine okay too |
| 20:49.01 | Samot | So both types of calls send ACKs to the 200 OK |
| 20:49.03 | Kobaz | file: I'm not assuming it's asterisk just yet, but I'm noticing a difference on the asterisk side that I was very curious about |
| 20:49.07 | Samot | Audio and no audio |
| 20:49.15 | file | what - the log message? |
| 20:49.19 | Kobaz | yeah |
| 20:49.24 | file | that happens when media is received |
| 20:49.28 | Kobaz | 'Strict RTP switching to RTP'... then everything works |
| 20:49.28 | file | no media received, no message |
| 20:49.37 | Kobaz | Okay, that trips when it gets media |
| 20:49.41 | file | yes. |
| 20:49.45 | Kobaz | K cool, good to know |
| 20:53.44 | Kobaz | Like, for now. Sticking a Wait(1) in there is a bandaid, but I would like to figure out why I need this. |
| 20:53.51 | Kobaz | So yeah, i'll start poking at microsip |
| 20:54.15 | Kobaz | And then what happens when 1 second isn't long enough. maybe a high load situation, or network delay... it's not a real fix |
| 20:55.28 | igcewieling | I put a 1 second wait at the start of calls processed by our main asterisk box. Seems to reduce abandoned. |
| 20:55.50 | igcewieling | lots of people dial, then hangup when they relalized they misdialed. |
| 21:28.25 | vader- | So thinking of putting this Xorcom USB Channel bank on ebay... Any thoughts on pricing? |
| 21:29.17 | vader- | It is an XR0004 model which is 8 FXO + 8 FXS |
| 21:30.12 | vader- | https://www.voipsupply.com/xorcom-astribank-usb-gateway-for-asterisk-pbx#configure |
| 21:36.54 | *** join/#asterisk erichowey (uid462861@gateway/web/irccloud.com/x-iiqckrwfnxqghvua) |
| 21:37.05 | *** join/#asterisk drmessano_ (drmessano@pdpc/supporter/active/drmessano) |
| 21:37.23 | *** join/#asterisk leftleg__ (sid291906@gateway/web/irccloud.com/x-hvxbowldricblagh) |
| 21:37.28 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-pdtbrgdvyqjauuvm) |
| 21:37.28 | *** mode/#asterisk [+o bford] by ChanServ |
| 21:37.54 | *** join/#asterisk bbhoss (sid18216@gateway/web/irccloud.com/x-wkegsdoqqszhpojl) |
| 21:46.14 | *** join/#asterisk AndyCap (~aoy@pdpc/supporter/sustaining/AndyCap) |
| 23:25.13 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 23:57.57 | grummund_ | Anyone have an idea how to upload a Personal Address Book to a cisco SPA303 phone? |
| 23:58.29 | grummund_ | found a cisco document saying it's possible, but not how to. |