Subject: [BLISS] CC suspend/resume issue

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 22 Feb 2008 16:14:02 +0100

> 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 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
> 
> 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.
> 	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-masked]
http://www.ietf.org/mailman/listinfo/bliss

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 22 Feb 2008 15:58:46 +0000

Denis,

Comments below.

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Alexeitsev, D
> Sent: 22 February 2008 15:14
> To: [email-masked]
> 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 
> 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: 
> 
[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 
>         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
> 
>         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)"

>         Disadvantage: Additional subscription, implicit 
> suspend-resume based on the CC agent state.  
> 
>