| 02:23.51 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 02:23.51 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 02:43.19 | *** join/#asterisk-dev Gugge_ (gugge@92.246.2.105) |
| 04:34.24 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-250-191.dhcp.nwtn.ct.charter.com) |
| 04:34.24 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 06:32.27 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 08:32.26 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:37.56 | *** join/#asterisk-dev dark123us (~dark123us@leased-line-195-222-90-57.telecom.by) |
| 08:52.32 | *** join/#asterisk-dev tzafrir (~tzafrir@lemon.tzafrir.org.il) |
| 08:52.32 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:07.28 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 11:28.38 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 13:01.03 | jsmith | Morning.... |
| 13:01.49 | file | moo |
| 13:15.36 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:15.36 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:51.40 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-apdlleeobqgihqvg) |
| 13:51.40 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:11.56 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-lckbfmobbfllztmg) |
| 14:11.56 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:33.56 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ldjjepgrldkrghpv) |
| 14:33.56 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:23.31 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 15:23.31 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 15:34.11 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 15:34.11 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 15:39.31 | *** join/#asterisk-dev scgm11_ (~scgm11@187.192.163.69) |
| 15:40.58 | seanbright | hello |
| 15:41.16 | seanbright | what's the good word? |
| 15:42.55 | kharwell | banana? |
| 15:43.02 | seanbright | that works |
| 16:38.00 | *** join/#asterisk-dev mfr (~schay@2804:14d:bad7:2595:847d:4b30:9228:af52) |
| 17:06.28 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.173) |
| 17:20.52 | rmudgett | file: Re: https://gerrit.asterisk.org/#/c/asterisk/+/10015/ Did the leaking scenario involve INVITE retransmissions which caused us to start T.38 twice? |
| 17:21.39 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:21.39 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 17:23.02 | file | I think that would have also done it, but the one I noticed it in was just a simple T.38 reinvite out and rejected |
| 17:23.59 | file | at least from my brief digging in |
| 17:24.08 | file | once I saw it was state machine related I just opted for the fix I put up |
| 17:24.14 | file | minimizes fax exposure time |
| 17:24.39 | rmudgett | I had earlier tried to see if we could send a 100 trying when the invite came it but it didn't look easy to do it the way the code is structured. |
| 17:25.07 | rmudgett | *came in |
| 17:25.55 | file | yeah, that'd certainly be nice |
| 17:32.43 | kharwell | file: in https://gerrit.asterisk.org/#/c/asterisk/+/9505/ I see a few places now where the tpselector is now being unref'ed. Is that not a problem now? |
| 17:33.10 | file | it requires it now |
| 17:33.28 | file | (I updated that doxygen to specify that new behavior) |
| 17:37.05 | kharwell | which file/function? I'm not seeing it |
| 17:37.36 | kharwell | is pjrpoject I guess doing a final unref on destruction? |
| 17:37.54 | file | res_pjsip.h |
| 17:38.08 | file | line 2982 and 2995 |
| 17:38.17 | file | those populate the tpselector |
| 17:38.29 | file | and sadly not, we have to do it (thus the addition of the unref function) |
| 17:38.39 | file | previously there was a guarantee that they'd continue to exist regardless so no ref bump needed |
| 17:38.50 | file | however with flows the connection can go away, so the ref bump is needed |
| 17:39.25 | kharwell | oh ya I see that is says it needs to be unreffed now. My question is why in some spots is the unref needed now? |
| 17:39.34 | mfr | how i get channel dialing into struct ast_channel *chan ? |
| 17:39.54 | kharwell | file: hrm I mean shouldn't we be unreffing that in current off nominal paths in the code? |
| 17:40.07 | file | outside of my patch, you mean? |
| 17:40.48 | file | if so - then no, the act of populating tpselector does not increase the reference count of the transport |
| 17:40.58 | file | essentially the code assumes that the transport can't/won't go away |
| 17:43.37 | kharwell | a place like "ast_sip_create_dialog_uac" in res_pjsip.c. In your patch if the sip_dialog_create_from fails or just after it you unref the selector. Should we be doing that currently? Like in 13? Seems like the selector would be leaking otherwise? |
| 17:44.23 | file | it doesn't leak because the reference count of the transport is not increased by placing it into the tpselector |
| 17:45.07 | file | the only transport you can place in a tpselector in 13 is also the UDP transport |
| 17:48.18 | kharwell | ah okay I think I see now. I was confused for a second on pjproject's dec/inc of the ref when setting it, but it's just removing/adding a ref that was already there. For flow type an extra ref gets set, so must be removed |
| 17:48.55 | file | with a flow the connection can drop or go away, so you need the ref to be guaranteed it's valid |
| 18:24.04 | rmudgett | file: That fax code is really strange in how it treats the reserved session to create a new session. |
| 18:24.11 | file | rmudgett: yes. |
| 18:24.57 | rmudgett | Think that code was trying to be entered into a competition for worst bad code? |
| 18:25.28 | file | I've seen worse |
| 18:56.35 | mfr | I have a problem with amd. When a hangup occurs in callee side, amd detects it as HANGUP, ok... but asterisk sends 200 ok to the caller before BYE. |
| 18:57.46 | mfr | my idea is to send a hangup on the callee channel |
| 19:05.26 | seanbright | asterisk will send the 200 OK when the call is answered, which should be happening before you call AMD() |
| 19:11.47 | mfr | No. 200 OK comes from the gateway, AMD still analyzing responds as HANGUP status but transfers 200 ok to the extension and then BYE |
| 19:12.19 | scgm11_ | Hi i have a question about DSP detection , Im using ast_dsp_get_tstate(dsp) == DSP_TONE_STATE_RINGING is that related to the values in indications.conf? I think is not I´ve seen some hardcoded data on dsp.c function __ast_dsp_call_progress |
| 19:13.32 | scgm11_ | I can see only MODE_NA, MODE_CR and MODE_UK is that right? |
| 19:14.07 | scgm11_ | I have an issue detecting Ring with some carriers that I think those values may be different |
| 19:33.11 | rmudgett | scgm11_: That tstate does not get its config from indications.conf. The setting is configured with the chan_dahdi.conf progzone option. |
| 19:33.28 | scgm11_ | ok but im using it on sip |
| 19:35.03 | rmudgett | ast_dsp_set_call_progress_zone() sets the locality the dsp is going to look for. |
| 19:35.24 | rmudgett | only chan_dahdi calls that |
| 19:40.26 | scgm11_ | but Im using it on sip |
| 19:40.36 | scgm11_ | and works the call_progress_detection |
| 19:40.55 | scgm11_ | in some carriers and in some not detecting ring |
| 19:41.22 | scgm11_ | I think is about these Hz numbers that are different carrier to carrier |
| 19:48.06 | rmudgett | Then you would need to call ast_dsp_set_call_progress_zone() to setup the zone the dsp code is looking for. |
| 19:48.42 | rmudgett | There are only the three different zones defined in the code. |
| 19:48.46 | scgm11_ | ok thanks I will check on dahdi how to set up |
| 19:49.11 | scgm11_ | yes I saw that I may have to add code to dsp if my setting are note there right? |
| 19:49.20 | rmudgett | yes |
| 19:50.56 | rmudgett | you would need to add another PROG_MODE_xx switch case in the code. |
| 19:59.45 | scgm11_ | one last question if I configure the prog_zone on chan_dahdi I dont need to call ast_dsp_set_call_progress_zone() is that right? |
| 20:35.28 | rmudgett | Since you are writing your own code in chan_sip/chan_pjsip you have to call it for each dsp you setup. chan_dahdi is the only channel driver that currently uses that dsp mode of operation. |
| 21:48.05 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-144-232.dialup.adsl.anteldata.net.uy) |
| 23:20.33 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-lckbfmobbfllztmg) |