[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] New I-D: A solution for the HERFP caused by forked SIPINVITE requests
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.
- vijay
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP