Subject: Re: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-04.txt

From: Flemming Andreasen <[email-masked]>
Date: Sun, 04 Mar 2007 14:05:19 -0500

Stach, Thomas wrote:
> Fleming,
>
> this looks quite mature.
>
> Just a nit-picking(?) comment on the last paragraph of 3.5.3. 
> I propose to explicitly clarify details of the second offer/answer
> cycle.
> The text in 04 says: "This second offer/answer exchange will not modify
> the session in any way".
> However the second offer deviates from the previous one. 
> Now RFC3264 says in section 8, 3rd para:
>    When issuing an offer that modifies the session,
>    the "o=" line of the new SDP MUST be identical to that in the
>    previous SDP, except that the version in the origin field MUST
>    increment by one from the previous SDP.  If the version in the origin
>    line does not increment, the SDP MUST be identical to the SDP with
>    that version number. ...
>    However, the answerer MUST generate a valid
>    answer (which MAY be the same as the previous SDP from the answerer,
>    or MAY be different), ...
>
> I think its pretty clear that an incremented SDP version number is
> required for the offer, but the answer could be the same. Nevertheless
> I'd like to spell it out again in draft.
>
>   
Ok -added some text.
> Another small issue is about keying matrial in the SDP. Should it be
> repeated in the second offer/answer cycle? 
> Well, in case of Sdescription and forking the key(s) from the offer are
> distributed to multiple targets. 
> This would merit re-keying once the INVITE received a 200OK. Without
> forking re-keying wouldn't be necessary.
>
> The added text could look like:
> -------------------------------
> The second offer/answer cycle MUST be in accordance with RFC3264, this
> includes e.g. incrementation of the version number in the offer, but not
> necessarily in the answer.
> Attribute lines carrying keying material SHOULD repeat the keys from the
> previous offer, unless re-keying is necessary for e.g. a previously
> forked SIP INVITE request.
> -------------------------------
>
>   
I've added the second verbatim, and a modified version of the first part.

> Some nits (from a quick review):
> page 17 4th para from the bottom last sentence replace "configs" with
> "configurations".
>   
It's referfing  to the definition above it, which uses the same 
terminology, so I think it's ok.
> In the examples of 3.5.2.1 I found 4 occurrence of the line
> "a=tool:foo". 
> Is this intentional? If yes, what does it mean?
>   
It doesnt' really mean anything - it's just an example trying to 
illustrate what happens with attributes in various places in the SDP.

-- Flemming

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic