This seems to be the other solution. Could you give an example how this would look like?
What specification work would have to be done for this? BR, Martin > -----Ursprüngliche Nachricht----- > Von: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 18. April 2008 14:35 > An: Hülsemann, Martin > Cc: [email protected] > Betreff: Re: [BLISS] Call Waiting Indication > > Martin, > > While I haven't thought about this much, I think Alert-Info > is the most > appropriate solution. > > If the Alert-Info contained audio information it might interfere with > normal ringback, which you may not desire. But if it contains > non-audio > information (in fact, non-media information) then it > shouldn't interfere. > > I have recommended before that we establish a family of URNs for use > with Alert-Info. I think the same approach can be taken here. > For each > such URN there needs to be a standard definition of the semantics > associated with it. I would expect those semantics to include: > - a description of the *concept* to be conveyed > - *optionally* one or more media representations that may be > used to indicate this concept to the user. These could be > any media type (audio, video, text, etc.) or a combination. > > One of these with a concept but no representation would > simply mean that > the implementor just decide on its own representation. And in > any case > the implementor could choose pick its own representation of > the concept. > > Paul > > Huelsemann, Martin wrote: > > Dear colleagues, > > > > we've discussed about Call Waiting some time ago, but I > think we didn't really came to a conclusion at that time. So > I'm still looking for a solution how to inform a calling user > that the called user is already involved in a call. > > > > The background was and is, > > as the behaviour of the called user in the case of call > waiting is different from the situation the phone rings and > the user just answers the call (the time until the call is > answered will be longer in average, because the user realises > that a call is waiting, then he brings the call he is > involved in on hold or ends it, probably saying some words to > the other user, and only then he answers the waiting call), > in the PSTN there is an indication in the backward 'Ringing' > message, saying "call is a waiting call", defined in the > Generic Notification Indicator element in ITU-T recommendation Q.763. > > > > In some networks this leeds to a call waiting announcement > to the calling user. > > > > Anyway the calling user is informed that the time until the > call is answered might be a littlebit longer, and he will > wait a littlebit longer until he hangs up. > > On the other hand the called user knows the the calling > user has information about the call waiting situation, and > that gives him some more time to answer the waiting call. > > > > > > > > When we discussed this issue, I think the proposed > solutions were the following > > > > - usage of a 182 Queued response > > > > Con: it not sure the the 182 will cause a ringing tone at > the calling user > > > > > > - usage of an Alert-Info header > > > > Con: Alert-Info shoulf be used to provide Ringing tones, > possible conflict between providing a ringing tone and > rendering the information to the user > > > > > > - Usage of presence information <activities> > <on-the-phone/> </activities> > > > > Con: Presence is a subscription based service and it may > not be possible to interwork this information to other > Networks, esp. PSTN > > > > > > - I proposed (as usual) to use a P-header for this purpose, > as a possibility to interwork the Generic Notifiaction > Indicator element in general > > > > Con: another new P-header; possible interactions with the > event notification framework; > > > > > > > > So in my opinion the best solution would be an indication > in the 180 Ringing response. Something like the Alert-Info > header without the mentioned difficulties. > > > > > > In other discussions it was proposed to use the Call-Info > header for a similar purpose. This could perhaps be done by > using a special URI and defining a new CW specific purpose value. > > > > Another solution could be to re-use the presence XML schema > as defined in RFC 4480 with <activities> set to > <on-the-phone/> and include it in a MIME body in the 180. > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > _______________________________________________ > > BLISS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
