sorry about the truncated message.... evolution crashed and I didn't
notice it had not recovered everything.
On Wed, 2008-09-24 at 13:03 -0400, keccles wrote:
> On Wed, 2008-09-24 at 12:22 -0400, Scott Lawrence wrote:
> > On Tue, 2008-09-23 at 16:43 -0400, Kathleen Eccles wrote:
> > > 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)
That's what the draft is about - a phone should never return any 6xx
code. The 6xx responses imply global knowledge that phones never have.
The usual reason for a 6xx code from a phone is that a Reject button was
pressed. There are two things that _might_ be meant by that:
A. I want this call rejected everywhere so that it does not go to
my voicemail or any other possible recipients.
B. I want this call to stop ringing on this phone now, but let it
go to my voicemail.
In case A, we would want to kill the transaction up the tree until the
target address was not the same, so for example if:
771 forwards simultaneously to 272 and 274, and then voicemail.
272 has a registered phone and voicemail.
274 has no registered phone and no voicemail
So, now someone calls 771:
* call forks to 272 and 274
* 272 starts ringing
* 274 returns 404
* user at 272 presses 'reject', returning 603
Many people (not I) would argue that that call should now go to
voicemail for 771, because it was the 272 address that was rejected, not
the 771. This gets into a distinction that they try to make between
'retargeting' by which they mean "sending to a Contact for some AOR",
and 'redirecting' by which they mean "sending to a different AOR".
If you're thinking that that is a pretty fine distinction, then you
agree with me. There really isn't any difference between a Contact
address and an AOR - they are both just addresses you send the message
to and maybe you get somewhere useful and maybe you don't.
So... I think that a 603 coming from downstream is pretty hard to credit
with knowing enough about what is going on to do what the standard says
and kill everything. I'm prejudiced in favor of giving every call the
maximum chance of landing _somewhere_ rather than being rejected; if
that's not what they wanted, they can always delete the voicemail.
Essentially, treat any 6xx as some 4xx code (403 is probably best), and
if that is the best response you've got, forward the 403 upstream.
> > > 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)?
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
