Subject: [P2PSIP] Question on draft-baset-p2psip-p2pcommon

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 3 May 2007 08:28:56 -0500

It seems to me that the protocol described in this draft could run on the
same connection where SIP, STUN/TURN/ICE packets are also being processed.
There is no mention in the draft accomodating this and probably the byte
encoding specified for P2PP may interfere with the multiplexing of packets.
Is this an issue?

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

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 3 May 2007 12:36:19 -0400 (EDT)

It is an issue and it needs to be specified in the draft. The techniques
will be similar to what have been specified in sipoutbound and STUN
drafts.

The STUN draft provides a magic cookie in the common header (bytes 5-8).
P2PP can check for the presence of magic cookie.

I think there is a need to specify a 'magic cookie' for P2PP so that other
protocols can differentiate it.

-salman

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 3 May 2007 15:07:32 -0400

Hi Salman,

I think that sounds great. What items are we planning for the next rev of
the draft. From an implementation standpoint, has anyone implemented this
draft yet? The 'magic cookie' approach is frankly unavoidable for a usable
implementation since I don't know how you escape the NAT traversal (SIP/ICE)
issues otherwise.

Medhavi.

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 3 May 2007 16:34:04 -0400 (EDT)

We have a basic implementation for Kademlia and another one in progress
for Chord. Both Kademlia and Chord are implemented using P2PP.

NAT traversal issues, churn recovery, replication and integration with SIP
are some of the issues that need to be addressed/further clarified in the
next revision.
-s

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 3 May 2007 16:37:12 -0400 (EDT)

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Sun, 13 May 2007 23:54:15 -0400

Hi Salman,

Regarding NAT Traversal, I couldn't see how the lookup handles the scenario
of the looked up resource accepting connections only on one of its
established connections in the p2p network (ie., through peers it is
connected to because of NAT issues). I may have glossed over something. Any
idea?

Medhavi.

On 5/3/07, Salman Abdul Baset <[email-masked]> wrote:
> > > > It seems to me that the protocol described in this draft could run
> on
> > > the

---

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 14 May 2007 22:56:11 -0400 (EDT)

You mean connection reuse for peers? It is not explicitly mentioned in the
draft but peers should reuse existing connections to send the request.
-salman

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 14 May 2007 23:15:51 -0400

I think connection re-use should cover that as long as connections are
shared for multiple protocols as and when possible (p2p, sip etc). Basically
to establish a SIP session between a source and destination there would be a
p2p lookup followed by a SIP message sent through a rendezvous server to one
of the directly connected peers of the destination ( I assume this is how it
works).
On 5/14/07, Salman Abdul Baset <[email-masked]> wrote:

> > > > I think that sounds great. What items are we planning for the next
> rev
> > > of
> > > > > I think there is a need to specify a 'magic cookie' for P2PP so
> that
> > > other
> > > > > > There is no mention in the draft accomodating this and probably
> the
> > > byte
> > > > > > encoding specified for P2PP may interfere with the multiplexing
> of
> > > > > packets.
> > > > > > Is this an issue?
> > > > > >
> > > > > > Medhavi.
> > > > > >
> > > > >
> > > >
> > >
> >
>