[asterisk-bugs] [Asterisk 0014066]: Calls parked fail to return to the correct phone after timeout

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14066 
====================================================================== 
Reported By:                bluefox
Assigned To:                otherwiseguy
====================================================================== 
Project:                    Asterisk
Issue ID:                   14066
Category:                   Features/Parking
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.22 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2008-12-11 20:01 CST
Last Modified:              2009-01-14 14:54 CST
====================================================================== 
Summary:                    Calls parked fail to return to the correct phone
after timeout
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)
====================================================================== 

---------------------------------------------------------------------- 
 (0097817) otherwiseguy (administrator) - 2009-01-14 14:54
 http://bugs.digium.com/view.php?id=14066#c97817 
---------------------------------------------------------------------- 
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 at 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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-14 14:54 otherwiseguy   Note Added: 0097817                          
======================================================================