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