Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: SDP Considerations (Section 11)

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

Hi,

Below are my comments/questions on section 11.

Regards,

Christer

Section 11:

	ED_11-1: I don't understand what the text in the section has to do with SDP. I think 
	the text should say that the section defines SDP extensions, procedures etc. Copy/paste error?

Section 11.1:

	The text says:

	"Not providing this information may/will make the sender or receiver ignore the header 
	extensions. However, MPRTP MAY be used by either sender or receiver without prior signaling."

	ED_11_1-1: The text is a little confusing. I assume it means that you can use the header extension without prior
	signaling, but that endpoints will ignore it. Now, if "signaling" also contains in-band signaling, I think this
	text belongs elsewhere in the document, as it is not SDP specific.

	FU_11_1-1: Why allow usage of MPRTP even if it hasn't been negotiated?

	FU_11_1-2: The fact that the usage of SDP is optional raises some issues. For example, assume 
	I establish a session, and uses in-band signaling to negotiate interfaces. The SDP does not  
	contain any interface information. Then, later during the session I send a new SDP offer, again 
	without any interface information. Now, does that remove the interfaces that I previously 
	negotiated in-band? Which signaling has higher priority: in-band or out-of-band? 
	I think it would be good if only ONE mechansim was used throughout the session, and I think you 
	later claim, that if the SDP only contains the a=mprtp attribute, without any interface information, 
	one should use in-band signaling.
	
	FU_11_1-3: Depending on the outcome of FU_11_1-2, you need to define the offer/answer aspects of the 
	attribute. For example, if an offer contains an attribute without interface parameter(s), does the 
	answer have to do the same? What about mid-session modifications?

	ED_11_1-2: "The literal 'mprtp' MUST be used to indicate support for MPRTP." ->
	"The a=mprtp MUST be used to indicate support of receiving media on the associated media stream 
	using MPRTP."

	ED_11_1-3: In order to be consistance with section 11.3.1, please add the following text in front 
	of the attribute syntax:

	"The syntax of the mprtp attribute is defined using the following Augmented BNF, as defined in [9]." 

	ED_11_1-4: I think the name of the section should be "a=mprtp attribute".

Section 11.2:

	ED_11_2-1: I don't understand the text. What is this URN, and where is it used?

Section 11.3:

	ED_11_3-1: I think it would be good to have a level 11.x section, named "MPRTP with ICE", or something.

	ED_11_3-2: "out-band" -> "out-of-band"

	ED_11_3-3: What is a "preloaded interface"? 

		(Comment applies also to sections 5.1 and 5.2)

	ED_11_3-4: "initial INVITE" -> "initial SDP offer"

	The text says:

	"2.  Advertising MPRTP interfaces: When a sufficient number of
       	connectivity checks succeed the endpoint MUST send an updated
       	offer containing their interfaces."

	FU_11_3-1: I don't understand the second step.

	FU_11_3-1a: Are you talking about ICE connectivity checks, based on the ICE candidates?

	FU_11_3-1b: What does "their interfaces" mean?

	FU_11_3-1c: Do you mean that, when ICE is finished and an ICE candidate has been selected, you send an updated SDP offer 
	which contains that ICE candicate (according to the ICE procedures), and IN ADDITION to that you add one or more 
	interfaces associated with that ICE candidate?

	FU_11_3-1d: Do you mean that, when ICE has determined which ICE candidates work (based on the ICE connectivity checks), and
	updated offer is sent where each ICE candidate is represented by an interface, but no additional interfaces are added?

	FU_11_3-1e: If the interfaces are based on ICE candidates, I think the priority of the interfaces should also somehow
	be associated with the priority of the ICE candidates.

Section 11.3.1:

	ED_11_3_1-1: "interface" is not an attribute. It is an optional attribute parameter.

	The text says:

	"It is used to describe one of the many network addresses of an endpoint."

	ED_11_3_1-2: Please use similar wording/terminology as for the in-band mechanism. Something like "It is used to advertise
	an interface address", or something like that.

	ED_11_3_1-3: "It reuses the RFC4566 [18] definitions of unicast-address, port, token, SP, and CRLF." ->
	"The definitions of unicast-address, port, token, SP, and CRLF are according to RFC4566 [18]."

	FU_11_3_1-1: <mprtp-interface>. I don't think it is good to rely on the order of interface attributes, so I 
	think it would be better to say that the interface with the lowest counter value must match the c/m-line 
	information. In the same way, the priority should be based on the counter value, not the position of the attribute.

	FU_11_3_1-2: <port>: How can the value represent an address for which the connectivity checks have succeeded, if the 
	endpoints haven't even negotiated where to send the connectivity checks yet?

	FU_11_3_1-3: <counter>: Is there a reason not to have a MUST instead of SHOULD?`

	FU_11_3_1-4: Is the <counter> value required to stay the same throughout the session?

Section 11.5:

	ED_11_5-1: I would like to see an example where MPRTP is used with ICE.

Section 11.5.1:

	The text says:

	"...SHOULD use in-band signaling for exchanging interfaces
   	and for performing connectivity checks."

	ED_11_5_1-1: Please do not use "SHOULD" in an informative example.

	ED_11_5_1-2: Aren't the connectivity checks always performed in-band (even when STUN is used)?

	ED_11_5_1-3: "out-band" -> "out-of-band"

	ED_11_5_1-4: Is there text in the normative part of the draft saying that in-band signaling should be used 
	when the a=mprtp attribute is used without interface information (see FU_11_1-2)?

Section 11.5.2:

	ED_11_5_2-1: "out-band" -> "out-of-band"

	ED_11_5_2-2: Please do not use "MAY" in an informative example. In this case I think you could use "can" instead.