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

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

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

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

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