SIP Router Project


FS#152 - t_reply 302 redirects use wrong to-tag after fr_inv_timer fires

Attached to Project: sip-router
Opened by Andrew Mortensen (admorten) - Saturday, 17 September 2011, 16:29 GMT
Last edited by Daniel-Constantin Mierla (miconda) - Tuesday, 23 December 2014, 09:42 GMT
Task Type Feature Request
Category Module → tm
Status Closed
Assigned To Andrei Pelinescu-Onciul (andrei)
Operating System All
Severity Medium
Priority Normal
Reported Version Development
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


If the failure route is armed and a call’s fr_inv_timer fires following a 180 with to-tag from the callee, invoking t_reply(”302”, “Redirect”) from the failure route does not use the to-tag from the callee. Instead, sip-router generates a new to-tag and attaches that to the 302 response. Our Polycom handsets then ignore the 302 because the to-tag does not match the to-tag it already received in the 180 from the callee. (Oddly, our Cisco gateways will happily redirect regardless of the unexpected to-tag in the 302. I suspect it has to do with a different reading of RFC3261 12.1 and 12.3.)

The attached patch stores the early dialog’s to-tag in t→fwded_totags, and passes the winning to-tag into build_res_buf_from_sip_req in the _reply() routine. This ensures the correct to-tag is part of the final response, so the UAC considers it an in-dialog response, and redirects as instructed.

This task depends upon

Closed by  Daniel-Constantin Mierla (miconda)
Tuesday, 23 December 2014, 09:42 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Re-open on github issues if still considered useful to implement, with a patch adding the option to enable/disable the behaviour via module parameter.
Comment by Daniel-Constantin Mierla (miconda) - Monday, 19 September 2011, 11:45 GMT

Hi Andrew, is this really SIP RFC requirement or even compliant? Thinking of serial/parallel forking, several and different To-tags can go back to caller within many 1xx replies. They have to be discarded and the one in final reply has to be considered good, so IMO the phone is buggy.

What happens if there is a parallel forking and there are many 1xx, but then timeout and 302? Which branch is considered good? Furthermore, one may have the redirect server as separate Kamailio instance, so on timeout of previous branches a new one is sent to redirect server which replies directly 302, having no idea of the branches in main proxy. What happens then, polycom will ignore it?

I understand it solves an issue with some Polycoms, but I don’t think it is the right approach to make this default in the proxy. Ideally Polycom will solve the bug. If it has to be “fixed” in the proxy, then it has to be something optional/configurable, with at less impact as possible on default behaviour.