IRC log for #asterisk on 20210228

00:11.37*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
00:50.43*** join/#asterisk Dovid (~dovid@96.56.22.146)
02:29.39*** join/#asterisk tsal (~tsal@i59F5FF34.versanet.de)
05:16.25*** join/#asterisk electronic_eel_ (~quassel@213.240.182.225)
05:26.29*** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net)
06:26.45*** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net)
06:54.44*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
07:07.26*** join/#asterisk estragon (~gerard@lfbn-nic-1-96-192.w2-15.abo.wanadoo.fr)
08:34.54*** join/#asterisk sponji (~i5@172.58.107.28)
09:01.51*** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54)
09:59.39*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
12:10.27*** join/#asterisk javi404 (~quassel@unaffiliated/javi404)
12:14.39*** join/#asterisk javi404 (~quassel@unaffiliated/javi404)
12:41.12*** join/#asterisk electronic_eel (~quassel@213.240.182.135)
13:04.18*** join/#asterisk rpifan (~rpifan@p200300d2671bda00d08805972a7823e0.dip0.t-ipconnect.de)
13:07.13*** join/#asterisk aoeui (~aoeui@unaffiliated/aoeui)
13:24.21*** join/#asterisk javi404 (~quassel@unaffiliated/javi404)
13:54.15*** join/#asterisk sponji (~i5@172.58.107.99)
14:46.46*** join/#asterisk rpifan (~rpifan@p200300d2671bda00980b1f7f47100b20.dip0.t-ipconnect.de)
15:25.27*** join/#asterisk rpifan (~rpifan@p200300d2671bda002e10b502c3ab54d2.dip0.t-ipconnect.de)
16:34.50*** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772)
16:43.51*** join/#asterisk rwb1 (~Thunderbi@65.183.138.202)
17:09.08*** join/#asterisk rwb1 (~Thunderbi@65.183.138.202)
17:10.37electronic_eelI've got an asterisk 16.16.1 that is creating disk io load problems because it is constantly writing to the astdb.sqlite3 file
17:11.12electronic_eelwhen looking into the sqlite journal it seems like it is constantly updating the subscription_persistence data
17:12.02igcewielingdo you have a lot of subscribes?
17:12.05electronic_eelthere are about 30 phones connected that have about 15 blf monitors open each
17:12.11igcewielingah.
17:12.12electronic_eelis that a subscribe each?
17:12.20igcewielingI think so.
17:12.29electronic_eelis there a way to make them not persistent?
17:12.51igcewielingno idea, you have reached the limit of my knowledge about subscriptions.
17:13.40electronic_eelnow i could probably load the whole file into a tmpfs, but that seems like a rather crude solution to me
17:13.43igcewielingmaybe check pjsip.conf.sample of something obvious?
17:14.21filehttps://www.irccloud.com/pastebin/jVDBIsao/
17:14.24filein sorcery.conf may do it
17:14.47electronic_eelok, i'll try that
17:14.49igcewielingsometimes I wonder if file should be venerated as a god.
17:14.59fileit does require a restart.
17:15.18electronic_eelno problem, that is why i'm working on this on sunday ;)
17:25.04electronic_eelthank you very much, that reduced io load significantly
17:37.53Kobazerm..
17:38.22Kobazanyone have any idea why throwing ast_verbs in channel.c ast_queue_hangup would lock up pjsip ?
17:39.52KobazFlow: Device1 Calls Asterisk to ring Device2. (B2BUA), and then Device 2 Transfers to Park,  Device 3 does a park pickup and then hangs up.  ast_queue_hangup gets called and then tries to log the hangup, and then BYE's never get sent out
17:42.53Kobazand oddly enough there's no locks being held
17:45.58fileif it isn't deadlocked, then it's not locked up
17:46.05Kobazyeah, in theory
17:46.08fileas well this is users so most people in here have barely any idea what you're talking about
17:46.18fileas well the debug log generally provides info
17:46.26Kobazi know... i knew you were here and might jump in :)
17:46.29fileand there is no "in theory"
17:47.01fileotherwise, no idea, you'd have to investigate yourself
17:49.35Kobazoh, you know what
17:49.54Kobazit has nothing to do with that, i took out the code, still occuring, and. i built 16.16.1 clean with no changes, and it's still occuring
17:50.09KobazI'll try and build a test case and file a bug
17:51.08fileok
17:56.59SamotUm this on the same system?
17:57.08Kobazsame system as what
17:57.22SamotEach other
17:57.25Kobazoh, yeah
17:57.30SamotDevice1 and device2
17:57.35Kobazyup
17:58.03SamotSo who should get the BYE in this case?
17:58.15*** join/#asterisk electronic_eel_ (~quassel@213.240.182.227)
17:58.29Kobazthe parked caller got got picked up
17:58.36Kobazliterally the phone locks up in some situations
17:58.51SamotWhat kind of phone?
17:58.57Kobazolder polycom. 331
17:59.08Kobazi actually got a vvx to semi-crap out as well
17:59.10SamotOh the one that might have a bug
17:59.14Kobazit was stuck in 'transferring'
17:59.17SamotWhat vvx?
17:59.24Kobazvvx 400
17:59.31SamotWhat firmware?
17:59.36Kobaznewest that it can handle
17:59.43SamotSo 5.9
17:59.55Kobaz5.9.1
17:59.56Kobazyeah
17:59.58SamotOk
18:00.15SamotHow does it semis crap?
18:00.23Kobazforever until you reboot
18:00.35Kobazwell, forever meaning, more than 20 minutes
18:00.37SamotWhat does it do?
18:00.45Kobazjust sits there flashing the line, you can't hit the line key
18:01.03Kobazit's in some sort of weird state because media stopped flowing and it never got a BYE
18:01.10SamotShow a call
18:01.13Kobazyeah
18:01.25Kobazit's not very interesting, it's an entire call, just without a BYE
18:01.27SamotBecause I have customers using this
18:01.36Kobazbut, yeah i'll get that
18:01.41SamotOn VVXs with that firmware
18:01.49SamotNo one locks up
18:01.56SamotCalls end properly
18:02.04Kobazi can't get it to break on phone<->asterisk<->phone
18:02.19Kobazjust phone->park  otherphone->parkpickup,  otherphone->hangup
18:02.28SamotYes
18:02.34SamotThats what I was saying
18:02.37Kobazk
18:02.40SamotPark and pickup
18:02.51SamotThey park calls between each other all the time
18:04.24SamotAnd
18:04.41Kobazi'm narrowing down if it just is related to park, or tearing down an agi that ran park
18:04.44SamotThey use both transferring by phone
18:04.59SamotAnd pickup by phone plus using FOP2
18:05.17SamotSo two different methods
18:05.26SamotFOP uses AMI
18:05.32SamotPhones use dialplan
18:14.13Kobazweeeel, i'm now having a hard time reproducing.. so, to be continued
18:40.24*** join/#asterisk eXistenZ (~pectic@bzq-79-180-211-217.red.bezeqint.net)
18:45.09KobazOkay, i got it to break again, here's a call
18:45.30Kobazhttps://dpaste.com/BWA38T9VG.. and this is native 16.16.1
18:46.01Kobazi only have the 2803 side of the call here in this log
18:46.19Kobaz2803 -> 2802 -> xfer park 700        2801 -> pickup park 700, hangup
18:47.03Kobazat 13:40:06 2801 hangs up, and 2803 (original parked caller) doesn't get a BYE
18:47.40Kobazso i'll get a nice console log with everything as well
18:56.55Kobazwell dpaste doesn't like the size but
18:57.01Kobazhere's the raw debug in all its glory: https://filebin.net/qkpwpgl7l2jrhrm1
18:58.04Kobaznotice the conspicuous lack of any kind of sip traffic after [2021-02-28 13:52:53.069] DEBUG[8277][C-0000000e] channel.c: Channel 0x7fc3f020ee20 'PJSIP/2803-00000012' hanging up.  Refs: 2
19:00.09Kobazwhat i don't know yet, is if this still exists if you're not using agi
19:02.59fileit encountered a transport error trying to send the BYE, why that is I don't know
19:04.18Kobazaah
19:04.37Kobaz[2021-02-28 13:52:53.075] DEBUG[5109] res_pjsip_session.c: PJSIP/2803-00000012: Source of transaction state change is TRANSPORT_ERROR
19:06.16Kobazhttps://dpaste.com/5F87FXKP8
19:06.19Kobaztransports
19:07.10Kobazoh
19:07.26Kobazthis might be those race conditions you're talking about with pjsip reload
19:07.32Kobazlet me turn thqat off
19:08.20Kobazi see there was a res_pjsip reloading during some portion of the flow
19:09.59SamotYeah, it's always better to be "no" for that.
19:10.27Kobazyeah
19:10.30KobazYou've mentioned
19:10.47KobazAnd, I've been testing with it on, to see if anything breaks, so.. this could be it
19:11.33Kobazi would like to work on a mini-reload for res_pjsip
19:11.49Kobazbasically it would be quite useful to be able to update local_net runtime
19:11.53Kobazthat's really all i need it for
19:12.08Kobaz...lock everything else
19:20.01Kobazyeah, this is considerably much better.  I was occasionally getting transport errors when calling b2bua phone to phone
19:57.30Kobazgoing well so far
19:57.31Kobazthanks
20:16.44*** join/#asterisk scampbell (~scampbell@mail.scampbell.net)
20:33.37*** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at)
21:01.45*** join/#asterisk opal (~wowaname@volatile/founder/wowaname)
21:03.00*** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net)
22:08.19*** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme)
22:19.53*** join/#asterisk electronic_eel (~quassel@213.240.182.227)
22:35.55*** join/#asterisk Dovid (~dovid@96.56.22.146)
23:11.22*** join/#asterisk electronic_eel (~quassel@electroniceel.org)
23:14.45kerouac[m]<drmessano "and I, for one, don't click on r"> Sorry, I'm just bridged to IRC from matrix ) I'll try to split message on little ones. I wrote:
23:15.00kerouac[m]Hi there. I'm trying to configure asterisk 17 for the first test call with webRTC as it is said in
23:15.00kerouac[m]https://wiki.asterisk.org/wiki/display/AST/WebRTC+tutorial+using+SIPML5
23:15.12kerouac[m]I've done proper configs in /etc/asterisk/pjsip.conf and extensions.conf (to have 200 to answer demo-congrats).
23:15.12kerouac[m]I logged in my instance of asterisk with
23:15.12kerouac[m]https://www.doubango.org/sipml5/
23:15.31kerouac[m]using my proper endpoint's login and password. But trying to call 200, i get this in log of asterisk:
23:15.31kerouac[m]```ERROR[13982]: res_pjsip_session.c:934 handle_incoming_sdp: 6001: Couldn't negotiate stream 0:audio-0:audio:sendrecv (nothing)```
23:15.44kerouac[m]What could be the reason?
23:15.44kerouac[m]Google says that something wrong with codec's but I have no idea how to check it up.

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.