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
