In line. "Francois Audet" <[EMAIL PROTECTED]> wrote on 07/18/2007 11:26:54 AM:
> > > 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. > > I am not talking about multiple provisional responses from the same > endpoint. > > I am talking about multiple responses (provisional and final) from > multiple forks. For example, multiple 4XX responses. Yes, I understood that. > > While it is possible that a single forking proxy may decide to > include the RPH in all responses, that proxy has absolutely no > control over downstream and upstream proxies who may not include it > (they may be proxies in different domains). > > That's the point I'm trying to make. You can not enforce the > presence RPH in responses in a global system. Agree. For the context I am working in, a "global system" is not of concern. I would not expect universal "RPH in responses" in a global system. > > > 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. > > That is precisely the type of clarification that needs to be included > in the draft. It points out the constraints of the mechanism so > implementors use the feature properly. > > Some text explaining that the UAC needs to be able to deal with the RPH > not being present in responses gracefully (and why) is needed. I am not sure why that needs to be in the ID. It is an implementation specific issue. Since RFC 4412, as currently published, forbids RPH in responses, I think it "goes without saying" that "the UAC needs to be able to deal with the RPH not being present in responses". Further, while I know that the systems (and namespaces) _I_ work with intend to use RPH in responses, I also have been told that other systems (using other namespaces) do not intend to put RPH in ANY responses. I do not think there is any need to standardize this aspect, just to adjust the standard so it is PERMITTED. > > Similar text for proxies also need to be there. What if a proxy > forwards a request with RPH and it receives nultiple responses from > the downstream proxies, with some including the RPH and others not > including it? Does this need to be standardized? Again, I do not think there is a need to standardize this aspect. 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
