[P2PSIP] Re: Comments to draft-marocco-p2psip-interwork-01

"Enrico Marocco" <enrico.marocco@telecomitalia.it> Mon, 12 March 2007 23:58 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQuPD-00050w-SN; Mon, 12 Mar 2007 19:58:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQuPD-00050n-3K for p2psip@ietf.org; Mon, 12 Mar 2007 19:58:19 -0400
Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQuP7-000142-6b for p2psip@ietf.org; Mon, 12 Mar 2007 19:58:19 -0400
thread-index: AcdlAkrGTBE9vEEwRUyHfFLrb+cIlg==
Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 00:58:12 +0100
Received: from ptpxch004ba020.idc.cww.telecomitalia.it ([156.54.240.43]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 00:58:11 +0100
Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch004ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 00:58:10 +0100
Message-ID: <45F5E9A4.1040904@telecomitalia.it>
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826
Date: Tue, 13 Mar 2007 01:00:36 +0100
From: Enrico Marocco <enrico.marocco@telecomitalia.it>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Willekens, Marc" <Marc.Willekens@siemens.com>
References: <67043E463DDBFD4A8087ED940BFF756B0144CD13@BRU0038A.ww018.siemens.net>
In-Reply-To: <67043E463DDBFD4A8087ED940BFF756B0144CD13@BRU0038A.ww018.siemens.net>
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 12 Mar 2007 23:58:10.0739 (UTC) FILETIME=[49E45830:01C76502]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: p2psip@ietf.org
Subject: [P2PSIP] Re: Comments to draft-marocco-p2psip-interwork-01
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

Willekens, Marc wrote:
> *1. General remark*
> 
> Thanks for your work already done for the P2PSIP inter-working to allow 
> the interconnection between the "classic SIP" and the "new P2PSIP" 
> networks.
> 
> Question: how are we going to differentiate all the different types of 
> "SIP networks" ;-)? Conventional SIP, canonical SIP, classic SIP, IETF 
> SIP, 3GPP SIP, IMS SIP, Enterprise SIP, private SIP, public SIP, IPv4 
> SIP, IPv6 SIP, standard SIP, extended SIP, ...

I see no problem as long as the differences concern the internal 
structure on the networks.  Seen from outside, each network should 
appear just as a "conventional SIP network" and the intention of the 
interworking draft is in that sense.

> *2. Specific remarks*
> 
> [Page 4], 1.1 Terminology, §5
> 
> P2PSIP Proxy Peer: Can we also consider this in an extended way as a 
> gateway peer? Now the proxy is defined as having a function to forward 
> SIP messages from the P2PSIP network to the conventional or canonical 
> SIP networks. Is a "gateway" reserved for inter-working from SIP (P2P or 
> conventional) to non-SIP networks (such as other P2P network, PSTN, 
> etc.)? Can such a gateway also be part of the P2PSIP overlay network and 
> then defined as a "P2PSIP Gateway peer" and registered as such in the 
> p2p network or will it be kept in the conventional SIP network? Or will 
> it be part of an additional P2P overlay network? I assume that all 
> options are still open and currently the PSTN inter-working is kept in 
> the conventional SIP network.

In my very personal opinion, a gateway to non-SIP networks is a service 
which should be registered in the overlay, just as a proxy peer or a 
stun server.

> [Page 6], 2 Overview
> 
> If an addressed SIP UA does not belong to the own P2P overlay domain and 
> when the originating SIP UA is only part of the local P2P network, then 
> the request is forwarded to a P2PSIP Proxy which then belongs also to 
> one or more conventional SIP networks, one or more P2PSIP networks, or 
> one inter-domain connection network based on classic SIP or P2PSIP?

A proxy peer is registered in one P2PSIP network, plus is referred by a 
DNS record which makes it resolvable as defined in RFC 3263.  In 
general, it doesn't belong to more than one network.

> [Page 11], 3.3.3 Impacts on the overlay
> 
> When different nodes in the p2p network can fulfill the role of a proxy 
> or a relay agent, how is the selection of a specific proxy/relay made 
> out of the possible set of proxies? What kind of hash function is 
> proposed to do this? Will there only be one key-partitioning approach? 
> What when more and more distributed functions are made available but not 
> on all nodes of the p2p network, i.e. when peers start differentiating 
> more and more instead of being "real peers"?

Good question.  I think it mainly depends on how registrations of 
well-known URLs (or services) are distributed among peers.

> [Page 13], 5 Examples
> 
> Thanks for the examples.
> 
> Don't we have to consider also a case where a p2p network is used as an 
> inter-domain connection network so that the P2PSIP proxy peer can 
> request the inter-domain overlay network for the corresponding proxy of 
> the public SIP or p2pSIP terminating network? Or is this something for 
> another draft?

It is an interesting case that surely deserves more investigation.  So 
far we have been considering a flat hierarchy right below the DNS level, 
laying aside more complex structures (e.g. overlays of overlays).

-- 
Ciao,
Enrico

Ahem.. Sorry, the notice below is not my fault :-(
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

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

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip