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