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.
sr-t_reply-302-totag.patch
Description: Binary data
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
