> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: 15 March 2002 21:10
<snip>
> > However, direction-tag applied to current and desired
> status seems to
> > have a specific meaning related to the direction of QoS
> reservations.
> > Other pre-condition types could be imagined for which a
> different type
> > of status indication was required. So, perhaps they syntax for curr
> > and des should include a generalised 'status' which in the
> case of qos
> > has type direction-tag ?
> >
>
> I believe that these fields are applicable to more types of
> preconditions. Thus, I would keep them in the framework. New
> preconditions types can always define new attributes if needed. For
> example, a new precondition type could say that the segmented status
> type MUST NOT be used...
>
OK, if I think hard, I can pursuade myself that the concept of 'direction-tag' is relevant to all future pre-condition types, in that it makes sense to say 'This precondition must be met to enable the send/recv/both media streams to start' (If the precondition is not needed for either of the directions, then it is not really a precondition!).
<snip>
> I would like an answer with a precondition type to mean that
> the entity
> generating the answer understands that precondition type.
> That might be
> useful if the other end suddently decides to ask for
> mandatory remote as
> well.
>
> My proposal is that if you receive an offer with a precondition type
> that you do not understand, you generate an error response. The error
> response can carry the preconditions types the UA does understand.
>
> The a line with the unknown precondition would have an "unknown" tag,
> rather than a "failure" tag, which would mean that you understand the
> precondition type but cannot meet it.
>
> I can add text about it in section 8. What do you think?
I still think there is no reason in principle why a UA needs to understand the pre-condition type in order to be able to deal with the other end requiring local pre-conditions.
If I get:
A-->B
a=des: foo mandatory local sendrecv
I can reply with:
B-->A
a=des: foo mandatory remote sendrecv
a=conf: foo remote recv
Which (if I've got my directions right) just means that I would like to receive confirmation when the A's foo conditions have been met.
If I later get:
A-->B
a=des: foo mandatory remote sendrecv
I just send
B-->A
a=des: foo unknown remote sendrecv
or whatever. Does it matter that A does not know that B does not recognise foo until A tries to require a mandatory foo condition on B ?
It will be frustrating if we discover a kind of pre-condition in future which (for example) is only relevant at the UAC, but we find that we cannot make it work with UASs which do not understand the new pre-condition tag. i.e. there is no need to upgrade the UAS to functionally make the pre-condition work, but we've imposed an artificial requirement to upgrade the UAS because of the way we designed the protocol.
As a general point, the scope says this is a 'general framework for preconditions' but the text often implies that the pre-conditions are related to 'network resources'. Just 'resources' would be better, as there may be pre-conditions which are not related to the network, but to resources at the UAS/UAC.
And a final language thing. In the definition of the Desired status, and elsewhere, we refer to the 'value' of the current and desired status attributes, but we do not define exactly what this means - it is obviously not the whole of the attribute, because their syntax is different.
Instead of 'When the current status value has the same or a better value than the desired status value, the preconditions are considered to be met for each stream.', I think what is meant is:
'When the direction-tag of the current status attribute with a given precondition-type/status-type is equal to (or better than) the direction-tag of the desired status attibute with the same precondition-type/status-type, then the preconditions are considered to be met.'
Regards...Mark