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
[EMAIL PROTECTED] wrote:
> 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 PROTECTED]
> Sent: 04 September, 2008 15:33
> To: Mutikainen Jari (Nokia-D-MSW/Helsinki); [EMAIL PROTECTED]
> Cc: [email protected]; [EMAIL PROTECTED]
> Subject: RE: [BLISS] Alert-Info URNs
>
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> Sent: 04 September 2008 11:11
>> To: Elwell, John; [EMAIL PROTECTED]
>> Cc: [email protected]; [EMAIL PROTECTED]
>> Subject: RE: [BLISS] Alert-Info URNs
>>
>> 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.
> [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
>
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
