Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback readiness for publication

From: Tom Taylor <[email-masked]>
Date: Thu, 21 Oct 2010 12:46:13 -0400

I've consulted with others on the offer-answer issue, to make sure I 
wasn't just imposing my own engineering preferences. The advice I 
received was that the current text is indeed problematic and needs 
fixing. In particular, you can expect a detailed review from Flemming.

Flemming also noted that new payload types need review by AVT. We'll 
have to get them involved either now or after the next version of the draft.

On 17/09/2010 4:03 PM, Kaynam Hedayat wrote:
> Tom,
>
> Thanks for the notes and my sincere apologies for the late response.
>
> Here are my thoughts on your specific comments.
>
...

>
> 4. On RTP header extensions: In direct loopback, I expect that most
> mirrors will retain the extensions. Mostly because, the mirror is
> probably going to change a few bits in the packet that it receives
> before sending it back. Of course, this is implementation specific and I
> think the draft should be agnostic about it.
>
> 5. Your point #2 on offer-answer model is the most contentious thing in
> the draft. The original problem we tried to address was that the
> encapsulated and direct loopback modes require a different specific
> payload on the mirror to source direction. With existing SDP mechanisms,
> this would require two different m=lines which we thought would be very
> confusing (one with a=sendonly and one with a=recvonly attributes). One
> of the concerns I have is that there are quite a few implementations of
> the draft out there and while the changes you are suggesting may make
> things simpler, I would rather not change things unless what we are
> doing violates the standards and impacts them in a negative manner.
>
> 6. Colin, indeed, helped us quite a bit on this draft and it is a
> mistake on our part not to include his name.
>
> Regards,
> Kaynam
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tom Taylor
> Sent: Tuesday, August 10, 2010 4:00 PM
...
> ------------------------------------------------------------------------
> ----
>
> Offer-Answer model
> ==================
>
> Given recent discussion, I paid particular attention to the offer-answer
> syntax.
> The existing syntax overrides RFC 4566 in two ways:
>
> (1) a=loopback-source and a=loopback-mirror assign directionality to the
> formats
> specified on the m= line, in the same way that a=sendonly and a=recvonly
> do.
> (Section 5.2). Probably OK, but the redundancy of functionality is
> unfortunate
> and the mirror can't pause an incoming loopback stream using a=sendonly
> or
> a=inactive.
>
> (2) a=rtpmap is used to qualify payload type values found in another
> attribute
> line as well as payload type values found on the m= line. (Section 5.3)
> This one
> is a bit scary. At a minimum, to avoid ambiguity, I would expect that
> you would
> have to specify that the payload type numbers used on the a= lines would
> have to
> differ from those used in the m= line unless the media formats involved
> were
> exactly the same. Putting this into more general terms (not mentioning
> payload
> type numbers) could be difficult, but I think I know how to do it if it
> comes to
> that.
>
> It seems to me this structure was put into place before the latest
> tweaking of
> use cases (eliminating the use of encapsulation for media loopback). By
> their
> nature, encapsulated packet loopback and direct loopback are independent
> of the
> payload types of the incoming packets. What comes in is what goes out,
> buried
> inside the new payload type. To satisfy the needs of systems that don't
> understand the encapsrtp or rtploopback formats, it suffices to put all
> of the
> media types in the m= line. Possibly the convention would be to put the
> encapsulating formats first in the media description for the loopback
> mirror,
> and last in the list in the media description for the loopback source.
>
> The only time you need to specify what comes in and what goes out
> explicitly is
> in the media loopback case. Thus the incoming and outgoing formats
> logically go
> with a choice of a=loopback:rtp-media-loopback, not with the loopback
> mode. I
> would suggest a new attribute:
>
>      "a=loopback-format:" input-fmt-list "/" output-fmt-list
>
> input-fmt-list = 1*(SP fmt) ; incoming payload types
> output-fmt-list = 1*(SP fmt) ; outgoing payload types
>
> ; fmt has the definition and semantics given in [RFC4566].
>
>
> ---------------------------------------------------------------
...