Subject: RE: [Sip] WGLC for Manyfolks draft

From: "Mark Watson"<[email-masked]>
Date: Mon, 18 Mar 2002 10:50:32 -0000

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> 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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Mar 2002 22:58:53 +0200

Mark,

> 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.

we will discuss this point in the SIP WG meeting this evening. I have
prepared a couple of slides about it.

I will add your comments regarding the language for the "value" of the
attributes.

Thanks for your comments,

Gonzalo

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 25 Mar 2002 17:53:16 +0200

Mark,

> 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:
> 
> 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.'

Fixed.

Thanks,

Gonzalo