Subject: [Simple] New I-D on presence states for phones

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2003 02:42:14 -0400

Folks,

In case folks havent seen it, I wanted to call your attention to:

http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-simple-pidf-phone-00.txt
http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt
http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html

This draft, written by Jon and myself, defines some PIDF extensions 
for describing phones, including traditional "black" phones, wireless 
phones and enterprise phones. I think these will provide invaluable 
for a device-centric view of a presentity.

Comments and questions welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: [email-masked]
Date: Thu, 17 Jul 2003 15:50:29 +0300

Hi,

I think this draft defines bunch of useful information. However, I would definitely take away the "signal-strength" attribute under the wireless phone state. As already stated in the draft, this information is changing frequently, so I think it is not sensible in the timescale that SIP events work. And even if it would be possible to convey this information, what would it mean in GPRS, WCDMA or WiFi? Is there any use case what any watcher could in _practice_ benefit from this information? 

What might be useful as an addition to "ran" is some more information on the access-link, i.e. that the "downlink capacity class" is ~40 kbps, and "RTT class" is ~500 ms. This _kind_ of information might give watchers some idea what _kind_ of applications/media the device could be able to do at the moment (although you could find that out also through PIDF/prescaps and SDP negotiations). This kind of info is relatively static (in the order of minutes rather than seconds), but still changing. In any case, this would be more valuable than "signal-strength".   

Markus 

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 08 July, 2003 09:42
> To: Simple WG
> Subject: [Simple] New I-D on presence states for phones
> 
> 
> Folks,
> 

Thanks,
Jonathan R.

---

From: "MANSOOR Usama FTRD/DMR/LON" <[email-masked]>
Date: Mon, 21 Jul 2003 11:57:38 +0200

Knowing the link characteristics (bandwidth, delay, etc.) would certainly be a useful thing for mobile networks, for services that adapt to the different constraints. 

What I'd also like to see, in addition to the roaming, is some kind of indication of what time zone you're in. Hopefully this would allow telesales people to know not to call me 3.00 am in the morning asking if I would like buy some double glazing when I'm roaming in a different country :)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 17, 2003 1:50 PM
To: [email-masked]; [email-masked]
Subject: RE: [Simple] New I-D on presence states for phones

Hi,

Markus 

Thanks,
Jonathan R.

---

From: "MANSOOR Usama FTRD/DMR/LON" <[email-masked]>
Date: Tue, 29 Jul 2003 13:18:21 +0200

Hi Ashir,

Thanks for pointing me towards how to obtain the timezone info. Now, with this information, I would like a kind of 'presence state' (apologies if that's the wrong terminology) that shows quickly that I'm available, but, say, 5 hours ahead. So, a presence state that is the timezone. 

- Usama

-----Original Message-----
From: Ashir Ahmed [mailto:[email-masked]]
Sent: Tuesday, July 29, 2003 1:27 AM
To: MANSOOR Usama FTRD/DMR/LON; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Simple] New I-D on presence states for phones

Hi Mansoor,
A location object carries location information (geographic or civil)  of a
device.
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-reqs-03.txt

Time-zone information can be included into the location object as a location
data type or can be calculated locally by the presence server or by the
endpoint.

Ashir

----- Original Message -----
From: "MANSOOR Usama FTRD/DMR/LON" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, July 21, 2003 6:57 PM
Subject: RE: [Simple] New I-D on presence states for phones

Knowing the link characteristics (bandwidth, delay, etc.) would certainly be
a useful thing for mobile networks, for services that adapt to the different
constraints.

What I'd also like to see, in addition to the roaming, is some kind of
indication of what time zone you're in. Hopefully this would allow telesales
people to know not to call me 3.00 am in the morning asking if I would like
buy some double glazing when I'm roaming in a different country :)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 17, 2003 1:50 PM
To: [email-masked]; [email-masked]
Subject: RE: [Simple] New I-D on presence states for phones

Hi,

I think this draft defines bunch of useful information. However, I would
definitely take away the "signal-strength" attribute under the wireless
phone state. As already stated in the draft, this information is changing
frequently, so I think it is not sensible in the timescale that SIP events
work. And even if it would be possible to convey this information, what
would it mean in GPRS, WCDMA or WiFi? Is there any use case what any watcher
could in _practice_ benefit from this information?

What might be useful as an addition to "ran" is some more information on the
access-link, i.e. that the "downlink capacity class" is ~40 kbps, and "RTT
class" is ~500 ms. This _kind_ of information might give watchers some idea
what _kind_ of applications/media the device could be able to do at the
moment (although you could find that out also through PIDF/prescaps and SDP
negotiations). This kind of info is relatively static (in the order of
minutes rather than seconds), but still changing. In any case, this would be
more valuable than "signal-strength".

Markus

Thanks,
Jonathan R.

---

From: "MANSOOR Usama FTRD/DMR/LON" <[email-masked]>
Date: Thu, 31 Jul 2003 13:53:54 +0200

One possible application for signal strength would be if you want to
hand over from Wi-Fi to cellular and back again, and having the handover
triggered according to the signal strength on the two network types. 

Another, I guess, would be knowing whether you had GSM and/or Wi-Fi
coverage, and being able to use the most appropriate codecs for the
bandwidth available (e.g. if you have good enough wi-fi signal strength,
then stream a high bandwidth video, otherwise, if you only have GPRS,
only stream a low bandwidth video). 

I'm not sure whether real people would have to see this info though, it
could just be of use to the element that controls the call. 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, July 30, 2003 10:40 PM
To: Vikas Tandon
Cc: [email-masked]
Subject: Re: [Simple] New I-D on presence states for phones

Generally, I agree that the scope of the draft was too broad, covering 
a bunch of things which probably are outside the scope of presence. 
But, thats the nature of a -00 draft, and the way to get discussion
going.

The reason I had put signal strength in there in the first place was 
that, ultimately, a watcher would know that their call/IM/whatever 
won't succeed if the target has poor signal strength. However, I agree 
with Markus that it really does change too much (and also probably 
nearly impossible to obtain in any accurate or timely way). So, I will 
remove it from the next rev of the document.

The best way to determine what is, and what is out, of scope is for 
people to give examples of the kinds of applications that might need 
each piece of presence data. If you can't think of a presence app that 
needs a piece of data, there is a good chance it should just be 
removed from the spec.

So, here are some thoughts on the motivating apps and some of their 
presence needs:

call state: very useful for rendering to watchers, says alot about 
whether now is a good time to make a call to them. Also useful input 
to other pieces of presence which can be derived from it, such as 
OPEN/CLOSED for voice. I agree that the full call state model is 
perhaps not needed. In particular I cant think of a reason why a 
watcher cares to know ringing vs. in a call. Both are probably the 
same in terms of presence.

registration state: this seems pretty fundamental - no communication 
is possible unless this is true. I think its also really useful to 
render to people, to let them know if the phone is on or off. A change 
in registration state is frequently the trigger for push apps, such as 
a ringback application.

data-state: useful for knowing if a SIP IM will succeed or not - 
clearly not if the data-state is not connected. I dont think its 
useful to render to a user, but applications which want to push 
information to a user probably care.

roaming: I think this is really useful to render to watchers. Its sort 
of really high level geoloc information. Frequently, you want to know 
whether someone is on a trip or not, to decide whether to call them, 
and roaming helps the watcher know that.

visited/home strings: not really sure what these might be used for. 
Seems neat, but perhaps its too much. Anyone have any ideas?

barred: I'm not sure this is usefully different than not registered, 
but I need to think about it.

-Jonathan R.

Vikas Tandon wrote:

> Hi Markus, Alex and SIMPLE experts,
> 
> As rightly pointed out, signal strength can change several times
within
> a second based on the attenuation factors and even what is displayed
on
> the phone is a best-possible view. Having lower signal strength
however
> might not be  a very useful information to the watcher. Additionally
and
> noticeably, we are talking about adding more processing on the client
> side.
> 
> If we were to add some of the phone status attributes, we should look
at
> ones which display what the user wants to be communicated like - I can
> set: My phone is switched off without letting others know that
actually
> I'm on!! 
> 
> These category of information might be a useful information on the
> network side for delivery purpose but not for the watcher, and
moreover
> information of this category as best picked up from the network nodes
> themselves rather than making the client thicker.
> 
> Regards,
> Vikas
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Alex Audu
> Sent: Friday, July 18, 2003 7:49 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Hello,
>>From a user's point of view, I am not sure if "signal strength" is not
a
> valuable information to have. Granted, it may be changing very
> frequently, but you can always limit how often it is updated.
> 
> I am not sure however, if  "signal strength" can be a valid attribute
of
> the state of the phone. It is descriptive, more of the environment the
> phone is in, than the phone itself.
> 
> Regards,
> Alex.
> 
> [email-masked] wrote:
> 
> 
>>Hi,
>>
>>I think this draft defines bunch of useful information. However, I
>>would definitely take away the "signal-strength" attribute under the 
>>wireless phone state. As already stated in the draft, this information
> 
> 
>>is changing frequently, so I think it is not sensible in the timescale
> 
> 
>>that SIP events work. And even if it would be possible to convey this 
>>information, what would it mean in GPRS, WCDMA or WiFi? Is there any 
>>use case what any watcher could in _practice_ benefit from this 
>>information?
>>
>>What might be useful as an addition to "ran" is some more information
>>on the access-link, i.e. that the "downlink capacity class" is ~40 
>>kbps, and "RTT class" is ~500 ms. This _kind_ of information might 
>>give watchers some idea what _kind_ of applications/media the device 
>>could be able to do at the moment (although you could find that out 
>>also through PIDF/prescaps and SDP negotiations). This kind of info is
> 
> 
>>relatively static (in the order of minutes rather than seconds), but 
>>still changing. In any case, this would be more valuable than 
>>"signal-strength".
>>
>>Markus
>>
>>
>>>http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s
>>
>>imple-pidf-phone-00.txt

---

From: [email-masked]
Date: Thu, 31 Jul 2003 10:41:44 -0400

>triggered according to the signal strength on the two network types. 

I strongly hope you are not suggesting handover control based on SIP presence
based signal strength. There are appropriate L2 mechanisms doing this in real-time 
rather well. I do not see this as a real application example.

Dirk

---

From: "MANSOOR Usama FTRD/DMR/LON" <[email-masked]>
Date: Thu, 31 Jul 2003 13:53:54 +0200

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, July 30, 2003 10:40 PM
To: Vikas Tandon
Cc: [email-masked]
Subject: Re: [Simple] New I-D on presence states for phones

-Jonathan R.

within
on
however
and
at
actually
moreover
Of
a
of

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 31 Jul 2003 11:17:09 -0400

I think you are dreaming,

There are TWO networks, and they are not usually under the same
administrative control.  If you have a call up,
to do a handoff, you will need to do it at the SIP level.
It's not something the L2 is going to do.  L2 handoff would
only work if both networks were in the same administrative
domain. 

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, July 31, 2003 10:53 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> [email-masked] wrote:
> 
> Also, comparing signal strengths in the two different 
> networks is rather 
> like comparing apples and oranges...
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 31 Jul 2003 11:17:09 -0400

Brian

---

From: [email-masked]
Date: Thu, 31 Jul 2003 11:24:06 -0400

And for the SIP level handoff, you would use signal strength indications, obtained from 
SIP phone presence information? 

You shouldn't stick to my L2 comment rather than to the doubt I have that 
a SIP event based notification on signal strength would suffice to do handover control.

Dirk

>From: ext Rosen, Brian [mailto:[email-masked]]
>Sent: Thursday, July 31, 2003 11:17 AM
>To: 'Henning Schulzrinne'; Trossen Dirk (NRC/Boston)

---

From: [email-masked]
Date: Thu, 31 Jul 2003 11:24:06 -0400

Dirk

---

From: "MANSOOR Usama FTRD/DMR/LON" <[email-masked]>
Date: Thu, 31 Jul 2003 17:14:27 +0200

Yes, agreed, using it to hand over for proper voice calls, video calls,
etc. is not the best way of doing that. 

What I was thinking of was more for data transfers (e.g. peer-to-peer,
file transfer, one way streaming video, etc.), where it might be better
to use the higher bandwidth wi-fi if you can. In this case the acutal
value of the signal strength is not important, it's whether wi-fi is
available or not. 

But if people think it's an unlikely scenario, then I guess there is no
need for a signal strength attribute. 

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, July 31, 2003 3:53 PM
To: [email-masked]
Cc: MANSOOR Usama FTRD/DMR/LON; [email-masked];

> rather well. I do not see this as a real application example.
Also, comparing signal strengths in the two different networks is rather

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 31 Jul 2003 11:40:02 -0400

I dunno.  It's all in how much work you want to do in the phone.
I'd personally be inclined to have the phone decide, in which
case signal strength may not be very interesting, but YMMV.

I'm not really convinced of the value of signal strength in
presence.  It might be useful, but I doubt it.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, July 31, 2003 11:24 AM
> To: [email-masked]; [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 31 Jul 2003 11:40:02 -0400

Brian

---

From: "MANSOOR Usama FTRD/DMR/LON" <[email-masked]>
Date: Thu, 31 Jul 2003 17:14:27 +0200

---

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Thu, 31 Jul 2003 12:24:28 -0400

Inline [RRR]

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, July 31, 2003 11:17 AM
To: 'Henning Schulzrinne'; [email-masked]
Cc: [email-masked]; [email-masked];

[RRR] Right. When the impact of handoff (i.e., change in attachment) affects the upper application layer (e.g., SIP), more works need to be done in the application layer (e.g., SIP) for mobility management (signaling and media) in addition to the lower layer.

Brian

---

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Thu, 31 Jul 2003 12:24:28 -0400

Inline [RRR]

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, July 31, 2003 11:17 AM
To: 'Henning Schulzrinne'; [email-masked]
Cc: [email-masked]; [email-masked];

Brian