IRC log for #asterisk-bugs on 20090205

00:03.00*** join/#asterisk-bugs matthew___i (n=matthew@adsl-163-41-84.hsv.bellsouth.net)
00:59.29KhratosCorydon76-dig, the provided patch is just for * v1.6.1 ?
00:59.44Corydon76-digon which issue?
01:00.00Corydon76-digI've written a ton of patches today
01:00.35KhratosOh, sorry, about 'broken pipes' when a peer dumbly closes the connection
01:00.41Khratoslet me see the bug num.
01:00.51Khratoshttp://bugs.digium.com/view.php?id=14379
01:01.09Corydon76-digThat one was built out of 1.4, actually
01:01.49Corydon76-dig1.4 trunk
01:01.58Corydon76-digerr, 1.4 SVN
01:02.53KhratosThanks the Lord! , And you of course! xD
01:53.18*** join/#asterisk-bugs Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net)
01:53.18*** mode/#asterisk-bugs [+o Deeewayne] by ChanServ
02:15.14*** join/#asterisk-bugs Khratos (n=Khratos@190.166.113.91)
02:35.19*** join/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb)
02:35.19*** mode/#asterisk-bugs [+o russellb] by ChanServ
02:38.26*** join/#asterisk-bugs matthew___i (n=matthew@adsl-163-35-202.hsv.bellsouth.net)
03:51.12*** part/#asterisk-bugs Khratos (n=Khratos@190.166.113.91)
04:02.35*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
04:02.35*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
08:12.27*** join/#asterisk-bugs bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net)
08:12.27*** mode/#asterisk-bugs [+o bbryant] by ChanServ
08:52.29*** join/#asterisk-bugs matthew___i (n=matthew@adsl-163-35-202.hsv.bellsouth.net)
10:47.01*** join/#asterisk-bugs ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br)
11:39.45*** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim)
11:47.58*** join/#asterisk-bugs ChanServ (ChanServ@services.)
11:47.58*** mode/#asterisk-bugs [+o ChanServ] by irc.freenode.net
12:13.43*** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982)
12:29.25*** join/#asterisk-bugs bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net)
12:29.25*** mode/#asterisk-bugs [+o bbryant] by ChanServ
12:55.41*** join/#asterisk-bugs anonymouz666 (n=anonymou@189.24.79.73)
13:02.50*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
13:02.50*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
13:06.43anonymouz666lmadsen: please clarify something to me... I have an issue but I don't know exactly which category it is....
13:07.09anonymouz666it involves libpri+chan_zap+app_queue
13:10.58lmadsenok...
13:14.09*** join/#asterisk-bugs Khratos (n=khratos@190.166.103.180)
13:14.24Khratos'morning
13:15.20lmadsenmorning!
13:15.38lmadsenanonymouz666: were you going to explain the issue? I still don't know what to tell you
13:16.49anonymouz666again? no problem.
13:16.51anonymouz666heh
13:18.24anonymouz666lmadsen: when I have static members in the queue like Zap/g2/6666 and the 6666 is a legacy pbx system and the communication is between ISDN link... app_queue does not call the member.
13:18.44anonymouz666asterisk -> (ISDN) -> siemens -> legacy extensions
13:19.09anonymouz666if you call directly works.
13:19.20anonymouz666Dial(Zap/g2/6666...)
13:20.02anonymouz666and I have EXACTLY the same setup (with legacy pbx) and it works. the ONLY difference is that the communication is done through MFCR2 signalling.
13:28.12*** join/#asterisk-bugs oej (n=olle@ns.webway.se)
13:37.14*** join/#asterisk-bugs guaxinim (n=guaxinim@unaffiliated/guaxinim)
13:48.50lmadsenanonymouz666: then I would blame the thing that is different
13:49.31lmadsenanonymouz666: and I didn't see your explanation before because I wasn't in the room
13:50.27anonymouz666it's interesting case.
13:50.42anonymouz666the different thing doesn't work ONLY if mixed with app_queue.
13:50.53anonymouz666as I said, calling directly works.
13:57.28anonymouz666lmadsen: take a quick look... http://www.pastebin.ca/1326537 maybe something comes to your mind.
14:05.13lmadsenis this a working or non working output you showed me?
14:05.53lmadsenanonymouz666: so you're saying you can't reproduce unless it is going through app_queue?
14:06.50anonymouz666non working.
14:07.05anonymouz666I can't reproduce unlesse it is going through app_queue.
14:07.22anonymouz666I am patching myself app_queue after an idea.
14:07.27lmadsenok cool
14:07.29anonymouz666let's see what happens.
14:07.34lmadsenI'd say just file it under what you feel is most appropriate
14:30.22anonymouz666where's putnopvut?
14:34.59lmadsenit's only 8:30am in HSV
14:35.08lmadsenprobably getting ready for work and having breakfast.
14:35.18lmadsenI don't expect you'll see him for at least another hour at the last
14:46.40anonymouz666lmadsen: this bug is definitely in libpri or chan_zap.
14:47.02lmadsensweet :)
14:47.15anonymouz666app_queue is innocent.
14:48.00anonymouz666I just added a CONTROL FRAME (proceeding) in app_queue.c
14:48.16anonymouz666so we can see now: -- Zap/67-1 is ringing (proceeding)
14:48.35anonymouz666instead of "Dunno what to do with CONTROL FRAME 15"
14:48.57anonymouz666and there is these msgs:
14:48.57anonymouz666-- Channel 0/5, span 3 got hangup request, cause 31
14:48.58anonymouz666-- Nobody picked up in 1000 ms
14:49.18anonymouz666so we have a disconnect from ISDN (cause 31)
14:49.31anonymouz666and then we call a member for just 1 SEC. there is times 0ms.
14:50.00lmadsenya, the "Dunno what to do with CONTROL FRAME 15" was making me think libpri/chan_dahdi
14:51.45anonymouz666Doing a PRI DEBUG I see the whole ISDN signalling. Message type: DISCONNECT (69) [...] < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the remote user (5)
14:52.06anonymouz666now I need to investigate that, since I don't know much about ISDN
14:59.45*** join/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb)
14:59.45*** mode/#asterisk-bugs [+o russellb] by ChanServ
15:36.46*** join/#asterisk-bugs awk_r (n=awk_r@nat/digium/x-49b6bbd5fd5e1f23)
15:53.49*** join/#asterisk-bugs putnopvut (n=putnopvu@nat/digium/x-68f661bb89ac3a3f)
15:53.49*** mode/#asterisk-bugs [+o putnopvut] by ChanServ
16:01.53*** join/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-45c17a16b9793d6d)
16:01.53*** mode/#asterisk-bugs [+o Deeewayne] by ChanServ
16:28.24*** join/#asterisk-bugs The_Boy_Wonder (n=davidvos@nat/digium/x-ac10a94735f5f89e)
16:49.50*** join/#asterisk-bugs bbryant (n=brett@68.208.65.50)
16:49.50*** mode/#asterisk-bugs [+o bbryant] by ChanServ
16:58.57*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
16:58.57*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
17:16.25*** join/#asterisk-bugs codefreeze-lap (n=murf@72.21.67.40)
17:18.23*** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim)
17:34.35Entomologist*** CLOSED (14374) [Applications/app_transfer] Revision 172517 segfault after using A *2 transfer to B and B dial *2
17:34.35EntomologistAssigned to: putnopvut
17:34.35EntomologistReported by: aragon  Karma: 3.75
17:34.35Entomologisthttp://bugs.digium.com/view.php?id=14374
17:34.35Entomologist*********************************************************
17:44.51*** join/#asterisk-bugs oej (n=olle@ns.webway.se)
18:26.07mnicholsonI have a sip bug I would like some comments on (bug 13569).  Basically it is an issue with reinvites.  When one reinvited peer (peer a) responds with a more limited media offer than what was sent to the other peer (peer b), peer b may send media to peer a in a format that was not in peer a's response.
18:27.30putnopvutM13569
18:27.32MuffinMan[feedback] [Asterisk] Channels/chan_sip/CodecHandling 0013569: Asterisk sending the wrong codec on re-invite. reported by bkw918 (Karma: +53.25) http://bugs.digium.com/view.php?id=13569
18:28.11mnicholsonyou will probably want to scroll down and read my last comment as the description for the bug contains inaccurate information
18:31.33putnopvutYour idea of sending the reinvites to each host separately was the first idea that crossed my mind, too. The problem is that neither side of the bridge is aware of the other side. At least from within chan_sip.
18:31.42Corydon76-digfile: ping
18:31.46putnopvutBeing a B2BUA makes the situation a bit difficult.
18:32.37mnicholsonright
18:33.34fileeh?\
18:33.38*** join/#asterisk-bugs implicit (n=bayan@unaffiliated/implicit)
18:33.38*** mode/#asterisk-bugs [+o implicit] by ChanServ
18:35.54fileCorydon76-dig: what do you seek?
18:39.22*** join/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb)
18:39.22*** mode/#asterisk-bugs [+o russellb] by ChanServ
18:46.25oejputnopvut: Well, the directrtpsetup stuff showed how broken our media negotiation is, and videocaps solves part of it
18:46.40oejptunopvut: The problem is that there's only forwarding of offers, but the reply can't be sent back.
18:47.23oejputnopvut: We spent a lot of time with this on astridevcon
18:47.47putnopvutwishes he got to go to astridevcon last year :(
18:47.52oejIn regards to being aware of the other side, check the T.38 code... We peek over the bridge there !
18:48.04putnopvutoh, really? I need to take a look at that.
18:48.22oejBut then we do have a bridge.
18:48.31oejAt re-invite time we do also.
18:48.40putnopvutcorrect
18:49.16oejBut the real core of the problem is that the ANSWER doesn't contain any response
18:49.26oejwe just say "someone answered and everything is tally-ho"
18:49.29oejin video, the answer might be "Yes, but only in portrait mode and black/white with 10x10 pixels"
18:49.48oejAnd we shorten that to a "yes"
18:59.49Corydon76-digfile: I was wondering if you could take a look at 14414, as it is an audiohook issue
19:00.22fileI can tomorrow probably
19:00.36Corydon76-digk, I'll assign it to you, then
19:07.25seanbrightputnopvut: you can go this year
19:07.29seanbrightputnopvut: you're welcome
19:07.50putnopvutSo, here's something interesting. I just committed a fix for a mixmonitor race condition, and as part of it, I used a combination of a boolean flag and condition variable to make sure that threads executed in the proper order. I realize now that I could have used a semaphore instead. Any preference for either method and any reason behind such preference?
19:07.55putnopvutseanbright: thanks!
19:39.27Corydon76-digputnopvut: a semaphore wouldn't work if the sender sent before the receiver was listening, right?
19:40.21putnopvutNope, a semaphore is pretty much just an integer. sem_post increments it, so if sem_wait reaches it, it just won't wait at all if the value is already non-zero.
19:40.40putnopvutI worded that a bit oddly.
19:41.07putnopvutBut essentially, if sem_post has already been called in one thread, then sem_wait in another thread is pretty much a no-op.
19:43.01Corydon76-digSounds nice
19:44.33putnopvutYeah, I just noticed that they weren't used anywhere in Asterisk and so I was wondering if there was some underlying reason why. No real reason to change what I already wrote, but thought I'd bring it up for the next time I write something similar.
20:29.11Entomologist*** CLOSED (14376) [Applications/app_queue] autopause should not pause interfaces that are busy
20:29.11EntomologistAssigned to: putnopvut
20:29.11EntomologistReported by: fiddur  Karma: 0
20:29.11Entomologisthttp://bugs.digium.com/view.php?id=14376
20:29.11Entomologist*********************************************************
20:31.36Corydon76-digSomeone else want to take a look at 14387?
20:32.12putnopvutM14387
20:32.14MuffinMan[feedback] [Asterisk] Resources/res_musiconhold 0014387: mpg123 crashes when trying to play stream. reported by jonnt (Karma: +0.50) http://bugs.digium.com/view.php?id=14387
20:33.47Corydon76-digIt's not actually crashing; he's just not hearing the music that he wants to hear
20:34.27putnopvutThat's a weird thing to call a "crash"
20:34.48Corydon76-digWell, he certainly got my attention
20:35.04Corydon76-digI'm beginning to miss the negative karma
20:35.25putnopvutI was wondering why there were no backtraces attached if there were crashes.
20:36.26putnopvutCorydon76-dig: the one thing that he says that makes me think there's something screwy in Asterisk is that things work in 1.6.0.1 but not in 1.6.0.3 and 1.6.0.5
20:36.31Corydon76-digand if I try it, it works perfectly.  So it's gotta be config related
20:38.57putnopvutCorydon76-dig: the only difference in res_musiconhold.c between 1.6.0.1 and 1.6.0.5 is added error checking...
20:39.08putnopvutno idea what could be going on there,  but I agree that it is config-related.
20:39.52putnopvutIf you think that the problem is due to having no internal timing, it may be that his asterisk.conf file needs to have internal timing enabled.
20:47.54Entomologist*** CLOSED (13673) [Applications/app_voicemail/IMAP] [patch] Addition of a Mailbox id facility to allow shared mailboxes to work
20:47.54EntomologistAssigned to: jpeeler
20:47.54EntomologistReported by: howardwilkinson  Karma: 5.5
20:47.54Entomologisthttp://bugs.digium.com/view.php?id=13673
20:47.54Entomologist*********************************************************
20:52.08putnopvutjpeeler: yay! I'm always thrilled when IMAP bugs are closed by someone other than me :)
20:52.16jpeelerha
20:53.01jpeelerputnopvut: you had already pretty much done all the work on it already
20:53.16jpeelerand i like to repeat myself
20:53.38putnopvutah, I had already forgotten about that issue.
21:02.04putnopvutM14164
21:02.06MuffinMan[acknowledged] [Asterisk] Applications/app_dial 0014164: Dial() option d is not working reported by DennisD (Karma: neutral) http://bugs.digium.com/view.php?id=14164
21:02.19putnopvutThis is a bug where I understand why the problem exists, but I have no idea how to go about solving it.
21:05.42putnopvutThe only solution that comes to mind is to always send a 183 with SDP if we know that a phone is set up for rfc2833 DTMF. But I think that's not ideal.
21:10.08*** join/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb)
21:10.08*** mode/#asterisk-bugs [+o russellb] by ChanServ
21:49.29*** join/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb)
21:49.29*** mode/#asterisk-bugs [+o russellb] by ChanServ
22:35.33*** join/#asterisk-bugs bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net)
22:35.33*** mode/#asterisk-bugs [+o bbryant] by ChanServ
23:19.20Entomologist*** CLOSED (12312) [Channels/chan_sip/Registration] [patch] DNS SRV lookups causing re-registration problems
23:19.20EntomologistAssigned to: putnopvut
23:19.20EntomologistReported by: jrast  Karma: 0
23:19.20Entomologisthttp://bugs.digium.com/view.php?id=12312
23:19.20Entomologist*********************************************************
23:29.26Entomologist*** CLOSED (13905) [Applications/app_voicemail/IMAP] [patch] Messages not marked as read/unread properly when moved from New to Old folder and back.
23:29.26EntomologistAssigned to: putnopvut
23:29.26EntomologistReported by: jaroth  Karma: 20.75
23:29.26Entomologisthttp://bugs.digium.com/view.php?id=13905
23:29.26Entomologist*********************************************************
23:44.06*** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.