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
