| 00:00.42 | *** join/#asterisk-dev Victor_Yure_ (n=victor@unaffiliated/victoryure/x-837844) |
| 01:34.50 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 01:34.50 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:09.51 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 02:09.51 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 02:28.47 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) [NETSPLIT VICTIM] |
| 02:28.47 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) [NETSPLIT VICTIM] |
| 02:58.56 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-212-6.west.biz.rr.com) |
| 03:22.18 | *** part/#asterisk-dev califus (n=chatzill@210.212.160.101) |
| 04:32.03 | *** join/#asterisk-dev Octothorpe (n=Octothor@pdpc/supporter/professional/octothorpe) |
| 04:42.50 | *** join/#asterisk-dev lasko (n=lasko@pool-71-111-24-127.ptldor.dsl-w.verizon.net) |
| 05:04.27 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 07:12.12 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:22.51 | wedhorn | I'm tidying up skinny chan->tech_pvt handling which sort of meant screwing with the locking |
| 07:22.56 | wedhorn | I've removed a bunch of locks from chan_skinny so I basically have a device lock and use the chan lock in combination |
| 07:23.00 | wedhorn | Anyway, to avoid deadlocking, I basically make sure I have the chan lock before calling any channel.c functions |
| 07:23.11 | wedhorn | I thought this a bit overzealous and so had a look through channel.c and ended up with a bunch of wtf's (numbers used for ease of reference) |
| 07:23.16 | wedhorn | 1 why does ast_queue_hangup basically go "!trylock(set softhangup, unlock), lock, do stuff, unlock" ??? Why not just lock the chan to begin with? |
| 07:23.21 | wedhorn | 2 why do we have ast_queue_frame_head when it's only use appears to be to fix AST_LIST_ADD_HEAD in ast_answer? |
| 07:23.28 | wedhorn | 3 chan->_softhangup seems to be set locked and unlocked. It's a bit mask and some comparisons are ==, it is sometimes specifically assigned values without checking whether something is already there |
| 07:23.33 | wedhorn | 4 why does __ast_queue_frame use the channel lock. Couldn't we queue and dequeue based on a list lock? |
| 07:23.38 | wedhorn | Anyway, the biggest for me is __ast_queue_frame locking. If we used a list lock or similar, I could remove most (if not all) chan locking in chan_skinny. May apply to other channels as well. But I'm not familiar enought with all the ins and outs of channel.c to know if this is feasible |
| 07:52.39 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:52.39 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:03.28 | *** join/#asterisk-dev mbranca (n=matteo@2001:1418:130:0:21e:8cff:fe51:5b05) |
| 08:22.30 | *** part/#asterisk-dev bencer (n=bencer@heal.cauterized.net) |
| 08:28.37 | *** join/#asterisk-dev Octothorpe (n=Octothor@pdpc/supporter/professional/octothorpe) |
| 08:36.00 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 09:02.50 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 09:02.51 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 09:11.35 | *** join/#asterisk-dev dlu_dus (n=dlu@83.125.8.7) |
| 09:16.02 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 09:25.58 | *** join/#asterisk-dev mort___ (n=mort@nsabfw1.nsab.se) |
| 09:36.56 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 09:37.28 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 09:37.28 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 10:16.11 | *** join/#asterisk-dev mort___ (n=mort@nsabfw1.nsab.se) |
| 10:41.53 | *** join/#asterisk-dev frawd (n=francois@96.Red-83-35-179.dynamicIP.rima-tde.net) |
| 10:44.40 | *** part/#asterisk-dev frawd (n=francois@96.Red-83-35-179.dynamicIP.rima-tde.net) |
| 10:50.12 | *** join/#asterisk-dev destructure (n=de@67-23-12-32.static.slicehost.net) |
| 11:00.03 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:00.03 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:00.46 | kpfleming | le |
| 11:13.08 | snuff-home | la |
| 11:21.10 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 11:37.05 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:37.05 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:39.23 | *** join/#asterisk-dev fiddur (i=fiddur@c042.rit.se) |
| 11:42.53 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 11:59.56 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:16.59 | *** join/#asterisk-dev Mw3 (i=mw3@ip59934bd1.rubicom.hu) |
| 12:27.08 | *** join/#asterisk-dev shyam_k (n=user@unaffiliated/shyam-k/x-8459115) |
| 13:00.58 | *** join/#asterisk-dev Mw3 (i=mw3@ip59934bd1.rubicom.hu) |
| 13:24.08 | *** join/#asterisk-dev moy (n=chatzill@74.12.124.89) |
| 13:36.59 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 14:09.11 | *** join/#asterisk-dev ctooley (n=ctooley@24.248.220.72) |
| 14:09.11 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 14:13.26 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 14:22.48 | *** join/#asterisk-dev jeangal (n=jeang@nat/digium/x-60dc44cce253f851) |
| 14:23.38 | kaii | -yawn- |
| 14:24.54 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.24.187) |
| 14:42.09 | *** join/#asterisk-dev bbryant (n=bbryant8@68.208.65.34) |
| 14:42.09 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 14:42.29 | bbryant | eliel: ping |
| 14:44.18 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:44.18 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:45.06 | bbryant | guess he's not around |
| 14:58.45 | *** join/#asterisk-dev bbryant (n=bbryant8@68.208.65.34) |
| 14:58.45 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 15:00.38 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:00.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:02.13 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 15:02.20 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:02.28 | *** join/#asterisk-dev eliel (n=eliels@151-202-114-200.fibertel.com.ar) |
| 15:02.28 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 15:05.38 | *** join/#asterisk-dev schmooze_tony (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 15:06.22 | eliel | russellb: thanks for the review |
| 15:06.46 | russellb | np |
| 15:06.56 | russellb | bbryant: eliel is here now |
| 15:15.51 | tzafrir_laptop | Is sruffell around? |
| 15:16.42 | sruffell | tzafrir_laptop: I'm am... |
| 15:17.00 | sruffell | still have it on the list to test the B410P. |
| 15:28.32 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 15:28.54 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 15:33.14 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:53.13 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 16:00.10 | *** join/#asterisk-dev shido6 (n=shido6@96-28-34-156.dhcp.insightbb.com) |
| 16:04.12 | eliel | I have uploaded my proposal :) now I will concentrate on other thing or i am not going to sleep till 20 april... |
| 16:04.24 | leifmadsen | hehehe |
| 16:05.27 | eliel | leifmadsen: I am trying to make xinclude work on the astxml docs |
| 16:05.47 | leifmadsen | awesome! |
| 16:05.55 | leifmadsen | keep me posted and let me know if there is anything i can do |
| 16:06.04 | Corydon76-dig | Sleep is overrated |
| 16:07.17 | eliel | leifmadsen: right now I was able to make libxml2 parse the xi:include tag but I am getting a recursive error, i think it is because i am trying to make a reference to the same document with a wrong xpointer. |
| 16:07.26 | eliel | Corydon76-dig: he |
| 16:11.13 | eliel | the karmar_transaction link is not working: http://bugs.digium.com/karma_view_transactions.php?id=3802 |
| 16:11.43 | eliel | I was making a reference to it in the proposal... |
| 16:13.35 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:15.33 | *** part/#asterisk-dev bbryant (n=bbryant8@68.208.65.34) |
| 16:26.58 | tzafrir_laptop | when I build dahdi with C=1 with kernel 2.6.29 it complains about two new things. |
| 16:27.26 | tzafrir_laptop | 1. wctdm has some bit fieds that are signed int |
| 16:27.52 | tzafrir_laptop | 2. drivers/dahdi/tor2.c:342:10: warning: dereference of noderef expression |
| 16:28.21 | tzafrir_laptop | This seems to be when dereferencing tor->plx , which is of type __iomem |
| 16:28.59 | tzafrir_laptop | It seems that this message is normally related to attempting to dereference __user type memory |
| 16:29.18 | tzafrir_laptop | Is __iomem also some place we shouldn't touch directly? |
| 16:29.53 | *** join/#asterisk-dev dbrooks (n=dbrooks@nat/digium/x-1279895ff52b7921) |
| 16:31.49 | *** join/#asterisk-dev lasko_ (n=lasko@70.102.15.210) |
| 16:47.59 | *** join/#asterisk-dev Cresl1n (n=matt@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:47.59 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 17:02.55 | *** join/#asterisk-dev mog (n=mog@c-68-62-218-186.hsd1.al.comcast.net) |
| 17:02.55 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 17:06.55 | *** join/#asterisk-dev Mw3 (i=mw3@ip59934bd1.rubicom.hu) |
| 17:13.16 | *** join/#asterisk-dev bbryant (n=bbryant8@68.208.65.34) |
| 17:13.16 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 17:16.18 | *** join/#asterisk-dev dlu_dus (n=dlu@83.125.8.7) |
| 17:18.59 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 17:20.10 | *** part/#asterisk-dev dlu_dus (n=dlu@83.125.8.7) |
| 17:28.23 | *** join/#asterisk-dev dlu_dus (n=dlu@83.125.8.7) |
| 17:29.20 | *** join/#asterisk-dev lftsy (n=lftsy@pul-lav-fw-so-01-x1.vtxnet.net) |
| 17:31.00 | lftsy | Hello all, I have a small question not answered, is there someone how could help me please.. |
| 17:31.23 | russellb | lftsy: unless it's a question about C programming, no. |
| 17:31.29 | russellb | lftsy: please see the topic and join message. |
| 17:32.00 | lftsy | yes it is about the C Dial function |
| 17:32.15 | russellb | is about modifying the code for the Dial() application, or about how to use Dial() ? |
| 17:32.34 | swathanthran | russellb: what about my query on bugs..? |
| 17:33.09 | russellb | oh yes, sorry, *responds* |
| 17:33.36 | lftsy | Do you think that is it easily possible to modify the C Dial function adding a parameter in order to change the number to be reach without modifying the Peer IP and Reg. Contact IP |
| 17:34.00 | lftsy | Because it is not the actual behaviour of the C function |
| 17:38.31 | russellb | you do not need to change the code for that |
| 17:38.37 | lftsy | like a Dial(SIP/1003/1005,"q") that will use 1003 IP and Reg Contact rewriting only the number in the URI to reach without altering the IP |
| 17:38.55 | russellb | please ask in #asterisk, you can already do this. |
| 17:40.57 | lftsy | I will, but I haven't reveive any answer on the mailing list, so I suppose noone has already tried to do it.. ++ |
| 17:44.57 | file | kpfleming: poke! |
| 17:45.06 | kpfleming | ouch |
| 17:45.21 | file | kpfleming: we can't use apache license 2.0 stuff can we? |
| 17:45.43 | kpfleming | ugh... my brain is not in that mode right now, but i believe we can |
| 17:46.12 | tzafrir_laptop | file: there would be no problem if gplv3 was used... |
| 17:46.59 | tzafrir_laptop | I don't recall the exact technical issue that caused the incompatibility between gplv2 and apache2.0 |
| 17:49.20 | tzafrir_laptop | http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses |
| 17:51.00 | swathanthran | had a glance on that page yesturday.. but left it for more interesting mrcp docs..:) |
| 17:54.10 | swathanthran | " citing the patent termination and indemnification provisions as restrictions not present in the older GPL license" says http://www.apache.org/licenses/GPL-compatibility.html |
| 18:00.48 | swathanthran | and i was thinking about unimrcp implementation in asterisk and unimrcp is in apache license 2.0 |
| 18:02.15 | swathanthran | unimrcp is an mrcp implementation written by the same author of cepstral funded openmrcp.. |
| 18:11.47 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 18:11.48 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 18:13.25 | eliel | I am getting this warning when compiling trunk: http://pastebin.ca/1370710 |
| 18:13.58 | *** join/#asterisk-dev BlargMaN00 (n=blargman@12.234.16.130) |
| 18:14.24 | Corydon76-lap | eliel: safe to ignore |
| 18:14.46 | eliel | Corydon76-dig: ok |
| 18:16.46 | Corydon76-lap | Do we have a good way currently to track file descriptor leaks? |
| 18:16.59 | Corydon76-lap | To track down where they leak, that is |
| 18:17.14 | kpfleming | don't think so |
| 18:17.43 | Corydon76-lap | Okay, just wanted to check before I write something to track it down |
| 18:26.37 | swathanthran | file: now but it seems its ok to release unimrcp based systems in gplv2 while what is not possible is to include gplv2 licensed libraries INTO unimrcp project as their licenses are incompatible.. |
| 18:28.08 | jpeeler | Deeewayne: you said that channel state needs to be maintained in libpri, but libpri doesn't handle all the channel allocations from what i can tell. would it be possible to add the information in chan_dahdi? |
| 18:29.13 | *** join/#asterisk-dev moy (n=moy@74.12.124.89) |
| 18:32.19 | jpeeler | Deeewayne: i'm assuming the service type, channel, and state is all that would need to be stored. also, with future additions in mind, i don't think in service channels can be missing (which wouldn't happen if stored in chan_dahdi) if shutdown or loopback statuses for example are supported later. |
| 18:37.09 | russellb | M205 |
| 18:37.11 | MuffinMan | [closed] [Asterisk] Core/General 0000205: Inbound IAX2 calls block asterisk and/or crash it. reported by bkw918 (Karma: +53.25) http://bugs.digium.com/view.php?id=205 |
| 18:37.15 | russellb | oops. |
| 18:37.16 | russellb | R205 |
| 18:37.19 | MuffinMan | [R205] Improve event API cache performance [Pending] Submitted by russell => http://reviewboard.digium.com/r/205/ |
| 18:37.28 | russellb | The_Boy_Wonder: there :-) |
| 18:38.28 | The_Boy_Wonder | russellb: F7ESH! |
| 18:52.36 | Deeewayne | jpeeler, I was suggesting a bit field used to indicate whether or not a b-channel is in service in libpri and a callback used by chan_dahdi to set a b-chan out-of-service |
| 18:53.57 | Deeewayne | there are probably other ways to do it, but an out-of-service 'net' channel should not send a RESTART to the cpe |
| 18:55.54 | jpeeler | ok so the bitfield could support multiple statuses |
| 18:56.07 | jpeeler | but why create anything in libpri when the channels live in chan_dahdi? |
| 18:57.49 | jpeeler | i'm guessing that i'm missing something that caused you to choose your choice of putting it in libpri |
| 18:58.12 | Deeewayne | one sec |
| 18:58.32 | jpeeler | or wanting to next |
| 18:58.33 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.24.187) |
| 18:59.31 | *** join/#asterisk-dev Mw3 (i=mw3@ip59934bd1.rubicom.hu) |
| 19:01.13 | Corydon76-lap | jpeeler: well, it is PRI level information... |
| 19:01.25 | Corydon76-lap | encapsulation |
| 19:02.12 | *** join/#asterisk-dev Mw3 (i=mw3@mw3.hu) |
| 19:04.35 | jpeeler | but having an array of channels just for service maintenance messages seems weird to me |
| 19:21.01 | Deeewayne | jpeeler, if a b-chan (configured as cpe) is out-of-service and a RESTART msg comes in for it, it needs to ignore the RESTART message and do nothing. |
| 19:21.29 | Deeewayne | if a b-chan (configured as net) is out-of-service is should not send a RESTART msg |
| 19:23.37 | *** join/#asterisk-dev dlu_dus (n=dlu@83.125.8.7) |
| 19:24.15 | Deeewayne | I was thinking that the libpri bit field is not 'just for service maintenance messages' but is instead used to determine if a RESTART msg is sent up to Asterisk (when configured for cpe) or sent out to the cpe (when configured for net) |
| 19:25.49 | Deeewayne | If you can prevent an out-of-service 'net' channel from sending a RESTART from the Asterisk level, you don't need to add the bit field to libpri |
| 19:26.58 | Deeewayne | Cresl1n may have a better way of doing that |
| 19:27.29 | file | call me crazy but couldn't you just change the reset interval to 0 to disable it when it goes out of service? |
| 19:27.57 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 19:27.57 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 19:29.05 | Deeewayne | file, don't know |
| 19:38.11 | jpeeler | Deeewayne: what about the other service change statuses, do they react to restart messages? |
| 19:38.29 | Deeewayne | file, that may work on the net side, but you would still need to ignore restarts that come in to an out-of-service cpe b-channel...but that is already in chan_dahdi so no work would need to be done for that |
| 19:38.56 | Deeewayne | jpeeler, you mean loop and stuff ? |
| 19:39.23 | jpeeler | yeah... i'm just wondering if it is only a question of being out of service |
| 19:40.30 | Deeewayne | at&t tr41459 is your friend :-) |
| 19:40.53 | Deeewayne | behavior is a little different depending on the service state |
| 19:42.39 | jpeeler | so that's a spec? |
| 19:45.59 | *** join/#asterisk-dev mosty (n=mosty@213-66-224-163-no22.tbcn.telia.com) |
| 19:50.12 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 19:50.12 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:55.29 | *** part/#asterisk-dev Cresl1n (n=matt@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 20:19.16 | *** part/#asterisk-dev dlu_dus (n=dlu@83.125.8.7) |
| 20:36.33 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 20:36.33 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:52.38 | russellb | putnopvut: thanks a lot for the review |
| 20:53.00 | russellb | putnopvut: for the documentation suggestion, do you think it would be better to put it with the prototypes at the top, or with the implementations later in the file? |
| 20:54.30 | putnopvut | Good question. I suppose with the prototypes since that is the typical place for docs. |
| 20:54.30 | putnopvut | But I can see it going either way, really. |
| 20:54.30 | russellb | Alrighty |
| 20:54.30 | russellb | yeah, same here |
| 20:54.30 | russellb | it's a toss-up |
| 20:54.35 | russellb | and i'm not sure there is a precedent for it |
| 20:54.45 | russellb | goes with prototypes |
| 20:54.55 | putnopvut | Yeah the precedent is that most static functions in Asterisk don' thave prototypes. |
| 20:55.41 | russellb | yep |
| 20:55.47 | russellb | and when they do, they're just not documented at all, heh |
| 20:56.01 | kpfleming | well, there are a lot that do, when the file is large and they are forward declared so they don't have to be moved to the top of the file, or when there are circular references between static functions |
| 20:56.28 | russellb | it's a minority, but yeah, for sure |
| 20:56.32 | russellb | chan_sip is the biggest example of it |
| 20:57.00 | putnopvut | chan_sip could really use some doxygenification...but I'm certainly not doing it any time soon. |
| 20:57.04 | russellb | heh |
| 20:57.18 | putnopvut | What it could really benefit from are the \pre tags so we can easily tell what is and is not locked prior to the function call. |
| 20:58.04 | putnopvut | russellb: hey, does wedhorn have a team directory on origsvn? |
| 20:58.16 | russellb | putnopvut: nope, but i offered it in my last post to -dev |
| 20:58.19 | putnopvut | ah |
| 21:03.26 | jpeeler | one thing about the doxygen stuff, don't comment both the prototypes and the implementation |
| 21:03.32 | jpeeler | it does not merge them |
| 21:03.32 | russellb | jpeeler: k! |
| 21:04.03 | jpeeler | it's done a lot of places and documentation is lost because of it |
| 21:06.07 | russellb | that is sad. |
| 21:07.42 | Corydon76-lap | jpeeler: which takes precedence? |
| 21:08.17 | jpeeler | the implementation, but i noticed that we tend to favor documenting the prototypes |
| 21:08.17 | jpeeler | so i think that should be made the rule |
| 21:08.18 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 21:08.22 | Corydon76-lap | And what about \note in the implementation? |
| 21:09.07 | Corydon76-lap | I've been adding that tag within code, because I thought it would improve that |
| 21:09.27 | jpeeler | can't remember now if there were any exceptions, seemed that any doyxgen commenting with the implementation "erased" the other documentation |
| 21:09.52 | jpeeler | i know \brief did it |
| 21:15.16 | *** join/#asterisk-dev philippel (n=p_lindhe@pool-98-111-74-92.sttlwa.fios.verizon.net) |
| 21:20.08 | *** join/#asterisk-dev bartpbx (n=bartpbx@62.216.165.71) |
| 21:43.54 | bartpbx | hello, I |
| 21:44.26 | bartpbx | I'm currently debugging the t.38 passthrough implementaion in asterisk 1.4 |
| 21:46.18 | bartpbx | and i dont understand, why the reinvite is always ending in an end 2 end packet connection even if nat is actie on one end. |
| 22:11.36 | *** part/#asterisk-dev philippel (n=p_lindhe@pool-98-111-74-92.sttlwa.fios.verizon.net) |
| 22:17.32 | *** join/#asterisk-dev ZX81 (n=matt@202.20.97.211) |
| 22:49.05 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 23:21.29 | *** join/#asterisk-dev Dovid (n=annon@tony09-121-90.inter.net.il) |
| 23:59.44 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-212-6.west.biz.rr.com) |