[Sip] Re: update-01 comments

Bob Penfield wrote:
> 
> Section 4 says the UPDATE may contain an offer any time after a dialog
> is
> established. Although section 5.3 says it must follow the offer/answer
> rules
> you may want to point out in section 4 that the UPDATE can only contain
> an
> offer if allowed under the offer/answer rules.

This section is meant to overview operation, and doesn't specify
normative behavior. So, I don't want to get into details. I reworded to
say:

Afterwards,
the UAC can generate an UPDATE method that contains
an SDP offer \citenorm{draft-ietf-mmusic-sdp-offer-answer} for the
purposes of updating the session.

> 
> Section 5.3 talks about the Supported header in the response, but
> section
> 5.2.1 mandates the response contain the Require header. This should be
> made
> consistent. Otherwise it is not clear why the Require:update is needed.
> Also, the language in 5.3 implies that the fact that it is a 155
> response is
> sufficient.

There are two different conditions here:

Condition 1: the UAS sent a 155. In this case, the UAC really needs to
send an update to get it out of the wait state it is in. This is the
reason for the MUST level inclusion of Require in the 155. Effectively,
processing of the 155 requires an extension, and that extension is
separate from the support of the UPDATE method.

Condition 2: the uAS just sent a vanilla reliable provisional response
(i.e., 183). The UAC can send an update if it likes. UPDATE is a method
supported by the UAS. So, it is included in an Allow header, just like
any other method. Thus, the text in 5.3 is wrong, since it says
Supported. It needs to say Allow. Allow is mentioned in section 5.1 as
something the UAC can include. It is supposed to be symmetric.

> 
> Since we have changed the strength of the UAS requirement for generating
> a
> 155 from MAY to SHOULD, I suggest that we change the addition of
> Require:update in the proxy from a SHOULD to a MAY. If the UAS does not
> support update, you'll end up with 3 exchanges if there is a repairable
> error in the INVITE instead of 2. I don't see any great advantage in the
> proxy requiring update.

OK, I think that is sensible.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip