Re: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)

[Ben Campbell <[e-mail]>]

Sorry for jumping in late—I was on the road most of last week and am just catching up.

I think I share Adam’s view (and by extension, Ekr’s). More comments inline:

> On May 21, 2018, at 10:37 AM, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
>>> It is also important to remember that this affects virtually every SDP attribute we define, >> unless there are cases where "initial offer" always means the initial offer of a session, i.e., >> it is not possible to introduce an attribute later in a session.
>> 
>> I'm not following your logic here. Can you give an example?
> 
> Assume I establish a session, with audio and video.
> 
> The initial offer will contain the m- lines, and associated SDP attributes, for audio and video.

Sure.

(But be advised that if we are taking about rfc4583bis, that’s not the most convincing argument since it hasn’t been published yet, and RFC4583 does not use this structure at all.)

> 
> Later in the session, I send a subsequent offer, adding a BFCP m- line.

Isn’t that a _modified_ offer? There’s a separate section for that.

> 
> When setting the SDP attributes associated with the BFCP m- line, I will now use the "initial offer" procedures for those attributes, because it is the initial offer for those attributes (while a subsequent offer for the SIP session).

This is where I (agreeing with Adam) think readers will get confused, because it’s out of sync with the SDP offer/answer. To extend your example, we end up with “initial SDP offer” == “no BFCP offer” and “modified (or subsequent) SDP offer” == “initial BFCP author”.

I see further down my mailbox list that you brought up RID. I will respond further there.

Ben.




> 
> Regards,
> 
> Christer
>