Fine with me.
Janet
"Audet, Francois (SC100:3055)" <[EMAIL PROTECTED]> wrote on 07/18/2007
02:58:39 PM:
> I will be happy if the document is revised to explain that you
> cannot expect that responses received by a UAC or Proxy will
> necessarily include RPM, in particular in systems where forking
> occurs, and that therefore, applications that use this draft must
> take it into account.
>
> From: Janet P Gunn [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 10:41
> To: Audet, Francois (SC100:3055)
> Cc: [email protected]; James M. Polk
> Subject: RE: [Sip] New draft modifying RFC 4412 for Responses
>
>
> 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
