Subject: [P2Prg] Simple SIP usage scenario

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 7 Mar 2007 07:45:00 -0800

Sorry, the discussions on this I-D were held on the initial Columbia
University p2psip mailing list. They really belong here. 

http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-01.txt  

   This memo discusses the usage scenario of SIP where all the 
   applications reside in the endpoints. This is an alternative to the 
   current usage of SIP where the services reside in the network.  

   The use of SIP where the applications reside in the endpoints is 
   applicable to P2P SIP networks and also to client-server networks. 

   Such an approach reduces the number of required SIP related standards

   (as by spring 2007) from roughly 100 to about 11. 

   Successful IP communications must also include the relevant      
   standards for NAT traversal, some of which are not directly      
   related to SIP and also several standards for security. These      
   standards are included in the simple usage scenario for SIP as well.

There may not be time to have it on the agenda of the SIPPING or P2PSIP
WGs, so any discussions on the lists will be helpful to correctly define
simple SIP usage scenario. One item to decide is whether the simple SIP
usage should be a WG item, in which WG, or an informational individual
contribution.
Please comment.

Here are some of the latest discussions: 

Benny Prijono wrote:

>ask whether it's worth implementing it, since it's not too 
>simple, and especially since without it these doesn't sound too 
>"interesting", or they can be achieved by simpler/other means (for 
>example, by looking at SDP for call hold. About talking to 
>automaton, don't you just know when hearing it?

Implementing UA Capabilities is I believe a useful informational
reference, but should not be mandatory. I would add to Benny's comments
the following observation:

Mobile devices are already predominating and we have to think on what is
doable for mobile devices, as well as for other scenarios where a small
footprint is required.

Proposal: Keep the normative and informational documents separate.
UA Capabilities and RPID belong to the informational part.

What do you think?

Henry

-----Original Message-----
From: Benny Prijono [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 3:40 PM
To: Alan Johnston
Cc: Henry Sinnreich; Spencer Dawkins; [email-masked]
Subject: Re: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS
Systems

Hi Alan,

thanks for your response. Please see mine below.

Alan Johnston wrote:
>> You are right. RFC 3840 indicating UA Capabilities is designed for
>> network based services and need not be used in the simple SIP
scenario.
>>
>>   
> I don't really agree here.  UA capabilities are useful even in 
> peer-to-peer sessions.  For example, isfocus is used to indicate local

> mixing is taking place, +sip.rendering=no indicates that you have been

> put on hold, automaton indicates that you are talking to a machine not
a 
> human, etc.  While caller preference implementation in servers is
very, 
> very complicated, indicating capabilities in feature tags is very easy

> for UAs, in my opinion.

That is true of course, but I think I'm still not too convinced. 
While such indications could be "useful" to know, IMO the main 
strength, or even purpose, of the RFC is to allow UA selection in 
the server based on their capabilities (although please don't quote 
me on this since I only read it briefly). Without this capability in 
the server, then UA implementors such as myself would seriously need 
to ask whether it's worth implementing it, since it's not too 
simple, and especially since without it these doesn't sound too 
"interesting", or they can be achieved by simpler/other means (for 
example, by looking at SDP for call hold. About talking to 
automaton, don't you just know when hearing it?).

I could just be plainly wrong, of course...

  -benny

_______________________________________________
p2p-sip mailing list
[email-masked]
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

Benny,

Thanks for your comments on the draft - see mine below on RFC 3840.

Thanks,
Alan

Henry Sinnreich wrote:
> Benny,
>
> Upon reviewing you excellent suggestions for simple SIP usage, here 
> are the considerations, item by item:
>
>   
>> Since we taking out RFC 2119, what about putting in RFC 3265 (Session

>> Initiation Protocol (SIP)-Specific Event Notification) to fill in the

>> hole since presence depends on this.
>>     
>
> Yes, definitely. RFC 3265 defining SIP events is very useful for all 
> kind of new e2e services combining presence, applications and 
> communications.
>
>   
>> And thinking about other stuffs that are normative, what about RFC
>> 2617 for SIP digest authentication? 
>>     
>
> The SIP digest authentication scheme is already included in RFC 3261.
>
>   
>> And RFC 4566 for SDP?
>>     
>
> SDP is already implied in RFC 3261, so the updated RFC 4566 on SDP is 
> implied as well.
>
>   
>> And is RFC 3840 really essential for endpoint based operations? 
>> Looks like it's more to network based service to me.
>>     
>
> You are right. RFC 3840 indicating UA Capabilities is designed for 
> network based services and need not be used in the simple SIP
scenario.
I don't really agree here.  UA capabilities are useful even in
peer-to-peer sessions.  For example, isfocus is used to indicate local
mixing is taking place, +sip.rendering=no indicates that you have been
put on hold, automaton indicates that you are talking to a machine not a
human, etc.  While caller preference implementation in servers is very,
very complicated, indicating capabilities in feature tags is very easy
for UAs, in my opinion.
>> And don't we want RPID (RFC 4480) for presence? I think we do.
>>     
>
> RFC 4480 for rich presence extensions is useful/informative for 
> developers, but the rich presence RPID may be a nuisance for some and 
> not enough for others. I suggest leaving this to the endpoint 
> developers and to the market.
>
>   
>> Call transfer (RFC 3515, 3420, 3891, 3892, 4488)? Probably not.
>>     
>
> You are right again. Call transfer between UAs can be also done by 
> IM-ing the URL of the caller or with a SIP event package as in RFC 
> 3265 mentioned above.
>
> This brings the new count of SIP standards for the simple SIP scenario

> back to 11, if we don't include the SDP update.
>
> Last but not least, a successful standard must have OS code UA 
> implementations, such as http://sourceforge.net/ and your 
> http://pjsip.org/
>
> Let's hope this reduced number (11 as of now) of SIP standards will 
> make this much easier, compared to the count at http://rfc3261.net/ 
> This applies both the core CS SIP (no network application services) 
> and P2P SIP.
>
> What do all you think?
>
> Thanks again, Henry
>
> -----Original Message-----
> From: Benny Prijono [mailto:[email-masked]]
> Sent: Monday, March 05, 2007 7:31 PM
> To: Henry Sinnreich
> Cc: Spencer Dawkins; [email-masked]
> Subject: Re: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS 
> Systems
>
> Hi Henry,
>
> Henry Sinnreich wrote:
>   
>> Thanks for catching that RFC 2119 need not be counted as a SIP RFC.
>>
>>     
>
> Since we taking out RFC 2119, what about putting in RFC 3265 (Session 
> Initiation Protocol (SIP)-Specific Event Notification) to fill in the 
> hole since presence depends on this.
>
> And thinking about other stuffs that are normative, what about RFC
> 2617 for SIP digest authentication? And RFC 4566 for SDP?
>
> And is RFC 3840 really essential for endpoint based operations? 
> Looks like it's more to network based service to me.
>
> And don't we want RPID (RFC 4480) for presence? I think we do.
>
> Call transfer (RFC 3515, 3420, 3891, 3892, 4488)? Probably not.
>
> Just my 2p.
>
>   -benny
>
>
>
>   

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 20 Mar 2007 02:21:24 -0700

>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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 20 Mar 2007 02:45:09 -0700

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 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Mar 2007 06:57:53 -0400

> http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Mar 2007 05:34:54 -0400

Henry,

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Mar 2007 13:22:44 -0500

Henry,

This is an interesting document. However I think I may not understand 
all the assumptions that are being made.

In particular, there is the assumption that network servers are not 
needed because all services can be provided by endpoints. But a network 
server that terminates a call *is* an endpoint. (Lets keep B2BUAs out of 
this for the moment.)

For instance, take voicemail. I could have voicemail implemented in my 
phone. But that might not work very well if my phone is mobile and isn't 
always online. So I may prefer to have a dedicated voicemail device, 
independent of my phone. I could buy this as a personal device, plug it 
in at home, and go happily about my business. And I guess that would fit 
your model. OTOH, I could contract with some voicemail service provider 
to provide that service for me. It could be functionally equivalent - 
registering with my AOR. Is that bad? There are pros and cons to both 
approaches - I would be happy if both were available.

Similarly with presence. If I have a single device that I use with my 
AOR then it may be sufficient for it to implement presence itself. 
Watchers will realize that if they can't subscribe I must not be 
present. (But this will be inconvenient for watchers - they will have to 
poll to discover when I am again available to accept presence 
subscriptions.) If I have more than one device that I use with the same 
AOR, then having each implement presence presents some problems. SIP 
forking doesn't provide a reliable way for subscribers to establish 
subscriptions to all my endpoints, and the problem is compounded if some 
of my devices go offline frequently. So, as with voicemail, I may find 
it useful to have a separate device that handles my presence. And again, 
it could be an appliance I buy for myself, or a service I subscribe to.

The bottom line for the above: specialized services for an AOR can be 
provided by a user owned/managed appliance, or by a network service. I 
see no reason to distinguish between them as long as they function in 
the same manner.

Regarding callee-caps/callerprefs: I sympathize that this is a complex 
spec. In many cases I think it could be replaced by pervasive use of 
presence. However I don't think access to presence will ever be 
pervasive. Even if everybody maintained presence, I have my doubts that 
it will be made available to everyone who might want to call. The value 
appears when there are multiple devices available for a single AOR, not 
all of which have the same capabilities. The callerprefs usecases RFC 
provides a number of plausible cases. However the key to whether 
callerprefs are useful comes in knowing when/how to incorporate them 
into requests. I don't expect anyone to provide a UI to a caller to 
explicitly construct caller preferences. Rather they are potentially a 
tool for implementing services in endpoints. At the least, some 
consideration is needed for how one reaches the appropriate endpoint 
when there are multiple candidates.

	Thanks,
	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 20 Mar 2007 10:20:59 -0700

Paul,

Thanks for your comments. They are all accurate and valid.

There may be people around however and scenarios where feature servers
are not the best option, and where applications in the endpoints are
preferable, either in a P2P SIP scenario or in a CS scenario with
nothing more that 3261 SIP registrar/proxy/redirect available.

Not all telephony and IM services can be implemented, but looking at
Skype (though it is not the ultimate P2P system), good enough for rich
multimedia and even enterprise applications and good enough to have
roughly 100 times more users than the nearest SIP based VoIP provider
that I know of (Vonage which is my "regular" telephone service, besides
Skype).

The document has to be fixed however and all your comments are welcome,
so the next version will be improved.

Simple SIP is just for one usage scenario - no "network services" beyond
what can be done with RFC 3261 (and some RFCs that complement it), and
the applications all in the endpoints. 
As in the e2e principle on the Internet.

We believe this usage scenario benefits everybody: 
End users, enterprise IT networks, service providers, application
developers and endpoint developers.

Simple SIP however does not exclude all the other usage scenarios
published in the SIPPING WG.

Please everybody, keep the comments and questions coming, they are very
helpful for the next version. I promise to include answers, wherever
pertinent.

Thanks, Henry

Note: Sorry for the duplicate messages to the p2prg, it was my mistake
and has propagated in the discussions. As per the indications of the
SIPPING WG chair, the discussions on this topic will continue only on
the SIPPING list.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 7:23 PM
To: Henry Sinnreich
Cc: [email-masked]; [email-masked]
Subject: [P2Prg] Re: [Sipping] Simple SIP usage scenario

Henry,

this for the moment.)

	Thanks,
	Paul

a
very,

---

From: Eric Burger <[email-masked]>
Date: Wed, 21 Mar 2007 09:36:59 +0100

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.

>>> mobile handset without a proxy/registrar somewhere.

_______________________________________________________________________
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.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Mar 2007 05:45:01 -0400

Eunsoo raises a good point - if we are going to argue for/against 
"network services" then we at least must agree on what a "network 
service" is.

IMO, if something behaves like an endpoint, then we might as well 
consider it an endpoint. A network service must be provided by something 
that behaves differently from an endpoint.

I must say that while I would certainly like to get a free lunch, I 
remain a skeptic about the ability of p2p to provide a free lunch. In 
particular, I am skeptical about depending on strangers with which I 
have no contractual arrangement to provde me with reliable service. I'm 
less concerned with transient services, such as making a call, because I 
can always try another approach if this one doesn't work. But for 
storage of messages I would prefer to have them stored with 
someone/something with an incentive to provide me with reliable service.

	Paul

Eunsoo Shim wrote:
> Just one comment about 'network service' in the below.
> 
> On 3/20/07, *Paul Kyzivat* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     Henry Sinnreich wrote:
>      > Paul,
>      >
>     <http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/>
>      > cucs-044-04.pdf
> 
> It is a  fresh angle of view (to me) about "network service"!
> If we see a network service  as something provided by a third party (not 
> caller, nor callee), then the fundamental P2P services are a kind of 
> "network service".
> Well, I think we used "network service" as something controlled/managed 
> and provisioned by a network owner/service provider with a central 
> server rather than something enabled/provided by end devices (or end 
> points) until now. In the latter sense, the service such as VM storage 
> by the P2P network may not be classified as a "network service".
> 
> 
> Thanks.
> Eunsoo
>      > From: Paul Kyzivat [mailto: [email-masked]
>     <mailto:[email-masked]>]
>      > Cc: [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>      >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>      >> To: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>      >>    From: Paul Kyzivat <[email-masked]
>     <mailto:[email-masked]>>
>      >>
>      >> Sipping mailing
>     list  https://www1.ietf.org/mailman/listinfo/sipping
>     <https://www1.ietf.org/mailman/listinfo/sipping>
>      >> Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>      >> Use [email-masked] <mailto:[email-masked]> for new developments of
>     core SIP
>      >>
>      >> Sipping mailing list  
>     https://www1.ietf.org/mailman/listinfo/sipping
>      >> Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>      >> Use [email-masked] <mailto:[email-masked]> for new developments of
>     core SIP
>      >>
>      >
> 
>     Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>     Use [email-masked] <mailto:[email-masked]> for new developments of core SIP
> 
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 21 Mar 2007 09:58:47 -0700

This is a very useful comment, since it provides the place to argue that
timeouts and any other VM preferences can be handled equally well or
better in the endpoints than in network servers. 

They can be handled better in the endpoints, since endpoint development
does not depend on network infrastructure development and also due to
the simple fact that the accumulated CPU power and storage in the
endpoints by far exceeds the CPU and storage available in network VM
servers.

Last but not least the load and scalability problem is solved by
reversing the roles: The more endpoints, the better the P2P network will
work.

Sorry, it would take a P2P SIP VM design document to show how this is
done, but we will sure have several in due time.

Thanks, Henry

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 7:16 AM
To: Henry Sinnreich; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [P2Prg] RE: [Sipping] Simple SIP usage scenario

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Tuesday, March 20, 2007 4:21 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] Simple SIP usage scenario
> 
> 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.

RFC-3261 doesn't give you any way of knowing what the original request
URI was before the redirection, so you don't know which VM box to
deposit the call into.  This is where RFC-4244 and RFC-4458 come into
play. If the proxy handles the timeout and forwarding it could send the
INVITE over to the VM server using a loose-route to preserve the URI,
but otherwise, you need an extension to SIP to make it happen
consistiently (for instance, the UA that timed out may not be the UA
that was originally called and therefore not the correct VM user to
deposit the call at).

> 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
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core 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: Thu, 22 Mar 2007 13:41:42 -0400

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

> From: Eric Burger [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 4:37 AM
> To: Paul Kyzivat (pkyzivat); Henry Sinnreich
> 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.
> 
> 
> >> This is a good question regarding VM in P2P SIP. It is discussed 
> >> along with other telephony services in more detail in:
> >> 
> >> 
> > 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.
> > 
> server with 
> >>>> a mobile handset without a proxy/registrar somewhere.
> >>> 1. In the case of a VM server no extensions to RFC 3261 
> are required
> >> for
> server with 
> >>> a mobile handset without a proxy/registrar somewhere.
> >>> 
> >>> Dale
> >>> 
> >>> 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
> >>> 
> >>> 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
> >>> 
> >> 
> > 
> > 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.
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 22 Mar 2007 13:46:53 -0400

Define the SP-provided VM hosts as endpoints of the P2P network that are
always on.

It seems that call delivery options/features are applications above the
P2P framework.

Mike

> From: Paul Kyzivat (pkyzivat) 
> Sent: Wednesday, March 21, 2007 5:45 AM
> To: Eunsoo Shim
> Eunsoo raises a good point - if we are going to argue 
> for/against "network services" then we at least must agree on 
> what a "network service" is.
> 
> IMO, if something behaves like an endpoint, then we might as 
> well consider it an endpoint. A network service must be 
> provided by something that behaves differently from an endpoint.
> 
> I must say that while I would certainly like to get a free 
> lunch, I remain a skeptic about the ability of p2p to provide 
> a free lunch. In particular, I am skeptical about depending 
> on strangers with which I have no contractual arrangement to 
> provde me with reliable service. I'm less concerned with 
> transient services, such as making a call, because I can 
> always try another approach if this one doesn't work. But for 
> >     along
> > If we see a network service  as something provided by a third party 
> > (not caller, nor callee), then the fundamental P2P services 
> are a kind 
> > of "network service".
> > Well, I think we used "network service" as something 
> > controlled/managed and provisioned by a network 
> owner/service provider 
> > with a central server rather than something enabled/provided by end 
> > devices (or end
> >      > Your comments below seem to assume that I must have 
> a UA attached
> >     any
> >      >>> It seems like it would be hard to associate a 
> voicemail server
> >     with a
> >      >> 1. In the case of a VM server no extensions to RFC 
> 3261 are required
> >      > for
> >      >> It seems like it would be hard to associate a 
> voicemail server
> >     with a

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 22 Mar 2007 13:41:42 -0400

Mike

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 22 Mar 2007 13:46:53 -0400

Mike

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 23 Mar 2007 00:59:49 -0700

> Define the SP-provided VM hosts as endpoints of the P2P network that
are

There must be several VM hosts so that in spite of churn, the VM
information is still available somewhere and can be found by the peer
protocol.

Henry

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 6:47 PM
To: Paul Kyzivat (pkyzivat); Eunsoo Shim
Cc: [email-masked]; [email-masked]
Subject: [P2Prg] RE: [Sipping] Simple SIP usage scenario

Mike

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 23 Mar 2007 01:49:42 -0700

This is a very good discussion and we will take all this into
consideration when designing the VM for P2P, but we are not there yet.

Sufficient to say the P2P overlay has the storage capability for VM and
SIP can be used to for the session setup and dialog control.

Any comments from the list regarding P2P SIP VM?

Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, March 23, 2007 9:41 AM
To: Henry Sinnreich
Cc: Michael Hammer (mhammer); Eunsoo Shim; [email-masked];
[email-masked]
Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario

> information is still available somewhere and can be found by the peer

I'm not sure I understand. Do you mean several VM hosts/mailbox?

A user who desires a mailbox should be able to decide how he wants to 
get it. He could buy an appliance, plug it in at home, and have it 
register. In this case there clearly won't be multiples - if its down 
its down.

Or he could select a VM SP of his choice, independent of the P2P 
network. Somehow he then enrolls with that SP, after which it will 
generate a registration to his chosen P2P network. In this case the SP 
system will probably want to be fault tolerant and scalable, so there 
may be several VM hosts, but how that is done is an implementation issue

independent of the p2p architecture.

Or I suppose the VM functionality could potentially be "built in" to the

P2P network framework. If it is, then that is the alternative that is 
the best candidate for being called a "network service". I haven't 
thought about this alternative.

	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 23 Mar 2007 09:10:16 -0700

David Oran wrote

>> Sufficient to say the P2P overlay has the storage capability for VM
> In the overlay itself? Is that what you meant to say?

Yes, exactly, in several peer nodes for reliability, in the presence of
churn. Please see:

Henry

-----Original Message-----
From: David R Oran [mailto:[email-masked]] 
Sent: Friday, March 23, 2007 1:08 PM
To: Henry Sinnreich
Cc: Paul Kyzivat; [email-masked]; [email-masked]; Michael Hammer
(mhammer)

On Mar 23, 2007, at 4:49 AM, Henry Sinnreich wrote:

> Sufficient to say the P2P overlay has the storage capability for VM
In the overlay itself? Is that what you meant to say?

> and

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 27 Mar 2007 09:39:40 -0700

David Oran wrote (with regard to voice mail):

>I'm not saying this can't be made to work, only that it isn't
immediately >obvious that it has advantages over a classic application
server >approach.

The answer for VM is "it depends":

There are several commercial P2P IP PBX solutions without any server for
VM or anything else. No doubt the IT organization appreciates just
having to plug in the IP phones and GWY to the PSTN without any
configuration ever for VM or any other PBX feature.

For public P2P SIP networks there are two more scenarios where VM can
reside (and without ever spending one cent on VM servers + IT systems):

- In Cable and DSL service provider networks: The residential router can
act as a voice recorder and P2P can cover the not too frequent cases,
where the router is not in operation, so the data is backed up in other
peer residential gateways (encrypted).

- In mobile networks: The VM can reside in quite stable peers inside the
wireless base station network. The peers in the base station network
need no configuration, etc.

Add to this the conferencing capability coming from p2p application
layer multicast, the SIP e2e control capabilities (for such as
auto-attendant, agent workstation, etc.) and one has to wonder why IT
networks, public VoIP networks and end users should support the huge
cost of hand engineering, testing, monitoring, maintaining server based
VoIP networks. P2P self configuration is nothing less that automation
applied to VoIP, plus the shifting of computing to the endpoints, where
there is an abundance of unused CPU, storage, bandwidth and electricity.

Eric Burger also notes IM changes completely the usage for VM and may
make unnecessary to place calls on VM in the first place.

Michael Hammer makes the important point about encrypting VM: 
In P2P the media will most likely be encrypted and the peers
authenticated as has been mentioned by Kurt Zhu.

Thanks to all for raising these issues. I suspect VM was raised to
support the case for P2P and simple SIP :-)

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-sinnreich-sip-to
ols-01.txt 

We will soon have an update to take the comments into account.

Thanks again, Henry

"P2P will do to VoIP what VoIP did to PSTN" (David Bryan)

-----Original Message-----
From: David R Oran [mailto:[email-masked]] 
Sent: Friday, March 23, 2007 12:10 PM
To: Henry Sinnreich
Cc: Paul Kyzivat; [email-masked]; [email-masked]; Michael Hammer
(mhammer)

> http://www1.cs.columbia.edu/~library/TR-repository/reports/ 
Ok, then what you're proposing is to use a P2P file storage system  
like Oceanstore applied to the content of Voicemail messages. From  
the brief writeup in the Columbia report, I suspect this requires  
recording by the source system and then using the P2P mesh as a  
distributed file system. What I don't see is how the recipient in  
this design knows there's a message waiting unless either the  
originator is also online (a fatal flaw for voicemail applications,  
as others have pointed out), or that there's some additional non-SIP  
event delivery system from the DHT members holding copies of the  
message to the recipient when the recipient is online.

I'm not saying this can't be made to work, only that it isn't  
immediately obvious that it has advantages over a classic application  
server approach.

Dave.

>>>> Define the SP-provided VM hosts as endpoints of the P2P network  
>>>> that
>>> are
>>>> always on.
>>>