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

From: Tom Taylor <[email-masked]>
Date: Tue, 10 Aug 2010 15:59:43 -0400

As an aid to my understanding of the media-loopback draft and judgement of its 
readiness to go forward, I have assembled a complete history of list discussion 
going back to the initial submission in 2004. As a side note, the critical 
discussions regarding the use of encapsulation occurred in early August, 2006. 
See http://www.ietf.org/mail-archive/web/mmusic/current/mail8.html.

I have noted a number of places where the text could be clearer. I can work out 
this editorial stuff with the authors in short order, but the points below 
should be considered first.

---------------------------------------------------------------------

Preliminary note: the document fails a number of idnits checks. These will have 
to be fixed. I can give you private guidance if you need help. The RFC Editor 
will probably also require you to drop one of your authors (limit is 5). You 
could have an "Additional Authors" section if necessary to acknowledge the other 
person.

---------------------------------------------------------------------

Use Cases
=========

I propose that the following text be added as a subsection of the Introduction. 
Your verification of this text also verifies my understanding of the document.

<proposed new text>
1.1 Use Cases Supported

As a matter of terminology in this document, packets flow from one peer acting 
as a "loopback source", to the other peer acting as a "loopback mirror", which 
in turn returns packets to the loopback source. In advance of the session, the 
peers negotiate to determine which one acts in which role. The negotiation also 
includes details such as the type of loopback to be used.

This specification supports three use cases: "encapsulated packet loopback", 
"direct loopback", and "media loopback". These are distinguished by the 
treatment of incoming RTP packets at the loopback mirror.

As a supplement to these use cases, this specification also allows the loopback 
source to request the loopback mirror to begin sending a media stream to the 
loopback source, ending when the mirror begins to receive packets from the 
source. This facility is needed in some circumstances to establish the media 
path through middleboxes lying between the peers.

1.1.1 Encapsulated Packet Loopback

In the encapsulated packet loopback case, the entire incoming RTP packet is 
encapsulated as payload within an outer payload type that is specific to this 
use case and specified below (Section 7.1).  The encapsulated packet is returned 
to the loopback source.  The loopback source can generate statistics for one-way 
path performance up to the RTP level for each direction of travel by examining 
sequence numbers and timestamps in the outer header and the encapsulated RTP 
packet payload. The loopback source can also play back the returned media 
content for evaluation.

Because the encapsulating payload extends the packet size, it could encounter 
difficulties in an environment where the original RTP packet size is close to 
the path MTU size.  The encapsulating payload type therefore offers the 
possibility of RTP-level fragmentation of the returned packets.  The use of this 
facility could affect statistics derived for the return path.  In addition, the 
increased bit rate required in the return direction may affect these statistics 
more directly in a restricted-bandwidth situation.

1.1.2 Direct Loopback

In the direct loopback case, the loopback mirror copies the payload of the 
incoming RTP packet into a new packet, the payload type of which is again 
specific to this use case and specified below (Section 7.2).  The loopback 
mirror returns the new packet to the packet source. There is no provision in 
this case for RTP-level fragmentation.

This use case has the advantage of keeping the packet size the same in both 
directions.  The packet source can compute only two-way path statistics from the 
direct loopback packet header, but can play back the returned media content.

     It has been suggested that the loopback source, knowing that the
     incoming packet will never be passed to a decoder, can store a
     timestamp and sequence number inside the payload of the packet it
     sends to the mirror, then extract that information from the returned
     direct loopback packet and compute one-way path statistics as in the
     previous case. Obviously, playout of returned content is no longer
     possible if this is done.

[Open issue here: does any RTP header extension in the incoming packet get 
discarded along with the rest of the header? That's probably OK given that 
header extensions are defined as non-essential to the decoding process, but we 
should think about it a moment. -- PTT]

1.1.3 Media Loopback

In the media loopback case, the loopback mirror submits the incoming packet to a 
decoder appropriate to the incoming payload type. The packet is taken as close 
as possible to the analog level, then reencoded according to an outgoing format 
determined by negotiation. The reencoded content is returned to the loopback 
source as an RTP packet with payload type corresponding to the reencoding format.

This usage allows trouble-shooting at the codec level. The capability for path 
statistics is limited to what is available from RTCP reports.
</proposed new text>

----------------------------------------------------------------------------

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].

---------------------------------------------------------------

Acknowledgements:

Colin Perkins gave a lot of guidance through the early versions of this 
document. You really shouldn't miss him out from the Acknowledgements section.