Robert - thanks for the clear explanation. It is helpful.
So what happens if the proxy receives 183 from more than one of the
forked destinations?
Paul
Robert Sparks wrote:
>
> There is some subtlety here that's important to understand.
>
> The restriction below is not actually in the text - I'm working
> to try to find a way to make it harder for people to reach it and
> welcome input.
>
> First - we are talking about a proxy that is handling a transaction
> statefully. If the transaction is being handled statelessy, it doesn't
> deal with this whole "best" response concept.
>
> When a stateful proxy sends any non-200 response (basically any
> hop-hop response), it is really responding on its own as a UAS
> using the various responses it received as inputs.
>
> It MAY choose to reuse the To: tag from one of those inputs if
> it chooses to forward it, but ->nothing<- will break if it chooses
> to make up its own.
>
> In fact, there are cases where its going to have to - if every
> downstream proxy for this particular request returns a 503, this
> proxy probably is probably going to return a 4xx and provide its
> own tag (other requests going through other downstream proxies
> may yet succeed). If the proxy determines that the whole world
> has gone sour and wants to return its own 503 - it really is making
> a statement about itself, not forwarding a statement about proxies
> downstream from it.
>
> Consider further a proxy that acts as a redirect aggregation service -
> every place it sent this request to returns a 302. It chooses not to
> recurse, but to pool all the contacts into one big collection and
> send it upstream. The resulting 302 comes from _this_ element (acting
> as a UAS). So does it add its own tag or reuse one from one of the
> responses it received? It _doesn't matter_. An implementation could
> just pick one of the received 302s, copy the contacts from all the
> others into it and forward it. Or it could build its own response
> from scratch, making its own tag in the process. The end result from
> a system perspective is exactly the same.
>
> The same is true for returning a 401/407 (where a proxy has to
> aggregate all of the challenges from any other 401s or 407s its
> seen into this one).
>
> The main thing to remember is that as non-200 responses, they
> are hop-hop. The tag information contained in them has _NO_CHANCE_
> of being used to construct an ongoing dialog. An element could
> munge the tag for _every_ forwarded non-200 replacing it with its
> own value (globally unique to the transaction of course) and
> nothing breaks. From a system perspective, nobody could even tell.
>
> Responses that might create a dialog are a whole different matter.
> The restrictions on not touching the tags there are very important.
>
> RjS
>
> > Based on table 3 (Summary of Header fields), and on the text
> > in section
> > 16.6, the proxy is not allowed to modify the To header in the
> > "best" non-2xx
> > final response it sends to the UAC. Therefore, the proxy is
> > not allowed to
> > add a tag, or change the tag in the response.
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
