Summary:	ASTERISK-14559: Transfer to parking lot replies '202 Accepted' rather than '480 Temporarily Unavailable' when lot is full
Reporter:	nick_lewis (nick_lewis)	Labels:
Date Opened:	2009-09-24 12:05:58	Date Closed:	2011-06-07 14:07:56
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When using sip refer to blind transfer to the parking lot, asterisk always responds '202 Accepted'. When the parking lot is full it should instead respond '480 Temporarily Unavailable'. ****** ADDITIONAL INFORMATION ****** Rather than leaving everything to the ast_park_call function (too late), it needs to be possible to reserve a space in the parking lot up front (reserved=ast_park_reserve()). Only if the reservation is successful should the transfer be accepted, channel masqueraded, etc etc. There may also need to be a timeout for the reservation so that if for any reason the call is not parked in the reserved space, it can be made available again. (A crude alternative would be an ast_park_full function)
Comments:	By: Leif Madsen (lmadsen) 2009-09-28 12:59:47 Setting this to Acknowledged. I suppose you wouldn't be able to provide a patch to correct this behaviour? :) By: nick_lewis (nick_lewis) 2009-09-29 03:16:33 I have to admit that I only implemented the quick and dirty ast_park_full function. This function was just a copy and paste of the existing "No more parking spaces\n" check at the beginning of ast_park_call This approach works 99.9% of the time as there is little chance of parking lot churn between requesting a transfer to the parking lot and actually doing it. The "No more parking spaces\n" check is still in ast_park_call as well so for the other 0.1% it is no worse than the current implementation. Having said all that I am not promoting the quick and dirty approach. A reservation system which reserves and returns a parking space number is the better solution. By: Leif Madsen (lmadsen) 2009-09-29 08:35:11 OK, thanks! By: nick_lewis (nick_lewis) 2009-12-15 04:19:29.000-0600 I see that a park_space_reserve function was fairly recently added to features.c. At the moment it is used only for dtmf initiated transfers to parking lots but there is no reason it cannot also be used in chan_sip.c for the same purpose. For example (in pseudocode): sip_park_thread() { pu = ast_park_space_reserve() if (!pu) { transmit_response("480 Temporarily Unavailable"); } else {  ast_do_masquerade()  res = ast_park_call(pu); } } By: David Woolley (davidw) 2009-12-15 05:31:50.000-0600 I believe that 202 Accepted is the correct response.  At that stage, all you are saying is that you implement REFER, the REFER request was well formed, and it doesn't violate policy.  (In the general case of a SIP refer, the recipient will then issue an INVITE, and only when it gets a final response to the INVITE, would it know whether the number was reasonable.) The correct place to signal that there is no parking lot is in a subsequent NOTIFY. As this is a SIP issue, you need to follow the SIP bug reporting guidelines and supply traces.  However, the correct way dealing with the failed call is to make sure that the Park application doesn't answer the call until it is sure that it will succeed.  When the call then fails, the NOTIFY will tell the transferor that it should resume the original call, which it should not have released until it got a final status in a NOTIFY. It think this is what you are eventually saying, but it doesn't result in the replacement of the 202 Accepted, it causes a NOTIFY, at a later stage. Incidentally, I think your pseudo code looks too like real code and may need to be submitted as a licensed attachment. By: nick_lewis (nick_lewis) 2009-12-15 07:57:04.000-0600 Yes I agree that behaviour should be as per other blind transfers to unavailable destinations. So the failure to park should be reported in the NOTIFY and not the initial response to the INVITE. Irrespectively I think there needs to be a call to ast_park_space_reserve in order to try to reserve an ast_parkeduser slot before any masquerading stuff. Otherwise it is difficult to rollback if no slots are found later on. Having looked again I think this reservation probably needs to be right back at !strcmp(p->refer->refer_to, ast_parking_ext()) rather than in sip_park or sip_park_thread so these will need to be passed an additional parameter e.g. struct ast_parkeduser *pu (as of course will ast_park_call) By: nick_lewis (nick_lewis) 2009-12-15 08:57:12.000-0600 Blind transfers to unavailable destinations used to be answered by asterisk with "484 Address Incomplete" but are now answered with "202 Accepted" followed by a notify with "503 Service Unavailable" so I guess parking is behaving consistently. Whether this new behaviour a good idea for UAC compatibility is another matter but since it agrees with RFC5589 this is not a bug. Please close this ticket By: Leif Madsen (lmadsen) 2009-12-15 09:49:03.000-0600 Closed per the reporter.