inline
> -----Original Message-----
> From: A Venkatraman [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 16, 2001 10:58 AM
> To: Robert Sparks; 'Paul Kyzivat'
> Cc: 'Bob Penfield'; Wei BJ Lu; [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] How does forking proxy handle
> To Tag in
> errorresponse selection?
>
>
> Robert
> It is understood that the receipt of a non-2xx final response
> on one of the
> provisional call-legs should cleanup the state in all other
> call-legs for
> that transaction and a timer started for the call-leg that
> received the
> non-2xx final response.
> If a 2xx class response is received on one call-leg, a timer should be
> started on the other legs for cleaning up if no 2xx class is
> ever received
> on the others.
> I am not sure that we should impose an additional twist on the UAC by
> allowing the proxy to create a new call-leg by sending the
> non-2xx response
> with a tag that is different from the ones on the
> provisionals that have
> been forwarded, earlier.
The point is you cannot prevent it. A proxy could very
legitimately have reasons to reply on its own, even after
having forwarded state loading provisionals. We aren't
imposing an additional twist - this is a scenario that has
always existed.
> When picking a best reponse, can we not suggest that the
> proxy re-use a tag
> from one of the final responses it is choosing from?
I suspect that most implementations are going to do that
anyhow. Even so, such a recommendation is pointless. Consider
this case:
A
/
P2
/ \
requestor --P1 B
\
C
Where A and C send some provisional response that causes
the requestor to create state, but B only sends a 100.
Everybody returns non-200 final responses.
Suppose P2 chooses B's response to forward (it was better than
A's) and reuses its tag, and P1 chooses P2's respsonse, again
keeping B's tag.
The requestor is now in _exactly_ the same position it would
have been if P2 had created its own tag.
RjS
> Venkat
>
> -----Original Message-----
> From: Robert Sparks [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 16, 2001 10:43 AM
> To: 'Paul Kyzivat'; Robert Sparks
> Cc: 'Bob Penfield'; Arunachalam Venkatraman; Wei BJ Lu;
> [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] How does forking proxy handle
> To Tag in
> errorresponse selection?
>
>
> I assume you are asking about how endpoints deal with any state
> they may created due to provisional responses, and not really
> about what the proxy does with multiple provisionals? (Venkat
> was asking this question).
>
> A stateful proxy just forwards any provisional (except 100)
> it sees.
>
> Basically, you are doomed to clean up such state with timers.
> Consider the following:
>
>
> A
> /
> requestor - P1
> \
> B
>
> Where A and B return a state-invoking provisional. Suppose
> now that both A and B reject the dialog, each returning a
> 486 perhaps. Even if P1 preserves the tag from one, you have
> no way of seeing a final response containing the tag of the
> other.
>
> RjS
>
>
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 16, 2001 10:18 AM
> > To: Robert Sparks
> > Cc: 'Bob Penfield'; Arunachalam Venkatraman; Wei BJ Lu;
> > [EMAIL PROTECTED]
> > Subject: Re: [Sip-implementors] How does forking proxy handle
> > To Tag in
> > errorresponse selection?
> >
> >
> > 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
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
