Subject: RE: [Sip] WGLC for Manyfolks draft

From: "Mark Watson"<[email-masked]>
Date: Wed, 13 Mar 2002 17:43:57 -0000

All,

Two comments:

1) Section 11.1 (page 16) describes the sending of a new Offer in the 200 OK
to the INVITE (after an offer/answer exchange has already completed) in
order to take the media off hold:

   "However, if B wants A to generate local ringback, it can put the
   media stream on hold in SDP4. In this case, B would put the media
   stream off hold by sending an offer in the 200 OK for the INVITE (8)."

I thought we decided this was not allowed due to the glare problem (no way
of rejecting the SDP in the 200 OK). Instead the UAS has to send both an
UPDATE and a 200 OK (hopefully at the same time, without waiting for the
response to one before sending the other).

2) It's not 100% clear which elements are specific to the 'qos'
pre-condition type and which are intended to be general for all
pre-condition types. status-type and strength-type seem to be general as
does direction-tag when applied to the confirmation status (which
direction(s) is confirmation required ?). These things would work in the
same way for any new pre-condition tags as they do for qos.

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 ?

It's important because the behaviour on receipt of pre-conditions with an
unknown pre-condition type need not be to always reject (BTW is this defined
?). A UA can deal with pre-conditions which are 'local' to the other UA even
if it does not recognise the pre-condition type - namely, ask for
confirmation and wait until the curr and des status for match.

Regards...Mark

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 10 March 2002 22:11
> To: [email-masked]
> Cc: [email-masked]; Gonzalo Camarillo; [email-masked]; Rohan
> Mahy; [email-masked]
> Subject: [Sip] WGLC for Manyfolks draft
> 
> 
> We'd like to open discussion for working group last call on:
> 
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-manyfolks
> -resource-05.t
> xt
> 
> This is part of the "Bundle 2" group needed by 3GPP.
> 
> The working group last call discussion period will close 
> immediately after
> IETF 53, eta March 25, with the intent to move to IETF Last 
> Call as soon as
> possible thereafter.
> 
> --
> Dean Willis
> SIP WG Co-Chair
> 
> 
> 
> 
> _______________________________________________
> 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: Fri, 15 Mar 2002 23:10:26 +0200

Mark,

Mark Watson wrote:
> 
> All,
> 
> Two comments:
> 
> 1) Section 11.1 (page 16) describes the sending of a new Offer in the
> 200 OK to the INVITE (after an offer/answer exchange has already
> completed) in order to take the media off hold:
> 
> I thought we decided this was not allowed due to the glare problem (no
> way of rejecting the SDP in the 200 OK). Instead the UAS has to send
> both an UPDATE and a 200 OK (hopefully at the same time, without
> waiting for the response to one before sending the other).

Yes, you are right. George had already reported this in a private mail.
It is already fixed. Thanks.

> pre-condition types. status-type and strength-type seem to be general
> as does direction-tag when applied to the confirmation status (which
> direction(s) is confirmation required ?). These things would work in
> the same way for any new pre-condition tags as they do for qos.
> 
> 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...

> It's important because the behaviour on receipt of pre-conditions with
> an unknown pre-condition type need not be to always reject (BTW is
> this defined ?).

No, it is not. Good point.

> A UA can deal with pre-conditions which are 'local'
> to the other UA even if it does not recognise the pre-condition type -
> namely, ask for confirmation and wait until the curr and des status
> for match.

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?

Thanks for your comments,

Regards,

Gonzalo