Yes, I obviously meant 182, not 181. Could you now evaluate a possibility to use 182+180?
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. 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
