| 01:02.53 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 01:02.53 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 01:09.53 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 01:09.53 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:52.57 | *** join/#asterisk-dev newtonr (~newtonr@173-18-148-28.client.mchsi.com) |
| 01:52.57 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 02:14.35 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 02:14.36 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 02:27.22 | *** part/#asterisk-dev newtonr (~newtonr@173-18-148-28.client.mchsi.com) |
| 02:32.55 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:32.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:56.47 | mjordan | elguero: whoops :-) |
| 02:56.54 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 02:56.54 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:33.24 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:33.24 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:42.55 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 04:42.56 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 05:26.58 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 05:26.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:38.24 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 06:14.31 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 06:47.06 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1003) |
| 06:47.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:51.46 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 07:09.36 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:7da1:ffbf:6ffa:79ff) |
| 07:09.42 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 07:09.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:16.09 | *** join/#asterisk-dev bulkorok (~bulkorok@217.110.197.225) |
| 09:17.34 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:17.34 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:14.57 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 10:14.59 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:49.49 | *** join/#asterisk-dev spditner (~simon@206-248-134-101.dsl.teksavvy.com) |
| 12:05.11 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 12:05.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:19.31 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 12:19.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:04.50 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fqkqasgaceyagzfb) |
| 13:04.50 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:11.57 | *** join/#asterisk-dev luckman212 (~irc@2001:470:8abb:0:8c4c:ca87:2fc8:2a46) |
| 13:19.21 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 13:27.52 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 13:27.52 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:30.25 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-zhigtprspeymevqp) |
| 13:34.02 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 13:56.11 | acidfoo | erm, I feel like I don't completely understand under what circumstance the callback (struct ast_rtp_glue) update_peer |
| 13:56.46 | acidfoo | (asterisk 1.8.13..) |
| 13:58.41 | mjordan | acidfoo: are you asking when it gets called? |
| 14:00.16 | acidfoo | well, i'm digging in the code, I'm still unable to formulate a clear question at this point ;) |
| 14:00.28 | acidfoo | but yeah, I don't completely understand when it is called |
| 14:02.03 | acidfoo | mjordan, ah, I just realized that my sentece was short and missed a couple of words :) |
| 14:02.09 | mjordan | right. So ast_rtp_glue is a table of callback functions that the rtp_engine can use to get information about the channel that an RTP session is associated with, or to inform the channel that something has changed in the RTP session |
| 14:02.12 | mjordan | np :-) |
| 14:02.38 | mjordan | update_peer gets called when something about the remote destination that the channel should send information to has changed |
| 14:02.39 | acidfoo | yeah, I'm trying to use it to do direct RTP |
| 14:05.03 | mjordan | so, for example, when you have a direct RTP bridge, and one of the peers puts the session on hold, update_peer gets called to tell the channel that there's no one to send information to right now |
| 14:05.25 | mjordan | later when the call is taken off hold, update_peer gets called again with the remote destination information |
| 14:08.27 | acidfoo | ok |
| 14:08.35 | acidfoo | and now I have a clear question I think ;) |
| 14:08.44 | acidfoo | when I establish a call, the update_peer is called twice |
| 14:09.20 | acidfoo | the first time, the rtp remote address is set to NULL because I juste created the rtp object |
| 14:09.43 | acidfoo | both phone then send to the channel their ip/port info for RTP |
| 14:09.52 | acidfoo | then both phone send their first RTP packet |
| 14:10.01 | acidfoo | than the update_peer is called because the information has changed |
| 14:10.16 | acidfoo | it was NULL and now the remote rtp information is set to something |
| 14:10.22 | mjordan | yup |
| 14:10.34 | mjordan | are you in a remote_bridge_loop, or a local_bridge_loop? |
| 14:10.45 | acidfoo | remote |
| 14:10.48 | mjordan | hm |
| 14:11.02 | acidfoo | well, I guess since I return AST_RTP_GLUE_RESULT_REMOTE |
| 14:12.21 | acidfoo | http://pastebin.com/MkHeSuV7 |
| 14:12.38 | acidfoo | line 17, update_peer is called |
| 14:12.43 | acidfoo | hence my callback that point to it |
| 14:12.52 | acidfoo | and then line 29 |
| 14:14.16 | mjordan | that's what I would expect |
| 14:14.44 | acidfoo | I'm trying to understand under what circumstance does the update_peer is called the first time |
| 14:14.46 | acidfoo | I mean |
| 14:14.55 | acidfoo | what cause it to be called |
| 14:15.07 | acidfoo | because if I don't start the rtp... update_peer is never called |
| 14:17.03 | mjordan | Its called at the beginning of the remote_bridge_loop before the loop begins and RTP packets are processed. Keep in mind that the remote bridge loop is a bit different then the local bridge loop, as it attempts to move the RTP stream between devices if at all possible (directmedia) |
| 14:17.25 | mjordan | If you want the media stream to stay with Asterisk in the middle, where it swaps the RTP packets between the peers, you want the local bridge loop |
| 14:17.54 | mjordan | I suspect the reason why its called at the beginning is to sanity check whether or not the two remote peers have a chance in hell of talking to each other, but I'd have to look into it further |
| 14:18.06 | acidfoo | ok |
| 14:18.13 | acidfoo | but yeah, I want to do direct rtp |
| 14:18.29 | acidfoo | ok, well, if it's the normal behavior then good |
| 14:18.56 | acidfoo | I was thinking that I could achieve something better than sending one rtp packet to the Asterisk server |
| 14:19.04 | acidfoo | before update_peer get called again |
| 14:19.30 | acidfoo | and then now I can give the phone the right address/port of the endpoint to which directly send the rtp stream |
| 14:19.51 | acidfoo | and then to give * |
| 14:20.24 | mjordan | ah. I suspect this is actually more in place to 'help' chan_sip. update_peer will cause a re-INVITE to be sent out in certain circumstances to get the media streams directed between the remote end points. That would be called at the beginning of the remote bridge loop to try to get the peers to start sending RTP between each other. |
| 14:21.14 | acidfoo | ah ok |
| 14:21.36 | mjordan | acidfoo: potentially yes - if you had the addresses prior to the remote_bridge_loop starting such that the information is set on entering the remote_bridge_loop, then the second update would never occur |
| 14:22.03 | acidfoo | I'll try to see if I could refactor my code so I get these informations earlier |
| 14:22.25 | acidfoo | mjordan, thank you for the informations |
| 14:49.09 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:49.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:49.34 | acidfoo | erm |
| 14:50.39 | acidfoo | mjordan, I think that the ptr callback "get_rtp_info" is called to early by rtp_engin.c:ast_rtp_instance_bridge() for me to be able to have the ip/port of the device earlier enough |
| 14:50.49 | acidfoo | too early* |
| 14:52.25 | acidfoo | I would need to block in the .call callback (struct ast_channel_tech) and wait for the phone to tell me what ip/port he will accept RTP on |
| 14:52.29 | acidfoo | and then return |
| 14:52.39 | acidfoo | because just after I return, the bridging mechanism start |
| 14:52.49 | acidfoo | and call a function that ask me info about the rtp |
| 14:53.10 | acidfoo | in which I need to return ...GLUE_RESULT_LOCAL or _REMOTE |
| 14:53.15 | acidfoo | and set *instance to my rtp instance |
| 14:53.33 | acidfoo | oh well, no big deal, i'll just use the way it work with update_peer being called twice |
| 15:31.12 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:31.22 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:45.39 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-akslmafdtpxvkyay) |
| 15:55.32 | *** join/#asterisk-dev luckman212_ (~irc@2001:470:8abb:0:8c4c:ca87:2fc8:2a46) |
| 17:11.44 | *** join/#asterisk-dev marv (~Adium@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 17:59.08 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 18:03.52 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 18:12.37 | *** join/#asterisk-dev luckman212_phone (~luckman21@166.137.87.67) |
| 18:36.02 | *** join/#asterisk-dev luckman212 (~irc@2001:470:8abb:0:8c4c:ca87:2fc8:2a46) |
| 18:59.54 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 19:08.51 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 19:08.51 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 19:16.26 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 19:33.28 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 19:44.57 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 19:44.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:50.29 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 20:05.07 | datachomper | seanbright: I have a potential workaround for the "Failed to create channel in timeslot" error you were seeing on the tc400. If you'd like to test it. https://issues.asterisk.org/jira/browse/DAHLIN-268 |
| 20:05.11 | seanbright | heh |
| 20:05.28 | seanbright | was literally typing "does russ meyerriecks hang out in here?" |
| 20:06.14 | seanbright | i would test, but we haven't had that problem in production for some time, so i'm hesitant to roll out a change |
| 20:06.16 | datachomper | I do, indeed |
| 20:06.42 | datachomper | seanbright: I understand. It seems to be a pretty rare issue, but another customer saw it as well and it was a quick patch. |
| 20:06.51 | seanbright | yeah, the patch looks sane |
| 20:07.01 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 20:08.07 | seanbright | i'm doing some server maintenance this weekend (sunday) |
| 20:08.15 | seanbright | i'll roll that out and see what happens |
| 20:08.22 | seanbright | any reason it wouldn't apply cleanly to 2.6.1? |
| 20:09.15 | datachomper | It applies cleanly, just tested it |
| 20:09.30 | seanbright | excellent |
| 20:12.55 | kpfleming | notes that datachomper is not bigdatachomper |
| 20:17.12 | datachomper | kpfleming continues to haunt us from beyond the mason-dixon line |
| 20:17.26 | *** join/#asterisk-dev luckman212 (~irc@2001:470:8abb:0:8c4c:ca87:2fc8:2a46) |
| 20:18.57 | *** join/#asterisk-dev luckman212_ (~irc@2001:470:8abb:0:8c4c:ca87:2fc8:2a46) |
| 20:19.34 | seanbright | he's the #asterisk-dev guardian executive |
| 20:19.48 | kpfleming | i'm still in huntsville, until the beginning of next month |
| 20:21.18 | malcolmd | kpfleming still has an empty hole in his stomach he's trying to fill with chuck wagon before it's too late |
| 20:21.40 | kpfleming | lol |
| 20:21.43 | kpfleming | maybe tomorrow |
| 20:22.20 | malcolmd | be careful up there in pepsi country |
| 20:23.32 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 20:23.51 | putnopvut | malcolmd: seriously, what is it with the Northeast's like of Pepsi? |
| 20:40.33 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 20:41.05 | malcolmd | putnopvut: seriously. pepsi can't hold a candle to this: http://www.youtube.com/watch?v=Nn2swaMcTv8 |
| 20:47.07 | leifmadsen | pepsi ftw |
| 20:56.57 | seanbright | i'm a coke man myself, but i about an hour from the pennsylvania border so i guess i'm technically a southerner |
| 20:57.05 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 20:57.09 | seanbright | or a borderer if you want to be all 1800s about it |
| 21:00.33 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:10.01 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:13.37 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 21:30.08 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 21:46.40 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 22:03.12 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 22:20.05 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 22:24.04 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 22:35.13 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fqkqasgaceyagzfb) |
| 23:35.10 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |