Subject: Re: [Sipping] device-info-01

From: Brijesh Kumar <[email-masked]>
Date: Thu, 11 Nov 2004 16:58:21 -0500

----- Original Message -----
From: Jonathan Rosenberg <[email-masked]>
Date: Thursday, November 11, 2004 9:45 am
Subject: Re: [Sipping] device-info-01

> I think there is an interesting question at the root of this 
> draft. The 
> interesting question is how to manage a "network" where the 
> network 
> includes all of the SIP user agents (and in particular, single 
> user 
> devices like softphones and hardphones). Management, in this 
> context, 
> includes configuration (where things like the config profile are 
> targeted), but also includes fault management, accounting, 
> performance 
> and security management. This draft is targeted roughly in the 
> area of 
> device performance management, and thats a laudable goal.

Hi Jonathan:

As I clarified during our presentation, the purpose of this draft
is to monitor the useful states of a device that are 
relevant for a variety of applications. 
  
For example, I may be interested in knowing the current status
of a camera attached to a user's phone before I start streaming
video to him. Or, I may be interested in monitoring if the user's
device has enough memory left for me to stream a live video, and
then continue monitoring. Also, to know if the speaker is muted 
or not, or the camera is on or of.  I may even want to know if the 
my friend is inside his home in a comfortable environment rather than 
in open in 100 degree heat before streaming a live video to him.  

And, another example is what Dean mentioned - knowing the status of
of a video recorder, and then using that status information go to 
a different recorder to record a video stream.

There are many use cases that will benefit with the abilities 
to learn the device and various type of status information on the 
device.  I have only given examples related to applications that
are in the common knowledge - I know there are a lot many use
cases of similar nature. 

Cheers,

--brijesh 

> 
> However, I think the problem is fairly broad, and would benefit 
> from a 
> top-down look at what really needs to be done here, rather than 
> jumping 
> to an event package or OPTIONS or whatever. The problem is 
> complicated 
> because in many cases, these devices are run and managed by end users.
> 
> -Jonathan R.
> 
> Mahfuz Rahman wrote:
> 
> > Thanks Cullen for making some good comments. My response is as 
> follows:  
> > 
> > OPTIONS method is used to query device capabilities such as 
> supported methods,
> > contnet types, codesc etc.. This draft defines data elements for 
> device profile
> > which is  different from the tags defined for OPTIONS. So if we 
> like to define
> > tags for each of the data elements we have defined in the 
> profile it will be a long
> > list. I am not sure if it is acceptable. Also, as you suggested 
> to include multiple
> > schemas and URLs for a device it would be difficult to represent 
> using OPTIONS unless
> > we allow attachment of a body in the OPTIONS response with the 
> following content type: 
> > application/device-profile+xml. 
> > 
> > I agree with you to add software version and also an optional UUID.
> > 
> > The status part will be extended in the future revision which 
> might include a 
> > common XML format. Currently it describes only how vendor 
> specific status information
> > can be retrieved. 
> > 
> > - mahfuz
> > 
> > -----Original Message-----
> > From: [email-masked] [[email-masked]]On
> > Behalf Of Cullen Jennings
> > Sent: Saturday, November 06, 2004 6:19 PM
> > To: sipping
> > Subject: [Sipping] device-info-01
> > 
> > 
> > Nice draft - few comments ...
> > 
> > As a completely alternative suggestions.... How much of this 
> information can
> > you get by just sending an OPTION request to the device.
> > 
> > I would remove all the discussion of the device status - you 
> don't define
> > anything about how to do it so the discussion does not help.
> > 
> > This reports things that should not change so rate of 
> notifications is very
> > very seldom.
> > 
> > I would add an optional UUID to the profile
> > 
> > You might want to add software version.
> > 
> > I would make the schema URL and name attributes of a schema 
> object so that
> > the device can lists multiple schema that it can support.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> _______________________________________________
> 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
> 

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Nov 2004 19:12:29 -0500

Brijesh,

The more I hear the more I dislike. It sounds like you are trying to 
reinvent presence, but in a very device specific way. The functionality 
you describe can, I believe, be achieved in a much more interoperable 
way by defining new presence attributes which the device may publish, 
and which may be disclosed to you if policy of the owner of the device 
desires you to know it.

	Paul