Subject: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 17 May 2007 21:57:51 -0400

I briefly scanned this draft. I think it would work well if some
requirements and use cases are mentioned in the beginning. For example,
there seem to be two broad categories: outbound sessions originating from
P2P nodes and inbound sessions coming in from non P2P devices. SIP
Registrations will need to be optional since the legacy device may not
always be a SIP proxy (like a gateway).

I think the need for an interworking device like a P2P SIP Proxy etc is
optional in most cases (and should be avoided). At the media level, I am not
sure any interoperability is required since we are using ICE (which works in
non P2P environment as well). At the signaling level, the session
establishment protocol is SIP which doesnt need interworking as well. The
main problem seems to be inbound calls where a legacy device like a gateway
may not know the FQDN to route an incoming call to. I think an approach
similar to what is used for the bootstrap server would work well here for
the P2P SIP Proxy. The proxy can be stateless (since it only need to aid in
location). Once the INVITE reaches the destination P2P SIP node, it doesnt
need to be in the path. For outbound calls, I dont think any proxy or
interworking is required since location is not an issue there. I think the
issue pointed out in the draft with using correct URLs when communicating
with the legacy node makes sense.

Do I have the right understanding of the issues?

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

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 18 May 2007 09:18:46 +0200

Medhavi Bhatia wrote:
> there seem to be two broad categories: outbound sessions originating
> from P2P nodes and inbound sessions coming in from non P2P devices. SIP

Registrations with the overlay is nothing but "P2PSIP Resource Record
Insertions", as defined in concepts draft.  It can be done using SIP,
using the peer protocol or even using the client protocol, if one will
be defined.  OTOH, for registering with a public SIP network, since it
is just a _SIP_ network, SIP must be used.  So, yes, SIP registrations
are optional, but some kind of registration is still required.

> optional in most cases (and should be avoided).

They are optional when all clients and peers have unrestricted connectivity.

>                                                 At the media level, I am
> not sure any interoperability is required since we are using ICE (which
> works in non P2P environment as well).

I'm not sure ICE is effective if not using relayed and server reflexive
candidates.

>                                        At the signaling level, the
> session establishment protocol is SIP which doesnt need interworking as
> well. The main problem seems to be inbound calls where a legacy device
> like a gateway may not know the FQDN to route an incoming call to. I
> think an approach similar to what is used for the bootstrap server would
> work well here for the P2P SIP Proxy. The proxy can be stateless (since
> it only need to aid in location). Once the INVITE reaches the
> destination P2P SIP node, it doesnt need to be in the path. For outbound
> calls, I dont think any proxy or interworking is required since location
> is not an issue there. I think the issue pointed out in the draft with
> using correct URLs when communicating with the legacy node makes sense.

Proxy and relay agent peers are optional only when all clients and peers
have full connectivity.  In the most conservative case, when only few
peers are "unrestricted", they must act as proxies and relays for
allowing any other node to establish sessions with user agents on the
Internet.

-- 
Ciao,
Enrico

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 18 May 2007 11:53:59 -0400

Hi Enrico,

Please see inline for some more comments.

> are optional, but some kind of registration is still required.

Ok, I didn't think of the scenario where a device has to register with an
overlay. I think a better way is for the device to register with a regular
SIP Proxy and we figure out how the overlay interworks with it. I think same
holds for the reverse scenario as well.

> They are optional when all clients and peers have unrestricted

Connectivity is a requirement I think. After the address is know for a P2P
node, connectivity may require some help (similar to what functionality a
bootstrap node provides)

> I'm not sure ICE is effective if not using relayed and server reflexive

In any case, ICE interop is not what this draft should focus on.

> allowing any other node to establish sessions with user agents on the

Yeah. I am not debating connectivity is a problem, but it probably can do
with a simple stateless SIP Proxy like the bootstrap server.

--

---

From: Enrico Marocco <[email-masked]>
Date: Sat, 19 May 2007 10:28:23 +0200

Medhavi Bhatia wrote:
> Connectivity is a requirement I think. After the address is know for a
> P2P node, connectivity may require some help (similar to what
> functionality a bootstrap node provides)

Use cases collected so far (http://www.p2psip.org/P2PUseCases.php)
include some scenarios where peers may have restricted or no connectivity.

>     >                                                 At the media
>     level, I am

Yeah, I agree that discovery of media relays -- and, in general, of
well-known services -- should probably be addressed separately.

> Yeah. I am not debating connectivity is a problem, but it probably can
> do with a simple stateless SIP Proxy like the bootstrap server.

Personally I'd prefer to keep roles as distinct as possible, but, yes,
the proxy peer is actually a SIP proxy.

---

From: JiangXingFeng <[email-masked]>
Date: Tue, 22 May 2007 15:39:06 +0800

> the proxy peer is actually a SIP proxy.

IMHO, proxy peer in the interworking draft could be thought of as a
bootstrap peer. Finding a proxy peer in the DNS will be reduced to find a
bootstrap peer in the DNS. In this way, the caller or its authoritative
proxy server could be thought of as a client. In order to communicate with
SIP UA in an overlay, the only thing it needs to do is to find a Peer to
serve for him. The Peer could be any one in the overlay. 

In Philip's draft-matthews-p2psip-bootstrap-mechanisms-00, a bootstrap
mechanism named bootstrap server mechanism is proposed. It proposes the
bootstrap server is a SIP registrar and proxy server. I have a question
here, if the bootstrap server has all of UA contact locations, why not using
conventional SIP directly? 

So I think a Dynamic DNS may be an alterative choice for bootstrap server
because of its generality. The problems that lies in DDNS mechanism are: 1.
how does the method keep the consistence because of peers' churn. 2. Which
subset of peers could be granted to register with DNS? If all peers has
right to do registration with DNS on behalf of the overlay, DNS database
will be populated with a lot of redundant data and receive a lot of request
and will bring security threat to DNS.  

--
Jiang XingFeng

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 22 May 2007 10:18:32 +0200

> conventional SIP directly? 

It hasn't.  It acts just as a front-end for the overlay, storing and
retrieving locations in the distributed database.

> and will bring security threat to DNS.  

Registrations of peers -- proxy, bootstrap or whatever -- into DNS are
an open issue; it is critical if they are regulated by policies both too
restrictive and too permissive. The draft tries to point it out in
section 3.1.1 ("Insertion into DNS").

-- 
Ciao,
Enrico

---

From: JiangXingFeng <[email-masked]>
Date: Tue, 22 May 2007 16:36:13 +0800

> retrieving locations in the distributed database.

Yes, I know the bootstrap server will proxy message to bootstrap peer for
the joining peer. But there is still a problem: do all Peers have rights to
register with the bootstrap server? How does the bootstrap server to ensure
the consistency if the registered peers leaves the overlay gracefully or
ungracefully? Certainly, in real deployments, the operator could deploy some
server-like peers with high availability and have them register to the
bootstrap server. Personally, I don't like this method. 

--
Jiang XingFeng

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 22 May 2007 11:10:15 +0200

> bootstrap server. Personally, I don't like this method. 

Different deployments will adopt different policies for managing nearly
all kinds of operation -- joins, puts, gets, enrollments, registrations
with bootstrap/DNS servers...  The protocols needs just to be
transparent about the policy and it will be up to the deployment to find
the best way for addressing issues like those you mentioned.

-- 
Ciao,
Enrico

---

From: "Eric Cooper" <[email-masked]>
Date: Tue, 22 May 2007 15:03:41 -0400

[snip]
> conventional SIP directly?

In draft-matthews-p2psip-bootstrap-mechanisms-00, the bootstrap server need 
not be a regular SIP registrar/proxy in the client-server SIP sense, though 
we do make the observation that, with minor modifications to the URI 
processing, the code that powers a regular registrar could also power a 
bootstrap server.  The important difference between the bootstrap server in 
the draft and a regular client-server SIP registrar is that the bootstrap 
server only needs to store contact information for a small number of peers 
in the overlay (say 2 or 3).

Best Regards,

Eric.

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 23 May 2007 09:25:16 +0800

Hi, Eric: > 
> in the overlay (say 2 or 3).
But the bootstrap server has taken the responsibility to proxy the message
for the joining peer. It will mean that bootstrap server should understand
the peer protocol, whether it takes SIP or other more general protocol. It
will make the bootstrap server more involved in the overlay. IMHO, the basic
functionality of bootstrap server is to provide the contact points of the
overlay to the joining nodes. 

Regards!

JiangXingFeng

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 22 May 2007 23:20:06 -0400

Hi Jiang,

The bootstrap server only forwards a control protocol message (needed to
establish control connection between joining peer and the p2p network) and
not the p2p messages themselves. I don't think the bootstrap server is
really part of the p2p network itself as a logical entity (physically there
may be a colocated p2p node). Really we should not mix the bootstrap server
(which provides a lightweight function in the p2p network and is required
for robustness of the same) with an interworking server which is quite
stateful. That wont be a good choice.

Medhavi.

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 23 May 2007 12:03:26 +0800

>The bootstrap server only forwards a control protocol message (needed to
establish >control connection between joining peer and the p2p network) and
not the p2p >messages themselves. I don't think the bootstrap server is
really part of the p2p >network itself as a logical entity (physically there
may be a colocated p2p node). >Really we should not mix the bootstrap server
(which provides a lightweight function >in the p2p network and is required
for robustness of the same) with an interworking >server which is quite
stateful. That wont be a good choice. 

In my opinion, I also like the independence of bootstrap server from the P2P
network. It had better only provide service for joining peer to find out
existing peers in the overlay.

In the bootstrap draft and concept draft, bootstrap server should proxy
message between the joining peer and bootstrap peer especially if there are
intervening NATs between them. The typical message will be join message,
which is embodied as an INVITE message in dSIP solution. In the bootstrap
draft, when bootstrap server forwards the INVITE message, it has to modify
the message to make the bootstrap peer process the message correctly. IMHO,
I think these messages are P2P messages.  

Comments? 

Regards!

JiangXingfeng

---

From: "Eric Cooper" <[email-masked]>
Date: Wed, 23 May 2007 10:22:51 -0400

Hi JiangXingFeng,

In the bootstrap draft, one of the major ideas is that we'll use SIP to 
establish peer protocol connections.  This is analogous to the way SIP is 
used to establish RTP connections for VoIP calls.  So, I don't think it is 
necessary for the bootstrap server to understand the peer protocol (much 
like the way a pure SIP proxy doesn't need to understand RTP).

In the bootstrap draft, we have not said that the peer protocol should be 
SIP.  We took no position whatsoever on that point.

As the group explores the requirements for the peer protocol further, it may 
decide that it is a requirement that the peer protocol be able to establish 
its own connections.  Such a decision would make the bootstrap draft's usage 
of SIP obsolete.  The concepts of bootstrap servers and bootstrap peers may 
or may not survive.

You are right that the basic function of the bootstrap server is to provide 
contact points to peers joining the the overlay.  That is our intention and 
we thought it was useful to separate that function from the other operations 
a p2p overlay will require.

Best Regards,

Eric.