Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-00

From: "Roni Even" <[email-masked]>
Date: Wed, 21 Mar 2012 11:10:19 +0200

Hi,

I read the draft, some comments and typos

1.       In section 2 the text about bundle media says that RTCP mux is
optional.  Section 6.1 5th bullet mandate RTCP multiplexing and the example
in section 10 do not have RTCP-MUX.  I am wondering if we need to mandate
RTCP-MUX when defining this grouping attribute in MMUSIC. Maybe for RTCweb
it can be mandated but I think that here we should make this optional as in
section 2.

2.       In section 6.2 " If the SDP Offerer is not able to separate
multiple media received on  a single port, it MUST send a new SDP Offer ", I
am not sure how does the offerer know it cannot separate multiple media in a
single port since by sending BUNDLE grouping it says it can separate and the
assumption is that that the answer will have allow different 5-tuple for
each m-line, is it based on the answer or is this based on some application
logic.  

3.       Also in the same section "If an SDP Offer, offering a "BUNDLE"
group, and the SDP Offerer has  reasons to believe  ". What are reasons to
believe, I think that this will be when the answer do not understand BUNDLE
and do not support multiple m-lines of same media type for example it may
reject the offer (sending for example 488 or 606). Are there other cases.  

4.       In section 6.3 the last paragraph and mostly the last sentence is
true if the answerer understand BUNDLE but does not want to use it by
omitting the bundle attribute in the response. Otherwise I am not sure how
you can have a "MUST" in the last sentence.

 

Typo:

Both section 2 and 3 have the RFC2119 reference.

In section 6.2 second paragraph "proceudres"  

In section 6.3 "session-evel " 

In section 12 " athmosphere" should be " atmosphere"

Roni Even

 

  _____

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Mar 2012 11:44:51 +0100

Hi Roni,

> 1. In section 2 the text about bundle media says that RTCP mux is optional.  Section 6.1 5th bullet mandate RTCP multiplexing and the example in 
> section 10 do not have RTCP-MUX.  I am wondering if we need to mandate RTCP-MUX when defining this grouping attribute in MMUSIC. Maybe 
> for RTCweb it can be mandated but I think that here we should make this optional as in section 2.

The original intention of section 2 was to say that all RTCP streams share the same port , but that they may or may not share the port with the RTP streams. 

I agree that section 6.1 currently mandates that the RTCP streams and RTP streams are multiplexed on a single port. I will need to think a little more about it, but at
the moment I see no reason why not making it optional. 

I can add it as an open issue in my Paris presentation.

> 2. In section 6.2 " If the SDP Offerer is not able to separate multiple media received on  a single port, it MUST send a new SDP Offer ", I am not sure 
> how does the offerer know it cannot separate multiple media in a single port since by sending BUNDLE grouping it says it can separate and the assumption
> is that that the answer will have allow different 5-tuple for each m-line, is it based on the answer or is this based on some application logic.  

I will need to think about what the reasoning behind the text was.

> 3. Also in the same section "If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has  reasons to believe  ". What are reasons to believe, I think
> that this will be when the answer do not understand BUNDLE and do not support multiple m-lines of same media type for example it may reject the offer
> (sending for example 488 or 606). Are there other cases.  

Yes. But, 488/606 can be sent for a number of reasons, and there might not be an explicit indicator saying "I do not accept your offer which uses the same port for multiple m- lines".

So, the client might make the assumption based on additional information, previously sent Offers, configuration etc.

> 4. In section 6.3 the last paragraph and mostly the last sentence is true if the answerer understand BUNDLE but does not want to use it by omitting the 
> bundle attribute in the response. Otherwise I am not sure how you can have a "MUST" in the last sentence.

True, but I assume that the procedures apply to entities that do support the BUNDLE mechanism.

But, if you want, I can modify the first sentence of the last paragraph to:

	"If the SDP Answerer <new>supports the BUNDLE grouping extension, but </new> does not accept the..."

> Both section 2 and 3 have the RFC2119 reference.

I think that is the part of the template, but I'll double check.

> In section 12 " athmosphere" should be " atmosphere"

Will be fixed.

Thanks!

Regards,

Christer