Re: [Sipping] RE: Comments on draft-johnston-sipping-p2p-ipcom-01.txt

[Philip Matthews <[e-mail]>]

A peer-to-peer network can do voicemail and call handling without having
to upload the CPL script to every node in the network.

One option is for a user to have a number of trusted backups (phones, not people)
that will handle his/her calls when his/her phone is unreachable.
By using q values (as Brian noted), one can assign the highest q value
to the user's phone, and a lower q value to the backup phones.
A backup phone will then receive the call and can forward it, take voicemail,
etc.

In the case of voicemail, the message might be encrypted at the calling phone,
so that the backup cannot even look at the message (though it could delete it).

There are perhaps other options and tricks that can give even higher degrees
of security.

- Philip

Xiaotao Wu wrote:
> On Tue, 29 Mar 2005, Brian Rosen wrote:
> 
> 
>>I think this is not true.  All you need is multiple contacts with q values
>>so that eventually, one endpoint gets the call; voicemail in this case.
> 
> 
> This can be done through caller preference, and as you said, use q values,
> no CPL scripts needed.
> 
> 
>>Forwarding can also be done if an endpoint is allowed to forward.  The
>>endpoint has to be trusted by the user, but that's the nature of p2p.
> 
> 
> Users may trust nodes for routing, but should users also trust nodes for
> not releasing privacy? For example, if you use time-switch for time-based
> call routing, your schedule can get released. If you have call screening
> service to block a people you don't like, can you ensure that that
> people's node will not be one of the routing nodes?
> 
> Certainly, it works in most cases if you put your scripts to whatever
> nodes in the network, e.g., by using REGISTER, but leave it in your
> endpoints are better.
> 
> -Xiaotao
> 
> 
>>I imagine that what happens really is that I have an endpoint which is mine,
>>and under my control that is last in the contact list.  It has CPL, or
>>whatever I want, and forwards the call if necessary.
>>
>>Brian
>>
>>
>>>-----Original Message-----
>>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>>Of Xiaotao Wu
>>>Sent: Tuesday, March 29, 2005 10:58 AM
>>>To: Arjun Roychowdhury
>>>Cc: Johnston, Alan; sipping
>>>Subject: Re: [Sipping] RE: Comments on draft-johnston-sipping-p2p-ipcom-
>>>01.txt
>>>
>>>
>>>>>>    return more than just a simple Contact URI. In a pure Peer-to-
>>>
>>>peer
>>>
>>>>>>    SIP network, if the user's phone is not reachable (e.g., it is a
>>>>>>    wireless phone that is out of range), then we would still like
>>>>>>    the call to follow the user's call handling preferences.
>>>>>>This might
>>>>>>    involve taking voicemail for the user, or forwarding the call to
>>>>>>    another AoR. The user might have expressed these call handling
>>>>>>    preferences by uploading a CPL script to the "network" somehow
>>>>>>    beforehand.
>>>>>
>>>>>Yes - these are important requirements that we will want to meet with
>>>>>this protocol.
>>>>
>>>>Why is this an important requirement ? If the goal of this draft is
>>>>pure p2p, then there is no intelligent network inbetween that needs to
>>>>be relied on from a service perspective. If CPL needs to be invoked,
>>>>it would be a part of the User Agent either originating or terminating
>>>>a call and not some node in between.
>>>
>>>I agree with Arjun's point. In a P2P network, you cannot put your
>>>service scripts in the network due to both reliability and privacy
>>>concerns. If you want it to be reliable, you must have your scripts
>>>distributed to all potential routing nodes, which you never know whether
>>>they are trustable or untrustable, and the privacy will be a big concern.
>>>
>>>There could be some exceptions, such as spam filtering, a user may like to
>>>push it into the network so he does not have to keep a copy for all his
>>>devices. But, keeping service script copies on every device and
>>>synchronize the copies would not be a big problem in a P2P network.
>>>
>>>For services on endpoints, we have extended CPL to the Language for End
>>>System Services (LESS), which can be found at
>>>
>>>http://www.ietf.org/internet-drafts/draft-wu-iptel-less-00.txt
>>>
>>>The new language removes the 'proxy' action in CPL since you would not
>>>expect your endpoints to proxy calls. The language will just fit the P2P
>>>environment for services.
>>>
>>>Thanks!
>>>
>>>-Xiaotao
>>>
>>>
>>>>--
>>>>Arjun Roychowdhury
>>>>
>>>>_______________________________________________
>>>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>>This list is for NEW development of the application of SIP
>>>>Use [e-mail] for questions on current sip
>>>>Use [e-mail] for new developments of core SIP
>>>>
>>>
>>>_______________________________________________
>>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>This list is for NEW development of the application of SIP
>>>Use [e-mail] for questions on current sip
>>>Use [e-mail] for new developments of core SIP
>>>
>>
>>
>>
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP