Subject: [MMUSIC] Comments to draft-ietf-mmusic-media-loopback-16

From: "Miguel A. Garcia" <[email-masked]>
Date: Sun, 16 Oct 2011 22:42:30 +0200

Hi,

Here are my comments to version 16 of the media loopback draft.

- Since this draft defines both an SDP extension and an RTP payload 
extension, I wonder whether this draft has been reviewed by the AVTEXT 
working group. Can the authors comment?

- Continuing with the comment above, I noticed that the title of the 
draft reflects the SDP extension, but is mute towards the RTP extension. 
I recommend to become "An extension to SDP and RTP for media loopback". 
This clearly reflects the actual contents of the draft.

- Terminology. I don't find any justification for this draft to depend on 
RFC 3261 and for making references to SIP INVITEs and alike. Instead, the 
draft should be based on the SDP offer/answer model (RFC 3264). As part 
of this, I will add a paragraph in Section 2 saying that ... "The 
following terms are borrowed from RFC 3264: offer, offerer, answer, 
answerer". I will rename section 3 to "SDP offerer behavior", Section 4 
to "SDP answerer behavior". An in general, I will not talk of the 
"offering entity" (section 3), but the "offerer", or the "answering 
entity" (section 4), but the "answerer".

- I will add a new paragraph at the end of Section 3 indicating where the 
"loopback" attribute is defined.

- Section 4, the last paragraph is not correct, because it puts a 
normative requirement (MAY) for answerers that are not compliant with 
this specification. So, if an answerer is not compliant with this 
specification, how can it comply with the normative MAY?

I suggest to replace the "MAY" with "is expected".

- I would rename Section 5 to "New SDP attributes"

- I would start Section 5.1 with a sentence that says: "This 
specification defines a new 'loopback' attribute which indicates the type 
of loopback that the entity is able to do".

- The syntax of the loopback attribute in Section 5.1 can be enhanced. I 
believe this one is more according to what we are used in SDP (only the 
first three lines differ with the draft):

         attribute             /= loopback-attr
         ; attribute defined in RFC 4566
         loopback-attr          = "loopback:" loopback-type
         loopback-type          = loopback-choice [1*SP loopback-choice]
         loopback-choice        = loopback-type-pkt / loopback-type-media
         loopback-type-pkt      = "rtp-pkt-loopback"
         loopback-type-media    = "rtp-media-loopback"

- The last two paragraphs in Section 5.1 describe the packet loopback and 
the media loopback. However, in Section 1.1, there are three modes 
defined. I would like to have a matching between the two values and the 
three modes. For example, you could add a sentence indicating in each of 
these two values "this value is used when the loopback is of type xxx 
(see Section 1.X)."

- Section 5.2 actually defines two attributes (loopback-source and 
loopback-mirror). First, I would like to ask if the authors have 
considered to have a single attribute, that you could cal 
"loopback-mode", with two values "source" and "mirror". If this is not 
desirable, then you need to split section 5.2 into two sections, each one 
devoted to a single attribute. Make sure that the name of the attribute 
is listed in the title of the section, so that it is also visible in the 
table of contents.

- If you continue with the two attributes approach, then the syntax for 
one of then would be:

         attribute             /= loopback-src-attr
         ; attribute defined in RFC 4566
         loopback-src-attr      = "loopback-source:" fmt *(SP fmt)
         ; fmt defined in RFC 4566

- Section 5.3, after the example. There is a note that contains a 
normative statement (MUST NOT). In principle, notes should be informative 
by nature, so just remove the word "Note:" from the beginning of the 
paragraph.

- Section 5.3, the paragraph after the Note refers to the "m= line" when 
the draft says "The port number and the address in the offer (m= 
line)..." However, the address in SDP goes in the c= line, therefore, 
whenever you refer to port number and address, you should refer to the 
"m/c= lines".

- Still talking of the same sentence as before. The sentence reads:

     The port number and the address in the offer (m= line) indicate
     where the offerer would like to send and receive the media stream.

I disagree with the "send" in the above sentence. According to RFC 3264, 
the port number and the address in either the offer or the answer 
represents where the offerer or answerer would like to receive the media 
stream, respectively.

Note that if you really want to keep the "send" in the above sentence, 
you need to mandate the usage of symmetric RTP and RTCP, RFC 4961. I 
haven't seen that dependency so far, so I believe that the "send" is 
incorrect in the sentence.

Also note that the resolution of this issue applies to Section 5.4, first 
paragraph as well.

- Examples at the end of Section 5.3 It would be nice to elaborate these 
examples, describing what they are showing. Also, at this point in the 
draft, the "encaprtp" and "rtploopback" tokens have not been introduced, 
so it would be nice to point to the sections where it will later be defined.

- Section 5.4, first paragraph, first sentence, replace "a loopback 
answer" with "an SDP answer". Later in this same paragraph replace 
"offerere" with "offerer".

- There is some missing words in the second sentence of the first 
paragraph in Section 5.4. The sentence is incomplete.

- Section 5.4, second paragraph, write "attributes" in plural in the 
first sentence.

- Section 5.5, first and second sentences, read:

     The answer to a loopback-source MUST be loopback-mirror.  The
     answer to a loopback-mirror MUST be loopback-source.

First, the sentences should be expressed in terms of "SDP offer" and "SDP 
answer" "containing a loopback-source" or "loopback-mirror". For example:

     An offer containing a "loopback-source" attribute must be answered 
with an SDP answer containing a "loopback-mirror attribute in the same 
media description. An offer containing...

But, having said that... I wonder whether the above sentence makes sense 
in this section. This section is titled "Offerer processing of the 
answer". Therefore, I expect to find there what the offerer should do 
when it receives an SDP answer, not what the answerer should do to 
process the offer and generate the answer. So, move these two sentences 
to the Section 5.4.

- The third and fourth sentences in Section 5.5 read:

     The
     loopback-mode line MUST contain at least one codec the answerer is
     willing to send or receive depending on whether it is the loopback-
     source or the loopback-mirror.  In addition, the "m=" line MUST
     contain at least one codec that the answerer is willing to send or
     receive depending on whether it is the loopback-mirror or the
     loopback-source.

Well, it seems that these sentencse also describe how the answerer 
generates the answer, so it should be moved to Section 5.4.

- Second paragraph in Section 5.5. Replace "target UA" with "answerer". 
But most important, this paragraph needs to say what happens if the offer 
receives an answer that does not include the 
loopback-mirror/loopback-source attribute. I believe it should say that a 
session is still established, but loopback packets are not expected. It 
is up to the offerer to close down the session by regular means (high 
level protocol such as a SIP BYE or sending a new offer with the port 
number set to zero).

- Section 5.6, I wonder way the "may" in the first sentence is not a MAY.

- Section 5.6, replace the reference to SIP. You just need the reference 
to Section 8 of RFC 3264.

- Section 7.1.2. The paragraph under "Receive Timestamp: 32 bits". The 
sentence reads:

     The
     Receive timestamp MUST be based on the same clock used by the
     loopback-source.

I wonder if there are mechanisms in place to implement the MUST, i.e., to 
make sure that exactly the same clock is used by both endpoints. Is there 
such mechanism?

The resolution of this issue also applies to Section 7.2.1.

- I don't understand the only normative sentence in Section 7.2 (Direct 
loopback). It reads:

     This payload format MUST NOT be used in cases where
     the MTU on the loopback path will cause fragmentation of looped
     back RTP packets.

So, if direct loopback does not increment the size of the payload, why is 
there a "MUST NOT".

I would understand if the sentence were written in Section 7.1, so that 
it would be applicable to the Encapsulated Payload Format". But I don't 
see how this sentence applies to Direct loopback.

- Section 10. All the examples, replace "client", "server" and "INVITE 
request", and "response" with:

An [offerer|answerer] sends an SDP [offer|answer] which looks like:

- Section 10. In all the examples, replace "s=Example" with "s=" (source, 
RFC 3264). And you can omit the i= and e= lines as well, they do not 
really add anything, nor they are mandated.

- Section 10.3. Re-title this section to "SDP answer rejecting loopback 
media".

- The note at the end of Section 10.3 reads:

     NOTE: Loopback request may be rejected by either not including the
     loopback mode attribute (for backward compatibility) or setting the
     media port number to zero, or both, in the response.

First, I don't like this note here, because it may induce to double 
specification, specially since you have Section 5.4 that describes how to 
reject a loopback request.

And actually, here you have double incongruent specification. Section 
5.4.1 only offers one mechanism for rejecting a session: setting the port 
to zero like in regular SDP. Nothing is written about rejecting a session 
by not including the loopback mode attribute.

Not including a loopback mode attribute in the answer is not a rejection, 
it is merely a session with no support for the loopback feature, but the 
session is established.

I recommend to delete this note.

- Section 11. I disagree with the dependency on RFC 3261. Please remove. 
Also, I am surprised of not seen any dependency of the security 
considerations of RTP/RTCP.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain