Subject: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-13

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 27 Apr 2010 18:46:52 +0530

Hi All,
 
A few comments on the latest draft:
 
1) When a loopback-source sends an offer requesting rtp-media-loopback,
can the codecs this loopback-source is willing to send and expecting to
receive be different? For e.g, is the following a offer valid?
 
m=audio 41352 RTP/AVP 0
a=loopback:rtp-media-loopback
a=loopback-source:8
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
 
The draft doesn't explicitly mention that such an offer can be sent nor
seem to prevent it. This could be useful for testing whether a
transcoding function in an intermediate SBC or media relay works well.
If this is valid, can we add examples illustrating it?
 
2) In direct RTP loopback the RTP packet echoed back by the
loopback-mirror has no payload specific header. How can the
loopback-source or an intermediate RTP relay derive the encoding format
of this RTP packet and process it? It can be argued that the
loopback-source knows that the encoding format of this RTP packet is the
same as what it sent, but then why have a PT field in the payload
structure when the encapsulated RTP loopback is used?
 
3) Section 11.3:
A server sends a response with SDP which looks like:
 
    v=0
    o=user1 2890844526 2890842807 IN IP4 192.0.2.11
    s=Example
    i=An example session
    e=[email-masked]
    c=IN IP4 192.0.2.12/127
    t=0 0
    m=audio 49270 RTP/AVP 113
    a=loopback:rtp-pkt-loopback
    a=loopback-mirror:0 114
    a=rtpmap:0 pcmu/8000
    a=rtpmap:113 rtploopback/8000
    a=rtmpa:114 loopbkprimer/8000
 
Shouldn't the loopbkprimer PT (114) be specified in the m-line (rather
than in a=loopback-mirror) since that is what the server is willing to
send?
 
4) Section 7.2.3
The payload type number for the payload loopback stream can be
negotiated using a mechanism like SDP.
                                ^^^^^^^^^^^^^^^^
                                direct loopback?
 
Muthu

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Apr 2010 16:43:27 -0400

Muthu,

1) "a=rtpmap:8 pcma/8000" is used to map a payload type on the m= line to a
particular media type.  8 is not specified anywhere, so I'd think it should
be ignored (or rejected, though I prefer ignoring)

2) Why would an intermediary need to?  It should be echoed as-is.  But, you
ask a good question: why do we need the direct loopback option?  The only
benefit is to avoid packet fragmentation, but it's hard to imagine where
that would be a real issue.  I personally prefer the encapsulation option.

3) I assume the "rtmpa" line is typo.  And I think you're right that it
should be on the m= line.

4) I think this is right.  "Ecapsulated steam" is used for the encapsulated
form.  "Payload loopback" is used for the "direct loopback".  But, I agree
it would read better if we changed it as you suggest.

Kaynam, comments?

Paul

From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]] 
Sent: Tuesday, April 27, 2010 9:17 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]
Cc: [email-masked]
Subject: Comments on draft-ietf-mmusic-media-loopback-13

Hi All,

1) When a loopback-source sends an offer requesting rtp-media-loopback, can
the codecs this loopback-source is willing to send and expecting to receive
be different? For e.g, is the following a offer valid?

m=audio 41352 RTP/AVP 0

a=loopback-source:8

a=rtpmap:0 pcmu/8000

a=rtpmap:8 pcma/8000

The draft doesn't explicitly mention that such an offer can be sent nor seem
to prevent it. This could be useful for testing whether a transcoding
function in an intermediate SBC or media relay works well. If this is valid,
can we add examples illustrating it?

2) In direct RTP loopback the RTP packet echoed back by the loopback-mirror
has no payload specific header. How can the loopback-source or an
intermediate RTP relay derive the encoding format of this RTP packet and
process it? It can be argued that the loopback-source knows that the
encoding format of this RTP packet is the same as what it sent, but then why
have a PT field in the payload structure when the encapsulated RTP loopback
is used?

3) Section 11.3:

    v=0

    s=Example

    i=An example session

    e=[email-masked]

    c=IN IP4 192.0.2.12/127

    t=0 0

    a=loopback-mirror:0 114

    a=rtpmap:0 pcmu/8000

Shouldn't the loopbkprimer PT (114) be specified in the m-line (rather than
in a=loopback-mirror) since that is what the server is willing to send?

4) Section 7.2.3

The payload type number for the payload loopback stream can be negotiated
using a mechanism like SDP.

                                ^^^^^^^^^^^^^^^^

                                direct loopback?

Muthu

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 28 Apr 2010 08:43:08 +0530

[Trimming the message and resending, since mmusic seems to have a
message limit of 50 KB]
 
Hi Paul,
 
> 1) "a=rtpmap:8 pcma/8000" is used to map a payload type on the m= line
to a particular media type.
 
Consider the example described in section 11.2:

    v=0
    o=user1 2890844526 2890842807 IN IP4 192.0.2.11
    s=Example
    i=An example session
    e=[email-masked]
    c=IN IP4 192.0.2.12/127
    t=0 0
    m=audio 49270 RTP/AVP 112
    a=loopback:rtp-pkt-loopback
    a=loopback-mirror:0
    a=rtpmap:0 pcmu/8000
    a=rtpmap:112 encaprtp/8000
 
Here, "a=rtpmap:0 pcmu/8000" describes a payload type listed in
"a=loopback-mirror", but not in the "m=" line. Without extending
"a=rtpmap" to map payload types listed in "a=loopback-source" and
"a=loopback-mirror", I don't see how rtp-pkt-loopback would actually
work, because the send and receive payload types will be different for
both loopback-source and loopback-mirror. I think the draft needs to
describe this extension to "a=rtpmap". Perhaps, we want to name it
"a=rtp-loopback-map"?
 
Now, one of the primary motivations for rtp-media-loopback seems to be
the ability to test whether all the encoding/decoding functions are
actually working in a media processing element, rather than just test
the media path. All I am trying to see is, if the same can be used to
test a transcoder that I know can transcode b/w two codecs. I think this
would be a useful capability for enterprises and service providers.
 
2) Why would an intermediary need to?
  
Consider a distributed SBC where the signaling plane programs the media
plane to provide certain level of QoS for certain RTP payloads. Now, if
the RTP packet doesn't carry the payload type used for
encoding/decoding, there is no way this will work. Of course, the
distributed SBC would need an upgrade to understand the packet formats
for rtp-pkt-loopback, but as far as the RTP packets carry the payload
type used for encoding/decoding, the design is still feasible.
 
> why do we need the direct loopback option?  The only benefit is to
avoid 
> packet fragmentation, but it's hard to imagine where that would be a
real
> issue.  I personally prefer the encapsulation option.
 
I tend to agree with you -- the direct loopback method seems least
useful in practice.
 
Muthu
 
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2010 2:13 AM
To: Muthu ArulMozhi Perumal (mperumal); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-mmusic-media-loopback-13
 
Muthu,
 
1) "a=rtpmap:8 pcma/8000" is used to map a payload type on the m= line
to a particular media type.  8 is not specified anywhere, so I'd think
it should be ignored (or rejected, though I prefer ignoring)
2) Why would an intermediary need to?  It should be echoed as-is.  But,
you ask a good question: why do we need the direct loopback option?  The
only benefit is to avoid packet fragmentation, but it's hard to imagine
where that would be a real issue.  I personally prefer the encapsulation
option.
3) I assume the "rtmpa" line is typo.  And I think you're right that it
should be on the m= line.
4) I think this is right.  "Ecapsulated steam" is used for the
encapsulated form.  "Payload loopback" is used for the "direct
loopback".  But, I agree it would read better if we changed it as you
suggest.
 
Kaynam, comments?
 
Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Apr 2010 09:51:42 -0400

Muthu,
 
> > 1) "a=rtpmap:8 pcma/8000" is used to map a payload type on
> > the m= line to a particular media type.
> 
>     i=An example session e=[email-masked]
>     c=IN IP4 192.0.2.12/127 t=0 0
> Here, "a=rtpmap:0 pcmu/8000" describes a payload type listed
> in "a=loopback-mirror", but not in the "m=" line. Without
> extending "a=rtpmap" to map payload types listed in
> "a=loopback-source" and "a=loopback-mirror", I don't see how
> rtp-pkt-loopback would actually work, because the send and
> receive payload types will be different for both
> loopback-source and loopback-mirror. I think the draft needs
> to describe this extension to "a=rtpmap". Perhaps, we want
> to name it "a=rtp-loopback-map"?

Yeah, I'm wondering about that.  For direct media flows, this should not be
an issue, as the sender and receiver would figure it out.  In this case, the
sender of the request expects to receive 112 (the encapsulated format), but
I think that "0" would look odd to a device that might be in the path and
not understand the semantics.

I'm not at all concerned about the fact there is symmetric media formats:
that's perfectly legal.  We could send a "0" type in one direction and "112"
in the other, but what would an SBC do if it saw something like this?

Perhaps this is the safest thing to do, since they'd likely remove those
lines from the SDP?

The offer/answer model (RFC 3264) also says:
   For streams marked as sendrecv in the answer,
   the "m=" line MUST contain at least one codec the answerer is willing
   to both send and receive, from amongst those listed in the offer.

The answer to the above example in the document does not contain 112.  Was
that discussed before?  Honestly, I can't remember... that's what we get for
having the draft sitting around for so long.  But, this seems to be at odds
with 3264.

This is where we need Kaynam to provide some history and guidance.

> Now, one of the primary motivations for rtp-media-loopback
> seems to be the ability to test whether all the
> encoding/decoding functions are actually working in a media
> processing element, rather than just test the media path.
> All I am trying to see is, if the same can be used to test a
> transcoder that I know can transcode b/w two codecs. I think
> this would be a useful capability for enterprises and
> service providers.

What kind of test do you want?  Since a human is not listening, there's no
subjective testing possible.  How would an automated device know whether the
transcoding was good or not?
 
> Consider a distributed SBC where the signaling plane
> programs the media plane to provide certain level of QoS for
> certain RTP payloads. Now, if the RTP packet doesn't carry
> the payload type used for encoding/decoding, there is no way
> this will work. Of course, the distributed SBC would need an
> upgrade to understand the packet formats for
> rtp-pkt-loopback, but as far as the RTP packets carry the
> payload type used for encoding/decoding, the design is still
> feasible.

It's true that no special QoS treatment would likely be given to the
loopbacked media, but I'm  not sure how we could guarantee this unless the
transcoder understands the loopback stuff.

Paul

---

From: Nathan Stratton <[email-masked]>
Date: Wed, 28 Apr 2010 13:05:33 -0500 (CDT)

> This is where we need Kaynam to provide some history and guidance.

The issue was not addressed before, but I don't see it as a major issue 
one way or the other. I do agree that this has gone on way to long. I am 
working with several CPE vendors to implement this and many are frustrated 
with the constant changes.

><>
Nathan Stratton                                CTO, BlinkMind, Inc.
nathan at robotics.net                         nathan at blinkmind.com
http://www.robotics.net                        http://www.blinkmind.com

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 28 Apr 2010 23:49:40 +0530

Paul,

|I think that "0" would look odd to a device that might be in the
|path and not understand the semantics.

Yes, this could cause certain problems. Suppose there is a firewall or
SBC in the media path that doesn't understand these SDP semantics, but
is policing the RTP stream to verify whether the RTP payload type is the
same as what was negotiated in the offer/answer, then they might just
throw away these encapsulated RTP packets whose payload types they
didn't expect.

But, however we design, I think it isn't realistic to expect it would
always work with all intermediaries in the media path, unless they
actually understand/support the semantics.

|I'm not at all concerned about the fact there is symmetric media 
|formats that's perfectly legal.  We could send a "0" type in one
|direction and "112" in the other    

I am not concerned about it either.

|but what would an SBC do if it saw something like this?
|Perhaps this is the safest thing to do, since they'd likely remove
|those lines from the SDP?

I agree -- this looks the safest way to go with SBCs, since they would
most likely remove what they don't understand.

|The offer/answer model (RFC 3264) also says:
|   For streams marked as sendrecv in the answer,
|   the "m=" line MUST contain at least one codec the 
|   answerer is willing to both send and receive, from
|   amongst those listed in the offer.
|
|The answer to the above example in the document does not 
|contain 112.  Was that discussed before?  Honestly, I can't
|remember... that's what we get for having the draft sitting 
|around for so long.  But, this seems to be at odds with 3264.

Yes, this it at odds with RFC3264, and it seems to me that the only way
to be compliant is to change the semantics for directionality described
in section 5.2:

> When loopback-mode is specified as loopback-source, the media
> format corresponds to the RTP payload types the source is willing
> to send. When loopback-mode is specified as loopback-mirror, the
> media format corresponds to the RTP payload types the mirror is
> willing to receive. The payload types specified in m= line for a
> loopback-source specify the payloads the source is willing to
> receive. Similarly, for the loopback-mirror these payload types
> specify the payloads it is willing to send.

As follows:
When loopback-mode is specified as loopback-source, the media
format corresponds to the RTP payload types the source is willing
to receive. When loopback-mode is specified as loopback-mirror, the
media format corresponds to the RTP payload types the loopback-mirror
is willing to send. 

The directionality of the "m=" lines can be pinned down using
"a=sendonly" and "a=recvonly". 
We then need a "a=loopback-rtpmap" that can map the RTP payload type
numbers, as used in the "a=loopback-source" and "a=loopback-mirror"
lines, because as per RFC4566 (section 6) "a=rtpmap" maps only to a "m="
line.

So, a loopback offer for the encapsulated RTP would be:

    m=audio 49170 RTP/AVP 0
    a=sendonly
    a=loopback:rtp-pkt-loopback
    a=loopback-source:112
    a=rtpmap:0 pcum/8000
    a=loopback-rtpmap:112 encaprtp/8000
    
And the answer would be:

    m=audio 49170 RTP/AVP 0
    a=recvonly
    a=loopback:rtp-pkt-loopback
    a=loopback-mirror:112
    a=rtpmap:0 pcum/8000
    a=loopback-rtpmap:112 encaprtp/8000

This would be compliant to RFC3264, as well as hide the new encoding
name in a new SDP attribute -- media processing elements that don't
understand it can just ignored it.

|What kind of test do you want?  Since a human is not listening,
|there's no subjective testing possible.  How would an automated
|device know whether the transcoding was good or not?

Why should it be always an automated test. Why wouldn't someone want to
test a SBC at the enterprise or service provider edge using a video
conferencing or Teleprsence system, by initiating a loopback call to see
how good his/her own video is seen on the screen? Now suppose the SBC
can insert a transcoder when the endpoints don't have a matching codec
for a given media stream. If this SBC supports the loopback semantics,
the user/admin might want to test its transcoding function by initiating
a loopback call, by specifying rtp-media-loopback and different codecs
for sending and receiving.

If we change the semantics for directionality as I've described above,
it should be possible to perform such a test as follows:

Offer:
    m=audio 49170 RTP/AVP 0
    a=sendonly
    a=loopback:rtp-media-loopback
    a=loopback-source:8
    a=rtpmap:0 pcmu/8000
    a=loopback-rtpmap:8 pcma/8000

Answer:
    m=audio 49170 RTP/AVP 0
    a=recvonly
    a=loopback:rtp-media-loopback
    a=loopback-mirror:8
    a=rtpmap:0 pcmu/8000
    a=loopback-rtpmap:8 pcma/8000

|It's true that no special QoS treatment would likely be given
|to the loopbacked media, but I'm  not sure how we could guarantee
|this unless the transcoder understands the loopback stuff.

Sure, it needs to, if wants to provide enhanced troubleshooting
capability to users/admins.

Muthu

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 29 Apr 2010 00:07:17 +0530

Shouldn't we fix, rather than being at odds with both RFC3264 and
RFC4566 forever? I understand it will make a few vendors unhappy for
some time, but if we fix it, I think we could achieve better interop
with existing systems in the longer run.

Muthu 

|-----Original Message-----
|From: Nathan Stratton [mailto:[email-masked]]
|Sent: Wednesday, April 28, 2010 11:36 PM
|To: Paul E. Jones
|Cc: Muthu ArulMozhi Perumal (mperumal); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah);
[email-masked]
|Subject: RE: Comments on draft-ietf-mmusic-media-loopback-13
|
|On Wed, 28 Apr 2010, Paul E. Jones wrote:
|
|> Yeah, I'm wondering about that.  For direct media flows, this should
not
|be
|> an issue, as the sender and receiver would figure it out.  In this
case,
|the
|> sender of the request expects to receive 112 (the encapsulated
format),
|but
|> I think that "0" would look odd to a device that might be in the path
and
|> not understand the semantics.
|>
|> I'm not at all concerned about the fact there is symmetric media
formats:
|> that's perfectly legal.  We could send a "0" type in one direction
and
|"112"
|> in the other, but what would an SBC do if it saw something like this?
|>
|> Perhaps this is the safest thing to do, since they'd likely remove
those
|> lines from the SDP?
|>
|> The offer/answer model (RFC 3264) also says:
|>   For streams marked as sendrecv in the answer,
|>   the "m=" line MUST contain at least one codec the answerer is
willing
|>   to both send and receive, from amongst those listed in the offer.
|>
|> The answer to the above example in the document does not contain 112.
Was
|> that discussed before?  Honestly, I can't remember... that's what we
get
|for
|> having the draft sitting around for so long.  But, this seems to be
at
|odds
|> with 3264.
|>
|> This is where we need Kaynam to provide some history and guidance.
|
|The issue was not addressed before, but I don't see it as a major issue
|one way or the other. I do agree that this has gone on way to long. I
am
|working with several CPE vendors to implement this and many are
frustrated
|with the constant changes.
|
|><>
|Nathan Stratton                                CTO, BlinkMind, Inc.
|nathan at robotics.net                         nathan at blinkmind.com
|http://www.robotics.net                        http://www.blinkmind.com

---

From: Nathan Stratton <[email-masked]>
Date: Wed, 28 Apr 2010 14:23:05 -0500 (CDT)

> with existing systems in the longer run.

Yes we should try to fix it, but we also should try to finish this up and 
at some point say it is done.