On Wed, 2008-09-24 at 12:22 -0400, Scott Lawrence wrote: > 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. > > I'm not sure I understand yet why this rule is needed. > > > 2 - 2xx responses should be preferred over all others; > > -- Within 2xx responses, 200 responses should be the least preferred. > > Robert got this right in his reply. Right, I was tired. > > > 3 - 3xx responses should be preferred over 4xx, 5xx, 6xx; > > -- Within 3xx responses, 300 responses should be the least preferred. > > But of course in the forking function we never actually send those back > upstream, just start new child transactions to act on them. Correct. > > > 4 - 6xx responses should be preferred over 4xx, 5xx. > > Actually, I think not. This probably deserves some discussion, since it > is not what the standard says... > > Dale did an Internet Draft on this a while ago that was focused on > getting User Agents not to send 6xx. The problem is that in the real > world in SIP there may not be anyone that has the required global > knowledge. > > I suspect that the right thing to do is to forward 6xx only when it is > the only alternative (move it to the end of this list, which I further > suspect means we never really send them, which is a good thing). > What about this case where the phone returns 603? (LG-6830)
> > 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. > > Can't we just express that as a preference order? > > 4xx != 404|487|408 > because it is probably more specific than those below > 487 if CANCEL was received on server side > 408 > because it means we found somewhere to go but it did not > answer > > > 6 - 5xx responses should be the least preferred. > > not quite - I think they are preferred over 404 (which may be what you > meant), so 404 goes after 5xx > > > This behavior will probably require that we distinguish more clearly > > between external requests/responses and > > those generated internally by the proxy. > > I'd like more discussion of why this is needed. For instance, what happens if a 404 response is returned from downstream? Is that preferred over a 408 on another fork? Is a registrar 404 preferred over a 408 on a different fork? A timeout causes an internal 408 and cancels all other forks. These forks then return 487. Should those 487 be preferred over the real cause (timeout)? > > > 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). > > Agree with your preferred response. > > > ---------------------------------------------------------- > > 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) > > Agree with your preferred response. > > > > ---------------------------------------------------------- > > 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). > > I believe that we should consider translating this to something else - > I'd actually be Your message stopped in mid <something> -ke _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
