[Home]

Summary:ASTERISK-07661: 302 Redirect from Transfer command passes diaplan flow on a timeout but continues to resend 302 redirect
Reporter:Chris A. Icide (cicide)Labels:
Date Opened:2006-09-01 19:00:57Date Closed:2006-10-29 13:37:43.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If a system that has been sent a 302 Redirect doesn't respond to the redirect, dialplan flow will continue on, however asterisk continues to send out retries of the 302 Redirect.

For example:

exten => _X.,1,Transfer(SIP/10.0.0.1,j)

exten => _X.,102,Dial(SIP/10.0.0.1/${EXTEN}

If 10.0.0.1 fails to reply to the 302 redirect, Asterisk jumps to priority 102 and continues on in the dialplan.  Meanwhile Asterisk continues to send retransmits of the 302 redirect while call flow continues.

This bug was found while attempting to redirect a incoming call, the carrier sending the call didn't support redirect to the point that they sent no response at all.  When the call was answered by the called party, the moment a 302 redirect retransmit was sent, the carrier dropped the call.

The correct functionality would be to not issue retransmits once call flow is passed to the next step in the dialplan, or to wait for the 302 to timeout via normal SIP timing mechanisms.
Comments:By: Serge Vecher (serge-v) 2006-09-05 08:57:02

I wonder if this actually needs to be addressed in Transfer() app itself, but just in case, can you please provide a SIP trace of this as per following?

1) Prepare test environment (reduce the ammount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterik.
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Save complete console log to file and _attach_ said file to the bug.
By: Olle Johansson (oej) 2006-10-17 13:05:45

The transfer() app is severly broken and needs to be fixed. There's no way we can report an error or anything back. I'm a bit surprised that execution continues after transfer() at all.
By: Olle Johansson (oej) 2006-10-29 13:24:44.000-0600

Doesn't the 302 time out like normal? Hmm.
By: Olle Johansson (oej) 2006-10-29 13:36:40.000-0600

Fix committed to 1.2 - rev 46406, 1.4 - rev 46407 and trunk - rev 46408

Thank you for the bug report. I finally understood the problem... :-)

regardless, the transfer application is in need of a new architecture.
By: Olle Johansson (oej) 2006-10-29 13:37:01.000-0600

Fixes committed to all branches and trunk.