RE: [P2PSIP] Consensus calls

"Henry Sinnreich" <hsinnrei@adobe.com> Thu, 29 March 2007 17:45 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWyh8-0003p1-8E; Thu, 29 Mar 2007 13:45:54 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWyh7-0003ot-AJ for p2psip@ietf.org; Thu, 29 Mar 2007 13:45:53 -0400
Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HWyh3-0003Mx-6t for p2psip@ietf.org; Thu, 29 Mar 2007 13:45:53 -0400
Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Thu, 29 Mar 2007 10:45:25 PDT
Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l2THjFSd005421; Thu, 29 Mar 2007 10:45:15 -0700 (PDT)
Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l2THj212022947; Thu, 29 Mar 2007 10:45:15 -0700 (PDT)
Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 10:45:12 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [P2PSIP] Consensus calls
Date: Thu, 29 Mar 2007 10:44:57 -0700
Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF0D@namail5.corp.adobe.com>
In-Reply-To: <38A6D5A6-587D-4327-94B5-AB59CDB0E4A1@wimmreuter.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [P2PSIP] Consensus calls
Thread-Index: AcdyJBWuATwbIVnkQ3WH2/Uj+jA6yQABOcvQ
References: <4d4304a00703281250o750a5b8ah3a373458382d59fd@mail.gmail.com><095f01c7717f$2d0906a0$65500a0a@ronin> <4d4304a00703281430l7d428892wa76328489869ab6@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADEF9@namail5.corp.adobe.com> <38A6D5A6-587D-4327-94B5-AB59CDB0E4A1@wimmreuter.de>
From: Henry Sinnreich <hsinnrei@adobe.com>
To: Wilhelm Wimmreuter <wilhelm@wimmreuter.de>
X-OriginalArrivalTime: 29 Mar 2007 17:45:12.0814 (UTC) FILETIME=[00A1B8E0:01C7722A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07
Cc: P2PSIP Mailing List <p2psip@ietf.org>
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

> some form of what has been called an adaptor node

I agree with Willi's arguments and would like to add there are also some
very interesting mixed adaptor nodes possible, such as residential
gateways and set-top boxes that have (1) an adaptor for RJ-11 analog
phones and also (2) act as base the station for Wi-Fi connected mobile
devices.

The peer protocol for connecting the mobile devices must however be
designed with battery life in mind, while giving full access to all the
resources and routing modes of the P2P overlay (data interface, services
interface, join a multicast, do a name search, etc).

Thanks, Henry

-----Original Message-----
From: Wilhelm Wimmreuter [mailto:wilhelm@wimmreuter.de] 
Sent: Thursday, March 29, 2007 12:02 PM
To: Henry Sinnreich
Cc: David A. Bryan; Eric Cooper; P2PSIP Mailing List
Subject: Re: [P2PSIP] Consensus calls

Agree to 1) and 2) an had some thoughts about 3).

While understanding Henrys thoughts on a good
market penetration through 3), there are more
things to consider if we connect endpoints that
do not take part in the DHT ring.

- Peers in general must be part of the DHT ring.

- Their functions however can be quite polymorph

   I can see three major implementations for peers:

   + User Peers: Integrate P2P and the user interface
     e.g. P2P Phones or soft-clients
   + Service peers: Provide Services to other peers
     e.g.: Trust- , Database-, Directory-, Billing-
           Services etc.
   + Gateway Peers: Integrate the P2P endpoint and
     some mediation device to other network, service,
     and user/CPE entities.
     e.g. PSTN gateways, SS7 Gateways,
     h.323 Gateways (Henry, sorry for that),
     SIP- Network and User-Endpoint peers, ...

Considering hum 3), we will end up in the definition
of a gateway peer towards SIP phones. In fact, this
device must mediate things like:
  - Phone numbers to peer ID's
  - Peer presence to phone presence
  - Phone signaling peer equivalents
  - Routing functions as mentioned by Eric
    are another thing to handle.

Is this adaptor 3) not an ATA for P2P a SIP
endpoint gateway?

... I can see Fritz-, Linksys- and Intertex-boxes
that act as adaptor and interconnect to SIP phones
and well standard DECT or analog phones in
future.

By all that, I definitely agree on 3)!

Of course, we need to discuss if 3) shall become a

  - BCP for implementors of such adaptors/ATAs/gateways?
  or
  - Does 3) need a standards track RFC for mediation
    specific protocol stuff we need?

Willi







On 29.03.2007, at Do, 29. Mrz .07 00:57, Henry Sinnreich wrote:

>> Basically, some form of what has been called an adaptor node or
> proxy->peer. The question was simply "do we want to define this thing
> and make >sure we can support it".
>
> Yes. This will enable the use of most existing SIP UAs (phones, etc.),
> plus ATA-style adapters,
>
> Thanks, Henry
>
> -----Original Message-----
> From: David A. Bryan [mailto:dbryan@sipeerior.com]
> Sent: Wednesday, March 28, 2007 4:31 PM
> To: Eric Cooper
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] Consensus calls
>
> We tried in the call to avoid the client issue -- we are basically
> talking about "do we provide some mechanism by which a vanilla SIP
> client can get the routing information". Basically, some form of what
> has been called an adaptor node or proxy-peer. The question was simply
> "do we want to define this thing and make sure we can support it".
>
> David
>
> On 3/28/07, Eric Cooper <eric_d_cooper@sympatico.ca> wrote:
>> Agree with 1 & 2.
>>
>> Don't think I understand 3.  Does 'connect to the DHT' mean  
>> operate as
> a client (as per one of the 3 definitions of client in the concepts
> draft)?
>>
>> Eric.
>>
>> ----- Original Message -----
>> From: "David A. Bryan" <dbryan@sipeerior.com>
>> To: "P2PSIP Mailing List" <p2psip@ietf.org>
>> Sent: Wednesday, March 28, 2007 3:50 PM
>> Subject: [P2PSIP] Consensus calls
>>
>>
>>> There were a few hums taken at the meeting at IETF 68 in Prague, and
> I
>>> would like to ask the list their thoughts on these, so that we can
>>> truly say we have consensus on them and move on. Absence of comment
>>> for a few days will be assumed to be agreement with the (nearly 200)
>>> folks present.
>>>
>>> 1) With respect to draft-willis-p2psip-concepts-03, we took a hum
> and
>>> agreed to adopt it as a WG item and as a start toward the overview
>>> document mentioned in our charter. We further decided it will not be
>>> immediately submitted to the IESG, but rather evolve to document the
>>> decisions we make. That is, it will continue to reflect the
> consensus
>>> and outline as that evolves.
>>>
>>> 2) We took a hum and agreed to design the peer protocol in such a
> way
>>> that multiple DHTs could be used by the protocol, but only one at a
>>> time (not simultaneous use of more than one within a particular
>>> overlay). We further agreed we would have one or a very small number
>>> of must-implement DHTs, to be determined later, for compatibility.
> Hum
>>> was majority agreed, few dissent.
>>>
>>> 3) Took a hum that we should have some mechanism that allows an
>>> unmodified SIP UA to connect to a DHT using some sort of adaptor. We
>>> did not specify the protocols for it, how it would look etc -- just
>>> that we want to include this functionality. Positive response to the
>>> hum.
>>>
>>> Again, if any of this is something you disagree with, please
> discuss.
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> --
>>> David A. Bryan
>>> dbryan@SIPeerior.com
>>> +1.757.565.0101 x101
>>> +1.757.565.0088 (fax)
>>> www.SIPeerior.com
>>>
>>> _______________________________________________
>>> P2PSIP mailing list
>>> P2PSIP@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/p2psip
>>>
>>
>
>
> -- 
> David A. Bryan
> dbryan@SIPeerior.com
> +1.757.565.0101 x101
> +1.757.565.0088 (fax)
> www.SIPeerior.com
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>

---
Wilhelm Wimmreuter
mailto:wilhelm@wimmreuter.de
Tel.: +49 89 62500 70-3
Mob.: +49 151 121 64041



_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip