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