Subject: [P2PSIP] RE: [Sipping] Simple SIP usage scenario

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 7 Mar 2007 15:30:34 -0800

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.

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

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

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

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

Thanks again and keep them coming,

Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 12:23 PM
To: Henry Sinnreich
Cc: [email-masked]; [email-masked]
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:[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
>>
>>
>>
>>   
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Mar 2007 09:42:46 -0500

> multiple applications as well.

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

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

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

> 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 "network", as long as pay for adequate broadband (necessary for CS

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 20 Mar 2007 10:20:59 -0700

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:[email-masked]] 
Sent: Wednesday, March 07, 2007 7:23 PM
To: Henry Sinnreich
Cc: [email-masked]; [email-masked]
Subject: [P2Prg] Re: [Sipping] Simple SIP usage scenario

Henry,

this for the moment.)

	Thanks,
	Paul

standards
well.
P2PSIP
define
SIP
comments
is
small
local
been
not
easy
(Session
the

a
very,

scenario

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Mar 2007 05:11:00 -0400

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 21 Mar 2007 08:50:27 -0700

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:[email-masked]] 
Sent: Wednesday, March 21, 2007 10:11 AM
To: Henry Sinnreich
Cc: P2PSIP Mailing List; [email-masked]
Subject: Re: [P2Prg] Re: [Sipping] Simple SIP usage scenario

	Paul

local
been
not
easy
(Session
the

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Mar 2007 13:14:41 -0400

> 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

---

From: <[email-masked]>
Date: Wed, 21 Mar 2007 13:27:57 -0500

Henry,

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

john

>From: ext Henry Sinnreich [mailto:[email-masked]] 
>Sent: 21 March, 2007 08:50
>To: Paul Kyzivat
>Cc: [email-masked]; P2PSIP Mailing List
>Subject: RE: [P2Prg] Re: [Sipping] Simple SIP usage scenario
>
>Paul,
>
>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
>
>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":
>
>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" 
>>>> ask whether it's worth implementing it, since it's not too simple, 
>>>> and especially since without it these doesn't sound too 
>>> 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 
>>> This list is for NEW development of the application of SIP Use 
>>> [email-masked] for questions on current sip Use 
>>> [email-masked] for new developments of core SIP
>>>
>> 
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 22 Mar 2007 02:24:07 -0700

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 

Henry

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

Henry,

john