Subject: RE: [Sipping] Simple SIP usage scenario

From: "Eric Burger" <[email-masked]>
Date: Tue, 10 Apr 2007 12:32:21 -0700

The whole point is the caller gets to chose.  It doesn't matter what the
target user has or subscribes to.  If the target happens to have a voice
message service, great, I can leave a message if I chose.  If the target
doesn't, or I feel like sending an e-mail, I can just do it.  No need
for whacky protocols, architectures, inter-carrier agreements, service
identifiers, etc. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 26, 2007 7:34 AM
To: Eric Burger; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] Simple SIP usage scenario

How would this work? If the callee (or his agent in IM style) are
off-line he is not able to inform the caller. 

The VM concept Works is based on asynchronous transaction, where both
the callee and the caller are in control; the callee is in control by
subscribing to a VM service or implementing a voicemail Application and
the caller is in control by choosing to leave a voicemail.

I agree that the VM experience can be improved where both the caller and
the calle gets to choose how to deliver the message. But my point is how
does the caller know from which options to choose if the callee did not
(or could not because of being off line) inform the caller of the
options? Otherwise I have a system the leaves control solely to the
caller.

Colin Pons
Senior Architect
WSO Innovation Management

-----Oorspronkelijk bericht-----
Van: Eric Burger [mailto:[email-masked]]
Verzonden: vrijdag 23 maart 2007 9:47
Aan: Michael Hammer (mhammer); Paul Kyzivat; Henry Sinnreich
CC: [email-masked]; [email-masked]
Onderwerp: Re: [Sipping] Simple SIP usage scenario

Missing the point:

The called party gets to CHOOSE whether the caller is allowed to send
them an e-mail.  The called party does this by publishing their e-mail
address.
That is like a classic subscription to voice mail.  However, it is
BETTER than classic voice mail, in that if the called party does not
CHOOSE to offer voice mail, there is still the possibility for an
asynchronous IM-style transaction.

Best of all, the caller (you) gets to CHOOSE how to deliver the message.
Note I say CHOOSE, and not "the network does weird stuff that I don't
understand and has a ton of hidden feature interactions that pop out
when I and the called party least expect it."  If I chose to go the
e-mail route, then I know to expect the message to be delivered in a
timely manner, especially if "message-context: voice-message" is set.
Moreover, if I CHOOSE to go the asynchronous route, then my expectation
is appropriately set.

Also, it is important to note that the IM-style method does not
necessarily mean when *I* am on-line.  It can mean when my *agent* is on
line.

On 3/22/07 6:41 PM, "Michael Hammer (mhammer)" <[email-masked]>
wrote:

> Note that doing that (Skype P2P) delays the deliver of the message to 
> when the caller is back online versus when the sender intended the 
> message to be sent and stored, i.e. before the called party is online.
> 
> What if I need to leave an important message before hopping a plane,
and
> the receiver getting it when the plane lands hours later will be after

> the meeting for which the message was intended?
> 
> Not good.  Not the same service as VM.  The whole point is dijoint 
> asynchronous delivery.
> 
> Mike
> 
> 
>> -----Original Message-----
>> From: Eric Burger [mailto:[email-masked]]
>> Sent: Wednesday, March 21, 2007 4:37 AM
>> To: Paul Kyzivat (pkyzivat); Henry Sinnreich
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [Sipping] Simple SIP usage scenario
>> 
>> I would offer the concept of putting the responsibility for "sending"

>> the message on the caller IS EXCELLENT.
>> 
>> It totally removes a ton of hard stuff that VM systems have to do, 
>> like absolutely, positively, delivering the message once the caller 
>> thinks the message was recorded.  Why is this so?  The CALLER knows 
>> if his device is up, down, or sideways.
>>  If he knows the device is not on line or broke, then he has NO 
>> expectations of the message being delivered.
>> 
>> Think of how Skype and Yahoo!IM does delayed delivery: they wait 
>> until both parties are back on-line before sending the message.  Thus

>> this paradigm is NOT going to be foreign to a p2p SIP user.
>> 
>> 
>> On 3/20/07 11:57 AM, "Paul Kyzivat" <[email-masked]> wrote:
>> 
>>> 
>>> 
>>> Henry Sinnreich wrote:
>>>> Paul,
>>>> 
>>>> This is a good question regarding VM in P2P SIP. It is discussed 
>>>> along with other telephony services in more detail in:
>>>> 
>>>> 
>> http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-20
>>>> 04/
>>>> cucs-044-04.pdf
>>> 
>>> Loots to me that this could use a lot more discussion.
>>> 
>>> It seems that there is one fundamental decision to be made:
>> When the
>>> callee is not available, is it the responsibility of the
>> caller or the
>>> callee to capture a message? Then there are secondary
>> questions of how
>>> the message is stored, and how it is conveyed to the recipient.
>>> 
>>> Clearly the current world view is that it is the
>> responsibility of the
>>> callee to handle the capture of the message. If the goal is
>> to change
>>> that assumption, then there will need to be some compatibility 
>>> mechanism put in place for callers that don't do it. To the extent 
>>> that it is the callee that would like to have the message, it may 
>>> always need to be a responsibility of the callee.
>>> 
>>> If it is decided that it is the callee that must provide this, then 
>>> either it is done by the P2P framework or it is not. If not we can 
>>> perhaps ignore it as just another UA, though it might actually be 
>>> provided by a multiuser VM service provider.
>>> 
>>> If this is to be provided by the p2p framework, then it has
>> become a
>>> "network service".
>>> 
>>> Personally, I rather like the idea of making this a
>> requirement of the
>>> caller, and having them email the message. (If the callee wants to 
>>> receive a message it could return a 3xx with email url.)
>> But I don't
>>> know how we get to where we can count on callers doing it.
>>> 
>>> Paul
>>> 
>>>> Henry
>>>> 
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:[email-masked]]
>>>> Sent: Tuesday, March 20, 2007 10:35 AM
>>>> To: Henry Sinnreich
>>>> Cc: [email-masked]; [email-masked]; [email-masked]
>>>> Subject: Re: [Sipping] Simple SIP usage scenario
>>>> 
>>>> Henry,
>>>> 
>>>> Your comments below seem to assume that I must have a UA
>> attached any
>>>> time I might what to send a call to VM. But if all I have
>> are mobile
>>>> devices then that won't be the case. I need a way to have
>> *something*
>>>> that acts for me when I have none of my own devices attached.
>>>> 
>>>> I could satisfy this by contracting for service from something to 
>>>> register on my behalf at all times. If I want that, where
>> does that
>>>> service fit into the p2p framework? Is it internal to it,
>> or external?
>>>> 
>>>> Paul
>>>> 
>>>> Henry Sinnreich wrote:
>>>>>> It seems like it would be hard to associate a voicemail
>> server with
>>>>>> a mobile handset without a proxy/registrar somewhere.
>>>>> This is a good _editorial_ catch.
>>>>> 
>>>>> 1. In the case of a VM server no extensions to RFC 3261
>> are required
>>>> for
>>>>> simple VM. The called UA can redirect the call to VM
>> after a timeout.
>>>>> This must be made clear in the text.
>>>>> 
>>>>> 2. In the case of P2P SIP, the DHT can serve for voice
>> mail storage.
>>>>> 
>>>>> Maybe I am missing something?
>>>>> 
>>>>> Thanks for noting it,
>>>>> 
>>>>> Henry
>>>>> 
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>> Sent: Tuesday, March 20, 2007 1:59 AM
>>>>> To: [email-masked]; [email-masked]
>>>>> Subject: Re: [Sipping] Simple SIP usage scenario
>>>>> 
>>>>>    From: Paul Kyzivat <[email-masked]>
>>>>> 
>>>>>    It could be functionally equivalent - registering with my AOR.
>>>>> 
>>>>> This strikes me as a central issue.  Especially if the real UA is 
>>>>> mobile, you need a high-accessibility "fixed" server to
>> anchor the
>>>>> AOR.  SIP has the machinery to do that well, yes, but
>> that machinery
>>>>> *is* a proxy/registrar.  At that point, I don't see how
>> the "Simple
>>>>> SIP scenario" differs from a PBX, though possibly a PBX with one 
>>>>> extension.
>>>>> 
>>>>> It seems like it would be hard to associate a voicemail
>> server with
>>>>> a mobile handset without a proxy/registrar somewhere.
>>>>> 
>>>>> Dale
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> 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
>> 
>> ______________________________________________________________
>> _________
>> Notice:  This email message, together with any attachments, may 
>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
>> affiliated entities,  that may be confidential,  proprietary,  
>> copyrighted  and/or legally privileged, and is intended solely for 
>> the use of the individual or entity named in this message. If you are

>> not the intended recipient, and have received this message in error, 
>> please immediately return this by email and then delete it.
>> 
>> _______________________________________________
>> 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
>> 
> 

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

_______________________________________________
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

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 11 Apr 2007 00:23:23 +0200

Eric,

What you describe below is already (and always has been) possible. Note that 
in todays world also e-mail has inter-provider agreements, and 
architectures, and wacky protocols, and well-known ports (the UDP/TCP 
equivalent of one aspect of a service identifier).

Voice mail, as it is currently commonly used and known, is a service that 
may kick in when A calls B and B has a voice mail service. One could imagine 
a "straight to voice mail" service controlled by the caller, but usually the 
callee determines when voice mail is offered. When offered, the caller can 
then choose to leave a message "after the beep", or not. Whatever the caller 
does after/besides this (e.g. send e-mail) is irrelevant for the VM service.

My point here is: voice mail works the way it does. It provides the caller 
an extra option to deliver a message, under certain conditions, and provides 
a certain user experience with associated expectations. In no way does it 
(or the architecture or what have you) limit the choices of either the 
caller or the callee with regards to using other means of communication.

One can change (hoping to "improve", subjective) the user experience 
provided by voice mail, but you soon end up with something which is 
essentially a _different_ service. To avoid confusion, it should then no 
longer be called "voice mail"

So: are we really talking about a "voice mail" service for P2P SIP here?

Regards,
Jeroen

Eric Burger wrote:
> does the caller know from which options to choose if the callee did
> not (or could not because of being off line) inform the caller of the
>>>>>> 1. In the case of a VM server no extensions to RFC 3261 are
>>>>>> required for simple VM. The called UA can redirect the call to VM
>>> after a timeout.
>>>> https://www1.ietf.org/mailman/listinfo/sipping This list is for
>>>> NEW development of the application of SIP Use
> contain

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Apr 2007 09:09:55 -0400

Jeroen van Bemmel wrote:
> Eric,
> 
> What you describe below is already (and always has been) possible. Note 
> that in todays world also e-mail has inter-provider agreements, and 
> Voice mail, as it is currently commonly used and known, is a service 
> that may kick in when A calls B and B has a voice mail service. One 
> could imagine a "straight to voice mail" service controlled by the 
> caller, but usually the callee determines when voice mail is offered. 
> When offered, the caller can then choose to leave a message "after the 
> beep", or not. Whatever the caller does after/besides this (e.g. send 
> e-mail) is irrelevant for the VM service.
> 
> My point here is: voice mail works the way it does. It provides the 
> caller an extra option to deliver a message, under certain conditions, 
> and provides a certain user experience with associated expectations. In 
> no way does it (or the architecture or what have you) limit the choices 
> of either the caller or the callee with regards to using other means of 
> communication.

Well, it does work the way it does. :-)

But it does limit other options of both caller and callee. Some examples:

- when caller is an automaton, and doesn't care to leave a message,
   it provides little option. Calling systems use various heuristics
   to figure out if they are talking to VM, but those are unreliable.

- If Alice calls Bob, and Bob is not present, then Bob may wish to
   try forwarding the call to Charlie, and then if Charlie doesn't
   answer route the call to Bob's VM. But this may not work if
   Charlie isn't present but has his own VM system.
   (I know some VM systems try to get around this by selecting the
   VM mailbox of the original target, but that also isn't reliable.
   It only works if both share the same mail server.)

Callerprefs-usecases (RFC 4596) attempted to address some of these 
cases. But that only works if the VM server *registers* with its 
capabilities.

> So: are we really talking about a "voice mail" service for P2P SIP here?

I think that the implementations of VM are sufficiently diverse that we 
can't assume too much in any case.

	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 11 Apr 2007 15:21:04 -0700

>From the user perspective, what matters is a voice message can be left
for later retrieval by the called party. From this perspective VM is VM
no matter what the technology is or how this capability is enhanced by
"surround stuff" to justify more charges.

Eric makes a valid and critical point that presence may induce the
caller to just not make the call in the first place or send an e-mail or
a deferred IM (as it works in Skype). (The advantages are many: Save
your breath and don't talk to machine, save the called party to retrieve
the VM since texting, IM or email are more accurate and understandable).

It also can be argued that for network enabled people VM is just a bad
habit :-)

But P2P can certainly provide a VM that can be sold as such and this is
all that matters to the marketing folks.

My two cents,

Henry

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2007 3:23 PM
To: Eric Burger; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] Simple SIP usage scenario

Eric,

that 

Voice mail, as it is currently commonly used and known, is a service
that 
may kick in when A calls B and B has a voice mail service. One could
imagine 
a "straight to voice mail" service controlled by the caller, but usually
the 
callee determines when voice mail is offered. When offered, the caller
can 
then choose to leave a message "after the beep", or not. Whatever the
caller 
does after/besides this (e.g. send e-mail) is irrelevant for the VM
service.

My point here is: voice mail works the way it does. It provides the
caller 
an extra option to deliver a message, under certain conditions, and
provides 
a certain user experience with associated expectations. In no way does
it 
(or the architecture or what have you) limit the choices of either the 
caller or the callee with regards to using other means of communication.

Regards,
Jeroen

---

From: David R Oran <[email-masked]>
Date: Wed, 11 Apr 2007 20:03:53 -0400

> It also can be argued that for network enabled people VM is just a bad
Yeah the only VM feature I use is a greeting that tells people to  
send me email.