Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: MPRTP Protocol (Section 8)

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Aug 2011 23:06:10 +0200

Hi,

Below are my comments/questions on section 8.

Regards,

Christer

Section 8:

	The text says:

	"To enable a quick start of a multimedia session, a multipath session
  	MUST be upgraded from a single path session.  Therefore, no explicit
   	changes are needed in multimedia session setup and the session can be
   	setup as before."

	ED_8-1: I don't understand what the text is trying to say. Especially the second sentence is very unclear to me.

	ED_8-2: In the picture, would it be better to use "Interface" instead of "Address", to be more consistant in 
	terminology with the associated text in section 8.1 (and the terminology used elsewhere throughout the document).

Section 8.1:

	ED_8_1-1: In bullet one, I am not sure what you mean by "standard session setup". I assume you are talking about 
	"establishment of a normal RTP session", or something like that.

	ED_8_1-2: "This may be SIP or RTSP." -> "This can be performed e.g. using SIP or RTSP."

	ED_8_1-3: "Following the setup, like in a conventional RTP scenario," -> "When the RTP session has been established,"

	ED_8_1-4: "Host B is an MPRTP-capable media sender" -> "Host B supports sending of media using MPRTP"

	ED_8_1-5: "another interface B2." -> "an additional interface, B2."

	ED_8_1-6: "Host A is an MPRTP-capable media receiver and becomes aware of another interface A2." ->
	"Host A supports receiving of media using MPRTP, and becomes aware of an additional interface, A2."

Section 8.1.1:

	The text says:

	"On receiving the MPRTP Interface Advertisement, an MPRTP-capable receiver MUST respond with
   	its own set of interfaces."

	ED_8_1_1-1: I assume the receiver should, even if it supports MPRTP, still be able to choose 
	whether it wants to use it. So, maybe saying something like: "On receiving the MPRTP Interface 
	Advertisement, if the receiver supports and is willing to use MPRTP, it MUST response with...".

	ED_8_1_1-2: "MUST respond with the default..." -> "MUST indicate the default..."

	ED_8_1_1-3: Please clarify what "default" means. I assume you are talking about the ports and 
	addresses that the endpoint would use for a normal RTP session.

Section 8.1.2:

	ED_8_1_2-1: "After MPRTP support has been discovered" -> "After MPRTP support has been negotiated"

	ED_8_1_2-2: What is an "interface pair"?

	ED_8_1_2-3: I think you should define the "RTCP connectivity checks" somewhere else in the document, 
	and simply refer to them in this section.

	ED_8_1_2-4: Is there a reason why STUN connectivity checks can't be used (even if the endpoints don't
 	use ICE, or even SDP, to negotiate the interfaces)?

	ED_8_1_2-5: I think the section should talk about the collecting of candicate subflows, as they are 
	later used in secion 8.1.3.

Section 8.1.3:

	The text says:

	"The sender MAY open any number of subflows from the set of candidate
   	subflows after performing connectivity checks."

	ED_8_1_3-1: Clarify what "open a subflow" means.

	ED_8_1_3-2: Define "candicate subflow". I assume it is the interface pairs, for which sucessful 
	connectivity checks have been performed, something like that. I also think that section 8.1.2 
	should talk about the gathering of candidates. 

	The text says:

	"To avoid redoing the connectivity checks the endpoint MAY send keep-alive MPRTP packets 
	(see Section 9.1.3) to the passivesubflows to keep the NAT bindings alive."

	ED_8_1_3-3: I think it would be good to have a dedicated subsction (8.1.x) about NAT traversal.

	ED_8_1_3-4: "to the passive subflows" -> "on the subflows where bo media is sent".