[MMUSIC] Media loopback revisited (draft-ietf-mmusic-media-loopback-15.txt)

[Flemming Andreasen <[e-mail]>]

Hi

I have taken a look at the updated media-loopback draft

     
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-15.txt 
<http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-15.txt>

and I consider it to be a subtantial improvement over v14. I still have 
two signficant comments, both of which probably require discussion with 
our ADs and/or the Payload WG chairs, however it would be useful for the 
MMUSIC WG participants to give their view on these as well:

1) Alternative NAT traversal mechanism (Section 5.7)
One general question/comment for the group and our ADs, and two 
technical comments as well
1a) The draft defines an alternative NAT traversal mechanism instead of 
ICE, and this mechanism will only work in certain deployment scenarios 
under certain assumptions. The draft does say that ICE is the preferred 
mechanism and the alternative specified here should only be used if ICE 
is not available and you fulfill the deployment scenario requirements.  
Considering the intended status of the document is Proposed Standard, is 
this acceptable ?

1b) The draft allows for the answerer to add this NAT traversal 
mechanism as a media format to the answer, even if the offer did not 
include it. The draft furthermore requires the offerer to accept use of 
this mechanism then. This breaks normal O/A behavior and I don't see any 
good reason to do so. If the offerer supports and is willing to use this 
mechanism, he should include it in the offer.

1c) The draft seems to assume what is commonly referred to as latching 
behavior by the loopback-source inasmuch as in order for the mechanism 
to work, the loopback-source must send packets to the observed source 
IP-address and port rather than what was negotiated in the SDP. This 
operation however is not explained in the draft, and it needs to be 
(with a MUST).


2) Definition of several new RTP payload formats (Sections 7, 8, and 14.2)
The draft defines several new RTP payload formats, however, as far as I 
know, the draft has not been reviewed in the PAYLOAD WG (or AVT prior to 
that). Ideally, there would be two different drafts, with the RTP 
payload part handled in PAYLOAD, and the other part handled in MMUSIC, 
however I'm sympathetic to the fact that we are on v15 of this draft.


I have a few detailed comments as well that should be relatively easy to 
resolve, however I'll defer those until we figure out a path forward on 
the above.

Thanks

-- Flemming