Subject: FW: [P2PSIP] Re: Peer definition in Concept draft

From: JiangXingFeng <[email-masked]>
Date: Thu, 05 Apr 2007 10:20:45 +0800

--
Jiang XingFeng
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

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

> -----Original Message-----
> From: JiangXingFeng [mailto:[email-masked]]
> Sent: Thursday, April 05, 2007 10:08 AM
> To: 'Dean Willis'
> Subject: RE: [P2PSIP] Re: Peer definition in Concept draft
> 
> Hi, Dean:
> Please see inline!
> Regards!
> --
> Jiang XingFeng
> 
> 
> > Whether a peer understands SIP or not depends greatly on its role.
> > Since we started with P2PSIP, the roles we've though about the most
> > involve handling SIP requests.
> >
> > It's quite possible that the "Bootstrap peer" may not speak SIP.
> >
> > Nothing in the current model requires peers to use SIP. However,
> > there are proposals (such as dSIP) that would effectively require
> > every peer to have at least some level of SIP knowledge.
> >
> > Other proposals, if I understand what Jonathan and Philip appear to
> > be thinking, require SIP only at nodes that also have traditional SIP
> > roles -- basically, at UAs and at SIP-to-P2PSIP boundary nodes that
> > would look like proxies or proxy/registrars to the SIP side.
> >
> > This could probably be better demonstrated in the reference model.
> [Jiang XingFeng] I'd like P2PSIP reference model should allow the
existence of
> non-SIP peers. If non-SIP nodes are excluded from the P2PSIP reference
model,
> the P2PSIP will be not flexible enough to support new type of peers, for
example,
> STUN peers which does not speak SIP in nature.
> 
> 
> >
> > Imagine a model where the peer protocol is not SIP, but instead
> > provides a means for carrying SIP requests in an "envelope" or
> > wrapper provided by the peer protocol.
> >
> > Peer Z would route the request along the P2PSIP Peer Protocol channel
> > based on the Peer ID indicated in the request's envelope, without
> > ever doing SIP-level parsing of the request.
> >
> > This has some interesting advantages:
> >
> > 1) The SIP body could be completely protected cryptographically and
> > not visible to intermediate peers.
> >
> > 2) Since the the request could be routed without parsing the text-
> > formatted SIP message, there is the possibility that routing
> > decisions could require substantially (perhaps an order of magnitude)
> > less processing power than that required for conventional SIP
> > proxies. This is further augmented by not having to decrypt/re-
> > encrypt each request at every proxy when TLS is used.
> >
> [Jiang XingFeng]I like these advantages. If application messages could be
delivered
> through the overlay and Peers does not care about what's in the section of
> application message, it will speed up lookup operations in a recursive
manner.
> As you suggested, every peer should have tunnel functionality to wrap
application
> message. Is the tunnel functionality specific to SIP?
> 
> Comments?
> 
> 
> > >
> 
> > That'll have to be addressed by people who speak CHORD, but I suspect
> > this mode, if deemed desirable, might influence the DHT selection
> > process.
> [Jiang XingFeng]I agree with you.
> 
> >
> > --
> > Dean

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

---

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

>>STUN peers which does not speak SIP in nature.

Good point.

Of course, if we  select SIP or modified SIP as the peer protocol (as 
per dSIP), then excluding non-sip nodes would be impossible.

...

>>message. Is the tunnel functionality specific to SIP?

As I read the charter, we're tasked with making it work for SIP. If it 
works for something besides SIP, I guess that's OK, but really not a 
design goal.

On the other hand, the classic Postel process is to favor generality 
over optimization.

--
Dean

---

From: JiangXingFeng <[email-masked]>
Date: Fri, 06 Apr 2007 15:32:12 +0800

> per dSIP), then excluding non-sip nodes would be impossible.
[JiangXingFeng] I hope non-sip nodes playing peer role is in the scope. 

> On the other hand, the classic Postel process is to favor generality
[JiangXingfeng] I like the general one. :-)

---

From: "Oredope, Adetola" <[email-masked]>
Date: Fri, 13 Apr 2007 11:43:04 +0100

Hello,

Do any one know of where I can find any information on Presence services
using P2P-SIP (SIMPLE)?
Is there any one out there working on this?

Regards,

Tola

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Apr 2007 21:34:46 -0700

I've been told about implementations where there is no presence  
server but instead pair wise subscriptions. Assume that for everyone  
on your buddy list you are on their buddy list. Then when you come on- 
line, you subscribe to everyone on your buddy list by sending them a  
subscribe directly over the P2P mesh just like you would send them an  
INVITE. When your buddies see you subscribe to them, they subscribe  
to you.

It's less than perfect but it works pretty well.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 23 Apr 2007 12:16:55 -0700

> server but instead pair wise subscriptions.

Sorry for the late reply, but we can do better than that.

A few key I-D is all that is required for example to support powerful
multimedia chat rooms for CS-SIP:

1. Message sessions: draft-ietf-simple-message-sessions-19 
by B. Campbell, R. Mahy and C. Jennings 

2. Chat rooms: draft-niemi-simple-chat-06 
by A. Niemi/Nokia and M. Garcia-Martin/Nokia 

3. NAT traversal for chat using ICE: draft-niemi-simple-msrp-ice-00 
by A. Niemi/Nokia

By using the power of P2P multicast, such as in Scribe/Pastry. See here
the 
background: 

http://research.microsoft.com/~antr/PAST/jsac.pdf 

I understand there is free code at Rice University.

I have focused here on SIMPLE P2P chat rooms, since the lack of open
source SIMPLE servers makes us all here use XMPP instead, for the simple
reason that it's available as OS and free downloads :-)> 

Reminder: We can write protocol standards until we get blue in the face
and they will fail unless OS code and free implementations are made
available to support the standard. 

Now back to SIMPLE P2P as by the above references...

Thanks, Henry

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 Apr 2007 11:03:34 +0200

Eyebeam - SIP UA with SIMPLE and XCAP support
http://counterpath.com

OpenSER - SIP SIMPLE Presence agent
http://openser.org

Xcap-lite - XCAP server
http://www.ag-projects.com/downloads

Regards,
Adrian