Re: [Sipping] RE: Comments on draft-johnston-sipping-p2p-ipcom-01.txt

Xiaotao Wu <xiaotaow@cs.columbia.edu> Tue, 29 March 2005 16:03 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13538 for <sipping-web-archive@ietf.org>; Tue, 29 Mar 2005 11:03:31 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGJIU-0001XA-NJ for sipping-web-archive@ietf.org; Tue, 29 Mar 2005 11:10:31 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGJ6r-0003aa-7K; Tue, 29 Mar 2005 10:58:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGJ6p-0003aQ-9X for sipping@megatron.ietf.org; Tue, 29 Mar 2005 10:58:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11988 for <sipping@ietf.org>; Tue, 29 Mar 2005 10:58:25 -0500 (EST)
Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGJDU-00012L-SO for sipping@ietf.org; Tue, 29 Mar 2005 11:05:22 -0500
Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2TFwIqt018066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Mar 2005 10:58:19 -0500 (EST)
Received: from flame.cs.columbia.edu (localhost [127.0.0.1]) by flame.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2TFwIXT027544; Tue, 29 Mar 2005 10:58:18 -0500 (EST)
Received: from localhost (xiaotaow@localhost) by flame.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id j2TFwHbH027539; Tue, 29 Mar 2005 10:58:17 -0500 (EST)
X-Authentication-Warning: flame.cs.columbia.edu: xiaotaow owned process doing -bs
Date: Tue, 29 Mar 2005 10:58:17 -0500
From: Xiaotao Wu <xiaotaow@cs.columbia.edu>
To: Arjun Roychowdhury <arjunrc@gmail.com>
Subject: Re: [Sipping] RE: Comments on draft-johnston-sipping-p2p-ipcom-01.txt
In-Reply-To: <a9994e940503290705310dee7a@mail.gmail.com>
Message-ID: <Pine.GSO.4.58.0503291043040.19328@flame.cs.columbia.edu>
References: <40AF35183B110B4899DD3221904B6B58F4BD49@usashms001.mcilink.com> <a9994e940503290705310dee7a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: "Johnston, Alan" <alan.johnston@mci.com>, sipping <sipping@ietf.org>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

> > >     return more than just a simple Contact URI. In a pure Peer-to-peer
> > >     SIP network, if the user's phone is not reachable (e.g., it is a
> > >     wireless phone that is out of range), then we would still like
> > >     the call to follow the user's call handling preferences.
> > > This might
> > >     involve taking voicemail for the user, or forwarding the call to
> > >     another AoR. The user might have expressed these call handling
> > >     preferences by uploading a CPL script to the "network" somehow
> > >     beforehand.
> >
> > Yes - these are important requirements that we will want to meet with
> > this protocol.
>
> Why is this an important requirement ? If the goal of this draft is
> pure p2p, then there is no intelligent network inbetween that needs to
> be relied on from a service perspective. If CPL needs to be invoked,
> it would be a part of the User Agent either originating or terminating
> a call and not some node in between.

I agree with Arjun's point. In a P2P network, you cannot put your
service scripts in the network due to both reliability and privacy
concerns. If you want it to be reliable, you must have your scripts
distributed to all potential routing nodes, which you never know whether
they are trustable or untrustable, and the privacy will be a big concern.

There could be some exceptions, such as spam filtering, a user may like to
push it into the network so he does not have to keep a copy for all his
devices. But, keeping service script copies on every device and
synchronize the copies would not be a big problem in a P2P network.

For services on endpoints, we have extended CPL to the Language for End
System Services (LESS), which can be found at

http://www.ietf.org/internet-drafts/draft-wu-iptel-less-00.txt

The new language removes the 'proxy' action in CPL since you would not
expect your endpoints to proxy calls. The language will just fit the P2P
environment for services.

Thanks!

-Xiaotao

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

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