| 00:13.35 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 00:13.35 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 01:00.26 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 01:28.24 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 02:01.09 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 02:07.00 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 05:49.11 | *** join/#asterisk-dev irroot (~gregory@197.104.216.5) |
| 06:18.04 | *** join/#asterisk-dev luckman212 (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 07:43.55 | *** join/#asterisk-dev Tim_Toady (~fuzzy@188.4.1.11.dsl.dyn.forthnet.gr) |
| 08:01.27 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 08:26.24 | *** join/#asterisk-dev irroot (~gregory@197.106.2.32) |
| 09:20.26 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 09:20.55 | *** join/#asterisk-dev _ys (~Miranda@HS3-193-3.xG.SPb.SkyLink.RU) |
| 09:30.59 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:30.59 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:35.50 | *** join/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 09:45.57 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 09:45.59 | schmidts | good morning |
| 09:53.38 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-zncztvlgcxwtrucs) |
| 09:53.38 | *** mode/#asterisk-dev [+o mnicholson] by ChanServ |
| 09:56.06 | *** join/#asterisk-dev sustav (~alfa@nat/digium/x-knlgcrnnqezdwslg) |
| 10:06.34 | *** join/#asterisk-dev irroot (~gregory@197.105.85.40) |
| 10:07.35 | schmidts | anybody allready awaken and can help me? |
| 10:07.54 | schmidts | a typical unsigned char * on a 64bit debian machine is how big? |
| 10:08.06 | schmidts | imho 8 bit right? |
| 10:08.12 | *** join/#asterisk-dev _ys (~Miranda@HS3-193-228.xG.SPb.SkyLink.RU) |
| 10:09.33 | schmidts | cause i am very confused about the data i get from the coredump and i try to understand what happend there |
| 10:09.44 | schmidts | atleast something nearly impossible happend |
| 10:16.13 | wdoekes2 | schmidts: pointers are usually of the same size |
| 10:16.32 | wdoekes2 | 64bit on 64 bit machines |
| 10:17.05 | schmidts | ok thats what i had in my mind but i wasnt sure |
| 10:17.17 | schmidts | its still the problem from yesterday i had, and i dont get why this could happens |
| 10:17.56 | schmidts | i have this value: (void *) 0x7ffd107ecbf0 which is casted into an unsigned char * var and the result is 0xfffffffffffffff4 |
| 10:18.26 | schmidts | what i just dont understand is the value of 0xfffffffffffffff4 which would be 17 bits? |
| 10:19.42 | wdoekes2 | ? |
| 10:19.49 | wdoekes2 | (1) you're not looking at the cast |
| 10:21.29 | wdoekes2 | (2) that number is 64 bits: >>> len('%x' % (0xfffffffffffffff4,)) |
| 10:21.29 | wdoekes2 | 16 |
| 10:21.50 | wdoekes2 | (16 nibbles) |
| 10:22.14 | schmidts | sooorry fuck ok i need more coffeee |
| 10:22.17 | schmidts | stupid me |
| 10:22.26 | schmidts | base 2 != base 16 ;) |
| 10:22.47 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 10:22.51 | schmidts | ok thanks wdoekes2 |
| 10:23.21 | schmidts | but then there is still the question why this could happens or in what special situation |
| 10:23.26 | wdoekes2 | as for your problem.. the big problem I see is that the returned s->f shouldn't point at the same thing as the frame passed to rtp_write |
| 10:24.39 | wdoekes2 | can I take a quick gdb tour through that dump |
| 10:25.17 | schmidts | sure what do you need? |
| 10:25.32 | wdoekes2 | shell access |
| 10:25.51 | schmidts | ok, i need your ip from where you want to connect |
| 10:25.56 | wdoekes2 | vpn.mc.osso.nl |
| 10:33.17 | *** join/#asterisk-dev ixyd_ (~denzs@carbon.gonicus.de) |
| 10:33.48 | ixyd_ | hi guys, iam restructuring my dialplan to only use subs instead of macros (i know 1.8 is already doing this all the time)... iam wondering about the following warning: "....application call to GoSub affects flow of control...." can someone tell me if there is a real reason not to use gosub directly? |
| 10:35.25 | schmidts | i guess this means something different, maybe you want to use goto inside the sub? |
| 10:38.33 | ixyd_ | you mean goto to enter the sub? |
| 10:38.53 | schmidts | this or a goto in the sub |
| 10:39.10 | ixyd_ | there are no gotos in my subs... |
| 10:40.33 | schmidts | give me a second i will take a look |
| 10:40.55 | ixyd_ | thank you! :) |
| 10:41.10 | schmidts | do you use ael or extensions.conf? |
| 10:41.29 | ixyd_ | ael |
| 10:41.35 | ixyd_ | thats the problem ;) |
| 10:41.36 | schmidts | aaahh ok |
| 10:41.41 | schmidts | looks like ;) |
| 10:42.49 | ixyd_ | it seems there is no "official" way to use something like a function (macro, sub, whatever...) which can retrieve arguments and generate usable CDRs by not breaking the dst by something stupid like "~~s~~" ... :( |
| 10:43.39 | ixyd_ | the only way i see is using subs with explicit gosub calls in my ael, and use "_. " as exten in the subs, so i can pass the original exten to the sub....then the behaviour is mostly like macros in 1.4 |
| 10:44.05 | ixyd_ | but thats kinda disappointing :( |
| 10:44.22 | ixyd_ | or at least the i have to understand the warning i mentioned ;) |
| 10:54.33 | schmidts | sorry i have never used ael so i have no idea ;9 |
| 11:05.10 | ixyd_ | hehe i see thank you |
| 11:33.23 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 11:35.13 | *** join/#asterisk-dev IsUp (~nocturne@unaffiliated/isup) |
| 11:35.23 | IsUp | hello |
| 11:36.02 | schmidts | hi isup |
| 11:40.06 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:40.06 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:57.38 | schmidts | its sometimes real fun to read through the code : * there is no telling what will happen, <insert mad scientist laugh here>!!! */ |
| 12:04.36 | IsUp | i have a issue, should i share pcap and my log here? |
| 12:04.45 | IsUp | because i want to discuss it before posting it to JIRA |
| 12:05.04 | IsUp | or maybe this is not a bug at all. so i want to be sure. may anyone help me? |
| 12:06.17 | schmidts | isup depends on your issue ;) |
| 12:07.01 | IsUp | ok, i'll do my best to explain. i know my English is not perfect but i'll try, 1 sec |
| 12:33.45 | IsUp | schmidts: may i paste url to my webserver? i have captures and logs |
| 12:41.23 | kpfleming | until you have described the problem you are having and someone has expressed interest in helping you, there's no value in posting a URL to packet captures/logs |
| 12:45.23 | IsUp | kpfleming: erm, basicly i cant detect SIP hangups from my provider. my pbx handles 4k~ calls per day. its only happens in 3-4 calls. |
| 12:45.38 | tzafrir | The AST-2011-013 does not mention CVE id: CVE-2011-4597 |
| 12:45.52 | IsUp | kpfleming: ive captured problematic call, i have asterisk log and i have call recordings from both legs |
| 12:46.51 | IsUp | kpfleming: when i listen these audio recordings, caller is hanging up in the middle of call. but channel is alive and i can hear my agent is talking. so channel looks bridged, SIP -> ZAP, but only ZAP is getting audio. also caller is already gone. |
| 12:47.12 | IsUp | here is my asterisk log: http://178.162.250.30/debug/call-log.txt i've tried to explain here step-by-step |
| 12:50.43 | IsUp | also, if needed i can share audio recordings. ive analyzed them in sound forge to be sure if caller is here or not. but im %100 sure caller is already hanged up. i'll get CDRs from my provider today. they are using Asterisk on their side too. so i'll match CDRs. our CDR looks 3550 seconds, but i am sure call is only 6-7 minutes. |
| 12:51.36 | *** join/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 12:52.41 | IsUp | also this is the screenshot of capture, if you see "Arrival Time" in packet list, theres a "space" between 19:02 and 20:01. http://178.162.250.30/debug/capture2.png |
| 12:54.20 | IsUp | i've suspected this if its related to my problem: https://issues.asterisk.org/view.php?id=18935 because all my calls are going to AGI. AGI handles everything. ive captured AGI Server <-> Asterisk socket too. communication looks okay. |
| 12:55.48 | IsUp | and one last info, i am running Asterisk 1.4.31, i dont know my provider. i'll ask their assistance too. if you need any info/file/capture please tell me, i can provide anything |
| 13:14.56 | kpfleming | IsUp: this is far too complicated for someone to help you in real-time. you need to post on the asterisk-users mailing list with as many details as you can provide. |
| 13:19.24 | schmidts | kpfleming ever heard of a problem that frame->data.ptr is set to NULL while frame is handled in ast_rtp_write ? |
| 13:29.01 | kpfleming | you are saying that ast_rtp_write changed the data pointer to NULL, or that it was NULL on entry to that function? |
| 13:31.20 | schmidts | kpfleming nope none of both ;) i can see in gdb that it was not null when entering ast_rtp_raw_write (where the segfault happend) but after rtpheader is initialised |
| 13:31.39 | schmidts | rtpheader = (const char *) frame->data.ptr - 12; |
| 13:33.50 | schmidts | what i meant it was null when rtpheader gets the value from it |
| 13:34.13 | kpfleming | nope, that's nothing i've heard of before |
| 13:34.44 | schmidts | ok ;) thanks |
| 13:35.04 | schmidts | maybe it was just a stupid memory corruption and has nothing to do with asterisk or rtp itself |
| 13:36.13 | kpfleming | maybe, although those are pretty rare |
| 13:38.18 | schmidts | i really hope so ;) |
| 13:43.28 | *** join/#asterisk-dev irroot (~gregory@197.174.87.11) |
| 14:01.08 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.16.145) |
| 14:02.26 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-sjyfhfxfnovrjvne) |
| 14:16.04 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-meokifilbigudcaz) |
| 14:16.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:44.33 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-wwhplvnwfgakbwij) |
| 14:48.26 | *** join/#asterisk-dev irroot (~gregory@41.53.212.37) |
| 15:06.16 | *** join/#asterisk-dev irroot (~gregory@197.107.158.211) |
| 15:28.48 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:28.48 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:37.45 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:37.46 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:39.09 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:39.09 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:40.58 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:40.58 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:56.04 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:56.05 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:07.11 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 16:07.17 | jmls | afternoon all |
| 16:22.10 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:34.44 | anonymouz666 | [Dec 15 14:34:33] ERROR[1597] chan_iax2.c: maxcallnumber limit of 2048 for 172.30.130.10 has been reached! |
| 16:34.47 | anonymouz666 | this is new to me :) |
| 16:36.06 | anonymouz666 | specially because 2048 is a very high number |
| 16:43.32 | pabelanger | #asterisk |
| 18:51.48 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-uovmthxlwuuwcvtg) |
| 18:51.49 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:13.45 | *** join/#asterisk-dev outtolunc (~outtolunc@c-76-21-78-122.hsd1.ca.comcast.net) |
| 20:04.03 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 20:04.04 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:14.17 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 20:43.31 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 21:59.31 | leifmadsen | Both Asterisk 1.8.8.0 and Asterisk 10.0.0 have just been released! Release announcements at http://www.asterisk.org/node/51696 and http://www.asterisk.org/node/51697 |
| 22:07.12 | The_Boy_Wonder | ! |
| 22:12.55 | jsmith | leifmadsen: Look at you go... |
| 22:13.31 | leifmadsen | jsmith: weeeeee! |
| 22:22.57 | *** join/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 22:30.59 | jmls | congrats guys |
| 22:31.20 | jmls | back to business ;) |
| 22:32.36 | jmls | now, is there anywhere that documents the input / output data that hits the tcp socket in fastagi ? I know that there are some client libraries, but was wondering what the official documentation state was .. |
| 22:32.58 | kpfleming | it's AGI, just over a TCP socket instead of a pipe |
| 22:37.20 | jsmith | And there's sample code in the agibin directory, as I recall |
| 23:29.21 | *** join/#asterisk-dev Micc_ (~Micc@c-24-19-33-189.hsd1.wa.comcast.net) |
| 23:29.57 | Micc_ | so I think I've found where this bug is happening. is there someone who can look into something with me in chan_sip? |
| 23:30.19 | Micc_ | this is in 1.6.2.20 and in 1.8.8.0 |
| 23:30.29 | mjordan | micc_: sure |
| 23:31.33 | mjordan | where do you think it is in chan_sip? |
| 23:31.41 | mjordan | specifically, the 1.8 branch |
| 23:31.46 | Micc_ | in set_address_from_contact |
| 23:32.34 | Micc_ | ok so here is my problem. |
| 23:33.24 | Micc_ | when I dial a peer without an extension it uses the internal ip, but when I dial a peer with an extension the to and contact headers use the external ip. so the device ignores the invite |
| 23:34.08 | Micc_ | and I think the reason is this if statement here that uses the address the peer is registering from instead of the contact field. |
| 23:35.00 | Micc_ | so my question is why is it saying don't trust the contact field when its nat? It seems to me I could fix this problem by just commenting out the whole if there. |
| 23:35.11 | Micc_ | but I'm not sure what other problems that will cause. |
| 23:35.12 | kpfleming | what does 'with an extension' mean? can you provide an actual example instead of trying to explain it? |
| 23:37.23 | Micc_ | I mean SIP/peer/1234 instead of SIP/peer in the dial command. |
| 23:37.59 | Micc_ | http://pastebin.com/LYS7MvTv |
| 23:38.17 | Micc_ | theres the sip debug output for two calls one with SIP/peer and one with SIP/peer/number |
| 23:38.27 | kpfleming | when you dial a SIP endpoint and provide the target URI, Asterisk cannot use the previously-registered Contact URI, because that is also a target URI. the INVITE cannot have two target URIs. |
| 23:38.35 | Micc_ | and you can see one has 10.1.10.1 and the other has the external ip. |
| 23:38.52 | *** part/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 23:39.00 | kpfleming | it's quite unusual to have a device register to you and then also provide a target URI when you dial to it |
| 23:39.49 | Micc_ | I don't know what you mean by target URI, but I don't think its doing anything any different that any other device that registers. |
| 23:39.59 | kpfleming | yes, it's quite different. |
| 23:40.22 | kpfleming | when a SIP device registers, it provides a Contact URI, which might look like "sip:4567@x.x.x.x:5060". |
| 23:40.32 | Micc_ | its behind nat obviously, so the reg contact uses the internal ip. Thats what all the phones that register with our server do. |
| 23:40.57 | kpfleming | when you dial that device, Asterisk will use the Contact URI to construct the outbound INVITE's Request URI (target URI). |
| 23:41.16 | kpfleming | that's the 'normal' behavior for a device that registers. |
| 23:41.22 | kpfleming | with me so far? |
| 23:41.22 | Micc_ | when it registers it has this Contact: <sip:waldimports1@10.1.10.10:5060;transport=UDP> |
| 23:41.29 | kpfleming | right |
| 23:42.33 | Micc_ | isn't that correct? do you want to see the full register that it is sending? |
| 23:42.36 | kpfleming | now, when you dial SIP/peer/1234, that '1234' is supposed to end up being the 'user' part of the Request URI. |
| 23:43.02 | Micc_ | yes it does, but with the wrong ip address. |
| 23:43.20 | kpfleming | but Asterisk doesn't take "sip:waldimports1@10.1.10.10:5060;transport=UDP" and replace the 'waldimports1' with '1234', because it can't know that the resulting URI is actually valid |
| 23:43.59 | kpfleming | all it can do is construct a *new* URI using the information that it has from the registration, which is the apparent IP address and port number that the device registered from |
| 23:44.41 | kpfleming | it would be possible to do what you want, but it wouldn't work in all circumstances, so it would definitely have to be optional behavior. |
| 23:45.50 | Micc_ | ok, so what would I need to do? |
| 23:46.28 | kpfleming | well, to be able to use asterisk as it stands today, you'll need to have the device not register with you... just have a static host/port assigned so that you can dial target extensions on that device. |
| 23:47.04 | kpfleming | for the longer term, i'd suggest posting to the -dev mailing list and asking for opinions on how an optional feature could be designed to allow the behavior you want |
| 23:47.24 | kpfleming | but like i said, it would not always work |
| 23:49.21 | kpfleming | this is why SIP providers generally either you have provide them a static IP/port to deliver calls to you, or they have you register separately for each 'extension' that they need to be able to send you |
| 23:51.55 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-uovmthxlwuuwcvtg) |
| 23:58.23 | Micc_ | if the device doesn't register with me, won't the headers still have the external IP address which would make the device ignore the invite still? |
| 23:58.33 | Micc_ | or does it look different when it doesn't register? |
| 23:59.19 | kpfleming | if the device is ignoring incoming INVITE messages that it receives because the address in the Request URI and the To header isn't what it thinks it has, then it is broken :-) |
| 23:59.45 | kpfleming | if it has received the INVITE, then it was supposed to receive it... that's how UDP and IP work! |
