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

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 21 Nov 2011 17:59:55 +0000

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 21 Nov 2011 18:57:53 +0000

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

> 4. Title: I think the title is indicating that this is only an SDP
> solution, but it clearly contains the considerations needed for the
> RTP/RTCP part also. I think it should reflect that it is a solution for
> RTP transported media loopback including SDP signalling.

I propose the following title:
"A Media Loopback Mechanism for Real-time Transport Protocol (RTP)"

Does anyone object?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 21 Nov 2011 19:05:56 +0000

With regards to issue #11 on the media-loopback draft, the consensus on the mailing list so far appears to be ok with the following text:

"Since media loopback requires bidirectional RTP, its normal direction mode is "sendrecv"; the "sendrecv" direction attribute MAY be encoded in SDP or not, as per section 5.1 of [RFC3264], since it is implied by default. If either the loopback source or mirror wish to disable loopback use during a session, the direction attribute "inactive" MUST be used as per [RFC3264].  The direction mode attributes "recvonly" and "sendonly" are incompatible with the loopback mechanism and MUST NOT be indicated when generating an SDP Offer or Answer."

Does anyone object to the above text?

-hadriel

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

> 11. Section 5.3
> "    Note: A loopback offer in a given media description MUST NOT
>    contain the standard mode attributes sendonly, recvonly, sendrecv,
>    or inactive. The loopback-mode attributes (loopback-source and
>    loopback-mirror) replace the standard attributes."
> 
> This appears to be a strange MUST NOT which I think might encounter
> issues. Considering that SIP proxies that looks into this SDP requires
> the direction attribute to be present and adds it, what happens now.
> And why isn't sendrecv and inactive possible values? sendrecv appears to
> be requried for loopback to work, and inactive would put media transport
> in an established session on hold. Isn't that reasonable?

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 22 Nov 2011 08:11:24 +0000

Hi Miguel,
I knew you had also posted comments but I was planning to address Magnus' first and then your's, but I see now there is some overlap.

With regard to title, would this be ok:

"A Media Loopback Mechanism for Real-time Transport Protocol (RTP) and Extension for SDP"

-hadriel

On Nov 22, 2011, at 1:43 AM, Miguel A. Garcia wrote:

> Hi:
> 
> In my comments posted in this mail:
> http://www.ietf.org/mail-archive/web/mmusic/current/msg08958.html
> 
> I suggested to rename the draft to: "An extension to SDP and RTP for media loopback".
> 
> While I don't care much of the exact words, I think the terms "SDP", "RTP" and "media loopback" need all be in the title of the document. Your proposal misses "SDP", so, if you add it, I will agree.
> 
> BR,
> 
>      Miguel
> 
> On 21/11/2011 19:57, Hadriel Kaplan wrote:
>> 
>> 
>> 
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
> 
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 22 Nov 2011 07:43:19 +0100

Hi:

I suggested to rename the draft to: "An extension to SDP and RTP for 
media loopback".

While I don't care much of the exact words, I think the terms "SDP", 
"RTP" and "media loopback" need all be in the title of the document. Your 
proposal misses "SDP", so, if you add it, I will agree.

BR,

       Miguel

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

---

From: Nathan Stratton <[email-masked]>
Date: Mon, 21 Nov 2011 13:26:37 -0600

Looks good.

Sent from my iPhone

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 22 Nov 2011 09:12:16 +0100

Works for me.

/Miguel

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