[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



All,
 
With apologies for the monologue, I'd like to share a thought I had after submitting the draft:
 
Instead of sending the modified INVITE back to the proxy and merge it with the ongoing call attempt, a new (second) call attempt by the UAC would be much simpler. The proxy could provide the Request URI it used in a Contact header (perhaps along with other information that resulted from consulting the location service) and send the response in a FIX body as described. The UAC can accept it or not, the proxy considers the branch failed regardless. The second INVITE will not follow the same route as the original, but the question is: is that really a problem?
 
UAS would be similar: FIX with Contact header (as it would provide in a 2xx response to the INVITE)
 
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