| 00:50.32 | *** join/#asterisk-dev moy_ (~moy@70.31.14.144) |
| 01:01.02 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 01:01.02 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 01:16.13 | *** join/#asterisk-dev rrb3942 (~rbullock@cpe-67-242-215-62.rochester.res.rr.com) |
| 01:57.54 | Kobaz | anyone alive |
| 02:12.25 | jnemeth | nope :-> |
| 02:14.09 | Kobaz | what's the proper way to get a datastore to migrate to a channel that's masquraded |
| 02:14.26 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 02:14.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 02:22.28 | jnemeth | no idea... not even sure what you mean by a channel that's masqueraded... |
| 02:24.55 | Kobaz | like when you're doing a transfer, the callers channel gets's masq'd into the callers channel, and then is bridged to the final destination channel |
| 02:25.12 | Kobaz | er... the callers channel gets masq'd into the callee's channel |
| 02:25.30 | Kobaz | like, 6208 calls 6211, 6211 transfers the call to 6288 |
| 02:25.57 | Kobaz | SIP/6208 gets masquraded into SIP/6211, and then gets renamed back to SIP/6208, and then gets bridged to SIP/6288 |
| 02:27.55 | Kobaz | i set up some datastores on SIP/6208, (a hangup handler), and i need it to survive a masqurade |
| 02:34.16 | jnemeth | hrmm... sounds complicated... being a transfer 6211 drops out of the call? |
| 02:34.42 | jnemeth | I've only really dug into the code for porting purposes... |
| 02:35.45 | Kobaz | yeah 6211 is gone after the transfer |
| 02:35.56 | Kobaz | i'm gonna add a bunch of debugging to the channel destroys and masqurades |
| 02:36.11 | Kobaz | somehow the datastore just gets lost, it doesn't even trigger the ->destroy |
| 02:36.48 | jnemeth | sounds like a potential memory leak... |
| 02:37.20 | jnemeth | are you an official Asterisk developer or just playing with it? |
| 02:37.44 | Kobaz | i have commit access |
| 02:37.48 | Kobaz | does that make me official? |
| 02:37.50 | Kobaz | heh |
| 02:39.38 | Kobaz | there's an inherit flag on the datastore |
| 02:39.41 | Kobaz | probably need to use that |
| 02:39.54 | Kobaz | but if it's not inherited, it should still trigger the destroy though |
| 02:49.52 | jnemeth | makes you more official than me :-> I'm a NetBSD developer (have commit access to the NetBSD repository) and maintain the Asterisk port for NetBSD, so I've basically just looked at the source for porting issues... |
| 02:50.08 | Kobaz | ah |
| 04:33.11 | Corydon76-home | Kobaz: datastores should migrate automatically at the point of fixup |
| 04:33.35 | Corydon76-home | but datastores need a fixup method implemented in order to do so |
| 04:40.38 | Kobaz | okay |
| 04:40.43 | Kobaz | good to know |
| 04:40.55 | Kobaz | any simple examples you can think of for fixups |
| 04:41.10 | Corydon76-home | All masquerades are fixups |
| 04:41.40 | Kobaz | hmm, don't quite follow |
| 04:42.37 | Corydon76-home | The only time you need a fixup is when a channel gets a new structure, due to a masquerade |
| 04:42.55 | Corydon76-home | Every other case is one of inheritance (master -> slave) |
| 04:43.37 | Kobaz | so, in the instance of a an attended transfer, what happens |
| 04:43.37 | Corydon76-home | So a fixup has to update the datastore's internal pointers back to the channel structure, because the location has changed |
| 04:43.43 | Kobaz | does it inherit? |
| 04:44.10 | Kobaz | okay... i don't have pointers to channels in the datastore |
| 04:44.20 | Kobaz | so i wouldn't have anything to fix up in that respect |
| 04:44.45 | Corydon76-home | For a true transfer, I don't think there's any fixups, no |
| 04:45.07 | Corydon76-home | A typical masquerade involves something like call pickup |
| 04:46.52 | Kobaz | so, would i need to set inheritance, and then it will be taken care of? |
| 04:59.07 | Corydon76-home | Kobaz: you'd need to map out how the operation is actually performed before you can make such a determination |
| 05:00.37 | Kobaz | well basically... this is the hangup handlers stuff i posted to the list a while ago |
| 05:01.49 | Kobaz | so what happens is, SIP/2608 calls SIP/2611, a datastore is added to SIP/2608, SIP/2611 attended transfers to SIP/2688, SIP/2608 no longer has the datastore i gave it |
| 05:03.05 | Corydon76-home | Uh, if the datastore is added AFTER the call is generated, then it never got added to SIP/2611, correct? |
| 05:03.34 | Kobaz | well, in between 2608 -> 2611, a datastore is added |
| 05:03.40 | Kobaz | before the Dial() |
| 05:04.34 | Corydon76-home | Was it inherited to SIP/2611? |
| 05:04.58 | Corydon76-home | I think it may need both inheritance and fixup, then |
| 05:05.46 | Kobaz | i just turned on inheritance on the datastore, need to do some tests |
| 05:06.04 | Corydon76-home | 2608 is probably masqueraded into 2611's second channel |
| 05:06.20 | Kobaz | yeah, it is |
| 05:06.43 | Corydon76-home | So it needed to inherit the datastore prior to the fixup |
| 05:09.43 | Kobaz | i think it's being inherited |
| 05:09.55 | Kobaz | it stays around until 6288 hangs up |
| 05:10.00 | Corydon76-home | So what's being stored in the datastore? |
| 05:10.41 | Kobaz | linked list of dialplan targets |
| 05:11.03 | Kobaz | when a channel hangs up, traverse and execute from the list |
| 05:17.44 | Kobaz | i think i need some sort of fixup thinger |
| 05:20.52 | Corydon76-home | One thing that I think may be helpful sometime would be to change how the dialplan works... instead of a global linked list, a channel should refcount the global pointer at the time at which it is created, ensuring that if rules are added/removed, it always has a consistent picture of the dialplan |
| 05:21.19 | Corydon76-home | Then deref when the channel is destroyed |
| 05:21.54 | Kobaz | if I do a Bridge(), the datastore doesn't seem to be properly associaed to the channe |
| 05:22.11 | Kobaz | oh, that would be cool |
| 05:22.14 | Corydon76-home | At reload, the global list would be recreated from scratch |
| 05:22.38 | Kobaz | hmm, would that remove the ability to hot-reload dialplan on a running channel? |
| 05:27.48 | Kobaz | [2011-01-30 00:26:38] NOTICE[26508]: channel.c:570 ast_channel_register_hangup_handler: Added hangup handler for channel SIP/6208-00000000: CallQueue_Hangup,s,1 |
| 05:27.54 | Kobaz | do a Bridge() |
| 05:28.08 | Kobaz | Bridge(SIP/6208) from say, SIP/6211 |
| 05:28.15 | Kobaz | hang up that call |
| 05:28.23 | Kobaz | [2011-01-30 00:26:59] NOTICE[26539]: channel.c:590 ast_channel_run_registered_hangup_handlers: No hangup handlers for channel: SIP/6208-00000000 |
| 05:28.47 | Kobaz | i think i need a fixup or something, i gotta dig around to see how that works |
| 05:50.31 | WIMPy | Hmm. After reading M18709, EXTEN seems to end up in CALLERID(ANI) there. Wonder if there's a relationship to EXTEN ending up in CALLERID(num) for me. |
| 05:50.33 | MuffinMan | [new] [Asterisk] CDR/General 0018709: On cdr table Caller number in not being stored in clid and src, instead extension number is on outgoing calls. reported by CidiRome https://issues.asterisk.org/view.php?id=18709 |
| 05:53.18 | Kobaz | is it safe to memcpy an AST_RWLIST |
| 05:53.33 | WIMPy | I think I will do some serious printf spamming tomorrow. |
| 06:25.26 | Corydon76-home | Kobaz: No, you must do a deep copy |
| 06:27.03 | Corydon76-home | http://thedailywtf.com/Articles/Best-of-the-Email-Too-Many-Tests,-The-Great-Lamp-Caper,-and-More.aspx |
| 06:30.08 | Kobaz | k |
| 06:30.26 | Kobaz | oh right, it's a linked list, duh |
| 06:30.27 | Kobaz | heh |
| 07:30.21 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-103-164.lns4.bat.bigpond.net.au) |
| 07:35.18 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-116-81.ptld.qwest.net) |
| 09:00.29 | *** join/#asterisk-dev micols (~mio@rlogin.dk) |
| 09:37.57 | *** join/#asterisk-dev micols (~mio@rlogin.dk) |
| 10:00.33 | *** join/#asterisk-dev micols (~mio@rlogin.dk) |
| 12:31.11 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 13:41.15 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.63.57.56) |
| 13:58.22 | seanbright | russellb: ping |
| 14:05.03 | *** join/#asterisk-dev hehol (~Adium@ip-78-94-0-76.unitymediagroup.de) |
| 14:21.37 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 14:21.37 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 14:59.34 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:59.34 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:21.39 | *** join/#asterisk-dev moy (~moy@70.25.53.39) |
| 16:48.43 | *** join/#asterisk-dev hehol (~Adium@ip-78-94-0-76.unitymediagroup.de) |
| 17:30.36 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 18:02.30 | *** join/#asterisk-dev Corydon76-home (six@c-69-137-80-31.hsd1.tn.comcast.net) |
| 18:02.30 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 18:35.05 | *** join/#asterisk-dev Corydon76-home (eleven@c-69-137-80-31.hsd1.tn.comcast.net) |
| 18:35.05 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 18:54.27 | *** join/#asterisk-dev Sipster_ (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 20:26.28 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 20:26.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:26.20 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 22:26.20 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 22:26.20 | *** mode/#asterisk-dev [+oo snuff-home snuff-work] by verne.freenode.net |
| 22:27.44 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-103-164.lns4.bat.bigpond.net.au) |
| 22:29.56 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 22:29.56 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:41.11 | *** join/#asterisk-dev rrb3942 (~rbullock@cpe-67-242-215-62.rochester.res.rr.com) |
| 22:53.04 | *** join/#asterisk-dev razu (~razu@razu.data.ee) |
| 23:41.30 | *** join/#asterisk-dev erinspice (~erin@207.98.195.107) |
| 23:42.36 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |