| 00:11.53 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:11.53 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 00:17.24 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 00:17.24 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 01:26.43 | *** join/#asterisk-dev kerframil (~kerframil@gentoo/user/kerframil) |
| 01:55.54 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 01:55.54 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 02:49.54 | *** join/#asterisk-dev sshock (~sshock@63.248.133.83) |
| 02:56.58 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 02:56.58 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 04:05.34 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 04:05.35 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 04:54.52 | *** part/#asterisk-dev sshock (~sshock@63.248.133.83) |
| 06:39.28 | *** join/#asterisk-dev alecdavis (~sivad@202-78-149-14.cable.telstraclear.net) |
| 07:18.56 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:27.28 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 07:42.01 | *** join/#asterisk-dev lorenzom (~lorenzo@151.8.202.59) |
| 07:47.28 | *** part/#asterisk-dev alecdavis (~sivad@202-78-149-14.cable.telstraclear.net) |
| 07:56.28 | lorenzom | hi all |
| 08:16.16 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:16.16 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:29.43 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |
| 09:20.34 | *** join/#asterisk-dev ybit2 (~quassel@unaffiliated/ybit) |
| 09:52.18 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 09:54.40 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |
| 11:07.21 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 11:08.32 | *** join/#asterisk-dev c0rnoTa (~c0rnoTa@109.188.77.225) |
| 11:08.43 | c0rnoTa | Hello everyone |
| 11:09.33 | c0rnoTa | I'm using E1 channel to connect to PSTN. Sometimes I get debug messages "Got a FRAME_CONTROL (8) frame on channel DAHDI/". I receive this when call is active and people speaking. The call drops when this message was received. My telco said, that my PBX disconnect the call (send Disconnect frame with cause 16 - normal clear). russellb siad: "control frames are call signaling information ... 8 is Congestion" So, the question is: What is the initiator |
| 11:17.11 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |
| 11:21.06 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 11:21.06 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:21.15 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:21.15 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:55.23 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 12:09.35 | *** join/#asterisk-dev frawd (~francois@113.Red-81-44-76.dynamicIP.rima-tde.net) |
| 12:23.13 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |
| 12:24.37 | *** join/#asterisk-dev rrb3942 (~rbullock@12.180.137.90) |
| 13:07.21 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:07.21 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:28.20 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 13:38.01 | *** join/#asterisk-dev rrb3942 (~rbullock@12.180.137.90) |
| 13:42.26 | jsmith | c0rnoTa: Turn on PRI debugging to see who is causing the call to be hung up |
| 13:43.00 | *** join/#asterisk-dev bklang_ (~bklang@tesla.alkaloid.net) |
| 13:45.05 | *** join/#asterisk-dev moy_ (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 13:49.02 | c0rnoTa | jsmith: thanks for answer. I have already set pri debug. And can show you log. I know that this question must be in #asterisk channel, but on #asterisk i hadn't answer from people. As I thought, it's too complex question, must have deep knowledge of asterisk |
| 13:49.38 | c0rnoTa | jsmith: Here is log of the call: http://pastebin.mozilla-russia.org/107089 |
| 13:50.52 | c0rnoTa | jsmith: and here is 'system state' (part of system log at this moment) http://pastebin.mozilla-russia.org/107090 |
| 13:51.08 | c0rnoTa | jsmith: I uses verbose 6, debug 6 |
| 13:52.18 | jsmith | c0rnoTa: Looks like it your Asterisk box that's sending the DISCONNECT message |
| 13:53.30 | c0rnoTa | jsmith: yes, it's true. But as you can see in pastebin 107089 line 81. The call stop after Got a FRAME_CONTROL (8) frame on channel DAHDI/2-1 |
| 13:53.41 | leifmadsen | waves to jsmith |
| 13:55.16 | c0rnoTa | jsmith: so, this message was received from channel.c. But why it sends my this message, if there was no messages in PRI channel? |
| 13:55.20 | jsmith | Morning leifmadsen... just got off the phone with a fellow Toronto guy... he couldn't figure out how I knew he'd just stopped by Tim Horton's for a double-double |
| 13:56.35 | jsmith | c0rnoTa: I'm not sure where that frame control message came from either :-( |
| 13:56.50 | leifmadsen | jsmith: lol |
| 13:56.55 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:56.55 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:57.02 | leifmadsen | jsmith: too funny -- I don't use sugar in my coffee though as I don't like the taste |
| 13:57.08 | jsmith | leifmadsen: He was like "How did you know?" |
| 13:57.20 | leifmadsen | jsmith: were you like "oh, I've been to Toronto before" :) |
| 13:57.28 | leifmadsen | the line ups get stupid sometimes |
| 13:57.34 | leifmadsen | it's not even good coffee! |
| 13:59.06 | c0rnoTa | jsmith: do you know where i can get answer for my question? |
| 14:01.32 | jsmith | leifmadsen: The donuts are good though :-) |
| 14:01.44 | jsmith | c0rnoTa: Sorry... I don't know what else to tell you |
| 14:03.14 | *** join/#asterisk-dev eugeneoden (~goden@rrcs-97-77-255-86.sw.biz.rr.com) |
| 14:03.58 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 14:08.11 | leifmadsen | jsmith: :) |
| 14:09.39 | jsmith | Mmmmn... donuts. |
| 14:09.46 | jsmith | needs another breakfast |
| 14:12.57 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:12.57 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:26.26 | *** join/#asterisk-dev eugeneoden (~goden@rrcs-97-77-255-86.sw.biz.rr.com) |
| 14:56.23 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 14:56.23 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:10.20 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:10.20 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:20.26 | *** join/#asterisk-dev Corydon76-lap (~Adium@nat/digium/x-nqzetgfjvbrkeoqr) |
| 15:20.26 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 15:33.00 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |
| 16:03.42 | *** join/#asterisk-dev eugeneoden (~goden@rrcs-97-77-255-86.sw.biz.rr.com) |
| 16:13.28 | *** join/#asterisk-dev BesticlesWork (~larry@209-58-227-178.static-ip.telepacific.net) |
| 16:18.23 | *** join/#asterisk-dev miguel3239 (~miguel323@12.187.84.162) |
| 16:53.21 | *** join/#asterisk-dev mpe_ (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 16:55.01 | *** join/#asterisk-dev eugeneoden (~goden@rrcs-97-77-255-86.sw.biz.rr.com) |
| 16:58.11 | *** join/#asterisk-dev frawd (~francois@113.Red-81-44-76.dynamicIP.rima-tde.net) |
| 17:11.16 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:11.16 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:58.02 | *** join/#asterisk-dev ybit2 (~quassel@unaffiliated/ybit) |
| 19:02.22 | *** join/#asterisk-dev hehol (~Adium@ip-78-94-0-76.unitymediagroup.de) |
| 19:21.21 | kpfleming | The_Boy_Wonder: is your question on -dev about RCTP receiver reports or sender reports? |
| 19:21.35 | kpfleming | s/RCTP/RTCP/ |
| 19:26.54 | The_Boy_Wonder | kpfleming: I send reports |
| 19:27.00 | The_Boy_Wonder | wow |
| 19:27.07 | The_Boy_Wonder | that came out really weird |
| 19:27.14 | The_Boy_Wonder | kpfleming: sender reports |
| 19:27.41 | The_Boy_Wonder | i said "sender reports" in my mind, but typed "i send reports" |
| 19:27.48 | kpfleming | ok |
| 19:28.09 | kpfleming | so yes, changing the SSRC in the sender reports when the stream we are sending has changed SSRC does make sense |
| 19:28.27 | kpfleming | i don't know enough about RTCP to know whether a Bye should be sent or not |
| 19:28.46 | kpfleming | but it's pretty crazy that x-lite drops a call because the other end stopped sending SRs |
| 19:28.59 | The_Boy_Wonder | yeah, it seems odd |
| 19:29.15 | The_Boy_Wonder | especially to have that option on by default |
| 19:30.08 | kpfleming | right |
| 19:30.45 | kpfleming | the people at counterpath have been fairly helpful in the past, although i don't know how many of the people we knew are still there... but it probably wouldn't hurt to ask them what they are expecting |
| 19:35.22 | The_Boy_Wonder | kpfleming: how have we communicated with them in the past? Has it always been through someone directly |
| 19:35.56 | kpfleming | it's been quite a while... and two people i used to work with there are gone |
| 19:36.19 | kpfleming | but i suspect just emailing their support people would get it escalated to the right people |
| 19:36.29 | The_Boy_Wonder | cool, thanks |
| 19:47.59 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 19:59.54 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 20:03.21 | *** join/#asterisk-dev erinspice (~erin@207.98.195.107) |
| 21:21.24 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 21:21.24 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:40.18 | Qwell | So, ast_call_forward() takes a timeout parameter. which it sets to the return value of ast_call(). That seems quite wrong. The timeout would end up being set to 0 on a successful forward. |
| 21:40.36 | russellb | maybe 0 means no timeout? |
| 21:40.53 | Qwell | yes, exactly. which breaks the loops that all of its callers are in |
| 21:41.01 | Qwell | which means it gets no frame...which means it hangs up. |
| 21:41.13 | Qwell | or, no timeout as in none. no |
| 21:41.51 | Qwell | Check out __ast_request_and_dial(), where it calls ast_call_forward() |
| 21:45.08 | Corydon76-lap | Qwell: what would occur if the timeout were specified as â1? No timeout? |
| 21:45.31 | Qwell | where? |
| 21:45.53 | Qwell | passed into __ast_request_and_dial() as -1? |
| 21:47.26 | Corydon76-lap | Right |
| 21:47.36 | Qwell | got me |
| 21:47.52 | Corydon76-lap | Looks like request_and_dial makes â1 be the actual 'no timeout' value |
| 21:48.05 | Qwell | that isn't relevant to my issue |
| 21:49.01 | *** join/#asterisk-dev mpe_ (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 21:49.06 | Corydon76-lap | I don't see where it is using the return value of ast_call() |
| 21:49.14 | Qwell | in ast_call_forward |
| 21:49.30 | Qwell | if ((*timeout = ast_call(new, data, 0))) { |
| 21:50.25 | *** part/#asterisk-dev mpe_ (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 21:53.47 | Corydon76-lap | Ah, still not following how that would make it hangup, though |
| 21:55.06 | Qwell | ast_pbx_outgoing_exten() is the caller. Since the channel isn't up, as it needs to be when exiting __ast_request_and_dial(), it'll hang it up. |
| 21:55.39 | Qwell | The new channel is never given the opportunity to answer. |
| 21:55.48 | Corydon76-lap | Ah |
| 21:56.10 | Qwell | So I assert that ast_call_forward() is dumb, and doesn't need a timeout param at all. |
| 21:57.39 | Corydon76-lap | svn blame to the rescue |
| 22:06.38 | Qwell | Hrm. I probably aughtn't just remove the timeout arg, for API breakage reasons. |
| 22:12.04 | kpfleming | correct |
| 22:14.10 | russellb | you break API, I break YOU! |
| 22:15.07 | Qwell | So then, what.. stop passing in timeout, only set it if passed in, and let the people doing so continue to be broken? |
| 22:16.05 | Corydon76-lap | What if you just don't set timeout to anything? |
| 22:16.26 | Corydon76-lap | pass in the parameter, then do nothing with it |
| 22:16.46 | Qwell | That would be breaking the API, as other callers could be expecting it to change. |
| 22:17.32 | Corydon76-lap | Possible, but the return value of ast_call is of little use as a timeout value, right? |
| 22:18.26 | Qwell | Not as a timeout, no. But, it's being set to something. Somebody somewhere could be using it as...something. Incorrectly. |
| 22:19.41 | Corydon76-lap | Well, then they're using it contrary to the definition of the API and should not be surprised if it breaks... |
| 22:20.27 | kpfleming | you are talking about two difffernt things |
| 22:20.29 | Corydon76-lap | We should be able to fix things that are just broken. If the parameter should have been something else, then they should have changed the definition to match |
| 22:20.37 | kpfleming | he's not suggesting changing ast_call() at all |
| 22:20.44 | Corydon76-lap | No, I know |
| 22:21.04 | kpfleming | does the timeout parameter of ast_call_forward() have any useful purpose? |
| 22:21.05 | Corydon76-lap | I'm suggesting not assigning the return value of ast_call to the timeout parameter in ast_call_forward |
| 22:21.13 | Qwell | kpfleming: no |
| 22:21.34 | kpfleming | but the code is currently inspecting it? |
| 22:21.37 | Qwell | well.. not *correctly* useful. |
| 22:21.48 | Qwell | ast_call_forward() does not inspect it. It only sets it. |
| 22:22.19 | kpfleming | so how does passing in the result of ast_call() affect it then? |
| 22:22.53 | Corydon76-lap | It's setting timeout to the return value of ast_call |
| 22:22.54 | Qwell | ast_call_forward(args, int *timeout) is calling *timeout=ast_call() |
| 22:23.08 | kpfleming | oh |
| 22:23.37 | kpfleming | yeah, that seems risky to change without making it obvious it has changed |
| 22:23.44 | Qwell | then the caller of ast_call_forward() says "hey, timeout is now 0. give up!" |
| 22:24.45 | Qwell | http://pastebin.com/8sBXzy3w |
| 22:25.00 | Qwell | Then __ast_request_and_dial() can just pass in NULL, and be happy. |
| 22:25.07 | kpfleming | if the parameter is really of no value (because the result of ast_call() itself is not valuable), then you can make a new version of the API call that doesn't take the parameter, and fix the in-tree uses of it |
| 22:25.43 | kpfleming | yeah, that seems OK too |
| 22:26.06 | kpfleming | or __ast_request_and_dial() could pass a pointer to a throwaway variable |
| 22:26.10 | kpfleming | but this seems better |
| 22:26.22 | russellb | Qwell: if (timeout), not if (*timeout) |
| 22:26.43 | russellb | otherwise, seems fine |
| 22:27.09 | russellb | if timeout == NULL, then if (*timeout) go boom |
| 22:28.19 | Qwell | right, of course |
| 23:28.55 | *** join/#asterisk-dev pabelanger (~pabelange@2607:f2c0:a000:166:218:f3ff:fe51:c71) |
| 23:28.55 | *** join/#asterisk-dev Mirell (~mmiller@maetel.mirell.org) |
| 23:28.56 | *** join/#asterisk-dev micols (~mio@rlogin.dk) |
| 23:41.58 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 23:41.58 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |