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

["Jeroen van Bemmel" <[e-mail]>]

Dean,

> On Wed, 2005-10-19 at 09:22 -0400, David R Oran wrote:
>
>> What we don't have a way of saying is "I'm busy, go try this other
>> place".
> . . .
>> 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.
>
> 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.
>

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



> 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
>
>
>
> _______________________________________________
> 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 


_______________________________________________
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