Subject: Re: [BLISS] Alert-Info URNs

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 2 Sep 2008 14:09:04 +0200

Hi

The new version of the Alert-Info URNs draft is available.

http://www.ietf.org/internet-drafts/draft-alexeitsev-bliss-alert-info-ur
ns-01.txt

* Some clean up based on the comments. 
* New validity description is proposed to describe if an indication is
valid without sub sections. 
* Minor section  to separate the top-level indications form
sub-indications 

Input on the 'tone' sub-indications is wanted.

I've found the list of the call progress tones used in North America. Is
this a complete list? Should some/all of the tones be added to the
draft? Should they be added as tones or as service/state indications?
 
Low tone
 
High tone
 
Dial tone
 
Audible ring tone
 
Line Busy Tone
   
Reorder
   
Alerting tone
   
Recorder warning tone
   
Reverting tone 
 
Deposit coin tone
   
Receiver off-hook (analog)
 
Receiver off-hook
 
Howler
 
No such number (crybaby)
   
Vacant code
   
Busy verification Tone (Centrex)
 
Busy verification Tone (TSPS)
 
Call waiting tone
 
Confirmation tone
 
Indication of camp-on
 
Recall dial tone
 
Data set answer back tone
 
Calling card prompt tone
 
Class of Service
   
Order tones: Single Double Triple Quad
   
Number checking tone
   
Coin denomination
 
3 5 cents
   
slot 10 cents
   
stations 25 cents
   
Coin collect tone
   
Coin return tone
   
Coin return test tone
   
Group busy tone
   
Vacant position
   
Dial off normal
   
Permanent signal
   
Warning tone
   
Service observing
   
Proceed to send Tone (IDDD)
 
Centralized intercept
 
ONI order tone

Greetings
Denis Alexeitsev
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: <[email-masked]>
Date: Tue, 2 Sep 2008 17:05:12 +0300

Hello,

In my understanding the Alert-Info has been specified for INVITE and 180
only. Quite many of the examples below do not make sense in INVITE or
180. In any case, to me it seems that the CW is the only real problem
what needs to be solved in this I-D, everything else seems to be
imaginary, is there really a need for a generic framework?

In addition, the I-D could describe why 181 is not sufficient solution.

BR,
Jari 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Alexeitsev, D
Sent: 02 September, 2008 15:09
To: [email-masked]
Subject: Re: [BLISS] Alert-Info URNs

Hi

 
Low tone
 
High tone
 
Dial tone
 
Audible ring tone
 
Line Busy Tone
   
Reorder
   
Alerting tone
   
Recorder warning tone
   
Reverting tone 
 
Deposit coin tone

Receiver off-hook
 
Howler
 
No such number (crybaby)
   
Vacant code

 
Call waiting tone
 
Confirmation tone
 
Indication of camp-on
 
Recall dial tone

Calling card prompt tone
 
Class of Service

Number checking tone
   
Coin denomination
 
3 5 cents
   
slot 10 cents
   
stations 25 cents
   
Coin collect tone
   
Coin return tone
   
Coin return test tone
   
Group busy tone
   
Vacant position
   
Dial off normal
   
Permanent signal
   
Warning tone
   
Service observing

Centralized intercept
 
ONI order tone

Greetings
Denis Alexeitsev

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 2 Sep 2008 16:25:54 +0200

Hi Jari

Comments inline 

Hello,

180. 

[DA] Could you point to the examples that make no sense?

In any case, to me it seems that the CW is the only real problem
what needs to be solved in this I-D, everything else seems to be
imaginary, is there really a need for a generic framework?

[DA] Do you have a proposal on how to solve the issues without having a
generic framework?

[DA] What use case do you have in mind that can be solved by using 181?

Greetings,
Denis Alexeitsev

---

From: <[email-masked]>
Date: Tue, 2 Sep 2008 17:51:57 +0300

Hello Denis,

Please see inline: 

-----Original Message-----
From: ext Alexeitsev, D [mailto:[email-masked]] 
Sent: 02 September, 2008 17:26
To: Mutikainen Jari (Nokia-D-MSW/Helsinki)
Cc: [email-masked]
Subject: AW: [BLISS] Alert-Info URNs

Hi Jari

Comments inline 

Hello,

[Jari] If I start from the top of the list, there are high tone and low
tone, which I have no idea what they are. Then the next one is dial
tone, so let's concentrate on this. Dial tone is a tone which is given
to the caller when he/she picks up the phone, before making any
dialling. By hearing the dial tone, the caller knows the "line is free".
This is implemented only in legacy fixed phones, e.g. mobile phones do
not have a dial tone. What meaning the sending of the dial tone could
have in INVITE or 180? Once the INVITE hits the callee, the playing of
the dial tone to the caller has been discontinued a long time ago. How
about 180, does it indicate that the dial tone should be played to the
caller in alerting phase?  

In any case, to me it seems that the CW is the only real problem what
needs to be solved in this I-D, everything else seems to be imaginary,
is there really a need for a generic framework?

[Jari] Yes, let's use 181+180, or if that is not sufficient for some
reason (which reason I would like to read from the I-D), 180 with
Alert-Info with a CW indication. 

[Jari] The CW use case: how to indicate to the caller that the callee is
alerting but busy with another call. I think this was the original
problem to be solved? 

BR,
Jari

Greetings,
Denis Alexeitsev

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Sep 2008 12:19:57 -0400

> alerting but busy with another call. I think this was the original

181 means "Call is being forwarded". What does that have to do with call 
waiting?

IMO the entire CW user experience carries much legacy baggage.

Its not at all clear to me that the caller needs to know anything about 
it, or that the callee necessarily wants the caller to know he is on 
another call. If so, there are many potential ways to make that known to 
the caller. The legacy way is with a special tone. More modern devices 
could find other ways to do it - perhaps graphical. But obviously when 
interoperating with a PSTN caller one needs to do something consistent 
with what the caller expects and can handle.

Sending *some* signal that indicates the call state seems desirable 
because it allows the calling end to render that as it wishes. 
Alert-Info with URNs is one way of encoding the semantic intent to 
inform the caller of the state without tying down how it is rendered. 
Then a GW can render it in the legacy way, and a more modern sip UAC can 
render it as it wishes.

Certainly there are other possible ways to signal this information. But 
I don't think 181 is one of those ways.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Tue, 2 Sep 2008 19:50:39 +0300

Yes, I obviously meant 182, not 181. Could you now evaluate a
possibility to use 182+180? 

I agree that the Alert-Info with some URN encoding is an alternative,
but I don't see a reason why this I-D should define other tones than CW.
The URN of course needs to be extensible, but there is no need to define
all possible tones for future use in this document.

BR,
Jari  

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: 02 September, 2008 19:20
To: Mutikainen Jari (Nokia-D-MSW/Helsinki)
Cc: [email-masked]; [email-masked]
Subject: Re: [BLISS] Alert-Info URNs

[email-masked] wrote:

> [Jari] The CW use case: how to indicate to the caller that the callee 
> is alerting but busy with another call. I think this was the original 
> problem to be solved?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Sep 2008 13:14:53 -0400

[email-masked] wrote:
> Yes, I obviously meant 182, not 181.

Hmm. Not *that* obvious. It didn't dawn on me you had that in mind.

> Could you now evaluate a

Well, AFAIK there is no agreed semantic for 182 - either exactly what it 
*means* to be queued without being answered, or what one might expect a 
UAC to do about it.

For instance, 182 might also be used with a call center. You might even 
get two-way early media and an IVR with a 182.

I do agree that it would be possible to enhance the definition of 182 in 
such a way that it would be appropriate for CW. (Define it as something 
like: your call is awaiting the availability of the recipient.) IMO the 
suitability of this depends on whether people are happy with the 
ambiguity of this. For this to interoperate with the PSTN, the GW will 
have to know when to generate the CW tones to the caller. Is that 
appropriate for all uses of 182?

> all possible tones for future use in this document.

I agree that defining the tones here is a stretch. Its entirely possible 
that they should be defined as distinct URNs, and maybe by different SDOs.

The "framework" was my original concept - primarily that URNs be used to 
convey either semantics or the "name" of some specific rendering rather 
than a specific encoding of that rendering. I see uses for both, but 
they aren't the "same" use. For instance they can be used for 
distinctive ring.

I guess the question is whether to establish a framework as part of the 
first use, or not. And in this case its how flexible to make the URN 
scheme, and the registration process for extending it. While there 
doesn't have to be just one kind of URN scheme for this, its probably 
best if every feature doesn't have to define a new URN scheme.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 03 Sep 2008 07:16:35 +0100

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: 02 September 2008 15:52
> To: [email-masked]
> Cc: [email-masked]

> alerting but busy with another call. I think this was the original
[JRE] What is the relevance of 181 (Call is Being Forwarded)? Perhaps
you meant 182 (Queued)?

John

---

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 3 Sep 2008 18:38:46 +0200

Hi Jari

See inline

[DA] The tones were just for information to see if there is any interest
in defining some. That is why I added them to the e-mail and not to the
draft.
I would like to hear more opinions on the tones issue. If there will be
no support for the tone definitions I can drop them entirely from the
draft.

[DA] I generally don't think that it is a good idea to overload the
semantic of the 182 to include the CW meaning. The cost of the urn
implementation is minimal and an explicit solution is more future proof
that an overloaded one. 

Let me ask the other way - what issues do you see with a urn?

Greetings,
Denis Alexeitsev

---

From: <[email-masked]>
Date: Thu, 4 Sep 2008 10:56:19 +0300

Hello Denis,

The problem with the URN is that we should define the semantics for the
URN structure, even if we don't define all possible values at this
point. This means we should know does the value indicate a tone,
call-state, or something else. Because the only realistic use case what
we can imagine at this point seems to be Call Waiting, it is impossible
to decide what structure the URN should use, in order to be usable also
in the future, if any extensions are required. If someone could come
with another use case that should be solved in this context, it would be
easier to decide the URN structure. Your attempt regarding the tones was
a good to that direction, but I think we should start from the use
cases. 

BR,
Jari 

-----Original Message-----
From: ext Alexeitsev, D [mailto:[email-masked]] 
Sent: 03 September, 2008 19:39
To: Mutikainen Jari (Nokia-D-MSW/Helsinki)
Cc: [email-masked]
Subject: AW: [BLISS] Alert-Info URNs

Hi Jari

See inline

Greetings,
Denis Alexeitsev

---

From: <[email-masked]>
Date: Thu, 4 Sep 2008 12:12:53 +0300

Hello Paul,

Regarding the use of 182: 
If there is early media in 18x message, the PSTN GW should not try to
play a tone itself, but connect the media path to the original media
source. In this way, the PSTN caller hears the original announcement
from the IVR. 3GPP TS 29.163 follows this logic, I assume the same
applies to other GWs too. 

So, the new logic in the GW would be, that if 182 is received without
the early-media, then the following 180 causes a CW indicator to ISUP
ACM. The existing logic ensures if there was early media in 182, then
the GW does not play the CW tone or announcement, but connects to the
original source. 

If some exisisng SIP IVR uses 182 for early-media prior to 180, the new
logic in GW does not break anything, the only issue seems to be that the
PSTN caller gets the CW notification (typically rendered as a beep tone
and graphical icon in the UI), although the use case was not really a
CW. 

As long as we cannot find another use case that would justify the URN, I
would suggest this approach. 

BR,
Jari

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: 02 September, 2008 20:15
To: Mutikainen Jari (Nokia-D-MSW/Helsinki)
Cc: [email-masked]; [email-masked]
Subject: Re: [BLISS] Alert-Info URNs

> The URN of course needs to be extensible, but there is no need to 
> define all possible tones for future use in this document.

I agree that defining the tones here is a stretch. Its entirely possible
that they should be defined as distinct URNs, and maybe by different
SDOs.

	Thanks,
	Paul

>> problem to be solved?
> 
> 181 means "Call is being forwarded". What does that have to do with 
> call waiting?
> 
> Its not at all clear to me that the caller needs to know anything 
> about it, or that the callee necessarily wants the caller to know he 
> is on another call. If so, there are many potential ways to make that 
> known to the caller. The legacy way is with a special tone. More 
> modern devices could find other ways to do it - perhaps graphical. But

> obviously when interoperating with a PSTN caller one needs to do 
> something consistent with what the caller expects and can handle.
> 
> Then a GW can render it in the legacy way, and a more modern sip UAC 
> can render it as it wishes.
> 
> Certainly there are other possible ways to signal this information. 
> But I don't think 181 is one of those ways.
> 
> 	Thanks,
> 	Paul
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 04 Sep 2008 10:29:37 +0100

> Sent: 04 September 2008 10:13
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> If there is early media in 18x message, 
[JRE] What is meant by "early media in the 18x message"? We normally use
the term early media to mean information received on the media path,
e.g., over RTP.

John

> the PSTN GW should not try to

---

From: <[email-masked]>
Date: Thu, 4 Sep 2008 13:10:32 +0300

Sorry to be unclear. I meant a scenario when the 18x includes the
P-Early-Media header as defined in RFC 5009. Of course this is not
necessarily always the case, then I assume the GW follows the logic in
RFC 3960, i.e:

1. Unless a 180 (Ringing) response is received, never generate
         local ringing.

      2. If a 180 (Ringing) has been received but there are no incoming
         media packets, generate local ringing.

      3. If a 180 (Ringing) has been received and there are incoming
         media packets, play them and do not generate local ringing.

         Note that a 180 (Ringing) response means that the callee is
         being alerted, and a UAS should send such a response if the
         callee is being alerted, regardless of the status of the early
         media session.

So in both cases 2 and 3 above, if the GW received 182 prior to 180, it
should generate a CW notification.

BR,
Jari

-----Original Message-----
From: ext Elwell, John [mailto:[email-masked]] 
Sent: 04 September, 2008 12:30
To: Mutikainen Jari (Nokia-D-MSW/Helsinki); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [BLISS] Alert-Info URNs

> Of [email-masked]

John

> If some exisisng SIP IVR uses 182 for early-media prior to 180, the 
> new logic in GW does not break anything, the only issue seems to be 
> that the PSTN caller gets the CW notification (typically rendered as a

> beep tone and graphical icon in the UI), although the use case was not

> really a CW.
> 
> As long as we cannot find another use case that would justify the URN,

> I would suggest this approach.
> 
> BR,
> Jari
> 
> *means* to be queued without being answered, or what one might expect 
> a UAC to do about it.
> 
> For instance, 182 might also be used with a call center. You might 
> even get two-way early media and an IVR with a 182.
> 
> I do agree that it would be possible to enhance the definition of 182 
> in such a way that it would be appropriate for CW. (Define it as 
> something

> I agree that defining the tones here is a stretch. Its entirely 
> possible that they should be defined as distinct URNs, and maybe by 
> different SDOs.
> 
> The "framework" was my original concept - primarily that URNs be used 
> to convey either semantics or the "name" of some specific rendering 
> rather than a specific encoding of that rendering. I see uses for 
> both, but they aren't the "same" use. For instance they can be used 
> for distinctive ring.
> 
> I guess the question is whether to establish a framework as part of 
> the first use, or not. And in this case its how flexible to make the 
> URN scheme, and the registration process for extending it. While there

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 04 Sep 2008 13:33:06 +0100

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 04 September 2008 11:11
> To: Elwell, John; [email-masked]
[JRE] But then we have no way of denoting a transition from call waiting
to alerting. I don't know whether that is a requirement, but it sounds a
reasonable requirement to me.

Nobody has clearly explained to me why 182 alone will not do. Then a 180
following the 182 would indicate a transition to alerting. It has been
claimed that 182 is typically used in a call centre environment where
the call is queued, but I don't really see how that differs in principle
from call waiting. The definition of 182 is:
"   The called party is temporarily unavailable, but the server has
   decided to queue the call rather than reject it."
Both call waiting and call centre queueing seem to fit that definition.
In both situations it is likely that the called user(s) will be given
some indication that there is a call (or calls) waiting. Also, if a tone
or other indication is to be given to the caller, I don't see why the
same indication wouldn't suit both situations.

John

---

From: <[email-masked]>
Date: Thu, 4 Sep 2008 16:03:12 +0300

Hello John,

In the current PSTN CW service, the CW is tied to the Alerting call
state, i.e. there is no need to be able to indicate the state change
from CW to Alerting. 

Regarding the question why 182 alone is not sufficient, I think this
originates from the assumption that 182 is used for some other purpose
somewhere, and this other purpose should not be seen as CW service in
PSTN. So if we tie 182 to 180, the probability that this combination is
used somewhere for some other purpose, should be smaller. I agree with
you, that 182 should be sufficient alone. But, in PSTN this is anyhow
converted to the same ALERTING message with CW indication, which means a
combination of 182 and 180. PSTN cannot send the CW without ALERTING,
thus in practice the GW must wait for the 180. This is at least my
understanding of the PSTN service.

BR,
Jari

-----Original Message-----
From: ext Elwell, John [mailto:[email-masked]] 
Sent: 04 September, 2008 15:33
To: Mutikainen Jari (Nokia-D-MSW/Helsinki); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [BLISS] Alert-Info URNs

> So in both cases 2 and 3 above, if the GW received 182 prior to 180, 
> it should generate a CW notification.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Sep 2008 10:14:36 -0400

This seems to be devolving into specifics of particular implementations.
If the signaling depends on that then I think there is a problem.

In particular, how does a CW call differ from a regular call? Does an 
implementation have two state transitions to be signaled independently 
by a 182 and a 180, or only one? And if two, does it matter in what 
order they occur? Or is the suggestion to signal one state transition 
with two responses?

If my UA is engaged in a call, and another call arrives, I assume the 
phone can alert me just as easily and quickly as if there was no other 
call. (The form of the alert may differ, but that seems irrelevant.) Why 
would that not be signaled immediately with a 180?

Its also likely that I can, if I wish, switch to the new call just as 
fast, or likely faster, than if I was not on the phone and had to dig 
the phone out of my bag or walk across the room to answer it. So I see 
no a-priori reason the caller should get some signal that this call will 
take longer to answer than some other call. That seems to be something 
that the phone developer may want to decide. In the pstn case it would 
seem that the decision has been made that the callee being on a call is 
important to signal immediately, but that is *its* decision, not a 
universal one. (And is likely motivated by the way CW was implemented at 
some point in the past.)

I *suppose* that if I don't answer the call promptly, the phone might 
want to signal that I am aware of the call but slow in responding. That 
could conceivably be via a 182 *after* the 180, or some other way. 
(Though 182 doesn't seem entirely appropriate in this case.)

IMO we are, at best, trying to signal nuances in UAS state to the 
caller. These nuances are likely to vary from implementation to 
implementation. Either we just put them in buckets by response code such 
as 180 and 182, or we put them in buckets such as Alert-Info URNs, or 
you give up and send something specific via early media. The Alert-Info 
has the advantage of being more expandable as different nuances are desired.

I don't think it is at all good to start interpreting various 
*sequences* of responses as having specific meanings. (180 and 182 have 
their own meanings alone, 182/180 means something else, 180/182 means 
something different. How about 180/182/180? 180/180?) Among other 
things, these responses are often sent unreliably, so they may not all 
be received.

I agree that the definition of a URN for Alert-Info makes little sense 
if only one value is to be used. But Bliss is taking features pretty 
much one-by-one. If this logic is used each time, then the general 
mechanism will never be chosen even though it might have made sense when 
viewed for the totality of features.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Thu, 4 Sep 2008 19:30:45 +0300

Hello Paul,

Please see inline:

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: 04 September, 2008 17:15
To: Mutikainen Jari (Nokia-D-MSW/Helsinki)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [BLISS] Alert-Info URNs

[Jari] Like I explained in the previous mail, in the PSTN service there
is only one state transition, with or without the CW indication.

[Jari] Yes, this is true. The only problem we are solving here in my
understanding, is how the caller is notified that you are engaged in
another call.  

Its also likely that I can, if I wish, switch to the new call just as
fast, or likely faster, than if I was not on the phone and had to dig
the phone out of my bag or walk across the room to answer it. 

[Jari] This is also true.

So I see no a-priori reason the caller should get some signal that this
call will take longer to answer than some other call. 

[Jari] Personally I see some value. The caller who believes his call is
impoertant, is willing to wait for a longer time, because he knows the
callee is present. The caller who believes his call is less important,
most likely drops the call immediately after the CW notification, and
either calls back later, or waits to be called back. I agree in SIP also
completely different means, e.g. Presence could be used, for the same
purpose. 

That seems to be something that the phone developer may want to decide. 

[Jari] This I don't understand. Obviously the developer always decides
what functions the phone implements. 

In the pstn case it would seem that the decision has been made that the
callee being on a call is important to signal immediately, but that is
*its* decision, not a universal one. (And is likely motivated by the way
CW was implemented at some point in the past.)

[Jari] Like I told, in PSTN service these conditions (alerting, cw) are
signaled at the same time. In SIP we can of course decide, whether this
needs to be the case, or if not, whether certain order needs to be
followed. 

[Jari] Hmm, if there is an RFC which says this condition must be
signaled in certain way, then the developed who wants to implement this
function, should follow the RFC. Of course, the developed may decide not
to implement the function at all, or implement it in some other way, but
then the implementation is not compliant with the RFC. I think this
applies no matter how we decide the CW should be signaled (182, 182+180,
180+182, Alert-Info, or something else).

implementation. 

[Jari] Please see above.

Either we just put them in buckets by response code such as 180 and 182,
or we put them in buckets such as Alert-Info URNs, or you give up and
send something specific via early media. The Alert-Info has the
advantage of being more expandable as different nuances are desired.

[Jari] Yes, I agree.

[Jari] 182 alone should be sufficient to signal the CW condition. But,
the PSTN GW still needs to wait for 180, due the fact how CW service was
designed in PSTN.

BR,
Jari

	Thanks,
	Paul

> PSTN. So if we tie 182 to 180, the probability that this combination 
> is used somewhere for some other purpose, should be smaller. I agree 
> with you, that 182 should be sufficient alone. But, in PSTN this is 
> anyhow converted to the same ALERTING message with CW indication, 
> which means a combination of 182 and 180. PSTN cannot send the CW 
> without ALERTING, thus in practice the GW must wait for the 180. This 
> is at least my understanding of the PSTN service.
> 
> BR,
> Jari
> 
> 
>  
> 
> [JRE] But then we have no way of denoting a transition from call 
> waiting to alerting. I don't know whether that is a requirement, but 
> it sounds a reasonable requirement to me.
> 
> Nobody has clearly explained to me why 182 alone will not do. Then a 
> 180 following the 182 would indicate a transition to alerting. It has 
> been claimed that 182 is typically used in a call centre environment 
> where the call is queued, but I don't really see how that differs in 
> principle from call waiting. The definition of 182 is:
> some indication that there is a call (or calls) waiting. Also, if a 
> tone or other indication is to be given to the caller, I don't see why

> the same indication wouldn't suit both situations.
> 
> John
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Sep 2008 13:05:25 -0400

Just commenting on one thing:

> the PSTN GW still needs to wait for 180, due the fact how CW service was

I don't understand what you are saying.

If the GW is *originating* the call, then it will get whatever it gets. 
There is no guarantee it will *ever* get a 180. It may get a 183 and 
then a 200, or a 182 and 200, or ...

Are you saying that the pstn phone, calling through a gw to a sip phone 
will only get the CW ringback if the sip phone sends both 182 and then 
180? If so, then I think that solution is broken.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Thu, 4 Sep 2008 20:21:11 +0300

Hello,

But this is already true for 180, the GW may never get it, as you told.
In this case, the GW does not generate ALERTING. If there is no 180 from
UAS, the UAS is not ringing, I suppose. And only if the UAS is ringing,
it makes sense to generate ALERTING at the GW. So I don't see what is
broken here? 

BR,
Jari

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: 04 September, 2008 20:05
To: Mutikainen Jari (Nokia-D-MSW/Helsinki)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [BLISS] Alert-Info URNs

> *sequences* of responses as having specific meanings. (180 and 182 
> have their own meanings alone, 182/180 means something else, 180/182 
> means something different. How about 180/182/180? 180/180?) Among 
> other things, these responses are often sent unreliably, so they may 
> not all be received.
> 

> the PSTN GW still needs to wait for 180, due the fact how CW service 
> was designed in PSTN.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 09 Sep 2008 16:31:00 +0100

Resending because appears to be missing from archive (last week's email
crash)

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 05 September 2008 14:25
> To: Elwell, John
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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