Subject: [Sip] Last Call comments on manyfolks-05

From: William Marshall <[email-masked]>
Date: Thu, 14 Mar 2002 18:17:11 -0500 (EST)

One of the pieces lost in the re-write between manyfolks-03 and -05 is
all the spec language about the UAS sending its answer in a 183 (Session 
Progress) provisional response, and when the UAS needs to include
a confirmation request in that answer.

When the offer is contained in a 1xx reliable provisional response,
the rules already require the answer to be in the PRACK.  However,
when the offer is in the INVITE, nothing (except for the desire for
a working system) is requiring the UAS to send the answer as shown in 
the examples in section 11. 

Two cases need to be covered.  First, the UAC may need the destination
information in order to make its local segmented resource reservation,
and to establish the flowspec through firewalls etc.  Second, the UAS
may need confirmation for any aspect that it can't guarantee itself.
I believe that wording the requirement around the second case will also
include the first case.

I propose the following text be added into section 6, just after the
indented motivation paragraph beginning "Note that in this case..."

  A UAS that is not capable of unilaterally meeting all of the
  mandatory preconditions MUST include a confirm-status attribute
  in the SDP (offer or answer) that it sends (see Section 7).  Further,
  an SDP (offer or answer) that contains a confirm-status attribute MUST
  be sent as soon as allowed by the SIP offer/answer rules.

Hopefully the above text also covers the case where the offer is sent
by the UAS in 183 without mandatory preconditions, and the answer from
the UAC in the PRACK upgrades them to mandatory.  The UAS then needs
to send a new offer with the confirm-status attribute, presumably in
another 183 reliable provisional response.

Two other places need spec language.  The last paragraph of section 
5.1 should contain a MUST:
  With the transaction status table, the user agent MUST generate the
  current-status and the desired status lines following the syntax of
  Section 4 and the rules described below in Section 5.1.1.
Also, in section 5.2, in the paragraph after Table 3:
  Once both tables have been updated, an asnwer MUST be generated
  following the rules described in Section 5.1.1 and taking into
  account .....

And, a nit.  In section 11.2, SDP1 is generated by A, not B.
  SDP1:  A includes local and remote QoS preconditions in the .....

Bill Marshall
[email-masked]

_______________________________________________
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: William Marshall <[email-masked]>
Date: Fri, 15 Mar 2002 09:20:52 -0500 (EST)

I wrote too fast yesterday:
> Hopefully the [inserted] text also covers the case where the offer is sent

Goofed there.  The UAS would need to send a new offer with the confirm-
status attribute in an UPDATE message, since it can't send a new offer
in a subsequent reliable provisional response.  But the text to be
inserted is still OK, I think.

Bill Marshall
[email-masked]

-----original message-----
From: William Marshall <[email-masked]>
Date: Thu, 14 Mar 2002 18:17:11 -0500 (EST)
To: [email-masked]
Cc: [email-masked]
Subject: [Sip] Last Call comments on manyfolks-05

Bill Marshall
[email-masked]