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

[Ben Campbell <[e-mail]>]

> On May 21, 2018, at 11:23 AM, Christer Holmberg <[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.
> 

*** MMUSIC Chairs and other SDP experts: Please feel free to jump in with your opinion about how we should expect the “Offer/answer considerations” sections be written in SDP extension RFCs. ***

I will let Adam confirm his intent, but I read the “initial SDP offer” section as talking about the initial _SDP_ offer”. It says the initial offer _MAY_ contain one or more “a=rid” lines. The "Modifying the Session” section then goes on to say that such an offer MAY change the number of RID lines in use. I argue that going from zero to one or more RID line counts as changing the number of RID lines in use.

I do not dispute that there may be some SDP extension RFCs that are written as you suggest. I would have to go back and re-read a bunch of documents to reasonably comment on how many. But picking a random target:

draft-ietf-mmusic-dtls-sdp-32 seems ambiguous on this point. The “Generating initial SDP offer” section is written from the assumption the initial offer includes DTLS-SRTP. But the “modifying a session” section talks about putting a new offer for DTLS-SRTP in a subsequent SDP offer. Taken as a whole, this seems more in the vein of “initial SDP offer” is really the initial SDP offer, and it just (reasonably) neglected to describe the case where the initial offer does not include DTLS-SRTP.

In the case of BUNDLE, I don’t think we are talking about a complete restructure. Just recognize the difference between invoking bundle in the initial SDP offer vs subsequent SDP offers. That probably means adding a few sentences to the “Initial SDP offer” and “Modifying the Session” sections.


Ben.

> Regards,
> 
> Christer
> 
> 
> Sent from my iPhone
> 
> On 21 May 2018, at 18.37, 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.
>> 
>> 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
>>