[EMAIL PROTECTED] wrote:
> Yes, I obviously meant 182, not 181.
Hmm. Not *that* obvious. It didn't dawn on me you had that in mind.
> Could you now evaluate a
> possibility to use 182+180?
Well, AFAIK there is no agreed semantic for 182 - either exactly what it
*means* to be queued without being answered, or what one might expect a
UAC to do about it.
For instance, 182 might also be used with a call center. You might even
get two-way early media and an IVR with a 182.
I do agree that it would be possible to enhance the definition of 182 in
such a way that it would be appropriate for CW. (Define it as something
like: your call is awaiting the availability of the recipient.) IMO the
suitability of this depends on whether people are happy with the
ambiguity of this. For this to interoperate with the PSTN, the GW will
have to know when to generate the CW tones to the caller. Is that
appropriate for all uses of 182?
> I agree that the Alert-Info with some URN encoding is an alternative,
> but I don't see a reason why this I-D should define other tones than CW.
> The URN of course needs to be extensible, but there is no need to define
> all possible tones for future use in this document.
I agree that defining the tones here is a stretch. Its entirely possible
that they should be defined as distinct URNs, and maybe by different SDOs.
The "framework" was my original concept - primarily that URNs be used to
convey either semantics or the "name" of some specific rendering rather
than a specific encoding of that rendering. I see uses for both, but
they aren't the "same" use. For instance they can be used for
distinctive ring.
I guess the question is whether to establish a framework as part of the
first use, or not. And in this case its how flexible to make the URN
scheme, and the registration process for extending it. While there
doesn't have to be just one kind of URN scheme for this, its probably
best if every feature doesn't have to define a new URN scheme.
Thanks,
Paul
> BR,
> Jari
>
>
>
>
> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: 02 September, 2008 19:20
> To: Mutikainen Jari (Nokia-D-MSW/Helsinki)
> Cc: [EMAIL PROTECTED]; [email protected]
> Subject: Re: [BLISS] Alert-Info URNs
>
>
>
> [EMAIL PROTECTED] wrote:
>
>> In addition, the I-D could describe why 181 is not sufficient
> solution.
>> [DA] What use case do you have in mind that can be solved by using
> 181?
>> [Jari] The CW use case: how to indicate to the caller that the callee
>> is alerting but busy with another call. I think this was the original
>> problem to be solved?
>
> 181 means "Call is being forwarded". What does that have to do with call
> waiting?
>
> IMO the entire CW user experience carries much legacy baggage.
>
> Its not at all clear to me that the caller needs to know anything about
> it, or that the callee necessarily wants the caller to know he is on
> another call. If so, there are many potential ways to make that known to
> the caller. The legacy way is with a special tone. More modern devices
> could find other ways to do it - perhaps graphical. But obviously when
> interoperating with a PSTN caller one needs to do something consistent
> with what the caller expects and can handle.
>
> Sending *some* signal that indicates the call state seems desirable
> because it allows the calling end to render that as it wishes.
> Alert-Info with URNs is one way of encoding the semantic intent to
> inform the caller of the state without tying down how it is rendered.
> Then a GW can render it in the legacy way, and a more modern sip UAC can
> render it as it wishes.
>
> Certainly there are other possible ways to signal this information. But
> I don't think 181 is one of those ways.
>
> Thanks,
> Paul
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
