On Tue, 2008-09-23 at 16:43 -0400, Kathleen Eccles wrote: > Fixing this issue requires changing how we select proxy responses. > I propose the following behavior: > > 1 - Responses from outside the proxy should be preferred over responses > generated internally by the proxy.
Does the proxy generate any response internally other than 408 for timeout? > 2 - 2xx responses should be preferred over all others; > -- Within 2xx responses, 200 responses should be the least preferred. > 3 - 3xx responses should be preferred over 4xx, 5xx, 6xx; > -- Within 3xx responses, 300 responses should be the least preferred. I think that 2xx responses are required to be forwarded upstream immediately and cause the transaction to be terminated (no longer generate forks). Further 2xx responses received must be forwarded upstream immediately. I think that 3xx responses are acted upon immediately to generate new forks. So the only classes of responses we can choose from among are the 4xx, 5xx, and 6xx failure responses. > 4 - 6xx responses should be preferred over 4xx, 5xx. > 5 - 4xx responses should be preferred over5xx; > -- Within 4xx responses: > --- 404 should not be returned unless it is the only valid response. > --- 408 should not be returned unless 404 is the only other valid response. > --- 487 should only be returned if the calling party generated the CANCEL > request. > 6 - 5xx responses should be the least preferred. We need to ensure that responses that imply ways to recover from failure have a high priority. 401, 407, and 491 are the usual candidates for this treatment. > This behavior will probably require that we distinguish more clearly between > external requests/responses and > those generated internally by the proxy. > > Current behavior is demonstrated by the following test cases: > ======================================================== > I have created three test cases. > For all cases: > User 771 is configured to forward simultaneously to 272 and 274 and has no > voicemail. > User 272 is configured with a registered phone. User 274 is not configured > with a registered phone. > User 271 calls 771, Registrar returns 302 with contacts for 272 and 274. > Proxy forks two invites(272, 274) to self. > For 272-forked-Invite, Registrar returns 302 with single contact; > For 272-forked-Invite, Registrar returns 404 for User 274. > Proxy "forks" single invite(272) to self. > Proxy sends single invite to 272. > > ---------------------------------------------------------- > Case 1- Simply don't answer call to 272. > Result:404 response is sent to caller(271), > Preferred response: 408 > > Details: > - 272 rings for approx 30 seconds. > - After 30 secs, 404 response is sent to caller(271) and > - Cancel is sent for invite to 272 and > - 408 response is generated and consumed within proxy for 272 fork(s). It seems to me that 487 Canceled would be preferable, although I don't know if we can cause that to happen. But I see 487 as indicating "ring no answer" as well as "caller canceled call". > ---------------------------------------------------------- > Case 2- Caller 271 hangs up. > Result: 404 Response is sent to caller (271) > Preferred response: 487 > > Details: > - Cancel is sent to 272 fork(s). > - 487 response is returned by 272. > - 408 response is generated within proxy for 272 fork(s). > - 404 Response is sent to caller (271) > > > ---------------------------------------------------------- > Case 3- Caller 272 refuses call. > Result: 404 response is sent to caller (271). > Preferred response: 603 > Details: > - 603 response is returned from 272. > - 603 response is returned on all internal proxy paths. > - 404 response is sent to caller (271). Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
