Subject: [P2PSIP] RELOAD Interconnection

From: Frederic-Philippe Metz <[email-masked]>
Date: Sun, 27 Dec 2009 15:29:02 +0100

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|
  +-------+     +-------+                   +-------+     +-------+

---

From: jc <[email-masked]>
Date: Sun, 27 Dec 2009 09:58:27 -0500

Call routing doesn't span overlays. There is also no mechanism to  
bridge overlays that are unique. You must join or peer each overlay   
that your node is interested in calling through.

Peering is the cheapest way to perform this operation currently.

Sent from my iPhone

On Dec 27, 2009, at 9:29 AM, Frederic-Philippe Metz <[email-masked] 
 > wrote:

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

---

From: Salman Abdul Baset <[email-masked]>
Date: Sun, 27 Dec 2009 11:34:53 -0500 (EST)

This problem lies with the realm of service discovery; how does a peer 
discover those gateway peers. There is nothing in the draft that will 
explicitly prevent this.

-s

On Sun, 27 Dec 2009, jc wrote:

> Call routing doesn't span overlays. There is also no mechanism to bridge 
> overlays that are unique. You must join or peer each overlay  that your node 
> is interested in calling through.
>
> On Dec 27, 2009, at 9:29 AM, Frederic-Philippe Metz <[email-masked]> 
> wrote:
>
>> Hi all,
>>

---

From: [email-masked]
Date: Mon, 28 Dec 2009 09:48:55 +0800

Hi Frederic,

All overlays full-mesh connected? Or a Fetch request can route though 
multiple overlays until it reaches the destination? 
By the way, there are two drafts about P2PSIP interworking. One uses DNS 
to interwork, the other introduces a top overlay for interworking.

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.