|
|
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: colin.pons@xxxxxxx [mailto:colin.pons@xxxxxxx]
Sent: Monday, March 26, 2007 7:34 AM
To: Eric Burger; mhammer@xxxxxxxxx; pkyzivat@xxxxxxxxx;
hsinnrei@xxxxxxxxx
Cc: p2prg@xxxxxxxx; sipping@xxxxxxxx
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:eburger@xxxxxxx]
Verzonden: vrijdag 23 maart 2007 9:47
Aan: Michael Hammer (mhammer); Paul Kyzivat; Henry Sinnreich
CC: p2prg@xxxxxxxx; sipping@xxxxxxxx
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)" <mhammer@xxxxxxxxx>
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:eburger@xxxxxxx]
>> Sent: Wednesday, March 21, 2007 4:37 AM
>> To: Paul Kyzivat (pkyzivat); Henry Sinnreich
>> Cc: p2prg@xxxxxxxx; sipping@xxxxxxxx
>> 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" <pkyzivat@xxxxxxxxx> 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:pkyzivat@xxxxxxxxx]
>>>> Sent: Tuesday, March 20, 2007 10:35 AM
>>>> To: Henry Sinnreich
>>>> Cc: Dale.Worley@xxxxxxxxxxx; sipping@xxxxxxxx; p2prg@xxxxxxxx
>>>> 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: Dale.Worley@xxxxxxxxxxx [mailto:Dale.Worley@xxxxxxxxxxx]
>>>>> Sent: Tuesday, March 20, 2007 1:59 AM
>>>>> To: p2prg@xxxxxxxx; sipping@xxxxxxxx
>>>>> Subject: Re: [Sipping] Simple SIP usage scenario
>>>>>
>>>>> From: Paul Kyzivat <pkyzivat@xxxxxxxxx>
>>>>>
>>>>> 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
>>>>> sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use
>>>>> sip@xxxxxxxx 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
>>>>> sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use
>>>>> sip@xxxxxxxx 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
>>> sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use
>>> sip@xxxxxxxx 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
>> sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use
>> sip@xxxxxxxx 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
sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use
sip@xxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
|
|