Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to think?

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 10:48:43 -0400

One of the things I think we blew big time on sip was that we didn't require
some fundamental things in every sip device to differentiate them from
existing technology.  We have an opportunity to fix that with p2psip, and I
think we should do it.

Now, admittedly, what I'm talking about is somewhat a "marketing" issue, but
it's a very real thing that we could do which I believe would be helpful.

So, I propose:
1. We do not support any form of insecure signaling.  We define the protocol
to reject attempts to signal without TLS (or whatever).  I'm assuming the
protocols are TCP only.  The overlay defines what credentials are needed
(and supplies them).

2. We do not support any form of insecure media.  It's always encrypted.
This is the tough one, especially if we say we support SIP UAs.

3. All devices that support audio support wideband audio.  

4. All devices support text (IM and real time interactive).

5. All devices support presence.  We define a minimal set of presence
characteristics that all devices publish.

6. We define a minimal feature set (something like unattended and attended
transfer, call forward no answer, call forward busy, basic conferencing,
...) that every device supports the same way.

7. All devices work behind a given set of NAT configurations, given a
specified set of ICE components (or whatever).

8. We define what constitutes a minimal configuration set; all of the above
just work with this level of configuration (and credentials from an
overlay).  We of course define the configuration mechanism.  I'm thinking
that we do this by configuring the device with the credentials, and using
the overlay to provide any other configuration (which could be influenced
by, say, a website the overlay runs) automatically.

All of these are designed to be minimum capabilities, but the idea is that
ANY device, with credentials on an overlay, can expect to communicate with
any other device on that overlay with ALL of the above.

Finally, I propose we invent a phrase, something like "p2psip conformant"
which means a device that does that.  No protocol police, but the idea is
that if you say you have a "p2psip conformant" device, it means all of the
above.  Perhaps we have a way to signal that.

This is pretty much what Skype does.  Why should we not do that, at least?

Brian

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 4 Apr 2007 08:14:10 -0700

These are good points and actually should copied to the SIPPING list
since they apply to the simple SIP Toolkit :-)

>...) that every device supports the same way.

Let's first look how presence and IM may affect user behavior and if
this cannot be a special endpoint app, say for receptionists or agents.

> This is pretty much what Skype does 

I am using Skype now for several years for most long distance calls and
for conferences, but have never transferred a call. May be my secretary
would transfer a call, but I don't have one :-)
Nor do 99.99% of consumers or most employees any more. One can IM the
number...

Thanks, Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 9:49 AM
To: 'P2PSIP Mailing List'
Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to
think?

One of the things I think we blew big time on sip was that we didn't
require
some fundamental things in every sip device to differentiate them from
existing technology.  We have an opportunity to fix that with p2psip,
and I
think we should do it.

Now, admittedly, what I'm talking about is somewhat a "marketing" issue,
but
it's a very real thing that we could do which I believe would be
helpful.

So, I propose:
1. We do not support any form of insecure signaling.  We define the
protocol
to reject attempts to signal without TLS (or whatever).  I'm assuming
the
protocols are TCP only.  The overlay defines what credentials are needed
(and supplies them).

6. We define a minimal feature set (something like unattended and
attended
transfer, call forward no answer, call forward busy, basic conferencing,
...) that every device supports the same way.

8. We define what constitutes a minimal configuration set; all of the
above
just work with this level of configuration (and credentials from an
overlay).  We of course define the configuration mechanism.  I'm
thinking
that we do this by configuring the device with the credentials, and
using
the overlay to provide any other configuration (which could be
influenced
by, say, a website the overlay runs) automatically.

All of these are designed to be minimum capabilities, but the idea is
that
ANY device, with credentials on an overlay, can expect to communicate
with
any other device on that overlay with ALL of the above.

Finally, I propose we invent a phrase, something like "p2psip
conformant"
which means a device that does that.  No protocol police, but the idea
is
that if you say you have a "p2psip conformant" device, it means all of
the
above.  Perhaps we have a way to signal that.

This is pretty much what Skype does.  Why should we not do that, at
least?

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 11:25:08 -0400

I REALLY wish I could transfer a call from Skype to my mobile and vice
versa.

I wish I could transfer it to my hardline when, for whatever reason, the
bandwidth gods are not smiling on me.

And then there is conferencing.  Depending on exactly how conferencing is
implemented, you may need to transfer to a bridge.

I really think transfer is an absolute minimal requirement.

I do think that a rich presence system might obviate the Call forward
issues.  I've never seen it done, so I've never been able to try, but I
could see how it might.

Conferencing is something that just has to work.

We need to go down the list of service examples and decide which ones are
MUST HAVE.  

Brian

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2007 11:14 AM
> To: Brian Rosen; P2PSIP Mailing List
> Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to
> think?
>

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 4 Apr 2007 11:30:26 -0400

Tend to agree with most of this, but we also need to keep in mind
non-telephony P2PSIP applications (say IPTV, voice add-on to gaming
etc.) and make sure we don't write things in such a way these
capabilities are required for these services as well.

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 11:35:05 -0400

Sure.  We can define these as "telephony devices".

Some, of course (like signaling and media security) might apply across the
board.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf Of David
> A. Bryan
> Sent: Wednesday, April 04, 2007 11:30 AM
> To: Brian Rosen
> Cc: Henry Sinnreich; P2PSIP Mailing List
> Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to
> think?
>

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 04 Apr 2007 17:42:36 +0200

> protocols are TCP only.  The overlay defines what credentials are needed

We haven't chosen the transport for the peer protocol, have we?  As far
as I remember, during the last meeting we deferred the issue...

-- 
Ciao,
Enrico

Ahem.. Sorry, the notice below is not my fault :-(
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 4 Apr 2007 11:43:56 -0400

> protocols are TCP only.  The overlay defines what credentials are needed

Requiring securing the protocol seems like a good goal.  We need to
have a scheme that secures ad-hoc networks and one that works with
NATs, so TLS over TCP certainly can't be our only option.

> ...) that every device supports the same way.

All of these assume a particular type of device that I don't think we
can (or should) assume for P2PSIP.  Where we get into the particular
calling features for telephony devices, hopefully we can just point at
BLISS.

> specified set of ICE components (or whatever).

agreed, although defining the exact configurations that we can support
is quite difficult.

Bruce

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 11:46:43 -0400

" I do think that a rich presence system might obviate the Call forward
issues.  I've never seen it done, so I've never been able to try, but I
could see how it might."

It does.  For example,  I don't have call forward, I have on my personal agent right now (a shameless plug for my employer, sorry) 'always call forward for identities that I really don't want to talk to or refuse to identify themselves,  call forward when busy for most people, call forward for even fewer people when DND, and even when I set my presence to DND  flash my call and interrupt me if it's a call from my kid's school, my doctor, my wife, my boss,  and a few people on this list, just not too loud.'  

This is done using client-server SIP server talking to another client-server SIP server and perhaps sometimes a third SIP server from another much larger vendor who doesn't care if they got things wrong along with a fourth SIP server that's a message store from two vendors and a fifth SIP server that might do 3rd party call control if our customers buy it, (whew!), all exchanging messages in a complex energetic manner that makes life harder for our developers than it has to be.  

The underlying mechanisms are an order of magnitude more complex than they have to be and I have proof that the amount of code needed if standard techiques existed* to interact with 3rd parties from low-end endpoints to big super-duper-supernodes** would be 1/10th the amount of code needed to do the equivalent in the C/S world.   A 1.5M code-line project becomes a 150K code-line project, which as any person who has ever put together a project plan knows carries enormous implications for probability of failure and success, the kind of products that result, and the kind of sales needed to justify them.  

P2P enables long-tail economics in communications systems products in the same way that you don't have to be a 3270 forms developer to develop web content.  Vendors that participate in long-tail environments such as eBay are wise to develop on such a platform.  There are others vendors, including employers of people reading this message, that are beneficiaries of long-tail markets.  Including mine.

Regards

Michael

*Which is the only way to get people to bother as the pull in the C/S direction is very hard.

**Which is really what a 'server' is, albeit with a much les silly name.

Michael Slavitch              
Lead, Technology Initiatives
[email-masked]

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 11:25 AM
To: 'Henry Sinnreich'; 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink?

Brian

-- 

-----------------------------------------------

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp.

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 11:56:31 -0400

Brian: Finally, I propose we invent a phrase, something like "p2psip
conformant"

Backed up by a test suite.   Please.

Michael Slavitch              

[email-masked]

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 16:15:18 -0400

Brian: I agree with you entirely.  The point is that a DHT  approach
eliminates the need for such exhausting server integration if cumulative
presence and cumulative inputs from many disparate sources is implicit
within a DHT.

Regards

Michael

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 4:11 PM
To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

I was talking about using standards based presence systems to control
how
calls are routed.  It's not really "call forwarding", it's "calls from
this
class of callers when I'm in such-and-such presence state are routed to
that
device".  I'm not sure the end user would understand the difference, but
the
implementation is quite a bit different.  We have standards that would
cover
the inter-box interfaces for such systems.  I think that those standards
would work for p2psip with zero to small changes.

Was that what you were thinking Henry?  Do you see any need for what
Michael
is talking about if it's not presence based routing?

Brian

> From: Michael Slavitch [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2007 11:47 AM
> To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List
> It does.  For example,  I don't have call forward, I have on my
personal
> agent right now (a shameless plug for my employer, sorry) 'always call
> forward for identities that I really don't want to talk to or refuse
to
> identify themselves,  call forward when busy for most people, call
forward
> for even fewer people when DND, and even when I set my presence to DND
> flash my call and interrupt me if it's a call from my kid's school, my
> doctor, my wife, my boss,  and a few people on this list, just not too
> loud.'
> 
> This is done using client-server SIP server talking to another client-
> server SIP server and perhaps sometimes a third SIP server from
another
> much larger vendor who doesn't care if they got things wrong along
with a
> fourth SIP server that's a message store from two vendors and a fifth
SIP
> server that might do 3rd party call control if our customers buy it,
> (whew!), all exchanging messages in a complex energetic manner that
makes
> life harder for our developers than it has to be.
> 
> The underlying mechanisms are an order of magnitude more complex than
they
> have to be and I have proof that the amount of code needed if standard
> techiques existed* to interact with 3rd parties from low-end endpoints
to
> big super-duper-supernodes** would be 1/10th the amount of code needed
to
> do the equivalent in the C/S world.   A 1.5M code-line project becomes
a
> 150K code-line project, which as any person who has ever put together
a
> project plan knows carries enormous implications for probability of
> failure and success, the kind of products that result, and the kind of
> sales needed to justify them.
> 
> P2P enables long-tail economics in communications systems products in
the
> same way that you don't have to be a 3270 forms developer to develop
web
> content.  Vendors that participate in long-tail environments such as
eBay
> are wise to develop on such a platform.  There are others vendors,
> including employers of people reading this message, that are
beneficiaries
> of long-tail markets.  Including mine.
> 
> Regards
> 
> Michael
> 
> > Subject: RE: [P2PSIP] When we say "p2psip" what do we want
"consumers"
> to
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
non-public
> information. Any use of this information by anyone other than the
intended
> recipient is prohibited. If you have received this transmission in
error,
> please immediately reply to the sender and delete this information
from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful.
> 
> 
> 
> Any views, opinions and content presented in this e-mail are solely
those
> of the author and may not represent those of Objectworld
Communications
> Corp.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 16:10:42 -0400

I was talking about using standards based presence systems to control how
calls are routed.  It's not really "call forwarding", it's "calls from this
class of callers when I'm in such-and-such presence state are routed to that
device".  I'm not sure the end user would understand the difference, but the
implementation is quite a bit different.  We have standards that would cover
the inter-box interfaces for such systems.  I think that those standards
would work for p2psip with zero to small changes.

Was that what you were thinking Henry?  Do you see any need for what Michael
is talking about if it's not presence based routing?

Brian

> It does.  For example,  I don't have call forward, I have on my personal
> forward for identities that I really don't want to talk to or refuse to
> identify themselves,  call forward when busy for most people, call forward
> server SIP server and perhaps sometimes a third SIP server from another
> much larger vendor who doesn't care if they got things wrong along with a
> fourth SIP server that's a message store from two vendors and a fifth SIP
> (whew!), all exchanging messages in a complex energetic manner that makes
> The underlying mechanisms are an order of magnitude more complex than they
> techiques existed* to interact with 3rd parties from low-end endpoints to
> big super-duper-supernodes** would be 1/10th the amount of code needed to
> do the equivalent in the C/S world.   A 1.5M code-line project becomes a
> 150K code-line project, which as any person who has ever put together a
> P2P enables long-tail economics in communications systems products in the
> same way that you don't have to be a 3270 forms developer to develop web
> content.  Vendors that participate in long-tail environments such as eBay
> including employers of people reading this message, that are beneficiaries
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> Any views, opinions and content presented in this e-mail are solely those
> of the author and may not represent those of Objectworld Communications
> Corp.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 16:00:24 -0400

> NATs, so TLS over TCP certainly can't be our only option.

Why not?  What is inherent in ad-hoc networks that would preclude TLS over
TCP?  What is hard about doing TLS over TCP in the presence of NAT?

> calling features for telephony devices, hopefully we can just point at
As with Henry, I agree that p2psip may be used with devices that aren't
traditional telephone-like devices.  We can use a term when we want to say
how devices that purport to be telephony like devices work, without
constraining interactive gaming devices.

> agreed, although defining the exact configurations that we can support
I'm not sure I'm following this.  It does seem relatively easy to specify
the characteristics of the most common NATs encountered in the wild and use
that to define a solution that works with those.  I agree that defining, for
a given solution, which NATs work is hard.

Brian

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 4 Apr 2007 16:28:45 -0400

> TCP?  What is hard about doing TLS over TCP in the presence of NAT?

I'm not an expert on all the options, but my understanding of TLS is
that a basic assumption is that each end has a certificate from a
trusted CA that binds it to a domain name.  In an ad hoc environment,
you lack a stable domain name and a shared trusted CA that has
preallocated a certificate, so you can't possibly use TLS.

As far as TCP over NAT, not all NATs support TCP simultaneous open.
There are many NATs where you will not be able to establish a TCP
connection where you could a UDP connection.  (And there are some
where you can establish a TCP but not a UDP connection, although I
think there are fewer of these.)

> a given solution, which NATs work is hard.

We can define which NATs will work with a given traversal technique.
(more precisely, which behavior characteristics are needed.)  For
example, we can easily produce a protocol that works when peers are
behind 4787-compliant NATs (after initial join) with
endpoint-independent filtering.

The problem is that it's possible to do much better than that,
depending on how much work you're willing to do and how many of your
peers are behind "evil" NATs.  A little bit of work gets you to work
with NATs that are 4787-compliant without endpoint-independent
filtering, and a bit more will let you probabilistically work with
most pairs of NATs without relaying.  I can imagine that some overlays
are going to be willing to invest more work to get each of their
members connected than other overlays.

I guess what I'm saying is:
- I agree with you that we can specify a protocol that will work with
peers behind NATs that meet certain characteristics.
- What we would probably specify is based on 4787, and NATs that meet
all of those characteristics are not now very common (they certainly
aren't the majority).
- We need to have a protocol that can work with a wider variety of
NATs, but it's hard to make guarantees of exactly what combinations of
NATs will succeed and what won't.

Also, because there is no way to determine exactly what type of NAT
you're behind, there is fundamentally no way of being sure whether
your peer is behind a "compliant" NAT, so it's impossible to avoid the
problem of best-effort NAT workarounds with some sort of ability to
withdraw as a peer and become a client as a fallback.

Bruce

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 16:29:51 -0400

I am not  sure why Datagram TLS is not an option given the benefits involved.

Regards 

Michael

Michael Slavitch              

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 4:00 PM
To: 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink?

Brian

--

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 16:33:48 -0400

Ahh, common ground.

I do think we need to consider what the box roles are in p2psip in relation
to presence.  What element is the "presence server"?  That element routes
calls to multiple devices.  Nice, but what element in p2psip does that kind
of routing?

And, you are implying another layer of identifier.  Normally, when we talk
about p2psip identifiers, we are assuming some form of AoR.  That is the
address someone else uses to address communication to a peer.  But what if
you have multiple devices that join the overlay for the same AoR?  Certainly
allowed, but what is the unique address for such devices?  Who gets the call
to the AoR and chooses the device?

However, if every peer MUST publish presence state, and every peer MUST have
a presence client, we are getting somewhere you and I both want to get to.

Brian

> Sent: Wednesday, April 04, 2007 4:15 PM

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 4 Apr 2007 22:44:35 +0200

> preallocated a certificate, so you can't possibly use TLS.

A certificate is bound to any "common name", it does not have to be  
an Internet domain name.  It could be Peer id, SIP URI or whatever  
you need to check against.

TLS works just fine in disconnected environments as it does over  
public Internet.

Adrian

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 16:54:26 -0400

I believe that good specs use MUST as much as possible and MAY only at gunpoint, and even then only if the shooter is a good shot, so yes common ground.

Given the sieve nature of a DHT presence data does not create a flood of data, a DHT itself contains the presence database, each node contains only the data it needs, and with one writer per AOR and many readers publishing presence is low-complexity DB stuff.  Having multiple instances of the same AOR is multi-writer multi-reader which is more complicated.   'Presense' in that case is the cumulative set of presence for the set of AOR's for a single higher-level identity, ie a person.   My workplace may not want to know the cumulative presence of my cottage PC,  my home PC,  my handheld along with my work devices, but my kid might, and so might E911 for that matter.

However this begs the question:  How do you aggregate a set of AOR's for a single abstract entity, ie me?  Is this set of AOR's another nested DHT, a DHT(me)?

Might a nested recursive DHT that contains the cumulative set of objects defined for a higher-level object (an organization or a person) be the best way to aggregate AOR's and hence presence?  This would be an elegant way to get the status for nested hierarchies.

Here is what I mean:

A DHT contains all the AOR's of  Org. 
A DHT within this DHT contains all the AOR's of Org.Marketing.
A DHT within this DHT contains all the AOR's of Org.Marketing.Phil
Phil's   DHT contains all the objects of Phil.Home,  Phil.Mobile, and Phil.Work

Or it could be just one AOR, for a P2P endpoint on Phil's cellphone.

This concept scales very well.    Each DHT itself has attributes including cumulative presence, which is calculated by the members of the DHT based on internal black box rules, and is arbitrary enough to be flexible without forgetting some basic rules regarding AOR.  

Does this make sense,  shouldn't we be using the recursive nature of DHT to do this?

Regards

Michael

Michael Slavitch              

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 4:34 PM
To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink?

Ahh, common ground.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 16:58:19 -0400

We have many years of experience to answer this question.

I was walking to dinner in Prague with Henning the other night when he said
to me "I wish I had insisted we made SIP TCP only when I first proposed to
do that", which was, I believe, before 2543.  I was astonished he was that
precient.  He should have insisted.  So many things would be better if we
never had allowed UDP:

1. Fragmentation
2. Security
3. NAT traversal
4. State machine complexity to achieve reliable message delivery

Fragmentation alone is a good reason to avoid UDP.  

The benefits of UDP are exactly zero:
Efficiency of setup

Given the realities of systems today, it just isn't true enough to matter
any more.

Because of fragmentation, we have to make TCP work.  We have no other
reasonable options.  Anyone who believes p2psip setup is inherently SMALLER
than base SIP is dreaming.  INVITE messages (and others) are getting longer,
certs will be passed around, etc.  TCP is a MUST HAVE.  UDP should be MUST
NOT.

Brian

> Sent: Wednesday, April 04, 2007 4:30 PM
> To: Brian Rosen; Bruce Lowekamp
> Cc: P2PSIP Mailing List

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 17:05:33 -0400

The problem with UDP is that it is UDP.  The problem with TCP is that it
is TCP.

Let me put this another way:

The pr bl m w th UDP is th t it is UD .  The problem with TC

 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 4:58 PM
To: Michael Slavitch; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

I was walking to dinner in Prague with Henning the other night when he
said

to me "I wish I had insisted we made SIP TCP only when I first proposed
to

do that", which was, I believe, before 2543.  I was astonished he was
that

precient.  He should have insisted.  So many things would be better if
we

never had allowed UDP:

1. Fragmentation

2. Security

3. NAT traversal

Efficiency of setup

Given the realities of systems today, it just isn't true enough to
matter

any more.

reasonable options.  Anyone who believes p2psip setup is inherently
SMALLER

than base SIP is dreaming.  INVITE messages (and others) are getting
longer,

certs will be passed around, etc.  TCP is a MUST HAVE.  UDP should be
MUST

NOT.

Brian

> I am not  sure why Datagram TLS is not an option given the benefits

> involved.

> > > protocols are TCP only.  The overlay defines what credentials are

> needed

> > > 2. We do not support any form of insecure media.  It's always

> encrypted.

> > > transfer, call forward no answer, call forward busy, basic

> conferencing,

> the characteristics of the most common NATs encountered in the wild
and

> use

> that to define a solution that works with those.  I agree that
defining,

> for

non-public

intended

error,

from

those

Communications

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 4 Apr 2007 14:12:52 -0700

Yes, there is an option in Skype to forward calls to some phone number. 

That's good enough for all users except agents and receptionists where
other call forwarding features are an endpoint application that use the
e2e call control capabilities of SIP.

Such endpoint applications can be coupled with peers collocated in agent
and receptionist workstations. 

Still no servers required, nor the horrible provisioning IT systems :-)>

Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 3:11 PM
To: 'Michael Slavitch'; Henry Sinnreich; 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

Brian

personal
to
forward
another
with a
SIP
makes
they
to
to
a
a
the
web
eBay
beneficiaries
"consumers"
needed
encrypted.
conferencing,
non-public
intended
error,
from
those
Communications

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 17:15:52 -0400

Ahh, the great "Service Provider of all beings" approach.

One nested overlay which is the service provider of choice for Phil.Work,
Phil.Mobile and Phil.Home.

All sending ka-ching to that one great SP in the sky.

Please, no.

Consider this small tidbit:

You don't want your employer to choose the service provider for phil.home.

Actually, it's not Phil.Work.  You have that backwards, it's Work.Phil.
You will not give me a vCard that says Phil.Work.  You give me one that says
Work.Phil.  That's because your office creates it.  Actually, it OWNS it.
When you change employers, that becomes Work2.Phil

You could implement Phil.Work to give to your friends that always routes to
WorkX.Phil of course, but that's not what you normally would hand out.  Your
employer wants you to be known as Work.Phil, and specifically, they want to
control how that gets answered when you no longer work for them.

So, we can't have one nested DHT.  We need interoperable, interworked DHTs
with some flexibilities.

Now, of course, it would be spectacularly great if Work.Phil could route to
the same device that Phil did.  As long as the device could keep the
contacts and URIs and features straight, that would be fabulous.

A much more interesting question is whether you EVER want to give out
Phil.Mobile and Phil.Home?  That is what we have today, but is that what we
want?  Do we want CALLER choice of device or CALLED choice of device?  I
think we want the latter, with the former being something very rare.

Brian

> Sent: Wednesday, April 04, 2007 4:54 PM
> I believe that good specs use MUST as much as possible and MAY only at
> gunpoint, and even then only if the shooter is a good shot, so yes common
> ground.
> 
> Given the sieve nature of a DHT presence data does not create a flood of
> data, a DHT itself contains the presence database, each node contains only
> the data it needs, and with one writer per AOR and many readers publishing
> presence is low-complexity DB stuff.  Having multiple instances of the
> same AOR is multi-writer multi-reader which is more complicated.
> 'Presense' in that case is the cumulative set of presence for the set of
> AOR's for a single higher-level identity, ie a person.   My workplace may
> not want to know the cumulative presence of my cottage PC,  my home PC,
> my handheld along with my work devices, but my kid might, and so might
> E911 for that matter.
> 
> However this begs the question:  How do you aggregate a set of AOR's for a
> single abstract entity, ie me?  Is this set of AOR's another nested DHT, a
> DHT(me)?
> 
> Might a nested recursive DHT that contains the cumulative set of objects
> defined for a higher-level object (an organization or a person) be the
> best way to aggregate AOR's and hence presence?  This would be an elegant
> way to get the status for nested hierarchies.
> 
> Here is what I mean:
> 
> This concept scales very well.    Each DHT itself has attributes including
> cumulative presence, which is calculated by the members of the DHT based
> on internal black box rules, and is arbitrary enough to be flexible
> without forgetting some basic rules regarding AOR.
>

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 17:18:42 -0400

One DHT Rules Them All.

Depends on your goals.   Organizations above a trivial size are all hierarchal. It is a natural human behavior.  It is fractal, it is chaotic, and it is fluid, but there you go.

 Hell, families are hierarchal, especially mine. ;)

Michael Slavitch              

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 5:16 PM
To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink?

Please, no.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 17:20:54 -0400

Michael

We are well past the point in understanding how to build reliable systems on
either TCP or UDP.  That has not been an issue for nearly a decade.

UDP is touted as being fast and efficient.  That’s it.  There is no other
claimed advantage.  The problem is, that with our current understanding, it
isn't true enough to matter any more.

Brian

________________________________________
From: Michael Slavitch [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 5:06 PM
To: Brian Rosen; Bruce Lowekamp
Cc: P2PSIP Mailing List
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

The problem with UDP is that it is UDP.  The problem with TCP is that it is
TCP.

 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 4:58 PM
To: Michael Slavitch; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

1. Fragmentation
2. Security
3. NAT traversal

Brian

> a given solution, which NATs work is hard.

________________________________________
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.
Any views, opinions and content presented in this e-mail are solely those of
the author and may not represent those of Objectworld Communications Corp.

---

From: Dean Willis <[email-masked]>
Date: Wed, 4 Apr 2007 16:21:57 -0500

> capabilities are required for these services as well.

Absolutely.

For example, why put text messaging into an earbud?

Why put a wideband audio codec into a device marketed exclusively to  
the hearing-impaired?

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Apr 2007 17:30:23 -0400

See grandcentral.com and the (glowing) NYT review thereof.

---

From: Dean Willis <[email-masked]>
Date: Wed, 4 Apr 2007 16:30:08 -0500

> preallocated a certificate, so you can't possibly use TLS.

You can still use TLS. You just don't the peer-authentication  
properties you might be expecting.

Of course, if in the process of enrollment you get a cert signed by  
the overlay, a lot of this goes away.

Can this be applied to ad-hoc networks?

Perhaps. What if all those emergency-responder radios in an ad-hoc  
network required having been previously enrolled while in a more  
connected state? Boom, identity problem solved.

> think there are fewer of these.)

That's why you need some STUN servers out there, and a way to find  
them. Seems like this would work with TCP just fine.

Admittedly, if every single node is behind a port and address  
restricted NAT, we're going to have a problem.

So?

--
Dean

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 17:33:52 -0400

Show and tell time please, I'd appreciate some references on this.  

The networks I'm forced to deal on an ongoing basis show problems with TCP timeouts and retransmits on a frequent basis.     

For DHT data that aggregates over time  neither fragmentation is needed nor is retransmits.  The whole point of a DHT is that data comes in chunks so a lossy link does not matter.   Getting into TCP retransmit/timeout hell does matter.

Michael Slavitch              

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 5:21 PM
To: Michael Slavitch; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink?

Michael

UDP is touted as being fast and efficient.  That's it.  There is no other
claimed advantage.  The problem is, that with our current understanding, it
isn't true enough to matter any more.

Brian

 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 4:58 PM
To: Michael Slavitch; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

1. Fragmentation
2. Security
3. NAT traversal

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 17:35:31 -0400

Henry

I love Skype.  I use it.  You can Skype me if you want (brtech).

I could never replace any of my 3 (4 really) telephony services with Skype.
It is not reliable enough, it does not meet my feature needs and it doesn't
work on a network I can count on.  It's a "when it works it's great" thing.

I need to have call forward - no answer, not call forward.  I want presence
based call forward - no answer with class of caller filters.  It doesn't do
that.  If it did, I'd have to configure it.  It has to be standards based so
that it can connect to other standard based systems.  It can't assume that
IT is the presence client, always.  It has to publish presence somewhere
else, standards based.  I want to control what buddies see what presence
info.  More configuration.  I want click to call (out, on my choice of
outbound device, which may not be served by the same service provider, based
on my presence).

Skype is a hint, a tantalizing hint, but just a hint, of what could be.  I'd
like to engineer something that really was the right thing.  I have no
illusions that such a thing is inherently simple.

We might be able to make the user experience pleasant.  I have a quote I
love from my favorite UI designer:

"You have no idea how hard it was, and how complex it is, to make it look
that simple"

That's a tradeoff I'd make every time: complexity in the system for apparent
simplicity of the user experience, but I know how hard that is to do well.
Usually, you get the worst of both worlds: complex systems AND complex UI.

Brian

> Sent: Wednesday, April 04, 2007 5:13 PM
> To: Brian Rosen; Michael Slavitch; P2PSIP Mailing List

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 18:27:01 -0400

Ah, but you can't have one number.

You need at least two, and most people want three:
Work, Personal, Family (there really is four, because there really is an
equivalent of "Family" for work, the main number).

You are not allowed to choose your work number.  It is assigned to you by
your employer, and they own it.  You can try to layer something else on top
of it, but the employers would prohibit your use of that in most cases.

Most people still want a "family" vs a "personal" number.  It means "first
person in the family that answers it", and may well have different presence
and routing rules.  Some day, we may grow out of that.

And with current implementations, one number is quite costly because you
have to pay more than double because the calls (and the media) go through
the one number facility AND the device facility.  We could fix that with SIP
(or p2psip) of course.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2007 5:30 PM
> To: Brian Rosen
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers"
> tothink?
> 
> >
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 04 Apr 2007 16:29:24 -0700

At Wed, 4 Apr 2007 16:28:45 -0400,
> preallocated a certificate, so you can't possibly use TLS.

Well, you need a certificate that is bound to *something*.
As I'd understood it, one of the basic assumptions of P2PSIP
(in this WG) was that every entity in the system was holding
some cryptographic credential, so I don't think this is an inherent
problem...

-Ekr

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 4 Apr 2007 20:42:56 -0400

Brian,

You are arguing that TCP would have been a better choice for
conventional SIP.  I absolutely agree.

But you are then inferring that because TCP would have been better for
conventional, it will be better for P2PSIP.  That's a huge leap.

> 4. State machine complexity to achieve reliable message delivery

These are all completely true for conventional, but when we apply them
to P2P, we're looking at different issues.  1 and 4 are still true,
probably 2 (though we now have some good options there), but 3 is a
tough question.   When both sides are behind a NAT, whether TCP or UDP
is easier is a somewhat thorny question.
http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ presents a
discussion of some of the solutions, and while they achieve a rather
success rate of almost 90%, it's with some fairly involved
infrastructure, at high latency cost, and (according to some people)
not on an accurate sampling once commercial NATs are taken into
account.

> Given the realities of systems today, it just isn't true enough to matter

Ignoring NAT traversal, let's look at this question in terms of P2P
environments.  A P2PSIP peer will have to maintain connections with
their neighbors in the overlay.  Let's say maybe 16 peers.  Each TCP
connection requires memory for state and requires maintenance.   A
large overlay or active peer will require more connections.  I'm not
sure we can casually wave off the cost of these connections, at least
on low-end devices.  (I'm not sure we can't dismiss them, I'd just
rather not wave them off out of hand.)

When you put those connections behind a NAT, you have the question of
how many simultaneous connections a NAT can maintain.

> reasonable options.

Solving fragmentation inside the protocol (rather than relying on IP
to do it) isn't really that hard.

> Anyone who believes p2psip setup is inherently SMALLER

I don't dispute that it was a mistake to allow UDP for conventional
SIP, but there are a lot of questions to be answered before making
that decision for P2P.

Bruce

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Apr 2007 21:06:02 -0400

> rather not wave them off out of hand.)

This is a red herring. The per-connection cost is somewhere in the  
neighborhood of 1000 bytes for a Linux-style OS. Unless you're  
thinking of running P2PSIP on motes, this just doesn't matter. The  
'maintenance' is an initial handshake, once per peer.

(We've run several hundred thousand TCP connections on a standard  
modern Linux box, for what it's worth.)

Henning

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 4 Apr 2007 21:27:27 -0400

Thus the use of the term "low-end."

I think we're much more likely to have problems with NAT or firewall
limitations than kernel limitations, although I don't know enough
about limitations in embedded OSes other than linux.

Bruce

---

From: "Eric Cooper" <[email-masked]>
Date: Wed, 4 Apr 2007 21:50:28 -0400

I believe the default FD_SETSIZE for vxWorks is 2048, so that should give us a hint.  I don't think the low-end boxes will be getting to hundreds of thousands, but tens of tens should be OK.

In other threads there's been some discussion around running P2PSIP peers inside the NAT/FW boxes.  I believe that Linksys (Cisco) recently changed one of their popular low-end Wi-Fi routers from Linux to vxWorks and cut the RAM and flash in half (from 16/4MB to 8/2MB).

I think there will be a lot of P2PSIP peers that are several orders of magnitude less capable than modern PCs.

Best Regards,

Eric.

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 22:11:14 -0400

My worry is not the CPU, my worry is the reality-based Internet I have to deal with, which is like the Bronx at 3am.

-----Original Message-----
From: Eric Cooper [mailto:[email-masked]]
Sent: Wed 04/04/2007 9:50 PM
To: Bruce Lowekamp; Henning Schulzrinne
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink?

Best Regards,

Eric.

----- Original Message ----- 
From: "Bruce Lowekamp" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>
Cc: "P2PSIP Mailing List" <[email-masked]>
Sent: Wednesday, April 04, 2007 9:27 PM
Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink?

--

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 4 Apr 2007 19:13:26 -0700

> we didn't require some fundamental things in every sip device to 
> differentiate them from existing technology

On 2nd thought, "we" MUST NOT require any features, only the SIP
rendezvous service.

Features are the business of the endpoint application developers, not of
standards bodies, nor of the FCC or the government.

The users will select the products with the features they want. 
Now what features do I want for my social network? 
It's no business of the standards folks to make this decision.

Thanks, Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 9:49 AM
To: 'P2PSIP Mailing List'
Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to
think?

So, I propose:

Brian

---

From: Dean Willis <[email-masked]>
Date: Thu, 05 Apr 2007 00:22:16 -0500

Michael Slavitch wrote:
> 
> My worry is not the CPU, my worry is the reality-based Internet I have 
> to deal with, which is like the Bronx at 3am.

I've been doing my daily telephony over a VPN built using IPSEC over TCP 
for the last couple of months, including hotels and the IETF network, 
and it has worked just fine. It even works moderately well when running 
over GPRS EDGE using a phone as a "bluetooth modem".

--
Dean

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 05 Apr 2007 09:53:23 +0200

Dean Willis wrote:
> That's why you need some STUN servers out there, and a way to find them.
> Seems like this would work with TCP just fine.

If you can't establish simlutaneously opened TCP connections and you
can't use UDP, you need the STUN server to relay all your traffic to any
natted peer; OTOH, assuming all NATs are 4787 compliant, with UDP you
need the STUN server only for discovering your mapped address.  In the
first case you have to pay for the bandwidth twice -- to your ISP and to
the STUN server.  Am I wrong, Dean?

---

From: <[email-masked]>
Date: Thu, 5 Apr 2007 10:36:34 +0200

Michael Slavitch wrote:
> the data it needs,

The implicit assumption with this is that we are only concerned with
presence data within this DHT. 

I agree with Brian that we will see multiple interworked DHTs and that
it will be the CALLERs choice of device. This brings up how and where to
aggregate the presence data and associated user policies (e.g. do I want
Work.Phil be routed to Phil.Mobile and when do I want to do this
respectively). 

In addition, presence data may come from environments outside p2psip,
e.g. IPTV (I am watching my favorite sports team on TV and do not want
to be interrupted). Therefore, IMO DHT presence data should be able to
be federated with other presence data sources (including a presence
aggegration application).

Colin Pons
Senior Architect
WSO Innovation Management

-----Oorspronkelijk bericht-----
Van: Brian Rosen [mailto:[email-masked]] 
Verzonden: woensdag 4 april 2007 23:16
Aan: 'Michael Slavitch'; 'Henry Sinnreich'; 'P2PSIP Mailing List'
Onderwerp: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

One nested overlay which is the service provider of choice for
Phil.Work,
Phil.Mobile and Phil.Home.

Please, no.

You don't want your employer to choose the service provider for
phil.home.

Actually, it's not Phil.Work.  You have that backwards, it's Work.Phil.
You will not give me a vCard that says Phil.Work.  You give me one that
says
Work.Phil.  That's because your office creates it.  Actually, it OWNS
it.
When you change employers, that becomes Work2.Phil

You could implement Phil.Work to give to your friends that always routes
to
WorkX.Phil of course, but that's not what you normally would hand out.
Your
employer wants you to be known as Work.Phil, and specifically, they want
to
control how that gets answered when you no longer work for them.

So, we can't have one nested DHT.  We need interoperable, interworked
DHTs
with some flexibilities.

Now, of course, it would be spectacularly great if Work.Phil could route
to
the same device that Phil did.  As long as the device could keep the
contacts and URIs and features straight, that would be fabulous.

A much more interesting question is whether you EVER want to give out
Phil.Mobile and Phil.Home?  That is what we have today, but is that what
we
want?  Do we want CALLER choice of device or CALLED choice of device?  I
think we want the latter, with the former being something very rare.

Brian

> Does this make sense,  shouldn't we be using the recursive nature of
DHT
> to do this?
> allowed, but what is the unique address for such devices?  Who gets
the
> call
> However, if every peer MUST publish presence state, and every peer
MUST
> have
"consumers"
"consumers"
"consumers"
> > > issues.  I've never seen it done, so I've never been able to try,
but
> > I
> > > *Which is the only way to get people to bother as the pull in the
C/S
> > > direction is very hard.
"consumers"
> > > I wish I could transfer it to my hardline when, for whatever
reason,
> > > And then there is conferencing.  Depending on exactly how
conferencing
> > > issues.  I've never seen it done, so I've never been able to try,
but
> > I
> > > We need to go down the list of service examples and decide which
ones
> > are
> > > > I am using Skype now for several years for most long distance
calls
> > > > Nor do 99.99% of consumers or most employees any more. One can
IM
> > > > Subject: [P2PSIP] When we say "p2psip" what do we want
"consumers"
> > > > some fundamental things in every sip device to differentiate
them
> > > > Now, admittedly, what I'm talking about is somewhat a
"marketing"
> > issue,
> > > > 7. All devices work behind a given set of NAT configurations,
given
> > > > 8. We define what constitutes a minimal configuration set; all
of
> > > > All of these are designed to be minimum capabilities, but the
idea
> > > > which means a device that does that.  No protocol police, but
the
> > idea
> > > > is
> > > > that if you say you have a "p2psip conformant" device, it means
all
> > of
from
Communications
non-public
intended
error,
from
those
Communications

---

From: <[email-masked]>
Date: Thu, 5 Apr 2007 10:19:51 +0200

I suggest to define these as "personal communication devices"

> characteristics that all devices publish.

What do any of these have to do with telephony? Maybe telephony 2.0, but
not the TDM version we know today.

Furthermore, there will be devices that may not need these as are
already mentioned on the list. I struggle with this because I do like
these requirements for SIP devices, but I realize these requirements do
not always make sense for specific categories of devices.

Colin Pons
Senior Architect

-----Oorspronkelijk bericht-----
Van: Brian Rosen [mailto:[email-masked]] 
Verzonden: woensdag 4 april 2007 17:35
Aan: 'David A. Bryan'
CC: 'Henry Sinnreich'; 'P2PSIP Mailing List'
Onderwerp: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

Some, of course (like signaling and media security) might apply across
the
board.

Brian

to
conferencing
> > issues.  I've never seen it done, so I've never been able to try,
but I
ones
"consumers"
calls
> > > 7. All devices work behind a given set of NAT configurations,
given a
> > > that if you say you have a "p2psip conformant" device, it means
all of

---

From: <[email-masked]>
Date: Thu, 5 Apr 2007 10:44:04 +0200

Brian,

Lot of these devices will be wireless and/or mobile. 

I am interested in how to make SIM authentication and DHT work
seamlessly together. 
I believe that many wifi/wimax devices in the near future will be
shipped with SIM stacks as well, allowing secure authetication and
authorisation.

Colin Pons
Senior Architect

-----Oorspronkelijk bericht-----
Van: Brian Rosen [mailto:[email-masked]] 
Verzonden: woensdag 4 april 2007 16:49
Aan: 'P2PSIP Mailing List'
Onderwerp: [P2PSIP] When we say "p2psip" what do we want "consumers" to
think?

So, I propose:

Brian

---

From: "Michael Slavitch" <[email-masked]>
Date: Thu, 5 Apr 2007 07:49:26 -0400

Inline:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thu 05/04/2007 4:36 AM
To: [email-masked]; Michael Slavitch; [email-masked]; [email-masked]
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink?

MNS: If that is assumed implicit lets remove that assumption. In a peer model such data can exit or enter the DHT through a peer. The question is how does it get to a peer and what is the entity that calculates 'presence'?

MNS:  I fully agree, this is where things get useful, but how does it get there and who makes decisions? Through an aggregation via one node, where the aggregator makes decisions or via all nodes federated externally where some external (C/S) system decides? If it's external that's fine but it is a different animal. Some decisions are best suited to one and some to others. The question is, where is the application? In the peer fabric or in an outside entity? 

-----Oorspronkelijk bericht-----
Van: Brian Rosen [mailto:[email-masked]] 
Verzonden: woensdag 4 april 2007 23:16
Aan: 'Michael Slavitch'; 'Henry Sinnreich'; 'P2PSIP Mailing List'
Onderwerp: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

Please, no.

Brian

DHT
the
MUST
"consumers"
"consumers"
"consumers"
but
C/S
"consumers"
reason,
conferencing
but
ones
calls
IM
"consumers"
them
"marketing"
given
of
idea
the
all
from
Communications
non-public
intended
error,
from
those
Communications

--

---

From: "Michael Slavitch" <[email-masked]>
Date: Thu, 5 Apr 2007 08:25:14 -0400

It had better work over the IETF network or the entire NOC should get fired, and the same goes for nice hotels and academic networks running on Internet II fiber.  That largely summarizes the problem with assumptions of the IETF.  

What you are saying is that P2PSIP can displace a CSSIP that largely depends on outside well-ordered carefully provisioned detailed engineering of servers and clients, an OAM&P system that lies completely out of the control of the SIP protocol with a P2PSIP that largely depends on and assumes an outside well-ordered carefully provisioned detailed engineering of networks, backbones and demarc nodes that lies completely out of the control of the P2P protocol. For me, that's a show stopper. I thought that one of the use cases in ad-hoc networks is Katrina-like emergencies, where Bronx At 3 AM is utopia. If one of the goals of P2PSIP protocol is resilience you have to price in resilience into the protocol and not assume it lies elsewhere.

ICE has improved, STUN will be needed in any case, fragmentation is something that is more efficiently done at a higher layer, so the argument for TCP and only TCP has no merit.  If the SDP of P2PSIP is going to be so fat and complex as to require protocol-level fragments that cannot be reassembled at an application layer we are headed down the IMS path before having an empire to defend.   

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thu 05/04/2007 1:22 AM
To: Michael Slavitch
Cc: Eric Cooper; Bruce Lowekamp; Henning Schulzrinne; P2PSIP Mailing List
Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink?

--
Dean

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 5 Apr 2007 09:11:49 -0400

And that is how generic SIP got to be associated with a PSTN lookalike that
doesn't work as well, but maybe costs less. 

I liken this to security "MUST IMPLEMENT" choices we make.  We don't do them
because the protocol depends on them to work, and it's definitely a feature.
It's a value judgment; we want all implementations to have certain security
characteristics because we see the consequences of not having those
features.  The user is free to not use the feature, but if she wants to, she
can.   MUST IMPLEMENT is as ignorable as any other words in an RFC.  What
I'm proposing is the same.

What I want are interoperable implementations.  To do that, I need one
implementation to know that it, for example, tries to transfer, the other
end will be able to do that.  If it offers whatever wideband codec we choose
for audio, the other end will be able to accept.  If it subscribes to
presence for the AoR it has, assuming permission is granted, it will get it,
and certain information will be available to it (again, assuming
permissions).  I want more that "basic call" to work for all implementations
(at least those designed to work in a telephony like environment).

This is p2psip.  SIP is a multimedia session establishment protocol.  P2psip
is a multimedia session establishment protocol.  I'm not sure what you are
implying with "my social network", but if it's not multimedia session
establishment, then p2psip is not solving your problem.

Brian 

> Sent: Wednesday, April 04, 2007 10:13 PM

---

From: "Eric Cooper" <[email-masked]>
Date: Thu, 5 Apr 2007 09:48:55 -0400

I thought bliss was solving the problem you're describing.

Eric.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 5 Apr 2007 09:56:41 -0400

No.  Bliss wants to make implementation of some complex features more
uniform.  An example is call park.

Brian

> Sent: Thursday, April 05, 2007 9:49 AM
> To: Brian Rosen; 'Henry Sinnreich'; 'P2PSIP Mailing List'

---

From: "Eric Cooper" <[email-masked]>
Date: Thu, 5 Apr 2007 10:28:37 -0400

So bliss isn't trying.  I guess sipping must've failed if we still don't have interoperable transfers.  What will we do differently?

I thought P2PSIP was a distributed location service for SIP and a NAT-penetrating transport mechanism for SIP.  I don't think it's a multimedia session establishment protocol.  I think it's a bunch of primitives that reliably accomplish put/get/send using the resources of a whole bunch of nodes.  I don't see it as defining a 'profile' for what codecs and methods SIP UAs should support.

There's consensus in the group for supporting vanilla SIP UAs, but if all those UAs can't already interoperate w.r.t. call transfer do you propose to have the proxy peer (or GW or whatever) interwork their broken transfers to the P2PSIP transfer mechanism?

I'm with Henry.  I think we should stay out of this game.

Eric.

---

From: EdPimentl <[email-masked]>
Date: Thu, 5 Apr 2007 11:06:31 -0400

We are now risking letting go of  ietf p2psip ship rudder/steering
wheel and navigating without a compass into a vehement tempestous
(TelCO/CableCO IMS ) storm and will be relying on TelCO's lighthouses
and buoys to help guide us through turbulent shallow waters.

Would be possible to agree on the minimum subset of features that the
first phase of the working code should have....??
Later hardended and make more robust and even serve as critical ip
communication survival infrastructure that just works.... with or
without the un-willingpartner network (telco/cableco)
-E

-- 
Thanks in advance and best regards,

Ed Pimentel
AgileCO
Founder

Mail:   edpimentl[at]gmail.com
IM:     edpimentl [AOL | Jabber | Yahoo | MSN ]
Voip:   edpimentl [SKype | GoogleTalk ]

Mobile Content Marketing/Management/Digital Delivery
http://mobilecentral.ws

Mobile ( Relevant, Ambient, Location ) based Social Network
http://TagR.mobi (Alpha)

Mobile Payment - P2P Payment
http://agilepay.ws

Sponsor of P2PSIP  open source [viasip_ng] project
Creating a standards base P2PSIP dSIP infrastructure
https://sourceforge.net/projects/viasip/
Mailing List [email-masked]

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 5 Apr 2007 09:06:51 -0700

Thanks Eric!

> I think we should stay out of this game.

Just to make it clear:

1. P2P SIP is a rendezvous and e2e session setup protocol ONLY,

2. Don't mess with SIP based applications, they belong to the p2p
endpoint developers, owners and users. The Internet must stay
transparent to such.

3. SIP has far too many extensions already and if anything, we need to
just ignore them (the "simple SIP" I-D!). 

If endpoint developers want to publish their features and SIP extensions
on a web site or share them in confidential business meetings or discuss
them in industry alliances and consortiums, that's their business.
It is not the business of Internet standards engineers, the government
or the United Nations.

Thanks again, Henry

-----Original Message-----
From: Eric Cooper [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 9:29 AM
To: Brian Rosen; Henry Sinnreich; 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

So bliss isn't trying.  I guess sipping must've failed if we still don't
have interoperable transfers.  What will we do differently?

I thought P2PSIP was a distributed location service for SIP and a
NAT-penetrating transport mechanism for SIP.  I don't think it's a
multimedia session establishment protocol.  I think it's a bunch of
primitives that reliably accomplish put/get/send using the resources of
a whole bunch of nodes.  I don't see it as defining a 'profile' for what
codecs and methods SIP UAs should support.

There's consensus in the group for supporting vanilla SIP UAs, but if
all those UAs can't already interoperate w.r.t. call transfer do you
propose to have the proxy peer (or GW or whatever) interwork their
broken transfers to the P2PSIP transfer mechanism?

Eric.

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Eric Cooper'" <[email-masked]>; "'Henry Sinnreich'"
<[email-masked]>; "'P2PSIP Mailing List'" <[email-masked]>
Sent: Thursday, April 05, 2007 9:56 AM
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

"consumers"
>> tothink?
>> 
>> 
>> > And that is how generic SIP got to be associated with a PSTN
lookalike
>> > I liken this to security "MUST IMPLEMENT" choices we make.  We
don't do
>> > features.  The user is free to not use the feature, but if she
wants to,
>> she
>> > end will be able to do that.  If it offers whatever wideband codec
we
>> choose
>> > presence for the AoR it has, assuming permission is granted, it
will get
>> it,
>> > This is p2psip.  SIP is a multimedia session establishment
protocol.
>> P2psip
>> > is a multimedia session establishment protocol.  I'm not sure what
you
"consumers"
>> >> Features are the business of the endpoint application developers,
not
given a
all of

---

From: Dean Willis <[email-masked]>
Date: Thu, 5 Apr 2007 11:21:44 -0500

On Apr 5, 2007, at 7:25 AM, Michael Slavitch wrote:

>  If the SDP of P2PSIP is going to be so fat and complex as to  
> require protocol-level fragments that cannot be reassembled at an  
> application layer we are headed down the IMS path before having an  
> empire to defend.
>
I think that's a given, especially if we use some sort of S/MIME  
wrapper to keep intervening peers out of our SDP.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 5 Apr 2007 11:50:47 -0500

On Apr 5, 2007, at 9:28 AM, Eric Cooper wrote:

> So bliss isn't trying.  I guess sipping must've failed if we still  
> don't have interoperable transfers.  What will we do differently?
>
> primitives that reliably accomplish put/get/send using the  
> resources of a whole bunch of nodes.  I don't see it as defining a  
> 'profile' for what codecs and methods SIP UAs should support.
>
> There's consensus in the group for supporting vanilla SIP UAs, but  
> if all those UAs can't already interoperate w.r.t. call transfer do  
> you propose to have the proxy peer (or GW or whatever) interwork  
> their broken transfers to the P2PSIP transfer mechanism?
>

If I understand the question being asked to be the same as the one  
Eric answers above, then I find I must agree with Eric. P2PSIP must  
not attempt to define a profile of SIP user agent features for  
SIPPING-style call scenarios. That's somebody else's problem.

I'm not exactly sure I understand the question being asked, however.  
I think it may have slithered away from us while being reduced to the  
absurd by the discussion.

--
Dean

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 5 Apr 2007 19:06:41 -0700

seamlessly together.

The enrollment service can provide the crypto key pair that may or may
not reside in the SIM card.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 3:44 AM
To: [email-masked]; [email-masked]
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

Brian,

Colin Pons
Senior Architect

-----Oorspronkelijk bericht-----
Van: Brian Rosen [mailto:[email-masked]] 
Verzonden: woensdag 4 april 2007 16:49
Aan: 'P2PSIP Mailing List'
Onderwerp: [P2PSIP] When we say "p2psip" what do we want "consumers" to
think?

So, I propose:

Brian

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Sat, 14 Apr 2007 11:34:32 +0200

I agree with both points entirely. But I'd like to keep in mind the
following issues:
1) could we consider SCTP? we could then manage QoS issues at lower levels
if working with MANET
2) could we consider working with IPv6 ip addresses using *RFC 2462* IPv6
Stateless Address Autoconfiguration?
(A pure p2p net should not consider a dhcp server). -but i also agree that
using v4 or v6 should not be relevant-
3) is a p2p-sip net a closed net with no other service dependence? Should
p2psip rely on dhcp, dns and so on?
My opinion is p2psip should be and independent network with no other service
dependence, p2psip users should be able to perform an overlay in spite there
are no centralised servers (dns, dhcp, ntp..) neither internet reachability
(why not be able to perform an overlay when climbing the Everest? )
4) we should consider p2psip only as a singaling protocol with independence
of tx media (we can define it at SDP payload)
So, p2psip could be used for audio, video and other media session signaling
and... why not as a grid computing signaling protocol?

Thanks, Victor Pascual

-- 
Victor Pascual Ávila

mail:[email-masked]
sip:[email-masked]
fon user: 223364
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 14 Apr 2007 09:04:34 -0700

Victor Pasqual wrote:

>My opinion is p2psip should be and independent network with no other service dependence, 

>p2psip users should be able to perform an overlay in spite there are no centralised servers (dns, dhcp, ntp..) 

>neither internet reachability (why not be able to perform an overlay when climbing the Everest? ) 
>4) we should consider p2psip only as a singaling protocol with independence of tx media (we can define it at SDP payload)

Thanks Victor! It was time someone reminded the list what P2P SIP is all about!

Thanks again, Henry

________________________________

From: Victor Pascual Ávila [mailto:[email-masked]] 
Sent: Saturday, April 14, 2007 2:35 AM
To: David A. Bryan
Cc: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List
Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think?

I agree with both points entirely. But I'd like to keep in mind the following issues:
1) could we consider SCTP? we could then manage QoS issues at lower levels if working with MANET
2) could we consider working with IPv6 ip addresses using RFC 2462 IPv6 Stateless Address Autoconfiguration?
(A pure p2p net should not consider a dhcp server). -but i also agree that using v4 or v6 should not be relevant-
3) is a p2p-sip net a closed net with no other service dependence? Should p2psip rely on dhcp, dns and so on? 
My opinion is p2psip should be and independent network with no other service dependence, p2psip users should be able to perform an overlay in spite there are no centralised servers (dns, dhcp, ntp..) neither internet reachability (why not be able to perform an overlay when climbing the Everest? ) 
4) we should consider p2psip only as a singaling protocol with independence of tx media (we can define it at SDP payload)
So, p2psip could be used for audio, video and other media session signaling and... why not as a grid computing signaling protocol? 

Thanks, Victor Pascual

	David

	--
	David A. Bryan
	[email-masked]
	+1.757.565.0101 x101
	+1.757.565.0088 (fax)
	www.SIPeerior.com

-- 
Victor Pascual Ávila

mail: [email-masked] <mailto:[email-masked]> 
sip:[email-masked]
fon user: 223364

---

From: EdPimentl <[email-masked]>
Date: Sat, 14 Apr 2007 12:11:21 -0400

Would using an alias as a reminder help us keep these point top of mind?
P2PSIP is  FINE   "Future Internet Network Engineering"   :-)

-Ed

On 4/14/07, Henry Sinnreich <[email-masked]> wrote:
> >4) we should consider p2psip only as a singaling protocol with
> independence of tx media (we can define it at SDP payload)

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 14 Apr 2007 09:15:20 -0700

> P2PSIP is  FINE   "Future Internet Network Engineering"   :-)

Actually, the P2P SIP work comes a little late, at the time when p2p
traffic already dominates the Internet and Skype dominates VoIP.

So LATE may be more appropriate than FINE :-(

Henry

From: EdPimentl [mailto:[email-masked]] 
Sent: Saturday, April 14, 2007 9:11 AM
To: P2PSIP Mailing List
Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

-Ed

>So, p2psip could be used for audio, video and other media session
signaling

Thanks Victor! It was time someone reminded the list what P2P SIP is all
about!

Thanks again, Henry

---

From: "Oredope, Adetola" <[email-masked]>
Date: Tue, 17 Apr 2007 09:25:31 +0100

I really do believe that P2P-SIP when fully developed can still give
skype a run for its money and this is due to many reasons such as
P2P-SIP will facilitate trusted and secured interconnectivity between
domains. Also, due to it standardized and Open-source approach new
services can easily be developed (cf the Internet)

Even skype can admit that since releasing some APIs, thousand of news
services that were not thought about have emerge all of a sudden. Who
ever though that there could be a Skype Enterprise Edition?

P2P-SIP is the way forward!

	-----Original Message-----
	From: Henry Sinnreich [mailto:[email-masked]] 
	Sent: 14 April 2007 17:15
	To: EdPimentl; P2PSIP Mailing List
	Subject: RE: [P2PSIP] When we say "p2psip" what do we want
"consumers" tothink?

	> P2PSIP is  FINE   "Future Internet Network Engineering"   :-)

	Actually, the P2P SIP work comes a little late, at the time when
p2p traffic already dominates the Internet and Skype dominates VoIP.

	Henry

	From: EdPimentl [mailto:[email-masked]] 
	Sent: Saturday, April 14, 2007 9:11 AM
	To: P2PSIP Mailing List
	Subject: Re: [P2PSIP] When we say "p2psip" what do we want
"consumers" tothink?

	Would using an alias as a reminder help us keep these point top
of mind? 
	P2PSIP is  FINE   "Future Internet Network Engineering"   :-)
	
	-Ed

	Victor Pasqual wrote:

	>p2psip users should be able to perform an overlay in spite
there are no centralised servers (dns, dhcp, ntp..)
	>So, p2psip could be used for audio, video and other media
session signaling

	Thanks Victor! It was time someone reminded the list what P2P
SIP is all about!

	Thanks again, Henry

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 17 Apr 2007 05:54:44 -0700

>I really do believe that P2P-SIP when fully developed can still give
skype a run for its money and this is due to many reasons 

Many of us fully agree with you. Thanks for the good note!

Henry

From: Oredope, Adetola [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 1:26 AM
To: Henry Sinnreich; EdPimentl; P2PSIP Mailing List
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers"
tothink?

	-----Original Message-----
	From: Henry Sinnreich [mailto:[email-masked]] 
	Sent: 14 April 2007 17:15
	To: EdPimentl; P2PSIP Mailing List
	Subject: RE: [P2PSIP] When we say "p2psip" what do we want
"consumers" tothink?

	Henry

	
	-Ed

	Thanks again, Henry