Subject: [p2p-sip] Interoperation Between HeterogenousP2P

From: wangzb at gmail.com (zhibing)
Date: Mon, 28 Aug 2006 17:14:50 +0800

Hi,Juwei,

your hierarchical P2P-SIP architecture is mainly focused on the two
problems:

1. P2P overlay to another P2P overlay ,difficulty exists.

2. how to inherit features of stateful proxy from the traditional SIP

 for the first problem:

I have a question: if single sip proxy which is elected to be a overlay
proxy failed,your way assures the connection among different overlays. but I
think it doesn't have strong connection among different overlays.Why not
inject more self-organized property into the heterogeneous overlays. I
propose  that it is better to elect a proxy farm to act as the proxy to
bridge different overlays.

 It seems the proposed Sip url name schemes do not comply with existing sip
url schemes. There is maybe difficulty in realistic deployment and maintance
for P2P-SIP.Is it realistic to introduce a header flag like as
P2P-Underlying?

The poor number of dedicated sip overlay proxyes might be the bottleneck of
sip traffic ,and also the victims of security attack.

 Thanks

Zhibing

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

Message: 1
Date: Sun, 27 Aug 2006 21:29:06 +0200
From: Sandford bessler <bessler at ftw.at>
Subject: Re: [p2p-sip] A New Internet-draft is available
To: Juwei Shi <jwshi at bupt.edu.cn>
Cc: p2p-sip at cs.columbia.edu
Message-ID: <44F1F282.60203 at ftw.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Thanks Juwei for the detailed answer.

I have a few other questions related to the draft:

1) In the example of  section 7, Bob's UA needs basically the address of
Alice's UA in order to set up the INVITE message. Is it not more elegant
to get
this address via the overlay infrastructure and then send the INVITE
directly to Alice ? Why do the P1 nad P2 proxies have to understand SIP
(messages F3, F7, etc.) ?

2) Looking at figure 1, we see that gateway nodes are both in the global
and one or more local overlays.
Another more traditional design possibility would be to connect local
overlay gateway nodes with global nodes  via a link and a simple
protocol. This would allow to
better secure domain nodes, implement access and storage policies,
require only one DHT technology per domain, etc.  The drawback is an
additional hop introduced.
What do you think ?

3) How is performed the addressing in the hash space ?  There are again
two possibilities IMHO:  in the first one each local domain has the
whole 160 bit hash space at its disposal. The routing is done with
the additional identified overlay-ID. The advantage is that in all
overlays a user for example would be stored under the same key.
The other possibility is to use the overlay-ID as prefix  and consuming
a part of the  160 bit hash  space.  Which one did you consider ?

Thanks,
Sandford

Juwei Shi schrieb:
> Hi, Sandford
>
> The sip:alice at pku.can is the global uniform identifier for Alice which
> everybody records it in the address book, and we assume that pku.can is
the
> home domain of Alice at Peking Univ. in the CAN overlay (The IP of her
home
> domain host is 59.64.154.11). When Alice visits another country (The IP of
> her visiting domain host is 211.154.71.23), she can also register the
> sip:alice at pku.can SIP URI to the CAN overlay. Then the INVITE message to
> Alice will be routed to both the hosts in his home domain and visiting
> domain.
>
> We have implemented this application layer mobility based on the multicast
> function provided by Internet Indirection Infrastructure (I3). When Alice
is
> in her home domain, she will register sip:alice at pku.can to the CAN overlay
> (indeed we use Chord overlay in I3, here use CAN for instance) via
Reg_URI()
> at 59.64.154.11. When Alice move to 211.154.71.23 in another domain, she
> will re-register sip:alice at pku.can to the CAN overlay via Reg_URI() at
> 211.154.71.23. Then the INVITE message to Alice will be routed to both
> 59.64.154.11 and 211.154.71.22. When Alice leaves the visiting domain and
> comes back to her home domain, the URI registration from 211.154.71.22will
> be removed. Then the INVITE message will be only routed to 59.64.154.11.
>
> Thanks
> Juwei
>
> _________________________________________________________
>
> Hi,
> Reading the call example in the draft, the user location functionality
> we know from SIP is not quite clear:
> Basically I would like to call Alice using her fixed SIP-URI without
> having to know that she is at pku.can
>
> In case alice at pku.can is the SIP address everybody has in the address
> book, we should maybe explain how her current address is obtained when
> she registers from another local overlay. e.g in another country she is
> visiting.
>
> Best Regards
> Sandford
>
>
>
>
>
> Juwei Shi schrieb:
>
>> Hello, all
>>
>> We have submitted a new Internet-draft entitled "A Hierarchical P2P-SIP
>>
> Architecture". This draft focuses on the SIP-over-P2P architecture and
> interworking of heterogeneous overlay networks.
>
>>
>>
>> This document is available in the Internet-drafts archive now:
>>
>> http://www3.ietf.org/internet-drafts/draft-shi-p2psip-hier-arch-00.txt
>>
>> Comments are welcomed!
>>
>> Thanks
>>
>> Juwei
>>
>> Juwei Shi
>>
>> Wireless Technology Innovation Institute (WTI)
>>
>> Beijing Univ. of Posts and Telecommunications (BUPT)
>>
>> Tel: +86-10-62283600 ext. 312
>>
>> Email: jwshi at bupt.edu.cn
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> p2p-sip mailing list
>> p2p-sip at cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
>>
>
>
>

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

Message: 2
Date: Sun, 27 Aug 2006 15:13:01 -0500
From: "Adam Fisk" <adamfisk at gmail.com>
Subject: Re: [p2p-sip] Interoperation Between Heterogenous P2P
       OverlayNetworks
To: "Henry Sinnreich" <hsinnrei at adobe.com>
Cc: p2p-sip at cs.columbia.edu, Mosiuoa Tsietsi
       <g06t6632 at campus.ru.ac.za>
Message-ID:
       <f40963db0608271313i22e5bd04sff93567ea5fc675 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I have been using Open DHT for over a year now, and my experience with it
has been adequate but not great.  The basic problem is that Planet Lab has a
fair number of stale nodes so connections often fail.  Also, for any
significant sized deployment, it just wouldn?t scale because you need more
nodes participating.

I think Bamboo is a good option.  l actually think a better option is the
mojito dht nearing completion over at LimeWire, however.  It?s a separate,
pure DHT module.  I?ve worked with many of the coders, and they really know
what they?re doing.  In my experience with the Bamboo *code*, it?s written
by people more specialized in academic algorithm research and less in
software engineering.  That?s not to say it doesn?t work or anything against
them at all (I don?t truly know if it would work on a large scale), but it?s
not the easiest code to play with.

The LimeWire guys also have the advantage of being able to instantly test
their DHT on a network with millions of nodes.  That alone will make Mojito
the DHT of choice in the near future.  It?s a modified version of Kademlia.
Azureus is also a candidate, but I?ve heard bad things about the code.
Check out mojito:

https://www.limewire.org/fisheye/browse/limecvs/mojito

-Adam

On 8/27/06, Henry Sinnreich <hsinnrei at adobe.com> wrote:
>
> Mos,
>
> >I am currently knee-deep in the Bamboo side of things.
>
> This seems to be the most promising exploration worth sharing with the
> P2P SIP folks. Bamboo is in my understanding the only (or foremost) DHT
> that defines peer neighbors in terms of delay.
>
> This alone should make Bamboo the preferred DHT for VoIP.
>
> Besides, the http://opendht.org/ is already an available network
> _service_ and its commercialization would relieve us from having to
> plant our own bootstrap servers.
>
> What do you think?
>
> Thanks, Henry
>
>
> -----Original Message-----
> From: Mosiuoa Tsietsi [mailto:g06t6632 at campus.ru.ac.za]
> Sent: Saturday, August 26, 2006 6:04 PM
> To: Henry Sinnreich
> Cc: p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] Interoperation Between Heterogenous P2P
> OverlayNetworks
>
> Henry,
>
> Firstly, thanks for the interest!
> I have already done most of the work with OpenChord.  I am currently
> knee-deep in the Bamboo side of things.  I hope to have something
> working early next month and would be happy to share my results and
> experiences with the group.
>
> Cheers.
> On Fri, 2006-08-25 at 08:27 -0700, Henry Sinnreich wrote:
> > Mos,
> >
> >
> >
> > >I have begun using OpenChord and Bamboo (Java DHT implementations) to
> > test out my plugin theory.
> >
> >
> >
> > This is really extremely interesting. Please see if/when you can share
> > the results.
> >
> >
> >
> > Thanks, Henry
> >
> >
> >
> >
> > ______________________________________________________________________
> > From:p2p-sip-bounces at cs.columbia.edu
> > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Mosiuoa Tsietsi
> > Sent: Friday, August 25, 2006 9:22 AM
> > To: p2p-sip at cs.columbia.edu
> > Subject: [p2p-sip] Interoperation Between Heterogenous P2P Overlay
> > Networks
> >
> >
> >
> >
> > Hi all,
> >
> >
> >
> > I have been listening in very intently on the list and have been very
> intrigued by many of the comments that have been made particularly
> concerning interoperation between heterogeneous P2P Overlays.  I read
> the document draft-shi-p2psip-hier-arch-00.txt with great interest and
> would like to comment on a statement made therein saying:
> >
> > "A peer in one P2P overlay (such as Chord) is difficult to route the
> SIP message to another P2P overlay (such as Pastry) based on their
> individual P2P peer locating service"
> >
> >
> >
> > I can understand the difficulty as mentioned.  I have come up with an
> > idea that could (hopefully) ameliorate these difficulties.  I propose
> > a node architecture for a P2PSIP UA within the context of using DHTs
> > as the basis of a location service, with an added abstraction layer
> > built in to the UA to hide the differences in the DHT APIs.  This
> > abstraction layer consists of a layer of DHT plug-ins for different
> > DHT algorithms.  These plug-ins will allow "pluggability" of different
> > DHTs in participating overlay nodes. This design will allow all P2PSIP
> > nodes to use a common {get, put, remove} API which is then translated
> > by the particular plug-in in use at that time.  This would eliminate
> > the need for a gateway node (since all nodes can do translation
> > between DHTs) and is more kosher in strictest p2p sense.
> >
> >
> >
> > I have begun using OpenChord and Bamboo (Java DHT implementations) to
> > test out my plugin theory.
> >
> >
> >
> > Have I misunderstood the problem and oversimplified it?  Comments much
> > appreciated.
> >
> >
> >
> > Mos
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060827/796d8dcc/attachment-0001.html

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

Message: 3
Date: Mon, 28 Aug 2006 14:10:29 +0800
From: "Juwei Shi" <jwshi at bupt.edu.cn>
Subject: Re: [p2p-sip] A New Internet-draft is available
To: "'Sandford bessler'" <bessler at ftw.at>
Cc: p2p-sip at cs.columbia.edu
Message-ID: <200608280610.k7S6ASo3026211 at noya.bupt.edu.cn>
Content-Type: text/plain;       charset="UTF-8"

Hi, Sandford

There're the answers for you.

1)
The reason why F3 and F7 exist is that we intend to make the session initial
course more controllable. Traditionally the proxy will respond a 100-Try
message to the UA when it forwards the INIVTE message to other proxies. Here
we also expect that the P2P Proxy could respond the mid-status during the
inter-domain session initial process but not only roughly forward the
message to other overlays. If we use overlays to locate the peer?s IP
address and send the INVITE message to it directly, we will not know what
happens during the inter-domain peer lookup process. In sum, we intend to
inherit the controllable feature of SIP when we replace its peer locating
service by P2P overlays and this hierarchical architecture may combines the
advantages of both SIP-over-P2P and P2P-over-SIP.

2)
I agree that this is a simple and practical design. But we think that the
deployment and maintenance cost will be increased since we need to deploy
and maintain additional global nodes. And what kind of nodes do you think
should become the global nodes?

3)
Both of the two naming schemes are under consideration now and we are also
exploring some novel naming schemes to make the P2P-SIP overlay be aware of
the underlining physic position. You may refer to the ID-stack design of
Internet Indirection Infrastructure (i3) first and we can discuss this issue
deeply in the future.

Thanks
Juwei
_______________________________________________________________

Thanks Juwei for the detailed answer.

I have a few other questions related to the draft:

1) In the example of  section 7, Bob's UA needs basically the address of
Alice's UA in order to set up the INVITE message. Is it not more elegant
to get
this address via the overlay infrastructure and then send the INVITE
directly to Alice ? Why do the P1 nad P2 proxies have to understand SIP
(messages F3, F7, etc.) ?

2) Looking at figure 1, we see that gateway nodes are both in the global
and one or more local overlays.
Another more traditional design possibility would be to connect local
overlay gateway nodes with global nodes  via a link and a simple
protocol. This would allow to
better secure domain nodes, implement access and storage policies,
require only one DHT technology per domain, etc.  The drawback is an
additional hop introduced.
What do you think ?

3) How is performed the addressing in the hash space ?  There are again
two possibilities IMHO:  in the first one each local domain has the
whole 160 bit hash space at its disposal. The routing is done with
the additional identified overlay-ID. The advantage is that in all
overlays a user for example would be stored under the same key.
The other possibility is to use the overlay-ID as prefix  and consuming
a part of the  160 bit hash  space.  Which one did you consider ?

Thanks,
Sandford

Juwei Shi schrieb:
> Hi, Sandford
>
> The sip:alice at pku.can is the global uniform identifier for Alice which
> everybody records it in the address book, and we assume that pku.can is
the
> home domain of Alice at Peking Univ. in the CAN overlay (The IP of her
home
> domain host is 59.64.154.11). When Alice visits another country (The IP of
> her visiting domain host is 211.154.71.23), she can also register the
> sip:alice at pku.can SIP URI to the CAN overlay. Then the INVITE message to
> Alice will be routed to both the hosts in his home domain and visiting
> domain.
>
> We have implemented this application layer mobility based on the multicast
> function provided by Internet Indirection Infrastructure (I3). When Alice
is
> in her home domain, she will register sip:alice at pku.can to the CAN overlay
> (indeed we use Chord overlay in I3, here use CAN for instance) via
Reg_URI()
> at 59.64.154.11. When Alice move to 211.154.71.23 in another domain, she
> will re-register sip:alice at pku.can to the CAN overlay via Reg_URI() at
> 211.154.71.23. Then the INVITE message to Alice will be routed to both
> 59.64.154.11 and 211.154.71.22. When Alice leaves the visiting domain and
> comes back to her home domain, the URI registration from 211.154.71.22will
> be removed. Then the INVITE message will be only routed to 59.64.154.11.
>
> Thanks
> Juwei
>
> _________________________________________________________
>
> Hi,
> Reading the call example in the draft, the user location functionality
> we know from SIP is not quite clear:
> Basically I would like to call Alice using her fixed SIP-URI without
> having to know that she is at pku.can
>
> In case alice at pku.can is the SIP address everybody has in the address
> book, we should maybe explain how her current address is obtained when
> she registers from another local overlay. e.g in another country she is
> visiting.
>
> Best Regards
> Sandford
>
>
>
>
>
> Juwei Shi schrieb:
>
>> Hello, all
>>
>> We have submitted a new Internet-draft entitled "A Hierarchical P2P-SIP
>>
> Architecture". This draft focuses on the SIP-over-P2P architecture and
> interworking of heterogeneous overlay networks.
>
>>
>>
>> This document is available in the Internet-drafts archive now:
>>
>> http://www3.ietf.org/internet-drafts/draft-shi-p2psip-hier-arch-00.txt
>>
>> Comments are welcomed!
>>
>> Thanks
>>
>> Juwei
>>
>> Juwei Shi
>>
>> Wireless Technology Innovation Institute (WTI)
>>
>> Beijing Univ. of Posts and Telecommunications (BUPT)
>>
>> Tel: +86-10-62283600 ext. 312
>>
>> Email: jwshi at bupt.edu.cn
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> p2p-sip mailing list
>> p2p-sip at cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
>>
>
>
>

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

Message: 4
Date: Mon, 28 Aug 2006 14:12:01 +0800
From: "Juwei Shi" <jwshi at bupt.edu.cn>
Subject: Re: [p2p-sip] Interoperation Between HeterogenousP2P
       OverlayNetworks
To: "'Mosiuoa Tsietsi'" <g06t6632 at campus.ru.ac.za>,     "'Seaward Hu'"
       <hu.xinyu at huawei.com>
Cc: p2p-sip at cs.columbia.edu
Message-ID: <200608280612.k7S6C0o3026367 at noya.bupt.edu.cn>
Content-Type: text/plain;       charset="UTF-8"

Hi, Mosiuoa

The idea only storing resource bindings is very interesting and I think that
proxy nodes are still needed. The difference between our scheme and your
scheme is that: we implement the inter-overlay operation via a higher level
overlay and you implement that via only inter-domain resource
operation/register. Does every overlay need to register to any other
overlays as the resource? The efficiency, reliability, scalability and
message overhead need to be evaluated by your future experiment.

Thanks
Juwei

__________________________________________________

Hi folks,

Thanks for the probing questions, they really make me think more
carefully about my idea, which is for all intents and purposes, work in
progress.  Firstly, interoperation aside, pluggability of algorithms is
useful to overlays because it doesn't commit them to one way of doing
things.  I don't think anyone is willing to stick out his/her head and
say Chord is best or Pastry is best for P2P SIP (neither am I saying
DHTs are the best p2p protocol, oops!).  An overlay can choose to
"switch" to another routing algorithm for experimental purposes and we
can examine differences in latency etc.

Now for the contentious issue, interoperation.  Say for sake of
arguement bob at chord.co.za wants to initiate a call with
alice at pastry.co.za.  Bob notices that the RHS of Alice's AOR is not
chord.co.za (not part of the local overlay).  So what next?  The idea is
still taking form in my mind, but if we are allowing storage of foreign
resource bindings in the local overlay, essentially, only one binding
for a given overlay may be enough since the P2PSIP proxy is flattened
across the foreign overlay and every peer is savvy enough to translate.

I could be wrong about this.  I did initially think of using a proxy (it
is the natural choice) but thought it would simply be an optimization to
the base case.  It may actually be the way to go since I also wanted to
explore interoperation with canonical SIP and that will definately need
gateways (for interest sake, I was thinking along the lines of
CoDoNS/Beehive and DNS-DHT translators..).

At any rate, I'm glad I got my idea out there.  The input is great!

Mos
On Sat, 2006-08-26 at 10:42 +0800, Seaward Hu wrote:
>      I agree with Krishna, let me show a example.
>       We know that the Window OS can support many companies' CPU, but
after
> you install it in your computer with Pentium CPU, you can not simply move
> the hard disk to another computer with AMD CPU and boot it successfully,
for
> the two kinds of CPU have different instruction set. To interwork between
> the two computers, we need other protocols such as FTP, HTTP and SIP.
>      So I mean not every node can bear the burden of supporting many kinds
> of DHT protocol, for the efficient reason, the protocol for interworking
> over different overlay is needed. And those strong nodes which equipped
with
> two kinds or more stack will become the GW.
>       I don't know if I misunderstand Mos's idea, comments are
appreciated.
>
> Thanks.
>
> Seaward
>
> > -----Original Message-----
> > From: p2p-sip-bounces at cs.columbia.edu
> > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna
> > Sankar (ksankar)
> > Sent: Saturday, August 26, 2006 1:30 AM
> > To: Juwei Shi; Mosiuoa Tsietsi; p2p-sip at cs.columbia.edu
> > Subject: Re: [p2p-sip] Interoperation Between Heterogenous
> > P2P OverlayNetworks
> >
> > >   I can't understand your plug-in theory clearly. Although the
> > common API can be provided by your architecture, the <KS>
> >
> > Yep, same here.
> >
> > There are two distinct layers, the interface layer and the
> > protocol layer. The interface layer can be abstracted by a
> > plug-in architecture, thus making a system independent from
> > programming changes. But if the underlying protocol machines,
> > state machines, information model and wire formats are
> > different, we will not be able to achieve interoperability
> > and will result in what Juwei has described.
> >
> > The JMS (Java Messaging Service) world has parallels - the
> > JMS API is standard, so that we can use JMS either with JMS
> > providers or with products like Tibco, MQ et al. The
> > programming does not change. But none of them are
> > interoperable; which means we cannot send a JMS message
> > through an IBM JMS implementation and expect BEA JMS to understand it.
> > This is because, the wire format and the protocols are not
> > standardized.
> >
> > That said, am interested in how Mos's idea works out. From
> > the beginning, this was one of my wishes - a substrate
> > agnostic, transport independent and orthogonally extensible
> > P2P-SIP. But am not sure it can be achieved ...
> >
> > </KS>
> >
> >
> > ________________________________
> >
> >     From: p2p-sip-bounces at cs.columbia.edu
> > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Juwei Shi
> >     Sent: Friday, August 25, 2006 10:12 AM
> >     To: 'Mosiuoa Tsietsi'; p2p-sip at cs.columbia.edu
> >     Subject: Re: [p2p-sip] Interoperation Between
> > Heterogenous P2P OverlayNetworks
> >
> >
> >
> >     Hi, Mos
> >
> >
> >
> >     I can't understand your plug-in theory clearly.
> > Although the common API can be provided by your architecture,
> > the underlying lookup protocols still differ. If every node
> > has all kinds of overlays, it must join all overlays. That is
> > to say, all nodes can do translation between DHTs means every
> > node should join all DHTs. Then the DHT operation message
> > overhead will be significantly increased and I personally
> > don't think it is a practical way for heterogeneous overlay
> > interwroking.
> > Furthermore, if every node runs all kinds of DHTs, there's no
> > need of interworking.
> >
> >
> >
> >     Do I comprehend your idea correctly? Can you give us an
> > session initial example between Bob in Chord and Alice in Pastry?
> >
> >
> >
> >     Thanks
> >
> >     Juwei
> >
> >
> >
> >     ________________________________
> >
> >
> >
> >     Hi all,
> >
> >
> >
> >     I have been listening in very intently on the list and
> > have been very intrigued by many of the comments that have
> > been made particularly concerning interoperation between
> > heterogeneous P2P Overlays.  I read the document
> > draft-shi-p2psip-hier-arch-00.txt with great interest and
> > would like to comment on a statement made therein saying:
> >
> >     "A peer in one P2P overlay (such as Chord) is difficult
> > to route the SIP message to another P2P overlay (such as
> > Pastry) based on their individual P2P peer locating service"
> >
> >
> >
> >     I can understand the difficulty as mentioned.  I have
> > come up with an idea that could (hopefully) ameliorate these
> > difficulties.  I propose a node architecture for a P2PSIP UA
> > within the context of using DHTs as the basis of a location
> > service, with an added abstraction layer built in to the UA
> > to hide the differences in the DHT APIs.  This abstraction
> > layer consists of a layer of DHT plug-ins for different DHT
> > algorithms.  These plug-ins will allow "pluggability" of
> > different DHTs in participating overlay nodes. This design
> > will allow all P2PSIP nodes to use a common {get, put,
>
> > remove} API which is then translated by the particular
> > plug-in in use at that time.  This would eliminate the need
> > for a gateway node (since all nodes can do translation
> > between DHTs) and is more kosher in strictest p2p sense.
> >
> >
> >
> >     I have begun using OpenChord and Bamboo (Java DHT
> > implementations) to test out my plugin theory.
> >
> >
> >
> >     Have I misunderstood the problem and oversimplified it?
> > Comments much appreciated.
> >
> >
> >
> >     Mos
> >
> >
> >
> >
> >
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> >
>
>
>

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

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

End of p2p-sip Digest, Vol 13, Issue 42
***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060828/030a4773/attachment-0001.html

---

From: jwshi at bupt.edu.cn (Juwei Shi)
Date: Mon, 28 Aug 2006 17:48:03 +0800

Hi, Zhi Ding

Simultaneity electing several proxies in an overlay is acceptable. However, the message overhead will increase. If we apply this approach, the cooperation of the elected proxies within an overlay needs to be discussed. 

The inter-working between P2PSIP overlays and conventional SIP networks is discussed in 

http://www.p2psip.org/drafts/draft-marocco-p2psip-interwork-00.txt

The domain of overlay ID should be located by the DNS server for the inter-working. 

Thanks

Juwei

Hi,Juwei,

your hierarchical P2P-SIP architecture is mainly focused on the two problems:

 for the first problem:

I have a question: if single sip proxy which is elected to be a overlay proxy failed,your way assures the connection among different overlays. but I think it doesn't have strong connection among different overlays.Why not inject more self-organized property into the heterogeneous overlays. I propose  that it is better to elect a proxy farm to act as the proxy to bridge different overlays.

 It seems the proposed Sip url name schemes do not comply with existing sip url schemes. There is maybe difficulty in realistic deployment and maintance for P2P-SIP.Is it realistic to introduce a header flag like as P2P-Underlying? 

The poor number of dedicated sip overlay proxyes might be the bottleneck of sip traffic ,and also the victims of security attack.

 Thanks

Zhibing

Message: 1

Thanks,
Sandford

Juwei Shi schrieb:
> Hi, Sandford
>
> The sip:alice at pku.can  <mailto:sip:alice at pku.can> is the global uniform identifier for Alice which
> everybody records it in the address book, and we assume that pku.can is the
> home domain of Alice at Peking Univ. in the CAN overlay (The IP of her home 
> function provided by Internet Indirection Infrastructure (I3). When Alice is
> (indeed we use Chord overlay in I3, here use CAN for instance) via Reg_URI()
> comes back to her home domain, the URI registration from 211.154.71.22 will

Message: 2
       <f40963db0608271313i22e5bd04sff93567ea5fc675 at mail.gmail.com >

-Adam

On 8/27/06, Henry Sinnreich <hsinnrei at adobe.com> wrote:
> From: Mosiuoa Tsietsi [mailto: <mailto:g06t6632 at campus.ru.ac.za>  g06t6632 at campus.ru.ac.za]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060827/796d8dcc/attachment-0001.html

Message: 3
From: "Juwei Shi" < jwshi at bupt.edu.cn>

Hi, Sandford

1)
The reason why F3 and F7 exist is that we intend to make the session initial course more controllable. Traditionally the proxy will respond a 100-Try message to the UA when it forwards the INIVTE message to other proxies. Here we also expect that the P2P Proxy could respond the mid-status during the inter-domain session initial process but not only roughly forward the message to other overlays. If we use overlays to locate the peer?s IP address and send the INVITE message to it directly, we will not know what happens during the inter-domain peer lookup process. In sum, we intend to inherit the controllable feature of SIP when we replace its peer locating service by P2P overlays and this hierarchical architecture may combines the advantages of both SIP-over-P2P and P2P-over-SIP. 

2)
I agree that this is a simple and practical design. But we think that the deployment and maintenance cost will be increased since we need to deploy and maintain additional global nodes. And what kind of nodes do you think should become the global nodes? 

3)
Both of the two naming schemes are under consideration now and we are also exploring some novel naming schemes to make the P2P-SIP overlay be aware of the underlining physic position. You may refer to the ID-stack design of Internet Indirection Infrastructure (i3) first and we can discuss this issue deeply in the future. 

Thanks
Juwei

Thanks,
Sandford

Juwei Shi schrieb:
> everybody records it in the address book, and we assume that pku.can is the
> home domain of Alice at Peking Univ. in the CAN overlay (The IP of her home
> function provided by Internet Indirection Infrastructure (I3). When Alice is
> (indeed we use Chord overlay in I3, here use CAN for instance) via Reg_URI()
> comes back to her home domain, the URI registration from 211.154.71.22 will
> be removed. Then the INVITE message will be only routed to 59.64.154.11  <http://59.64.154.11> .
>
> Thanks
> Juwei
>

Message: 4
Date: Mon, 28 Aug 2006 14:12:01 +0800
From: "Juwei Shi" < jwshi at bupt.edu.cn <mailto:jwshi at bupt.edu.cn> >
Subject: Re: [p2p-sip] Interoperation Between HeterogenousP2P
       OverlayNetworks
To: "'Mosiuoa Tsietsi'" <g06t6632 at campus.ru.ac.za >,     "'Seaward Hu'"
       <hu.xinyu at huawei.com>
Cc: p2p-sip at cs.columbia.edu
Message-ID: < <mailto:200608280612.k7S6C0o3026367 at noya.bupt.edu.cn>  200608280612.k7S6C0o3026367 at noya.bupt.edu.cn>
Content-Type: text/plain;       charset="UTF-8"

Hi, Mosiuoa

The idea only storing resource bindings is very interesting and I think that proxy nodes are still needed. The difference between our scheme and your scheme is that: we implement the inter-overlay operation via a higher level overlay and you implement that via only inter-domain resource operation/register. Does every overlay need to register to any other overlays as the resource? The efficiency, reliability, scalability and message overhead need to be evaluated by your future experiment. 

Thanks
Juwei

Hi folks,

Mos
On Sat, 2006-08-26 at 10:42 +0800, Seaward Hu wrote:
>       We know that the Window OS can support many companies' CPU, but after
> the hard disk to another computer with AMD CPU and boot it successfully, for
> over different overlay is needed. And those strong nodes which equipped with 
>       I don't know if I misunderstand Mos's idea, comments are appreciated.
>
> Thanks.
>
> Seaward
>

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu  <mailto:p2p-sip at cs.columbia.edu> 
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060828/e17fe607/attachment-0001.html