Re: [P2PSIP] Concepts document: proposalfor active/passive peerterminology

["Greger V. Teigre" <[e-mail]>]

I have a use case I'm struggling to map onto the various terms, and I'm 
also not sure where this working groups scope ends:
Let's say we have a regular 3261 SIP proxy. It wants to proxy requests 
into a number of overlays. Let's assume that AORs are distributed 
according to their domain (and AORs with the same domain name cannot be 
registered in several overlays).

We can then implement the contact between the proxy's domain(s) and the 
overlays in (at least) two ways:

a. Forward an INVITE into the overlay and wait for the result

b. Lookup the AOR in the overlay before proxying the INVITE and make 
routing decision based on the response

a does not require any coding in existing SIP proxyies, while b requires 
the SIP proxy to implement some sort of lookup mechanism into the 
overlay(s), either by being a peer in each overlay or by contacting a 
"proxy peer" (or is it "adapter peer"?) using some sort of data access 
protocol.

If we add the possibility of AORs from the same domain being registered 
in several overlays or if we want the proxy to route (or not) based on 
presence, we really need to do b.

I certainly don't want the data access protocol aka client protocol to 
be SIP, because I would then get a SIP message back that is really not 
part of initial INVITE transaction (or if it does not have the same 
transaction id, my proxy needs to be a UAC). The XML-RPC Get method 
described in http://tools.ietf.org/id/draft-singh-p2p-sip-01.txt seems 
more promising. And btw, the alternative, requiring a SIP proxy to be a 
peer in every overlay it wants to forward requests to sounds like the 
best way to stop that kind of communication from being done. (a 
side-note: from a SIP proxy implementation perspective, it is clearly a 
preference not having to implement a special standalone local query node 
that will registers as a peer and then offer a proprietary lookup 
interface to the proxy)

Finally, if we assume some kind of meta-lookup across overlays, we may 
be better off, but this is starting to feel a bit enum'ish to me...
g-)

Brian Rosen wrote:
> <as individual>
>
> I think we can stomp this one hard.
>
> I think that, subject to someone coming up with a use case, the term
> “client” is reserved for a SIP UA and nothing else.
>
> There were several attempts to define a client that wasn’t a SIP UA, but no
> one came up with a use case.
> We decided to leave the door open for a use case.
> No one has presented such.
>
> Therefore, at least until someone does, the word “client” means a SIP UA.
> We use the term "proxy peer" for the "gateway" you discuss below.
>
> We continue to debate the notion that there may be some variation in "peers"
> (we don't yet agree on terminology for what is a peer) that usually have
> some variation on storage or network connectivity.
>
> Personally, I think attempts to work around limitations in storage capacity
> are often fruitless unless we're talking gigabytes.  I don't think we are.
>
> Sometimes, we do need to be concerned with network bandwidth.  I'm not so
> sure we are in this case.
>
> I think that means that our choice for DHT needs to be reasonably efficient
> in storage and bandwidth, but I doubt that is a revelation to anyone.  It
> would be fascinating to me to have someone take Chord, or one of the other
> DHTs, scale it up to a typical mobile network size, and figure out what each
> handset needs in storage and bandwidth to be a fully p2psip system.  My gut
> tells me it works.
>
> We're stuck with the NAT issue; there is no getting around that.
>
> I'd like to have more discussion on the above.  Do we really, truly have to
> worry about peers who can't store?  Are we conflating the peers that can't
> accept inbound from the peers that can't store -- that is, do we assume a
> peer behind a NAT can't store?  Is that an appropriate assumption?
>
> What ARE the storage requirements we are talking about?  Probably, there is
> a tradeoff between the size of the store and the bandwidth needed.  Is that
> actually relevant?
>
> Brian
>
> ________________________________________
> From: Greger V. Teigre [mailto:[e-mail]] 
> Sent: Friday, June 15, 2007 2:52 AM
> To: Enrico Marocco
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] Concepts document: proposalfor active/passive
> peerterminology
>
> I'm struggling a bit with an underlying issue that seems to only be
> implicitly addressed (or I confuse things up).  To me it looks like people
> are talking about two different types of clients without not always
> specifying explicitly when they talk about which. I think all agree that the
> "client" does not have full peer capabilities. However, such a client can be
> aware of the overlay (as in routing or having some storage capability) and
> as such participate in the overlay as a "lesser peer" or it can be ignorant
> of the overlay, except that it knows that some entity offers GET/PUT. So, it
> needs to have a full peer, which acts as a "gateway" into the overlay.
>
> So, a first decision would be to decide whether a "lesser peer" should be
> supported or if only access through a "gateway" should be allowed. A second
> decision would be whether SIP should be used for communication between
> client and "gateway peer" or some other client protocol.
> g-)
>
> Enrico Marocco wrote: 
> Spencer Dawkins wrote: 
>
> So - is this actually happening? Or are we trying to come up with a name for
> a concept we don't need/don't know WHY we need? 
>
> As far as I recall, the only credible use case which justifies the existence
> of the "client" concept is that where a "non contributing" node wants to
> store/retrieve in the overlay something which can't be encoded in SIP
> (REGISTER?) messages (e.g. public keys, VM records...). 
> Since such functionalities are not required to realize what the group has
> been chartered for (are they?) and perhaps they could be used in centralized
> environments too, well... I personally hope that it _is_ happening and that
> we get rid of "clients" before the next meeting. 
>
>
>
> ________________________________________
>
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/

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