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

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

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.
 
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
draft-johnston-sipping-p2p-ipcom-01.txt

	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
draft-johnston-sipping-p2p-ipcom-01.txt

	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
draft-johnston-sipping-p2p-ipcom-01.txt

	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

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Apr 2005 13:50:34 -0400

> universally, so assuming it as part of the solution seems like no great 

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
>     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
>     ways that this particular service (or other services) can be offered
>     in a distributed way.
> 
>      
> 
>     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
>     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,
>     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.
> 
> ------------------------------------------------------------------------
>

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 4 Apr 2005 21:07:47 +0300

Paul Kyzivat writes:

 > Given common usage like this, perhaps there should be some 

i support this idea, since i don't think that anyone likes the idea that
email identity is different from voice call identity.  this is big
problem with many of the current voice services, such as skype.

-- juha