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

[Paul Kyzivat <[e-mail]>]

Henry Sinnreich wrote:
> Paul,
> 
>> My real point is how you distinguish between a "network service" 
>> and an endpoint.
> 
> This is an excellent question. Until we find a more rigorous definition,
> I would offer that in the spirit of the Carterfone decision, anything
> that can be attached to the "stupid" broadband network, wired or
> wireless with the logical equivalent of an RJ-11 connector as an
> endpoint. The functions of this endpoint must in no way be constrained
> by the operator. Please see

I'd like to be able to buy a 1-mailbox voicemail server and plug it into 
my home broadband, so that it could connect to the p2psip overlay.

I'd also like to be able to contract from an independent VM provider for 
a VM mailbox. In support of that, I would like to know that the provider 
could just buy lots of those 1-mailbox servers and operate them, or it 
should be able to build a server that supports a million mailboxes and 
have each one register, using a fatter internet pipe. I don't see how 
the p2psip overlay that supports me would know or care about the 
difference, and I hope you don't care either.

> http://www.newamerica.net/publications/policy/wireless_net_neutrality

I've read it, and I am in strong support.

	Paul

> Now we could use some contributors to help translate this in IETF
> protocol language in the spirit of the recent IAB "Reflections on
> Internet Transaprency":
> 
> http://tools.ietf.org/group/iab/draft-iab-net-transparent-04.txt 
> 
> Thanks, Henry
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]] 
> Sent: Wednesday, March 21, 2007 10:11 AM
> To: Henry Sinnreich
> Cc: P2PSIP Mailing List; [e-mail]
> Subject: Re: [P2Prg] Re: [Sipping] Simple SIP usage scenario
> 
> Thanks henry. My real point is how you distinguish between a "network 
> service" and an endpoint. It seems to me that if something acts like an 
> endpoint (in the way it interacts), then it *is* an endpoint for the 
> purposes of p2psip. Whether a server contains many "virtual endpoints" 
> or not, where it sits, and who owns/operates it is irrelevant.
> 
> 	Paul
> 
> Henry Sinnreich wrote:
>> 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:[e-mail]] 
>> Sent: Wednesday, March 07, 2007 7:23 PM
>> To: Henry Sinnreich
>> Cc: [e-mail]; [e-mail]
>> Subject: [P2Prg] 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
>>>
>> _______________________________________________
>> P2prg mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/p2prg
>>
> 

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