Paul, I really don't have a problem with a UAC behaving this way for an outbound proxy. I'm more concerned with more complicated UAs like a gateway that selects the proxy/redirect server based on things like the calling & called numbers. I'm also wondering whether a proxy would have to behave the same way if it inserted a Route header in order to direct the request to a redirect server. Or in the case of a proxy would the "original request" be the request is received (w/o the Route header to the redirect server) instead of the request it sent to the redirect server?
cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 [EMAIL PROTECTED] ----- Original Message ----- From: "Paul Kyzivat" <[EMAIL PROTECTED]> To: "Bob Penfield" <[EMAIL PROTECTED]> Cc: "Jonathan Rosenberg" <[EMAIL PROTECTED]>; "Magnus Edev�g" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, January 02, 2003 10:58 AM Subject: Re: [Sip-implementors] request uri & where to send message? > Bob, > > This depends on how the UAC is configured. Many can be configured with > an "outbound proxy" thru which all outbound requests are routed. Based > on 3261 it seems that the preferred way for the UAC to implement the > outbound proxy functionality is to preload requests with a Route header > referencing the outbound proxy. In general there will be little > intelligence in the UAC about this - it will simply insert the Route > header in all new outbound requests. (Presumably those that aren't part > of a dialog.) > > It would be unwise to configure such a UAC with an outbound "proxy" that > is in reality a server which always returns redirect responses. It > clearly wouldn't work. > > You could of course construct a UAC that knows about a redirect server, > and knows how to use it. But it would require more complex logic in the > UAC to do the right thing. > > You can't simply expect a UAC that has an outbound proxy to bypass that > proxy every time it gets a 3xx response. The 3xx may have come from > further downstream, and the proxy may still be needed when retrying with > the new address. > > Paul > > Bob Penfield wrote: > > inline > > ----- Original Message ----- > > From: "Jonathan Rosenberg" <[EMAIL PROTECTED]> > > > >>inline. > >> > >>Bob Penfield wrote: > >> > >>>inline > >>>----- Original Message ----- > >>>From: "Paul Kyzivat" <[EMAIL PROTECTED]> > >>> > > <snip> > > > >>>>If the client is treating the server as an outbound proxy, by using a > >>>>preloaded Route header, why would it decide not to use the same > >>>>preloaded route header when sending to the redirected address? > >>>> > >>> > >>> > >>>You could certainly do that, but I if that server is just a redirect > >> > > server > > > >>>and not a proxy, there is no need to send the subsequent request back > >> > > thru > > > >>>the server. > >> > >>The UAC may not know that, though. Indeed, the spec does say that the > >>Route headers would be present in the recursed request. From 8.1.3.4: > >> > >> > In all other respects, requests sent upon receipt of a redirect > >> > response SHOULD re-use the header fields and bodies of the original > >> > request. > >> > >>Local outbound redirect servers, IMHO, are a bad idea, because they can > >>cause a ping-ponging effect. > >> > > > > > > This does not seem right to me. The UAC has decided by some local policy to > > contact a given next-hop server and sends it a request. That server says, I > > can't do it, but so-and-so can by sending a redirect response. Why would the > > UAC then send the request back to the same server that just told it to go > > somewhere else? > > > > With the above rule, how would you ever not send it back to the redirect > > server? My understanding of 3261 is that unless you are sending the request > > to host indicated in the Request-URI, you put a Route header in. > > > > > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
