Hello Paul, Please see inline:
-----Original Message----- From: ext Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: 04 September, 2008 17:15 To: Mutikainen Jari (Nokia-D-MSW/Helsinki) Cc: [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED] Subject: Re: [BLISS] Alert-Info URNs 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? [Jari] Like I explained in the previous mail, in the PSTN service there is only one state transition, with or without the CW indication. 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? [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. 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.) [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). 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. [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. 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. [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 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
