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

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

John,

Thanks for the pointer.

>> how you distinguish between a "network service" 
>>and an endpoint 

Yes, "Terminology for Describing Internet Connectivity" is part of it,
and the larger picture is given in RFC2775 and 

 http://tools.ietf.org/group/iab/draft-iab-net-transparent-04.txt  

Henry



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, March 21, 2007 7:28 PM
To: Henry Sinnreich; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [P2PSIP] RE: [P2Prg] Re: [Sipping] Simple SIP usage scenario

Henry,

Does this http://www.ietf.org/rfc/rfc4084.txt?number=4084 come close to
your
thoughts, or do you want something stronger_

john

>-----Original Message-----
>From: ext Henry Sinnreich [mailto:[e-mail]] 
>Sent: 21 March, 2007 08:50
>To: Paul Kyzivat
>Cc: [e-mail]; P2PSIP Mailing List
>Subject: RE: [P2Prg] Re: [Sipping] Simple SIP usage scenario
>
>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
>> 
>
>_______________________________________________
>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

_______________________________________________
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