Hi,
Maybe sending the RPH to the UAC is something that the 199 mechanism could be
used for.
Regards,
Christer
________________________________
From: Francois Audet [mailto:[EMAIL PROTECTED]
Sent: 18. heinäkuuta 2007 21:59
To: Janet P Gunn
Cc: [email protected]; James M. Polk
Subject: RE: [Sip] New draft modifying RFC 4412 for Responses
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
