Denis, Comments below.
John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Alexeitsev, D > Sent: 22 February 2008 15:14 > To: [email protected] > Subject: [BLISS] CC suspend/resume issue > > Hi > > I've summarised the suspend-resume discussion by describing > the problem and listing the known solutions. Please comment > if I left some solutions undescribed and if the pros and cons > are fairly described. > > > > General requirement: > > If the CC agent is busy on the receipt of the ready for > recall notification [JRE] Does it necessarily need to wait for receipt of recall notification? Would there be any advantage in suspending as soon as the CC agent goes busy? > it shall suspend the CC monitoring of the > callee. The CC agent shall resume the callee monitoring once > it becomes free. On the receipt of the suspension from the > top CC agent in the queue, the CC monitor shall perform the > callee monitoring for the next active CC agent in the queue. > On the receipt of the resume from the previously suspended > top CC agent in the queue the CC monitor shall perform the > callee monitoring for this top CC agent. > > General Architecture: > > There are two modes of transporting the suspend-resume > information from the CC agent to the CC monitor - push and > pull. In the push mode the CC agent actively changes (pushes) > the state of the queue at the CC monitor. In the pull mode > the CC monitor collects information (pulls) about the CC > agent and changes the state of the queue based on that information. > > Solutions: > > - Push solutions: > > A) Implicit change of the queue state at the CC monitor by > un-subscribing and re-subscribing to the CC service. > Advantage: easy to implement > Disadvantage: no explicit suspend-resume operation [JRE] This is rather intangible. What would the consequences be? If no real consequences, this method would appear to have no disadvantages. Or are there disadvantages concerning place in queue, timeouts, etc.? > > B) Explicit change of the queue state using notify=off" > mechanism proposed in draft-vakil-sipping-notify-pause > Advantage: explicit operation > Disadvantage: the "notify" parameter specifies > whether notifications should be generated, which is > independent of what their content is. change of > the state by the SUBSCRIBE method > > C) Use of a new Event header parameter like available=no/yes > Advantage: explicit operation > Disadvantage: change of the state by the SUBSCRIBE method > > D) Use of XCAP to change the queue state > Advantage: explicit operation, in line with > presence architecture > Disadvantage: introduction of the a new protocol > (http) complicates the solution and interworking > > - Pull solution: > > C) The CC monitor makes a reverse dialog-info subscription > over the same CC dialog to the CC agent. The CC monitoring is > suspended if the CC agent is in the busy at the ready for > recall moment. The CC monitoring is resumed once the CC agent > becomes free. [JRE] Presumably this should be "E)" > > Advantage: automated process, similar to KPML > Disadvantage: Additional subscription, implicit > suspend-resume based on the CC agent state. > > > Comments, suggestions are very welcomed. > > Greetings, > Denis Alexeitsev > > _______________________________________________ BLISS mailing list [email protected] http://www.ietf.org/mailman/listinfo/bliss
