Jeroen van Bemmel wrote:
Dale, Vijay,
Thanks for bringing this up. As I tried to sketch in a later email to the
list, the proposal is now to send a completely new INVITE to fix a
repairable error, independent of the original INVITE transaction /
dialog. I believe that would be safest, I imagine that even though a UAS
should not flag a 'fixed' (thus modified) INVITE request as a duplicate,
if it has the same CSeq, from-tag and Call-ID (and no to-tag) I fear that
many current UA will see it as duplicate anyway, in particular when they
strictly follow RFC3261.
I don't see how for rfc3261 at least; the topmost via branch of the
fixed INVITE will be different than the original one. Older user
agent servers (rfc2543 compliant) may detect this as a duplicate
(see Section 10.1.1 of rfc2543) since they only took in account
the Call-ID, To, From and CSeq. Newer ones should not.
A potential issue is that this new INVITE will follow a different route
(it won't go through the forking proxy again, unless the proxy
record-routes), but I think the alternative (merging the new with the
'old' INVITE and trying to work around duplicate detection anomalies and
other issues) is worse.
Would you agree?
Yes, sending the new INVITE is a little better. But all these
compromises and issues simply point to the basic fact that
fixing HERFP cleanly is non-trivial.
With your updated proposal, the call flow is now:
UAC Proxy
INV--->
...
<---FIX
200 OK FIX--->
INV------------------> To the real UAS
...
The call flow for Rohan's I-D is:
UAC Proxy
INV--->
...
<---130
PRA---> ----\ PRACKs are optional
<---200 OK ---/
INV--->
...
Both will get the job done. I think some more discussion needs
to be done in the WG to list out the pros and cons of each
to reach an optimal solution by fine-tuning them.