| 00:21.30 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 01:24.58 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 03:02.08 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.79) |
| 04:23.09 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 04:24.13 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 04:24.13 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 05:25.46 | *** join/#asterisk-dev ksteward (n=ksteward@pool-96-237-105-19.bstnma.fios.verizon.net) |
| 05:26.35 | *** part/#asterisk-dev ksteward (n=ksteward@pool-96-237-105-19.bstnma.fios.verizon.net) |
| 07:16.12 | *** join/#asterisk-dev Chris-NB (n=chris@85-126-61-10.work.xdsl-line.inode.at) |
| 07:18.32 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:22.07 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 07:22.07 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:28.40 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 07:47.18 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 08:48.47 | *** join/#asterisk-dev yahh (n=root@122.169.93.71) |
| 08:49.18 | yahh | Hello guys.. |
| 08:49.38 | yahh | I am having some issue with RTP |
| 08:50.26 | yahh | so i want to discuss about RTP processing |
| 08:50.44 | yahh | i think most of the code is in rtp.c and channel.c |
| 08:54.44 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 08:54.44 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 08:55.59 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 08:55.59 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 08:55.59 | *** join/#asterisk-dev Deeewayne (n=dwayne@76.29.245.9) |
| 08:55.59 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@75.97.64.33) [NETSPLIT VICTIM] |
| 08:55.59 | *** join/#asterisk-dev mbranca (n=matteo@2001:1418:130:0:21e:8cff:fe51:5b05) [NETSPLIT VICTIM] |
| 08:55.59 | *** join/#asterisk-dev lftsy (n=lftsy@ratatouille.leurent.eu) [NETSPLIT VICTIM] |
| 08:55.59 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 08:55.59 | *** mode/#asterisk-dev [+ooo The_Boy_Wonder Deeewayne seanbright] by irc.freenode.net |
| 08:57.45 | yahh | Hello guys. |
| 08:57.48 | yahh | <PROTECTED> |
| 09:03.51 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 09:05.48 | *** join/#asterisk-dev degrade (n=degrade@unaffiliated/degrade) |
| 09:32.33 | yahh | Hello guys.. |
| 09:32.45 | yahh | I am having some issue with RTP |
| 09:33.09 | yahh | I want to make it proper |
| 09:42.59 | *** join/#asterisk-dev skirmisha (n=asd@79-100-41-71.btc-net.bg) |
| 09:43.10 | tzafrir_laptop | config.guess/sub in menuselect needs updating as well (like in asterisk r205288) |
| 09:43.32 | tzafrir_laptop | it's basically a 'libtoolize -c --force' if you have a recent enough system |
| 09:43.55 | tzafrir_laptop | is menuselect trunk the only branch that needs updating? |
| 09:47.54 | skirmisha | guys |
| 09:48.15 | skirmisha | is there any priority in insecure option for ip and username? |
| 09:53.34 | yahh | Hello guys.. |
| 09:53.43 | yahh | I am having some issue with RTP |
| 09:53.53 | yahh | I want to make it proper |
| 10:02.18 | skirmisha | what is wrong with rtp |
| 10:18.01 | yahh | skirmisha are you there? |
| 10:20.53 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 10:21.48 | kaii | yahh: 12:04 -!- skirmisha [n=asd@79-100-41-71.btc-net.bg] has quit [] |
| 10:22.12 | kaii | yahh: but it will help when you explain your issue. |
| 10:22.16 | kaii | so that anyone can answer you. |
| 10:28.53 | yahh | sure |
| 10:29.33 | yahh | Normal rtp is being sent from asterisk1 to asterisk2 |
| 10:29.36 | yahh | for a call |
| 10:30.25 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 10:30.25 | yahh | now i have modified and sent some garbage udp packets in between |
| 10:30.35 | yahh | from asterisk1 to asterisk2 |
| 10:34.35 | yahh | now voice on asterisk2 's connnected phone is not coming proper |
| 10:37.07 | yahh | asterisk2 is processing it as null frame |
| 10:37.18 | yahh | why it is not throwing away |
| 10:56.39 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 10:59.06 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 11:09.44 | *** join/#asterisk-dev IgorG|note (n=IgorG|no@zeonweb.ru) |
| 11:35.10 | *** join/#asterisk-dev skirmisha (n=asd@79-100-41-71.btc-net.bg) |
| 11:35.54 | skirmisha | can someone explain me when insecure option is checked? |
| 11:36.03 | skirmisha | upon invite |
| 11:36.08 | skirmisha | or? |
| 11:37.58 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 11:37.58 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:38.27 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 11:39.13 | kaii | skirmisha: yes |
| 11:41.11 | skirmisha | what is checked as it looks like that on my system does not work and asterisk always sends 407 back |
| 11:41.20 | skirmisha | i have peer where call comes from |
| 11:41.29 | skirmisha | and have set insecure=invite |
| 11:41.38 | skirmisha | but that seems to not work at all |
| 11:44.36 | skirmisha | so any ideas why that option is not working will be welcomed |
| 11:57.14 | kaii | skirmisha: -> #asterisk this channel is for source code discussions. it will help in #asterisk, if you would pastebin your sip.conf with general and the specific peer section. a sip debug will help too. |
| 11:58.55 | skirmisha | this is the bug i am talking about |
| 11:58.57 | skirmisha | https://issues.asterisk.org/view.php?id=13644 |
| 11:59.16 | skirmisha | is it fixed in 1.4 |
| 12:01.13 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:01.13 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:03.42 | kaii | skirmisha: this bug is reported against 1.6 tree, i dont think the fix is in 1.4 |
| 12:03.51 | kaii | skirmisha: have you tried insecure=very ? |
| 12:04.31 | skirmisha | yes |
| 12:04.41 | skirmisha | tried all options but still have it |
| 12:04.55 | skirmisha | and asterisk always sends 407 |
| 12:05.15 | kaii | pastebin sip.conf and sip debug, thx |
| 12:05.18 | skirmisha | if number does not exist in sip.conf then call is passed thru as it is auth based on peer ip |
| 12:07.23 | tzafrir_laptop | kpfleming, config.guess and config.status need to be updates in menuselect and asterisk-gui as well |
| 12:08.16 | tzafrir_laptop | just updated (well, added) them in dahdi-tools |
| 12:10.50 | kpfleming | menuselect has been updated (1.0 and trunk branches) |
| 12:15.22 | tzafrir_laptop | my working copy was out of date, it seems |
| 12:15.47 | tzafrir_laptop | however it appears only config.guess was updated . What about config.sub ? |
| 12:16.07 | tzafrir_laptop | basically: run: libtoolize -c --force |
| 12:16.32 | tzafrir_laptop | and have a recent enough autotools-dev (on Debian/Ubuntu) |
| 12:18.55 | kpfleming | oh, you said config.status, not config.sub |
| 12:18.58 | kpfleming | i'll fix those too |
| 12:19.02 | tzafrir_laptop | well, though that's older than the new one included with Asterisk |
| 12:19.08 | tzafrir_laptop | config.guess, sorry |
| 12:19.18 | tzafrir_laptop | config.status is generated by configure |
| 12:19.42 | tzafrir_laptop | I figure you better copy the one from asterisk |
| 12:19.48 | kpfleming | config.sub updated as well |
| 12:19.56 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:19.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:19.59 | kpfleming | i did, i copied both of them from asterisk |
| 12:22.18 | *** join/#asterisk-dev Dovid (n=annon@tony09-118-62.inter.net.il) |
| 12:24.55 | tzafrir_laptop | ah, ok |
| 12:26.27 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:26.27 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 12:30.55 | tzafrir_laptop | sruffell, hi |
| 12:31.30 | tzafrir_laptop | is there a place to mark "candidates" for any next dahdi-{linux,tools} point release? |
| 12:35.16 | sruffell | tzafrir_laptop: hmm...not that I'm aware of. What do you have in mind? |
| 12:35.54 | tzafrir_laptop | the tor2 fix, certainly. |
| 12:36.27 | sruffell | goes to look if there is a field on mantis for that already... |
| 12:36.31 | tzafrir_laptop | config.sub and config.status as well, to resolve a nagging minor Debian bug |
| 12:38.20 | tzafrir_laptop | A SVN branch? |
| 12:38.26 | sruffell | The target version, right? |
| 12:39.12 | sruffell | if it's marked in the target version, it should get pulled into that release? (although that means I need to make sure to put in the next release...which I admittedly haven't been doing) |
| 12:40.55 | tzafrir_laptop | I meant: why not actually have a svn branch? |
| 12:40.56 | sruffell | but....I guess what you're really asking...is whether it's time to make a 2.2 branch of dahdi-linux... |
| 12:41.05 | sruffell | which it probably is. |
| 12:41.24 | sruffell | and whether we need a 2.1 branch too. |
| 12:42.17 | tzafrir_laptop | is 2.1 actively maintained? |
| 12:42.33 | tzafrir_laptop | (one ccan always start off a tag) |
| 12:42.42 | sruffell | I rather it not be.....so I would say no 2.1 branch unless you have a real problem with it. |
| 12:43.13 | snuff-home | has learnt the wisdom of cache-lines and 2d array accessing |
| 12:44.11 | mvanbaak | nice |
| 12:45.46 | snuff-home | goes for some zzz's.. |
| 12:53.30 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.83) |
| 12:53.53 | tzafrir_laptop | sruffell, well, but for 2.2? it needs to be "maintained" (as in - point releases need to be released) anyway |
| 12:54.56 | sruffell | yes...I have changes in the work for another 2.2 point release. The question I don't know if I have an answer to is if we branch 2.2, how long will it be maintained? |
| 12:55.00 | sruffell | 6 months? 1 year? |
| 12:55.36 | sruffell | I know kpfleming asked me to make a note about that in the doc in the project, which I've yet to do. |
| 12:59.32 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:59.32 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:03.33 | *** join/#asterisk-dev _ys (n=ys@91.151.196.67) |
| 13:09.24 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 13:34.03 | *** join/#asterisk-dev ctooley (n=ctooley@c-68-52-165-168.hsd1.tn.comcast.net) |
| 13:34.03 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 14:04.48 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:04.48 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:05.43 | *** join/#asterisk-dev moy (n=moy@bas1-unionville55-1177733615.dsl.bell.ca) |
| 14:13.15 | *** join/#asterisk-dev moy (n=moy@bas1-unionville55-1177733615.dsl.bell.ca) |
| 14:16.39 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:51.05 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:51.05 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:56.54 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:56.54 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:04.28 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 15:10.43 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.97) |
| 15:11.49 | *** join/#asterisk-dev xpot-mobile (n=james@static-66-182-88-85.bbsc.net) |
| 15:13.45 | *** join/#asterisk-dev marv[work] (n=timr@24.214.206.254) |
| 15:15.37 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) |
| 15:24.27 | yahh | I am having some issue with RTP |
| 15:25.26 | yahh | i have modified and sent some garbage udp packets in between |
| 15:25.37 | yahh | it has affected voice |
| 15:25.42 | yahh | plz advise |
| 15:26.42 | kpfleming | you did not post what asterisk version you are using, did not tell us how you modified the packets, or what the effect was |
| 15:26.56 | kpfleming | it's nearly impossible to give you any advice |
| 15:40.35 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 15:40.36 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 15:47.48 | ctooley | yahh, You modified the RTP to send garbage packets? That doesn't seem like a good idea to begin with. |
| 15:49.16 | seanbright | so i wrote this http client one time |
| 15:49.23 | seanbright | and smack in the middle of the headers section i put |
| 15:49.36 | seanbright | ZOMG THIS IS SO HARDCORE!!! |
| 15:49.51 | seanbright | and, for the life of me, could not get the darn thing to work |
| 15:50.55 | kpfleming | lol |
| 15:51.23 | seanbright | so naturally i wrote a message to the apache dev mailing list |
| 15:51.32 | seanbright | with the subject "problem" |
| 15:51.41 | yahh | ohh sorry |
| 15:51.47 | yahh | i am using 1.4.24.1 |
| 15:53.08 | yahh | kpfleming: i am generating garbage udp packet from asterisk 1 |
| 15:53.12 | yahh | to asterisk 2 |
| 15:53.19 | kpfleming | define 'garbage' |
| 15:53.32 | yahh | there is just random data |
| 15:53.43 | kpfleming | where? you have to be *extremely* specific |
| 15:53.50 | kpfleming | did you change the RTP payload, the RTP header, what? |
| 15:54.00 | yahh | i changed both |
| 15:54.07 | yahh | header and paload |
| 15:54.24 | yahh | and filled some random string |
| 15:54.35 | Corydon76-lap | You're just using a fuzzer? |
| 15:54.36 | kpfleming | then the only way anyone could tell you whether the resulting packets should be ignored or not would be to know the exact changes you made |
| 15:54.58 | ctooley | I'm still fuzzy on the rationale here. |
| 15:55.25 | yahh | so on asterisk2 it should be ignored |
| 15:55.27 | Corydon76-lap | ctooley: probably security |
| 15:55.32 | yahh | but it is not happening |
| 15:55.37 | kpfleming | i think he's trying to figure out whether asterisk will ignore incoming broken RTP |
| 15:55.48 | kpfleming | but without knowing exactly what he changed, we can't answer that question |
| 15:56.05 | *** join/#asterisk-dev errotan (n=errotan@62.201.123.242) |
| 15:56.24 | Corydon76-lap | yahh: best thing for you to do is to run wireshark and analyze the RTP packets that way |
| 15:56.41 | Corydon76-lap | yahh: they may be random, but even a blind squirrel occasionally finds a nut |
| 15:57.07 | yahh | yes i have checked |
| 15:57.32 | Corydon76-lap | IOW, you can't guarantee that the RTP headers don't occasionally make sense (even if the payload is still garbage) |
| 15:57.39 | yahh | i capture it in wireshark they are just shows malformad packet |
| 15:57.54 | Corydon76-lap | ALL malformed packets, or just most of them? |
| 15:58.21 | Corydon76-lap | because an occasional good header will screw with the endpoint |
| 15:58.31 | yahh | not all aroud 50% are real pakcet and 50% malformed |
| 15:58.43 | Corydon76-lap | Well, there you go |
| 15:59.18 | kpfleming | yahh: did you modify existing packets that were already headed to asterisk2, or create new ones? |
| 15:59.42 | yahh | i created new one |
| 15:59.50 | kpfleming | you are positive |
| 15:59.55 | kpfleming | you did not modify any of the existing packets |
| 16:00.16 | seanbright | with a random string only 50% are malformed? i find that hard to believe. |
| 16:00.18 | yahh | no, not existing packet...they are all as it is |
| 16:00.38 | yahh | say for example |
| 16:00.44 | kpfleming | and you preserved the *entire* state of the RTP stack when you did this, so that the next correct packet would still be properly created? |
| 16:00.54 | yahh | every 20 ms rtp packet is being sent |
| 16:01.48 | yahh | so in between at 10 ms and then 30 ms.. the garbage packet will be generated |
| 16:01.58 | yahh | and set to the asterisk2 |
| 16:02.13 | kpfleming | but if you just send another RTP packet, you'll cause the sequence numbers to change |
| 16:02.19 | yahh | asterisk RTP stack and STATE will remain as it is |
| 16:02.32 | kpfleming | well, without seeing your code, we can't believe that to be true |
| 16:02.35 | yahh | on asterisk1 |
| 16:03.25 | yahh | now problem is |
| 16:03.38 | yahh | phone2 is connected with asterisk2 |
| 16:03.54 | kpfleming | we understand waht the problem is |
| 16:03.59 | kpfleming | you dont' need to keep repeating yourself, slowly |
| 16:04.01 | yahh | asterisk2 not ignoring those packets and forward to phone2 |
| 16:04.12 | kpfleming | without seeing the changes you have made, there's nothing we can do to help you |
| 16:04.18 | yahh | so there is no proper audio on phone2 |
| 16:04.27 | kpfleming | screams |
| 16:04.40 | seanbright | yahh: upload a patch to a pastebin |
| 16:04.47 | seanbright | otherwise you are on your own |
| 16:05.56 | yahh | i dont know how to do that |
| 16:06.11 | yahh | plz explain |
| 16:06.32 | seanbright | ~pb |
| 16:06.32 | infobot | [~pb] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste , or , http://bin.cakephp.org/, or apt-get install pastebinit |
| 16:06.32 | seanbright | grrr |
| 16:07.25 | yahh | ok let me do that |
| 16:07.33 | seanbright | ok. i will let you. |
| 16:07.46 | kpfleming | seanbright: meanie :-) |
| 16:07.51 | seanbright | heh |
| 16:07.54 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:07.55 | seanbright | it's part of my charm |
| 16:10.59 | Corydon76-lap | Your lucky charm? |
| 16:11.22 | Corydon76-lap | is after seanbright's lucky charm |
| 16:12.28 | seanbright | heh |
| 16:12.43 | Corydon76-lap | c'mon, with a setup like that.... |
| 16:12.56 | putnopvut | I would say that sounds like innuendo, but I never know if that's actually intended when it's Corydon76-lap saying it. |
| 16:13.12 | Corydon76-lap | putnopvut: Think Austin Powers |
| 16:14.06 | yahh | guys here is the code http://pastebin.com/m42dc461f |
| 16:14.17 | *** join/#asterisk-dev thansen (n=thansen@76.27.110.194) |
| 16:16.43 | seanbright | yahh: what file is this? main/rtp.c? |
| 16:16.49 | yahh | yes |
| 16:16.58 | seanbright | because i don't find sleep_rtp_thread in main/rtp.c in 1.4.24.1 |
| 16:17.08 | kpfleming | ok, so i suspect in your case that the two RTP streams are P2P bridged, right? |
| 16:17.20 | yahh | i have declared |
| 16:18.19 | yahh | this code will not generate actual RTP stream |
| 16:18.24 | kpfleming | we know that |
| 16:18.31 | kpfleming | stop telling us what you have already told us four times already |
| 16:18.35 | yahh | yes you are rigjt |
| 16:18.44 | kpfleming | you already send messages very slowly, we don't want you waste them :-) |
| 16:18.47 | yahh | i am sorry kpfleming |
| 16:19.03 | kpfleming | ok, in P2P modem, asterisk does even less RTP sanity checking on the incoming frames than its does in non-P2P mode |
| 16:19.10 | kpfleming | it relies on the other RTP endpoint to do it |
| 16:19.20 | kpfleming | but it could probably use some improvement |
| 16:19.55 | kpfleming | you would need to look at bridge_p2p_rtp_write in rtp.c to figure out how it could decide not to forward the malformed packets onwards |
| 16:20.28 | yahh | ok.. |
| 16:22.21 | yahh | on asterisk2 the function ast_rtp_read(struct ast_rtp *rtp) is being called |
| 16:23.18 | kpfleming | of course it is |
| 16:23.24 | kpfleming | that's what reads incoming RTP frames |
| 16:23.31 | yahh | in around 60-70% of time it throws "TP Read too short (%d, expecting %d)" error |
| 16:23.40 | kpfleming | oh wait, i see your point |
| 16:23.46 | kpfleming | no, that's wrong |
| 16:23.48 | kpfleming | never mind |
| 16:23.52 | yahh | and retun this function with ast_null_frame |
| 16:23.57 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 16:24.08 | kpfleming | yes, that is expected and normal if the frame you sent is too short |
| 16:24.51 | yahh | but in this case asterisk should not forward that packet to phone2 |
| 16:25.27 | yahh | ohh just min |
| 16:25.51 | yahh | is that forwarding "silent packet" to phone2 ? |
| 16:26.36 | kpfleming | no |
| 16:26.46 | kpfleming | when ast_read gets back a null frame from ast_rtp_read, it drops it |
| 16:27.15 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 16:27.15 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 16:27.42 | yahh | so audio should work properly |
| 16:27.55 | yahh | i also did one thing |
| 16:28.03 | kpfleming | for the frames thate are dropped because they are too short |
| 16:28.16 | kpfleming | but if the garbage frames are not too short, they could still get forwarded |
| 16:28.56 | yahh | in ast_rtp_read just in inital part i have identified my frame with size |
| 16:29.11 | yahh | and return ast_null_frame |
| 16:29.26 | yahh | still audio is not coming proper |
| 16:29.33 | kpfleming | that does not make any sense |
| 16:29.47 | yahh | how can i over come from this |
| 16:30.26 | kpfleming | well, nobody has ever claimed that asterisk was resistant to malformed RTP packets arriving on a socket.. if you want it to be, you'll have to do some work to improve the RTP stack |
| 16:31.09 | yahh | yes i will work for that |
| 16:31.23 | yahh | but i need some guidence.. |
| 16:31.38 | kpfleming | we don't have guidance |
| 16:31.46 | kpfleming | if we did, we'd just write the code |
| 16:32.02 | seanbright | that is bumper sticker worthy |
| 16:32.11 | kpfleming | you'll need to write code in ast_rtp_read to do a sanity check on the incoming RTP frames before doing any further processing |
| 16:32.29 | kpfleming | this did make me thing of something we could improve, though |
| 16:32.35 | kpfleming | seanbright: want a relatively small project? |
| 16:32.42 | seanbright | kpfleming: no sir. |
| 16:32.44 | seanbright | :) |
| 16:32.57 | kpfleming | darn |
| 16:33.01 | seanbright | i have 0 side-work time right now |
| 16:33.12 | file | has infinite time |
| 16:33.32 | kpfleming | file: you can do it while you are packing! |
| 16:33.52 | file | all those computers are packed ^_^ |
| 16:33.58 | kpfleming | darn |
| 16:34.09 | kpfleming | so who i am going to tell to do this? |
| 16:34.12 | kpfleming | someone needs to do it |
| 16:34.15 | seanbright | heh |
| 16:34.24 | file | kpfleming: jpeeler! |
| 16:34.26 | seanbright | tell kevin to do it |
| 16:34.34 | seanbright | he's not doing anything but IRCing anyway |
| 16:34.34 | kpfleming | kevin is full of fail, he can't do it |
| 16:34.37 | seanbright | ah. |
| 16:34.40 | Qwell | kpfleming: such a nub |
| 16:34.50 | kpfleming | ooh... Qwell could do it |
| 16:34.54 | Qwell | ha |
| 16:34.56 | kpfleming | if he wanted to flex his mad coding skillz |
| 16:35.57 | Corydon76-lap | Ask this Kevin: http://as7.disneystore.com/is/image/DisneyShopping/200038?$full$ |
| 16:36.15 | seanbright | wtf is that? |
| 16:36.20 | kpfleming | that's odd |
| 16:36.42 | Corydon76-lap | It's from the movie I saw this weekend |
| 16:36.50 | Corydon76-lap | (Up) |
| 16:37.10 | Corydon76-lap | http://www.disneystore.com/up-up-kevin-plush-18/p/1247114/71025/ |
| 16:37.43 | yahh | what extra i should do apart from identifying packet and return with ast_null_frame |
| 16:40.17 | kpfleming | generate a LOG_DEBUG message, probably |
| 16:40.22 | kpfleming | or maybe even LOG_WARNING |
| 16:41.15 | yahh | that i will to,,,,but to get proper audio? |
| 16:42.51 | kpfleming | you don't need to do anything |
| 16:43.04 | kpfleming | if the 'proper audio' frames were not modified, they will flow through as expected |
| 16:44.36 | yahh | you are right... |
| 16:45.25 | yahh | is there any other thing which i should check, to overcome |
| 16:45.38 | kpfleming | there is no answer to that question |
| 16:45.51 | kpfleming | we can only tell you to deal with idenitifiable problems |
| 16:46.23 | yahh | ok... |
| 16:50.44 | yahh | thank you to all.. |
| 17:12.26 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 17:23.45 | jpeeler | does a hook transition complete event always follow a wink or flash? |
| 17:25.15 | russellb | it shouldn't |
| 17:25.25 | russellb | they shouldn't come together |
| 17:25.30 | russellb | it's either a hook state change or a wink/flash |
| 17:25.43 | russellb | and the debouncing to determine which it is should be going on in DAHDI |
| 17:28.54 | jpeeler | well then what transition is completing if it wasn't the previous event? |
| 17:29.21 | jpeeler | i guess that's too vague to answer |
| 17:30.41 | russellb | ah, hook complete ... |
| 17:31.15 | russellb | i don't know for sure, you'll have to check DAHDI. |
| 17:44.10 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 17:44.10 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 17:45.49 | *** join/#asterisk-dev thansen (n=thansen@76.27.110.194) |
| 17:47.43 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 18:03.33 | eliel | it is possible that the #include "asterisk/something" is searching first in the standard path instead of the local source tree? |
| 18:04.12 | eliel | aah, nono, now i found my problem |
| 18:13.09 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 19:02.06 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 19:02.06 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 19:11.04 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 19:21.14 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 19:21.14 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:36.12 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:36.12 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:02.02 | *** join/#asterisk-dev xpot-mobile (n=james@204-228-153-210.ip.xmission.com) |
| 20:56.38 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 21:06.28 | putnopvut | M15512 |
| 21:06.30 | MuffinMan | [new] [Asterisk] Core/General 0015512: Deadlock between ast_cel_report_event and ast_do_masquerade reported by lmsteffan (Karma: neutral) https://issues.asterisk.org/view.php?id=15512 |
| 21:06.44 | putnopvut | That is one of the most bizarre "core show locks" I've ever seen. |
| 21:06.57 | putnopvut | A SIP channel, as it is being created, is being masqueraded into another channel. How odd. |
| 21:07.37 | putnopvut | The channel hasn't even been ao2_linked yet. |
| 21:08.30 | kpfleming | that seems wildly wrong |
| 21:08.35 | russellb | I'm not sure how that's possible |
| 21:08.49 | russellb | based on your description |
| 21:08.59 | putnopvut | take a look at the core show locks. Maybe I'm off my rocker. |
| 21:09.10 | russellb | can't right now |
| 21:11.46 | putnopvut | russellb: I didn't necessarily mean just you. Anyone can take a look at that ridiculousness. |
| 21:15.50 | russellb | nods |
| 21:27.11 | russellb | aw man ... I randomly had a need to go back and find an IRC log, so I went to infobot's log page ... it looks like it keeps about 3 years worth. Had I checked about a week ago, it would have been there. damn. |
| 21:32.46 | Qwell | russellb: lame |
| 21:32.59 | Qwell | I've had that happen with a few things before.. sucks |
| 21:39.28 | putnopvut | So that deadlock appears to be more explainable than I originally had thought. |
| 21:39.33 | putnopvut | Which is good. |
| 21:39.53 | putnopvut | The problem is that I haven't the foggiest how to fix it. |
| 21:53.15 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 22:04.29 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 22:15.20 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 22:23.49 | *** join/#asterisk-dev gpled (n=gpled@firewall.fccfurn.com) |
| 22:24.58 | gpled | has anyone seen a modem, that can read DID numbers passed from the C.O. ? similar to the way modems can read caller id. |
| 22:29.35 | *** part/#asterisk-dev gpled (n=gpled@firewall.fccfurn.com) |
| 22:36.43 | Corydon76-lap | gpled: did numbers aren't passed inband, so it would be impossible for a modem to read it |
| 22:38.53 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 22:38.53 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 22:57.33 | putnopvut | Did the parameter for ast_sched_cb get constified during the mass constification of Asterisk a month or so ago? It seems like in every scheduler callback, a cast is necessary since the pointer does need to be modified. |
| 22:57.44 | putnopvut | Or has this been like this forever and I just never noticed? |
| 23:07.08 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip174-70-137-120.ks.ks.cox.net) |
| 23:23.13 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |