Subject: [BLISS] Call Waiting Indication

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 18 Apr 2008 12:49:28 +0200

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-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: <[email-masked]>
Date: Fri, 18 Apr 2008 13:55:38 +0300

Hello,

What would be the problem in sending both 182 and 180?

BR,
Jari 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Huelsemann, Martin
Sent: 18 April, 2008 13:49
To: [email-masked]
Subject: [BLISS] Call Waiting Indication

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

  Con: it not sure the the 182 will cause a ringing tone at the calling
user

  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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Apr 2008 08:34:47 -0400

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

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Mon, 21 Apr 2008 16:37:19 +0200

Hi, the problem is that in case of an interworking to the PSTN the mapping is not symmetrical. This is especially a problem if you think of a scenario where a Internet call to the PSTN is forwarded in the PSTN to back the Internet. When forwarding the PSTN generates an ACM indicating Call Forwarding, which will be mapped into a 181. 
The 180 generated by the destination in the internet will be mapped into an ACM, which will be mappep by the forwarding instance in the PSTN into a CPG indication allerting (because the ACM was already sent). The CPG will be mapped into a 180 back to the Internet. 
The 182 generated by the destination in the internet will be mapped into a CPG indicating Call Waitng, which at this point of the call would also be mapped into a 180, in this case followed by the 182. So there would be two 180 Ringing responses on the origination Internet side, which could cause problems.

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Gesendet: Freitag, 18. April 2008 12:56
> An: Hülsemann, Martin; [email-masked]
> Betreff: RE: [BLISS] Call Waiting Indication
> 
> Hello,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Apr 2008 11:46:08 -0400

Why should two 180 responses ever be a problem? (Assuming they carry the 
same answer.)

That is entirely legal, and may in fact be the most appropriate way to 
keep the transaction from timing out if the alerting goes on for a long 
time.

I certainly hope no UAS is going to choke on this.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Apr 2008 12:11:10 -0400

> Why should two 180 responses ever be a problem? (Assuming they carry the 

The above is a little sloppy. TO restate:

Why should two 180 responses ever be a problem so long as they conform 
to correct offer/answer and dialog usage?

(If reliable provisional responses are *not* being used, then those in 
the same dialog that contain answers must contain the same answer.)

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 22 Apr 2008 17:00:58 +0200

But it seems that some preconditions should be fulfilled in context with the 'adding a 182' solution, which could cause problems to very simple UAs or gateways. So if there is another solution which avoids this difficulties I think we should choose this other solution.

BR, Martin

> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Montag, 21. April 2008 18:11
> An: Hülsemann, Martin
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [BLISS] Call Waiting Indication
> 
> 
> 
> Paul Kyzivat wrote:
> >> Hi, the problem is that in case of an interworking to the 
> PSTN the mapping is not symmetrical. This is especially a 
> problem if you think of a scenario where a Internet call to 
> the PSTN is forwarded in the PSTN to back the Internet. When 
> forwarding the PSTN generates an ACM indicating Call 
> Forwarding, which will be mapped into a 181. 
> >> The 180 generated by the destination in the internet will 
> be mapped into an ACM, which will be mappep by the forwarding 
> instance in the PSTN into a CPG indication allerting (because 
> the ACM was already sent). The CPG will be mapped into a 180 
> back to the Internet. 
> >> The 182 generated by the destination in the internet will 
> be mapped into a CPG indicating Call Waitng, which at this 
> point of the call would also be mapped into a 180, in this 
> case followed by the 182. So there would be two 180 Ringing 
> responses on the origination Internet side, which could cause 
> problems.
> >>
> >>
> >> BR, Martin
> >>
> >>
> >>
> >>
> >>> From: [email-masked] 
> [mailto:[email-masked]] On Behalf

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 22 Apr 2008 17:02:34 +0200

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

> Gesendet: Freitag, 18. April 2008 14:35
> An: Hülsemann, Martin
> Cc: [email-masked]
> > 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.
> > 
> > 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. 
> > 
> > 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.
> > 
> > 
> > 
> >   Con: Alert-Info shoulf be used to provide Ringing tones, 
> possible conflict between providing a ringing tone and 
> rendering the information to the user
> > 
> > 
> >   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
> > 
> > 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
> > 
> > 
> > 
> > 
> > 
> > 
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Apr 2008 18:46:55 -0400

I wasn't trying to suggest that 180 and/or 182 is the best way to hand 
the call waiting indication. I was only reacting to the suggestion that 
there might be something wrong with returning multiple 180 responses.

	Paul

Huelsemann, Martin wrote:
>>>>> in the PSTN
>> in the 180
>> header for a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Apr 2008 19:07:33 -0400

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Apr 2008 19:18:15 -0400

BTW - I have seen something similar done in a lame, poor-man's way using 
the file: URL. E.g.

	Alert-Info: file:on-the-phone

Where I have seen this there was no real expectation that the recipient 
had a file system with a file of the specified name. And in fact the 
above doesn't even conform to the syntax of the file URL. It was clearly 
being used as an ad hoc sort of URN.

	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 24 Apr 2008 17:33:01 +0200

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

> Gesendet: Mittwoch, 23. April 2008 01:08
> An: Hülsemann, Martin
> Cc: [email-masked]
> Betreff: Re: AW: [BLISS] Call Waiting Indication
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Apr 2008 11:49:03 -0400

> 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 W…

I don't understand. Wouldn't you be choosing to send the call-waiting 
alert-info as an *alternative* to either the default ringback or some 
other alert-info you might otherwise send?

> 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? 

alert-info has no "purpose" like call-info. But it does allow multiple 
URIs. If there is more than one, then I expect the UAC may choose, and 
if they are such that they don't conflict with one another then it could 
choose to render more than one. (E.g. if one has an audio rendering and 
another has a video rendering.)

	Paul