Session Initiation Proposal Investigation (sipping)

g.jayadevan (Yahoo! | 3 Aug 2003 19:20

RE: Re: Update to 3pcc - corrected

Here's my take the e2e vs. a centralized model.

When considering best practices, I prefer to think
in term of building blocks. The c-t-d is only one
application of the 3pcc model. If we took the
REFER approach, it becomes a point solution
applicable well only to a single 3pcc call.
The 3pcc model can be generalized to many
call legs allowing a whole class of application
that require these manipulations to be built. Should
we build efficient point solutions or a generalized
service layer that will allow me to reuse
capability?

Imagine from one customer service agent, I will
like to xfer the call to another. And possibly
add a supervisor. Seems to me that all the phones
at the call center will have to have intelligent
applications loaded to perform these nifty 
manipulations.

Reliability of the controller approach can be made
up in other ways. The controller itself can be 
made reliable by a distibuted protocols such as 
persisting call information, and adding protocol
fault tolerance via SCTP or a distributive proxy.
In the 3GPP world, a model borrowed from the
IN world, an application server is a key player.

e2e is a great concept, but I prefer not to

(Continue reading)

headers

Jiri Kuthan | 5 Aug 2003 18:37

RE: Re: Update to 3pcc - corrected

At 07:20 PM 8/3/2003, g.jayadevan \(Yahoo!\) wrote:
>Here's my take the e2e vs. a centralized model.
>
>When considering best practices, I prefer to think
>in term of building blocks. The c-t-d is only one
>application of the 3pcc model. If we took the
>REFER approach, it becomes a point solution
>applicable well only to a single 3pcc call.
>The 3pcc model can be generalized to many
>call legs allowing a whole class of application
>that require these manipulations to be built. Should
>we build efficient point solutions or a generalized
>service layer that will allow me to reuse
>capability?

If we should propose "BCP" tools for a generalized
service layer, than we need to make a case. I don't think
we make a case with an example which can be better solved
other way.

>Imagine from one customer service agent, I will
>like to xfer the call to another. And possibly
>add a supervisor. Seems to me that all the phones
>at the call center will have to have intelligent
>applications loaded to perform these nifty 
>manipulations.

Well, phones that don't support call transfer/REFER
should be better junked than used in architectural
discussions.

(Continue reading)

headers

Henry Sinnreich | 4 Aug 2003 17:22

RE: Re: Update to 3pcc - corrected


> e2e is a great concept, but I prefer not to
> architect solution in order to adhere to the
> principle when it does not buy me convenience
> of deployment.

Think of the example of one or more ISP's in the path of a call from an
enterprise local SIP outgoing proxy to a call center with complex services
at both ends that the ISP's need not necessarily understand. This is clearly
a case where only the e2e service model will work. Inserting a B2BUA in the
middle would break any usefulness to the caller and basically make the user
avoid the offending ISP.

Henry

> -----Original Message-----
> From: sipping-admin <at> ietf.org [mailto:sipping-admin <at> ietf.org] On Behalf Of
> g.jayadevan (Yahoo!)
> Sent: Sunday, August 03, 2003 12:21 PM
> To: sipping <at> ietf.org
> Subject: RE: [Sipping] Re: Update to 3pcc - corrected
> 
> Here's my take the e2e vs. a centralized model.
> 
> When considering best practices, I prefer to think
> in term of building blocks. The c-t-d is only one
> application of the 3pcc model. If we took the
> REFER approach, it becomes a point solution
> applicable well only to a single 3pcc call.
> The 3pcc model can be generalized to many

(Continue reading)