Subject: [BLISS] FW: Alert-Info URNs - impact on ACH

From: "Elwell, John" <[email-masked]>
Date: Tue, 09 Sep 2008 16:29:42 +0100

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-masked]'; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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-masked] [mailto:[email-masked]] 
> > Sent: 04 September 2008 17:31
> > To: [email-masked]
> > Cc: Elwell, John; [email-masked]; [email-masked]
> > Subject: RE: [BLISS] Alert-Info URNs
> > 
> > Hello Paul,
> > 
> > Please see inline:
> >  
> > 
> > -----Original Message-----
> > From: ext Paul Kyzivat [mailto:[email-masked]] 
> > Sent: 04 September, 2008 17:15
> > To: Mutikainen Jari (Nokia-D-MSW/Helsinki)
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > 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-masked] 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-masked]]
> > > Sent: 04 September, 2008 15:33
> > > To: Mutikainen Jari (Nokia-D-MSW/Helsinki); [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: [BLISS] Alert-Info URNs
> > > 
> > > 
> > >> -----Original Message-----
> > >> From: [email-masked] 
> [mailto:[email-masked]]
> > >> Sent: 04 September 2008 11:11
> > >> To: Elwell, John; [email-masked]
> > >> Cc: [email-masked]; [email-masked]
> > >> 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-masked]
https://www.ietf.org/mailman/listinfo/bliss