I'm setting up some tests to a UAS that responds with an rfc5626 sip.instance tag on the contact. The current behavior (v5.3.1 at least) grabs the contents of the contact header between the first < and the last > and my UAS cannot parse an ACK because the R-URI is invalid. Example:

200 OK contains the following contact:

Contact: <sip:user@X.X.X.X:58292;transport=tcp;alias=Y.Y.Y.Y~58292~2>;+sip.instance="<urn:uuid:0f35feab-c878-4622-a94e-b2e6e812b177>"

And the next_url populates with the following in the ACK:

sip:user@X.X.X.X:58292;transport=tcp;alias=Y.Y.Y.Y~58292~2>;+sip.instance="<urn:uuid:0f35feab-c878-4622-a94e-b2e6e812b177

The UAS sees this as invalid and the dialog cannot be established.

I am working around this by re-factoring the R-URI in my proxy, but I couldn't figure out any other workaround for the issue. Ideally, the next_url would be parsed up until after the transport tag if present.