Subject: Re: [dispatch] [sipcore] draft-lavers-sipcore-immersive-capability-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2012 21:12:12 -0500

Glen,

I have a few issues with this, as written:

- My major one is that I don't find good criteria for deciding if 
something should be described as immersive or not. Lacking that, its 
going to be hard to get any kind of useful interoperability out of this.
What section 6 says is:

    Summary of the media feature indicated by this tag:  This feature tag
       indicates that the device provides an immersive audio and/or video
       communication experience.

    Values appropriate for use with this feature tag:  Boolean.

    The feature tag is intended primarily for use in the following
    applications, protocols, services, or negotiation mechanisms:   This
       feature tag is most useful in a communications application for
       describing the capabilities of a device, such as a Telepresence
       system.

    Examples of typical use:  Routing a call to a multimedia
       communication system that can provide an immersive communication
       experience.

Ideally if a UA has identified itself to me as immersive, then there 
ought to be something special about its behavior that I can count on.

The one tangible part of the description is "such as a Telepresence 
system". But it isn't very tangible because its only "such as", and 
"Telepresence system" itself isn't very well defined.

This would be much more tangible if it was tied to some specification, 
such as those in progress in the CLUE wg. There is also the 
specification of immersive in 
draft-ietf-mmusic-traffic-class-for-sdp-00. I presume there might be 
some relationship to it as well.

- My second (minor) point is that when using this tag in Contact headers 
you need to write it as '+sip.immersive'.

	Thanks,
	Paul

On 3/5/12 4:36 PM, Glen Lavers (glavers) wrote:
> Folks,
> I have submitted a new draft to define an 'immersive' media feature tag. The draft is posted at: http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability
>
> The authors would appreciate feedback  and or detailed comments.
>
> Many thanks,
> Glen
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 7 Mar 2012 07:44:19 -0500

My major one is that I don't find good criteria for deciding if something
should be described as immersive or not. Lacking that, its going to be hard
to get any kind of useful interoperability out of this.
...
Ideally if a UA has identified itself to me as immersive, then there ought
to be something special about its behavior that I can count on.
I agree. Two systems that describe themselves as immersive might not be
interoperable at all, so today this preferential call routing might not be
such a good idea.

It would be better to re-evaluate this idea later on, and see if the CLUE
work eliminates the need for it.  (Or maybe Glen should take this to CLUE
for consideration???)

Regards,
Stephen Botzko

On Tue, Mar 6, 2012 at 9:12 PM, Paul Kyzivat <[email-masked]> wrote:

> something should be described as immersive or not. Lacking that, its going
> to be hard to get any kind of useful interoperability out of this.
> What section 6 says is:
>
> Ideally if a UA has identified itself to me as immersive, then there ought
> to be something special about its behavior that I can count on.
>
> such as those in progress in the CLUE wg. There is also the specification
> of immersive in draft-ietf-mmusic-traffic-**class-for-sdp-00. I presume
> there might be some relationship to it as well.
>
>> I have submitted a new draft to define an 'immersive' media feature tag.
>> The draft is posted at: http://tools.ietf.org/html/**
>> draft-lavers-sipcore-**immersive-capability<http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability>
>>
>>
>> ______________________________**_________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>>
>>
> ______________________________**_________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 7 Mar 2012 08:09:46 -0500

Stephen,

The 'immersive' tag is not intended to carry interoperability considerations
with it.  It is just an indicator that the system provides, what it believes
is, an immersive experience.  If two systems cannot communicate properly,
this tag is not going to make any difference one way or the other.  This
proposed tag is like the existing 'video' or 'audio' tags.  Those alone do
not suggest one will achieve any kind of interoperability.

Now, what this tag does provide is the ability for the calling device to
indicate a preference.  This tag can be used following the caller
preferences RFC to help entities in the network route calls to devices that
advertise as having this feature.  It might help to avoid directing a video
call to a desktop phone or it might help the intermediaries in routing calls
over physical links that can provide a better level of service than the
routine audio or video call.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stephen Botzko
Sent: Wednesday, March 07, 2012 7:44 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [dispatch] [sipcore]
draft-lavers-sipcore-immersive-capability-00.txt

Regards,
Stephen Botzko

Glen,

- My major one is that I don't find good criteria for deciding if something
should be described as immersive or not. Lacking that, its going to be hard
to get any kind of useful interoperability out of this.
What section 6 says is:

The one tangible part of the description is "such as a Telepresence system".
But it isn't very tangible because its only "such as", and "Telepresence
system" itself isn't very well defined.

This would be much more tangible if it was tied to some specification, such
as those in progress in the CLUE wg. There is also the specification of
immersive in draft-ietf-mmusic-traffic-class-for-sdp-00. I presume there
might be some relationship to it as well.

- My second (minor) point is that when using this tag in Contact headers you
need to write it as '+sip.immersive'.

       Thanks,
       Paul

Folks,
I have submitted a new draft to define an 'immersive' media feature tag. The
draft is posted at:
http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability

Many thanks,
Glen

sipcore mailing list
[email-masked]

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Mar 2012 10:53:08 -0500

On 3/7/12 8:09 AM, Paul E. Jones wrote:
> Stephen,
>
> The ‘immersive’ tag is not intended to carry interoperability
> considerations with it. It is just an indicator that the system
> provides, what it believes is, an immersive experience. If two systems
> cannot communicate properly, this tag is not going to make any
> difference one way or the other. This proposed tag is like the existing
> ‘video’ or ‘audio’ tags. Those alone do not suggest one will achieve any
> kind of interoperability.

AFAIK the existing video/audio tags mean, respectively, that 
m=video/m=audio lines will be supported in offers and answers. Of course 
there still might not be interop because there are no codecs in common, 
but at least there is the basis for proposing something.

> preferences RFC to help entities in the network route calls to devices
> that advertise as having this feature. It might help to avoid directing
> a video call to a desktop phone or it might help the intermediaries in
> routing calls over physical links that can provide a better level of
> service than the routine audio or video call.

Replace the tag "immersive" with one called "xyzzy". That also provides 
an ability to indicate a preference. But how do I decide if I am 
qualified to offer it?

At the moment the word "immersive" is just an advertising buzz word. We 
need for it to have some tangible semantics.

Is there a difference between "immersive" and "telepresence"?

	Thanks,
	Paul

> Paul
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Stephen Botzko
> *Sent:* Wednesday, March 07, 2012 7:44 AM
> *To:* Paul Kyzivat
> *Cc:* [email-masked]
> *Subject:* Re: [dispatch] [sipcore]
> My major one is that I don't find good criteria for deciding if
> interoperable at all, so today this preferential call routing might not
> be such a good idea.
>
> It would be better to re-evaluate this idea later on, and see if the
> CLUE work eliminates the need for it. (Or maybe Glen should take this to
> CLUE for consideration???)
>
> Regards,
> Stephen Botzko
>
> On Tue, Mar 6, 2012 at 9:12 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Glen,
>
>     I have submitted a new draft to define an 'immersive' media feature
>     tag. The draft is posted at:
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Wed, 07 Mar 2012 09:55:45 -0600

I think the issue that people are having is that call capabilities have 
all been objective in nature to date. A device, by casual examination, 
either does or does not have an audio source and sink. It does or does 
not have a camera and a display. There's no opinion that enters into it.

What you're proposing steps outside this model by adding an inherently 
subjective capability.

The way "immersive" is defined in the current draft ("visual 
conferencing environments that duplicate, as closely as possible, an 
in-person experience") cannot be objectively measured. Reasonable people 
could disagree about whether a 32-inch display is sufficient to convey 
something approaching an "in-person" experience; whether 60 pixels per 
inch is a sufficiently high-definition display; whether G.722 is 
wideband enough to qualify as high-def audio; etc. Even worse: as 
technology advances, these definitions will drift upwards (while the 
older implementations will continue to tag themselves as "immersive").

Functionally, the proposed "immersive" tag is on par with the prospect 
of "expensive," "well-implemented," or "feature-rich" as capabilities.

 From a practical perspective, I agree with Stephen's comments. Wait for 
CLUE to get closer to finishing, and then see whether they've already 
solved this problem for you. If not, come back at that time with a 
feature tag that means something objective like "implements the protocol 
defined by CLUE."

/a

On 3/7/12 7:09 AM, Paul E. Jones wrote:
>
> Stephen,
>
> The 'immersive' tag is not intended to carry interoperability 
> provides, what it believes is, an immersive experience.  If two 
> systems cannot communicate properly, this tag is not going to make any 
> difference one way or the other.  This proposed tag is like the 
> existing 'video' or 'audio' tags.  Those alone do not suggest one will 
> achieve any kind of interoperability.
>
> Now, what this tag does provide is the ability for the calling device 
> to indicate a preference.  This tag can be used following the caller 
> that advertise as having this feature.  It might help to avoid 
> directing a video call to a desktop phone or it might help the 
> intermediaries in routing calls over physical links that can provide a 
> better level of service than the routine audio or video call.
>
> Paul
>
> *From:[email-masked] [mailto:[email-masked]] 
> *On Behalf Of *Stephen Botzko
> I agree. Two systems that describe themselves as immersive might not 
> be interoperable at all, so today this preferential call routing might 
> not be such a good idea.
>
> CLUE work eliminates the need for it.  (Or maybe Glen should take this 
> to CLUE for consideration???)
>
> Regards,
> Stephen Botzko
>
> - My second (minor) point is that when using this tag in Contact 
> headers you need to write it as '+sip.immersive'.
>
>        Thanks,
>        Paul
>
>
>
>
>
>
>     I have submitted a new draft to define an 'immersive' media
>     feature tag. The draft is posted at:

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 7 Mar 2012 11:28:51 -0500

Paul,

> but at least there is the basis for proposing something.

The 'video' and 'audio' tags would suggest that, but 'mobility' (another tag
specified in 3840) does not mean there is a mobility m= line.  As an author
of that document, you know quite well that tags do not equate to m= lines.

> Replace the tag "immersive" with one called "xyzzy". That also provides an
> ability to indicate a preference. But how do I decide if I am qualified to
> offer it?

Because you, the network administrator, or manufacturer configured the
device to do that.  How sets the mobile tag, duplex tag, description tag,
etc?
 
> need for it to have some tangible semantics.

It is a buzzword, but not so vague.  We could define the term in the draft.
We could borrow part of the definition of "Telepresence", which is fitting:

"An interactive audio-visual communications experience between remote
locations, where the users enjoy a strong sense of realism and presence
between all participants."

> Is there a difference between "immersive" and "telepresence"?

Yes.  "Immersive" does not necessarily mean "telepresence".  I think the
above definition goes a bit further than what everyone might consider as
"immersive"; i.e., a telepresence system is immersive, but not all immersive
systems are necessarily telepresence systems.  For example, my son plays
videogames online wearing a wireless headset.  In a dark room, nice screen,
and the headset, he has an immersive experience.  I'd call that system
immersive, but it's not telepresence.

Telepresence is defined more broadly:

"An interactive audio-visual communications experience between remote
locations, where the users enjoy a strong sense of realism and presence
between all participants by optimizing a variety of attributes such as audio
and video quality, eye contact, body language, spatial audio, coordinated
environments and natural image size."

An immersive experience does not necessarily include spatial audio or
include video.  An audio-only system can be immersive.

Net is that I would have all Telepresence systems advertise as "immersive",
but I might also have non-telepresence systems advertise that, too.  This is
intended for caller preferences, it's not intended to signal a different
flavor of SIP, different endpoint behavior, etc.  Its aim is to connect two
endpoints taking user preferences into consideration.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Mar 2012 13:12:49 -0500

> of that document, you know quite well that tags do not equate to m= lines.

And if I was doing it again I would tighten it up. No reason to repeat 
past mistakes.

> device to do that.  How sets the mobile tag, duplex tag, description tag,

So you are suggesting that this will only work right if the same 
administrator controls those setting the tags and those consuming the tags?

> between all participants."

The better you define it the better off we are.

It would be helpful to have some use cases for this. That would guide 
the sort of definition that is needed.

> endpoints taking user preferences into consideration.

So then, once we have some telepresence systems declaring themselves 
immersive, and we have some gaming systems also calling themselves 
immersive, what can we do that we couldn't do without that tagging?

	Thanks,
	Paul