RE: [P2PSIP] Consensus calls

>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