[P2PSIP] Re: Concept draft: Open issues #5 - 8

[Philip Matthews <[e-mail]>]

Regarding VoiceMail, here is one way to make it work.

A peer that is willing to act as a VoiceMail server registers
as a contact for the "VoiceMail" service.

When a User wants to enable VoiceMail, her UA does a lookup
on the VoiceMail service and gets back  a list of peers.
The UA picks one of these peers and contacts it and arranges
for it to act as a "VoiceMail taker" for the user.
The peer then registers with the UA as a contact point for the user,
presumably with a q value of .5 or similar.

So the "service" is the ability to take voicemail.
To register as a VM contact for a user, the peer registers as a UA for
the user.

- Philip


On 26-Feb-07, at 14:59 , David A. Bryan wrote:

> Only question I have is about services that are people specific (wow,
> I'm digging into odd turf here). What about things like VM? It is a
> service, but located on a per-user basis.
>
> I'm personally fine just treating that as a user-level resource, but
> wanted to see what others thought.
>
> David
>
> On 2/26/07, Philip Matthews <[e-mail]> wrote:
>> Folks:
>>
>> Back in late January I posted four more open issues for the Concepts
>> draft.
>> There was some discussion on these, and I am going to summarize here
>> what I think was agreed to as a result of these discussions.
>>
>> I plan to make these changes to the draft in the next couple of days.
>>
>> - Philip
>>
>>
>> Open issue #5: Users vs. Resources vs. Services.
>> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ 
>> 001998.html
>> =======================================
>> I propose to go with the following description of these. This is my
>> original proposal above
>> except for the addition of a change suggested by Richard Barnes.
>>
>> Users are humans. A user may be represented in the P2P Overlay by
>> multiple UAs, which represent the various different ways that the
>> user may be contacted (e.g., desk phone, mobile). Some of these may
>> answer even if the user is not available (e.g., voicemail server).
>>
>> A service represents something that a peer can do on behalf of
>> another peer.  Multiple peers may offer the same service. Within a
>> service type (e.g., "STUN server"), there may be differentiation
>> between the peers on the exact sub-type of the service provided
>> (e.g., "STUN server" vs. "STUN server with relay service"). However,
>> once the sub-type is selected, the service is identical  between
>> peers, so which one to contact can be determined by things such as
>> net-path efficiency.
>>
>> Information about a UA, user, or service may be stored in the
>> distributed
>> database. The information is stored in a "record", which has an
>> associated "key" which is used for lookup.
>>
>> It may be that a P2PSIP Overlay will store other information in the
>> distributed database. Generically, we use the term "resource" for
>> the information that can be stored in the distributed database.
>>
>>
>>
>> Open issue #6: Data Model vs Service Model
>> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ 
>> 001998.html
>> =========================================================
>> I propose to add the concept of a Data Model vs a Service Model,
>> as described in
>>     http://mice.cs.columbia.edu/getTechreport.php?techreportID=388
>> and
>>     http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-01.txt
>> Dan Romascanu requested that we come up with different terms,
>> and I will try to do that. (Feel free to make suggestions!)
>>
>>
>>
>> Open issue #7: Admitting Peer
>> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ 
>> 002000.html
>> =========================================================
>> I propose to add the terms "Joining Peer" and "Admitting Peer"
>> and change "Peer  Insertion" to "Peer Admission".
>>
>>
>>
>> Open issue #8: Expressing "Client protocol = SIP?"
>> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ 
>> 002013.html
>> =========================================================
>> I propose to rephase this question as "Do clients exist?".
>>
>>
>
>
> -- 
> 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