| 00:20.21 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:20.21 | *** 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:55.21 | *** join/#asterisk-dev tuxd00d_ (~tuxd00d@ip68-106-11-138.ph.ph.cox.net) |
| 06:49.38 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:50.55 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:54.31 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 06:59.20 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 06:59.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:59.41 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:26.17 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:04.54 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.41) |
| 10:38.02 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 11:26.09 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:26.43 | tsearle | ast_sip_push_task is asyncronous correct? |
| 12:27.08 | tsearle | I mean if I push a task with a session as data, I need to bump the reference count of session & decrement it in the task right? |
| 12:29.15 | file | yes |
| 12:30.03 | tsearle | cool! I'm learning :-D |
| 12:54.18 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-183-170.dialup.adsl.anteldata.net.uy) |
| 12:57.30 | *** join/#asterisk-dev DivideBy0x0 (~DivideBy0@unaffiliated/divideby0x0) |
| 12:57.30 | *** mode/#asterisk-dev [+o DivideBy0x0] by ChanServ |
| 13:43.49 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-ubeeuddovtpkrcyy) |
| 13:43.49 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:48.35 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:48.35 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:58.02 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-lapcfzujaqrkkuup) |
| 13:58.02 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:14.40 | *** join/#asterisk-dev sh_smith (foobar@cpe-76-174-26-91.socal.res.rr.com) |
| 14:32.09 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-gsuzhrnhpjjpctye) |
| 14:32.09 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:44.53 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-100-145.dialup.adsl.anteldata.net.uy) |
| 15:51.34 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:51.34 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:59.15 | *** join/#asterisk-dev mixaz (~mixa@82.208.100.167) |
| 16:02.50 | mixaz | hi all, could you please point me to source code of a GSM gate for asterisk, if any? What to read / look at in the source code of asterisk, may be there are any related samples? Thanks in advance! |
| 16:03.27 | file | GSM gate? |
| 16:03.44 | mixaz | yes |
| 16:04.03 | file | can you clarify what that is? do you mean a GSM gateway? |
| 16:04.12 | mixaz | yes, gateway |
| 16:06.53 | mixaz | I heard openvox.cn uses Asterisk in their GSM gateways, probably I can try to look there. Just looking for other options, may be there is something better to look at |
| 16:07.36 | file | there is nothing included with Asterisk itself, so you'd need to look elsewhere - unless someone in here knows of outside code |
| 16:08.05 | mixaz | OK, I see, thanks for the info |
| 16:29.30 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a06:a402:100:0:dc58:f509:767d:2783) |
| 17:50.55 | *** join/#asterisk-dev danjenkins (danjenkins@gateway/shell/firrre/x-jwqorccfxjtjkrqi) |
| 17:50.55 | *** mode/#asterisk-dev [+o danjenkins] by ChanServ |
| 17:58.43 | *** join/#asterisk-dev oej (~oej@h-205-12.A165.corp.bahnhof.se) |
| 17:58.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:11.46 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 18:11.46 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 18:33.34 | rmudgett | gtjoseph: ping |
| 18:34.09 | gtjoseph | Hey. Was looking at Ross's deadlocks/crash in ast_rtp_codecs_payload_code |
| 18:34.13 | gtjoseph | over the weekend |
| 18:35.02 | gtjoseph | I gave him a patch that keeps references to the instances in the frame hook data as you suggested and it worked, but... |
| 18:35.42 | rmudgett | Frame hook data? I was thinking of the bridge_native_rtp technology |
| 18:35.45 | gtjoseph | why not just unref any existing reference in ast_rtp_instance_set_bridged and bump the new onbe? |
| 18:35.58 | gtjoseph | yeah but the native bridge has no internal structure now |
| 18:36.06 | gtjoseph | but the frame hook does |
| 18:37.15 | gtjoseph | anyway it'd seem to be better to bump the reference when calling ast_rtp_instance_set_bridged |
| 18:37.15 | rmudgett | The struct ast_rtp_instance.bridged does not hold a ref to the bridged instance. If it did there would be a circular reference. |
| 18:38.47 | gtjoseph | no, it doesn't now but it could. |
| 18:39.54 | rmudgett | Yes it could be made to. It would rely on an external means of breaking the circular reference. |
| 18:40.29 | gtjoseph | yeah like ast_rtp_instance_set_bridged with NULL whicxh is what bridge_native does |
| 18:40.43 | gtjoseph | in native_rtp_bridge_stop |
| 18:41.18 | rmudgett | Right but the native rtp bridge relies on finding the rtp instances which seems to be failing occasionally when a channel leaves. |
| 18:42.43 | rmudgett | That's why I was thinking the native rtp bridge tech would need to keep the instance pointers itself. |
| 18:42.55 | gtjoseph | ok. well that's what i did and it's working |
| 18:43.06 | gtjoseph | now i understand a little more about what you meant |
| 18:43.23 | gtjoseph | You meant that native_rtp_bridge_get wasn't always working. |
| 18:43.26 | gtjoseph | yes? |
| 18:44.48 | rmudgett | yes that is the function that tries to get the instance pointers. |
| 18:45.03 | gtjoseph | Ok, now your comments are a little clearer |
| 18:51.24 | rmudgett | gtjoseph: Which channel instance pointer are you putting on the frame hook? You'll need to be able to put the audio and video (or more for master) there. |
| 18:52.23 | rmudgett | Depending upon how you did it you might still have problems because the hook has a slightly different lifetime than the rtp bridge links. |
| 18:52.43 | gtjoseph | i was calling glue->get_rtp_info just for audio for the test |
| 18:53.06 | gtjoseph | but that's what native_rtp_bridge_get does and if yo think that's what's failing then... |
| 18:53.13 | gtjoseph | hmmmm. |
| 18:53.40 | gtjoseph | the difference is that the frame hook gets added on a channel by channel basis |
| 18:57.03 | rmudgett | You could give the bridge tech a private data struct that holds a vector of all rtp instances that are bridged. When native_rtp_bridge_start is called it puts all of the found instances in the vector with a ref. When native_rtp_bridge_stop is called it unbridges all the instances in the vector as well as emptying the vector. |
| 18:57.47 | file | that'd be saner |
| 18:58.25 | gtjoseph | yeah that was my first thought BUT rmudgett if you think native_rtp_bridge_get wasn't returning the proper instances, that this won't work. |
| 18:59.50 | gtjoseph | the other odd part is that the final reference to any rtp instance should not have been released until timer_b expires. |
| 19:00.08 | rmudgett | It doesn't seem to be getting all the instance pointers on stop. On start it seems to get them or we'd see evidence of crashing when the bridge gets started not on hangup. |
| 19:02.20 | rmudgett | We could also put some safety in the start to ensure that we only link pairs when we have a pair. |
| 19:02.28 | gtjoseph | we do |
| 19:02.47 | gtjoseph | if there's only 1 channiel in bridhes->channels we simply return |
| 19:02.52 | gtjoseph | same for stop |
| 19:05.03 | gtjoseph | another little question... on join we add the framehook to the channels then call start but on leave we remove the framehook before calling stop |
| 19:05.33 | rmudgett | We are assuming that if the channels are in the bridge we will get the instance pointers. That doesn't seem to be true. |
| 19:06.03 | rmudgett | At least for when a channel leaves. |
| 19:06.22 | gtjoseph | well, we're getting the pointers. it's just that the rtp instance isn't bumped or locked. |
| 19:07.57 | rmudgett | The instance is locked when the bridged pointer is set. Also both channel locks are held when we call ast_rtp_instance_set_bridged() |
| 19:09.02 | gtjoseph | ok so this is what you said on the issue: "What I suspect is happening is when a channel leaves the native rtp bridge it cannot find the rtp instance of one of the channels and thus cannot clear the bridged with pointer for that channel." |
| 19:09.28 | gtjoseph | there is no "bridged with" pointer on channel. Did you mean rtp_instance->briodged? |
| 19:09.39 | rmudgett | Yes |
| 19:12.01 | rmudgett | The instance->bridged pointer is directly involved with the crash since it is pointing to a destroyed instance. |
| 19:12.10 | gtjoseph | ok. so what looks it like happened was that the last reference on the rtp instance was released somewhere and the "bridged" pointer wasn't cleared in the other instance, so when we got a frame we tried to send it to an already destroyed instance |
| 19:12.17 | cresl1n | Sorry to interrupt you guys, but does anybody have any thoughts on https://gerrit.asterisk.org/#/c/5751/ |
| 19:12.43 | gtjoseph | ok, so this has nothing to do with native_rtp_bridge_get not getting "all the instances" |
| 19:13.20 | gtjoseph | it got them, it's just that one was already destroyed. |
| 19:13.34 | file | cresl1n: it found another test that needed to be updated and they updated their test review? |
| 19:13.40 | cresl1n | is it just waiting on https://gerrit.asterisk.org/#/c/5756/3 |
| 19:13.41 | cresl1n | yeah |
| 19:13.51 | rmudgett | gtjoseph: Yes it does. When the stop happens and it cannot find the instance it cannot clear the instance->bridged poiinters. |
| 19:13.54 | cresl1n | file: so do we just need to merge the test review now? |
| 19:14.18 | file | it needs to be reviewed and tested with the change manually |
| 19:14.22 | file | then they can be merged |
| 19:14.31 | cresl1n | or rather, assuming the test change is right, that should resolve the gating issues with the other reviews? |
| 19:14.36 | file | yes |
| 19:14.37 | cresl1n | ok |
| 19:14.38 | cresl1n | cool |
| 19:14.40 | cresl1n | thanks :-) |
| 19:15.00 | cresl1n | Sometimes I like to mine through the oldest reviews |
| 19:15.13 | cresl1n | but sometimes I find myself walking into a minefiled |
| 19:15.17 | cresl1n | minefield |
| 19:15.54 | file | needs more cowbell |
| 19:15.58 | cresl1n | no kidding |
| 19:17.18 | rmudgett | gtjoseph: native_rtp_bridge_stop must clear all instance->bridged pointer set by native_rtp_bridge_start. To do that it cannot rely on finding the instance pointers again since they aren't always found again. |
| 19:17.41 | gtjoseph | yeah |
| 19:17.57 | gtjoseph | buy why |
| 19:18.15 | gtjoseph | that's the big question |
| 19:20.41 | rmudgett | Not necessarily because the native rtp bridge tech has an interest in the rtp instances it should have its own ref anyway. |
| 19:21.58 | gtjoseph | yeah agreed. i'm still trying to figure out how the last reference to the instance is getting released before timer_b though. |
| 19:22.08 | gtjoseph | maybe it doesn't matter |
| 19:23.10 | rmudgett | Fixing this may help explain that. :) |
| 19:23.34 | gtjoseph | maybe. chan_pjsip_get_rtp_peer already bumps the instance before it returns. |
| 19:24.59 | gtjoseph | i wonder if something is causing a AST_RTP_GLUE_RESULT_FORBID when it shouldn't |
| 19:25.53 | gtjoseph | well, i'll look at it more tonight. |
| 19:39.31 | *** join/#asterisk-dev mixaz (~mixa@93-120-211-139.dynamic.mts-nn.ru) |
| 20:35.26 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 20:35.26 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:37.20 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 20:44.44 | file | gtjoseph: https://jenkins2.asterisk.org/job/gate-ast-14-sip/115/ |
| 20:45.21 | gtjoseph | hmmm |
| 20:46.01 | gtjoseph | that makes no sense. |
| 21:01.51 | file | failures galore |
| 21:11.21 | gtjoseph | how do you define "galore"??? |
| 21:12.09 | file | gtjoseph: when we manually have to submit a decent percentage of reviews... I consider that enough of a galore to be a problem |
| 21:12.20 | gtjoseph | 2? |
| 21:12.25 | gtjoseph | or did you do some? |
| 21:12.31 | file | I did 3 |
| 21:12.34 | gtjoseph | ah |
| 21:12.43 | gtjoseph | i only saw 2 |
| 22:02.45 | cresl1n | waves |
| 23:29.30 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-lapcfzujaqrkkuup) |
| 23:31.55 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-cpkkpcigljdqruut) |
| 23:31.55 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 23:45.36 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 23:45.36 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |