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

[Paul Kyzivat <[e-mail]>]

Henry Sinnreich wrote:
> 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.

I agree that no extensions are needed for this. Its more a matter of 
perspective.

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

Sorry - I still don't understand the point you are making.

I can buy a VM appliance, plug it in and configure it to register - 
perhaps using p2psip. I gather you think that is fine.

I can also ask a friend who has such an appliance to create a mailbox 
for me on that and have it register. I presume you would find that ok too.

If my friend asks me to pay him for a share of the cost of the 
appliance, is it still ok?

If a thousand, or a million, people all pay the same friend to set up a 
mailbox for them, is that ok?

I think the key principle here is that the mechanism used is *open*, so 
that each user can provide their own device or rent service from a 
supplier of their choice.

>> 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! :->)

I think you missed my point.

It was that I will accept a call (at least let it ring my phone) from 
almost anybody. But I will not *allow* *all* of those people to see my 
presence status.

But I would be happy to have my proxy honor their callerprefs, up to a 
point. If somebody would rather have their call fail than go to my 
voicemail, then I will be happy to honor that - it will save me a VM 
message with no content.

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

I don't understand what you mean. Just that this will be functionally 
like a proxy/registrar, that will fork incoming invites to the multiple 
devices?

If so, then the question arises: do I want all requests parallel forked? 
Or is there a precedence ordering that they should be tried? And can the 
  caller influence that?

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

I don't know if we are agreeing or disagreeing.

I consider my UA to be an agent for me. It carries out policies that 
hopefully represent my preferences, based on inputs at the time and or 
previous configuration.

The "network" is the means by which my UA carries out my policies. Its 
also possible that I don't put all of my policies into a single device. 
Instead, I may have several, and I may expect them to use the network to 
cooperate in carrying out my policies. I also may choose to rent some of 
those devices rather than buy them. And it may be that some of those 
devices are "virtual", in that they are multiplexed with other virtual 
devices on a server somewhere.

When I call somebody, then there are two parties in the call, and each 
have policies. Sometimes those policies will disagree and there will 
have to be some negotiation to find a set of policies that are agreeable 
to both the caller and the callee. Callerprefs helps with that, encoding 
the caller's policies and delivering them to a policy agent for the 
callee. At that point, the agent for the callee is expected to reconcile 
policies as best it can.

In the case of an AOR with multiple user agents registered, there really 
must be some agent for the callee deciding on the appropriate policy for 
choosing among the candidate user agents. That could happen in an 
appliance owned by the callee, or in a server owned by somebody the 
callee has contracted with, or in a p2psip network that the callee has 
connected his user agents to.

	Paul

> 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