Re: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16

[Hadriel Kaplan <[e-mail]>]

Howdy,
Magnus sent back a big list of comments against media-loopback for the WGLC.
I plan to propose changes to address some of his points in separate emails, notably for the technical ones.

The following points copied below I consider editorial in nature and wish to resolve directly as the editor.  Does anyone object to this?


On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote:

> 5. Abstract: "maintaining voice/real-time Text/video quality,
> reliability, and overall performance." The "voice/real-time"
> construction appears to indicate that voice isn't real-time. I guess
> something like: maintaining real-time voice/Text/video quality,
> reliability, and overall performance. would be easier and clearer.
> 
> 6. Section 3.
> No reference to SDP offer answer. And the "Offering entity" is called
> agent in SDP O/A terminology.
> 
> 7. Section 3:
> "it MAY do so as defined in section 5.4.1 of
>    this specification."
> 
> Considering what is written in 5.4.1 I think that section can be moved
> to section 3.
> 
> 8. Section 4:
>    An answering entity that is not compliant to this specification and
>    which receives an offer with the "loopback" media attributes MAY
>    ignore the attribute and treat the incoming offer as a normal
>    request.
> 
> I would suggest reformulate this. I expect this text to say what is
> expected to happen when the answering agent doesn't know what this
> attribute is. Which is ignore the attribute, attempt to establish the
> session without loopback and send back the answer without the attribute.
> 
> I would suggest to clarify that the offering agent should consider
> terminating the establishment at this point as loopback was not
> available, unless it might actual "ring" if this is an end-point at a user.
> 
...
> 10. What is really the purpose of the sections 3 and 4. They seem to be
> teasers for a very small part of the issue that is covered in detail in
> section 5. Why not move the appropriate text in to the relevant subsections?
> 
...
> 
> 12. Section 5.3:
> I think one could clarify that the loopback source needs to include the
> encapsulation or direct loopback payload formats when suggesting pckt
> type loopback.
> 
> ...
> 14. Section 5.1:
>    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 ABNF appears broken as it doesn't define the whole attribute. I
> would suggest to add a line:
> 
> loopback-attr = "a=loopback:" loopback-type
> 
> 15. Section 5.2 is missing ABNF.
> I think it should make clear the attributes definition completely.
> 
> 16. Section 5
> Two new media attributes are defined: one indicates the type of
>    loopback and the other indicates the mode of the loopback.
> 
> I would claim that this spec defines 3 attributes.
> 
> 17. Section 5.4:
> 
> The loopback-mode attributes (loopbackThe
>    port number and the address in the answer (m= line) indicate where
>    the answerer would like to receive the media stream.
> 
> Strange sentence!
> 
...
> 21. Section 6.
> "An answering entity that is compliant to this specification and
>    accepting a media with the loopback type rtp-media-loopback MUST
>    transmit all received media back to the sender. "
> 
> I think this MUST, MUST have an exception for that the path from the
> mirror to the source actually can support the bit-rate required.
> 
...
> 36. Section 10.1
> Either of the o= lines are in error. Because they can't be the same when
> it comes to the ID and version fields.
> 
...

-hadriel