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.
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 protected]>
wrote:
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 protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
