Subject: RE: [Sipping] draft-elwell-sipping-redirection-reason-01

From: "Francois Audet" <[email-masked]>
Date: Thu, 10 Feb 2005 19:56:14 -0500

Yes, I agree with all your points. It's also quite entertaining :^)

Again, from my point of view, the current Reason header
has enough information, except for the difference between
a 302 for redirection (as in routing) versus "forwarding
for any non-routing reasons".

In fact, even from the point of view of the client making the
initial INVITE request, it seems to me that it should be able
to know if the 302 is for "routing" (redirect server) reasons versus 
"forwarding" reasons. The client may want to behave differently based 
on either case. Today, they look the same.

If the resons were different, then it would indeed be carried in 
History-Info.

> -----Original Message-----
> From: David R Oran [mailto:[email-masked]] 
> Sent: Thursday, February 10, 2005 12:26
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Cliff McCollum'; 'Paul Kyzivat'; [email-masked]'; 
> 'Elwell, John'
> Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
> 
> 
> 
> On Feb 9, 2005, at 10:54 PM, Francois Audet wrote:
> 
> > Actually, Dave, this is exactly the problem. History-Info 
> will indeed
> > keep track
> > of the information, but that information may be ambiguous 
> because the 
> > usage of
> > 302 is ambiguous.
> >
> OK, I'll buy that, but the set of potential "reasons" why somebody 
> decided to 302 you is unbounded. I have no objection to having a 
> Reason: header on the 302 response (which is of course obvious as I'm 
> one of the authors of the reason header draft). As others 
> have pointed 
> out, the reason is incorporated into the History Info and carried 
> forward in requests (barring all the privacy considerations, 
> of course) 
> so none of this should be controversial.
> 
> What I object to is is a direct coupling between a reason header and 
> mandated behavior on the part of a server receiving a request. So, if 
> it will make people happy to have some reason codes defined (or 
> imported from Q.mumble) I don't object to that.
> 
> However, the REAL issue is the extensibility one John brought up and 
> how to avoid creating a registry swamp. with entries like: 
> "Happy Hour" (from my earlier message) "I think this caller 
> is a bozo" (so you play the "you can leave a 
> message, but he probably won't listen"
> "I'm dead" (the reason you got "3.. moved temporarily to 
> purgatory") "I'm not really busy, but I hit the DND button on 
> this phone cause I'm 
> stressed out"
> 
> If that's the end game here, you're better off just allowing the 
> servers to process the text of the response code and figure 
> things out 
> from there:
> 302 Happy Hour
> 302 Deal with this bozo
> 304 Dead in purgatory
> 304 Made it to heaven
> 304 Oops, sent to the other place
> 302 I just can't handle the stress now, ok?
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Feb 2005 10:20:45 -0500

This still all seems like reading tea leaves to me. It seems to mix up 
mechanisms with goals and results.

Suppose Alice isn't home - she is visiting Bob. Her *goal* to receive 
calls directed to her AoR at the phone in Bob's office.

There are many *mechanisms* she could use in an attempt to achieve this. 
Here are a few:

1)she could put a forward no answer rule into the proxy
   managing her AoR. Calls directed to the AoR will then try the
   registered contacts, and if none answer, the call is forwarded
   to Bob's AoR. Once there Bob's proxy will forward to Bob's
   phone and it will ring.

2)she could cause a registration to be made to her AoR, with
   Bob's AoR as the contact address in the REGISTER. Then calls
   directed to her AoR will try Bob's AoR along with the other
   registered contacts, ordered by q-value. If she makes the
   q-value low then Bob's AoR will be tried last. Once the
   call is forwarded to Bob's AoR, Bob's proxy will forward to
   Bob's phone and it will ring.

3)same as (2) except she registers an address of Bob's *phone*
   (rather than his AoR) with her AoR. Calls directed to her
   AoR will be forwarded to the registered contacts, including
   Bob's phone. Once the call reaches Bob's phone it will ring.

4)all of the above could be done with 302 responses any place
   the call is forwarded.

 From Alice's point of view these all have the same *goal*. And they all 
have the same result. But the mechanisms are different. Also, I think it 
is clear that the same result could arise from different goals.

I think you are trying to record is either the *goal* or the *result*. 
(I am really not sure which.) But for the most part what is being 
recorded is the *mechanism*.

You seem to want to know *why* a proxy has chosen a particular next hop, 
or *why* a particular contact was registered to an AoR, or *why* a 
server returned a 302. (The latter is recursive, because to answer that 
it may need to know why it was given the contacts that it is returning 
in the 302.)

We have no mechanism defined to specify why a contact is registered with 
an AoR. So any time a proxy forwards to, or redirects to, a registered 
contact, it has no reason what the goal is of going that way. In cases 
2&3 above, Alice's proxy has no way to know that the reason for 
forwarding to the contact of Bob's AoR or phone is any different than 
forwarding to Alice's own phone.

There are no standards for nodes making forwarding or redirecting 
decisions. So in general we can't expect them to know *why* in the sense 
that you seek. So getting useful value from this approach depends on a 
bunch of nodes all knowing stuff that they may well not know.

It seems like it would be more reliable to just depend on the reliable 
information - the results, and give up on the goals.

Or, are you perhaps planning to require that components be built to 
know, and used in a way that permits them to know, the goals, so that 
can be captured and used to enable certain features?

	Paul