[asterisk-dev] 302 redirects ocassionally ignored; hypothesis: later queued busy preferred to earlier early media frame

[Dave WOOLLEY]

Richard wrote:

> Without looking into the code, queueing a busy frame to wake up the read 
> thread and look at the call-forward string seems wrong.  The null frame 
> should be queued instead.

This is the code from branch 11 SVN (branch 12 seems to be the same).  Whilst it is done as a drop through, part of the logic may be to provide and appropriate behaviour if redirects have been disabled at a higher level.  change_redirecting_information eventually sets the field containing the address information that Dial uses to detect the redirection.

				case 302: /* Moved temporarily */
				case 305: /* Use Proxy */
					if (p->owner) {
						struct ast_party_redirecting redirecting;
						struct ast_set_party_redirecting update_redirecting;

						ast_party_redirecting_init(&redirecting);
						memset(&update_redirecting, 0, sizeof(update_redirecting));
						change_redirecting_information(p, req, &redirecting,
							&update_redirecting, TRUE);
						ast_channel_set_redirecting(p->owner, &redirecting,
							&update_redirecting);
						ast_party_redirecting_free(&redirecting);
					}
					/* Fall through */
				case 486: /* Busy here */
				case 600: /* Busy everywhere */
				case 603: /* Decline */
					if (p->owner) {
						sip_handle_cc(p, req, AST_CC_CCBS);
						ast_queue_control(p->owner, AST_CONTROL_BUSY);

One point of detail.  It is actually the write to the alertpipe, within ast_queue_control that does the wakeup.

-- 
David Woolley
BTS Holdings Plc
Tel: +44 (0)20 8401 9000 Fax: +44 (0)20 8401 9100
http://www.bts.co.uk 

BTS Holdings PLC - Registered office: BTS House, Manor Road, Wallington, SM6 0DD - Registered in England: 1517630