Subject: [BLISS] CC suspend/resume issue

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 22 Feb 2008 16:10:00 +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]
https://www.ietf.org/mailman/listinfo/bliss

---

From: [email-masked]
Date: Tue, 11 Mar 2008 09:05:14 -0500

From: "Elwell, John" <[email-masked]>

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

I think we would get better performance if the agent suspended
immediately when the caller became not-available.  The cost would be
that the agents would do more suspend/resume operations.  IIRC, SS7
also has the caller suspend its CC request immediately upon becoming
busy.

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

I think the disadvantage is better phrased "no separate suspend-resume
operation", which implies the disadvantages you mention:  caller does
not maintain its place in the queue, timeouts become difficult to
implement.

Dale