| 02:16.52 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 02:40.35 | *** join/#asterisk-bugs pabelanger (n=pabelang@OTWAON23-1242541604.sdsl.bell.ca) |
| 03:01.29 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 03:01.29 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 03:18.14 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 03:18.14 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 03:48.20 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 05:14.33 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 05:44.56 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 06:16.50 | *** join/#asterisk-bugs mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 09:01.43 | *** join/#asterisk-bugs miloux (n=miloux@static-213.88.173.45.addr.tdcsong.se) |
| 09:03.56 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 10:01.13 | *** join/#asterisk-bugs jazzmann (n=chatzill@cpc1-lutn9-0-0-cust163.lutn.cable.ntl.com) |
| 12:09.04 | *** join/#asterisk-bugs russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:09.04 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 12:30.39 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:30.39 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 12:58.41 | *** join/#asterisk-bugs d1mas (n=chatzill@host-99.dataart.net) |
| 12:58.53 | d1mas | oej: are you there? (hello) |
| 12:59.10 | oej | Pong (hello) |
| 13:01.07 | d1mas | oej: Question regarding SIP - in 1.4 there are two places in the chan_sip which register peer's exten (call register_peer_exten with second parameter = TRUE). One of them is parse_register_contact but the code to register extension is inside the if (if (inaddrcmp(&peer->addr, &oldsin))) This IF is always false for me so the ext for the peer is neevr registered |
| 13:01.44 | d1mas | oej: Question: when extension for the peer actually supposed to be _initially_ registered? (for the first time) |
| 13:02.06 | oej | Go back a few steps : what's your issue? |
| 13:02.38 | d1mas | oje: :) sorry. My SIP phones successfully register but no extension is created for them |
| 13:02.51 | d1mas | oje: (for some of them actually) |
| 13:05.30 | oej | You mean no regexten ? |
| 13:05.49 | d1mas | oej: yes |
| 13:06.00 | oej | Have you set regcontext ? |
| 13:06.09 | d1mas | sure |
| 13:06.36 | d1mas | oej: for some phones the regexten is actually created. For some - it is not |
| 13:06.45 | oej | That's is weird |
| 13:06.49 | d1mas | agree |
| 13:06.57 | oej | You need to debug it and see what the difference is |
| 13:07.47 | d1mas | oej: that is what I'm doing. What I need to understand is what is the place in the chan_sip which is supposed to create regexten |
| 13:08.11 | oej | Hold on, a bit busy right now. I'll be back in a while. |
| 13:08.32 | oej | From memory, I belive there's one place where we add it and one place where we remove it at expiry |
| 13:09.03 | d1mas | oej: there are two... (and three in 1.6) |
| 13:22.04 | d1mas | oej: I do not understand the "if (inaddrcmp(&peer->addr, &oldsin))" check completely because for me, address from contact and real address from which the packet came are always the same. so the peer->addr == oldsin and the condition never met. This makes me think that this piece of code only creates regexten when peer's IP changes and that the first creation must be in some other place but I... |
| 13:22.06 | d1mas | ...can not find that place. |
| 13:31.11 | oej | Well, we only create it when IP address changes - at first registration |
| 13:47.09 | *** join/#asterisk-bugs blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:47.09 | *** mode/#asterisk-bugs [+o blitzrage] by ChanServ |
| 13:52.15 | d1mas | oej: so should regexten be created by parse_register_contact ? If yes, it means that peer->addr must be 0.0.0.0 in the case of first registration request... |
| 13:54.05 | oej | It normally is |
| 13:54.09 | oej | Or do you have another situation? |
| 13:56.05 | d1mas | oej: I do not know. What I see is that I restart asterisk and then I see REGISTER requests coming from my phones and for these requests peer->addr == oldsin |
| 13:56.28 | oej | Well you need to make sure there's no existing registration active for the peer |
| 13:56.30 | d1mas | oej: could it be something like some state of registered peers is restored from ASTDB ? |
| 13:56.33 | oej | Yes |
| 13:56.41 | d1mas | aha |
| 13:56.55 | d1mas | SIP peer state but not regexten I guess? |
| 13:57.21 | oej | What do you mean? |
| 13:58.19 | d1mas | oej: could it be that some of peer information is read from AstDB (like current peer's IP) ? In this case whn REGISTER request comes in, there is no 0.0.0.0 addr in the peer structure - there is already the right IP |
| 13:58.37 | d1mas | oej: so the code to create regexten is never executed |
| 13:58.40 | oej | run "sip show peer xxxx" to see the state of your peers |
| 13:58.57 | oej | If they are just re-registering, we don't add regexten's again. |
| 13:59.05 | oej | IN your case, it won't happen at all. |
| 13:59.15 | oej | So delete all the sip registry entries in ASTDB |
| 13:59.18 | oej | then restart |
| 14:04.49 | d1mas | oej: ok, for one phone regexten was created, for another - was not. I suspect the following: |
| 14:08.53 | d1mas | oej: "bad" phone always uses the same port (5060) for SIP. This port + ipadd was saved into the database (realtime). Next time when this bad phone tries to register, the peer is looked up in the realtime database and ipaddr=192.168.10.187, port=5056 is read. These numbers go to peer structure. So when the parse_register_contact is invoked, it sees that neither IP nor port changed and does... |
| 14:08.54 | d1mas | ...NOT register exten. |
| 14:10.53 | oej | That's an interesting scenario. |
| 14:11.14 | oej | So to get it to work, we need to make sure the IP address is reset in the db at expiry. Isn't it? |
| 14:11.45 | d1mas | oej: well, actually there is no expiry - that is the problem. |
| 14:11.54 | d1mas | oej: there is just Asterisk restarting |
| 14:13.12 | oej | So you're converting an existing installation? |
| 14:13.45 | d1mas | oej: I believe that when expiry timer runs out Asterisk behaves correctly removing cleaning up as needed. My problem is that expiry never happens because phone keeps registering itself. And the only problem is that at first registration no regexten created. |
| 14:14.03 | d1mas | oej: Yes, I'm moving from 1.4 (branch from SVN) to 1.4.20.2 |
| 14:14.30 | d1mas | oej: But I'm not sure when problem happened |
| 14:18.22 | oej | ..is not created, because it's not a first registration :-) |
| 14:18.42 | oej | If you use your mysql tool and reset all the IP addresses and then force the phones to re-register, I'm sure it'll work. |
| 14:19.00 | oej | We can't really guess that it's a "first registration since re-configuring" |
| 14:20.02 | d1mas | oej: well I will need to pune realtime first, but I agree - it should work |
| 14:20.16 | d1mas | s/pune/prune |
| 14:20.28 | oej | Well, this is such an old function and tested in many situations, so I was a bit surprised |
| 14:21.16 | d1mas | hm... found something... |
| 14:23.45 | d1mas | false alarm. found nothing.. I have no idea how it worked before |
| 14:29.22 | *** join/#asterisk-bugs km- (n=pgrace@fmservices.v6.fierymoon.com) |
| 14:30.47 | d1mas | oej: I confirm that if I prune realtime peer AND reset its port/ip in the database then on next registration, regexten is created |
| 14:31.11 | oej | ok, then things work as expected |
| 14:31.16 | oej | Thanks for confirming that |
| 14:33.44 | d1mas | oej: well, the only problem is that is may not be expected by people :) I really believe this qualify as a bug |
| 14:39.40 | russellb | I suppose we could check to see if the extension exists on each registration, and if not, create it. |
| 14:39.49 | russellb | that shouldn't cause any harm, and would avoid this problem |
| 14:41.34 | russellb | that's not a very expensive operation ... |
| 14:45.36 | d1mas | I agree |
| 14:47.18 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 14:49.27 | d1mas | Interesting enough, comments in the file say that for dynamic peers, defaddr provides address prior to real registration and addr only after it. But the fact is that realtime peer loaded has its addr initialized to the same value as defaddr |
| 14:50.29 | jsmith | russellb: Well, the problem comes up in cleaning up the previously created exten, if there was one |
| 14:50.45 | russellb | cleaning up? |
| 14:54.43 | d1mas | russellb: is there a function like create_ext_if_not_exist ? |
| 14:55.11 | russellb | no, but there is a function to simply check to see if an extension exists |
| 14:55.13 | jsmith | russellb: Well, let's say that you had "regexten" set to "1001" in the database, then you changed it to "1002". Shouldn't Asterisk go back and remove exten "1001"? |
| 14:55.21 | d1mas | russellb: I see |
| 14:55.34 | russellb | jsmith: interesting point. Though, I think that may be a different issue ... |
| 14:55.37 | d1mas | ohoho :) |
| 14:56.03 | jsmith | russellb: OK, if you say so. You know the code better than I |
| 14:56.05 | russellb | jsmith: I guess that's up to the configuration entity to ensure that gets cleaned up :) |
| 14:56.38 | jsmith | russellb: It was my understanding that that was the reason things are the way they are now |
| 14:56.43 | jsmith | could be totally wrong |
| 14:57.29 | d1mas | hurray. registration works :) |
| 14:57.36 | russellb | Well, doing what we're talking about shouldn't actually change that ... |
| 14:57.54 | russellb | if you have the realtime peer cached, your change isn't going to take effect until you prune, or the registration expires ... |
| 14:58.16 | russellb | anyway, yeah, this wouldn't change the behavior I don't think |
| 14:59.38 | d1mas | anyone needs a patch? :) |
| 14:59.57 | russellb | bugs.digium.com i guess |
| 14:59.58 | km- | if it produces hallucinations with little chance of dependence, please, I'll take one. |
| 15:00.04 | d1mas | i know i know :) |
| 15:00.21 | d1mas | russellb speaking about bugs.digium.com... |
| 15:00.44 | d1mas | russellb 12874 ? :) |
| 15:00.52 | russellb | M12874 |
| 15:00.54 | MuffinMan | [new] [Asterisk] Core/PBX 0012874: [patch] small bug introduced with fix for 12656 reported by dimas (Karma: +96.50) http://bugs.digium.com/view.php?id=12874 |
| 15:03.09 | russellb | interesting |
| 15:03.12 | russellb | i'll commit the fix |
| 15:03.31 | d1mas | :) |
| 15:03.40 | russellb | thanks for pointing it out |
| 15:05.58 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 15:17.19 | d1mas | Here we go. M13309 |
| 15:17.36 | d1mas | ah, that does not work for mortals :) |
| 15:18.03 | km- | damn |
| 15:18.24 | km- | russell: just talked to my boss and he said that unless what I change is to fix a bug in core asteirsk, everything I write is considered "secret sauce" :( |
| 15:18.35 | seanbright | d1mas: yes it does, but it has to be on a line by itself. |
| 15:19.00 | d1mas | ah, thanks |
| 15:23.58 | *** join/#asterisk-bugs jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:24.54 | russellb | km-: weak |
| 15:25.04 | *** join/#asterisk-bugs bad_duck (n=bad_duck@dynamic44-3.MAN-STDOM.cablenet.com.ni) |
| 15:25.05 | russellb | km-: then clearly everything you do is fixing a "bug" |
| 15:25.17 | russellb | the fact that asterisk didn't have that feature was a bug |
| 15:25.29 | russellb | problem solved |
| 15:25.35 | bad_duck | Hi, I have just installed asterisk on debian linux, and asterisk-gui, the installation seems to be ok but the web interface refreshes itself all the time when i log on |
| 15:27.14 | km- | russelb: haha |
| 15:31.55 | bad_duck | hm ok, problem solved |
| 15:33.16 | *** part/#asterisk-bugs bad_duck (n=bad_duck@dynamic44-3.MAN-STDOM.cablenet.com.ni) |
| 16:16.34 | *** join/#asterisk-bugs fakhir_ (n=fakhir@unaffiliated/fakhir) |
| 16:53.56 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:53.56 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 17:03.53 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 18:32.35 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 19:02.40 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:03.10 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 19:27.31 | *** join/#asterisk-bugs philippel (n=p_lindhe@pool-98-111-70-106.sttlwa.fios.verizon.net) |
| 19:29.21 | philippel | would the following be considered a bug or am I mis-understanding something. I set disconnect=** in features.conf and verify it is set at the CLI. I make a call and once answered, I need to press ** (vs. *) to hangup. However, if it is still ringing (prior to signalling answer), if I press a single '*' it hangs up ? This is all done with the H option set in the dial command |
| 19:29.45 | seanbright | philippel: #asterisk |
| 19:29.59 | philippel | jsmith suggested I ask here |
| 19:30.41 | philippel | in otherwords, it all works as expected except during the rining phase |
| 19:30.57 | jsmith | seanbright: He's asking whether that's a bug or expected behavior, which is why I sent him here |
| 19:31.02 | seanbright | i see |
| 19:31.25 | seanbright | well i was under the impression that features only worked on bridged channels |
| 19:32.09 | philippel | seanbright maybe that is the answer, but why the hangup at all with a single * pressed then? |
| 19:32.36 | seanbright | because of what you just said |
| 19:32.49 | seanbright | "This is all done with the H option set in the dial command" |
| 19:33.01 | seanbright | H - Allow the calling party to hang up by hitting the '*' DTMF digit. |
| 19:33.15 | philippel | yes but he H option choosed it's feature code based on the disconnect setting I thought? |
| 19:33.24 | seanbright | that is not correct |
| 19:33.47 | philippel | well maybe that is my mis-understanding then (and probably not an ideal design:( ) |
| 19:34.12 | seanbright | if (ast_test_flag(peerflags, OPT_CALLER_HANGUP) && (f->subclass == '*')) |
| 19:35.40 | seanbright | this is in 1.4, by the way |
| 19:35.44 | seanbright | not sure about trunk |
| 19:36.39 | philippel | seanbright well your answer is very helpful, thanks you. It implies that it is my mis-understanding. Now the question (maybe not to be asked here), is it appropriate to file a 'bug' against the inconsistency to be considered at least for 1.6, becasue it is bad design, imho to have it definable but hard coded in the dial command |
| 19:37.18 | philippel | jsmith opinion form you also? |
| 19:37.37 | seanbright | philippel: i'm not sure i would consider it a bug... it works as documented. feature requests on the bug tracker are typically discouraged unless there is a patch included. |
| 19:38.04 | jsmith | philippel: Yeah... I'd probably have to lean towards "feature request" instead of "bug", even though it's borderline |
| 19:38.35 | philippel | didn't realize feature requests could be made in the bug tracker, or is there somewhere else to make them? |
| 19:38.52 | philippel | in the meantime, I suspect it may not be hard to create a patch, I'll have a peak |
| 19:39.26 | seanbright | so this is interesting. |
| 19:39.35 | seanbright | philippel: can you test something for me? |
| 19:39.43 | philippel | what? |
| 19:39.59 | seanbright | use both the h and H option in your dial |
| 19:40.08 | philippel | k, just sec |
| 19:40.11 | seanbright | and try hitting a single '*' on the receiving side after the call is bridged |
| 19:40.26 | philippel | k, just sec |
| 19:40.47 | seanbright | if that doesn't work, that might be a bug. |
| 19:42.11 | philippel | nope but was a cell phone so let me see if I can try it to another phone (as in single or double * no go) |
| 19:42.23 | seanbright | single should fail |
| 19:42.27 | seanbright | double should work |
| 19:42.34 | seanbright | (my guess) |
| 19:42.37 | philippel | yeah but cell phone... |
| 19:42.48 | seanbright | right |
| 19:42.50 | seanbright | i'll wait |
| 19:42.51 | seanbright | :) |
| 19:43.30 | philippel | ok - to a real phone where I can do the double ** fast enough, it disconnects with double but not with single |
| 19:43.44 | seanbright | ok, then that is a bug. |
| 19:44.01 | seanbright | the other way around... i dunno |
| 19:44.14 | seanbright | it would make sense to use the feature disconnect code |
| 19:44.28 | philippel | so to fix the whole 9 yards, we just get the h and H options to pay attention to disconnect and it is a better overall solution, imho |
| 19:44.42 | seanbright | i would agree |
| 19:44.47 | seanbright | so... this is what you do |
| 19:44.53 | seanbright | post a bug against the 'h' issue |
| 19:45.16 | seanbright | saying that the documentation of the dial() command is wrong (feature code, blah blah) |
| 19:45.55 | seanbright | and say that it would also make sense if the H code used what was in features as well |
| 19:46.09 | seanbright | the latter will not make it into 1.4, but we'll at least get it more consistent. |
| 19:46.12 | seanbright | and in the meantime |
| 19:46.12 | seanbright | i go |
| 19:47.02 | philippel | and if I happened to include a patch, maybe that would help ... I'll poke a bit in the code but at a minimum, put up something on the lines of what you suggested |
| 19:47.38 | seanbright | yeah... if features worked on non-bridged channels that would make your life easier |
| 19:47.46 | seanbright | file: ping |
| 19:47.59 | file | eh? |
| 19:48.01 | seanbright | file's bridging API might make a lot of this easier |
| 19:49.21 | seanbright | file: would it be easy to make the 'H' option on Dial() (allow caller to disconnect) use the disconnect code in features.conf before the channels are bridged? |
| 19:49.28 | seanbright | file: or is it a PITA? |
| 19:49.39 | file | it would not be easy. |
| 19:49.53 | seanbright | hrmm |
| 19:50.25 | seanbright | damn it. |
| 19:50.26 | seanbright | heh |
| 19:50.33 | seanbright | ok, philippel, i'm fresh out of ideas :) |
| 19:51.34 | file | an interesting way to do it would be to turn audiohooks into framehooks... and add a hook for DTMF that when triggered queues a hangup on the channel... |
| 19:51.48 | philippel | seanbright ok dumb question (it's just been years since I've done much C programming (like 10+ other than tidbits) but is static struct ast_call_feature builtin_features[] accessible in app_dial.c and thus would it be reasonable to looku that featurecode there when doing the comparison (for the proposed patch)? |
| 19:52.25 | philippel | it is defined in res/res_features.c |
| 19:52.36 | seanbright | philippel: ... |
| 19:52.41 | seanbright | philippel: might want to skip the patch |
| 19:52.43 | seanbright | :) |
| 19:53.00 | seanbright | file: interesting idea |
| 19:54.15 | philippel | ok - so you suggest simply reporting the h bug as discussed above then and skipping the patch but commenting on the suggested consistency for a future release? |
| 19:54.28 | seanbright | yes |
| 19:54.32 | seanbright | all in the same issue |
| 19:54.38 | philippel | yes understood |
| 19:54.41 | seanbright | wonderful |
| 19:54.44 | seanbright | now i really have to run |
| 19:54.45 | seanbright | back later |
| 19:54.54 | philippel | thanks for your help |
| 20:02.48 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 20:09.23 | philippel | http://bugs.digium.com/view.php?id=13315 |
| 20:09.26 | philippel | ok reported |
| 20:09.28 | philippel | thanks again |
| 21:02.28 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 21:35.18 | *** join/#asterisk-bugs fakhir_ (n=fakhir@unaffiliated/fakhir) |