Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 3 May 2010 20:27:32 +0530

These look good to me and flexible enough to also request a transcoder
to loopback a media stream. 

However, the RTP port numbers advertised by the source/mirror for the
in/out and from/to media stream pairs would typically be the same. Is it
legal/safe to pair m-lines that use the same IP address and port?

RFC3388 (section 7.5.3) forbids such an usage for the Flow
Identification (FID) group:

<snip>
   FID MUST NOT be used to group "m" lines with the same 
   IP address/port. Therefore, an SDP like the one below MUST NOT
   be generated.

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=audio 30000 RTP/AVP 8
       a=mid:2

   The correct SDP for the session above would be the following one:

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       m=audio 30000 RTP/AVP 0 8

   If two "m" lines are grouped using FID they MUST differ in their
   transport addresses (i.e., IP address plus port).
</snip>

Not sure, if this is applicable only to FID or there are generic SDP
grouping/paring issue.

If this is legal, can't the directionality be derived based on
sendonly/recvonly, instead of having to explicitly specify in/out or
from/out?

Offer:
   m=audio 41352 RTP/AVP 0 8
   a=loopback:source x
   a=sendonly
   m=audio 41352 RTP/AVP 112
   a=loopback:source x
   a=rtpmap:112 encaprtp/8000
   a=recvonly
   m=video 41362 RTP/AVP 116
   a=loopback:source y
   a=rtpmap:116 videostuff...
   a=sendonly
   m=video 41362 RTP/AVP 118
   a=loopback:source y
   a=rtpmap:118 encaprtp/8000
   a=recvonly

Answer:
   m=audio 54312 RTP/AVP 0
   a=loopback:mirror x
   a=recvonly
   m=audio 54312 RTP/AVP 112
   a=loopback:mirror x
   a=rtpmap:112 encaprtp/8000
   a=sendonly
   m=video 51362 RTP/AVP 116
   a=loopback:mirror y
   a=rtpmap:116 videostuff...
   a=recvonly
   m=video 51362 RTP/AVP 118
   a=loopback:mirror y
   a=rtpmap:118 encaprtp/8000
   a=sendonly

thanks,
Muthu

|-----Original Message-----
|From: Paul Kyzivat (pkyzivat)
|Sent: Friday, April 30, 2010 7:57 PM
|To: Muthu ArulMozhi Perumal (mperumal)
|Cc: Paul E. Jones; [email-masked]; [email-masked]
|Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions
|
|
|Muthu ArulMozhi Perumal (mperumal) wrote:
|> Paul,
|>
|> |So maybe the answer here is to always include both the "real"
formats
|> |*and* the encapulated formats in both the offer and the answer,
while
|> |using the loopback-source and loopback-mirror to determine who uses
|> what.
|>
|> Are you proposing something like this?
|>
|> Offer:
|>     m=audio 49170 RTP/AVP 0 112
|>     a=loopback:rtp-pkt-loopback
|>     a=loopback-source
|>     a=rtpmap:0 pcum/8000
|>     a=rtpmap:112 encaprtp/8000
|>
|> Answer:
|>     m=audio 49170 RTP/AVP 0 112
|>     a=loopback:rtp-pkt-loopback
|>     a=loopback-mirror
|>     a=rtpmap:0 pcum/8000
|>     a=rtpmap:112 encaprtp/8000
|>
|> This looks good, except that I am wondering what will happen if the
|> answerer doesn't support media loopback and hence doesn't understand
the
|> "encaprtp" encoding name. What will be the behavior if such an
answerer
|> is:
|> 1) UA
|> 2) SBC
|
|While putting both in "works" techically, it requires the mirror to lie
|by claiming it is willing to receive the encapsulated format when it is
|really only willing to send it.
|
|A more o/a friendly way of doing this would be:
|
|Offer:
|   m=audio 41352 RTP/AVP 0 8
|   a=loopback:source-out x
|   m=audio 41354 RTP/AVP 112
|   a=loopback:source-in x
|   a=rtpmap:112 rtploopback/8000
|
|Answer:
|   m=audio 54312 RTP/AVP 8
|   a=loopback:mirror-in x
|   m=audio 54320 RTP/AVP 112
|   a=loopback:mirror-out x
|   a=rtpmap:112 rtploopback/8000
|
|Above is just a thought off the top of my head, and carefully
|considered. There are many changes implied in the above compared to the
|current draft:
|
|- a stream to be looped can be represented by two m-lines,
|   one for the input side and one for the output side.
|
|- there is no loopback-source/loopback-mirror
|
|- a=loopback indicates:
|   - the role of the message sender (source or mirror)
|   - the direction of the stream (in/out)
|   - an identifier used to pair the two streams
|
|- There is no *explicit* distinction between packet and media
|   loopback. Its implicit in the pairing of two streams and
|   the formats that they contain. This pairing could also
|   be used to request transcoding between regular formats.
|   (Packet loopback can be viewed as just a special kind
|   of transcoder.)
|
|In the case of media loopback without transcoding, you typically won't
|need two m-lines. So in that case it gets simpler:
|
|Offer:
|   m=audio 41352 RTP/AVP 0 8
|   a=loopback:source
|
|Answer:
|   m=audio 54312 RTP/AVP 8
|   a=loopback:mirror
|
|In above, lack of in/out means both. And then the identifier to match
|streams isn't needed.
|
|Another variant can handle case where choice of who to mirror is
negotiated:
|
|Offer:
|   m=audio 41352 RTP/AVP 0 8
|   a=loopback:source/mirror
|
|Answer:
|   m=audio 54312 RTP/AVP 8
|   a=loopback:mirror
|
|Alternative Answer:
|   m=audio 54312 RTP/AVP 8
|   a=loopback:source
|
|If two streams are desired but mirroring is to be negotiated, then
there
|is need to select what formats are to be transcoded to what:
|
|Offer:
|   m=audio 41352 RTP/AVP 0 8
|   a=loopback:from x
|   m=audio 41354 RTP/AVP 112
|   a=loopback:to x
|   a=rtpmap:112 rtploopback/8000
|
|Answer:
|   m=audio 54312 RTP/AVP 8
|   a=loopback:mirror-in x
|   m=audio 54320 RTP/AVP 112
|   a=loopback:mirror-out x
|   a=rtpmap:112 rtploopback/8000
|
|Alternate Answer:
|   m=audio 54312 RTP/AVP 8
|   a=loopback:source-out x
|   m=audio 54320 RTP/AVP 112
|   a=loopback:source-in x
|   a=rtpmap:112 rtploopback/8000
|
|Here is a more comprehensive example:
|
|Offer:
|   m=audio 41352 RTP/AVP 0 8
|   a=loopback:source-out x
|   a=sendonly
|   m=audio 41354 RTP/AVP 112
|   a=loopback:source-in x
|   a=rtpmap:112 rtploopback/8000
|   a=recvonly
|   m=video 41362 RTP/AVP 116
|   a=loopback:from y
|   a=rtpmap:116 videostuff...
|   a=sendrecv
|   m=video 41364 RTP/AVP 118
|   a=loopback:to y
|   a=rtpmap:112 rtploopback/8000
|   a=sendrecv
|
|Answer:
|   m=audio 54312 RTP/AVP 8
|   a=loopback:mirror-in x
|   a=recvonly
|   m=audio 54320 RTP/AVP 112
|   a=loopback:mirror-out x
|   a=rtpmap:112 rtploopback/8000
|   a=sendonly
|   m=video 54382 RTP/AVP 120
|   a=loopback:mirror-in y
|   a=rtpmap:120 videostuff...
|   a=recvonly
|   m=video 54384 RTP/AVP 118
|   a=loopback:mirror-out y
|   a=rtpmap:112 rtploopback/8000
|   a=sendonly

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 May 2010 11:55:33 -0400

> legal/safe to pair m-lines that use the same IP address and port?

That's a mistake in my examples. It should be as follows:

If the same format is used for the source and the mirror, then there 
will be only one m-line used bidirectionally. In case where different 
formats are used in the two directions, then different ports should be used.

> sendonly/recvonly, instead of having to explicitly specify in/out or

I thought about that. It *can* be derived that way in some cases. Cases 
where it cannot are when the offerer is willing to be either the source 
or the mirror. In that case it must make both streams sendrecv.

	Thanks,
	Paul

---

From: "Kumar, Satish" <[email-masked]>
Date: Thu, 6 May 2010 09:32:05 -0500

Hi All,

	I need to revisit my original question here. As per below explanation the SDP stated in draft (just above sec 5.4) is wrong. Here is the snapshot.

Example:       m=audio 41352 RTP/AVP 112
               a=loopback:rtp-pkt-loopback
               a=loopback-source:0 8
               a=rtpmap:112 rtploopback/8000
                      ^^^^^^^
Hi Paul E,
Can I safely assume that for rtp-loopback, payload type change is not allowed?  Please let me know.

Thx, Satish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, April 30, 2010 8:27 AM
To: Muthu ArulMozhi Perumal (mperumal)
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions

Muthu ArulMozhi Perumal (mperumal) wrote:
> Paul,
> 
> |So maybe the answer here is to always include both the "real" formats 
> |*and* the encapulated formats in both the offer and the answer, while 
> |using the loopback-source and loopback-mirror to determine who uses
> what.
> 
> Are you proposing something like this?
> 
> Offer:
>     m=audio 49170 RTP/AVP 0 112
>     a=loopback:rtp-pkt-loopback
>     a=loopback-source
>     a=rtpmap:0 pcum/8000
>     m=audio 49170 RTP/AVP 0 112
>     a=loopback:rtp-pkt-loopback
>     a=loopback-mirror
>     a=rtpmap:0 pcum/8000
> This looks good, except that I am wondering what will happen if the
> answerer doesn't support media loopback and hence doesn't understand the
> "encaprtp" encoding name. What will be the behavior if such an answerer
> is:
> 1) UA
> 2) SBC

While putting both in "works" techically, it requires the mirror to lie 
by claiming it is willing to receive the encapsulated format when it is 
really only willing to send it.

A more o/a friendly way of doing this would be:

Offer:
   m=audio 41352 RTP/AVP 0 8
   a=loopback:source-out x
   m=audio 41354 RTP/AVP 112
   a=loopback:source-in x
   a=rtpmap:112 rtploopback/8000

Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:mirror-in x
   m=audio 54320 RTP/AVP 112
   a=loopback:mirror-out x
   a=rtpmap:112 rtploopback/8000

Above is just a thought off the top of my head, and carefully 
considered. There are many changes implied in the above compared to the 
current draft:

- a stream to be looped can be represented by two m-lines,
   one for the input side and one for the output side.

- there is no loopback-source/loopback-mirror

- a=loopback indicates:
   - the role of the message sender (source or mirror)
   - the direction of the stream (in/out)
   - an identifier used to pair the two streams

- There is no *explicit* distinction between packet and media
   loopback. Its implicit in the pairing of two streams and
   the formats that they contain. This pairing could also
   be used to request transcoding between regular formats.
   (Packet loopback can be viewed as just a special kind
   of transcoder.)

In the case of media loopback without transcoding, you typically won't 
need two m-lines. So in that case it gets simpler:

Offer:
   a=loopback:source

Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:mirror

In above, lack of in/out means both. And then the identifier to match 
streams isn't needed.

Another variant can handle case where choice of who to mirror is negotiated:

Offer:
   a=loopback:source/mirror

Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:mirror

Alternative Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:source

If two streams are desired but mirroring is to be negotiated, then there 
is need to select what formats are to be transcoded to what:

Offer:
   m=audio 41352 RTP/AVP 0 8
   a=loopback:from x
   m=audio 41354 RTP/AVP 112
   a=loopback:to x
   a=rtpmap:112 rtploopback/8000

Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:mirror-in x
   m=audio 54320 RTP/AVP 112
   a=loopback:mirror-out x
   a=rtpmap:112 rtploopback/8000

Alternate Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:source-out x
   m=audio 54320 RTP/AVP 112
   a=loopback:source-in x
   a=rtpmap:112 rtploopback/8000

Here is a more comprehensive example:

Offer:
   m=audio 41352 RTP/AVP 0 8
   a=loopback:source-out x
   a=sendonly
   m=audio 41354 RTP/AVP 112
   a=loopback:source-in x
   a=rtpmap:112 rtploopback/8000
   a=recvonly
   m=video 41362 RTP/AVP 116
   a=loopback:from y
   a=rtpmap:116 videostuff...
   a=sendrecv
   m=video 41364 RTP/AVP 118
   a=loopback:to y
   a=rtpmap:112 rtploopback/8000
   a=sendrecv

Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:mirror-in x
   a=recvonly
   m=audio 54320 RTP/AVP 112
   a=loopback:mirror-out x
   a=rtpmap:112 rtploopback/8000
   a=sendonly
   m=video 54382 RTP/AVP 120
   a=loopback:mirror-in y
   a=rtpmap:120 videostuff...
   a=recvonly
   m=video 54384 RTP/AVP 118
   a=loopback:mirror-out y
   a=rtpmap:112 rtploopback/8000
   a=sendonly

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 6 May 2010 16:21:48 -0400

Satish,

I think we need a few experts to weigh in on this one. My reading suggested
it was, but others suggested that my interpretation was wrong. Indeed, when
I re-read the offer/answer document I could see where I was wrong.

Still, I'd rather have others comment on the list if they feel the
procedures are flawed.

Paul

> From: Kumar, Satish [mailto:[email-masked]]
> Sent: Thursday, May 06, 2010 10:32 AM
> To: Paul Kyzivat; Muthu ArulMozhi Perumal (mperumal); Paul E. Jones
> Subject: RE: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions
> 
> Hi All,
> 
> 	I need to revisit my original question here. As per below
> explanation the SDP stated in draft (just above sec 5.4) is wrong. Here
> is the snapshot.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 21 May 2010 11:14:15 -0400

Satish,

The draft isn't expired, yet.  The -13 draft expires in October.

The authors (at least most of us) had a meeting two weeks ago on this.  I
believe there was general agreement that a few places could use some
editorial changes to make it clearer.

However, there was a desire not to remove the current loopback modes,
because there are a number of implementations in the field.

The reason for having to change the PT is primary for encapsulation, I
think.  (Note: I didn't add that to the spec.  It came in sometime over the
past 6 years, but not sure when/why.)  When not encapsulating, I don't think
it would be necessary to change the PT, but these are some of the things
that I hope will be clarified in the document.

Paul

> Sent: Friday, May 21, 2010 9:02 AM
> To: Paul E. Jones; [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-ietf-mmusic-media-loopback-13 questions
> 
> Hi Paul,
> 
> 	Currently the draft is in expired state. Is there any plan to
> revise the draft? If so can you please re-consider the idea of dropping
> the RTP encapsulation mode?
> 
> I do not understand and question why RTP loopback, specifically,
> encapsulated rtp loopback modes are now "potentially" going to be used
> to measure performance statistics. Detailed performance statistics and
> metrics are already available in RTCP-XR (RFC3611 indicates that packet
> level statistics pertaining to packets sent/received/lost, jitter
> measurements, round-trip delay measurements are all available via RTCP-
> XR blocks). The encapsulated loopback mode potentially does provide a
> detailed record of individual packet arrivals for the test flow.
> 
> One more point of concern is regarding the payload type. We briefly
> discussed this as well but why in the direct loopback modes (type pkt
> and media) does the recipient has to potentially change the payload
> type. It does not make any sense. The entire purpose of loopback is
> just to re-transmit the RTP packet received either like a mirror(no
> processing) or after decode and re-encode. The mirror SHOULD NOT have
> to manipulate the RTP header. Is there a valid use case for this which
> I am missing here? This requirement should also be reviewed and
> hopefully removed.
> 
> -Satish
> 
> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Thursday, April 29, 2010 9:53 AM
> To: Kumar, Satish; [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-ietf-mmusic-media-loopback-13 questions
> 
> Satish,
> 
> > 1. Loopback will be good to ensure the path is still valid and every
> > one is alive. You can use the direct loopback to get that
> information.
> > It is still not clear how the RTP encapsulation mode will be used. Is
> > there some benefit in encapsulation or is this something that was put
> > into a draft because it sounds like a good thing to do?
> 
> I don't know who asked for encapsulation or why it was introduced
> later, but
> I had no objection to it.  It seems somewhat useful when one really
> just
> wants to mirror the contents of what is received back to the sender.
> The
> outermost RTP header serves to get the packets end-to-end while the
> inner
> layer is a preservation of what was originally transmitted.
> 
> One issue I see, though, is that we have four modes of operation:
> 
> Direct/loopback-type-pkt
> Direct/loopback-type-media
> Encapsulated/loopback-type-pkt
> Encapsulated/loopback-type-media
> 
> This seems a bit much, in my opinion.  But, over 6 years this kind of
> feature creep occurs.  I'd be content to reduce this set :-)
> 
> > 2. Does these loopback apply to RTCP as well?
> 
> No.
> 
> Paul
> 
>

---

From: "Kumar, Satish" <[email-masked]>
Date: Fri, 21 May 2010 08:01:56 -0500

Hi Paul,

	Currently the draft is in expired state. Is there any plan to revise the draft? If so can you please re-consider the idea of dropping the RTP encapsulation mode? 

I do not understand and question why RTP loopback, specifically, encapsulated rtp loopback modes are now "potentially" going to be used to measure performance statistics. Detailed performance statistics and metrics are already available in RTCP-XR (RFC3611 indicates that packet level statistics pertaining to packets sent/received/lost, jitter measurements, round-trip delay measurements are all available via RTCP-XR blocks). The encapsulated loopback mode potentially does provide a detailed record of individual packet arrivals for the test flow.  

One more point of concern is regarding the payload type. We briefly discussed this as well but why in the direct loopback modes (type pkt and media) does the recipient has to potentially change the payload type. It does not make any sense. The entire purpose of loopback is just to re-transmit the RTP packet received either like a mirror(no processing) or after decode and re-encode. The mirror SHOULD NOT have to manipulate the RTP header. Is there a valid use case for this which I am missing here? This requirement should also be reviewed and hopefully removed.

-Satish

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Thursday, April 29, 2010 9:53 AM
To: Kumar, Satish; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-mmusic-media-loopback-13 questions

Satish,

> one is alive. You can use the direct loopback to get that information.

I don't know who asked for encapsulation or why it was introduced later, but
I had no objection to it.  It seems somewhat useful when one really just
wants to mirror the contents of what is received back to the sender.  The
outermost RTP header serves to get the packets end-to-end while the inner
layer is a preservation of what was originally transmitted.

Direct/loopback-type-pkt 

No.

Paul

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 26 May 2010 13:41:54 +0530

Satish,

As mentioned by Paul, draft-ietf-mmusic-media-loopback-13 expires only
in October and the next revision should be out soon.

RTCP isn't supported by all endpoints/vendors today, leave out RTCP-XR.
In addition, using RTCP you hear about the quality of media reception
from the receiver. On the other hand, using media loopback you determine
that yourself, for e.g by watching your video in a Telepresence screen
when you stand in front of it. So, it provides an option to vendors to
support what they want. 

My understanding about the direct RTP loopback type is that it was
requested by vendors to simplify the implementation in hardware. So,
there is no plan to drop it.

On your comment on the payload type for direct loopback mode -- the
draft does not mandate to change the payload type. The loopback-mirror
is free to choose whatever payload type it wants (including the one
chosen by the loopback-source), as far it indicates what it chooses in
the loopback answer.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of
|Paul E. Jones
|Sent: Friday, May 21, 2010 8:44 PM
|To: 'Kumar, Satish'; [email-masked]
|Cc: 'Nagarjuna Venna'; [email-masked]
|Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions
|
|Satish,
|
|The draft isn't expired, yet.  The -13 draft expires in October.
|
|The authors (at least most of us) had a meeting two weeks ago on this.
I
|believe there was general agreement that a few places could use some
|editorial changes to make it clearer.
|
|However, there was a desire not to remove the current loopback modes,
|because there are a number of implementations in the field.
|
|The reason for having to change the PT is primary for encapsulation, I
|think.  (Note: I didn't add that to the spec.  It came in sometime over
the
|past 6 years, but not sure when/why.)  When not encapsulating, I don't
think
|it would be necessary to change the PT, but these are some of the
things
|that I hope will be clarified in the document.
|
|Paul
|
|> -----Original Message-----
|> From: Kumar, Satish [mailto:[email-masked]]
|> Sent: Friday, May 21, 2010 9:02 AM
|> To: Paul E. Jones; [email-masked]
|> Cc: [email-masked]
|> Subject: RE: draft-ietf-mmusic-media-loopback-13 questions
|>
|> Hi Paul,
|>
|> 	Currently the draft is in expired state. Is there any plan to
|> revise the draft? If so can you please re-consider the idea of
dropping
|> the RTP encapsulation mode?
|>
|> I do not understand and question why RTP loopback, specifically,
|> encapsulated rtp loopback modes are now "potentially" going to be
used
|> to measure performance statistics. Detailed performance statistics
and
|> metrics are already available in RTCP-XR (RFC3611 indicates that
packet
|> level statistics pertaining to packets sent/received/lost, jitter
|> measurements, round-trip delay measurements are all available via
RTCP-
|> XR blocks). The encapsulated loopback mode potentially does provide a
|> detailed record of individual packet arrivals for the test flow.
|>
|> One more point of concern is regarding the payload type. We briefly
|> discussed this as well but why in the direct loopback modes (type pkt
|> and media) does the recipient has to potentially change the payload
|> type. It does not make any sense. The entire purpose of loopback is
|> just to re-transmit the RTP packet received either like a mirror(no
|> processing) or after decode and re-encode. The mirror SHOULD NOT have
|> to manipulate the RTP header. Is there a valid use case for this
which
|> I am missing here? This requirement should also be reviewed and
|> hopefully removed.
|>
|> -Satish

---

From: "Kumar, Satish" <[email-masked]>
Date: Thu, 27 May 2010 09:14:24 -0500

Hi Muthu,
	Thanks for the reply. I am not able to find the use case for re-encapsulating RTP header in RTP payload. What are we achieving by making the end point to put the received RTP header in payload and sending it back to the source. This is defined in rtp-pkt-loopback.

The rtp-media-loopback confirms that 'all is well' at the end point. This mode confirms the health of encoder/decoder functions too. Why do we even need rtp-pkt-loopback?

-Satish

-----Original Message-----
From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]] 
Sent: Wednesday, May 26, 2010 2:12 AM
To: Paul E. Jones; Kumar, Satish; [email-masked]
Cc: Nagarjuna Venna; [email-masked]
Subject: RE: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions

Satish,

Muthu

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 27 May 2010 23:07:52 +0530

Satish,

|What are we achieving by making the end point to put the received 
|RTP header in payload and sending it back to the source. This is 
|defined in rtp-pkt-loopback.

The payload header of the encapsulated RTP packets sent by the
loopback-mirror is not exactly the same as RTP header of the packets
sent by the loopback-source, but quite close. I see the payload header
has the following benefits:
1. The receive timestamp in the payload header would help the
loopback-source to compute both the RTT and the time taken by the
loopback-mirror to process the packet -- without the receive timestamp
the loopback-source can compute only the sum of the two.
2. The sequence number in the payload header would help the
loopback-source to determine the number of packets lost in the direction
from the loopback-source to the loopback-mirror -- without this sequence
number, the loopback-source can compute only number of packets lost in
the directions from the loopback-mirror to the loopback-source.

I am not able to think of any immediate benefits of the SSRC and CSRC
identifiers in the payload header, but I guess there might by some.

|The rtp-media-loopback confirms that 'all is well' at the end point. 
|This mode confirms the health of encoder/decoder functions too. Why
|do we even need rtp-pkt-loopback?

The problem arises if something isn't well :). The media loopback won't
tell you if the issue is with the media path or the encoder/decoder
function. This is where the rtp-pkt-loopback that tests the media path
comes handy.

Muthu

|-----Original Message-----
|From: Kumar, Satish [mailto:[email-masked]]
|Sent: Thursday, May 27, 2010 7:44 PM
|To: Muthu ArulMozhi Perumal (mperumal); Paul E. Jones;
[email-masked]
|Cc: Nagarjuna Venna; [email-masked]
|Subject: RE: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions
|
|Hi Muthu,
|	Thanks for the reply. I am not able to find the use case for re-
|encapsulating RTP header in RTP payload. What are we achieving by
making the
|end point to put the received RTP header in payload and sending it back
to
|the source. This is defined in rtp-pkt-loopback.
|
|The rtp-media-loopback confirms that 'all is well' at the end point.
This
|mode confirms the health of encoder/decoder functions too. Why do we
even
|need rtp-pkt-loopback?
|
|-Satish
|
|-----Original Message-----
|From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
|Sent: Wednesday, May 26, 2010 2:12 AM
|To: Paul E. Jones; Kumar, Satish; [email-masked]
|Cc: Nagarjuna Venna; [email-masked]
|Subject: RE: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions
|
|Satish,
|
|As mentioned by Paul, draft-ietf-mmusic-media-loopback-13 expires only
|in October and the next revision should be out soon.
|
|RTCP isn't supported by all endpoints/vendors today, leave out RTCP-XR.
|In addition, using RTCP you hear about the quality of media reception
|from the receiver. On the other hand, using media loopback you
determine
|that yourself, for e.g by watching your video in a Telepresence screen
|when you stand in front of it. So, it provides an option to vendors to
|support what they want.
|
|My understanding about the direct RTP loopback type is that it was
|requested by vendors to simplify the implementation in hardware. So,
|there is no plan to drop it.
|
|On your comment on the payload type for direct loopback mode -- the
|draft does not mandate to change the payload type. The loopback-mirror
|is free to choose whatever payload type it wants (including the one
|chosen by the loopback-source), as far it indicates what it chooses in
|the loopback answer.
|
|Muthu