Resending because appears to be missing from archive (last week's email crash)
> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 05 September 2008 14:25 > To: Elwell, John > Cc: [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED] > Subject: Re: [BLISS] Alert-Info URNs - impact on ACH > > > > Elwell, John wrote: > > Perhaps there is another perspective on this thread. An > indication of > > call waiting could be useful to the inbound proxy > performing automatic > > call handling (ACH, draft-ietf-bliss-ach-analysis) on behalf of the > > callee. For example, if ACH causes the call to be sent to voicemail > > after 15 seconds of alerting, say, there may be value in > not applying > > this rule to call waiting situations, or applying a longer > timeout. In > > this case the proxy would need to be aware of the call waiting > > condition. > > I agree that some automata handling would possibly be useful here. > But I think it would be better served by presence, which can convey a > much more nuanced state than a response code can. [JRE] True that it can convey a much more nuanced state. In the BLISS ACH work to date we have defined ways to indicate some basic states through response codes for ACH purposes. It is a question where we draw the line and say that for more complex cases you should use presence. > > The CW concept and user experience seems to be all tied up with voice > because voice is something that can't practically be > multiplexed at the > callee on a fine grained basis. If the call were for an IM > session the > situation would be quite a bit different, in that its likely > no problem > for the callee to handle more than one IM session > concurrently. But that > may vary based on the capabilities of the device. Add video > to the mix > and it gets more complex. > > So ultimately the question is: what is it that the callee is > trying to > communicate about its state? Is it: > - please play the "call waiting *tone*" > - please indicate to the caller *somehow* that I am in > "call-waiting state" (whatever that is) > - please indicate to the caller somehow that I am > aware of the call but can't answer for awhile > - please indicate to the caller that I am on another > voice call and might answer this one after I put that one > on hold > - please indicate that the *network* doesn't have the > resources to connect my call right now but has queued it > and will eventually put it through > - indicate that the callee is in session with somebody more > important than the caller, but will get to the caller later > - ... > > My take is that the most useful semantic would be: > - please indicate to the caller somehow that I am > aware of the call but can't answer for awhile > > And along with that it would be good to indicate support for presence > and allow a presence subscription so that the caller can get > more info > about the current state. That in turn could be used to refine what is > rendered to the caller. [JRE] But that won't help if the caller is PSTN. > > I also have a question about how this might typically work. > Suppose the > callee is on another call, but has put it on hold, and so > perhaps is not > listening. Then another call comes in. Should the new call get a CW > indication, given that the callee probably is *not* aware of > the caller? [JRE] This is very much up to the UI - I don't think we can give a definitive answer. > > > > Discrimination based on response code would certainly be > the easiest for > > ACH. You could have a rule that says "if response code x, > do y". It is > > more complex to say "if response code x plus Alert-Info URN > z, do y". > > > > Although the idea of a URN scheme seems attractive, if we > can't think of > > any other applications with which to populate the registry, > it seems to > > be overkill and an unnecessary complication for ACH. > > Distinctive ring is another good use case, selected either by > the caller > or by an agent for the callee. While in theory the caller or an agent > for the callee can already insert an Alert-Info with a URL that > references an audio file, its incredibly unsafe for the recipient to > play it, since it could be anything. Using URNs, its the semantics of > what to play that are being communicated. This can be ignored > if unknown > to the recipient. Also, an agent for the callee can filter the values > arriving from the caller, or insert values based on some configured > policy. And since these are conveyed semantically, the particular > rendering can be specific to the recipient - quality > appropriate for the > device, and even the media chosen according to the desires of the > recipient, such as a video rendering for a deaf user, or an > audio/video > rendering for an especially capable device. [JRE] My comments were related to service URNs, rather than tone URNs. John _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
