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 PROTECTED]
Sent: 04 September, 2008 12:30
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] On Behalf
> Of [EMAIL PROTECTED]
> Sent: 04 September 2008 10:13
> To: [EMAIL PROTECTED]
> Cc: [email protected]; [EMAIL PROTECTED]
> Subject: Re: [BLISS] Alert-Info URNs
>
> Hello Paul,
>
> Regarding the use of 182:
> 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
> 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 PROTECTED]
> Sent: 02 September, 2008 20:15
> To: Mutikainen Jari (Nokia-D-MSW/Helsinki)
> Cc: [EMAIL PROTECTED]; [email protected]
> Subject: Re: [BLISS] Alert-Info URNs
>
>
>
> [EMAIL PROTECTED] 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
> > possibility to use 182+180?
>
> 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?
>
> > 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.
>
> 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
>
> > BR,
> > Jari
> >
> >
> >
> >
> > -----Original Message-----
> > From: ext Paul Kyzivat [mailto:[EMAIL PROTECTED]
> > Sent: 02 September, 2008 19:20
> > To: Mutikainen Jari (Nokia-D-MSW/Helsinki)
> > Cc: [EMAIL PROTECTED]; [email protected]
> > Subject: Re: [BLISS] Alert-Info URNs
> >
> >
> >
> > [EMAIL PROTECTED] wrote:
> >
> >> In addition, the I-D could describe why 181 is not sufficient
> > solution.
> >> [DA] What use case do you have in mind that can be solved by using
> > 181?
> >> [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?
> >
> > 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
> >
> _______________________________________________
> BLISS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bliss
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
