Subject: questions on cc-framework draft

From: Rohan Mahy <[email-masked]>
Date: Wed, 15 Mar 2000 11:10:51 -0800

Hi,

The cc-framework draft proposes a modular approach to adding features.  It 
concerns me that the framework proposes these modules, but doesn't name any 
except for the TRANSFER draft.  Lets say that one of the next features 
module to be addressed is conferencing.  Is CONFERENCE in this model a 
feature or a primitive?

In many models call monitoring is a feature which uses the conference 
primitive. In this framework what would it look like?

Would each module consist of a single draft?   If conference (for example) 
is a primitive, does the user of the primitive have to invoke the primitive 
differently based on the implementation (bridge, mesh, multicast)?

thanks,
-rohan

---

From: Ben Campbell <[email-masked]>
Date: Wed, 15 Mar 2000 14:05:14 -0600

> module to be addressed is conferencing.  Is CONFERENCE in this model a

That depends on design work that hasn't been done yet in this context.
Hypothetically speaking, suppose that the requirements of conferencing do
not require any additional protocol extensions (either of syntax or
semantics) beyond TRANSFER. Then we end up with a draft that says how to use
the TRANSFER extension to accomplish conferencing. It is not an extension
per se, but it is still a useful application in the context of call control.

I suspect we are putting to many connotations on the meaning of of the word
"module". Perhaps I could have chosen a better term. The point of the draft
was not to specify a module structure in advance, but to encourage an
open-ended series of specifications for various call control applications.

> primitive. In this framework what would it look like?

In this case, lets assume that conference requires a real extension, and
that monitoring can be accomplished using the conference syntax and
semantics exactly as specified.. Then we have an extension for conference,
and a description of how to use that extension to accomplish call
monitoring.

> differently based on the implementation (bridge, mesh, multicast)?

We did not intent to specifiy the draft structure of a module one way or
another. In the conference example, I would only expect a user to invoke it
differently if the aplication required syntactic or semantic changes. If
this is true, then another extension may be in order.

Hope this helps!

Ben Campbell.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 15 Mar 2000 12:53:47 -0800

Hi,

Thanks for the clarification.

So it sounds like the primary benefit of the TRANSFER method (over INVITE + 
Also) is to provide notification that the new INVITE succeeded.  Is that 
accurate?

thanks,
-rohan

---

From: Ben Campbell <[email-masked]>
Date: Wed, 15 Mar 2000 15:16:33 -0600

> Also) is to provide notification that the new INVITE succeeded.  Is that 

That is my understanding as well.

Thanks,

Ben.