Re: [Sipping] New I-D: A solution for the HERFP caused by forked SIPINVITE requests

["Dale R. Worley" <dworley at pingtel.com>]

On Fri, 2005-09-02 at 20:14 +0200, Jeroen van Bemmel wrote:
> For an unreliable transport the INVITE server transaction at the UAS
> remains in the CONFIRMED state for T4 (default : 5sec) after receiving
> an ACK. If the modified INVITE arrives within that time, according to
> section 8.2.2.2 the UAS will see it as a looping request (since it
> will have the same CSeq, from-tag and Call-ID)
>  
> What would be the least painful workaround?

I've been told (and I agree) that it is impossible for a proxy to
determine accurately whether a request is looping or not, since a
request may legitimately loop through a proxy if it is "different", and
the proxy really can't judge what differences will be significant to the
destination UAS or not.  So best current practice is for a proxy to not
do loop detection at all, but rather leave it to the UAS.

When a UAS receives an INVITE with the same dialog identifiers as it has
already received, it needs to judge whether this INVITE is "different"
from the previous one.  Assuming that the new one is "fixed" so that the
UAS will respond to it differently, it should not flag it as a duplicate
of the previous INVITE.

Dale



_______________________________________________
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