Re: Policy to register media feature tags

Hans Erik van Elburg wrote:
> There is no rule stating that requiring "audio" and "video" will imply 
> that you also require one of the new tags. In that sense these tags are 
> completely orthogonal.

Its good to hear that. While I had no specifics, I had hints to the 
contrary. I guess those were wrong.

> If the caller adds "require" header field parameter then it is a 
> consequence of the callerpreferences processing that some calls could 
> fail that would otherwise have succeeded. If the caller added this, then 
> this must have been its intention. That is the *feature* that RFC3841 
> provides to the caller. The 3gpp specification does not say that one has 
> to use "require" header field parameter, it even warns that this might 
> hamper interoperability.
> 
> So I think your following sentence was a fair analysis of how the newly 
> proposed tags are actually used/should be judged: "If it only represents 
> a preference for whatever extra goodies are provided by 3gpp over and 
> above audio and video, then it may be a reasonable feature tag."

If that is the intent, then I am reassured.

Presumably the end user isn't actually selecting callerprefs. Rather the 
end user is just pushing a button on the phone to initiate a call, and 
some application on the phone is deciding what callerprefs to use.

So in the end it will be a question of whether the app constructs the 
call to maximize interop, or not.

	Thanks,
	Paul

> /Hans Erik van Elburg
> 
> 
> On Mon, Mar 23, 2009 at 2:26 PM, Paul Kyzivat <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     Inline...
> 
> 
>     Hans Erik van Elburg wrote:
> 
>         Responses inline...
> 
>         /Hans Erik
> 
>         Paul Kyzivat wrote:
> 
>             On one side were those who wanted capabilities and
>             preferences to be stated in terms of feature tags that are
>             well known and orthogonal. On the other side were those who
>             prefer to associate arbitrary names to collections of
>             features and then negotiate on the basis of the names of
>             those collections.
> 
>             Using the latter approach its possible that interoperation
>             will fail because the parties don't share a common name for
>             a collection of features even though they both possess the
>             necessary features to interoperate.
> 
>         That is a feature.
> 
> 
>     *what* is a feature?
> 
> 
>         This interoperability "problem" only occurs when the originating
>         party includes the header field parameters "require" and
>         "explicit" in the Accept-Contact header field containing the
>         feature tag. In this case the failure of the call when not all
>         of the receiving  UA's support  the feature is intended!
> 
> 
>     Lets get tangible about this. (This is retracing old ground, but
>     people sometimes have short memories.)
> 
>     Suppose Alice calls Bob. Alice has the latest and greatest 3gpp
>     phone with the capability to make audio/video calls, and would
>     prefer to do so if possible. Bob has an open source softphone
>     running on his PC. It is fully capable of audio/video operation
>     using a wide source of codecs. He also has a plain vanilla audio
>     phone registered to the same AOR.
> 
>     Alice's phone will send an invite with offer containing audio and
>     video media. It can also include callerprefs to bias the selection
>     of device in favor of one that will support audio and video. It
>     could do so a variety of different ways:
>     - indicate preference for audio and video
>     - indicate preference for the 3gpp "videophone" feature.
>     - indicate preference for audio, video, *and* 3gpp "videophone"
> 
>     Assuming none of these *require* these features, the first and the
>     last will both bias towards the softphone and result in an
>     audio/video call. The middle will probably cause both of bob's
>     phones to ring and audio/video will result if he happens to answer
>     the softphone.
> 
>     The situation is worse if Alice *requires* both audio and video, and
>     as a result *requires* the 3gpp videophone feature.
> 
>     The problem is one of orthogonality. the features should all be
>     orthogonal to one another. If "3gpp videophone" encompasses "audio,
>     video, and the 3gpp videophone look and feel", then it isn't
>     orthogonal to the existing audio and video feature tags. If it only
>     represents a preference for whatever extra goodies are provided by
>     3gpp over and above audio and video, then it may be a reasonable
>     feature tag.
> 
>     (Note that I have no knowledge of how 3gpp intends to name an use
>     features. I'm just exploring the possibilities.)
> 
> 
>             I don't have a problem with independent groups defining new
>             feature tags, as long as they are primitive and orthogonal
>             to existing ones. But I do have a problem with defining
>             feature tags that identify collections of features,
>             especially when the mapping from the identifier to the
>             collection of features is not public.
> 
>         Well who is going to determine what can be called a feature and
>         what not.
>         I also like to see where this principle is documented to apply
>         to the global tree.
> 
> 
>     IMO it was probably a mistake to use the existing feature tag
>     mechanism for callee caps in the first place. While there are some
>     simmilarities, the intentions are quite different. But we are where
>     we are.
> 
>     I don't know if we can impose additional rules on the global tree or
>     not. I expect that imposing an orthogonality constraint might not be
>     so controversial, and so *might* be possible. But the challenge may
>     be in *defining* orthogonality in an application-independent way. It
>     would be easier to do that in the context of sip, though still not
>     trivial.
> 
> 
>             The bottom line is that I think this sort of thing needs to
>             be thrashed out within the sip community. So I think the RFC
>             process is the right process.
> 
>         I think that bending the rules because some SIP people don't
>         like on how other organisations are applying SIP in their
>         solutions will alieanate those SIP users from that same SIP
>         community. So I seriously hope we will not go down that path.
> 
> 
>     Lets see what others say.
> 
>     IMO its important that those other communities don't use this
>     mechanism to erect more walls around their garden.
> 
>            Thanks,
>            Paul
> 
>         /Hans Erik
> 
>         _______________________________________________
>         Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>         This list is for NEW development of the core SIP Protocol
>         Use [email protected]
>         <mailto:[email protected]> for questions on
>         current sip
>         Use [email protected] <mailto:[email protected]> for new
>         developments on the application of sip
> 
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip