I'm still going to beg off on this. I don't feel I have sufficient understanding of
the philosophy and intent behind these statuses. I would prefer to hear from someone
with more history.
Paul
Sachin Shenoy wrote:
>
> Hi Paul,
>
> I got your idea.
>
> I can think of 3 cases at proxy in which proxy might not want to go
> through with the call.
>
> 1. Proxy is low with resources (for the time being) and has to prioritize.
> 2. Proxy is down for maintenance.
> 3. Proxy doesn't want to allow particular user to establish call.
>
> 1. Proxy is low with resources (for the time being) and has to prioritize.
> In this case, I feel, proxy can send 500 with Retry-After. That would
> be sufficient indication to the user that proxy has encountered some
> internal error (i.e. in our case low with resources). The retry-after
> header
> would give the user and indication of when to retry. 500 Rsp would allow
> the UA to know that other calls may go through, but not this one
> (until the expiration of Retry-After).
>
> 2. Proxy is down for maintenance.
> In this case, proxy can send 503 with appropriate Retry-After. This
> would let the UA know that *NO* call will get through. So UA, need
> not try at all until the Retry-After time has passed.
>
> 3. Proxy doesn't want to allow particular user to establish call (Note proxy
> has resource but is denying to establish call).
> In this case, proxy can use one of the 4xx responses.
>
> Does this sound Ok? If yes, is this ok with any server (ie not just proxy)?
>
> Thanks
> Sachin
>
> At 07:30 AM 11/18/02 -0500, you wrote:
> >Sachin,
> >
> >That is an interesting question. I could make a case that this should be
> >handled independently for each user. (For instance, there is no guarantee
> >that the same result will be returned for all users. A proxy might
> >prioritize requests for favored clients.
> >
> >OTOH, the same argument applies, to a lesser extent, to different requests
> >by the same client. And from a practical point of view there is much to be
> >said for sharing this knowledge among multiple clients when available.
> >
> >I will have to defer to somebody more expert on this one.
> >
> > Paul
> >
> >Sachin Shenoy wrote:
> > >
> > > Hi Paul,
> > >
> > > On the same lines I have a query regarding handling of 503.
> > >
> > > According to RFC
> > >
> > > "21.5.4 503 Service Unavailable
> > > ...
> > > A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
> > > attempt to forward the request to an alternate server. It SHOULD NOT
> > > forward any other requests to that server for the duration specified
> > > in the Retry-After header field, if present."
> > >
> > > Consider that 2 users, user-A & user-B, who are sharing the same code
> > > on the same server ( ie. using the same UA process).
> > >
> > > User A sends request out. (The destination was resolved and the request was
> > > sent out).
> > > But the request was rejected with a 503 response which had retry-after
> > header.
> > >
> > > Now User B tries to send a request out, which resolved to the same server.
> > > Should the stack send the request out without bothering about the
> > previous 503
> > > that it had received, or should it try another server?
> > >
> > > I think in this case we should not send the request to the server. Because
> > > in a
> > > gateway there could be thousands of users using the same UA, and if a
> > server
> > > is down for maintenance, there is no point in again and again sending
> > requests
> > > (from different users) to the server that had already responded with 503.
> > >
> > > Hope I got it right?
> > >
> > > Thanks
> > > Sachin
>
> _______________________________________________
> 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
