"Francois Audet" <[EMAIL PROTECTED]> wrote on 07/17/2007 05:45:58 PM:
> > What I mean is that the error response may not be delivered to the UAC > because a forking proxy will only deliver one final response. If there > are multiple error responses on the individual forks, one being the one > with the RPH, and the other being some other response, it is up to the > proxy to decide which one to forward back. > > So the UAC can not rely on receiving the RPH to "re-intiate" the session > or > provide some alternative treatment. This may or may not be a problem > depending > on the application (that's why I said "if it absolutely has"). > I don't think that will be a problem. For one thing (for the namespaces I am working with) the expectation would be that ALL the responses (except 100 and 403) would have the RPH on the response, so it wouldn't matter which one made it back to the UAC. Secondly, the expectation is that the devices responsible for "re-initiating" WOULD be stateful, and not dependant on the information in the RPH in the response. It is the intervening devices that might not be stateful, and would take advantage of the RPH information in the responses. Janet > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
