[MMUSIC] Comments on draft-westerlund-mmusic-max-ssrc-00

[Paul Kyzivat <[e-mail]>]

I just reviewed this and have some comments:

In Section 4.4 on o/a usage, *an* offerer must use this mechanism in the 
*initial* offer, while *the* answerer must use the mechanism in *each* 
subsequent *offer* and *answer*.

IIUC this means the initial offerer on the initial o/a of a session 
might use the mechanism on the initial offer and never again, while the 
answerer of the initial o/a has to use it on every offer and answer.

This is very asymmetric, and I suspect not what you intend.

I *think* what you intend is that a supporter generating an initial 
offer in a session must use the mechanism. Then, if the answer doesn't 
use the mechanism the offerer should cease using it in subsequent o/a 
exchanges in the session.

OTOH, if the initial answer uses the mechanism then it should be used by 
both ends for all subsequent o/a exchanges.

Is that what you intended?

That makes more sense. But this won't necessarily work right if there is 
a B2BUA that passes SDP through unchanged, and then at some point 
replaces a one session with another on one side of the B2BUA. (I.e. a 
3pcc transfer.) If the other end of the new session differs in support 
for this draft from the replaced endpoint it won't be properly 
negotiated for the new session.

This can be solved by the B2BUA editing the SDP, but that is a high 
burden for some B2BUAs.

ISTM that there is no real harm in an end that supports this *always* 
including it in offers.

A smaller point:

Is there any reason not to also allow this as a session level attribute, 
applying to all the media descriptions that don't have their own?

It could be convenient to just put the following at session level:

a=max-send-ssrc:{*:1}
a=max-recv-ssrc:{*:1}

And finally, section 5 has an example with the following which must be 
wrong because it is missing a ":":

a=max-send-ssrc:{* 1}

	Thanks,
	Paul