Subject: [P2PSIP] Simple SIP usage scenario

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 7 Mar 2007 13:23:28 -0800

Sorry, the discussions on this I-D were held on the initial Columbia
University p2psip mailing list. They really belong in both SIPPING and
P2PSIP for now, until we find a home. 

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:[email-masked]] 
Sent: Tuesday, March 06, 2007 3:40 PM
To: Alan Johnston
Cc: Henry Sinnreich; Spencer Dawkins; [email-masked]
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
[email-masked]
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:[email-masked]]
> Sent: Monday, March 05, 2007 7:31 PM
> To: Henry Sinnreich
> Cc: Spencer Dawkins; [email-masked]
> 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
>
>
>
>   

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