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