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

[Christer Holmberg <[e-mail]>]

In my opinion, if the problem is that there is a conflict with the terminology in RFC 3261 and/or 3264, then let’s fix those specs instead.

Regards,

Christer

Sent from my iPhone

On 21 May 2018, at 19.23, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:

...and, to use an example you may be more familiar with: RID.

Are you saying that the “initial offer” procedures can only be used for the initial offer of the SIP session, meaning I can’t introduce RID later in the session (to an existing and/or new m- line)? If so, I think that should be explicitly stated in the draft.

Regards,

Christer


Sent from my iPhone

On 21 May 2018, at 18.37, Christer Holmberg <[e-mail]<mailto:[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.

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

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).

Regards,

Christer