Subject: [P2Prg] Re: [Sipping] Simple SIP usage scenario

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Mar 2007 08:16:56 -0400

Eric Burger wrote:
> Small matter of engineering: how do I know the e-mail address?  I suppose
> the DHT could have an entry for an e-mail address for multi-media messages.
> If you want the classic, "I'm not here, but send me a message
> asynchronously" behaviour, you would let out your e-mail address.  If you
> want to keep you e-mail address private, then the caller can wait until you
> are both on line.

Yes, it would be necessary to provide a way for the caller to route to 
an email to the callee. There could be conventions or mechanisms to 
obtain that. And of course there should be a way for a callee to prevent 
  this.

> The beauty is there are no surprises for the caller.  In a sense, the called
> party does not care, as they usual problems of long-delayed delivery come
> from the CALLER not knowing that it will take a long time for the message to
> be delivered.  In our scenario here, the caller has the appropriate
> expectations, and act accordingly.

Its quite possible for there to be cases where the caller and callee 
will rarely if ever be online at the same time. A solution that requires 
that seems pretty useless. Such a design would just lead to a market for 
a (network?) service that is online all the time and acts as an 
intermediary between caller and callee. In reality and email server is 
just a standard form of that.

	Paul

	Paul

> On 3/21/07 11:00 AM, "Paul Kyzivat" <[email-masked]> wrote:
> 
>> I think a VM solution that requires the caller and the callee to both be
>> online concurrently for the message to be delivered is a really bad idea.
>>
>> I do think that expecting the caller to record the message and request
>> its delivery solves a lot of problems. The method of delivery to an
>> agent of the callee could be email. It would then be reasonable to
>> expect the callee's agent and the callee to be online concurrently for
>> final delivery to the callee.
>>
>>         Paul
>>
>> Eric Burger wrote:
>>> 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-2004/
>>>>> 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.
>>>
> 
> 
> _______________________________________________________________________
> 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.
> 

_______________________________________________
P2prg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2prg