Hi Paul, the only problems seems to be, if you want to use Alert-Info to actually specify another ringback tone for download, independently from CW. Then you cannot do this in the 180 informing about Call Waiting with the CW alert urn.
Is there a possibility to define something like types or classes of ringtones and with this ot be able to send several ringtones in the same response? BR, Martin > -----Ursprüngliche Nachricht----- > Von: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 23. April 2008 01:08 > An: Hülsemann, Martin > Cc: [email protected] > Betreff: Re: AW: [BLISS] Call Waiting Indication > > > > Huelsemann, Martin wrote: > > This seems to be the other solution. > > > > Could you give an example how this would look like? > > Something like: > > SIP/2.0 180 Ringing > Alert-Info: urn:alert:on-the-phone > ... > > > What specification work would have to be done for this? > > I think it will be necessary to standardize another urn > namespace. (I've > called it "alert" above, but that is just a hypothetical example.) > > There ought to be an initial set of values within that namespace. I > picked "on-the-phone" as a possible example for this use case. > Presumably there wojuld be others. I suspect it would be best > introduce > at least one more level of hierarchy below "alert" to give some > sub-namespaces, together with a mechanism, template, and registry for > defining new values. > > I can see several different kinds of things that might be > named in this way: > - pure concepts like this one, not tied to any particular rendering > - names for standard tones, such as those used by the PSTN. > For instance there could be names for all the various > country-specific > ring tones and ringback tones. > - possibly names for things with specific renderings that aren't > purely audio. They might be static icons, video sequences, > whatever. > > But I think the purely semantic ones are the most > interesting, because > it signals the intent and allows the recipient to decide what > to render > to achieve that. However it does require some care in > precisely defining > what those semantics are. > > Some advantages of a URN rather than a net reference to a > downloadable > value are: > - you don't have to download it > - you don't have to worry if you support the format downloaded > - there is no "danger" that you might end up rendering something > unexpected and undesirable. > - you can render as high (or low) quality as your device can use > > The downside is that if you send such a URN to somebody and > they don't > understand it then they won't be able to render anything. > > Paul > > > 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
