[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



To start off:
 
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?
1. Have the UAC or proxy select a to-tag, such that 8.2.2.2 processing is skipped
2. Have the proxy delay if less than 5sec has passed since the ACK was sent
3. Other options?
 
(all only in case an unreliable transport is used)
 
Regards,
 
Jeroen
----- Original Message -----
To: sipping
Sent: Friday, September 02, 2005 7:36 PM
Subject: [Sipping] New I-D: A solution for the HERFP caused by forked SIPINVITE requests

All,
 
I have submitted a new Internet Draft regarding HERFP to the IETF. While it is being processed, a copy of the document can be found here to start discussions: http://home.versatel.nl/jbemmel/draft-jbemmel-herfp-solution-00.txt
 
Best regards,
 
Jeroen van Bemmel


_______________________________________________
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
_______________________________________________
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