| Summary: | ASTERISK-13208: Calls parked fail to return to the correct phone after timeout | ||
| Reporter: | Michael Gaudette (bluefox) | Labels: | |
| Date Opened: | 2008-12-11 20:01:07.000-0600 | Date Closed: | 2010-07-07 10:57:25 |
| Priority: | Blocker | Regression? | No |
| Status: | Closed/Complete | Components: | Features/Parking |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) channame14.diff ( 1) log_censored.log ( 2) park2.log ( 3) SIP_blonde_transfer_park.diff.txt | |
| Description: | Calls put in park (parkedcalls feature) are put in park and can be picked up correctly. BUT when timeout occurs, instead of the phone that put the call on park ringing back, the phone that was put in the parking extension rings back. (i.e. the caller phone rings itself). This happens about 20% of the time. (this describes a SIP Phone - Asterisk - SIP phone call, but failure is also seen on an external call being put in park. But the result is a weird hangup instead of a phone calling itself back) ****** STEPS TO REPRODUCE ****** Setup parkecalls as per default feature.conf settings, with the SIP peer context including parkedclals context: [sip_context] .... include => parkedcalls Park a few calls You only need two phones, but it may take a few times (let's say 10) to see. ****** ADDITIONAL INFORMATION ****** CLI output on success: -- Executing [100@internal-local-only-hamel:1] Park("SIP/0004f215aabb-1-09eec150", "") in new stack == Parked SIP/0004f215aabb-1-09eec150 on 101@parkedcalls. Will timeout back to extension [internal-local-only-hamel] s, 1 in 45 seconds CLI output on failure: -- Executing [100@internal-local-only-hamel:1] Park("SIP/0004f215aabb-1-09eec150", "") in new stack == Parked SIP/0004f1234aa-1-09eec150 on 101@parkedcalls. Will timeout back to extension [internal-local-only-hamel] s, 1 in 45 seconds NOTICE how on failure, the parked call isn't the same as the argument in Park() | ||
| Comments: | By: Terry Wilson (twilson) 2009-01-05 12:51:13.000-0600 I haven't been able to reproduce this. Could you run asterisk with verbose/debug=5 and post a snippet from your log file so I can see what is going on? Thanks! By: Leif Madsen (lmadsen) 2009-01-13 12:18:18.000-0600 Any word on this issue? Our policy is to close issues with no response from the reporter after a week. Thanks! By: Michael Gaudette (bluefox) 2009-01-13 21:02:50.000-0600 I just uploaded a log with verbose and debug at level 5; got lucky, it failed on the first try. It usually works 80% of the time, but the other 20% are problematic. By: Michael Gaudette (bluefox) 2009-01-14 07:21:30.000-0600 Just a comment, because it's bound to get asked: park-dail is created by feauture.res. I have no park-dial context of my own in my dialplan where a timeout would be missing. By: Terry Wilson (twilson) 2009-01-14 12:39:38.000-0600 Ok, it looks like the reason this is happening is because asterisk isn't properly finding the name of the device and the channel becomes SIP/5060 which parking tries to use to call back. Some things to try: 1) do you have username= in sip.conf specified for the user? It looks like this *could* fix it at least for some situations. Also, mmichelson patched trunk to change this behavior, but didn't include it in other branches because it would be a behavior change--even if it is not "right", someone could be relying on the behavior somewhere. I'm not sure whether anyone realized that it could break parking though. If adding a username= fixes this for you, then I'd say that is a valid workaround. If you already have it or it doesn't, then you can try making the change that mmichelson made to trunk and see if that fixes it for you. I will attach the patch from that commit here (backported for 1.4). By: Michael Gaudette (bluefox) 2009-01-14 12:47:29.000-0600 I use sip realtime, but in my sip registration table all username=name for the phones I tested with. So there is no empty username value in play. I will try the patch later, can you give me an educated opinion on the risks involved (rgr other normal PBX operation/functions) in using this patch? By: Michael Gaudette (bluefox) 2009-01-14 13:29:02.000-0600 Obvious follow-up question: could this be linked to me using SIP realtime instead of the good old sip.conf file? By: Leif Madsen (lmadsen) 2009-01-14 14:29:11.000-0600 Are you using cached realtime users, or uncached? If they are uncached, they are not stored in memory, and could be part of the issue. Even if cached, it could possibly still be an issue if they peer has not been cached. By: Michael Gaudette (bluefox) 2009-01-14 14:37:10.000-0600 sip.conf does have the rtcachefriends=yes line, so I guess they are cached. And the SIP registrations do not change during one of my parking tests anyways. By: Terry Wilson (twilson) 2009-01-14 14:39:19.000-0600 realtime has nothing to do with this issue. By: Terry Wilson (twilson) 2009-01-14 14:54:30.000-0600 The problem is that the park return call tries to use magic to guess how to call back the person that was parked (since the information really isn't readily available to it since god knows what could happen in the dialplan, etc. before the park happens). What it does, is take the channel name, lop off everything after the last dash, and try to call that back directly. Now, when we get an inbound call (like bluefox is getting from his provider), asterisk currently just assigns a channel name based on the From header because hey...it's just a channel name, right? In 1.4, the method chosen looks for a ':' and takes what is after it as the first option, which will be a port number, which is why you get channels named SIP/5060 if the From header specifies the port (even though it doesn't need to because it is the default). Now, in trunk, mmichelson realized that was silly and improved it to where the fromdomain (the stuff after the '@' in the request would be set to the channel name. But, this is still not good enough (and after examination is at a different stage in the call and wouldn't affect this exact issue anyway) because if you are getting an inbound call from a pstn provider, you aren't going to be able to call back just the hostname and get the person that you want. Now, although bluefox has username= set for all of his phones, I doubt he has it set for his pstn provider that the call is coming in on. If he did, it would try to callback that username--which still would be pointless because you need multiple usernames if you are wanting to call back different people at that host. So, a solution might be to actually take the contact header and name the channel after that. Theoretically, things would be set up such that the contact was actually valid, then when we used the channel name to call back, we would actually call back 5555551212@myprovider.com. At the very least we would be calling back what the provider claimed was the contact for that call. I have a patch I'm working on that does this, and while it is a fairly simple change, it definitely adds a completely new behavior--and any time that you make a change in this area, it is always possible to break unintended areas...although it seems like a fairly safe change since you would be going from guessing a channel name and assigning something worthless like the port number and adding a channel name that actually had some meaning. I don't think having characters like '@' and ':' in a channel name would hurt, but... I have looked at trying to make the callback mechanism for parking just be less dumb, but it gets...very complicated. By: Michael Gaudette (bluefox) 2009-01-14 15:06:11.000-0600 Calling back the user is a bit of a hack anyways, because we don't want customers calling in, being hung up on, and then being called back. It's better than not being called back, but ideally they shouldn't be dropped. The example I gave you hangs up the call, but if I do an internal call (as you say, the sip username is filled in in that case) then what happens is not a disconnection, but the wrong phone is ringed back (ex: the phone that was put on parkis ringed back, which means the phone is calling itself instead of calling the operator that put the call on park). So, what I am hearing, is that "parking" is and as always been broken....and there is no simple bug that can be squashed. Am I understanding this correctly? By: Terry Wilson (twilson) 2009-01-16 17:39:29.000-0600 I wouldn't say that parking is and has always been broken, exactly. Mostly just very limited. There have been some fairly significant changes to parking in 1.4 this week to fix some bugs that were introduced into the branch about 3 weeks ago. If you have any kind of test system that you can reproduce your issue on, I would suggest trying to run code from a recent checkout from branches/1.4 just to see if it resolves your issue. The Park() application now uses a channel masquerade which should resolve some of the issues we've had. So while the change doesn't specifically address your issue (because I'm not sure what is causing it!) there is still a pretty good chance that it could still resolve it. By: Michael Gaudette (bluefox) 2009-01-18 04:36:35.000-0600 More info (and a new log file, park2.log). I used a test server nothing on it but the two Polycom SIP phones being used for the park test. I have now been using 1.4.23-rc4, as the readme mentionned masquerading for park. What I found is this: This time I couldn't get the park feature to fail, UNLESS I completed the transfer (transfer is managed by the phone) BEFORE I heard the first digit of parked extension. In that case, it's a 100% failure rate. Not only is it a 100% failure rate, but the funny thing is that is that if I transfer the call too quickly (before hearing the digits), the digits are heard on the wrong phone's speakerphone. As if the park application couldn't find the phone and fell back on whatever other device has a name close to it (in my case the sip names were test and test2). So the phone being put on park was the one hearing "7-0-0" when the parking phone was too quick to disconnect and park the call..... I believe this should help fix this, or at least find where the problem lies. By: Terry Wilson (twilson) 2009-01-18 21:16:43.000-0600 bluefox: sounds like I might have reintroduced an old bug when trying to fix the old. I think I know how to fix this particular case and will work on it on monday. For future testing, you may have to test out against an svn checkout of the 1.4 branch as I'm not sure when the next rc is coming out. By: Michael Gaudette (bluefox) 2009-01-19 08:59:31.000-0600 Understood, I'm waiting for the patch or the new build to test. By: Terry Wilson (twilson) 2009-01-19 15:49:17.000-0600 bluefox: could you see if SIP_blonde_transfer_park.diff.txt fixes the issue for you? (Blonde Transfer is putnopvut's term for using an attended transfer like a blind transfer). This fixes it for using SIP transfers with me. Builtin attended transfers (completed early), still play the audio back to the wrong channel...but that can be opened as a separate bug later. It looks like it is going to be hard to fix. By: Michael Gaudette (bluefox) 2009-01-19 15:54:24.000-0600 I can tell you blind transfers always worked, but then you don't get to hear the parked extension (which is an issue when the parking sees alot of action). I'm not sure I understand the request. I see a patch, is this supposed to fix attended transfers or blind transfers? My question I guess, is what am I looking for after installing this patch? By: Terry Wilson (twilson) 2009-01-19 16:01:37.000-0600 Yes, blind transfers worked. Doing an attended transfer where you don't wait to hear the number and just go ahead and complete it (like you mentioned doing in your previous message) were what was broken. That is fixed in the referenced patch. We have started calling that kind of transfer a "blonde transfer" because it is a complete misuse of the attended transfer function that causes all kinds of problems for us. Unfortunately, telling people that it is dumb to use an attended transfer like a blind transfer isn't a solution. So, yes, please test the patch and see if it fixes your issues. By: Michael Gaudette (bluefox) 2009-01-19 20:44:28.000-0600 It seems to work on my test system. I did not see a problem with audio being played to the wrong channel either, so as far as I am concerned this fixes it. I would definitely wait until I can get my heavy parking user to try it before closing this though. A few questions, given that we confirm fo good this is good: 1) Will this patch work on 1.4.23 release? 2) Will this be incorporated on 1.4.24 and 1.6.x? By: Leif Madsen (lmadsen) 2009-01-20 00:52:04.000-0600 My guess is this will work against 1.4.23, and I'd expect this for 1.4.24, and 1.6.x (if applicable). By: Terry Wilson (twilson) 2009-01-20 12:33:32.000-0600 bluefox: is your having parking user going to test it before it is in a release? We generally close an issue when the commit is made. Since this is a regression, I need to get the commit in so it can be part of a release. I think both of us testing it out is enough to get it committed and close the issue. You can always reopen it if you find something unexpected. By: Digium Subversion (svnbot) 2009-01-20 12:40:40.000-0600 Repository: asterisk Revision: 169485 U branches/1.4/res/res_features.c ------------------------------------------------------------------------ r169485 | twilson | 2009-01-20 12:40:40 -0600 (Tue, 20 Jan 2009) | 6 lines Don't play audio to the channel if we've masqueraded (closes issue ASTERISK-13208) Reported by: bluefox Tested by: otherwiseguy, bluefox ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=169485 By: Digium Subversion (svnbot) 2009-01-20 12:47:58.000-0600 Repository: asterisk Revision: 169486 _U trunk/ U trunk/main/features.c ------------------------------------------------------------------------ r169486 | twilson | 2009-01-20 12:47:58 -0600 (Tue, 20 Jan 2009) | 13 lines Merged revisions 169485 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r169485 | twilson | 2009-01-20 12:40:56 -0600 (Tue, 20 Jan 2009) | 6 lines Don't play audio to the channel if we've masqueraded (closes issue ASTERISK-13208) Reported by: bluefox Tested by: otherwiseguy, bluefox ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=169486 By: Digium Subversion (svnbot) 2009-01-20 12:58:19.000-0600 Repository: asterisk Revision: 169487 _U branches/1.6.0/ U branches/1.6.0/main/features.c ------------------------------------------------------------------------ r169487 | twilson | 2009-01-20 12:58:18 -0600 (Tue, 20 Jan 2009) | 20 lines Merged revisions 169486 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r169486 | twilson | 2009-01-20 12:48:14 -0600 (Tue, 20 Jan 2009) | 13 lines Merged revisions 169485 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r169485 | twilson | 2009-01-20 12:40:56 -0600 (Tue, 20 Jan 2009) | 6 lines Don't play audio to the channel if we've masqueraded (closes issue ASTERISK-13208) Reported by: bluefox Tested by: otherwiseguy, bluefox ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=169487 By: Digium Subversion (svnbot) 2009-01-20 13:00:50.000-0600 Repository: asterisk Revision: 169488 _U branches/1.6.1/ U branches/1.6.1/main/features.c ------------------------------------------------------------------------ r169488 | twilson | 2009-01-20 13:00:50 -0600 (Tue, 20 Jan 2009) | 20 lines Merged revisions 169486 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r169486 | twilson | 2009-01-20 12:48:14 -0600 (Tue, 20 Jan 2009) | 13 lines Merged revisions 169485 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r169485 | twilson | 2009-01-20 12:40:56 -0600 (Tue, 20 Jan 2009) | 6 lines Don't play audio to the channel if we've masqueraded (closes issue ASTERISK-13208) Reported by: bluefox Tested by: otherwiseguy, bluefox ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=169488 | ||