Subject: RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

From: "Francois Audet" <[email-masked]>
Date: Tue, 18 Oct 2005 16:22:48 -0500

Just to clarify what I was trying to say.

A 486 inside a 302 inside a History-Info is also what I was refering to.

I guess there are still some issues about Reason not being explicitely 
allowed in a response today (as John was pointing out).

Regardless, it is indeed sort of confusing, but not the first time we
come up with
something arcane and confusing :^) I'm not necessarily opposing to that,
although I do doubt that it will be practical (i.e., that it will work
in 
real life). It might be be interesting for an "1001 SIP hacks" book
however :^)

My issue was not that. 

My issue is when the endpoint is "faking" the 486 because there was
never any 
486 received. I think a GW (or B2BUA or SIP phone) sending a 302 with an
embedded
fake 486 just to make the other end believe (through History-Info or
not) that
it was Call Forward Busy is an abuse of the protocol.

If there is a 486 Reason in there, it should be because there was a 486
received.

Cheers.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Tuesday, October 18, 2005 13:01
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: sipping; Paul Kyzivat; Elwell,John; Michael Hammer (mhammer)
> Subject: Re: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> 
> 
> On Oct 17, 2005, at 5:47 PM, Francois Audet wrote:
> 
> > You mean adding a Reason of 486 inside 302????
> >
> > That seems highly confusing to me.
> 
> That's more or less what I think I proposed, except I buried it in a  
> History-Info header field.
> 
> One of the things that puzzles me about H-I is that while the RFC  
> allows use of H-I in 302 responses, it doesn't talk about it in any  
> great detail.
> 
> It would be very nice to have an H-I use-cases draft with some good  
> examples.
> 
> --
> Dean
> 
> 
> _______________________________________________
> 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
> 
> 

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Wed, 19 Oct 2005 00:02:12 -0500

> If there is a 486 Reason in there, it should be because there was a 486

Well, if I send you a 302 because I would have sent you a 486 if I
hadn't had an alternative (i.e. a call-forward because I was busy here)
is that faking? 

Can't I legimately file a "History-Info" saying I redirected you for a
reason? If so, what other reason would you suggest I use?

What if the 302 were being generated bya B2BUA instead of a terminal UA?

Or is History-Info just sort of broken when generated by a UA?

--Dean

---

From: David R Oran <[email-masked]>
Date: Wed, 19 Oct 2005 09:22:48 -0400

> hadn't had an alternative (i.e. a call-forward because I was busy  
Off the wall... (common for me)...
302 says "moved temporarily -please try this other contact, not me"
486 says "busy here" you'll have to figure out what if anything to do  
about this.

What we don't have a way of saying is "I'm busy, go try this other  
place".

One way to do that is to put a Reason header on the 302. That's more  
than a bit weird because it says you need more than the SIP response  
to tell you what's happening (Mary pointed this out in a message I  
just finished digesting).

Another way to do this is to allow a contact on a 486. That's also  
kind of weird.

A third way is to in fact invent a new 3xx which means exactly "Try  
this other place because I'm busy" (as opposed to moved temporarily).

Why don't we just do the last of these? It's completely  
straightforward to me.

Dave.

P.S. In terms of the debate over "telling you what happened so you  
can figure out what the right thing to do is" versus "telling the SIP  
infrastructure exactly what to do", I have consistently been in the  
former camp. In fact, that reasoning was one of the things that  
motivated both the Reason header and the History-Info work. I have a  
strong preference to avoid putting service directives into URIs  
except as a last resort, and only then when you know EXACTLY what you  
want a server to do and can ensure that the request in fact gets  
routed to that server.

---

From: Dean Willis <[email-masked]>
Date: Wed, 19 Oct 2005 10:11:26 -0500

> What we don't have a way of saying is "I'm busy, go try this other  
. . .
> Why don't we just do the last of these? It's completely  

At first glance, it sounds fine. But then people are going to want to
say "I'm busy to you because you're on my warn list, please try this
other contact " and "I'm busy because my QoS is saturated, please try
this other destination" and "I'm busy because I'm in a meeting, but I
could do text messaging too" and a million other things. We can't just
add a new response code for every one of these.

There are some fundamental problems with intertwingling applications
that use SIP with the SIP protocol itself, and I think that the path
you're suggesting leads to continuances of this layer violation model.

Of course, we could just accept that the application-protocol layer is
completely violated in the SIP model, and just make the best of what we
have. I suppose that is an alternative.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 19 Oct 2005 10:20:44 -0500

> want a server to do and can ensure that the request in fact gets  

Isn't that sort of like asking a web server to figure out which page you
want to see at by looking at your browser's history list? You must write
some interesting PHP-CGI scripts . . .

Seriously, this fundamental divide is much of what is causing muddling
in SIP. If we had "logic based on backward knowledge only", as Dave is
suggesting, then we'd have a relatively clean (but annoying to me)
model. If we had "logic based on forward knowledge only" (as per RFC
3087), then we'd have a relatively clean (but annoying to Dave) model.
As is, we have a complex model that's annoying everybody.

Once again, I'll note that web servers don't make decisions about which
web page to return based on HTTP-level information about which proxies
have previously seen a request and why they chose to pass it on.

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 19 Oct 2005 17:29:31 +0200

Dean,

> add a new response code for every one of these.

I agree here. Another thing to consider, is the intended consumer of this 
information: is it for the human user or for his super-duper intelligent 
softphone? The former would typically require a free-form String (as we 
already have in the reason phrase), the latter would need the response code. 
The error handling logic quickly becomes complex with more than a handful of 
response codes. My preference would be to use response codes for clearcut 
reasons ("busy"), and the human user (if any) for more complex sub-causes. 
Humans can do better reasoning even with incomplete information.

That being said, a redirect Contact with callee capabilities could be useful 
in a busy response. That is already possible using a 'Retry-After' header. 
The example in RFC3261 20.33 shows that the comment (was that deprecated 
now?) in this header was intended exactly for the kind of nuances you're 
describing

Regards,

jeroen