[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sip] Caller Preferences and Callee Capabilities: comments on version 7

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 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.

 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). 



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). 
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). 
  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). 

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.

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)))

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. Then, what happens to the terminal if the sender sends 100 pixel image because system said it was okay? Same problem if callee capability resolution is 50 instead of a range.  Caller should not use a range but a constraint like resolution > 100 if he wants to make sure 100pixel image can be sent.

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.). 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), SUBSCRIBE (for presence server to be able to create appropriate presence messages), etc. 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.
			o	Remove the restriction of having a serie of "OR" in a big "AND" in syntax.
			o	Fix matching problem with ranges.
			o	Fix other syntax problems outlined above.
			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. 

						   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. 

						   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.

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

Stephane
_______________________________________________
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