RE: [Sip] RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt

"Roy, Radhika R, ALASO" <rrroy@att.com> Fri, 08 February 2002 19:58 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22452 for <sip-archive@odin.ietf.org>; Fri, 8 Feb 2002 14:58:02 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02260 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 14:58:04 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01363; Fri, 8 Feb 2002 14:38:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01334 for <sip@optimus.ietf.org>; Fri, 8 Feb 2002 14:38:02 -0500 (EST)
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21627 for <sip@ietf.org>; Fri, 8 Feb 2002 14:37:58 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g18JbRW26877 for <sip@ietf.org>; Fri, 8 Feb 2002 14:37:28 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029) id 3C62A10C00018150; Fri, 8 Feb 2002 14:37:02 -0500
content-class: urn:content-classes:message
Subject: RE: [Sip] RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt
Date: Fri, 08 Feb 2002 14:37:02 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F90154ED9A@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic: [Sip] RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGwypCosqNWcBy6EdaSygAAwCUaDwAC0hvg
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, "Yadavalli, Satyamurthy" <syadavalli@telogy.com>
Cc: Alan Johnston <alan.johnston@wcom.com>, Aymeric MOIZARD <aymeric.moizard@wellx.com>, sip@ietf.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA01335
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi, Jonathan and Satyamurthy:

I believe that Jonathan is right. SIP provides all the tools for service creation.

Jonathan's draft (draft-rosenberg-sip-3pcc-03.txt) provides an example how 3pcc services can be provided. This kind of the drafts when finalized will foster the interoperability (again, services are NOT standardized). Similar is the case with SIP services example and others.

Hope that Satyamurthy may look into Janathan's draft and may pose questions differently. That is, if there are questions related to the 3pcc draft, SIP services example, and others, we may like to discuss here.

Best regards,
Radhika R. Roy

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, February 08, 2002 12:51 PM
To: Yadavalli, Satyamurthy
Cc: 'Alan Johnston'; 'Aymeric MOIZARD'; sip@ietf.org;
sip-implementors@cs.columbia.edu
Subject: Re: [Sip] RE: [Sip-implementors]
draft-ietf-sip-service-examples-03.txt




"Yadavalli, Satyamurthy" wrote:
> 
> I keep hearing these terms 3pcc, B2BUA, and other approaches etc., and I
> wonder how different vendors of SIP components (UAs, proxy servers
> etc.,)
> will be able to realize  supplementary features (sip-service-examples)
> each
> independantly presuming an  approach for each feature.
> The same thing said differently: for a simple feature like call
> forwarding....should the UA do it or should the proxy do it. If there
> exists
> no specification how would different vendors interoperate to achieve the
> call control features across networks?

The SIP spec doesn't tell an operator what services to role out, where
to put them, and so on. The sip spec, and the rest of the
specifications, ensure that the proper SIP tools exist to make the
service work.

Let us take the case of forwarding. It can be done in a proxy in the
network, or in a UA. If a provider chooses not to do it, all that means
is that their service doesn't offer the feature. You can choose to get a
UA that does it, or not, and that would be a user's choice. If the
provider does implement it, the user can make use of that service, or
disable it, and then have it provided on their UA. In all cases, there
is no interop problems at all. 

-Jonathan R.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip