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
