Re: Policy to register media feature tags

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] for questions on current sip
> Use [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