| 00:04.45 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-eaamqxapfyrqyozj) |
| 08:09.40 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 08:09.40 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Astricon 2011 in Denver, Colorado: AstriDevCon on October 24. Be there! |
| 08:18.07 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 08:26.40 | *** join/#asterisk-dev irroot (~irroot@196-215-124-168.dynamic.isadsl.co.za) |
| 08:28.13 | irroot | bum connex |
| 08:29.02 | oej | What's up, irroot? |
| 08:35.20 | irroot | im on the beach |
| 08:35.48 | irroot | ok not quite in durban office but the connextion is not so good the network is a mess |
| 08:42.12 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-153-143.bvtn.or.frontiernet.net) |
| 08:44.47 | *** join/#asterisk-dev irroot (~irroot@196-215-124-168.dynamic.isadsl.co.za) |
| 08:56.36 | oej | I refuse to hear the "on the beach" part. |
| 08:58.03 | oej | Updating all my branches from svn takes time. |
| 11:08.31 | oej | Afternoon folks |
| 11:31.45 | *** join/#asterisk-dev irroot (~irroot@41.221.5.170) |
| 11:35.52 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:35.52 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:37.31 | oej | Good morning, kpfleming! |
| 11:37.37 | oej | Another nice day in Internet-space |
| 11:39.04 | kpfleming | it seems that way... short day for me, traveling to Ohio LinuxFest this evening |
| 11:41.28 | oej | Nice. I envy you. I really need something like that. |
| 11:45.02 | kpfleming | short trip... heading up there tonight and back very early sunday morning |
| 11:45.10 | kpfleming | but it will give me some flying time to catch up on reading |
| 11:47.38 | oej | mmm. Always stuff to go through, right. |
| 11:48.13 | oej | Bria doesn't support ice properly. No a=rtcp header |
| 11:53.17 | *** join/#asterisk-dev luckman212 (~irc@2001:470:1f07:1225:ec3d:ac06:21a2:ec00) |
| 11:54.40 | jsmith | kpfleming: Oh, you're coming to OLF? Awesome! |
| 11:54.47 | kpfleming | yes... only for saturday though |
| 11:55.24 | kpfleming | i am listed on the speaker schedule, after all, so i assume i should be there |
| 11:57.29 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 12:01.41 | oej | kpfleming: That's usually an indication. |
| 12:05.03 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 12:05.22 | jmls | is there any way of getting sip debug on a peer only ? |
| 12:05.26 | *** join/#asterisk-dev DocAwesome (~DocAwesom@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:05.26 | *** mode/#asterisk-dev [+o DocAwesome] by ChanServ |
| 12:08.09 | leifmadsen | jmls: sip set debug peer <foo> ? |
| 12:08.12 | leifmadsen | is that what you mean? |
| 12:08.34 | jmls | ah. was trying sip debug peer .. ;) |
| 12:16.18 | oej | Watching too much futurama might be dangerous to your health, kpfleming |
| 12:18.18 | kpfleming | oej: yes, indeed |
| 12:19.25 | *** join/#asterisk-dev DocAwesome (~DocAwesom@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:19.25 | *** mode/#asterisk-dev [+o DocAwesome] by ChanServ |
| 12:21.41 | kpfleming | and now i go from watching futurama to reading Linux Weekly News. |
| 12:30.46 | acidfoo | into linkedlist.h: (both asterisk 1.4.42 and 1.8.6.0) there is an example of "ST_LIST_TRAVERSE_SAFE_BEGIN(&entries, current, list) {" but the macro already include the opening bracket "{" |
| 12:36.24 | acidfoo | yes, no, toaster ? |
| 12:37.19 | kpfleming | what was the question? |
| 12:38.06 | acidfoo | either the usage case is wrong, or the macro is wrong for #define AST_LIST_TRAVERSE_SAFE_BEGIN(head, var, field) { \ |
| 12:38.15 | acidfoo | into include/asterisk/linkedlists.h |
| 12:38.28 | kpfleming | 'in', not 'into' :-) |
| 12:39.01 | acidfoo | :) |
| 12:39.07 | kpfleming | no, it's fine |
| 12:39.24 | kpfleming | the macros include braces, and the example has a second set of braces |
| 12:39.35 | acidfoo | but the macro doesn't close his own brace ? |
| 12:39.42 | kpfleming | no, it can't |
| 12:39.48 | kpfleming | that was AST_LIST_TRAVERSE_SAFE_END is for |
| 12:39.59 | kpfleming | s/that was/that's what/ |
| 12:40.19 | irroot | any objections to commiting the SRTP authtag length setting ?? https://reviewboard.asterisk.org/r/1173/ |
| 12:40.22 | acidfoo | ah ! |
| 12:40.32 | acidfoo | good |
| 12:40.40 | acidfoo | thank you, I was searching for the missing } :) |
| 12:40.49 | schmidts | acidfoo but lists are slow better use ao2 containers instead :P |
| 12:40.52 | kpfleming | acidfoo: just read farther into the example |
| 12:41.07 | irroot | it uses the taglen in the invite and allows choosing between 32/80 |
| 12:41.09 | acidfoo | kpfleming, yeah, just woke up, sorry ;) |
| 12:41.47 | kpfleming | acidfoo: i'm only about an hour ahead of you on that front |
| 13:00.57 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-rrgfkyirrkoazopm) |
| 13:00.57 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:05.08 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-lrmlohvmjrsizoxj) |
| 13:31.51 | *** join/#asterisk-dev Fritz09 (~Adium@pop1-3620.catv.wtnet.de) |
| 13:36.23 | pabelanger | mjordan: ping |
| 13:41.15 | mjordan | pabelanger: pong |
| 13:42.33 | pabelanger | mjordan: I'm not sure disabling the reactor timeout is a good idea, otherwise a test can run forever. |
| 13:42.58 | mjordan | yeah, I'm not convinced that its a good idea either. |
| 13:43.13 | mjordan | On the other hand, the test run time bounds appear to be... unknown |
| 13:43.21 | pabelanger | In the past, this caused bamboo to hang until somebody manually stopped the test |
| 13:43.35 | pabelanger | Ya |
| 13:43.48 | mjordan | I'm hoping to get some measurements on how long bamboo will spin on that test |
| 13:43.59 | mjordan | because it's at least 3x what it takes locally |
| 13:44.11 | russellb | the test results XML file includes the time each test runs |
| 13:44.18 | russellb | and that should be reflected in the bamboo interface |
| 13:44.36 | mjordan | russellb: yup, but when the test prematurely gets stopped, you don't know how long it needed to run to finish properly |
| 13:44.40 | pabelanger | So, maybe it is time we implemented a way to update the reactor timeout when a test is running |
| 13:44.50 | russellb | mjordan: ah yes, indeed. |
| 13:44.59 | russellb | anyway, just throwing some relevant info out there, carry on :-) |
| 13:45.03 | mjordan | I've extrapolated this one test twice, and been wrong twice :-) |
| 13:45.06 | mjordan | np :-P |
| 13:45.32 | mjordan | pabelanger: except that you don't really know for sure when that timeout happens if you have timed out, or if the test is just taking awhile |
| 13:46.14 | mjordan | the timeout happens in the base class - you could have an overridable method in derived classes to call and ask "hey, are you stuck?" - but that seems fairly complex for what we're really trying to do |
| 13:47.15 | mjordan | pabelanger: on another note, one of those tests did actually *fail* - is there anyway to get the Asterisk log off of the Ubuntu Lucid run? |
| 13:47.51 | pabelanger | Right, so what I am suggesting is rather a global 30 seconds for a test to run, we dynamically increment the timer for each step of the test we run. EG: If we originate a call for 30seconds, then the reactor timeout must be 30 + n seconds before getting called. |
| 13:48.03 | pabelanger | no |
| 13:48.10 | mjordan | the base class probably doesn't have that information |
| 13:48.15 | pabelanger | We need to add the logic |
| 13:48.18 | pabelanger | we can do that today |
| 13:48.35 | mjordan | once you've scheduled the twisted callback, it's scheduled - I don't think there's a way to modify the timer |
| 13:49.03 | mjordan | what is deleting the log files? |
| 13:49.38 | pabelanger | bamboo |
| 13:50.00 | pabelanger | we need to add logic to move them into artifacts directory |
| 13:50.02 | mjordan | is there a way to turn that off for a few runs? |
| 13:50.35 | pabelanger | I can check |
| 13:52.09 | pabelanger | mjordan: reactor.cancelCallLater(); self.timeout += 25; reactor.callLater() _should_ work |
| 13:52.42 | pabelanger | just looking at the documentation for it, but have not tested it |
| 13:53.58 | mjordan | pabelanger: hm. That might work. We could just add a method to TestCase called "reschedule", and have the derived classes be responsible for incrementing the timeout |
| 13:54.05 | mjordan | Since they have the knowledge as to how far in the test they are |
| 13:55.50 | pabelanger | Yar, that is what I am thinking too. When we make it to checkpoint A in the test, and we know it takes 15secs to play an audio prompt for voicemail, reschedule the reactor for 15 + 1 seconds more, ???, profit |
| 13:55.57 | mjordan | sure |
| 13:56.01 | mjordan | I'll put that in and test |
| 13:56.06 | mjordan | sounds like the best option |
| 13:56.21 | mjordan | I'd like to still get some idea as to how long these things can take, max, on bamboo |
| 13:56.36 | mjordan | because right now, the playback of the files is taking a *lot* longer than their actual audio length |
| 13:56.59 | pabelanger | Hmmm |
| 13:57.18 | mjordan | its not just the playback, that's just an example |
| 13:57.52 | mjordan | it's probably just having to do a lot of process / thread switching, and its causing it to run gawdawful slow |
| 13:58.04 | pabelanger | I've seen that problem before, if I remember right, Asterisk was not actually playing the audio to the channel... something was causing it to fail |
| 13:58.12 | mjordan | nah, I'm getting the RTP packets |
| 13:58.17 | pabelanger | k |
| 14:00.48 | kpfleming | mjordan: they don't run "on bamboo". they run on various systems that fill the role of bamboo remote agents. |
| 14:01.38 | mjordan | kpfleming: yeah, in this context I was using 'bamboo' to mean the 'test system', which isn't correct |
| 14:01.59 | kpfleming | and we have a variety of test systems, with very different behaviors |
| 14:02.04 | kpfleming | so that could be a hard thing to quantify |
| 14:03.30 | mjordan | well, since our tests have a timed automatic failure built into them, we need *some* maximum bound. I think pabelanger's idea of increasing the timeout as you move through the test will help, but you could still run into problems where the increment isn't large enough for a given test step |
| 14:03.49 | mjordan | we'll just have to take the risk that the maximum bound may not be enough in some cases :-\ |
| 14:04.13 | pabelanger | right, we can create an absolute timeout |
| 14:09.39 | oej | Have a nice weekend, friends! Good flight, kpfleming! |
| 14:10.52 | kpfleming | oej: thanks |
| 14:17.34 | anonymouz666 | oej: how are working the pinana-publish? |
| 14:18.37 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:18.37 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:20.06 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 14:31.12 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:31.12 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:35.22 | *** join/#asterisk-dev moy_ (~moy@173.239.155.74) |
| 14:38.57 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-pqyctpefonoehuyg) |
| 14:39.11 | datachomper | tzafrir: +1 dahdi_maint fix |
| 14:39.12 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 14:46.17 | luckman212 | does res_musiconhold REQUIRE res_timing_pthread ? anybody know? |
| 14:47.47 | kpfleming | no |
| 14:47.56 | kpfleming | that wouldn't make any sense at all |
| 14:49.20 | luckman212 | I was looking at the source in res_musiconhold.c and I see a lot of things like "ast_pthread_create_background" |
| 14:49.42 | kpfleming | that is for thread creation |
| 14:49.47 | kpfleming | it has nothing at all to do with timing |
| 14:50.19 | luckman212 | ah. ok yes that makes sense |
| 14:51.05 | luckman212 | I'm trying to figure out https://issues.asterisk.org/jira/browse/ASTERISK-17474 |
| 14:51.08 | DocAwesome | [ASTERISK-17474] [Status: Open] when using mpg123 as a streaming MOH source, issuing 'moh reload' from CLI causes stream to die - https://issues.asterisk.org/jira/browse/ASTERISK-17474 |
| 15:06.32 | luckman212 | it's a doozy |
| 15:13.38 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:16.12 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 15:16.12 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 15:48.00 | *** join/#asterisk-dev fhirschberg (~fhirschbe@dslc-082-082-244-141.pools.arcor-ip.net) |
| 15:48.11 | fhirschberg | Hi! |
| 15:48.31 | fhirschberg | I've got a question, maybe anybody here can help me... |
| 15:49.27 | fhirschberg | I need a feature for asterisk that i would like to implement when not already there... But I don't know where to start. |
| 15:51.03 | fhirschberg | What I need is called "split ear" mode. It's is used in radio communications. You can have 2 audio streams on each ear. |
| 15:51.48 | fhirschberg | One stream per ear was what I meant |
| 15:51.53 | fhirschberg | sorry |
| 15:52.56 | datachomper | maybe try app_jack and use the audio processors to split up the left and right channels? |
| 15:53.32 | fhirschberg | Ah, that sounds interesting! Thanks for this hint |
| 15:53.36 | kpfleming | you just need to open two console channels to two audio devices, which happen to be the left and right channels of the same physical device |
| 15:53.52 | kpfleming | whatever method you choose, you need to use two channels in asterisk, not one |
| 15:54.20 | kpfleming | so if alsa/oss/pulseaudio/etc. will let you open the left/right channels independently, then using chan_console should make this possible |
| 15:54.24 | fhirschberg | @kpflemin yes, but currently I'm using chan_alsa and that has no possibility to use 2 devices... |
| 15:54.28 | kpfleming | right |
| 15:54.34 | kpfleming | chan_alsa is ancient. use chan_console instead. |
| 15:55.14 | fhirschberg | Ok, will this work on embedded systems? I've forget to mention that I'm working on an ARM platform |
| 15:55.33 | fhirschberg | Of course you're right. I need 2 Channels |
| 15:55.41 | fhirschberg | One for each ear |
| 15:56.21 | kpfleming | yes, chan_console uses portaudio, so you'd need the portaudio libraries available. |
| 15:57.06 | fhirschberg | Very good... I'm relativ new to Asterisk, so I don't know where to start... Thanks for the hints! |
| 15:59.23 | fhirschberg | I've already got already alsa devices for separate channels to the headset. So I will try to combine these with chan_console on monday at work! Thanks for your help! |
| 15:59.36 | fhirschberg | Have a nice weekend! |
| 16:00.49 | *** part/#asterisk-dev fhirschberg (~fhirschbe@dslc-082-082-244-141.pools.arcor-ip.net) |
| 16:10.51 | *** join/#asterisk-dev trelane (trelane@funtoo/staff/trelane) |
| 16:13.46 | *** join/#asterisk-dev fhirschberg (~fhirschbe@dslc-082-082-244-141.pools.arcor-ip.net) |
| 16:13.50 | *** part/#asterisk-dev fhirschberg (~fhirschbe@dslc-082-082-244-141.pools.arcor-ip.net) |
| 16:34.22 | *** join/#asterisk-dev thedavidfactor (~david@nc-76-3-106-212.dhcp.embarqhsd.net) |
| 17:11.07 | luckman212 | can anyone point me in the right direction- I'd like to hack in a feature to Ast1.8 to allow setting a channel variable before an Answer() command that can set the "a=" parameter in the SDP to sendonly, recvonly, or sendrecv |
| 17:31.39 | luckman212 | I need to insert some code to chan_sip.c around line 10981 |
| 17:31.47 | luckman212 | to test for my channel variable |
| 17:31.58 | luckman212 | but I really don't know how to do it ... can anyone help? |
| 17:32.31 | acidfoo | any documentation on the purpose of sched_context_create() and io_context_create() ? |
| 17:39.50 | kpfleming | if it's not in the header files that declare those functions, then it doesn't exist. we don't have developer documentation anywhere else. |
| 17:41.56 | russellb | 1 liner: thingies that keep track of state when you want to use those APIs for either scheduling functions to be executed at a future point in time, or if you want to use a big poll() wrapper |
| 17:42.38 | russellb | this documentation Copyright (C) 2011, Russell Bryant, all rights reserved. |
| 17:42.43 | russellb | you're not even allowed to read it. |
| 17:42.50 | luckman212 | assuming my channel VAR = "SDP_SENDONLY" then would it be acceptable to add something like=> if (pbx_builtin_getvar_helper(p->owner, "SDP_SENDONLY") { ...do goos stuff... } to chan_sip.c ? |
| 17:43.12 | luckman212 | s/goos/good |
| 17:46.58 | kpfleming | you could do that, yes |
| 17:47.30 | luckman212 | maybe I'll call it SDP_MEDIA_DIRECTION instead and allow any of { sendonly, sendrecv, recvonly } |
| 17:53.44 | acidfoo | russellb, ;) |
| 18:10.38 | *** join/#asterisk-dev Crowb4r (u1012@gateway/web/irccloud.com/x-wexdcwnbdqenxyaq) |
| 18:18.27 | Corydon76-home | luckman212: if you use a dialplan function, you can anchor it directly within chan_sip.c and also perform validation on the set values |
| 18:19.58 | anonymouz666 | Corydon76-home: is there much overhead using realtime queues instead of reading from conf files? |
| 18:20.23 | Corydon76-home | Overhead, no. |
| 18:21.41 | Corydon76-home | There are other issues relating to caching and state queries, though. Of course, you don't have to reload every queue to get a new queue added to the system... |
| 18:22.10 | luckman212 | Corydon76-home: yes I thought about validating the input but, how would I create a dialplan function? i'm quite new to this |
| 18:22.43 | Corydon76-home | See the multitude of dialplan functions that are already contained within chan_sip.c... SIP_HEADER, for example. |
| 18:23.38 | luckman212 | ok, thanks will have a look |
| 18:25.25 | pabelanger | Q: What is the purpose of the monitor_sig_flags() function in main/asterisk.c ? |
| 18:26.22 | Corydon76-home | pabelanger: to keep state of which signals have been received, so they can be processed NOT within a signal handler |
| 18:27.08 | Corydon76-home | Because there are many things you cannot do within a signal handler, because you're in a special interrupt state |
| 18:28.37 | pabelanger | Corydon76-home: cool, thanks |
| 18:50.16 | mickecarlsson | kudos to mjordan and the development team re ASTERISK-17288. |
| 18:51.00 | mickecarlsson | Will the code be in 1.8.7 or will it be included in 1.8.8? |
| 18:51.35 | mjordan | mickecarlsson: have you had a chance to test it out yet? |
| 18:51.39 | russellb | mjordan is kind of a big deal |
| 18:51.53 | mickecarlsson | Yes, and I have reported the outcome in the ticket. |
| 18:51.59 | mjordan | great! :-) |
| 18:52.24 | mickecarlsson | Without any changes in sip conf it work like it used to do when dialing out and gettting SIP 484 |
| 18:52.27 | *** join/#asterisk-dev SuD (~alex@90.175.32.209) |
| 18:52.40 | mickecarlsson | I.e. HANGUPCAUSE is now 28 |
| 18:53.35 | mjordan | russellb: this was definitely a team effort :-P |
| 18:53.38 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:1426:b5c4:b598:4131) |
| 18:53.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:54.13 | mjordan | mickecarlsson: while I'm not the person putting together what goes into what version, I would expect this to be in 1.8.8. |
| 18:54.36 | mickecarlsson | That was my understanding as 1.8.7 is rc |
| 18:54.43 | russellb | yep |
| 18:55.04 | mickecarlsson | Great. Thanks guys. |
| 18:55.06 | leifmadsen | 1.8.7.0-rc1 was just created yesterday though |
| 18:55.12 | mjordan | no problem, thanks for testing it out! |
| 18:55.16 | leifmadsen | so only changes since yesterday wouldn't be in that RC |
| 18:55.17 | *** join/#asterisk-dev oej_ (~olle@ns.webway.se) |
| 18:55.17 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 18:55.32 | mjordan | leifmadsen: went in around lunchtime today :-\ |
| 18:55.33 | mickecarlsson | No problem |
| 18:55.41 | leifmadsen | oh then ya, 1.8.8.0-rc1 |
| 18:55.53 | leifmadsen | unless you feel it is important enough to go into 1.8.7.0-rc1 |
| 18:55.57 | leifmadsen | s/rc1/rc2/ |
| 18:56.03 | mickecarlsson | feels that |
| 18:56.19 | russellb | doesn't ... |
| 18:56.19 | mickecarlsson | As I can test it in production |
| 18:56.28 | mickecarlsson | How did I know that answer :-) |
| 18:56.37 | russellb | not my call though :-) |
| 18:56.40 | pabelanger | russellb: +1 |
| 18:56.49 | mickecarlsson | Well, no problem |
| 18:56.55 | mickecarlsson | I am pleased that it is fixed |
| 18:57.20 | *** join/#asterisk-dev irroot (~irroot@197.173.241.226) |
| 18:57.29 | pabelanger | a downside of are RC process, once it is tagged, any bug fixes usually wait until the next 1.8.x+1-rc1 |
| 18:57.29 | leifmadsen | I still don't get how you can't test code from svn vs. some random tarball |
| 18:57.46 | mickecarlsson | Huh, me? |
| 18:57.48 | leifmadsen | yes |
| 18:58.02 | leifmadsen | if you can test 1.8.7.0-rc1, why can't you test from subversion? |
| 18:58.08 | mickecarlsson | I tested from svn |
| 18:58.14 | mickecarlsson | Just checked it out |
| 18:58.30 | leifmadsen | I think you were responding to somethign else now that I read back |
| 18:58.38 | leifmadsen | needs to stop doing 3 things at once |
| 18:58.39 | leifmadsen | sorry |
| 18:58.43 | mickecarlsson | np |
| 18:58.55 | mickecarlsson | For the record, I never use rpm or tarballs |
| 18:59.03 | mickecarlsson | I always use source |
| 19:07.11 | *** part/#asterisk-dev SuD (~alex@90.175.32.209) |
| 19:09.16 | luckman212 | Corydon76-home: if I want to create a dialplan function e.g. SIP_HEADER do I also need to add code to /res/ael/pval.c and /pbx/pbx_ael.c ? sorry for my stupidity |
| 19:16.04 | Corydon76-home | No, those locations are for coding AEL |
| 19:17.15 | luckman212 | ok. well I am losing bigtime |
| 19:18.36 | luckman212 | i'm all over chan_sip.c looking for the bits that set the "a=sendrecv" in the SDP i'm grepping like crazy finding nothing |
| 19:19.37 | luckman212 | thought I had it around lines 10976-10984 but looking again that doesn't seem right |
| 19:29.15 | luckman212 | grep -Ir --include=* "sendrecv" /usr/src/asterisk/ |
| 19:47.03 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 19:47.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:56.08 | Corydon76-home | luckman212: make sure you're grepping an actual source directory. I'm seeing two places in chan_sip.c |
| 20:03.23 | luckman212 | Corydon76-home: oh yes this is the src tree I compiled from, I get 5 hits too, it's just that none of them seem to be "right" |
| 20:04.12 | Corydon76-home | Grep isn't wrong. Check the path from which you're editing |
| 20:06.41 | luckman212 | Corydon76-home: what I mean is, I can find the references in the src but none of those sections seem to be relevant to Asterisk's generation of the SDP in the INVITE |
| 20:08.27 | Corydon76-home | You mean the one in add_sdp() isn't relevant to generating an SDP? |
| 20:10.09 | luckman212 | maybe ast isn't sending an a=sendrecv at all in its first INVITE. I didn't think of that |
| 20:10.09 | Corydon76-home | Hint: it's the one assigning to the variable "hold" |
| 20:10.49 | luckman212 | yes I saw that: if (add_audio) { ....... |
| 20:11.46 | Corydon76-home | transmit_invite() calls add_sdp() |
| 20:12.29 | luckman212 | but wouldn't that be for a channel thats already on hold? i couldn't find the part where that 'hold' variable was used |
| 20:12.42 | Corydon76-home | No |
| 20:13.22 | Corydon76-home | Start at the line where hold is defined, then search for "hold". It's the first match afterwards. |
| 20:14.16 | luckman212 | ah I think I found it... if (needaudio) { .... add_content(resp, hold); |
| 20:20.56 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:20.56 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:32.14 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 20:45.37 | *** join/#asterisk-dev otherwiseguy (~terry@cpe-69-76-217-40.kc.res.rr.com) |
| 20:51.11 | *** join/#asterisk-dev luckman212_ (~irc@2001:470:1f07:1225:5880:fdc2:20d7:fcf6) |
| 20:58.53 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:58.53 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 21:17.38 | luckman212_ | Corydon76-home: if I need a variable to hold the contents of pbx_builtin_getvar_helper(p->owner, "SDP_MEDIA_DIRECTION") would I define it as char *sdp_media_dir[256] or char sdp_media_dir[256] ? |
| 21:19.24 | luckman212_ | I think it should be char *sdp_media_dir[256] |
| 21:25.38 | Corydon76-home | the second |
| 21:26.00 | luckman212_ | char *var ? |
| 21:26.11 | Corydon76-home | If you declare char *foo[], you're declaring an array full of pointers, instead of an array full of chars |
| 21:27.03 | Corydon76-home | So you either use char foo[256] or char *foo. The second only declares a pointer, so you'd still need to malloc memory for the buffer |
| 21:27.28 | luckman212_ | ah... I should use char *sdp_media_dir = ""; |
| 21:27.48 | Corydon76-home | That allocates only a pointer and sets it to a constant string |
| 21:27.57 | luckman212_ | and then I could follow it with sdp_media_dir = pbx_builtin_getvar_helper(p->owner, "SDP_MEDIA_DIRECTION"); |
| 21:28.42 | Corydon76-home | Well, kind of... as long as you lock the channel beforehand and don't unlock the channel until you're done with that pointer |
| 21:29.03 | Corydon76-home | Otherwise, the pointer can be free'd asynchronously, such as from AMI |
| 21:29.47 | luckman212_ | I admit that I really don't understand ^^^^^ that there |
| 21:30.01 | Corydon76-home | That's why if we want to get a channel variable and use it for a long time, we duplicate the value into a local buffer |
| 21:30.57 | Corydon76-home | When you pbx_getvar_helper(), you're obtaining a pointer to a value in a shared location. Another thread can alter that list while the channel is unlocked |
| 21:31.43 | luckman212_ | so, ast_channel_lock(chan); |
| 21:31.52 | luckman212_ | ..... do stuff... |
| 21:31.57 | Corydon76-home | You have to lock the shared location (the channel) for exclusive access while you're accessing values in that shared location |
| 21:31.58 | luckman212_ | ast_channel_unlock(chan); |
| 21:32.21 | Corydon76-home | Right, as long as you aren't accessing that pointer after the unlock, you're fine |
| 21:33.03 | Corydon76-home | Now, since you're also accessing a pvt, you have two locks, so you need to observe locking order, in order to prevent deadlocks |
| 21:33.55 | Corydon76-home | IIRC, locking order is channel lock first, pvt second. So if the pvt is locked, you'll need to unlock it, lock the channel, then lock the pvt |
| 21:34.33 | Corydon76-home | Then compare, to ensure that the pvt is still owned by the channel |
| 21:35.03 | luckman212_ | i don't even know what a pvt is :( |
| 21:35.13 | Corydon76-home | (Pvts can be moved to other channels, such as during a transfer) |
| 21:35.40 | Corydon76-home | The pvt is the sip local structure in chan_sip that stores SIP-specific information |
| 21:36.07 | Corydon76-home | The channel is Technology-agnostic |
| 21:37.16 | luckman212_ | man, I am really lost now |
| 21:37.21 | luckman212_ | <sigh> |
| 21:37.49 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 21:39.46 | luckman212_ | how did u learn all this? is there a 'beginner's guide for developing for Asterisk' or some such thing?? |
| 21:41.02 | Corydon76-home | I've been doing this for over 11 years |
| 21:41.37 | luckman212_ | when u say 'this' do you mean C programming or Asterisk-specific? i don't think * is 11 years old so, must be the former(?) |
| 21:41.42 | Corydon76-home | Or no... over 10 years, anyway |
| 21:41.47 | Corydon76-home | Asterisk-specific |
| 21:41.56 | luckman212_ | nice |
| 21:42.11 | luckman212_ | well you're in on the ground floor then eh |
| 21:43.04 | Corydon76-home | I admit; there are a number of things you need to keep in mind when writing Asterisk code |
| 21:44.31 | luckman212_ | I just would like to know where to even begin. e.g. to learn about the data structures, the variables, etc. I'd like to be able to code small patches, changes, add minor features etc. |
| 21:46.45 | Corydon76-home | Start in the cdr/ directory. Those are amongst the simplest modules |
| 21:47.25 | Corydon76-home | There's no interaction with the channel, just a record passed in to post records to a backend |
| 21:47.46 | luckman212_ | alright. |
| 21:48.29 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:48.29 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 21:48.34 | Corydon76-home | Once you're comfortable with that, try the funcs/ directory, which does interact with the top-level channel, but does not delve into channel drivers |
| 21:48.49 | Corydon76-home | After funcs, apps/. |
| 21:49.53 | Corydon76-home | Then channel drivers and the core, but avoid transfers and other uses of masquerades until the very end |
| 21:50.38 | Corydon76-home | The masquerade functionality is a black art. |
| 21:50.46 | luckman212_ | yikes |
| 21:51.22 | Corydon76-home | So is trying to use Macro more than 7 levels deep |
| 21:52.15 | luckman212_ | I could imagine |
| 21:57.32 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-rrgfkyirrkoazopm) |
| 22:08.08 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 22:09.18 | *** join/#asterisk-dev droemel (~droemel@p4FCAC881.dip.t-dialin.net) |
| 22:09.32 | *** join/#asterisk-dev moy_ (~moy@CPE002719f00364-CM0026f3a1701d.cpe.net.cable.rogers.com) |
| 22:15.53 | *** part/#asterisk-dev droemel (~droemel@p4FCAC881.dip.t-dialin.net) |
| 22:32.08 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 23:10.12 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 23:10.42 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |