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

["Francois Audet" <[e-mail]>]

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