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
