[Sip] Re: Caller Preferences and Callee Capabilities: comments on version7

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

My apologies to the delay in responding to this. I'm just getting back
to caller prefs now.

Stephane.Coulombe@nokia.com wrote:
> Hi Jonathan and Henning,
>
> I would like to comment on the latest version of "Session Initiation
> Protocol (SIP) Caller Preferences and Callee Capabilities" document.
> The document significantly improved from the previous version.
> However, it still has many shortcomings, which I would like to
> address here.
>
> First, I am a bit concerned about the restricted way RFC 2533 is
> used, by saying:
>
> "The feature predicate constructed by a UA MUST be an AND of terms.
> Each term is either an OR of simple filters (called a disjunction),
> or a single simple filter. In the case of an OR of simple filters,
> each filter MUST indicate feature values for the same feature tag
> (i.e., the disjunction represents a set of values for a particular
> feature tag), and each element of the conjunction MUST be for a
> different feature tag. Each filter can be an equality, the negation
> of an equality, or in the case of numeric feature tags, an inequality
>  or range"

This has been the scope of the caller preferences capabilities since the 
draft was first published way, way back - some FOUR years now [this is 
the oldest sip extension in existence].

Anyway, the reasoning here is that this specification is NOT meant as a 
general solution to the problem of declaring device capabilities. Its 
meant as a way to express capabilities to assist caller preference 
routing. THis introduces several important constraints. First, a proxy 
must perform computations on each message that gets sent, in real time. 
Thus, we cannot afford arbitrarily complex matching. Second, the set of 
things over which one might like to do preferential routing on, is much 
less than the general set of capabilities of a device. Honestly, I can't 
see anyone wanting to route a call because the screen size of the 
recipient is 100x200 as opposed to 200x300. This may be useful for some 
of the transcoding work you have been looking at, but I think that this 
is out of scope.

>
> this pretty much cuts the legs of RFC 2533. Not only it has the
> restriction that it needs to be a serie of ORs inside a big AND. But
> the terms in the OR need to have same feature tags. This is very
> limiting especially if you want to deal with media content. A simple
> example from RFC 2533: (| (& (pix-x=750) (pix-y=500) (color=15) ) (&
> (dpi=300) (ua-media=stationery) (papersize=iso-A4) ) ) would not be
> acceptable according to the proposed document.

Correct. But why would you care to route a call based on this?

>
> To express caller's capabilities, "AND"ing terms is often sufficient
> (but not always) but certainly not for expressing callee capabilities
> which should be a big "OR" of supported features. RFC 2533 is full of
> "OR" examples. E.g. (| (& (| (& (pix-x<=640)  (pix-y<=480)
> (color<=16777216) ) (& (pix-x<=800)  (pix-y<=600) (color<=65535) ) (&
> (pix-x<=1024) (pix-y<=768) (color<=256) ) ) (ua-media=screen) ) (&
> (dpi=300) (ua-media=stationery) (papersize=iso-A4) ) )
>
> How to interpret the following callee capabilities? Contact:
> sip:1.2.3.4;type="video/H263,image/jpeg,audio/amr";video="TRUE",audio-
> ="TRUE",resolution="#<200" According to the rule, (& (|
> (type=video/H263) (type-image/jpeg) (type=audio/amr) (video=TRUE)
> (audio=TRUE) (resolution < 200) ) This is not the way RFC 2533 would
> represent a terminal supporting audio OR video (the syntax here
> suggests that the received media MUST be video AND audio).

Not at all. Please see section 5 which outlines the model of how rfc2533 
is used. You seem to be interpreting the predicate as saying "media 
streams that I receive MUST have these characteristics". But that is not 
the meaning. The meaning is, this predicate represents the set of 
instantaneous operating modes I support.

> Therefore, I also share the concern raised during the SIP meeting
> regarding the reference to RFC 2533 but definition of a new syntax in
> the document. The proposal should be better aligned with RFC 2533.

What value is gained from changing syntax?

>
> The resolution attribute would better apply to the specific MIME type
> rather than be general for all media types. E.g. | (&
> (type=image/jpeg) (resolution<640)) & (type=video/h263)
> (resolution<176)))

See my above comment on scope.

>
> I am also concerned about the usage of a range in capabilities. For
> instance, if the caller uses resolution="#R5..100" as in the
> document. If callee capabilities are resolution="#R5..50", then I
> guess that terminal is acceptable because intersection is not zero.

Right.

> Then, what happens to the terminal if the sender sends 100 pixel
> image because system said it was okay?

Well, I once again question the usage of caller prefs for this kind of 
operation.

However, if a caller wants to route to a UA that supports resolutions 
100 and higher it would ask for that, i.e., "#>=100".



> Presently, the document mostly focuses on callee capabilities that
> could be useful to a caller to set preferences on. Indeed callee
> capabilities include: methods, events, etc. But the scope is general
> and also applies to terminal characteristics which can be used in a
> broader range of situations and applications (the document indeed
> gives example of resolution, format types, etc.).

The document says that this information can be used for other things. It 
does not say that caller prefs is a genreal solution to declaring client 
capabilities for a broad set of applications. That, I contend, is a much 
broader scoped problem, and one with many existing solutions. It would 
need a much richer set of attributes, and declarations. You probably 
want to make it hard state, support uploading a URL. You have different 
authorization issues - now you might not want everyone to see and use 
it, only certain applications. And so on.

It may very well be that IFF we had a general UA capability declaration 
function, caller preferences should be based on that. But we don't. We 
are (still) trying to solve a smaller scoped problem at hand. At such 
time as we have a more general purpose mechanism, if needed, we can 
revisit aligning caller preferences with it.

 Therefore, it would
> be good if these callee capabilities would not be limited to the
> REGISTER method but be part of other methods such as OPTIONS (for
> someone to learn about these capabilities),

Actually I thought OPTIONS was covered, since the Contact in OPTIONS is 
similar to the Contact in 200 to INVITE, which can have caller prefs 
parameters. I'll mention that.



> SUBSCRIBE (for presence
> server to be able to create appropriate presence messages), etc.

This doesn't make sense to me.

> In
> that manner, not only the specification can be used for message
> routing based on caller preferences but also based on knowledge of
> callee capabilities (either in routing stage or at the sending end).
>
> In summary, here are my recommendations: -	

> Align the syntax and
> overall functionality to use full extent of RFC 2533.

Disagree. See above comments on scope.

> o	Remove the
> restriction of having a serie of "OR" in a big "AND" in syntax.

Disagree. See above comments on scope.

>o	Fix
> matching problem with ranges.

It was not clear to me what the problem is.


> o	Fix other syntax problems outlined
> above.

Which?


 o	Allow and add more detailed media capability description and
> preferences (e.g. resolution can apply to specific MIME types. - I
> suggest to add the descriptors used in
> draft-coulombe-message-adaptation-framework-00.txt : 1. length:
> maximum size of the entity specified. It could apply to the whole
> message or to specific MIME types.

Disagree. See above discussions on scope.

>
> 2. media-pix-x: horizontal resolution of visual media (e.g. image or
>  video). It could apply to all images or video or to specific MIME
> types.

I don't think this is useful given the current scope.
>
> 3. media-pix-y: vertical resolution of visual media (e.g. image or
> video). It could apply to all images or video or to specific MIME
> types.  As described in the document, it should be possible to
> associate "length" to the whole message or to specific MIME types.
> These feature tags are quite important for mobile terminals and some
> handheld devices. Note that the resolution is NOT necessarily the
> display resolution, but rather what the terminal can support (usually
> larger than the display resolution). For instance, I may want to
> route a message containing an image to a terminal that support
> high-enough resolution.

As above.

>
> -	Extend the methods where the callee capabilities are provided (not
> just REGISTER but also SUBSCRIBE, OPTIONS, etc.)

OPTIONS ought to be there. I see no use for SUBSCRIBE.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip