Re: [P2PSIP] Concepts issue: Domains and Overlays

["Bruce Lowekamp" <[e-mail]>]

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.

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.

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


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