| 03:35.26 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:35.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:59.45 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 05:59.48 | schmidts | good morning |
| 06:04.07 | *** join/#asterisk-dev mpe (~mpe@gate.ipvision.dk) |
| 06:35.09 | *** join/#asterisk-dev Corydon76-home (eight@c-69-137-80-31.hsd1.tn.comcast.net) |
| 06:35.09 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 07:25.51 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:6017:2b0d:dcd4:dea4) |
| 08:11.18 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 09:40.21 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 10:27.53 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 10:27.53 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:07.02 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 11:38.40 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:38.40 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:35.15 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 12:35.15 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 12:55.49 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:55.49 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:14.35 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-wbtcsvddlndnbcjf) |
| 13:14.35 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:25.48 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-rifqicujpctarnsv) |
| 13:29.57 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 13:30.50 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:30.50 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:59.06 | opticron | putnopvut, I've been looking over find_call and I'm still not seeing where dialog creation is prevent if pedantic is on and the incoming request has a to tag, could you point me at that (referring to review 1911) |
| 13:59.19 | opticron | *prevented |
| 13:59.46 | opticron | also, ? |
| 14:01.27 | putnopvut | opticron: okay, let me take the question in for a sec. |
| 14:01.54 | putnopvut | So there are two things that will prevent it. |
| 14:03.21 | putnopvut | So first off, in match_req_to_dialog, if a request has a to-tag, but we haven't allocated a local tag, yet, no dialog will be matched. |
| 14:04.04 | putnopvut | Then, one thing that is checked before allocating a new dialog is if the CAN_CREATE_DIALOG flag is true for the method coming in. ACKs cannot create dialogs, so they won't result in new dialogs being created. |
| 14:07.40 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:07.40 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:08.46 | opticron | putnopvut, ah, I was thinking along the lines of an INVITE |
| 14:09.20 | putnopvut | Ah, INVITE does have the CAN_CREATE_DIALOG attribute. |
| 14:09.25 | opticron | right |
| 14:09.32 | kpfleming | i should hope so |
| 14:10.05 | opticron | so removing that block would allow through initial INVITEs with a to tag when pedantic is on |
| 14:10.57 | opticron | at least, wouldn't catch them there, might get caught somewhere later |
| 14:10.58 | putnopvut | Okay, good observation. |
| 14:11.36 | putnopvut | So, would you agree that the final else block of that removed code could be removed though? Because an ACK should always have a to-tag. |
| 14:12.15 | opticron | that sounds correct |
| 14:17.28 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:49.45 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:06.58 | *** join/#asterisk-dev b3nt_pin (~b3ntpin@142.162.47.99) |
| 15:09.21 | *** join/#asterisk-dev Corydon76-work (pink@c-69-137-80-31.hsd1.tn.comcast.net) |
| 15:09.21 | *** mode/#asterisk-dev [+o Corydon76-work] by ChanServ |
| 15:23.42 | *** join/#asterisk-dev Corydon76-home (blue@c-69-137-80-31.hsd1.tn.comcast.net) |
| 15:23.42 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 15:39.51 | *** join/#asterisk-dev mfa (~mfacerias@AMontpellier-258-1-70-145.w90-48.abo.wanadoo.fr) |
| 15:53.54 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:53.55 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:13.56 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:16.43 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 16:18.56 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:18.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:24.05 | *** part/#asterisk-dev mfa (~mfacerias@AMontpellier-258-1-70-145.w90-48.abo.wanadoo.fr) |
| 16:48.01 | seanbright | sruffell: is that a new card? |
| 16:48.53 | seanbright | hmm, i guess not |
| 16:49.00 | sruffell | no, I guess I just never checked that dahdi_scan worked with it. |
| 16:49.06 | sruffell | I only went so far as making sure dahdi_genconf worked. |
| 17:33.46 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 17:36.36 | anonymouz666 | seanbright: what is broken in chan gtalk/jabber in 1.8? |
| 17:37.43 | file | seanbright != sean darcy |
| 17:37.47 | file | but *a lot* is broken |
| 17:37.56 | anonymouz666 | seanbright: sorry! |
| 17:38.33 | file | the only thing that works some is google voice |
| 17:39.28 | anonymouz666 | file: I have only tested google talk and it worked, that's why I asked what is broken |
| 17:39.51 | file | the Windows Google Talk client sorta works with chan_gtalk |
| 17:40.35 | file | I tried to get the gmail google talk plug-in to work with either and failed miserably |
| 18:00.11 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 18:23.46 | mjordan | file: opticron: about your comment on ConfbridgeExecAction |
| 18:24.07 | mjordan | the more I look at it, the more I think the correct answer actually is to implement a transaction queue on the bridge_channel |
| 18:25.09 | mjordan | having it pull items off the deferred list until the list is empty isn't a great idea, because you have to unlock the bridge_channel every time you go out and call the callback. If that callback puts another item on the deferred list, you're in an endless loop |
| 18:30.09 | opticron | true |
| 18:45.24 | *** join/#asterisk-dev scgm11 (~Sebastian@r186-52-2-57.dialup.adsl.anteldata.net.uy) |
| 18:50.36 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 18:51.03 | *** part/#asterisk-dev scgm11 (~Sebastian@r186-52-2-57.dialup.adsl.anteldata.net.uy) |
| 18:59.59 | file | mjordan: what be you envisioning? |
| 19:02.31 | mjordan | file: a queue of states to change to on a bridge_channel. states of END or HANGUP would go on the front, since anything after those two doesn't matter. |
| 19:02.42 | file | ah, yes |
| 19:03.17 | mjordan | that should resolve the issue opticron noted, and keep anything from getting starved in the presence of numerous deferred callbacks or framehook events |
| 19:14.03 | opticron | that sounds like a good fix to me :) |
| 19:33.05 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 19:33.05 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 20:38.43 | elguero | Working on ASTERISK-19856 and the reporter makes a good point (I think) in regards to the patch I posted... which led me to investigate where allowtransfer in sip_pvt is used... does anyone know whether allowtransfer in sip_pvt is needed? I could only find one place where it was used, the line that the patch tries to correct. Would it make sense to only use the peer's allowtransfer setting and clean up the code by removing allowtransfer |
| 20:38.49 | elguero | from sip_pvt if it is not used anywhere else? Just wondering if I am missing something somewhere. |
| 20:38.54 | elguero | When someone gets a chance... no rush |
| 21:00.48 | opticron | are you talking about removing the allowtransfer setting in the global scope? |
| 21:03.07 | elguero | no, not thinking about removing from global scope |
| 21:05.00 | elguero | I think the global setting should be there for peers that have allowtransfer undefined |
| 21:06.11 | elguero | what I am refering to is that peer->allowtransfer is set according to the global setting... |
| 21:07.06 | elguero | but I could not see where p->allowtransfer was really being used... seems that p->allowtransfer or dialog->allowtransfer was being set according to peer->allowtransfer but then never used anywhere |
| 21:09.13 | elguero | in the case of the issue ASTERISK-19856... where p->allowtransfer was being used, it is not respecting if peer->allowtransfer is defined in the config file |
| 21:09.30 | elguero | hope that clarifies it a bit :) |
| 21:11.00 | elguero | or maybe I misunderstood the question |
| 21:11.07 | opticron | ah, so you're suggesting we drop allowtransfer from sip_pvt and just reference it from relatedpeer since it doesn't change from call to call |
| 21:11.14 | elguero | correct |
| 21:16.42 | kpfleming | but if the peer's configuration is changed and then reload, it should not affect existing calls |
| 21:22.47 | elguero | hmm... that might be the part I was missing... but I could only find it used in one line which wasn't really working anyway becuase it is ignoring the peers setting altogether |
| 21:25.05 | elguero | I might need to dig deeper then and see why p->allowtransfer is not being set to the peer's setting at the time of transfer (I thought I did that but will look again) |
| 22:25.36 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-wbtcsvddlndnbcjf) |
| 22:31.55 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@66-232-81-197.ctcweb.net) |