[P2PSIP] RE: [Sipping] Simple SIP usage scenario

["Henry Sinnreich" <[e-mail]>]

Paul, 

Thanks a million for the comments and here are some tentative answers. 
We will use your comments to have a more adequate language in the next
version.

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

Good catch.
The I-D should specify that such as voice mail can be provided on one
end device, like a voice recorder, or in multiple peers of a P2P overlay
acting as a distributed database.
In either case, no extensions to RFC 3261 SIP are necessary, though P2P
database use require PUT and GET messages, but these can serve for
multiple applications as well.

>Similarly with presence. 

Correct. Again, e2e presence can be used or the presence information can
be stored in the p2p overlay, just like voice mail.

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

Yes, there is a reason: Use the properties of the self organizing P2P
SIP network (OPEX) with the development advantages of "simple SIP". This
is very important to service providers, including IT network managers
and for endpoint developers alike.

>However I don't think access to presence will ever be pervasive. 

I remember colleagues saying that presence is the dial tone of the 21st
century. Jonathan Rosenberg has excellent motivation papers and decks on
the value of presence.

>Even if everybody maintained presence, I have my doubts that it will be
>made available to everyone who might want to call. 

Skype allows me to select the entries in my buddy list and who is
authorized to watch my presence and who can call me. This is another
function that can be done very well without an XCAP server (Oops! :->)

>The value appears when there are multiple devices available for a
single >AOR, not all of which have the same capabilities. 

The AOR can also be handled by P2P SIP and I need to specify this with
some references. No need for any other SIP extensions here.

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

This another reminder that we have to better articulate and give an
example here. The bottom line is, I know better my caller preferences
and am free to buy an application of my choice. It's no damn business of
the "network", as long as pay for adequate broadband (necessary for CS
SIP as well anyway).

Thanks again and keep them coming,

Henry


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

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

Henry Sinnreich wrote:
> 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:[e-mail]] 
> Sent: Tuesday, March 06, 2007 3:40 PM
> To: Alan Johnston
> Cc: Henry Sinnreich; Spencer Dawkins; [e-mail]
> 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
> [e-mail]
> 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:[e-mail]]
>> Sent: Monday, March 05, 2007 7:31 PM
>> To: Henry Sinnreich
>> Cc: Spencer Dawkins; [e-mail]
>> 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
>>
>>
>>
>>   
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 

_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip