| 00:05.48 | *** join/#asterisk-dev csavinovich (sid296765@gateway/web/irccloud.com/x-ikhgmkslizdgwotw) |
| 00:05.48 | *** mode/#asterisk-dev [+o csavinovich] by barjavel.freenode.net |
| 03:49.00 | *** join/#asterisk-dev csavinovich (sid296765@gateway/web/irccloud.com/x-ikhgmkslizdgwotw) |
| 03:49.00 | *** mode/#asterisk-dev [+o csavinovich] by barjavel.freenode.net |
| 05:58.19 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 05:58.19 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 06:14.00 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 07:09.17 | Ravenheart | good day |
| 07:13.49 | DanJenkins[m] | Hi [Ravenheart](https://matrix.to/#/@freenode_Ravenheart:matrix.org) |
| 07:23.52 | *** join/#asterisk-dev CELYA_ (~Thunderbi@185.122.102.37) |
| 07:42.09 | Ravenheart | hey Dan can i ask some stupid question related to AMI |
| 07:43.21 | DanJenkins[m] | Of course! It's been a while though! Haha |
| 07:45.03 | Ravenheart | well me and my colleague are trying to piece together a "call" |
| 07:45.14 | Ravenheart | so far we got the correct events in the correct order |
| 07:45.35 | Ravenheart | every outside call gets routed to a queue |
| 07:46.00 | Ravenheart | and both support agents have their phones ring |
| 07:46.47 | Ravenheart | we receive two NewChannel events for those two ringing phones, but neither has its Exten set to the correct value, both have their Exten set to "s" |
| 07:47.08 | Ravenheart | how do we differentiate which channel is for which extension |
| 07:56.06 | Ravenheart | https://hatebin.com/rsarlckdlk |
| 07:56.30 | Ravenheart | this is one of the NewChannel events |
| 08:23.03 | DanJenkins[m] | hey sorry was getting into work |
| 08:25.14 | DanJenkins[m] | based on the channel |
| 08:25.23 | DanJenkins[m] | "PJSIP/toshko-0000000d" |
| 08:25.40 | DanJenkins[m] | toshko is the extension in pjsip.conf |
| 08:26.12 | DanJenkins[m] | presumably you have the two support agents have their own extensions Ravenheart |
| 08:27.58 | DanJenkins[m] | exten = s is the extension in the dialplan.... how did you move the inbound call from say coming in on XYZ from your provider into the queue? |
| 08:55.10 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.98) |
| 09:39.50 | *** join/#asterisk-dev CELYA_ (~Thunderbi@185.122.102.37) |
| 09:54.46 | *** join/#asterisk-dev CELYA_ (~Thunderbi@185.122.102.37) |
| 10:40.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 10:59.37 | Ravenheart | https://hatebin.com/awtsegbvpq @ DanJenkins[m] |
| 11:01.09 | Ravenheart | i have not defined agents explicitly |
| 11:01.33 | Ravenheart | they are "dynamic" agents, ie AddQueueMember with the extension |
| 11:01.54 | DanJenkins[m] | ah right, hence why they're "s" |
| 11:02.17 | DanJenkins[m] | so does "toshko" correlate with the pjsip extension name? |
| 11:02.21 | Ravenheart | yes |
| 11:02.36 | Ravenheart | i can string split it from the channel name |
| 11:02.45 | Ravenheart | but was wondering why it isn't correct in Exten |
| 11:03.18 | DanJenkins[m] | because thats not the extension as far as the physical phone |
| 11:03.34 | DanJenkins[m] | (or soft phone) |
| 11:03.56 | DanJenkins[m] | its just how asterisk internally dials out to your pjsip extensions |
| 11:06.17 | Ravenheart | so can i configure it or change up my dialplan to get the extension into Exten |
| 11:18.48 | DanJenkins[m] | i honestly dont know, I'd personally be using the channel identifier |
| 11:49.57 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.98) |
| 13:57.25 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-zxcpghvdzqjbkmiy) |
| 13:57.25 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 13:58.36 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-bbchiznkswnckvao) |
| 13:58.36 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:26.14 | jsmith | file: Are you aware that images are currently broken on the Asterisk blogs? |
| 14:26.17 | jsmith | file: Someone just complained to me that they can't see the images on https://www.asterisk.org/dana-and-asterisk-part-2/ |
| 14:26.37 | file | no |
| 14:27.01 | file | drop an email to bcopeland |
| 14:40.43 | *** join/#asterisk-dev csavinovich (sid296765@gateway/web/irccloud.com/x-xcyjavtwbpjivqcr) |
| 14:40.43 | *** mode/#asterisk-dev [+o csavinovich] by ChanServ |
| 14:56.23 | seanbright | looks like https://gerrit.asterisk.org/c/asterisk/+/15016 was missed |
| 14:56.53 | seanbright | or are 18 patches getting held back? |
| 14:57.14 | gtjoseph | oops on my part :) |
| 14:57.37 | gtjoseph | in the queue |
| 14:58.21 | seanbright | k |
| 15:57.10 | *** join/#asterisk-dev AsteriskRoss_ (~AsteriskR@37.157.48.2) |
| 18:02.06 | gtjoseph | seanbright: I'm looking specifically at app_externalivr about line 514 where it's looping over addresses trying create and start. if either fails, it contiues without cleaning up a possibly open socket. |
| 18:05.45 | gtjoseph | looks like res_http_websocket does the same thing. if either call fails, it just returns an error. |
| 18:07.29 | gtjoseph | oh wait, oh wait, websocket does go through the destrructors |
| 18:08.11 | gtjoseph | i don't think externalivr does though because it's not a websocket |
| 18:41.09 | seanbright | i used externalivr as my test when i initially wrote the patch |
| 18:42.10 | seanbright | there are two paths out of ast_tcptls_client_create() - either we fail and close the fds, or we succeed and return the ast_tcptls_session_instance |
| 18:42.36 | seanbright | the last time we can fail in that function is this line https://github.com/asterisk/asterisk/blob/master/main/tcptls.c#L671 |
| 18:43.16 | seanbright | and then we return tcptls_session with is an ao2 object which has an iostream in it |
| 18:44.12 | seanbright | any failure in ast_tcptls_client_start goes to the client_start_error label which decrements the ref on the ast_tcptls_session_instance |
| 18:44.39 | seanbright | which fires its destructor and the iostreams's destructor (which closes the fd) |
| 18:44.51 | seanbright | i ran this test: |
| 18:45.05 | seanbright | same => n,ExternalIVR(ivr://google.com:4567) |
| 18:45.20 | seanbright | it tried the IPv4 address and the IPv6 address, failing both times |
| 18:45.33 | seanbright | and there were not fds still open by asterisk afterwards |
| 18:45.55 | seanbright | (plus i added some logging to show when things were being destroyed/closed) |
| 18:46.08 | seanbright | gtjoseph: ^^^ |
| 18:47.19 | gtjoseph | looks again |
| 18:52.29 | seanbright | it's admittedly subtle |
| 18:52.35 | seanbright | and the client API is awful |
| 18:55.12 | gtjoseph | yeah no kidding. I see it now. We're relying on the caller of start to know to NOT use the session that was passed in because styart could have released the last ref. |
| 18:55.56 | gtjoseph | oy. |
| 18:56.12 | seanbright | no, start will return NULL |
| 18:56.15 | seanbright | well, wait |
| 18:56.38 | gtjoseph | start unreffs the passed in session on error then returns null. |
| 18:57.04 | seanbright | yes |
| 18:57.19 | gtjoseph | handle_tcptls_connection also unreffs it. hmmm. |
| 18:57.51 | seanbright | on failure, yes |
| 18:58.03 | seanbright | but then it won't hit the deref in start |
| 18:58.19 | gtjoseph | right |
| 18:59.24 | gtjoseph | could you at least add a comment in tcptls.h that start will unreff the session and return NULL to make sure a caller knows to not call anything on session again? |
| 18:59.38 | gtjoseph | it's not part of your change I know |
| 18:59.43 | gtjoseph | but it would help. |
| 18:59.49 | file | need a "this is fine" gif in here |
| 19:00.04 | gtjoseph | What is fine? |
| 19:00.21 | file | the API |
| 19:00.21 | file | :P |
| 19:00.22 | file | lawl |
| 19:01.03 | file | ooo I got paid, PARTY TIME! |
| 19:01.58 | gtjoseph | sorry. the smoke has turned my brain to mush |
| 19:04.59 | gtjoseph | Friday night party in Moncton. What does that involve? |
| 19:05.28 | file | putting money away for income taxes and sales taxes |
| 19:05.30 | file | that's what. |
| 19:05.50 | gtjoseph | An accountant's dream destination. |
| 19:38.18 | seanbright | wait |
| 19:38.26 | seanbright | * \brief Attempts to connect and start tcptls session, on error the tcptls_session's |
| 19:38.31 | seanbright | * ref count is decremented, fd and file are closed, and NULL is returned. |
| 19:38.45 | seanbright | it literally already says that |
| 19:38.57 | seanbright | gtjoseph: |
| 19:39.30 | gtjoseph | yeah yeah. comments are in blue in eclipse and i just missed them :) |
| 19:39.37 | gtjoseph | good to go then |
| 19:40.23 | gtjoseph | +1'd |
| 19:40.34 | seanbright | resplendid |
| 19:40.57 | seanbright | we should comment on that API that it shouldn't be used |
| 19:41.06 | seanbright | can we deprecate an API? |
| 19:56.40 | *** join/#asterisk-dev zerohalo (sid288136@gateway/web/irccloud.com/x-krdvioiecpdshvcm) |
| 19:57.32 | *** join/#asterisk-dev tuxd00d (sid401305@gateway/web/irccloud.com/x-lzxumjrilmfuwgmz) |
| 20:16.12 | kharwell | seanbright: like an Asterisk api function? Could use \deprecated <blah> in the API function comment |
| 20:17.12 | seanbright | kharwell: awesome. thanks. |
| 20:18.41 | kharwell | actually running across that in something I'm working on atm too. gotta deprecate a call essentially. |
| 20:55.48 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |