Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-02

From: ggb at tid.es (Gustavo García Bernardo)
Date: Mon, 16 Oct 2006 09:40:50 +0200

Hi, 

Some minor comments on the new version of draft:

* The ?P2PSIP Record (user) record? definition is duplicated.  They should
be mixed or deleted one of them.

* 3.1. Media relay: not limited to RTP.  Also MSRP for example.

* 3.4.3. "which speaks the P2PSIP server protocol"  ==> "which speaks the
P2PSIP peer protocol"

* 3.4.3. "as part of enrollment of through" ==> "as part of enrollment or
through"

* 3.4.4. The P2PSIP client/peer could discover directly other peers (for
instance using multicast) without discovering a bootstrap server before.

* Although in section 3.4.2. the client protocol is defined as put/get/send,
the send message is not explained/used in the rest of the draft.  For
example before sending a SIP message in the example signalling flows always
there are Lookups operations followed by direct SIP session establishment,
instead of a possible Send operation.

Best regards.

G.

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Sun, 22 Oct 2006 14:13:04 -0400

Gustavo:

Thanks for your comments on the document.
See more inline.

- Philip

> be mixed or deleted one of them.

Deleted second definition and did some minor rewording on the first.

> * 3.1. Media relay: not limited to RTP.  Also MSRP for example.

The text now reads:
	Media relay:
	    a P2PSIP peer or client capable of relaying media sessions.
              For example, an RTP relay as described in
             <xref target="I-D.ietf-behave-turn"/>

> * 3.4.3. "which speaks the P2PSIP server protocol"  ==> "which  
Fixed.

> * 3.4.3. "as part of enrollment of through" ==> "as part of  
Fixed.

> instance using multicast) without discovering a bootstrap server  

I have rewritten this section to take into account the distinction
between bootstrap server and bootstrap peer.
It now explicitly mentions various ways of finding a bootstrap peer,
of which using a bootstrap server is only one way.

> instead of a possible Send operation.

For now, I have removed any mention of a send operation and simply noted
that there is an open issue of how to contact peers and clients  
behind NATs.
The document notes that, because of NAT filtering rules, it may be  
necessary
to relay messages through intermediate peers, but doesn't say  
anything about how this is done.

- Philip