Subject: [MMUSIC] SDP Directorate review of draft-ietf-avtext-rams-scenarios-03

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Mar 2012 12:06:55 +0100

Hi,

I am the assigned SDP directorate reviewer for draft-ietf-avtext-rams-scenarios-03.

For background on SDP directorate, please see the FAQ at <http://www.ietf.org/iesg/directorate/sdp.html>.

Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Summary:
------------

The draft contain both technical and editorial issues that need to be dealt with before published.

(I also think it needs to be verified that the RTP level multiplexing parts are aligned with the discussions taking place in AVTCORE etc, but that is outside the scope of this review).

New SDP information elements:
----------------------------------------

The draft does not define any new SDP information elements.

Technical:
------------

QT1: Same address:port for multiple m- lines

At least in the example in section 3.1 the same address:port is used for multiple m- lines, which is not allowed.

The text does say:

	"Note that the multicast destination ports in the above SDP do not matter, and they could be the same or different."

...but I am not really sure what that means.
 
However, the same comment also applies to the example in section 5.1, where the same address:port is also used for multiple m- lines, and there I can't find any text saying that the ports don't matter.

QT2: RFC 5956 already has the problem identified in QT1.

The bigger problem is that the problem above is introduced already in RFC 5956 (Forward Error Correction Grouping Semantics) - or, in fact already in RFC 4756 (which is obsoleted by 5956). The RFC does mention that semantics need to be defined for the usage of the same address:port, but I can't find any such semantics defined in the RFC, nor is it listed in the requirements section of the RFC. ? Also, some of the issues we have identified in the BUNDLE work, associated with the usage of the same address:port, don't seem to be addressed in the RFC.

As the RFC has been produced in MMUSIC, I think we need to discuss how to fix it. A 5956bis, where BUNDLE is used?

Editorial:
-----------

QE2: Destination port terminology

The scenario chapters talk about "destination port", but it is a little unclear what it means, and what the SDP examples show. To me it sounds like they show SDPs (either offers or answers) received by someone.

QE3: Missing SDP information

Mandatory SDP information elements (e.g. v= and o=) are missing from the SDP examples.

Regards,

Christer

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 20 Mar 2012 20:18:04 +0000

Hi Christer,

Thanks for the review.

> Technical:

They have different c= lines. 
 
> ...but I am not really sure what that means.

In the example, I can change the port in the second m line to something else, that is still a valid example for this draft. But, since the example has different c lines, I think this is still a valid SDP with the same port used in both m lines.
 
> However, the same comment also applies to the example in section 5.1, where the same address:port is also used for
> multiple m- lines, and there I can't find any text saying that the ports don't matter.

I can repeat the same comment if you agree with the above.
  
> QT2: RFC 5956 already has the problem identified in QT1.

Well, when we did the review for 5956, I was told that using different c lines would make using the same port in different m lines OK.
 
> The bigger problem is that the problem above is introduced already in RFC 5956 (Forward Error Correction Grouping
> Semantics) - or, in fact already in RFC 4756 (which is obsoleted by 5956). The RFC does mention that semantics need to be
> defined for the usage of the same address:port, but I can't find any such semantics defined in the RFC, nor is it listed in the
> requirements section of the RFC. ? Also, some of the issues we have identified in the BUNDLE work, associated with the usage
> of the same address:port, don't seem to be addressed in the RFC.
> 
> The scenario chapters talk about "destination port", but it is a little unclear what it means, and what the SDP examples show.
> To me it sounds like they show SDPs (either offers or answers) received by someone.

These are multicast flows so the destination port means where the packets are going to (from the source to the receivers).
 
> Mandatory SDP information elements (e.g. v= and o=) are missing from the SDP examples.

I can add these.

Thanks.
-acbegen

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Mar 2012 07:52:12 +0100

Hi Ali,

>> However, the same comment also applies to the example in section 5.1, 
>> where the same address:port is also used for multiple m- lines, and there I can't find any text saying that the ports don't matter.
>

That is true. It's my mistake for not detecting the different c lines.

So, if you are using different c lines in every place where you use the same port then my technical issue is solved :)
 
> These are multicast flows so the destination port means where the packets are going to (from the source to the receivers).
 
Yes. But, what are the SDP examples showing? Normally we show Offer and/or Answer examples, in which case the SDP bodies contain local ports (from the offerer/answer's perspective).
 
>> Mandatory SDP information elements (e.g. v= and o=) are missing from the SDP examples.

Thanks! :)

Regards,

Christer

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 21 Mar 2012 19:19:50 +0000

Thank Christer. One comment below.

> Yes. But, what are the SDP examples showing? Normally we show Offer and/or Answer examples, in which case the SDP
> bodies contain local ports (from the offerer/answer's perspective).

Well, it is a multicast flow and the only port that makes sense in the multicast context is the port the multicast packets are destined to. I.e., the port the receivers have to listen to in order to receive the multicast packets. Can the meaning of the port in the SDP examples be understood in a different way?

-acbegen