Subject: Re: [P2PSIP] RELOAD Interconnection

From: "Michael Chen" <[email-masked]>
Date: Sun, 27 Dec 2009 09:55:16 -0700

Frederic,

One solution is to have the border-node treat all peers in one overlay as the client nodes of the other overlay. I think it is beyond the scope of this draft.

--Michael

-------- Original Message --------

Subject: [P2PSIP] RELOAD Interconnection

From: Frederic-Philippe Metz <[email-masked]>

Date: Sun, December 27, 2009 6:29 am

To: [email-masked]

Hi all,

I have some questions respective interconnection Szenarios.

Consider a situation where two independant overlays exist. Let's call

them O#1 and O#2. Consider also this situation on base of a SIP-Call.

One Node participating in O#1 is not able to connect to a node in O#2,

unless this Node is not Joining O#1 AND O#2.

Consider now multiple Overlays. Clients may do not want to join every

RELOAD network, i.e. due to diffent Overlay algorithms they have to

implement then.

So it is not quite far away to have a certain amount of

RELOAD-"Border"-Gateways acting as a Dual-RELOAD-Node. It has a

node-ID on O#1 and a Node-ID on O#2. (Any better ideas than that ?).

It is some sort of i.e. RELOAD Back-2-Back Node.

But:

Every RELOAD Node stores it's AOR in the overlay. What should this

Border-Node store in the overlay on behalf of the other overlay and

vice versa ? Let's assume that a Fetch of a AOR leads to the node-ID

of the Border-Node. But the appattach does not contain the AOR again

to do a new fetch in the other Overlay, right ?

Does that mean that the fetch has go through the border-Node (always

with translation of node-id at the border-node). How could that look

like ? Sample Call Flow ? Better ideas ?

Cheers,

Frederic

P.S.: Little Diagram for discussion (please note that node 20 is in both):

+-------+ +-------+ +-------+ +-------+

|Node 10|-----|Node 20|---+ +---|Node 11|-----|Node 20|

+-------+ +-------+ |Border Node| +-------+ +-------+

| | +-------+-------+

| Overlay O#1 | |Node 30|Node 51|

| | +-------+-------+

+-------+ +-------+ | | +-------+ +-------+

|Node 50|-----|Node 40|---+ +---|Node 41|-----|Node 31|

+-------+ +-------+ +-------+ +-------+

_______________________________________________

P2PSIP mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/p2psip

---

From: [email-masked]
Date: Mon, 28 Dec 2009 17:18:21 +0800

http://tools.ietf.org/html/draft-marocco-p2psip-interwork-01
http://tools.ietf.org/html/draft-shi-p2psip-hier-arch-00

These two drafts are expired. They interwork P2PSIP in SIP layer. 
There is also a paper about P2PSIP ineterworking: 
http://e-archivo.uc3m.es:8080/dspace/bitstream/10016/3390/1/H-P2PSIP.pdf 

Frederic-Philippe Metz <[email-masked]> 
2009-12-28 16:53

收件人
[email-masked]
抄送

主题
Re: [P2PSIP] RELOAD Interconnection

2009/12/28 <[email-masked]>

Hi Frederic, 

All overlays full-mesh connected? Or a Fetch request can route though 
multiple overlays until it reaches the destination? 

I Won't suggest any of them by now. I had only some thoughts (regarding a 
R&D project) of how to do that.
 
By the way, there are two drafts about P2PSIP interworking. One uses DNS 
to interwork, the other introduces a top overlay for interworking.

Please, I couldn't find a valid one at IETF reflecting RELOAD. Could you 
give me some links. Thanks.
 
Cheers,
 Lichun

Frederic-Philippe Metz <[email-masked]> 
发件人:  [email-masked] 
2009-12-27 22:29 

收件人
[email-masked] 
抄送

主题
[P2PSIP] RELOAD Interconnection

Hi all,

But:

Cheers,
 Frederic

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.