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

["Elwell, John" <[e-mail]>]

Francois, Paul,

I don't think this particular branch of this thread is going anywhere. The
history behind this (no pun intended) is that the redirection-reason draft
proposed the use of a Reason header within a 3xx response to indicate the
real reason (since it is forced to use an artificial 3xx response in order
to signal that it is redirecting). This isn't explicitly specified by RFC
3326, which states in section 1: "it can appear in any request within a
dialog, in any CANCEL request and in any response whose status code
explicitly allows the presence of this header field". Therefore it requires
an RFC explicitly to allow the Response header in a 3xx response. We don't
have it at present, but it could be achieved. The History-Info draft
anticipates this by making provision to make use of a Reason header in a 3xx
for populating the History-Info header.

However, one of the concerns with the redirection-reason draft was that it
required upgraded UACs in order for it to function as intended. This was one
of the main motivations for the proposal in the service-retargeting draft,
which captures relevant information in the URI to ensure automatic handling
at the UAC.

John


> -----Original Message-----
> From: Francois Audet [mailto:[e-mail]] 
> Sent: 18 October 2005 02:52
> To: Paul Kyzivat
> Cc: Michael Hammer (mhammer); sipping; Elwell, John
> Subject: RE: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> 486 is a response. In this particular example, it is a 
> response without
> a 
> corresponding request.
> 
> I don't know how more dubious it can be. I mean, sending "implied"
> responses
> to a request that never happened to me seems very dubious. Maybe it is
> just
> me...
> 
> Let's say we used Q.850, or even a new space for a response if it is
> less dubious.
> Or let's say everybody thinks that it is not dubious in the 
> first place.
> I am 
> willing to bet that it would be completely unimplementable with
> equipment today, 
> and in the near future (say, 5 years). I do not imagine that anybody
> would look 
> at some arcane ambigous Reason header embedded deeply with escape
> characters into 
> an OPTIONAL NEW History-Info header, and make routing 
> decisions based on
> it.
> 
> To me, shooting directly at the proper URI is always going to be
> less prone to errors than having the application look at 
> parameters that
> where not meant for routing, and that are almost never implemented...
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[e-mail]] 
> > Sent: Monday, October 17, 2005 17:08
> > To: Audet, Francois [SC100:9T51:EXCH]
> > Cc: Michael Hammer (mhammer); sipping; Elwell, John
> > Subject: Re: [Sipping] Re: 
> > draft-elwell-sipping-service-retargeting-00.txt
> > 
> > 
> > 
> > 
> > Francois Audet wrote:
> > > In the case where the far end actually sent a 486, it makes sense.
> > > 
> > > In the case where the far end did NOT send a 486, i.e., 
> > that forwards 
> > > the call itself with a 302, it seems highly dubious to me 
> > to insert a
> > > "fake" 486 inside a Reason header.
> > 
> > Doesn't seem so dubious to me. If I am a UA, and I return a 302 
> > *because* I am currently busy, then it makes sense to me to 
> include a 
> > 486 reason. I don't find anything in 3326 that says sip 
> > reason codes can 
> > only be used when a response containing that value was received.
> > 
> > It is however a matter of judgement to decide when any 
> > particular reason 
> > value should be used.
> > 
> > I guess the UA could instead choose to use a Q.850 reason 
> code, if it 
> > preferred.
> > 
> > The point is that we are not stuck with 302 as the reason 
> code when a 
> > 302 is returned. If something better is known, that can be 
> > expressed as 
> > a reason code, it can be returned. If nothing better is 
> > known, then we 
> > are out of luck in any case.
> > 
> > 	Paul
> > 
> > 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP