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

From: "Francois Audet" <[email-masked]>
Date: Wed, 9 Feb 2005 22:54:22 -0500

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.

302 is used for call routing, in the spirit of section 8.3/RFC 3261 on
redirect servers. The term "redirection" in used in that section.
In my mind, the procedures of section 8.3/RFC 3261 is what this "normal 
redirection" is meant to be.

302 is also commonly used to provide "call forwarding" features. For
example, 
a SIP UA can send a 302 to "forward" the session to another SIP URI. This
is what I usual think of retargetting.

The problem is that the two scenarios with the INVITE coming into the VM
service 
(for example) will not be distinguishable from the history-info. See:
http://www1.ietf.org/mail-archive/web/sipping/current/msg06919.html.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David R Oran
> Sent: Wednesday, February 09, 2005 12:04
> To: Cliff McCollum
> Cc: Elwell, John; Paul Kyzivat; [email-masked]'
> Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
>
> Correct me if I'm wrong, but history already tells you this - 
> it shows 
> the contacts tried and the response codes. In fact, it can tell you 
> about ambiguous behavior, where you parallel forked to two contacts 
> before trying the voicemail, and one gave you a 486 and the 
> other got a 
> no-answer time out. The voicemail server can even tell if the call 
> arrived because of an explicit redirect from one of the contacts and 
> play a "Bob really doesn't want to talk to you so don't bother trying 
> again because you'll just wind up right back here" greeting.
_______________________________________________
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: David R Oran <[email-masked]>
Date: Thu, 10 Feb 2005 15:25:51 -0500

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?

> The problem is that the two scenarios with the INVITE coming into the 
> VM service
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]