Re: [P2PSIP] Concepts issue: Domains and Overlays

["Wei Gengyu" <[e-mail]>]

Hi, 
Also including some dedicated networks.
Based on P2P technology, we are trying to give a solution to an operator for its mobility management.

Regards,

Gengyu

----- Original Message ----- 
From: "David A. Bryan" <[e-mail]>
To: "Eunsoo Shim" <[e-mail]>
Cc: "P2PSIP Mailing List" <[e-mail]>
Sent: Monday, June 25, 2007 11:35 PM
Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays


>I tend to agree local domain should be tried first, for a couple of
> reasons. First, the person you are trying to call is more likely there
> (using the "you call people in your company more than local people
> more than regional more than international" old rule of thumb. YMMV),
> and second, if the overlay is running in a small area (ad-hoc network,
> enterprise, local cluster), then the local domain search is likely to
> complete first in any case.
> 
> David
> 
> On 6/25/07, Eunsoo Shim <[e-mail]> wrote:
>> My comments are inline
>>
>>
>> On 6/20/07, Bruce Lowekamp <[e-mail]> wrote:
>> > Catching up on this thread.  Comments inline
>> >
>> > On 6/19/07, Dean Willis <[e-mail]> wrote:
>> > >
>> > > On Jun 19, 2007, at 2:54 AM, Greger V. Teigre wrote:
>> > >
>> > > > We have two choices as I see it:
>> > > >
>> > > > 1. Is the AoR supposed to be the equivalent of an email address
>> > > > where the whole domain must handled authoritatively by one entity,
>> > > > here overlay (which allows 3263 lookups) ?
>> > > >
>> > > > 2. Or is the AoR supposed to be the equivalent of "use your email
>> > > > address as username on my website"?
>> > > >
>> > >
>> > > I think #1 is the general solution, and there might reasonably be a
>> > > fallback to behavior #2 under certain fully-disconnected scenarios
>> > > that I don't really even want to think about right now because the
>> > > overlay-discovery and authentication problems become very, very messy
>> > > and make my head hurt.
>> >
>> > I agree, although I think that dividing into just these two scenarios
>> > is a little bit restrictive.  Consider a case where a company with an
>> > established conventional SIP installation is migrating over to a
>> > P2PSIP installation as hardware is replaced.  They could expect for
>> > some period of time to have both systems, and are not likely to want
>> > to use different domain parts for the old and new phones (no one
>> > really should be aware of the difference other than IT).   In this
>> > case, one good solution might be to have the p2p devices perform the
>> > lookup in the overlay and if it fails, contact the conventional proxy,
>> > only reporting failure if that fails.  So in this case, there is an
>> > overlay, and the overlay should only contain one domain, but it's not
>> > authoritative.
>>
>> There is a quite straightforward way to allow interoperation of the c/s sip
>> devices and p2psip devices using the same domain name. The concept draft or
>> my old architecture draft describes it. The overlay can be the authoritative
>> overlay for the domain.
>>
>> > I can also see situations where you might have some Internet
>> > connectivity, but might still want a particular overlay to support
>> > multiple domain parts (e.g. a non-IETF conference might have hundreds
>> > of people who could participate in a p2psip overlay and would
>> > frequently be contacting each other, but not have ideal connectivity
>> > to the Internet).
>>
>>
>> > Again, I think the right answer here is to search
>> > the local overlay before going to the broader Internet.
>>
>> I am not quite sure I understand the benefit of doing this.
>>  Are you concerned that the DNS thus the mechanism of RFC3263 may not work
>> very well because of poor Internet connectivity in this case?
>> > While I agree with the concern about being a part of 6 overlays and
>> > searching each of them everytime you make a call, I think this is
>> > something of an implementation (and usage) issue more than an issue we
>> > need to worry about right now.
>>
>> If we want interoperation of various implementations, we would need
>> agreement on what and how each peer/node will choose its own overlay(s)
>> because it will affect how a peer/node will find others.
>>
>> >   There are practical cases to support
>> > overlays that are authoritative for a single domainpart, practical
>> > cases where an overlay should have only one domain present but is not
>> > authoritative, and cases with mixed domains and no authoritative
>> > presence whatsoever.
>> >
>> > I also agree with Dean that my head hurts when thinking about how to
>> > handle authentication in the mixed domain case, since without
>> > involving an authoritative server for the domain, your security
>> > options are very different than in normal SIP.
>>
>> Yes. So I believe we should accept the fact and be flexible about security
>> requirements.
>> Again I believe  insecure connectivity may be better than no connectivity in
>> some situations.
>>
>> Thanks.
>>
>> Eunsoo
>>
>> > On 6/19/07, Brian Rosen <[e-mail]> wrote:
>> > > Okay.  I like it.
>> > >
>> > > Is there a way I can look in the URI or the DNS entry for the domain in
>> the
>> > > URI and discover if this is p2p or c/s, or do I blindly try one and then
>> the
>> > > other?
>> >
>> > Does it matter whether a URI is backed by a p2p or conventional SIP
>> > installation?  Unless you're going to join an overlay in order to send
>> > a message to anyone running one, I've been assuming that if you're
>> > sending a SIP message to a URI that is not supported by the overlay
>> > you're connected to, the resolution and message should follow the
>> > normal 3263 etc procedure.
>> >
>> > draft-marocco-p2psip-interwork-01 talks a bit about
>> interworkings
>> > between conventional and p2p deployments and I don't think has been
>> > mentioned in this thread so far.
>> >
>> > Bruce
>> >
>> > _______________________________________________
>> > P2PSIP mailing list
>> > [e-mail]
>> > https://www1.ietf.org/mailman/listinfo/p2psip
>> >
>>
>>
>> _______________________________________________
>> P2PSIP mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/p2psip
>>
>>
> 
> 
> -- 
> David A. Bryan
> [e-mail]
> +1.757.565.0101 x101
> +1.757.565.0088 (fax)
> www.SIPeerior.com
> 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
>

_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip