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

From: "Glen Lavers (glavers)" <[email-masked]>
Date: Mon, 5 Mar 2012 14:11:56 -0800

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-dispatch-immersive-capability 

The authors would appreciate feedback  and or detailed comments. 

Many thanks,
Glen

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Mar 2012 09:22:04 -0700

This draft does not actually define enough information to decide if a given video phone should consider itself "immersive" or not. 

I don't understand the use cases for this. 

On Mar 5, 2012, at 3:11 PM, Glen Lavers (glavers) wrote:

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

---

From: "Glen Lavers (glavers)" <[email-masked]>
Date: Wed, 7 Mar 2012 10:30:58 -0800

Cullen, Adam, et al.,
Sorry I hadn't confirmed my subscription to dispatch :-/ so I'm only now
getting the emails. I did find them in the archive though and really
mean to respond to the 2 major points that are being brought up. 
1) The definition of immersive and it's subjectivity/objectivity
2) Use cases 

The more criteria exposed the more restrictive it becomes. It wasn't the
intention of the draft to make the definition of immersive restrictive.
Some implementers might consider immersive to be a simple in-person
interaction of an audio and video experience. Other implementers might
require an environment that is replicated on each side of video
communication such that lighting, microphones etc... make the
individuals in the conference feel like they are in the same room. 

We opted for a less restrictive definition. The idea here is to provide
a line, not a fine one, but a notion nonetheless that immersive is a
duplication of an in-person or life-like experience. Above and beyond
that there is no limit, no specific requirement to be met. It is
subjective. Audio/Video quality is subjective. But this isn't just about
media quality it's about business and policy distinctions. 
 
The use cases are for business and policy distinctions. There are valid
policy decisions that implementers would like to make to differentiate a
video experience from an immersive experience such that an immersive
experience is a video experience but not the other way around. This is a
user preference which is of course subjective. But just because it's
subjective does not mean that it's invalid. 

As an enterprise I may want my endpoints to be classified as "immersive"
(this draft) and "video" (RFC 3840) in order to classify an endpoints
support of "video" vs "immersive" video (in-person experience) from
other endpoints and call flows and manage them for policy decisions. One
use case that we noted was for call routing. Another was for admission
control. 

Cheers,
glen

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2012 8:22 AM
> To: Glen Lavers (glavers)
> Cc: [email-masked]
> Subject: Re: [dispatch]
draft-lavers-sipcore-immersive-capability-00.txt
> 
> 
> This draft does not actually define enough information to decide if a
given
> video phone should consider itself "immersive" or not.
> 
> > 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-dispatch-immersive-
> capability

---

From: Adam Roach <[email-masked]>
Date: Wed, 07 Mar 2012 13:53:30 -0600

On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote:
> experience is a video experience but not the other way around.

You're positing that network operators will be willing to make business 
and policy decisions based on the nearly arbitrary, subjective opinions 
of implementors? I think that's a bit naïve.

/a

---

From: "Glen Lavers (glavers)" <[email-masked]>
Date: Wed, 7 Mar 2012 12:27:22 -0800

Sorry I'm using implementer in 2 contexts. What I mean by implementer is network operator, or someone deploying products or systems that use this feature tag. A vendor would add it to their product and provide ways to enable/disable/filter depending on product and usage.
	
If I'm an implementer who has purchased 2 different vendor products that allow for the immersive feature tag. As an implementer I can decide to use the tag or not based on what I know of the products and what I want as a policy decision. If I choose to use it I would know the capabilities of the 2 vendor products and decide for myself if they fit the criteria for this differentiation that I as an implementer/network operator am after. If they do then I can leverage that to make policy decisions, in my network, in call control, wherever or I turn them off or filter them based on the products themselves. 

A vendor adding this media feature tag to their product would hopefully leave it to the implementer to decide when and how to use it for policy.  

Does that better clarify my statements?
-glen

> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2012 11:54 AM
> Cc: Cullen Jennings; [email-masked]
> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt
> 
> > The use cases are for business and policy distinctions. There are
> > valid policy decisions that implementers would like to make to
> > differentiate a video experience from an immersive experience such
> > that an immersive experience is a video experience but not the other way
> around.
> 
> You're positing that network operators will be willing to make business and
> policy decisions based on the nearly arbitrary, subjective opinions of
> implementors? I think that's a bit naïve.
> 
> /a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Mar 2012 16:06:59 -0500

Glen,

I'm still not understanding your use cases.

Is your intent to *register* endpoints with the feature tag, and then 
use callerprefs so that calls prefer (or require) callees that have 
registered the tag?

Or is your intent to pass the tag (on a Contact header) during call 
establishment and use the value to decide whether to accept the call, or 
condition behavior after the call is established?

Either way, it isn't going to work right if everybody doesn't have some 
level of common understanding of what this means. If I'm sitting in a 
telepresence room and calling you, I will be wanting to reach a 
telepresence system, and probably won't be satisfied if I reach your 
game machine. (And what if you have both?)

Also, AFAIK virtually nothing currently supports callerprefs 
(Accept-Contact/Reject-Contact), except 3gpp. But I'll be pleased to 
hear I am wrong about that.

And even if some do, Accept-Contact won't be very useful unless you have 
multiple systems with different capabilities registered to the same AOR. 
(Reject-Contact might be useful to cause calls to fail unless you reach 
a device with the desired capabilities.)

Can you spell out the use case(s) you have in mind for this in 
significantly more detail? (Describe the capabilities and desires of the 
caller, the characteristics and behaviors of the potential callees, and 
the expected outcome in both positive and negative cases.) Also, how the 
UAs come to know what capabilities to register and to prefer - are those 
compiled into the code by the code developer, or are they configured in 
by the deployer?

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 8 Mar 2012 13:44:08 -0500

I'm no expert in this, but the following comments come to mind.  (Not
in priority order.)

The definition of "immersive" (which seems to be synonymous with
"telepresence") is not exact.  That doesn't mean that the term isn't
useful, but it is a warning that there may be no *technological*
distinction.

In regard to admission control, I expect that in both architecture and
practice, networks will want to base admission distinctions on more
detailed information than "immersive".  But maybe I'm wrong; I think
networks have explicitly excluded all "video" media as an admission
policy.  So perhaps a network would refuse admission to any
"immersive" video but allow non-immersive video, in order to conserve
bandwidth.

Please, please, please do not use the word "leverage" to mean "utilize
(to gain a further advantage)".  That word makes it sound like contact
with marketing people has damaged your brain.

In regard to routing decisions, a feature tag is useful if *some*
calls *prefer* the feature and also *some* calls *reject*
(anti-prefer) the feature.  Unless this criterion is true, the
callee's local network (or the callee's behavior) can obtain all
possible benefit by statically prioritizing the alternative UAs.

There are two examples in the draft, but neither is an example of
either stated motivation.  The examples and the motivations should not
be conceptually disjoint.

As Paul notes, the tag would be expressed as "+sip.immersive".

A motivation which seems plausible to me is that a video UA would want
to know if the *other* video UA was operating in an immersive manner
or not, or whether it was capable of doing so, so as to adjust its
behavior.  E.g., if an immersive system is communicating with an
"ordinary" system, it might want to (effectively) crop its transmitted
video signal from "immersive surrounding" to "viewing screen"
dimensions.

The previous paragraph suggests that the set of existing video
conferencing systems might be bimodal, that is, they might fall into
two distinct classes:  small-screen systems that people look at like
televisions, and large-screen systems that surround the viewers, with
no systems of intermediate size.  If that is actually true (and it
might have become true in the market without people explicitly
planning or noticing it), it should be documented, and might be a
justification for labeling videoconferencing systems with a binary
"immersive" attribute.

I suspect that there are important aspects of this subject that the
authors know (at least intuitively) but have not documented, and a
revision of the draft might be very informative.

In any case, it seems to me that this draft falls squarely within the
remit of CLUE.

Dale

---

From: Glen Lavers <[email-masked]>
Date: Fri, 09 Mar 2012 09:17:46 -0800

Hi Paul,
Comments inline

> condition behavior after the call is established?
My example below was to pass the tag in a contact header during call
establishment and use the value for a B2BUA or SBC to determine how to use
it. In the draft we provided a few examples that might be useful but I could
imagine others. What I do see is for the ability for enterprise call
management systems that interoperate like B2BUA's or SBCs to use this header
to drive routing decisions or effectuate admission control prior to SDP
offer (the 2 examples in the draft)

> game machine. (And what if you have both?)
Do you know of any systems that route calls for both gaming and telepresence
like endpoints? In any case I see this feature tag as more applicable to
vendors of telepresence like systems. If the gaming systems wanted to
leverage it then I guess they could. I guess you could imagine having a
gaming system that could do both telepresence conferencing AND immersive
gaming but if they did then I would see using another feature tag as a
further qualifier, perhaps sip.application.

I agree that a common understanding of what immersive means is critical. I
don't think however that it needs to be restrictive or extremely specific.
It's clear that many on this list are confused by our attempt at a broad
definition of telepresence like immersive video. We can try and articulate
this in terms of more specific adjectives however as many have mentioned
there will most always be a level of subjectivity unless we add clear
technical delineations which I'm extremely apprehensive about doing. What is
critical is that the network operator managing these systems is able to
control what uses the tag.

Video is clearly a very broad tag that is both useful and fits all types of
video. What we want here is a delineation of video and we would like that
delineation to be managed by the network operator and really used at their
discretion. Where they are able to decide where the line between video and
immersive video lies in the solution that they manage.

> compiled into the code by the code developer, or are they configured in
I see endpoint vendors coding it into their endpoints and allowing it to be
enabled/disabled. I also see call management systems using it between one
another. 
 
An example of admission control: 2 telepresence like vendor systems that
manage Enterprise calls for both video systems and telepresence like
systems. Prior to ringing an endpoint it is often difficult to determine the
type of call that is being established. Therefore sending an invite with a
contact header that stipulates video for example is useful, especially in
cases where delayed offer is used. This allows the receiving system to make
some decisions. In this example the decision is for admission control. Call
management systems tend to set an upper limit on how much bandwidth any
given call from one endpoint to another can use. So knowing that the call is
video prior to getting an offer is useful to validate that the bandwidth is
allocated for a potential video call prior to ringing the device. The same
is true for fixed telepresence-like systems which tend to use higher
bandwidth limits than generic desktop video. So if an endpoint or a call
management system can use this contact header with immersive it allows the
receiving system to know that the intent of the call is telepresence like
and can associate the correct bandwidth limits and deductions from the
appropriate bandwidth allocations.

As I mentioned it could be useful for any of those 2 systems to know at
invite what type of call they are receiving. That the intent of the call is
for an immersive telepresence like experience if available by the called
party. The calling system could send the invite with a contact header
showing not only immersive but other features as well like audio, video as
the possibilities of the type of call that's possible: Contact:
<sip:[email-masked];transport=tcp>;immersive;video;audio
The receiving system could make any number of assumptions using that
information. If it's doing admission control it could instantiate the invite
at ring as an immersive call deducting from an allocation of bandwidth
reserved for immersive style systems. If that fails it could then try video
or audio-only. If only an immersive tag was available then maybe it would
only try the immersive bandwidth allocation and if that failed it would
simply fail the call. If the called system has bandwidth for the call the it
in-turn signals the call on to the terminating endpoint or UA.

I'll say here that I think that it's very important that the network
operator control the manner in which the tag is used. Therefore it should be
controllable by the network operator. Meaning they should be able to enable
or disable the use of the header on a specific endpoint or determine how
it's used in calls from call management system to system.

I can also see a use case in a similar scenario for SBCs where the SBC can
use the information to determine directionality. If a user "owns" a number
of devices that have varying levels of capabilities. Let's say that Bob owns
a telepresence like system fixed in a room. He also has 2 other devices. A
desktop phone with standard video and a mobile device to receive audio only
calls. If the way to reach any of these devices is the same, meaning that
Bob's number or URI is exactly the same it could be useful for a network
operator to be able to use things like this media feature tag and the base
tags in order to direct the call to specific devices. So when a call comes
from another telepresence like system to Bob only Bob's telepresence
endpoint rings for example. If a call comes with a video and audio tag for
example the call could be routed to all devices. The network operator could
leverage the tag to achieve the requirements of the use cases.

I can imagine other use cases where the called system could also use the
indication to validate the call against a scheduling system specifically for
immersive calls. 

I find that these tags can be useful in a number of scenarios for
interoperation between call management system simply by allowing the use of
the tags. 

>> Sorry I'm using implementer in 2 contexts. What I mean by implementer is
>> network operator, or someone deploying products or systems that use this
>> feature tag. A vendor would add it to their product and provide ways to
>> enable/disable/filter depending on product and usage.
>> 
>> If I'm an implementer who has purchased 2 different vendor products that
>> allow for the immersive feature tag. As an implementer I can decide to use
>> the tag or not based on what I know of the products and what I want as a
>> policy decision. If I choose to use it I would know the capabilities of the 2
>> vendor products and decide for myself if they fit the criteria for this
>> differentiation that I as an implementer/network operator am after. If they
>> do then I can leverage that to make policy decisions, in my network, in call
>> control, wherever or I turn them off or filter them based on the products
>> themselves.
>> 
>> A vendor adding this media feature tag to their product would hopefully leave
>> it to the implementer to decide when and how to use it for policy.
>>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 9 Mar 2012 12:44:39 -0500

Glen,

The intent seems to be to indicate that the flow will be massive, whether
it is immersive or not.

Could you not also have something, say a brain-machine interface that is
remote, but not video,
that could also use a lot of BW?  An potentially still immersive.

If this all boils down to BW, then why not just ask for a BW indicator that
lets SP's to make policy decisions accordingly.
You could then take this indicator and make it a vector with a value.

Mike

---

From: Glen Lavers <[email-masked]>
Date: Fri, 09 Mar 2012 10:32:04 -0800

Paul,
As one of the authors of 3840 do you know of implementations that make use
of 3840? And how they are using it? It would be good to know anecdotally
your intended use cases and how it was actually used.
-glen

On 3/9/12 9:17 AM, "Glen Lavers" <[email-masked]> wrote:

> establishment and use the value for a B2BUA or SBC to determine how to use it.
> In the draft we provided a few examples that might be useful but I could
> to drive routing decisions or effectuate admission control prior to SDP offer
> (the 2 examples in the draft)
> 
>> 
> vendors of telepresence like systems. If the gaming systems wanted to leverage
> it then I guess they could. I guess you could imagine having a gaming system
> that could do both telepresence conferencing AND immersive gaming but if they
> did then I would see using another feature tag as a further qualifier, perhaps
> sip.application. 
> 
> this in terms of more specific adjectives however as many have mentioned there
> will most always be a level of subjectivity unless we add clear technical
> delineations which I'm extremely apprehensive about doing. What is critical is
> that the network operator managing these systems is able to control what uses
> the tag. 
> 
> manage Enterprise calls for both video systems and telepresence like systems.
> Prior to ringing an endpoint it is often difficult to determine the type of
> call that is being established. Therefore sending an invite with a contact
> header that stipulates video for example is useful, especially in cases where
> delayed offer is used. This allows the receiving system to make some
> decisions. In this example the decision is for admission control. Call
> management systems tend to set an upper limit on how much bandwidth any given
> call from one endpoint to another can use. So knowing that the call is video
> prior to getting an offer is useful to validate that the bandwidth is
> allocated for a potential video call prior to ringing the device. The same is
> true for fixed telepresence-like systems which tend to use higher bandwidth
> limits than generic desktop video. So if an endpoint or a call management
> system can use this contact header with immersive it allows the receiving
> system to know that the intent of the call is telepresence like and can
> associate the correct bandwidth limits and deductions from the appropriate
> bandwidth allocations.
> 
> As I mentioned it could be useful for any of those 2 systems to know at invite
> what type of call they are receiving. That the intent of the call is for an
> immersive telepresence like experience if available by the called party. The
> calling system could send the invite with a contact header showing not only
> immersive but other features as well like audio, video as the possibilities of
> the type of call that's possible: Contact:
> reserved for immersive style systems. If that fails it could then try video or
> audio-only. If only an immersive tag was available then maybe it would only
> try the immersive bandwidth allocation and if that failed it would simply fail
> the call. If the called system has bandwidth for the call the it in-turn
> signals the call on to the terminating endpoint or UA.
> 
> I'll say here that I think that it's very important that the network operator
> control the manner in which the tag is used. Therefore it should be
> controllable by the network operator. Meaning they should be able to enable or
> disable the use of the header on a specific endpoint or determine how it's
> used in calls from call management system to system.
> 
> I can also see a use case in a similar scenario for SBCs where the SBC can use
> the information to determine directionality. If a user "owns" a number of
> devices that have varying levels of capabilities. Let's say that Bob owns a
> telepresence like system fixed in a room. He also has 2 other devices. A
> from another telepresence like system to Bob only Bob's telepresence endpoint
> rings for example. If a call comes with a video and audio tag for example the
> call could be routed to all devices. The network operator could leverage the
> tag to achieve the requirements of the use cases.
>

---

From: Glen Lavers <[email-masked]>
Date: Fri, 09 Mar 2012 11:17:23 -0800

Hi Dale,
inline

> useful, but it is a warning that there may be no *technological*
This is why I do not think that this is much of a problem, specifically if
it's the network operator who should have control of when and how to use the
tag. 

> "immersive" video but allow non-immersive video, in order to conserve
I think what would be more useful is simply an indication of call type that
allows the network administrator to associate the call to a BW pool
dedicated for these call types. Today most implementations have 2 pools
audio and video. For a video call most implementations deduct both audio and
video and mark them the same (QoS). For audio only the call is deducted out
of an audio pool and marked differently from video. As video requirements
are raised networks are more and more challenged to admit and provide
preferential treatment of types of video becomes more important. Allow
immersive calls up to W and other video up to X. Direct immersive calls to Y
system and other video to Z system for example.

> with marketing people has damaged your brain.
It's a good word that's been overused for sure. I guess "use to control"
would be better ;-)

> possible benefit by statically prioritizing the alternative UAs.
Well to be more exacting it's not the calls that "prefer" but the network
operator that creates a policy of treatment based on user or admin
requirements. Immersive, video and audio just become variables that the
operator has at their disposal to make policy decisions. After all
configuration of a system is policy. Without those attributes there's no
other way to make those policy decisions unless you have SDP and even then
it's not clear. Dial-plan is one way but if you are doing URI or number
dialing a single number or URI can be associated to a number of endpoints of
varying capabilities.

> As Paul notes, the tag would be expressed as "+sip.immersive".
Thanks, we'll change it.

> video signal from "immersive surrounding" to "viewing screen"
I agree that could be useful. Today telepresence for example does this with
TIP (telepresence interoperability protocol). TIP however is established
endpoint to endpoint and not through the call management system and also is
established after the call has been answered so pre-ring there is really no
other informative manner to know that the call is telepresence. I'm using
telepresence as an example because it was brought up in the beginning but
this could be any telepresence like system that attempts to recreate an
in-person like audio and video experience. Are there other mechanisms that
exist on an invite that declare such capability that are standards based? I
don't know of any. 

> justification for labeling videoconferencing systems with a binary
I tend to agree with your statement about these bi-modal systems. This is
what I'm seeing in the Enterprise as many move to varying sizes of video
resolution up to something that will support viewing a person in life-size.
Management of these systems tend to be differentiated at that point, "tend"
being the key word and my perception of things. I see a lot of enterprises
standardizing on video bit rate for example where you'd see desktop video at
X rate and room-based systems at y rate. And that might be it for a lot of
Enterprises. Some have a dizzying array of endpoints with varying
capabilities but again attempts are made at managing and standardizing the
bit rate across a range of endpoints. Telepresence like systems have their
requirements and tend to set apart and are also in minority when it comes to
systems deployed.

---

From: Glen Lavers <[email-masked]>
Date: Fri, 09 Mar 2012 11:22:30 -0800

BW is just one use case. As I mentioned scheduling and call routing could be
others. BW indicator alone is not a good differentiator. A desktop device
with a good camera could effectively have the same BW requirements for video
as a telepresence like system. A differentiator could be something like QoS
marking and BW pool (CAC). So a BW indicator alone doesn¹t bring this
differentiation. Also what is useful are also all of the other attributes
like audio, video, application. So why go an recreate another mechanism for
all other attributes when it makes enough sense (to me anyway) to simply
extend 3840 with this feature tag?

Although I think other uses could be made for a BW indicator. At least for
systems that ³know² what their max yet do not send early offer on invite.
-glen

On 3/9/12 9:44 AM, "Michael Hammer" <[email-masked]> wrote:

> Glen,
> 
> The intent seems to be to indicate that the flow will be massive, whether it
> is immersive or not.
> 
>> <sip:[email-masked] <mailto:[email-masked]>
>> ;transport=tcp>;immersive;video;audio

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Mar 2012 15:47:25 -0500

> your intended use cases and how it was actually used.

I don't have any actual facts on this, only rumors and impressions.
I don't think I have heard of any implementations of 3841 (the 
callerprefs part), though *maybe* IMS does. (If so it came in after the 
last time I looked at the IMS specs, which was several years ago.)

People do seem to use 3840 in token ways, such as the infocus indicator, 
and IMS has some proprietary tokens that they use.

But I would be more than pleased if people who know of actual uses piped 
up here and told us about them.

	Thanks,
	Paul

> -glen
>
>
> On 3/9/12 9:17 AM, "Glen Lavers"<[email-masked]>  wrote:
>
>> Hi Paul,
>> Comments inline
>>
>>
>> On 3/7/12 1:06 PM, "Paul Kyzivat"<[email-masked]>  wrote:
>>
>>> Glen,
>>>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 9 Mar 2012 16:44:18 -0500

> it's used in calls from call management system to system.

This discussion seems to assume two things which we have long fought against:

1) The carrier controls the user's devices.

2) The carrier knows the detailed intention of the user's
communication.

These points are deeply important.  The IETF protocols are
distinguished from the ITU protocols because they deny these things,
and thus reduce the carriers' ability to exercise price discrimination
(http://en.wikipedia.org/wiki/Price_discrimination).  The resulting
price advantage of the IETF protocols is what caused them to triumph
over the ITU protocols in the market.

Related considerations are discussed in Jonathan Rosenberg's RFC 5897,
"Identification of Communications Services in the Session Initiation
Protocol (SIP)", which is really "Why SIP should not attempt to
identify the 'type of service' being requested in an INVITE."

Once you exclude these things, what the UA can usefully tell the
carrier is the bandwidth (and other QoS) that it needs, or the various
"steps" of QoS that it can usefully fall back to.  As Michael Hammer
notes, the category of "high bandwidth" doesn't necessarily correlate
well with "immersive video system", and IIRC you mentioned that some
desktop video systems demand as much bandwidth as an immersive system.

Looking at what CLUE is addressing, it seems to me that they are
addressing systems with a range of bandwidth demands that is large
enough that a binary "immersive" attribute will not be sufficient.
That is, they will almost necessarily solve the problem of effectively
signaling the bandwidth needs of a dialog.  Why not leverage their
solution?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Mar 2012 16:52:29 -0500

On 3/9/12 2:17 PM, Glen Lavers wrote:
> Hi Dale,
> inline
>
>
> On 3/8/12 10:44 AM, "Worley, Dale R (Dale)"<[email-masked]>  wrote:
>

This is something that deserves a discussion of its own, in a more 
general way.

Is it your thought that all use of feature tags is to be controlled by 
the network operator?

There are multiple aspects to that question:

- what tags a UA *indicates*, in registrations and dialogs.
   Is this driven by the native code of the UA, or by operator config?

- whether a UA *takes action* based on the presence of a particular tag.
   Is this driven by the native code of the UA, or by operator config?

- whether a middle box on the signaling path takes action based on
   the presence of a particular tag.
   Is this driven by the native code of the UA, or by operator config?

- are the answers to the above consistent for all tags,
   or is use of some tags driven by operator config and others
   by native code?

I don't think there can be hard and fast answers to the above, because 
of the wide range of implementations and uses. But some understanding of 
expectations in common cases would be very helpful.

My understanding of the intent of 3840 and 3841 was that individual 
devices would indicate their capabilities in a generic way. (For devices 
with variable capabilities this might depend on what capabilities have 
been enabled on the device. But this would typically be by, or on behalf 
of, the end user of the device.) Action by middle boxs was envisioned to 
be controlled by following the callerprefs inserted by the UAC, with 
limitations possibly imposed by middle box policies. How the UAC decided 
what callerprefs to include was AFAIK not discussed. I certainly didn't 
imagine end users writing callerpref expressions - I envisioned that 
these would be constructed to support various calling features offered 
in the UI of the UAC.

So, as I envision it, a device that has only plain voice phone 
capabilities would know intrinsically that it should indicate voice and 
not video. A device with video capabilities would intrinsically indicate 
voice and video, unless video had explicitly been disabled by the end 
user, or possibly the operator. Presumably a telepresence system would 
indicate voice and video and immersive (or telepresence or whatever it 
ends up being called). Again I suppose some of those could be disabled 
by policy, but to me that would be a weird policy to impose on such a 
device.

> system and other video to Z system for example.

Here you seem to be aligned with the intent of 
draft-ietf-mmusic-traffic-class-for-sdp. But it is a more explicit way 
to get at this.

I think it would be useful for you to huddle with the authors of that 
draft and see if you can reconcile and align the goals and terminology 
of the two drafts.

> requirements.

Note that 3840 and 3841 are about callee *capabilities* and caller 
*preferences*. So the intent was really to support the preferences of 
callers.

And, like option tags, feature tags represent *capabilities*, regardless 
of whether they are used or not. So for instance, a UAC could indicate 
it has audio and video capability, but without specifying any preference 
for video. And the UAS could in response indicate that it has only audio 
capability and all would be well. Or the UAS could indicate video 
*capability*, but the call could still be set up with only audio.

Using the capabilities of the caller to make an admission decision, such 
as to deny the call because there insufficient resources for a video 
call, goes contrary to the intent of 3840/3841. If you wanted to do 
something here, it might be more justified if the UAC had included 
callerprefs *requiring* video support. Better I think to just let the 
call be established without giving it sufficient resources for video, 
and let the call be established without video, or with very low BW video.

> Immersive, video and audio just become variables that the
> it's not clear.

The SDP provides a lot more to go on. But IMO its dicy to make admission 
control decisions based on what you guess the resource requirements of 
the call will be. For instance that just doesn't work if the 
requirements change over the course of the call.

For instance, CLUE is trying to arrange things so a CLUE UA can 
interoperate with a "regular" (e.g. voice, optionally video) UA. So the 
initial call may not require more than ordinary resources. And depending 
on what the UAS is, it may never. If the UAS turns out to be another 
CLUE UA, then a lot of resources may be used.

If I've gone to a telepresence room to call you, I probably do prefer to 
get the resources for a telepresence call. But if those aren't 
available, I would probably prefer to reach you via a plain audio/video 
call, or even a plain audio call, than to not reach you at all. So doing 
admission control based on your expectation that I must have resources 
for telepresence doesn't seem desirable.

> Dial-plan is one way but if you are doing URI or number

> requirements and tend to set apart and are also in minority when it comes to

 From working in CLUE its quite apparent that the BW required for a 
telepresence call won't be a constant, and may vary vastly from one call 
to another. To some extent it may be predictable by the geometry of the 
room - based on the number of cameras and screens. But it also may 
depend on the complexity of the call - what is going on at the other 
end. So I don't think just putting all telepresence systems into a 
single pool will be helpful.

Since I am not in Cisco any longer I can't look up what org you come 
from. But if you aren't part of the telepresence group, then it would 
probably be helpful for you to get together with them to sort out what 
makes sense in the context of what will be coming with CLUE.

>> In any case, it seems to me that this draft falls squarely within the

Speaking as one of the chairs of CLUE, I agree that it seems like the 
right place to address something like this, though it might not fit 
within the current charter. I'd also want to see this brought forward as 
a set of use cases and requirements rather than as a proposed mechanism.

But I also think that if this were to come to CLUE the likely outcome 
would be to postpone it until the existing work on CLUE is more advanced.

Also note that one of the Dispatch chairs (Mary) is also the other chair 
of CLUE, so we should hopefully be able to settle this quickly.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 09 Mar 2012 19:00:47 -0600

>signaling the bandwidth needs of a dialog.  Why not leverage their

color me confused a bit, but this is not a new capability, it is just 
a clarification on an existing capability. Caller Prefs already 
defines the 'audio' and 'video' feature tags, and this draft 
separates 'video' into 'video' and 'immersive'. If the carrier were 
the one to do this, I might agree with you, but the UA is the device 
that installs this feature tag on the Contact header, so, to edit 
your two bullets from above:

1b) The carrier controls the user's devices, but does *not* 
necessarily need to know about this feature tag.

2b) The carrier does not need to know the detailed intention of the 
user's communication since the carrier does not insert this feature 
tag (unless this is a completely SP operated and managed network in 
which the SP provides all call signaling services (i.e., the SIP servers).

Of course, this is my opinion, and I could be wrong.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2012 12:09:04 -0400

> offer (the 2 examples in the draft)

I see two examples - registration and session establishment. But neither 
of them give any insight into the purpose of doing this.

And I see two things mentioned in motivation - admission control and 
selective routing. But both of them are very vague.

Regarding admission control - why would you want to want to base 
admission control on such a vague indication, rather than basing it on 
something that more explicitly indicates the resources required, such as 
the SDP?

Regarding selective routing decisions - it would be helpful to have some 
realistic and tangible examples where the selective routing would 
actually be helpful. Presumably this would be where there are multiple 
registrations for an AOR and one is more suitable than another, and 
where that trumps the recipient's prioritization of the alternatives. We 
have had callerprefs for 10 years or so, and I have yet to hear of a 
single case where it is being used that way.

> like endpoints?

No. I also don't know any systems that have telepresence endpoints and 
something less capable registered to the same AOR.

I only mention gaming systems because those were brought up when I asked 
if immersive is the same as telepresence.

The same argument applies if its just differing telepresence 
implementations that can't interoperate. I would be more convinced if 
the proposal was for a feature tag indicating CLUE support. (But that is 
a bit premature.)

> In any case I see this feature tag as more applicable to

I can see focusing on telepresence, and including game systems if that 
is one of the things they can do.

> control what uses the tag.

IMO the first step is to focus on what you want to accomplish with this, 
and nail down the definitions that are required to accomplish that. 
Telepresence itself isn't all that well defined. A good part of what 
CLUE is doing is arguing out what the essential characteristics are that 
different telepresence systems share. If you are interested in something 
less specific than that, then I think you have the burden to spell it 
out such that different people can look at a system and agree on whether 
it is immersive or not. And you have to show that knowing that is 
helpful in making behavioral decisions.

What I would not like to see is agreement on just a *name* with fuzzy 
semantics, such that its only useful in a closed garden where a side 
agreement narrows the meaning. (E.g. Cisco systems assign meaning 
related to its own implementations, and things work only as long as all 
the systems using the tag adhere to that meaning.)

> video.

AFAIK it remains to be shown whether the sip.video feature tag is 
actually useful. I welcome some examples of how it is being used.

> What we want here is a delineation of video and we would like that

> enabled/disabled. I also see call management systems using it between one

Do you see this configurability as something special for immersive, or 
do you imagine that all the capabilities the endpoint has can likewise 
be configured?

Also, do you see this as a matter of configuring the device to have the 
functionality (e.g. telepresence functionality) and then the reporting 
of the corresponding capability feature tag is implicitly enabled? Or 
are you thinking that the enabling of the feature tag is independent of 
the enabling of the actual functionality?

Again, I'm concerned about interoperability. Its important that each 
endpoint vendor can make the decision whether it is "immersive", and 
that those decisions are consistent across vendors. If that is so, then 
it shouldn't be necessary to enable advertising of the feature tag 
independently of enabling the functionality.

> appropriate bandwidth allocations.

I already discussed this some above.

IMO it could be counterproductive to do admission control based on the 
*capabilities* of the calling device. (I think I mentioned this in some 
other reply.)

It might make more sense to base such a decision on stated callerprefs. 
But even then, what sort of decision would you want to make if the 
caller *prefers* but doesn't *require* video? ISTM that you should 
reject a call for lack of available video bandwidth if the caller 
*requires* video.

In common usage I would expect that most callers with video capability 
might *prefer* but not *require* video. OTOH, I can see how a 
telepresence system might often want to *require* telepresence 
capability and bandwidth as precondition for establishing the call.

BUT, I think the admission control could better be handled by other 
mechanisms, such as RSVP and preconditions during the O/A.

And arguing for this to work around limitations of an offerless INVITE 
seems silly. I am a proponent of offerless INVITES, in cases where they 
make sense. But the point of them is that you are delegating to the 
callee the decision about what sort of call this will be. If you have 
specific requirements about the media in the call, then you should be 
making the initial offer.

> endpoint rings for example.

That won't work very well if Bob is out of the office and only his 
mobile device is accessible to him. Even when calling from your 
telepresence room it will probably be better for the call to ring and 
connect to his phone, so you can talk with him - if only to decide when 
to reschedule.

This would all be quite straightforward (with a suitably smart home 
proxy) if the call included not just caller capabilities, but also 
callerprefs. Then the evaluation of the callerprefs could result in 
prioritizing the endpoints, and serial forking, first to his 
telepresence room, then his video phone, and finally to his mobile.

	Thanks,
	Paul

> If a call comes with a video and audio tag for

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 12 Mar 2012 12:14:37 -0400

> From: James M. Polk [[email-masked]]
> 
> If the carrier were the one to do this, I might agree with you, but
> the UA is the device that installs this feature tag on the Contact
> header, so, to edit your two bullets from above:

I quoted from earlier messages the following sentences:

> > > discretion.

> > > operator control the manner in which the tag is used.

So, independently of the *technical* content of the proposal, its
author seems to envision that its use is intended to be managed by a
network operator.  (Though the "network operator" is probably intended
to include both service providers and enterprise networks.)

Though the phrase "network operator" does not appear in the draft
itself; it may be that the proposal does not depend so much on
network operators.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 12 Mar 2012 12:37:00 -0400

If the purpose of the proposal is to allow UAs to identify themselves
(or rather, their sessions) as to their bandwidth/QoS needs, and the
identification is to pigeonhole the devices into a small number of
"device classes" (which is probably quite common in network
deployments), why don't we define a string-valued "device class" media
feature tag?

This has a number of advantages over the current proposal (which is to
add an additional classification, "immersive" to the current set,
"audio" and "video"):

The classification system can be expanded or subdivided without limit,
without further standards action, to accommodate future needs.

We do not have to specificy what is "immersive" and what is not.

Since the classification is done by the network operator for its own
benefit, the network operator can define classes and assign devices to
them as it sees fit.

Since the "device class" is expected to be defined and set by the
network operator, and only consumed by the network operator, there is
no need to standardize its vaules.

I see that there is already a "class" media feature tag, so let me
propose "devclass":

   Devclass

   Media feature tag name: sip.devclass

   Summary of the media feature indicated by this tag: This feature tag
      indicates the type of device that the UA is.  The value is
      expected to be provisioned into the UA by the network that it is
      attached to.  (The means of provisioning is outside the scope of
      this document.)

   Values appropriate for use with this feature tag: Token with an
      equality relationship.

   The feature tag is intended primarily for use in the following
      applications, protocols, services, or negotiation mechanisms: This
      feature tag is used by the network to which the UA is attached
      to classify the sessions created by the UA for admission
      control, bandwidth allocation, and QoS support.

   Examples of typical use:  Differentiating between devices that
      regularly provide audio, low-resolution video, and
      high-resolution (immersive) video.

Typical uses would be:

   REGISTER sip:example.com SIP/2.0
   From: sip:[email-masked];tag=asd98
   To: sip:[email-masked]
   Call-ID: [email-masked]
   CSeq: 9987 REGISTER
   Max-Forwards: 70
   Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
   Contact: <sip:[email-masked]>;audio;video
>>   ;+sip.devclass="<immersive>"
     ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
   Content-Length: 0

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
   Max-Forwards: 70
   To: Bob <sip:[email-masked]>
   From: Alice <sip:[email-masked]>;tag=1928301774
   Call-ID: [email-masked]
   CSeq: 314159 INVITE
   Contact: <sip:[email-masked]>
>>   ;+sip.devclass="<immersive>"
   Content-Type: application/sdp
   Content-Length: 142

(Assuming I've got the syntax of media feature tags correct.)

Dale

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 12 Mar 2012 21:05:25 -0400

Dale,

Thanks for the thorough review (as usual) :)

> useful, but it is a warning that there may be no *technological*

I personally view "immersive" as an adjective one can apply to Telepresence,
but not all immersive systems are telepresence systems.  For example, my son
has an immersive video gaming experience each time puts his headset on his
head.

While the definition of "immersive" can be debated, I think it is important
to differentiate immersive from Telepresence.  A voice call could certainly
be immersive.  Our intent was to allow this tag to be used as a user
preference in conjunction with audio and video tags to help route calls or
select devices.
 
> policy.  So perhaps a network would refuse admission to any "immersive"
> video but allow non-immersive video, in order to conserve bandwidth.

Admission control was viewed as just one possible usage.  Quite likely, if
it were used for admission control, the tag would be policed somewhere.
Assuming the tag is policed on both ends and both ends seek an immersive
experience, this will have an influence on the admission control decisions.
This draft certainly does not intend to suggest every input that will go
into admission control logic, but this is just one potentially useful code
point.
 
> Please, please, please do not use the word "leverage" to mean "utilize (to
> gain a further advantage)".  That word makes it sound like contact with
> marketing people has damaged your brain.

:-)  I cannot argue with you on that point.
 
> In regard to routing decisions, a feature tag is useful if *some* calls
> *prefer* the feature and also *some* calls *reject*
> (anti-prefer) the feature.  Unless this criterion is true, the callee's
> local network (or the callee's behavior) can obtain all possible benefit
> by statically prioritizing the alternative UAs.

Since it's a caller preferences tag, all things are possible.  A UA could
require tag, reject on the tag, etc.

> There are two examples in the draft, but neither is an example of either
> stated motivation.  The examples and the motivations should not be
> conceptually disjoint.

The REGISTER example wasn't intended to provide an example of motivation of
the tag directly, but it shows how might be used in signaling to facilitate
device selection.  Once the device is registered with this feature tag, then
call routing logic can utilize this information in device selection.

The INVITE example just shows its use, but I agree it does not help to
support the stated motivations.  The intent was just to show its usage.

I would have been happy without the examples, but others felt like the
examples were useful to show where this is signaled; that's about all the
examples are for.
 
> As Paul notes, the tag would be expressed as "+sip.immersive".

That was a point that was not entirely clear to me.  I wish I had seen Paul
K's message, but I seem to lose some of his :-(

Syntactically, the "immersive" tag is allowed per RFC 3261 syntax.  Per RFC
3640, it seemed to suggest +sip was needed, but it was not clear how one can
define new "base" tags that do not require +sip.  So, there is no
possibility for introducing new base tags -- ever?

> A motivation which seems plausible to me is that a video UA would want to
> know if the *other* video UA was operating in an immersive manner or not,
> or whether it was capable of doing so, so as to adjust its behavior.
> E.g., if an immersive system is communicating with an "ordinary" system,
> it might want to (effectively) crop its transmitted video signal from
> "immersive surrounding" to "viewing screen"
> dimensions.

That's certainly possible, yes.

> conferencing systems might be bimodal, that is, they might fall into two
> distinct classes:  small-screen systems that people look at like
> televisions, and large-screen systems that surround the viewers, with no
> systems of intermediate size.  If that is actually true (and it might have
> become true in the market without people explicitly planning or noticing
> it), it should be documented, and might be a justification for labeling
> videoconferencing systems with a binary "immersive" attribute.

I definitely think we will have such systems.  One does not want to limit a
system that can provide a rich experience from communicating with a desktop
video phone or an iPad.  Any communication is better than no communication.
In such cases, I can certainly see that a system might adjust behavior.

The main idea we had in mind (or I did and let the others state their
thoughts) was that a user might have a plurality of callable devices.  I
could use this tag to route calls to preferred devices.  I could tell my SIP
server that during the business day, I prefer to route all "immersive" calls
to my single screen Telepresence system on my desk.  In the evenings, I
might have those routed to my softphone.

Of course, the caller can also indicate preferences: it may not want to
allow the call to go to a softphone.  All of these things are possible with
the caller preferences framework.

> revision of the draft might be very informative.

Reading too much into this can be dangerous.  It's certainly possible to
throw out a lot of ideas for this tag, but at the end of the day it is
nothing but a feature tag.  In RFC 3840, no single tag is discussed at such
length.  As such, I didn't feel like this one should.  It was stated that
"immersive" is subjective and, to some extent, that's true.  An "immersive"
system is what one says it is.  Beyond that, though, the system behavior is
fairly well-defined in RFC 3840 and RFC 3841.
 
> In any case, it seems to me that this draft falls squarely within the

I do have to disagree with you on this point. :-)

If CLUE did or did not exist, it would not change the desire to an immersive
tag.  We're not defining multiple streams, camera positioning, or the
multitude of things people are pouring into "Telepresence".  None of that
makes any sense of an immersive audio call.

This gets back to "what is immersive"?  Like RFC 3840, one can ask "what is
text?"  (That's another feature tag.) Is this instant messaging text?  Or is
this real-time text that is delivered character-at-a-time?  There is also
the "mobility" tag.  Is that a mobile phone?  Is it a laptop with Wi-Fi?  A
tablet?

I'd like to separate the notion of "immersive" from Telepresence, because I
view it as an adjective that is a part of Telepresence.  Nonetheless, it is
an adjective that we would like to use with or without Telepresence and in
conjunction with audio and video feature tags.

Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 13 Mar 2012 00:12:24 -0500

> possibility for introducing new base tags -- ever?

You can define new parameters, sure. But they aren't capability tags without the +sip.xxx syntax. You seem to think you want to define a capability. If that turns out to be the case, you'll need the +sip prefix.

Now, I personally think you have jumped to a broken, semantic-free mechanism to satisfy implied and vaguely defined requirements, rather than taking the more straightforward route of coming to the WG with solid, clear requirements, and soliciting input on reasonable mechanisms for meeting those requirements. The discussion around syntax of capability tags is like arguing over whether the car you've specified should have pin stripes, rather than discussing the broader issue of whether a car is actually the best tool for cooking pancakes.

Your requirements are probably valid, and it would be good to have them stated in a clear and exhaustive fashion. Your proposed mechanism, however, is misguided.

/a

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 13 Mar 2012 03:21:40 -0400

Adam,

The intent was to register a new capability and the registration appears with sip. prepended in the I-D.  What I’m missing is the message apparently sent by Paul K. regarding usage of that new tag in the contact header.  Does it require a +sip. or can we use sip.?  Is sip. stripped or not?  Reading page 7, it seems to suggest that tags that are not the “base tags” (those defined and enumerated on page 7) sip. cannot be stripped and a + sign prepended.  I may not be reading that correctly, thus the reason for the question below.

The broader issue is why we propose the introduction of this feature tag.  We’re not trying to “jump to a broken, semantic-free mechanism.”  The intent is to define a user agent capability and, more specifically, a feature tag.  The intent is to introduce something similar to those defined in RFC 3840.  Just as a device might be mobile, or a device might do video, we wanted something to indicate that a device has an immersive quality.  Why is sip.class defined to indicate that a device is in a business setting or personal setting?  With whatever logic was applied there, I would think specifying that a device is classified as “immersive” or not should apply.

The issue is that the IETF has defined the car (RFC 3840) into which we wish to install a radio, but folks are suggesting that we’re taking the wrong approach because the car isn’t actually a car, but a horse drawn carriage without electrical power and therefore impossible to support a radio.  Or, perhaps RFC 3840 is a defective Pinto that needs to be recalled?

You’re a smart fellow.  You understand the idea behind classifying a device as “immersive”.  There’s no magic to this, one does not need a voluminous document to convey the idea, nor are we trying to invent something that is out in left field that warrants such an elaborate document.  As with all of the other very short registrations appearing in RFC 3840, we merely propose to register a “sip.immersive” tag so that we can know when a device registers that it is an “immersive” device.  When the device calls another device, it can indicate via the Accept-Contact and Reject-Contact headers its preferences for communicating with another device that is classified as “immersive”.

The definition of immersive might be in question;  a portion of the definition for Telepresence could be used.  Telepresence brings with it much more than the immersive quality, as I mentioned before.  We could work to define “immersive” if that was the only concern, but I don’t think that is the issue.

I’m certainly open to suggestions for how this should be accomplished.  If this absolutely does not fit within the RFC 3840 framework, then I can accept the fact that I do not understand the point of RFC 3840.

Paul

From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2012 1:12 AM
To: Paul E. Jones
Cc: Worley, Dale R (Dale); Glen Lavers (glavers); <[email-masked]>
Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt

 

/a

---

From: Michael Hammer <[email-masked]>
Date: Tue, 13 Mar 2012 09:10:56 -0400

A judge once said:  "I can't define pornography, but I can tell when I see
it."
The term immersive seems to be in the same category.

With something so subjective, can you tell me how that helps
interoperability?
ISTM that it will be as useful as the evil bit.

If I notice that it's use/non-use negatively impacts me,
then I change it and get better service, is that cool with you?

Mike

On Mon, Mar 12, 2012 at 9:05 PM, Paul E. Jones <[email-masked]>wrote:

> (to

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2012 11:38:35 -0400

On 3/13/12 3:21 AM, Paul E. Jones wrote:
> Adam,
>
> The intent was to register a new capability and the registration appears
> with sip. prepended in the I-D.  What I’m missing is the message
> apparently sent by Paul K. regarding usage of that new tag in the
> contact header.  Does it require a +sip. or can we use sip.?  Is sip.
> stripped or not?  Reading page 7, it seems to suggest that tags that are
> not the “base tags” (those defined and enumerated on page 7) sip. cannot
> be stripped /and/ a + sign prepended.  I may not be reading that
> correctly, thus the reason for the question below.

I can explain the history and rationale for the naming.

For most of the time while the drafts of callerprefs were evolving, the 
capabilities were a namespace unto themselves, as were the matching 
rules. Somewhere toward the end of the process, I think after it went to 
the IESG, the authors (Jonathan Rosenberg and I) were instructed to 
unify this with the preexisting feature tag mechanism. (IMO this was a 
mistake, buts lets not go there now.)

The feature tag mechanism already had a registry and rules for extending 
it. It also had the notion of sub-trees in the registry. Because the 
semantics of our tags was largely disjoint from the existing tags, it 
was decided to define a new sub-tree (sip.) for sip usage, except for a 
few tags that were perceived to have shared meaning.

We also wanted a way for servers to distinguish feature tags from other 
parameters in Contact headers, so that it could do appropriate 
callerprefs processing even when tags were present that the server 
didn't understand. This led to the "+" prefix to distinguish them.

We would have had all feature tags in Contact headers follow this 
syntax, but by this time the draft had been in the wild for a long time 
and we were concerned about backward compatibility. So we 
"grandfathered" the tags that had been in the draft. But all new usage 
must use the "+" syntax and use the full name of the tag.

> The broader issue is why we propose the introduction of this feature
> tag.  We’re not trying to “jump to a broken, semantic-free mechanism.”
> The intent is to define a user agent capability and, more specifically,
> a feature tag.  The intent is to introduce something similar to those
> defined in RFC 3840.  Just as a device might be mobile, or a device
> might do video, we wanted something to indicate that a device has an
> immersive quality.  Why is sip.class defined to indicate that a device
> is in a business setting or personal setting?  With whatever logic was
> applied there, I would think specifying that a device is classified as
> “immersive” or not should apply.
>
> The issue is that the IETF has defined the car (RFC 3840) into which we
> wish to install a radio, but folks are suggesting that we’re taking the
> wrong approach because the car isn’t actually a car, but a horse drawn
> carriage without electrical power and therefore impossible to support a
> radio.  Or, perhaps RFC 3840 is a defective Pinto that needs to be recalled?
>
> You’re a smart fellow.  You understand the idea behind classifying a
> device as “immersive”.

I'm sure Adam will respond to this, but I also want to respond.
IMO "immersive" is a marketing buzzword. For the purposes here is has no 
clear agreed upon meaning. In this regard it is quite different from 
"audio" or "video". You have stated that something can be immersive even 
though it has no video. Can something be immersive with video and no 
audio? Can something be immersive without either audio or video? 
(Perhaps floating in one of those isolation tanks. At least there you 
are truly immersed.)

Nor is it at all clear what one should do differently after knowing that 
something is immersive.

I suspect there is *something* distinct here worth investigating and 
talking about. But just defining a word whose meaning is in the eye of 
the beholder isn't going to be helpful.

> There’s no magic to this, one does not need a
> voluminous document to convey the idea, nor are we trying to invent
> something that is out in left field that warrants such an elaborate
> document.  As with all of the other very short registrations appearing
> in RFC 3840, we merely propose to register a “sip.immersive” tag so that
> we can know when a device registers that it is an “immersive” device.
> When the device calls another device, it can indicate via the
> Accept-Contact and Reject-Contact headers its preferences for
> communicating with another device that is classified as “immersive”.

The feature tag namespace includes sub-trees that don't require an rfc. 
You can mint a tag in the "u." tree without any process at all. Or you 
can mint a tag in the global ("g.") tree with only expert review.

If you just need a tag for proprietary use (about the only kind I can 
see would work given the fuzzy definitions provided so far) then going 
with the "u." form is probably your best bet.

For instance you could use: u.http://features.cisco.com/immersive

In sip the character set limitations require that to be transformed a 
bit (see 3840, section 5: "Each forward slash in the feature tag is 
converted to a single quote, and each colon are converted to an 
exclamation point"). So you would have something like:

Contact:sip:foo.com;+u.http!''features.cisco.com'immersive

> The definition of immersive might be in question;  a portion of the
> definition for Telepresence could be used.  Telepresence brings with it
> much more than the immersive quality, as I mentioned before.  We could
> work to define “immersive” if that was the only concern, but I don’t
> think that is the issue.

Yes, its a lot of the issue.

> I’m certainly open to suggestions for how this should be accomplished.
> If this absolutely does not fit within the RFC 3840 framework, then I
> can accept the fact that I do not understand the point of RFC 3840.

Whether it fits into the 3840 framework depends upon what you want to do 
with it.

IMO doing admission control based on *capabilities* doesn't fit the 
framework.

	Thanks,
	Paul

> Paul
>
> *From:*Adam Roach [mailto:[email-masked]]
> *Sent:* Tuesday, March 13, 2012 1:12 AM
> *To:* Paul E. Jones
> *Cc:* Worley, Dale R (Dale); Glen Lavers (glavers); <[email-masked]>
> *Subject:* Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt
>
> On Mar 12, 2012, at 20:05, "Paul E. Jones" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> You can define new parameters, sure. But they aren't capability tags
> without the +sip.xxx syntax. You seem to think you want to define a
> capability. If that turns out to be the case, you'll need the +sip prefix.
>
> Now, I personally think you have jumped to a broken, semantic-free
> mechanism to satisfy implied and vaguely defined requirements, rather
> than taking the more straightforward route of coming to the WG with
> solid, clear requirements, and soliciting input on reasonable mechanisms
> for meeting those requirements. The discussion around syntax of
> capability tags is like arguing over whether the car you've specified
> should have pin stripes, rather than discussing the broader issue of
> whether a car is actually the best tool for cooking pancakes.
>
> Your requirements are probably valid, and it would be good to have them
> stated in a clear /and exhaustive/ fashion. Your proposed mechanism,
> however, is misguided.
>
> /a
>
>
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 13 Mar 2012 12:16:52 -0400

> From: Paul E. Jones [[email-masked]]
> 

You'd be surprised how stateless the process is by which I've written
these messages.  If I thought the subject was important, I'd do a
*properly* thorough review of the draft.

> From: Paul E. Jones [[email-masked]]
>

I may or may not be a smart fellow, but I don't understand the idea
behind classifying a device as "immersive".  More exactly, I
understand it as a somewhat fuzzy property that a system may or may
not have, but I don't understand why devices should declare it, or why
a caller would care whether the destination UA had it or not.  

> The intent is to introduce something similar to those defined in RFC 3840.

In this regard, it is very different from "audio" or "video", as those
describe the ability to render particular types of media stream (a
clearly-defined technological difference), and relate to the sensory
modes by which the interlocutors communicate (a clearly-defined user
experience difference).

As I said before, the clear motivation for a feature tag is if some
incoming calls would prefer the destination to have it, and some
incoming calls would prefer the destination to *not* have it.

Glen Lavers has provided some significant motivation based on
bandwidth/QoS considerations.  But in that regard, I think a
generalized "device class" property would be more effective in the
long run, as it would be extensible in whatever way the network
operator wanted.

Dale

---

From: "Glen Lavers (glavers)" <[email-masked]>
Date: Tue, 13 Mar 2012 10:32:55 -0700

Paul, Adam, Dale,
What is the criteria for a media feature tag? Can you define that for
me?

-glen

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Paul Kyzivat
> Sent: Tuesday, March 13, 2012 8:39 AM
> To: [email-masked]
> Subject: Re: [dispatch]
> > The intent was to register a new capability and the registration
> > appears with sip. prepended in the I-D.  What I'm missing is the
> > message apparently sent by Paul K. regarding usage of that new tag
in
> > the contact header.  Does it require a +sip. or can we use sip.?  Is
sip.
> > stripped or not?  Reading page 7, it seems to suggest that tags that
> > are not the "base tags" (those defined and enumerated on page 7)
sip.
> > cannot be stripped /and/ a + sign prepended.  I may not be reading
> > that correctly, thus the reason for the question below.
> 
rules.
> Somewhere toward the end of the process, I think after it went to the
IESG, the
> authors (Jonathan Rosenberg and I) were instructed to unify this with
the
> preexisting feature tag mechanism. (IMO this was a mistake, buts lets
not go
> there now.)
> 
> The feature tag mechanism already had a registry and rules for
extending it. It
> also had the notion of sub-trees in the registry. Because the
semantics of our
> tags was largely disjoint from the existing tags, it was decided to
define a new
> sub-tree (sip.) for sip usage, except for a few tags that were
perceived to have
> shared meaning.
callerprefs
> processing even when tags were present that the server didn't
understand. This
> led to the "+" prefix to distinguish them.
> 
syntax, but
> by this time the draft had been in the wild for a long time and we
were
> concerned about backward compatibility. So we "grandfathered" the tags
that
> had been in the draft. But all new usage must use the "+" syntax and
use the
> full name of the tag.
> > tag.  We're not trying to "jump to a broken, semantic-free
mechanism."
> > The intent is to define a user agent capability and, more
> > specifically, a feature tag.  The intent is to introduce something
> > similar to those defined in RFC 3840.  Just as a device might be
> > mobile, or a device might do video, we wanted something to indicate
> > that a device has an immersive quality.  Why is sip.class defined to
> > indicate that a device is in a business setting or personal setting?
> > With whatever logic was applied there, I would think specifying that
a
> > device is classified as "immersive" or not should apply.
> >
> > The issue is that the IETF has defined the car (RFC 3840) into which
> > we wish to install a radio, but folks are suggesting that we're
taking
> > the wrong approach because the car isn't actually a car, but a horse
> > drawn carriage without electrical power and therefore impossible to
> > support a radio.  Or, perhaps RFC 3840 is a defective Pinto that
needs to be
> recalled?
> >
> > You're a smart fellow.  You understand the idea behind classifying a
> > device as "immersive".
> 
"audio" or
> "video". You have stated that something can be immersive even though
it has
> no video. Can something be immersive with video and no audio? Can
> something be immersive without either audio or video?
are truly
> immersed.)
talking
> about. But just defining a word whose meaning is in the eye of the
beholder
> isn't going to be helpful.
> 
> > There's no magic to this, one does not need a voluminous document to
> > convey the idea, nor are we trying to invent something that is out
in
> > left field that warrants such an elaborate document.  As with all of
> > the other very short registrations appearing in RFC 3840, we merely
> > propose to register a "sip.immersive" tag so that we can know when a
> > device registers that it is an "immersive" device.
> > communicating with another device that is classified as "immersive".
> 
can mint a
> tag in the global ("g.") tree with only expert review.
> 
see would
> work given the fuzzy definitions provided so far) then going with the
"u." form is
> probably your best bet.
bit (see
> 3840, section 5: "Each forward slash in the feature tag is converted
to a single
> quote, and each colon are converted to an exclamation point"). So you
would
> have something like:
> > definition for Telepresence could be used.  Telepresence brings with
> > it much more than the immersive quality, as I mentioned before.  We
> > could work to define "immersive" if that was the only concern, but I
> > don't think that is the issue.
> 
> > I'm certainly open to suggestions for how this should be
accomplished.
framework.
> > *Subject:* Re: [dispatch]
> >     Syntactically, the "immersive" tag is allowed per RFC 3261
syntax.
> >     Per RFC
> >     3640, it seemed to suggest +sip was needed, but it was not clear
how
> >     one can
> > solid, clear requirements, and soliciting input on reasonable
> > mechanisms for meeting those requirements. The discussion around
> > syntax of capability tags is like arguing over whether the car
you've
> > specified should have pin stripes, rather than discussing the
broader
> > issue of whether a car is actually the best tool for cooking
pancakes.
> >
> > Your requirements are probably valid, and it would be good to have
> > them stated in a clear /and exhaustive/ fashion. Your proposed
> > mechanism, however, is misguided.
> >
> > /a
> >
> >
> >

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 13 Mar 2012 14:19:26 -0400

> From: Glen Lavers (glavers) [[email-masked]]
> 

At root, the registry is specified in RFC 3840:

   12.1.  SIP Media Feature Tag Registration Tree

   This specification serves to create a new media feature tag
   registration tree, per the guidelines of Section 3.1.4 of RFC 2506
   [3].  The name of this tree is the "SIP Media Feature Tag
   Registration Tree", and its prefix is "sip.".  It is used for the
   registration of media feature tags that are applicable to the Session
   Initiation Protocol, and whose meaning is only defined within that
   usage.

   The addition of entries into this registry occurs through IETF
   consensus, as defined in RFC 2434 [18].  This requires the
   publication of an RFC that contains the registration.  The
   information required in the registration is identical to the IETF
   tree.  As such, specifications adding entries to the registry should
   use the template provided in Section 3.4 of RFC 2506.  Note that all
   media feature tags registered in the SIP tree will have names with a
   prefix of "sip.".  No leading "+" is used in the registrations in any
   of the media feature tag trees.

RFC 2506 says:

   2.1 Media feature tag purpose

   Media feature tags represent individual and simple characteristics
   related to media capabilities or properties associated with the
   resource to which they are applied.  Examples of such features are:

   * the color depth of the screen on which something is to be displayed
   * the type of paper available in a printer
   * the support of the `floating 5 dimensional tables' feature
   * the fonts which are available to the recipient
   * the capability to display graphical content

   Each media feature tag identifies a single characteristic. Values
   associated with a specific tag must use the data type defined for
   that tag.  The list of allowed data types is presented below, in
   section 2.3.

   Examples of media feature tags with values are:

   * the width of a display in pixels per centimeter represented as an
   integer value.
   * a font available to a recipient, selected from an enumerated list.
   * the version of a protocol composed of integers "i.j.k", defined as
   either a value in an enumerated list or with a defined mapping to
   make the value isomorphic to a subset of integers (e.g. i*100 + j*10
   +k, assuming j<=9 and k<=9).

   Further examples of media feature tags are defined in detail
   elsewhere [4].

   Feature collections may be composed using a number of individual
   feature tags [2]. Composition of feature collections is described
   elsewhere [2].  Examples of feature collections requiring multiple
   media feature tags are:

   * the set of all fonts used by a document
   * the width and height of a display
   * the combination of color depth and resolution a display can support

   This registry presumes the availability of the MIME media type
   registry, and MIME media types MUST NOT be re-registered as media
   feature tags.  Media feature tags which are currently in use by
   individual protocols or applications MAY be registered with this
   registry if they might be applied outside of their current domain.

   The media feature tag namespace is not bound to a particular
   transport protocol or capability exchange mechanism.  The registry is
   limited, however, to feature tags which express a capability or
   preference related to how content is presented.  Feature tags related
   to other axes of negotiation are not appropriate for this registry.
   Capability exchange mechanisms may, of course, be used to express a
   variety of capabilities or preferences.

Which isn't very specific.  I would say that something is an
appropriate media feature tag if it is "simple" (not easily decomposed
into a multiple, orthogonal features) and if it's useful (the other UA
might consider modifying its media stream based on the feature tag
and/or would have a preference for contacting one UA versus another UA
based on the values of the feature tag).

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2012 14:43:50 -0400

>> What is the criteria for a media feature tag?  Can you define that for

Dale pretty much covered it below. Its not very clear. And the fact that 
its merged into the mechanisms and definitions of 2506 isn't 
particularly helpful. If I had it do to again I would want to be more 
specific. Dale's last paragraph is very similar to what I would say.

In full disclosure - 2506 calls for expert review on new additions to 
the global tree. The last expert quit because all the requests he was 
getting were for sip usage (by 3gpp), and he didn't feel qualified. I 
was asked to take over this role. I'm not certain, but I think that was 
approved. But if so I have had no requests. But 2506 doesn't give a lot 
of guidance to the expert about this. (Note that expert review only 
applies to the global ("g.") tree. It doesn't apply to the "sip." tree 
(RFC required) or the "u." tree (no action required).)

One thing I think is important is that the features should be 
independent of one another (orthogonal). Overlapping feature definitions 
will lead to ambiguities in how to tag things. And they need to be well 
specified so that reasonable and informed people will come to the same 
conclusion about whether a tag applies in a given situation.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 13 Mar 2012 17:12:20 -0400

Dale,

> I may or may not be a smart fellow, but I don't understand the idea behind
> classifying a device as "immersive".  More exactly, I understand it as a
> somewhat fuzzy property that a system may or may not have, but I don't
> understand why devices should declare it, or why a caller would care
> whether the destination UA had it or not.

Our expectation was that a user, and more likely a system administrator,
will "declare" that a device is "immersive" or not.  That becomes
subjective, perhaps, but that is what the user preferred.  Along with that
preference, the system would be configured to have or not have a preference
or requirement to establish a call to another device that advertises the
same property.  We viewed this as similar to a user wanting to place a call
to a text-enabled device.  There's no value for a deaf person connecting to
an audio-only device.  In the same spirit, we wanted to allow a user to
indicate a preferred device.

The meaning of "immersive" may be considered subjective, but the logic
followed is clear.  At least it appears so reading the RFCs on caller
preferences.
 
> clearly-defined technological difference), and relate to the sensory modes
> by which the interlocutors communicate (a clearly-defined user experience
> difference).

I understand that video is a "thing" you can point your finger at and
identify, whereas immersive is not.  However, what is "mobile"?  What is
"data"?  I'd argue that "data" is equally as vague.  Still, it is a property
one can define and use.
 
> incoming calls would prefer the destination to have it, and some incoming
> calls would prefer the destination to *not* have it.

How is this not possible with RFC 3841 and with this draft?

> bandwidth/QoS considerations.  But in that regard, I think a generalized
> "device class" property would be more effective in the long run, as it
> would be extensible in whatever way the network operator wanted.

If that's the preferred way to solve the problem, I have no objection.  I
can see how a device might have any number of such properties, including
screen resolution, stereo sound, have a recording function, etc.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 13 Mar 2012 17:14:59 -0400

Mike,

Interoperability is in terms of "do you support this capability"?  The
answer is either yes or no.  The declaration that a device is immersive
might be subjective, but the use is not.

If I indicate in my INVITE when I call you that I want to reject any device
on your end that does not advertise itself as immersive and you have no such
devices, the call fails.  Likewise, if you have one that advertises the
capability, it connects to that one.

Paul

From: Michael Hammer [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2012 9:11 AM
To: Paul E. Jones
Cc: Worley, Dale R (Dale); Glen Lavers (glavers); [email-masked]
Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt

Mike

On Mon, Mar 12, 2012 at 9:05 PM, Paul E. Jones <[email-masked]>
wrote:

Dale,

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2012 17:29:46 -0400

> indicate a preferred device.

To work as you describe, your administrator will have to be configuring 
both ends: the devices that declare the capability and the devices that 
express a preference for it. Hence it becomes an entirely proprietary 
mechanism, and there is no point in standardizing the name of the tag.

If you want to have a tag that you can configure as you wish, I already 
suggested using a "u." tag. You need nothing from the IETF to do that.

> "data"?  I'd argue that "data" is equally as vague.  Still, it is a property

I'm not going to defend everything that's there. We learn from our mistakes.

The "data" tag is there as a parallel to video and audio - namely top 
level mime types. (I forget - is "application" there too?) But I agree 
that the data tag isn't really useful for anything.

> How is this not possible with RFC 3841 and with this draft?

We are talking about a *standard* here.
With what you are describing there is nothing *standard* that I can do 
with this tag.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 13 Mar 2012 17:33:05 -0500

> up here and told us about them.

This discussion prompted those of us in the SIP Forum's FoIP Task Group 
to change our plans and start working on proposing a "+sip.fax" feature 
tag, intended for use by carriers who need to route calls differently if 
the calling endpoint is FAX-capable (which will more than likely mean 
the purpose of the call is to complete a FAX transaction).

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2012 20:24:34 -0400

> the purpose of the call is to complete a FAX transaction).

I've already said it a couple of times in this thread, but I'll say it 
again:

Routing to a target based on the *capabilities* of the caller is ill 
conceived. Those capabilities don't equate to what the caller intends to do.

Routing based on caller *preferences* however makes perfect sense. But 
then you should actually implement 3841 to do it.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 14 Mar 2012 08:24:44 -0500

> then you should actually implement 3841 to do it.

In this case, the purpose isn't target selection, it's mid-path network 
element selection (carriers who need to send calls through different 
paths if the call is likely to use T.38), although I doubt that 
distinction matters much for your argument :-)

The target does not change, but the network path in between the source 
and target uses this information to ensure that the network can support 
what the call could (is likely) to need in order to be successful.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Mar 2012 10:12:09 -0400

> what the call could (is likely) to need in order to be successful.

Indicating capability doesn't even imply "is likely to use". Any phone 
capable of handling video could potentially support fax, and so might 
advertise that capability, even though the likelihood of doing so on any 
call may be slim. (There might be millions of phones that declare this 
capability and never use it. So making any resource decisions based on 
this could be unwise.

Conversely, *not* indicating the capability is no guarantee that the 
feature won't be used in the course of the call.

Or are you suggesting that the "network" impose a restriction that every 
feature that *might* be desired in the course of the call be declared at 
the beginning of the call?

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 14 Mar 2012 12:02:05 -0400

> capability and never use it. So making any resource decisions based on

But fax is an obnoxious special case:

Fax machines start the communication as an ordinary voice connection,
then switch to fax mode.  The result is that the initial SDP doesn't
declare the real *intention* of the call.  This leads to the carriers'
problem that Kevin mentioned:  the carrier wants to route the call
through different "trunks" if the call *will become* fax, but current
SIP signaling gives them no clean way to distinguish that at call
setup time.

In addition, while any device that handles video *could* support fax,
about 99.9% of all fax communications are between devices that are
used *exclusively* for fax.  So it's easy to get 99.9% of all fax
communications to declare at dialog creation time "I'm going to do fax
in a few seconds".

It's one of the few situations where *capability* is highly predictive
of the communication request that will be made in the near future (but
is not indicated at present).  Perhaps for "truth in advertising" the
feature tag should be "+sip.going-to-ask-for-T38-soon".  ;-)

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Mar 2012 12:09:32 -0400

> feature tag should be "+sip.going-to-ask-for-T38-soon".  ;-)

For dedicated fax devices its also perfectly reasonable to include 
callerprefs requesting fax capability.

	Thanks,
	Paul

---

From: Michael Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 12:52:20 -0400

Paul,

That subjective decision to use or not determines if it gets used or not,
and hence the result.  It is transitive.
Interoperability will be inversely proportional to the vagueness of the
mechanism.

Many false positives or false negatives will reduce the usefulness of such
a declarative capability.

As suggested elsewhere, this may boil down to random value matching and
non-standard value choices.

Mike

On Tue, Mar 13, 2012 at 5:14 PM, Paul E. Jones <[email-masked]>wrote:

> Mike,****
>
> ** **
>
> Interoperability is in terms of “do you support this capability”?  The
> might be subjective, but the use is not.****
>
> ** **
>
> If I indicate in my INVITE when I call you that I want to reject any
> device on your end that does not advertise itself as immersive and you have
> no such devices, the call fails.  Likewise, if you have one that advertises
> the capability, it connects to that one.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* Michael Hammer [mailto:[email-masked]]
> *Sent:* Tuesday, March 13, 2012 9:11 AM
> *To:* Paul E. Jones
> *Cc:* Worley, Dale R (Dale); Glen Lavers (glavers); [email-masked]
> ****
> ** **
> it."****
> The term immersive seems to be in the same category.****
>
> ** **
>
> interoperability?****
> ISTM that it will be as useful as the evil bit.****
>
> ** **
>
> If I notice that it's use/non-use negatively impacts me, ****
>
> then I change it and get better service, is that cool with you?****
>
> ** **
>
> Mike****
>
> ** **
>
> ** **
>
> ** **
>
> wrote:****
> https://www.ietf.org/mailman/listinfo/dispatch****
>
> ** **
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 14 Mar 2012 14:42:40 -0400

> callerprefs requesting fax capability.

Yeah.  I thought more about it, and it seems that a better scheme
would be:

A sip.fax media feature tag to indicate the device is *capable* of
doing fax.

Then a caller who *intends* do to fax on this call uses
"Accept-Contact: *;sip.fax" to select only fax-capable destinations.
(If I understand the syntax and semantics of Accept-Contact
correctly.)

A carrier can key off of this Accept-Contact to know to assign a
fax-capable trunk line for the call.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 14 Mar 2012 15:11:33 -0400

> subjective, perhaps, but that is what the user preferred.

Who is "the user" who preferred this?

> "data"?  I'd argue that "data" is equally as vague.  Still, it is a property

Well, if "data" is vague, that means you can't actually define it, and
if you can't define it, you can't effectively use it.

But in reality, the IANA registry defines "sip.data" as "This feature
tag indicates that the device supports data as a streaming media
type."  and refers to RFC 3840.  RFC 3840 says the same, and refers to
RFC 2327:  "The audio, video, application, data, and control feature
tags in the SIP tree (each of which indicate a media type, as defined
in RFC 2327) are different.  They do not indicate top level MIME types
which can be received in SIP requests.  Rather, they indicate media
types that can be used in media streams, and as a result, match up
with the types defined in RFC 2327."  Looking at RFC 2327 gives:

   m=<media> <port> <transport> <fmt list>
   [...]
   o The first sub-field is the media type.  Currently defined media are
     "audio", "video", "application", "data" and "control", though this
     list may be extended as new communication modalities emerge (e.g.,
     telepresense).  The difference between "application" and "data" is
     that the former is a media flow such as whiteboard information, and
     the latter is bulk-data transfer such as multicasting of program
     executables which will not typically be displayed to the user.
     "control" is used to specify an additional conference control
     channel for the session.

RFC 4566 updates RFC 2327 with:

   Note: The media types "control" and "data" were listed as valid in
   the previous version of this specification [6]; however, their
   semantics were never fully specified and they are not widely used.
   These media types have been removed in this specification, although
   they still remain valid media type capabilities for a SIP user agent
   as defined in RFC 3840 [24].  If these media types are considered
   useful in the future, a Standards Track RFC MUST be produced to
   document their use.  Until that is done, applications SHOULD NOT use
   these types and SHOULD NOT declare support for them in SIP
   capabilities declarations (even though they exist in the registry
   created by RFC 3840).

So the "sip.data" tag means that the UA supports "m=data ..." in SDP,
which will be used to carry bulk-data transfer such as multicasting of
program executables which will not typically be displayed to the user,
and it is obsolete and should not be used.

The IANA registry defines "sip.mobility" as "The sip.mobility feature
tag indicates whether the device is fixed (meaning that it is
associated with a fixed point of contact with the network), or mobile
(meaning that it is not associated with a fixed point of
contact). Note that cordless phones are fixed, not mobile, based on
this definition."

> Interoperability is in terms of “do you support this capability”?
> The answer is either yes or no.  The declaration that a device is
> immersive might be subjective, but the use is not.

Certainly "what would happen" is well-defined in a technical sense.
But the question is whether a caller would *wish* to invoke this
functionality.

In order for this to be a matter of interoperability, there would need
to be circumstances where a caller in one organization would want to
contact a callee *with whom he had no previous arrangements* and
desire the contact only be via an "immersive" UA (or only via a
non-"immersive" UA).  For this to be sensible, "immersive" has to have
some sort of global meaning.  If "immersive" is *freely* assigned by
each user (or organizational system administrator), it has no global
meaning, and there is no reason a caller would use it in
caller-preferences generally, since he has no idea what its
consequences would be at the callee's system.

So if we want to *standardize* an immersive indicator, we need to (1)
fix a (perhaps somewhat elastic) criterion for what constitutes
"immersive", and (2) have a belief that callers might wish to
distinguish between immersive and non-immersive UAs when calling
destinations about which they have no information other than the RFC.

Dale

---

From: Michael Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 15:20:21 -0400

If it can get down to identifying specific protocols to be used, that would
be useful.

Mike

---

From: Dean Willis <[email-masked]>
Date: Wed, 14 Mar 2012 14:38:07 -0500

> modes by which the interlocutors communicate (a clearly-defined user

I was reading a good book last night on my Nook. It was immersive. But this morning, on the same Nook and and the same book-app, the technical tutorial I was reading was not so immersive.

How could this be, if "immersive" is a property of the device? Are we talking about some kind of physical thing here like "is 3d", "has 180 degree field-of-view", or a subjective concept like a PG-13 rating?

Otherwise said, one man's immersion is the sprinkling of a few drops on the next man. But neither is as physiologically distinct as circumcision. And despite arguably equal significance to the persons involved, past immersion is pretty much impossible to verify by mechanical inspection, and might not be a feature of the "device" in question.

--
Dean

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 14 Mar 2012 22:08:20 +0000

Hi Dale, Paul, folks,
 So Dale, what you're telling me is that these features are related to the SDP m= line, and those sub-fields are related to the transport, as well as the end device processing?
I had always interpreted the sip.data type as meaning (in practice) that intermediaries (e.g.,B2BUAs) might be able to interpret (or even transcode) audio, video, or application type streams, but they shouldn't mess with data (not even lossy compression). I have no idea whether it is used out there IRL, but there's a way of handling it if it hits your (middle)box.

Re. the wonderfully wooly term "immersive" -- how does that help, and who does it help; what happens if it hits an intermediary box?
Agreed that fax is a nice hint for intermediaries (or multiple end devices registered for a SIP identity). When capabilities were first being developed, I had hoped that they would be more structured AND wider than they ended up, BUT ...

I can't see how this term helps, or could even discriminate between end devices.
Please, can anyone convince me that this is a technical feature and not just the coke-laden ravings of a carrier marketeer?
[No Paul, I don't mean you, but from your comments I wonder if that may be "the customer" :]

all the best from a bemused
  Lawrence

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 22 Mar 2012 15:38:25 -0500

> (If I understand the syntax and semantics of Accept-Contact

Slight correction: if the UAC is mandating that the UAS be FAX-capable, 
it would use:

Accept-Contact: *;require;+sip.fax

> fax-capable trunk line for the call.

Indeed they could. They wouldn't really have to do full RFC 3841 
processing if they didn't wish to; their proxies/UASes could have 
'special knowledge' of the sip.fax feature tag and not require that the 
downstream elements explicitly indicate support for this feature (it 
would be indicated via some administrative means instead).

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Mar 2012 14:43:49 +0000

On Mar 14, 2012, at 3:38 PM, Dean Willis wrote:

> Otherwise said, one man's immersion is the sprinkling of a few drops on the next man. But neither is as physiologically distinct as circumcision. 

That is the funniest email line I've read in a long time.  
I was skimming the dispatch list to see what I've missed for the past couple months… I did not expect to become drenched in a baptism of humor of that particular nature.  Circumcision?!?  You're a real cut above the rest.  ;)

-hadriel