New subject: PATCH: use correct to-tag in 302 redirects following early dialog creation

16 Sep 2011

Hi all. We've recently been experimenting with 302 redirects as the vehicle for
call-forwarding, and ran into an issue with call-forward no answer. A small patch against
(see below) fixed things.

Caller and callee are Polycom 550s. The caller sends an INVITE to the callee, and the
callee returns a 180 with a to-tag, establishing an early dialog. When sip-router's
fr_inv_timer fires and sends the fake 408 reply to the INVITE, we handle enter the failure
route and redirect to the forwarding address:

	# ... set URI to forwarded target here ...
	t_reply("302", "Call Forwarded");
	exit;

This should have worked, but in our testing the caller would completely ignore the 302. I
tracked it down to sip-router returning a new to-tag in the 302, not the to-tag used in
the early dialog. The Polycoms were evidently rejecting the 302 from sip-router as not
matching any known dialog because of the unrecognized to-tag. [1]

My patch simply stores forwarded to-tags for early dialogs, making the winning to-tag
available for the 302 reply. We've tested it with 3.0.3; the patch below is against
git head. I'm happy to revise it to get it into acceptable form. Please let me know.

Best,
andrew

[1] Oddly, our Cisco gateways don't care about the new to-tag from sip-router, and
will happily redirect regardless of the tag value in the 302. Perhaps it's the result
of a looser interpretation of RFC 3261 12.1 and 12.3.