Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-06.txt

From: "Venna, Nagarjuna" <[email-masked]>
Date: Tue, 5 Jun 2007 10:41:53 -0400

Hi Rick,

Here is an attempt at addressing your comments:

1. While it is plausible to compare plaintext/encrypted performance,
there is no guarantee that in direct loopback mode the mirror would
actually decrypt the payload. In the general case, you can not depend on
it. 

2. In media loopback mode, the packets go through the jitter buffer.
Using the inner timestamp portion as you suggested would work only for
encapsulated payload format.

3. I think the authors chose a different m=line as the start loopback
stream is logically a different media stream.

4. The overhead is only for encapsulated format, there is no overhead if
you are using direct loopback. With direct loopback, the sender can put
data in the payload that can help it compute metrics it is interested in
(after setting the appropriate payload type) as this data will be
returned unchanged by the mirror. This mode however has limitations
(related to MTU) as specified in the draft. 

Thanks,
Nagarjuna

-----Original Message-----
From: Rick Porter [mailto:[email-masked]] 
Sent: Wednesday, May 09, 2007 2:17 PM
To: [email-masked]
Subject: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-06.txt

Here are a few comments/questions...

1. Where does SRTP encryption/decryption come when doing packet
loopback? For media loopback, you obviously need to decrypt any
encrypted packets. If you're on a link that "always" does SRTP, I would
think that you'd want to be able to see how much jitter/loss/latency is
introduced by encryption/decryption and possibly compare
plaintext/encrypted performance.

2. Should looped back packets go thru the jitter buffer on the mirror?
If they do not, the jitter for a call will be compounded. If they do,
the latency is increased--depending on implementation, you may be able
to subtract jitter-buffer delay if the inner timestamp portion of the
encapsulated packet is set to the received timestamp (instead of simply
repeating the RTP timestamp). 

3. Can we reduce SDP to have a single media-description, even when
mirror initially sends packets? I think the session should only have one
media stream, and the second media-description/stream may confuse
non-loopback aware devices who handle the media (e.g. SBCs).

4. With packet loopback, can/should the mirror truncate the last 16
bytes of RTP payload to preserve RTP characteristics? In many
situations, I think the RTP header should be sufficient for processing.
However, I do see some situations where a device in the middle could
potentially transcode RTP packets so that the mirror does not receive
the original RTP and it may be desirable to have the whole RTP payload. 

Cheers,
Rick

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic