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

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Sat, 2 Apr 2005 11:20:26 -0600

On the corporate customers, I agree with Henry. Residential consumers,
may or may not care..

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Friday, April 01, 2005 3:22 PM
To: 'Dean Willis'
Cc: 'Johnston, Alan'; 'sipping'; 'Xiaotao Wu'
Subject: RE: [Sipping] RE: Comments on
draft-johnston-sipping-p2p-ipcom-01.txt

> Users are sheep. If it works, we're happy. If it doesn't, we're kebab.

Corporate customers will care however (though it's amazing how much bad
stuff they buy, that we need not mention here).

Even consumers may start to care where their voice mail is stored once
there
is a story in the media.

Henry

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, April 01, 2005 12:09 PM
To: [email-masked]
Cc: 'Xiaotao Wu'; 'Johnston, Alan'; 'Arjun Roychowdhury'; 'sipping';
'Brian
Rosen'
Subject: Re: [Sipping] RE: Comments on
draft-johnston-sipping-p2p-ipcom-01.txt

On Mar 30, 2005, at 5:04 PM, [email-masked] wrote:

>> I think this is not true.
>
> It is true.
>
> Nobody will accept a P2P voice mail service if they know the storage 
> is on
> someone else's PC. Storing on your own PC is however a better choice, 
> as is
> done here:
>
> http://www.hotrecorder.com/
>
>
Actually, I just signed up for Skype In, which gives me both a PSTN 
phone number and voice mail for euros 30 per year. I have absolutely no 
idea where the voice mail is stored, except it's probably NOT on my PC, 
since I can receive voice mail when my PC is turned off. It might be 
sliced up and stored all over the set of Skype clients. It might be on 
a server in London. I just don't know. But as long as it works, I'm not 
all that worried about it. Curious, vaguely, but I hadn't even stopped 
to wonder until I saw this email.

Users are sheep. If it works, we're happy. If it doesn't, we're kebab.

Baah!

--
dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 4 Apr 2005 14:05:59 -0400

Paul,

I was thinking that the ENUM entry would return:
sip: user@domain
smtp: user@domain 

If after sending 7 INVITEs to the sip address, I assume your sip phone
will play some announcement.  Did you need something specific?  That
could probably easily be stored in the email server as part of the
automatic reply mechanism, with emails that leave voice-mails getting an
automatic voice-mail in reply.  So, after 7 INVITEs fire of an email,
get an email back, play the voice-mail attachment.

Mike

>From: Paul Kyzivat (pkyzivat) 
>Sent: Monday, April 04, 2005 1:51 PM
>To: Michael Hammer (mhammer)
>Cc: [email-masked]; Roy, Radhika; Brian Rosen; Seamus 
>Gilchrist; Philip Matthews; sipping
>Michael Hammer (mhammer) wrote:
>> Henry,
>>  
>> A little bit of technology dependence, given that you are starting 
>> with dependence on SIP technology to begin with, is good.  I would 
>> argue that ENUM to tell you what addresses to send SIP to, 
>as well as 
>> where to send a store-and-forward message is a minimum, 
>given that you 
>> will need to use DNS in any case.  The voice-mail message can be 
>> generated and sent to that user that is not online at the time a SIP 
>> call is attempted and fails.  Email has already proved to be 
>a killer 
>> app and provided almost universally, so assuming it as part of the 
>> solution seems like no great stretch.
>
>If the target is a phone number, then enum can be used both to 
>decide where to send an INVITE, and where to send an email 
>containing voicemail. Seems like a decent approach.
>
>There are two things that doesn't do:
>- it doesn't give the caller an announcement if the callee is 
>unavailable. (Perhaps there should also be an enum entry for 
>rtsp as a way to provide an announcement.)
>
>- it doesn't say how to deliver an email message if the target 
>address is a sip address. One *might* assume that if you fail 
>at calling sip:[email-masked] then you can send an email to 
>[email-masked]. 
>But there is no normative relationship between those 
>addresses, so it isn't an entirely safe assumption, even 
>though most would probably attempt it. Given common usage like 
>this, perhaps there should be some effort to formalize a 
>convention that all URIs using the "user@domain" 
>format should, if they exist, "belong" to the same owner for 
>each value of "user@domain".
>
>	Paul
>
>> Mike
>> 
>>     
>---------------------------------------------------------------
>---------
>>     *From:* [email-masked] 
>[mailto:[email-masked]]
>>     *On Behalf Of [email-masked]
>>     *Sent:* Sunday, April 03, 2005 11:35 AM
>>     *To:* 'Roy, Radhika'; 'Brian Rosen'; 'Seamus Gilchrist'; 'Philip
>>     Matthews'
>>     *Cc:* 'sipping'
>>     *Subject:* RE: [Sipping] RE: Comments on
>>     Roy,
>>     Another way of separating the issues of voice mail and P2P is to
>>     make them technology independent.
>> 
>>      
>> 
>>     Is there an expectation from the customer to call and leave voice
>>     mail if the presence icon makes it visible that the 
>other party is
>>     not online? There is a reasonable chance I believe for 
>the "caller"
>>     not to call and experience voice mail (and the 
>disgusting IVR), but
>>     rather send an e-mail or try again some other time. So 
>there may be
>>     no expectation to have voice mail in the first place.
>> 
>>      
>> 
>>     If the called party is online and busy, an IM can be sent anyway.
>> 
>>      
>> 
>>     Henry
>> 
>>     
>---------------------------------------------------------------
>---------
>> 
>>     *From:* Roy, Radhika [mailto:[email-masked]]
>>     *Sent:* Sunday, April 03, 2005 9:36 AM
>>     *To:* Brian Rosen; Seamus Gilchrist; Philip Matthews;
>>     [email-masked]
>>     *Cc:* sipping
>>     *Subject:* RE: [Sipping] RE: Comments on
>>     Hi, all:
>>     As Brian said, let us make two separate threads:
>> 
>>      
>> 
>>     1. Distributed voicemail (or other specific services)
>> 
>>     2. P2P SIP system
>> 
>>      
>> 
>>     This is because item 2 can be used in a servcie independent way
>>     (services can used as examples that are applicable to 
>P2P SIP system).
>> 
>>      
>> 
>>     Item 1, it is a specific service and let us examine what are the
>>     ways that this particular service (or other services) 
>can be offered
>>     in a distributed way.
>> 
>>      
>> 
>>     Who knows it may so turn out that P2P SIP system may be the best
>>     ways to do this. Let us prove it before jumping for offering
>>     the voicemail service using P2P SIP system.
>> 
>>      
>> 
>>     Best regards,
>> 
>>     Radhika
>> 
>>      
>> 
>>     
>---------------------------------------------------------------
>---------
>> 
>>     *From:* [email-masked] on behalf of Brian Rosen
>>     *Sent:* Fri 4/1/2005 11:17 AM
>>     *To:* 'Seamus Gilchrist'; 'Philip Matthews'; [email-masked]
>>     *Cc:* 'sipping'
>>     *Subject:* RE: [Sipping] RE: Comments on
>>     I think this part of the discussion has gotten off track.
>> 
>>     In a P2P SIP system, the voicemail "server"; the thing 
>that answers the
>>     phone, plays a greeting and lets you record a message, 
>is a "peer",
>>     that is,
>>     it's a user agent server (UAS).
>> 
>>     The P2P problem is not answering phones, playing 
>messages and recording
>>     messages, it's how does the call get to the endpoint 
>that does that.
>> 
>>     We can, if you want, start a thread on how you might 
>make a completely
>>     distributed voicemail system, but that is a completely 
>different problem
>>     from a P2P SIP system.
>> 
>>     Can we now return to our regularly scheduled program?
>> 
>>     Brian
>> 
>> 
>> 
>---------------------------------------------------------------
>---------
>>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 8 Apr 2005 12:08:17 -0400

Lawrence,

Once they have your SIP address that horse has already left the barn.

I do think the use of ENUM would help.  I do not think this
fully-distributed approach is scalable or very secure.  If it was, DNS
would probably be on these ephemeral supernodes already.  I think reuse
of the existing systems for rendezvous provides a better migration path.
We'll see.

Mike

>From: lconroy [mailto:[email-masked]] 
>Sent: Friday, April 08, 2005 6:55 AM
>Cc: sipping; Arjun Roychowdhury
>Hi folks,
>   Have you guys not heard of identity leakage?
>So ... I call a number, and I get back a working email address.
>Is this wise?
>
>Also, if you want an "open" system to carry multiple URLs, why 
>not just use ENUM? That's what it's there for. It also solves 
>the problem of dialling URLs and remembering more than N phone 
>numbers [i.e. the 10 button problem].
>
>all the best from a puzzled
>   Lawrence
>
>On 7 Apr 2005, at 17:26, Michael Hammer (mhammer) wrote:
>> I was perhaps too terse.  What was already suggested was that the
>> Contact: header should carry the mailto: URI and the UAC 
>upon receipt 
>> of a non-200 response could leave a voice-mail at that 
>address, which 
>> presumable is always online.  While recommending that the 
>user@domain 
>> is identical for both mailto: and sip: URIs, it is not a necessary 
>> condition for this to work.
>>
>> Mike
>>
>>> From: Arjun Roychowdhury [mailto:[email-masked]]
>>> Sent: Thursday, April 07, 2005 12:12 PM
>>> Cc: sipping
>>> On Apr 7, 2005 11:59 AM, Michael Hammer (mhammer) 
><[email-masked]> 
>>> wrote:
>>>> 2) Include a parameter in the INVITE that conveys the 
>mailto, whose 
>>>> value may not match the contact sip:user@domain.
>>>
>>> It could be in an INVITE for the caller to indicate 
>alternate URIs or 
>>> in responses from the callee to indicate alternate URIs. And this 
>>> scheme should be valid for any URI format
>>> (mailto: im: pres: etc )
>>>
>>> regds
>>> arjun
>>>
>>> --
>>> Arjun Roychowdhury
>>>
>---------------------------------------
>lawrence conroy    |tel:+44-1794-833666
>