Subject: RE: [Sipping] Re: Update to 3pcc - corrected

From: "g.jayadevan \(Yahoo!\)" <[email-masked]>
Date: Sun, 3 Aug 2003 10:20:34 -0700 (PDT)

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 
architect solution in order to adhere to the 
principle when it does not buy me convenience
of deployment. Like others have pointed out
billing issues get confusing.

And the controller must be thought of as being an
end player too.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 04 Aug 2003 10:22:31 -0500

> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> g.jayadevan (Yahoo!)
> Sent: Sunday, August 03, 2003 12:21 PM
> To: [email-masked]
> Subject: RE: [Sipping] Re: Update to 3pcc - corrected
>

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 05 Aug 2003 18:37:32 +0200

>service layer that will allow me to reuse

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.

>applications loaded to perform these nifty 

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

>principle when it does not buy me convenience

As you might have read previously: REFER is more
convenient than b2bua -- so we don't need to open
a religious discussion about convenience versus
principles. To refresh your mind: there is fair
difference in complexity, interoperability and user 
experience.

>Like others have pointed out billing issues get confusing.

I still have not seen a problem description, so it is
hard to comment.

>And the controller must be thought of as being an

I have no opinion on this statement since I don't understand it.

-jiri