Resending because appears to be missing from archive (last week's email crash)
> -----Original Message----- > From: Elwell, John > Sent: 05 September 2008 08:12 > To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] > Cc: [email protected]; [EMAIL PROTECTED] > Subject: RE: [BLISS] Alert-Info URNs - impact on ACH > > Perhaps there is another perspective on this thread. An > indication of call waiting could be useful to the inbound > proxy performing automatic call handling (ACH, > draft-ietf-bliss-ach-analysis) on behalf of the callee. For > example, if ACH causes the call to be sent to voicemail after > 15 seconds of alerting, say, there may be value in not > applying this rule to call waiting situations, or applying a > longer timeout. In this case the proxy would need to be aware > of the call waiting condition. > > Discrimination based on response code would certainly be the > easiest for ACH. You could have a rule that says "if response > code x, do y". It is more complex to say "if response code x > plus Alert-Info URN z, do y". > > Although the idea of a URN scheme seems attractive, if we > can't think of any other applications with which to populate > the registry, it seems to be overkill and an unnecessary > complication for ACH. > > John > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: 04 September 2008 17:31 > > To: [EMAIL PROTECTED] > > Cc: Elwell, John; [email protected]; [EMAIL PROTECTED] > > Subject: RE: [BLISS] Alert-Info URNs > > > > 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
