Subject: [MMUSIC] draft-ietf-mmusic-media-loopback-14 review and comments

From: Flemming Andreasen <[email-masked]>
Date: Mon, 01 Nov 2010 18:28:32 -0400

Hi

I've taken a closer look at draft-ietf-mmusic-media-loopback (-14 more 
specifically). I've also reviewed the various MMUSIC mailing list 
discussion on this draft since 2004 to try and get the right context for 
the current draft. I have a number of comments on the draft, however I 
will start out with the major ones here, and defer some of the more 
detailed ones:

1) Offer/Answer model inconsistency.
As noted by others, the draft breaks the RFC 3264 offer/answer model by
a) changing the semantics of the m= line to be unidirectional in terms 
of offered codecs
b) making the now implied directionality of the m= line offered depend 
on other attributes (loopback-source and loopback-mirror)
c) supplying the media formats for "the other direction" in new 
attributes (loopback-source and loopback-mirror)
d) changing RFC 3264 processing in general as a result of the above

I have not seen a good motivation for the above, however I see several 
problems with it, e.g.
- Implementations cannot reuse current O/A model implementation
- Backwards compatibility issues with implementations that do not 
support media-loopback
- Draft ambiguities wrt handling of payload type mappings in the send 
and receive direction (e.g. is it a single payload type name space 
between the m= line and the -source/-mirror lines or not, and do we 
support asymmetric payload types in the send and receive direction as 
allowed in RFC 3264) ?
- "m=" line directionality doesn't really work if you try to do 
negotiation, e.g. consider capability negotiation where you offer to 
operate as either source or mirror - what's the directionality for the 
"m=" line now ?

I'd like for the authors to motivate this design choice, and to 
reconsider if it's really needed or whether we can in fact use normal 
O/A procedures instead.

2) NAT traversal and the "loopback primer"
First of all, we have ICE/STUN/TURN to address NAT traversal issues - 
why can that not be used ?
Secondly, the proposed mechanism doesn't seem to work. The mechanism 
seems to assume a specific topology scenario as follows:

     loopback-mirror (private IP) - NAT - loopback-source

where the NAT is assumed to not let packets through until the 
loopback-mirror has sent one or more packets through it. The problem 
here is that the NAT binding is not created until the loopback-mirror 
sends packets through it, yet the loopback-source is sending its packets 
to the IP-address/port advertisesed in the SDP by the loopback-mirror 
(which is different). ICE solves this basic scenario as well as many 
more variations not considered here (and without assuming any particular 
topology).

3) The Direct loopback RTP payload format
I do not quite understand why we need this payload format if all we do 
is send back the same payload as we received. More importantly, it 
limits what we can actually do.

As an example, it was suggested that the looped back media could be 
rendered so we could get an idea of what we sound/look etc. like to the 
other side. However, the direct loopback RTP media format does not 
identify the media format being conveyed so how do we render it if more 
than one media format is possible ? A simple example would be an audio 
stream that includes RFC 4733 DTMF events which would require two 
different payloads in the same stream.

A related question here is whether this draft has been presented to and 
reviewed by AVT. If not, it needs to.

4) SRTP considerations
The draft needs to address SRTP specifically. This applies to the 
different modes (rtp in particular) as well as the different payload 
formats (e.g. how much of the SRTP packet do you mirror with 
encapsulated RTP) ?

Few additional general comments
- Use the terms "offerer" and "answerer", or "entity that sent the 
SDP"/"entity that received the SDP" more consistently throughout rather 
than "sender", "source" and "receiver".
- An offer can be for either "loopback-source" or "loopback-mirror". 
Some of the text in the draft addresses only the offerer being a 
loopback-source.
- "MUST not" and "MUST NOT" are not the same; the former is used in a 
couple of places where the latter seems to be intended.
- Security considerations need to be expanded. RFC 3264 and specific 
session authentication mechanisms would seem relevant as would SRTP. 
Explicit end-user control of loopback (if expected to be automated) and 
the fact that you are essentially creating a level of indirection here 
(consider the source providing a third-party's IP-address information) 
require consideration as well. There are probably others.
- Some uses of "payload type" where it really should be "media format" 
or "payload format"

Thanks

-- Flemming

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 3 Nov 2010 00:40:51 +0530

One of the reasons I've heard in past for having to deviate from the
directionality semantics of the offer/answer model is that the
loopback-source needs a way to indicate to the loopback-mirror to send
the looped back media in a different format (encaprtp, as described in
the draft). Following the offer/answer model the source probably can use
2 separate m-lines, a sendonly stream indicating the media format the
source is willing to send and a recvonly stream indicating the media
format the source is expecting to receive. However, that would forbid
the source from specifying the same port for sending and receiving:
 
RFC-4566 section 5.14:
<snip>
   The semantics of multiple "m=" lines using the same transport address
are undefined.
</snip>
 
RFC-3388 section 7.5.3:
<snip>
   If several codecs have to be sent to the same IP address and port,
   the traditional SDP syntax of listing several codecs in the same "m"
   line MUST be used.  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>
 
So, the argument was for the source to use a single m-line, specifying
the transport address for sending and receiving, and hide the media
payload types it is willing to send in an "a=loopback-source" attribute.
 
On the direct loopback packet format, the reason I've heard for using it
is to make sure that mirrors that don't support the draft fail the call
(because they won't understand that codec), instead of rendering the
media to the user. Of course, there are alternate ways of achieving it,
like using a Require header tag in SIP.
 
On a different note, the draft seems to have been adopted by the
PacketCable specification targeted at cable industry and its customers: 
http://www.google.co.in/url?sa=t&source=web&cd=1&ved=0CBoQFjAA&url=http%
3A%2F%2Fwww.cablelabs.com%2Fspecifications%2FPKT-SP-RST-E-DVA-I05-090528
.pdf&rct=j&q=Residential%20SIP%20Telephony%20E-DVA%20Specification&ei=dF
mtTMv7FMW3cP_22e0N&usg=AFQjCNEO0SUyz63a8ptgdl58SgB8TAbHlQ&sig2=PhRKInrei
9qWoNZnmDI1Hg&cad=rja
So, wondering what existing implementations would be broken if major
semantic changes are introduced in the draft at this point..
 
Muthu

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 02 Nov 2010 16:06:21 -0400

On 11/2/10 3:07 PM, Muthu ArulMozhi Perumal (mperumal) wrote:
> the draft). Following the offer/answer model the source probably can 
> use 2 separate m-lines, a sendonly stream indicating the media format 
> the source is willing to send and a recvonly stream indicating the 
> media format the source is expecting to receive.
>
There is no need to break offer/answer to achieve that. Acceptance of 
loopback operation by itself could imply this kind of operation (i.e. it 
would be part of the specified loopback semantics). Alternatively, you 
can keep the loopback attribute as-is, but slightly alter the semantics 
so you again specify things in terms of send/receive on the m= line, but 
the loopback attribute further qualifies the payload format that will 
actually be used for the loopback. Remember, payload formats in an m= 
line merely indicates the ability to send/receive using those payload 
formats, not a promise to use all of them.

> However, that would forbid the source from specifying the same port 
> for sending and receiving:
>
> RFC-4566 section 5.14:
>
> <snip>
>
Using a single m= line seems desirable to me as well, but again, I do 
not see a reason to break offer/answer.

> On the direct loopback packet format, the reason I've heard for using 
> it is to make sure that mirrors that don't support the draft fail the 
> call (because they won't understand that codec), instead of rendering 
> the media to the user.
>
But they won't fail the call as long as they support at least one of the 
media formats in the m= line.

> Of course, there are alternate ways of achieving it, like using a 
> Require header tag in SIP.
>
Right (assuming SIP usage of course).

> http://www.google.co.in/url?sa=t&source=web&cd=1&ved=0CBoQFjAA&url=http%3A%2F%2Fwww.cablelabs.com%2Fspecifications%2FPKT-SP-RST-E-DVA-I05-090528.pdf&rct=j&q=Residential%20SIP%20Telephony%20E-DVA%20Specification&ei=dFmtTMv7FMW3cP_22e0N&usg=AFQjCNEO0SUyz63a8ptgdl58SgB8TAbHlQ&sig2=PhRKInrei9qWoNZnmDI1Hg&cad=rja 
> <http://www.google.co.in/url?sa=t&source=web&cd=1&ved=0CBoQFjAA&url=http%3A%2F%2Fwww.cablelabs.com%2Fspecifications%2FPKT-SP-RST-E-DVA-I05-090528.pdf&rct=j&q=Residential%20SIP%20Telephony%20E-DVA%20Specification&ei=dFmtTMv7FMW3cP_22e0N&usg=AFQjCNEO0SUyz63a8ptgdl58SgB8TAbHlQ&sig2=PhRKInrei9qWoNZnmDI1Hg&cad=rja>
>
That's a separate discussion, however if perceived as a problem, there 
is always the possibility of renaming attributes in a new version of the 
draft to avoid any ambiguities with existing implementations.

Thanks

-- Flemming

> Muthu
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Flemming Andreasen (fandreas)
> *Sent:* Tuesday, November 02, 2010 3:59 AM
> *To:* mmusic; [email-masked]
> *Subject:* [MMUSIC] draft-ietf-mmusic-media-loopback-14 review and 
> comments
>
> Hi
>
> discussion on this draft since 2004 to try and get the right context 
> for the current draft. I have a number of comments on the draft, 
> however I will start out with the major ones here, and defer some of 
> the more detailed ones:
>
> sends packets through it, yet the loopback-source is sending its 
> packets to the IP-address/port advertisesed in the SDP by the 
> loopback-mirror (which is different). ICE solves this basic scenario 
> as well as many more variations not considered here (and without 
> assuming any particular topology).
>
>
> rendered so we could get an idea of what we sound/look etc. like to 
> the other side. However, the direct loopback RTP media format does not 
> identify the media format being conveyed so how do we render it if 
> more than one media format is possible ? A simple example would be an 
> audio stream that includes RFC 4733 DTMF events which would require 
> two different payloads in the same stream.
>
> A related question here is whether this draft has been presented to 
> and reviewed by AVT. If not, it needs to.
>
>
> 4) SRTP considerations
> SDP"/"entity that received the SDP" more consistently throughout 
> rather than "sender", "source" and "receiver".
> Explicit end-user control of loopback (if expected to be automated) 
> and the fact that you are essentially creating a level of indirection 
> here (consider the source providing a third-party's IP-address 
> information) require consideration as well. There are probably others.

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 3 Nov 2010 12:46:04 +0530

Flemming,
 
|There is no need to break offer/answer to achieve that. 
|Acceptance of loopback operation by itself could imply 
|this kind of operation (i.e. it would be part of the 
|specified loopback semantics). Alternatively, you can keep 
|the loopback attribute as-is, but slightly alter the semantics 
|so you again specify things in terms of send/receive on the 
|m= line, but the loopback attribute further qualifies the 
|payload format that will actually be used for the loopback.
 
This does seem to make sense. If I understood correctly, you are
suggesting the loopback-source could indicate *all* the payload types it
is willing to send and expecting to receive in a single m-line, then use
the existing "a=loopback-source: <pt> ..." attribute to indicate the
payload types it is expecting to receive.
 
Similarly, the loopback-mirror could indicate *all* the payload types it
is willing to send and receive in a single m-line, then use the existing
"a=loopback-mirror: <pt> ..." attribute to indicate the payload types it
is willing to send.
 
So, a source willing to send PCMU and RFC 4733 packets, and expecting
the mirror to loop it back as encaprtp could send an offer like this:
    m=audio 49170 RTP/AVP 0 110 112
    a=loopback:rtp-pkt-loopback
    a=loopback-source:112
    a=rtpmap:110 telephone-events/8000
    a=rtpmap:112 encaprtp/8000
 
The mirror can send the answer like this:
    m=audio 49170 RTP/AVP 0 110 112
    a=loopback:rtp-pkt-loopback
    a=loopback-mirror:112
    a=rtpmap:110 telephone-events/8000
    a=rtpmap:112 encaprtp/8000
 
If the source wants to pause the mirror, it can simply mark the stream
as sendonly or go to the extent of removing the encaprtp payload type
and the loopback attributes then mark the stream as sendonly:
    m=audio 49170 RTP/AVP 0 110 112
    a=loopback:rtp-pkt-loopback
    a=loopback-source:112
    a=rtpmap:110 telephone-events/8000
    a=rtpmap:112 encaprtp/8000
    a=sendonly
OR
    m=audio 49170 RTP/AVP 0 110
    a=rtpmap:110 telephone-events/8000
    a=sendonly
 
Likewise, the mirror can simply mark the stream as recvonly or go the
extent of removing the encaprtp payload type and the loopback attributes
then mark the stream as recvonly:
    m=audio 49170 RTP/AVP 0 110 112
    a=loopback:rtp-pkt-loopback
    a=loopback-mirror:112
    a=rtpmap:110 telephone-events/8000
    a=rtpmap:112 encaprtp/8000
    a=recvonly
OR
    m=audio 49170 RTP/AVP 0 110 112
    a=rtpmap:110 telephone-events/8000
    a=recvonly
 
While the first method looks easier for implementation, the second looks
a bit cleaner.
 
I agree -- if these slight changes in semantics would break existing
implementations one way is to rename the attributes. Alternatively, we
could retire the current one addressing only the minor issues and
publish a new one?
 
thanks,
Muthu

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Nov 2010 10:45:51 -0400

The more I think about this the more I come to believe that this whole 
loopback thing may be just a special case of a transcoder. Its just "I 
want to send payload types A,B,C and get back payload types X,Y,Z."

ISTM this would be a much more broadly useful mechanism that could then 
be used for the loopback scenario too.

This would be more naturally accomplished with two m-lines, one sendonly 
and the other recvonly. Is that an unacceptable way to do the loopback?

Regarding using the same port in both m-lines - I'm not certain if that 
would be disallowed if one is sendonly and the other recvonly. ISTM that 
is logically should be permissible even if existing specs forbid it.

	Thanks,
	Paul

On 11/3/2010 3:16 AM, Muthu ArulMozhi Perumal (mperumal) wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 3 Nov 2010 21:48:39 +0530

I couldn't agree more and we even had a discussion on these lines some
time back:
http://www.ietf.org/mail-archive/web/mmusic/current/msg08110.html

The ability to request a transcoder to loopback media in a different
format would not only test the media path, but also how good the
transcoder itself functioning -- would definitely be useful for network
admins. However, it would expand the scope of media loopback testing and
I am eager to hear if the WG would be interested in the expanded scope..

thanks,
Muthu 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of
|Paul Kyzivat (pkyzivat)
|Sent: Wednesday, November 03, 2010 8:16 PM
|To: [email-masked]
|Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-14 review and
|comments
|
|The more I think about this the more I come to believe that this whole
|loopback thing may be just a special case of a transcoder. Its just "I
|want to send payload types A,B,C and get back payload types X,Y,Z."
|
|ISTM this would be a much more broadly useful mechanism that could then
|be used for the loopback scenario too.
|
|This would be more naturally accomplished with two m-lines, one
sendonly
|and the other recvonly. Is that an unacceptable way to do the loopback?
|
|Regarding using the same port in both m-lines - I'm not certain if that
|would be disallowed if one is sendonly and the other recvonly. ISTM
that
|is logically should be permissible even if existing specs forbid it.
|
|	Thanks,
|	Paul
|
|On 11/3/2010 3:16 AM, Muthu ArulMozhi Perumal (mperumal) wrote:
|> Flemming,
|>
|> |There is no need to break offer/answer to achieve that.
|>
|> |Acceptance of loopback operation by itself could imply
|>
|> |this kind of operation (i.e. it would be part of the
|>
|> |specified loopback semantics). Alternatively, you can keep
|>
|> |the loopback attribute as-is, but slightly alter the semantics
|>
|> |so you again specify things in terms of send/receive on the
|>
|> |m= line, but the loopback attribute further qualifies the
|>
|> |payload format that will actually be used for the loopback.
|>
|> This does seem to make sense. If I understood correctly, you are
|> suggesting the loopback-source could indicate *all* the payload types
it
|> is willing to send and expecting to receive in a single m-line, then
use
|> the existing "a=loopback-source: <pt> ..." attribute to indicate the
|> payload types it is expecting to receive.
|>
|> Similarly, the loopback-mirror could indicate *all* the payload types
it
|> is willing to send and receive in a single m-line, then use the
existing
|> "a=loopback-mirror: <pt> ..." attribute to indicate the payload types
it
|> is willing to send.
|>
|> So, a source willing to send PCMU and RFC 4733 packets, and expecting
|> the mirror to loop it back as encaprtp could send an offer like this:
|>
|> m=audio 49170 RTP/AVP 0 110 112
|>
|> a=loopback:rtp-pkt-loopback
|>
|> a=loopback-source:112
|>
|> a=rtpmap:110 telephone-events/8000
|>
|> a=rtpmap:112 encaprtp/8000
|>
|> The mirror can send the answer like this:
|>
|> m=audio 49170 RTP/AVP 0 110 112
|>
|> a=loopback:rtp-pkt-loopback
|>
|> a=loopback-mirror:112
|>
|> a=rtpmap:110 telephone-events/8000
|>
|> a=rtpmap:112 encaprtp/8000
|>
|> If the source wants to pause the mirror, it can simply mark the
stream
|> as sendonly or go to the extent of removing the encaprtp payload type
|> and the loopback attributes then mark the stream as sendonly:
|>
|> m=audio 49170 RTP/AVP 0 110 112
|>
|> a=loopback:rtp-pkt-loopback
|>
|> a=loopback-source:112
|>
|> a=rtpmap:110 telephone-events/8000
|>
|> a=rtpmap:112 encaprtp/8000
|>
|> a=sendonly
|>
|> OR
|>
|> m=audio 49170 RTP/AVP 0 110
|>
|> a=rtpmap:110 telephone-events/8000
|>
|> a=sendonly
|>
|> Likewise, the mirror can simply mark the stream as recvonly or go the
|> extent of removing the encaprtp payload type and the loopback
attributes
|> then mark the stream as recvonly:
|>
|> m=audio 49170 RTP/AVP 0 110 112
|>
|> a=loopback:rtp-pkt-loopback
|>
|> a=loopback-mirror:112
|>
|> a=rtpmap:110 telephone-events/8000
|>
|> a=rtpmap:112 encaprtp/8000
|>
|> a=recvonly
|>
|> OR
|>
|> m=audio 49170 RTP/AVP 0 110 112
|>
|> a=rtpmap:110 telephone-events/8000
|>
|> a=recvonly
|>
|> While the first method looks easier for implementation, the second
looks
|> a bit cleaner.
|>
|> I agree -- if these slight changes in semantics would break existing
|> implementations one way is to rename the attributes. Alternatively,
we
|> could retire the current one addressing only the minor issues and
|> publish a new one?
|>
|> thanks,
|>
|> Muthu
|>
|>
|>
|> _______________________________________________
|> mmusic mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/mmusic
|_______________________________________________
|mmusic mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 03 Nov 2010 20:22:28 -0400

On 11/3/10 3:16 AM, Muthu ArulMozhi Perumal (mperumal) wrote:
> suggesting the loopback-source could indicate *all* the payload types 
> it is willing to send and expecting to receive in a single m-line, 
> then use the existing "a=loopback-source: <pt> ..." attribute to 
> indicate the payload types it is expecting to receive.
>
> Similarly, the loopback-mirror could indicate *all* the payload types 
> it is willing to send and receive in a single m-line, then use the 
> existing "a=loopback-mirror: <pt> ..." attribute to indicate the 
> payload types it is willing to send.
>
Right - something like that would be much more in line with the current 
offer/answer model and avoid some of the aforementioned issues.
> a=rtpmap:112 encaprtp/8000
Right.
> extent of removing the encaprtp payload type and the loopback 
> attributes then mark the stream as recvonly:
>
Right (nit: need to remove 112 in the last m= line)

> While the first method looks easier for implementation, the second 
> looks a bit cleaner.
>
One way or the other I think we need to address the issues that have 
been brought up. It would be good to hear from more people though (incl. 
the authors) .

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 03 Nov 2010 20:29:21 -0400

I think it would be good to hear from the authors. Also, while I agree 
that the scope can be generalized, the draft has been in progress for 
around 6 years now and is presumably getting close to being done, so in 
fairness to the authors, I think we should hear their thoughts on all of 
this, including the issues that have been raised so far (in the context 
of the draft's current scope).

Thanks

-- Flemming

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Nov 2010 09:32:27 -0500

I think it's really unfair to the authors to raise these types of issues now, when the draft's been a WG item since *2004*.
I mean I know we can't just publish an age-old document if it's really technically flawed, but still... this document will have taken a longer time to publish than ICE at this point

Other comments inline...

On Nov 1, 2010, at 6:28 PM, Flemming Andreasen wrote:

I've taken a closer look at draft-ietf-mmusic-media-loopback (-14 more specifically). I've also reviewed the various MMUSIC mailing list discussion on this draft since 2004 to try and get the right context for the current draft. I have a number of comments on the draft, however I will start out with the major ones here, and defer some of the more detailed ones:

1) Offer/Answer model inconsistency.
As noted by others, the draft breaks the RFC 3264 offer/answer model by
a) changing the semantics of the m= line to be unidirectional in terms of offered codecs
b) making the now implied directionality of the m= line offered depend on other attributes (loopback-source and loopback-mirror)
c) supplying the media formats for "the other direction" in new attributes (loopback-source and loopback-mirror)
d) changing RFC 3264 processing in general as a result of the above

Yeah, it's not the greatest model, but I think the motivation was driven by the desire to work through legacy middleboxes with as little chance of failure caused by them.

I have not seen a good motivation for the above, however I see several problems with it, e.g.
- Implementations cannot reuse current O/A model implementation

O RLY??   What is this single common O/A model implementation that everyone has?  Regardless, I'm not sure it matters - in some sense this is a special case to begin with.  You're gonna have new code to handle it no matter what.  Obviously it would be cleaner to keep that code at a higher layer, but we're so far down the rabbit-hole with SDP and Offer/Answer "special cases" that this one's a drop in the bucket.

- Backwards compatibility issues with implementations that do not support media-loopback
- Draft ambiguities wrt handling of payload type mappings in the send and receive direction (e.g. is it a single payload type name space between the m= line and the -source/-mirror lines or not, and do we support asymmetric payload types in the send and receive direction as allowed in RFC 3264) ?
- "m=" line directionality doesn't really work if you try to do negotiation, e.g. consider capability negotiation where you offer to operate as either source or mirror - what's the directionality for the "m=" line now ?

When this draft started there was no such thing as cap-neg, and even though there is now, you can't seriously argue it's a reasonable use-case for media-loopback.  The use-case for this is a test call - you might as well argue what happens if you send an offerless INVITE.  Answer: don't do that, because it's illogical for this use-case.

2) NAT traversal and the "loopback primer"
First of all, we have ICE/STUN/TURN to address NAT traversal issues - why can that not be used ?

Is that a serious question, or did you forget to add the <sarcasm> tags?  Like this:
<sarcasm>Maybe this draft should remove NAT discussion altogether, since we'll all be on IPv6 without NATs anyday now too.</sarcasm>

Secondly, the proposed mechanism doesn't seem to work. The mechanism seems to assume a specific topology scenario as follows:

where the NAT is assumed to not let packets through until the loopback-mirror has sent one or more packets through it. The problem here is that the NAT binding is not created until the loopback-mirror sends packets through it, yet the loopback-source is sending its packets to the IP-address/port advertisesed in the SDP by the loopback-mirror (which is different). ICE solves this basic scenario as well as many more variations not considered here (and without assuming any particular topology).

No, in that case the loopback-source will latch on the packets from the mirror (or some middlebox will).  And it works for the opposite case as well, since the loopback-source also sends packets.  The only case it doesn't work for is when they're both behind NATs.  Oh shucks.

3) The Direct loopback RTP payload format
I do not quite understand why we need this payload format if all we do is send back the same payload as we received. More importantly, it limits what we can actually do.
 As an example, it was suggested that the looped back media could be rendered so we could get an idea of what we sound/look etc. like to the other side. However, the direct loopback RTP media format does not identify the media format being conveyed so how do we render it if more than one media format is possible ? A simple example would be an audio stream that includes RFC 4733 DTMF events which would require two different payloads in the same stream.

I'm confused - are you talking about the rtp-pkt-loopback or the rtp-media-loopback mode?  The words you used for the title ("The Direct loopback RTP payload format") imply the former, but the example sounds like the latter.

4) SRTP considerations
The draft needs to address SRTP specifically. This applies to the different modes (rtp in particular) as well as the different payload formats (e.g. how much of the SRTP packet do you mirror with encapsulated RTP) ?

Good question.  Since this only covers RTP/AVP, my assumption is this draft does not intend to cover SRTP cases.  Why is that a problem?  (I mean why can't they say "someone else can go write a draft for that")

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Nov 2010 09:40:28 -0500

> and the other recvonly. Is that an unacceptable way to do the loopback?

No, that's not gonna work.  One of the main premises of loopback calls is that they follow the same path and logic of devices as a normal call, right until they get to the UAS.  In other words, B2BUAs (and no I don't just mean SBCs) have to treat them the same way they would any other call, generally. (unless the loopback call is for the b2bua of course)

So you want it to look really similar to a normal call, including m-lines.

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 09 Nov 2010 00:07:29 +0800

On 11/8/10 10:32 PM, Hadriel Kaplan wrote:
>
> I think it's really unfair to the authors to raise these types of 
> issues now, when the draft's been a WG item since *2004*.
I was asked to review the document and that is what I have done. Also, 
some of these issues have been raised before (years ago in the case of 
O/A).

> I mean I know we can't just publish an age-old document if it's really 
> technically flawed, but still... this document will have taken a 
> longer time to publish than ICE at this point
>
> Other comments inline...
>
>
>> I've taken a closer look at draft-ietf-mmusic-media-loopback (-14 
>> more specifically). I've also reviewed the various MMUSIC mailing 
>> list discussion on this draft since 2004 to try and get the right 
>> context for the current draft. I have a number of comments on the 
>> draft, however I will start out with the major ones here, and defer 
>> some of the more detailed ones:
>>
>> b) making the now implied directionality of the m= line offered 
>> depend on other attributes (loopback-source and loopback-mirror)
> Yeah, it's not the greatest model, but I think the motivation was 
> driven by the desire to work through legacy middleboxes with as little 
> chance of failure caused by them.
Breaking offer/answer the way it's done here as opposed to adhering to 
it doesn't seem like a recipe to achieve that.

> O RLY??   What is this single common O/A model implementation that 
> everyone has?  Regardless, I'm not sure it matters - in some sense 
> this is a special case to begin with.  You're gonna have new code to 
> handle it no matter what.  Obviously it would be cleaner to keep that 
> code at a higher layer, but we're so far down the rabbit-hole with SDP 
> and Offer/Answer "special cases" that this one's a drop in the bucket.
>
I don't see this as an argument for why this draft needs to break 
offer/answer. Every time we do that it becomes more and more difficult 
to combine features not to mention that the implications of this new 
mode of operation are not well understood, simply because we don't have 
a lot of experience with it and haven't spent anywhere near the cycles 
on it that we have with O/A. This is another reason why it's valuable to 
have a common framework to adhere to.

>> operate as either source or mirror - what's the directionality for 
>> the "m=" line now ?
>
> When this draft started there was no such thing as cap-neg, and even 
> though there is now, you can't seriously argue it's a reasonable 
> use-case for media-loopback.  The use-case for this is a test call - 
> you might as well argue what happens if you send an offerless INVITE. 
>  Answer: don't do that, because it's illogical for this use-case.
>
We try to not design to specific narrow use cases but rather have more 
general solutions. Capability negotiation is just one example that 
wouldn't work with what has been specified here because it breaks 
offer/answer.

> <sarcasm>Maybe this draft should remove NAT discussion altogether, 
> since we'll all be on IPv6 without NATs anyday now too.</sarcasm>
>
Yes, it's a serious question, so what's a serious answer ?

> No, in that case the loopback-source will latch on the packets from 
> the mirror (or some middlebox will).  And it works for the opposite 
> case as well, since the loopback-source also sends packets.  The only 
> case it doesn't work for is when they're both behind NATs.  Oh shucks.
>
Neither this spec, RTP itself or offer/answer specifies this latching 
mode of operation. If latching is what the spec requires, then that 
needs to be called out and we can then have a discussion around the 
correct operation and security issues with that model (I believe this 
was already considered by BEHAVE/TURN years ago and rejected for those 
reasons, however I also understand that SBC's today may be using this 
model).

>> I do not quite understand why we need this payload format if all we 
>> do is send back the same payload as we received. More importantly, it 
>> the other side. However, the direct loopback RTP media format does 
>> not identify the media format being conveyed so how do we render it 
>> if more than one media format is possible ? A simple example would be 
>> an audio stream that includes RFC 4733 DTMF events which would 
>> require two different payloads in the same stream.
>
> I'm confused - are you talking about the rtp-pkt-loopback or the 
> rtp-media-loopback mode?  The words you used for the title ("The 
> Direct loopback RTP payload format") imply the former, but the example 
> sounds like the latter.
It is indeed the former; the rendering refers to the loopback-source 
rendering the looped back media, however that doesn't seem to be 
possible if multiple payload formats were to be used in the source media 
stream since we loose the actual payload type in the looped back media 
format and hence can only infer it from signaling (and thus, if there is 
more than one, which one is it ?)

> Good question.  Since this only covers RTP/AVP, my assumption is this 
> draft does not intend to cover SRTP cases.  Why is that a problem?  (I 
> mean why can't they say "someone else can go write a draft for that")
It seems overly restrictive to not consider SRTP and it wouldn't take 
much to add it so I would prefer that.

Thanks

-- Flemming

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Nov 2010 18:00:35 -0500

Hi Flemming,
comments inline...
(BTW - I read my email this morning and realized I sounded cranky... didn't mean to be... I was actually getting a chuckle from some of your comments, especially the one on ICE)

On Nov 8, 2010, at 11:07 AM, Flemming Andreasen wrote:

I think it's really unfair to the authors to raise these types of issues now, when the draft's been a WG item since *2004*.
I was asked to review the document and that is what I have done. Also, some of these issues have been raised before (years ago in the case of O/A).

Ah - understood -  I don't remember them being raised before.  The problem I think is this stuff has already been implemented by several vendors - that's not to say we should publish it simply because of that, but it's hard to see why they would change when it isn't actually broken for them. :(

Yeah, it's not the greatest model, but I think the motivation was driven by the desire to work through legacy middleboxes with as little chance of failure caused by them.
Breaking offer/answer the way it's done here as opposed to adhering to it doesn't seem like a recipe to achieve that.

Yeah and if I recall right we had that debate too - about whether it was safer to do X vs. Y to get through middleboxes.  I could be wrong on the motivation being that, but that's what some dusty memory cell in my brain tells me.  Hopefully the authors will chime in.

We try to not design to specific narrow use cases but rather have more general solutions. Capability negotiation is just one example that wouldn't work with what has been specified here because it breaks offer/answer.

I think we're talking past each other.  What I meant by "special case" isn't just that it's yet another draft for media negotiation - it's not really media negotiation to begin with.  Specifically, the encapsulated or direct packet loopback mode, but also the notion of being a source vs. a mirror.

The serious answer is there's no way this draft could reasonably rely on using ICE/STUN/TURN to fix its NAT traversal, because that would severely limit the addressable market.  It'd be like saying "why don't you just use IPv6".   Unless you don't mean to use ICE as the only way to fix this, but rather are saying if the offerer and answerer support ICE, wouldn't that also solve it for them. (I couldn't tell from your question in which way you meant it)

Neither this spec, RTP itself or offer/answer specifies this latching mode of operation. If latching is what the spec requires, then that needs to be called out and we can then have a discussion around the correct operation and security issues with that model (I believe this was already considered by BEHAVE/TURN years ago and rejected for those reasons, however I also understand that SBC's today may be using this model).

Which is probably why it doesn't call that out. :)

I'm confused - are you talking about the rtp-pkt-loopback or the rtp-media-loopback mode?  The words you used for the title ("The Direct loopback RTP payload format") imply the former, but the example sounds like the latter.
It is indeed the former; the rendering refers to the loopback-source rendering the looped back media, however that doesn't seem to be possible if multiple payload formats were to be used in the source media stream since we loose the actual payload type in the looped back media format and hence can only infer it from signaling (and thus, if there is more than one, which one is it ?)

Ahh - I understand what you're getting at now.  Right, it doesn't specify this very clearly.
In theory, the pkt-loopback mode is basically agnostic to the payload, and in practice I believe what PT you send is what you get back.  It doesn't care about 4733 vs. PCM vs. whatever.  So I guess if you wanted to send two different PTs, you could do this in the offer:

       m=audio 41352 RTP/AVP 112 113
       a=loopback:rtp-pkt-loopback
       a=loopback-source:0 8
       a=rtpmap:112 rtploopback/8000
       a=rtpmap:113 rtploopback/8000

And send your PCM (or whatever) using PT 112 and send 4733 using PT 113, and you'll get them back with those same PTs.

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 09 Nov 2010 13:55:54 +0800

On 11/9/10 7:00 AM, Hadriel Kaplan wrote:
> Hi Flemming,
> comments inline...
> (BTW - I read my email this morning and realized I sounded cranky... 
> didn't mean to be...
No problem - I didn't read that way :-)

> I was actually getting a chuckle from some of your comments, 
> especially the one on ICE)
>
>
>>>> - Draft ambiguities wrt handling of payload type mappings in the 
>>>> send and receive direction (e.g. is it a single payload type name 
>>>> space between the m= line and the -source/-mirror lines or not, and 
>>>> do we support asymmetric payload types in the send and receive 
>>>> direction as allowed in RFC 3264) ?
>>>> negotiation, e.g. consider capability negotiation where you offer 
>>>> to operate as either source or mirror - what's the directionality 
>>>> for the "m=" line now ?
>>>
>>> you might as well argue what happens if you send an offerless 
>>> INVITE.  Answer: don't do that, because it's illogical for this 
>>> use-case.
>>>
>> We try to not design to specific narrow use cases but rather have 
>> more general solutions. Capability negotiation is just one example 
>> that wouldn't work with what has been specified here because it 
>> breaks offer/answer.
>
> I think we're talking past each other.  What I meant by "special case" 
> isn't just that it's yet another draft for media negotiation - it's 
> not really media negotiation to begin with.  Specifically, the 
> encapsulated or direct packet loopback mode, but also the notion of 
> being a source vs. a mirror.
>
But presumably, the majority of endpoints that will use this draft are 
general endpoints that already support offer/answer (among other things) 
to begin with and are now being enhanced with media loopback procedures 
(the draft itself argues this scenario as motivation).

> The serious answer is there's no way this draft could reasonably rely 
> on using ICE/STUN/TURN to fix its NAT traversal, because that 
> would severely limit the addressable market.  It'd be like saying "why 
> don't you just use IPv6".   Unless you don't mean to use ICE as the 
> only way to fix this, but rather are saying if the offerer and 
> answerer support ICE, wouldn't that also solve it for them. (I 
> couldn't tell from your question in which way you meant it)
Why is loopback special though ? Again, the endpoints presumably need to 
establish other types of media streams besides loopback, and those 
endpoints will encounter the same NAT, FW, media relay traversal issues, 
i.e. we need a general solution for media streams. As you know we 
already have that in ICE/STUN/TURN, however if the argument is that 
something else is needed, then that's an entirely different discussion 
above and beyond loopback.

>>> case as well, since the loopback-source also sends packets.  The 
>>> only case it doesn't work for is when they're both behind NATs.  Oh 
>>> shucks.
>>>
>> was already considered by BEHAVE/TURN years ago and rejected for 
>> those reasons, however I also understand that SBC's today may be 
>> using this model).
>

Sure, but that doesn't solve the problem. If latching is required for 
this to work (and right now it seems to be), then it needs to be called 
out (at which point we'll enter into a much larger discussion around NAT 
traversal in general).

>>>> do is send back the same payload as we received. More importantly, 
>>>> it limits what we can actually do.
>>>>  As an example, it was suggested that the looped back media could 
>>>> be rendered so we could get an idea of what we sound/look etc. like 
>>>> to the other side. However, the direct loopback RTP media format 
>>>> does not identify the media format being conveyed so how do we 
>>>> render it if more than one media format is possible ? A simple 
>>>> example would be an audio stream that includes RFC 4733 DTMF events 
>>>> which would require two different payloads in the same stream.
>>>
>>> Direct loopback RTP payload format") imply the former, but the 
>>> example sounds like the latter.
>> possible if multiple payload formats were to be used in the source 
>> media stream since we loose the actual payload type in the looped 
>> back media format and hence can only infer it from signaling (and 
>> thus, if there is more than one, which one is it ?)
>
> In theory, the pkt-loopback mode is basically agnostic to the payload, 
> and in practice I believe what PT you send is what you get back.  It 
> doesn't care about 4733 vs. PCM vs. whatever.  So I guess if you 
> wanted to send two different PTs, you could do this in the offer:
> And send your PCM (or whatever) using PT 112 and send 4733 using PT 
> 113, and you'll get them back with those same PTs.
This type of operation is not specified anywhere in the draft though 
(you'd also need to say which mirror PT maps to which source PT). Still, 
I'm unclear on why we need this payload format. What problem does it 
solve (it just seems to introduce limitations right now) ?

Thanks

-- Flemming

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 03:42:15 -0500

Well I hate to answer on behalf of the authors, but since I need this thing to become an RFC, I'll try.
inline...

On Nov 9, 2010, at 12:55 AM, Flemming Andreasen wrote:

The serious answer is there's no way this draft could reasonably rely on using ICE/STUN/TURN to fix its NAT traversal, because that would severely limit the addressable market.  It'd be like saying "why don't you just use IPv6".   Unless you don't mean to use ICE as the only way to fix this, but rather are saying if the offerer and answerer support ICE, wouldn't that also solve it for them. (I couldn't tell from your question in which way you meant it)
Why is loopback special though ? Again, the endpoints presumably need to establish other types of media streams besides loopback, and those endpoints will encounter the same NAT, FW, media relay traversal issues, i.e. we need a general solution for media streams. As you know we already have that in ICE/STUN/TURN, however if the argument is that something else is needed, then that's an entirely different discussion above and beyond loopback.

I think you know that in practice lots of people don't use ICE/STUN/TURN to traverse NATs.  The loopback draft is meant to be as broadly applicable as possible, which means it can't rely on ICE to do NAT traversal.  Something else isn't "needed" - it already exists.  What it "needs", however, is for packets from behind the NAT to be sent _before_ packets back into the NAT.

Sure, but that doesn't solve the problem. If latching is required for this to work (and right now it seems to be), then it needs to be called out (at which point we'll enter into a much larger discussion around NAT traversal in general).

Latching isn't _required_ for it to work - if, for example, you _do_ support ICE then you're all set and don't need latching nor that attribute.  But if you don't have ICE, then you need it.  Regardless, latching and how to do NAT traversal is really a much larger discussion, as you say, and thus shouldn't hold up this draft... Unless what you're arguing for is a general solution to cases where a device behind a NAT needs to send something first, instead of being specific to loopback. (for example, the BFCP-over-UDP draft has this problem too)  But even then, I'd argue that it's unfair to make this draft wait for that type of work to happen.

And send your PCM (or whatever) using PT 112 and send 4733 using PT 113, and you'll get them back with those same PTs.
This type of operation is not specified anywhere in the draft though (you'd also need to say which mirror PT maps to which source PT).

Yeah, that should be cleared up by the authors - I'm not sure the authors would agree with me that such a thing would be possible that way.

Still, I'm unclear on why we need this payload format. What problem does it solve (it just seems to introduce limitations right now) ?

You mean why have a pkt-loopback mode to begin with, vs. just codec-layer/media mode?  Three reasons off the top of my head:
1) It lets the source send packets which aren't audio codec payload.  For example it can include sequence numbers in the payload, so that when it gets the packets back it can tell which got lost, or test different packet sizes.
2) It can avoid the buffering and codec delay on the mirror side, to measure more closely to the network layer.
3) It lets middleboxes like SBCs be a mirror without using DSPs.

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 09 Nov 2010 17:03:29 +0800

> thing to become an RFC, I'll try.
It would be good to hear from the authors and the group more broadly.
>>> The serious answer is there's no way this draft could reasonably 
>>> rely on using ICE/STUN/TURN to fix its NAT traversal, because that 
>>> would severely limit the addressable market.  It'd be like saying 
>>> "why don't you just use IPv6".   Unless you don't mean to use ICE as 
>>> the only way to fix this, but rather are saying if the offerer and 
>> Why is loopback special though ? Again, the endpoints presumably need 
>> to establish other types of media streams besides loopback, and those 
>> endpoints will encounter the same NAT, FW, media relay traversal 
>> issues, i.e. we need a general solution for media streams. As you 
>> know we already have that in ICE/STUN/TURN, however if the argument 
>> is that something else is needed, then that's an entirely different 
>> discussion above and beyond loopback.
>
> I think you know that in practice lots of people don't use 
> ICE/STUN/TURN to traverse NATs.  The loopback draft is meant to be as 
> broadly applicable as possible, which means it can't rely on ICE to do 
> NAT traversal.  Something else isn't "needed" - it already exists. 
>  What it "needs", however, is for packets from behind the NAT to be 
> sent _before_ packets back into the NAT.
>
I'm fine with that, but again I'll note that this issue cannot be unique 
to loopback but applies to media streams in general. If those 
implementations work today (with a little SBC help sometimes) without 
some sort of "primer" payload and without ICE/STUN/TURN, then why can't 
they do whatever it is they are doing today ? If they don't work, and 
they don't want to do ICE/STUN/TURN, then we have a larger issue that I 
don't think this draft should try and tackle if it wants to progress any 
time soon.

>
>>>>> No, in that case the loopback-source will latch on the packets 
>>>>> from the mirror (or some middlebox will).  And it works for the 
>>>>> opposite case as well, since the loopback-source also sends 
>>>>> packets.  The only case it doesn't work for is when they're both 
>>>>> behind NATs.  Oh shucks.
>>>>>
>>>> Neither this spec, RTP itself or offer/answer specifies this 
>>>> latching mode of operation. If latching is what the spec requires, 
>>>> then that needs to be called out and we can then have a discussion 
>>>> around the correct operation and security issues with that model (I 
>>>> believe this was already considered by BEHAVE/TURN years ago and 
>>>> rejected for those reasons, however I also understand that SBC's 
>>>> today may be using this model).
>>>
>> this to work (and right now it seems to be), then it needs to be 
>> called out (at which point we'll enter into a much larger discussion 
>> around NAT traversal in general).
>
> Latching isn't _required_ for it to work - if, for example, you _do_ 
> support ICE then you're all set and don't need latching nor that 
> attribute.  But if you don't have ICE, then you need it.
I do not understand how media streams beyond loopback work then - can 
you elaborate ?

>  Regardless, latching and how to do NAT traversal is really a much 
> larger discussion, as you say, and thus shouldn't hold up this 
> draft... Unless what you're arguing for is a general solution to cases 
> where a device behind a NAT needs to send something first, instead of 
> being specific to loopback. (for example, the BFCP-over-UDP draft has 
> this problem too)  But even then, I'd argue that it's unfair to make 
> this draft wait for that type of work to happen.
>
It seems to me that NAT traversal issues are the same for loopback and 
non-loopback media streams, and hence I don't think this draft should 
try and tackle NAT traversal, if it is anything but ICE/STUN/TURN based 
(which it probably should talk about).

>>> In theory, the pkt-loopback mode is basically agnostic to the 
>>> payload, and in practice I believe what PT you send is what you get 
>>> back.  It doesn't care about 4733 vs. PCM vs. whatever.  So I guess 
>>> if you wanted to send two different PTs, you could do this in the offer:
>> (you'd also need to say which mirror PT maps to which source PT).
>
> Yeah, that should be cleared up by the authors - I'm not sure the 
> authors would agree with me that such a thing would be possible that way.
>
>> Still, I'm unclear on why we need this payload format. What problem 
>> does it solve (it just seems to introduce limitations right now) ?
>
> You mean why have a pkt-loopback mode to begin with, vs. just 
> codec-layer/media mode?
No - I am asking specifically about the Direct RTP Payload *format*. The 
RTP loopback *mode* makes perfect sense - it's the media format I don't 
understand the motivation for (and it seems to introduce problems).

>  Three reasons off the top of my head:
> 1) It lets the source send packets which aren't audio codec payload. 
>  For example it can include sequence numbers in the payload, so that 
> when it gets the packets back it can tell which got lost, or test 
> different packet sizes.
> 2) It can avoid the buffering and codec delay on the mirror side, to 
> measure more closely to the network layer.
This all seems to talk to the RTP loopback *mode* - I'm asking about the 
Direct RTP Payload *format*.

Thanks

-- Flemming

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 04:19:47 -0500

On Nov 9, 2010, at 4:03 AM, Flemming Andreasen wrote:

> I'm fine with that, but again I'll note that this issue cannot be unique to loopback but applies to media streams in general. If those implementations work today (with a little SBC help sometimes) without some sort of "primer" payload and without ICE/STUN/TURN, then why can't they do whatever it is they are doing today ? 

Because in "normal" media cases you're sending RTP without waiting for the other side to send RTP.  In the loopback pkt-mode case, the mirror would be waiting for the source to send a packet before it sends the packet back, so clearly if the mirror is behind the NAT you're stuck.

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 09 Nov 2010 18:00:38 +0800

On 11/9/10 5:19 PM, Hadriel Kaplan wrote:
> > I'm fine with that, but again I'll note that this issue cannot be 
> unique to loopback but applies to media streams in general. If those 
> some sort of "primer" payload and without ICE/STUN/TURN, then why 
> can't they do whatever it is they are doing today ?
>
> Because in "normal" media cases you're sending RTP without waiting for 
> the other side to send RTP.  In the loopback pkt-mode case, the mirror 
> would be waiting for the source to send a packet before it sends the 
> packet back, so clearly if the mirror is behind the NAT you're stuck.
>
Right, however there are two issues here:
1) Use of latching to enable bi-directional NAT traversal instead of 
either an intermediary fixing the SDP (ala MIDCOM) or using ICE
2) Getting the side(s) behind the NAT to generate packets to create the 
required NAT binding(s)

Issue 1 needs to be resolved for any kind of media stream (i.e. not 
loopback specific).
Wrt issue 2, I believe your argument is that this is only an issue for 
loopback, however that is not the case. There is no guarantee that one 
side will generate media packets before the other and hence you may very 
well end up with having media streams that are now only unidirectional, 
i.e. the issue needs to be resolved for media streams in general (where 
loopback primer would seem to be a less than ideal solution). How do you 
solve these issues in practice today for non-loopback media streams ?

Additional problems to consider for the loopback primer:
- How does the mirror know it's behind a NAT ?
- What happens when both endpoints are behind NATs ?
- What happens when you have overlapping addresses and multiple sessions 
(the correlation problem solved by ICE)
- etc. (basically all the issues that lead to ICE being as comprehensive 
as it is).

You may not want to address all of these, but if so, the shortcomings 
need to be called out and we then need a discussion as to whether people 
are happy with those shortcomings and believe we should specify a much 
more restricted solution.

-- Flemming

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 09:58:04 -0500

On Nov 9, 2010, at 5:00 AM, Flemming Andreasen wrote:

> 1) Use of latching to enable bi-directional NAT traversal instead of either an intermediary fixing the SDP (ala MIDCOM) or using ICE
> 2) Getting the side(s) behind the NAT to generate packets to create the required NAT binding(s)
> 
> Issue 1 needs to be resolved for any kind of media stream (i.e. not loopback specific). 
> Wrt issue 2, I believe your argument is that this is only an issue for loopback, however that is not the case. There is no guarantee that one side will generate media packets before the other and hence you may very well end up with having media streams that are now only unidirectional, i.e. the issue needs to be resolved for media streams in general (where loopback primer would seem to be a less than ideal solution). How do you solve these issues in practice today for non-loopback media streams ? 

Do you mean with a middlebox (ie, SBC), or without a middlebox?  As far as I've seen there is no problem today for non-loopback RTP streams, when there are middleboxes.  Of course I only represent one middlebox company's perspective, and maybe others have seen differently. (though in my defense, we're deployed in  ~1,000 service providers, so I'm guessing I can't be too crazy thinking it works)

Without a middlebox, of course you have to use ICE/STUN/TURN or UpNP or whatever.

> - How does the mirror know it's behind a NAT ? 

It doesn't need to.

> - What happens when both endpoints are behind NATs ? 

They're not. (two endpoint phones don't do media loopback to each other, in practice, afaict)  But if they were, and there was a middlebox (SBC/whatever), it would work the same; or you can use ICE.  I'm not saying ICE shouldn't be allowed, I'm saying it can't be mandatory.

> - What happens when you have overlapping addresses and multiple sessions (the correlation problem solved by ICE)
> - etc. (basically all the issues that lead to ICE being as comprehensive as it is). 

With a middlebox, there is no such correlation problem.  Without one, you have to fix it yourself, using ICE or whatever.

> 
> You may not want to address all of these, but if so, the shortcomings need to be called out and we then need a discussion as to whether people are happy with those shortcomings and believe we should specify a much more restricted solution. 

In what way is it a "much more restricted solution"?  (on the contrary, mandating ICE would be far more restrictive)  Or are you just saying that it needs to _allow_ for ICE?  

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 10 Nov 2010 11:38:08 +0800

Let me try and summarize:

There is no need to mandate ICE for this draft, however the problem I 
have is that it is currently trying to specify an alternative to ICE 
that has much more limited scope and only works in specific deployment 
scenarios. Yet, at the same time, the NAT traversal problems that 
loopback seems to think it needs to address are somehow not an issue for 
non-loopback media streams even though they may exhibit the exact same 
send/receive characteristics as a loopback stream. This either doesn't 
add up or I'm missing something.

Furthermore, your comments below seem to suggest that for the proposal 
to work, there needs to be middleboxes in place.

More below...

On 11/9/10 10:58 PM, Hadriel Kaplan wrote:
> > Wrt issue 2, I believe your argument is that this is only an issue 
> for loopback, however that is not the case. There is no guarantee that 
> one side will generate media packets before the other and hence you 
> may very well end up with having media streams that are now only 
> unidirectional, i.e. the issue needs to be resolved for media streams 
> in general (where loopback primer would seem to be a less than ideal 
> solution). How do you solve these issues in practice today for 
> non-loopback media streams ?
>
> Do you mean with a middlebox (ie, SBC), or without a middlebox?  As 
> far as I've seen there is no problem today for non-loopback RTP 
> streams, when there are middleboxes.
>
However non-loopback media may be generated from the offerer before the 
answerer generates anything (or vice versa), so why is there not a 
problem here, but there is for loopback ?

> Of course I only represent one middlebox company's perspective, and 
> maybe others have seen differently. (though in my defense, we're 
> deployed in  ~1,000 service providers, so I'm guessing I can't be too 
> crazy thinking it works)
>
Ok - so are you saying that the loopback primer method is only 
applicable when there is a middlebox and if there is not a middlebox, 
then NAT traversal does indeed require ICE, UPnP, etc (and we should say 
so in the draft) ?
> > - How does the mirror know it's behind a NAT ?
How does it know that it needs to generate loopback primer packets then ?

> They're not. (two endpoint phones don't do media loopback to each 
> other, in practice, afaict)  But if they were, and there was a 
> middlebox (SBC/whatever), it would work the same; or you can use ICE.  
> I'm not saying ICE shouldn't be allowed, I'm saying it can't be mandatory.
>
I'm fine with not mandating ICE (it just may not work behind NATs then). 
The problem is when we start specifying a different NAT traversal 
mechanism that has a number of limitations and now also seems to require 
middleboxes to work, yet none of this is called out or has been 
discussed anywhere as far as I know.

>
> > - What happens when you have overlapping addresses and multiple 
> sessions (the correlation problem solved by ICE)
> With a middlebox, there is no such correlation problem.  Without one, 
> you have to fix it yourself, using ICE or whatever.
>
> >
> > You may not want to address all of these, but if so, the 
> shortcomings need to be called out and we then need a discussion as to 
> whether people are happy with those shortcomings and believe we should 
> specify a much more restricted solution.
>
> In what way is it a "much more restricted solution"?  (on the 
> contrary, mandating ICE would be far more restrictive)  Or are you 
> just saying that it needs to _allow_ for ICE?
>
It's restrictive inasmuch as it only works in a specific set of 
scenarios, which are not called out in the draft. ICE on other hand 
would work in any scenario.

-- Flemming

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 23:48:56 -0500

On Nov 9, 2010, at 10:38 PM, Flemming Andreasen wrote:

There is no need to mandate ICE for this draft, however the problem I have is that it is currently trying to specify an alternative to ICE that has much more limited scope and only works in specific deployment scenarios.

OK, so if the draft specified one could use ICE instead of primer, by the offerer putting both in the offer and the answerer picking ICE if it supports ICE (and under the constraints for doing so defined in ICE RFC), but otherwise doing the primer, would that be ok?

Yet, at the same time, the NAT traversal problems that loopback seems to think it needs to address are somehow not an issue for non-loopback media streams even though they may exhibit the exact same send/receive characteristics as a loopback stream. This either doesn't add up or I'm missing something.

The only thing you're missing (I think) is that in pkt-loopback mode no RTP packets are sent by the mirror, ever, until it gets a packet from the source.  Hence if the mirror is behind a NAT, it needs to send something out first.

However non-loopback media may be generated from the offerer before the answerer generates anything (or vice versa), so why is there not a problem here, but there is for loopback ?

For non-loopback media (ie, normal calls today), the offerer can't send media until it gets the answer, since clearly it has no address info to send RTP to.  The answerer can send as soon as it gets the offer, and once the answer gets back to the offerer, it can send media.  So regardless of which side is behind a NAT (or both), they'll open up their respective pinholes.  The SDP will of course have been changed by the middlebox to be the middlebox, so that the two UAs have a public address they can reach.  The middlebox latches onto what it gets, and uses the learned address to send the media back.  Of course that presumes devices behind NATs send RTP out, which in practice they do.
 (I should caveat this with there're some more tricks middleboxes have to employ to get that all to happen sometimes, but I assume we don't want to get into that whole topic on this thread or mailing list)

Ok - so are you saying that the loopback primer method is only applicable when there is a middlebox and if there is not a middlebox, then NAT traversal does indeed require ICE, UPnP, etc (and we should say so in the draft) ?

I'm ok with saying that in the draft, but it seems to be just us two having this email conversation. :)

It doesn't need to.

What I meant was it doesn't need to know, because it won't hurt if it _always_ sends the primers.  I.e., there's no decision it has to make.

It's restrictive inasmuch as it only works in a specific set of scenarios, which are not called out in the draft. ICE on other hand would work in any scenario.

That's misleading.  ICE only works in scenarios whereby both sides support ICE, and can both send and receive packets from the public Internet through their NATs, and have a STUN and/or TURN server available.  That is not "any scenario".  Just like UPnP doesn't work in all scenarios.  Of course needing to have a middlebox means you need to have a middlebox, so that's not universal either.  But my point is there is no universal magic cure.

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 10 Nov 2010 14:27:33 +0800

On 11/10/10 12:48 PM, Hadriel Kaplan wrote:
>> that has much more limited scope and only works in specific 
>> deployment scenarios.
>
> OK, so if the draft specified one could use ICE instead of primer, by 
> the offerer putting both in the offer and the answerer picking ICE if 
> it supports ICE (and under the constraints for doing so defined in ICE 
> RFC), but otherwise doing the primer, would that be ok?
>
I think we need more group discussion on that. The basic question is 
whether we want to define something like the loopback primer as a NAT 
traversal solution. If we do, then we at least need to call out the 
underlying assumptions for this to work as well as the limitations 
associated with it.

>
>> Yet, at the same time, the NAT traversal problems that loopback seems 
>> to think it needs to address are somehow not an issue for 
>> non-loopback media streams even though they may exhibit the exact 
>> same send/receive characteristics as a loopback stream. This either 
>> doesn't add up or I'm missing something.
>
> The only thing you're missing (I think) is that in pkt-loopback mode 
> no RTP packets are sent by the mirror, ever, until it gets a packet 
> from the source.  Hence if the mirror is behind a NAT, it needs to 
> send something out first.
>
Does that *have* to be a loopback-primer payload, or could it be using 
existing payload formats (in which case you would be more into 
conventions for doing certain things, and those conventions could 
presumably be used by non-loopback streams as well).

>
>> However non-loopback media may be generated from the offerer before 
>> the answerer generates anything (or vice versa), so why is there not 
>> a problem here, but there is for loopback ?
>
> For non-loopback media (ie, normal calls today), the offerer can't 
> send media until it gets the answer, since clearly it has no address 
> info to send RTP to.  The answerer can send as soon as it gets the 
> offer, and once the answer gets back to the offerer, it can send 
> media.  So regardless of which side is behind a NAT (or both), they'll 
> open up their respective pinholes.  The SDP will of course have been 
> changed by the middlebox to be the middlebox, so that the two UAs have 
> a public address they can reach.  The middlebox latches onto what it 
> gets, and uses the learned address to send the media back.  Of course 
> that presumes devices behind NATs send RTP out, which in practice they do.
This latter part is the key assumption for this to work. The question is 
why they send out RTP; you can certainly think of scenarios where that 
wouldn't be required, and hence the question is whether these devices 
perhaps couldn't just do something similar for the loopback stream to 
make things work in practice if they don't want to do ICE.

>  (I should caveat this with there're some more tricks middleboxes have 
> to employ to get that all to happen sometimes, but I assume we don't 
> want to get into that whole topic on this thread or mailing list)
>
Well, I'm not so sure, because I'm suspecting that some of these tricks 
are needed because the endpoints in fact do not generate RTP ahead of 
time (or at least one of them doesn't in the case where both of them are 
behind NATs). If so, then we've found the problem to apply beyond 
loopback streams and clearly it shouldn't be loopback specific at that 
point.

>> then NAT traversal does indeed require ICE, UPnP, etc (and we should 
>> say so in the draft) ?
>
Yeah - would be good to hear from at least the authors.

Thanks

-- Flemming

---

From: "Kaynam Hedayat" <[email-masked]>
Date: Mon, 22 Nov 2010 15:48:16 -0500

All,

Thank you for the lively discussion. We are glad to see that there is
interest in the community to complete this draft and we welcome all the
comments. Here is a summary of the major & minor topics raised and our
thinking on each of them.

- Breaking the offer/answer model

[Authors] Muthu clearly explained the motivation behind the approach in
the draft (basically not wanting to do two m= lines for packet
loopback). We believe that the proposal made by Flemming to keep all the
payload types in the m= line and using the loopback-source and
loopback-mirror attributes to constrain the payload in each specific
direction is a minor change to the draft that will bring us in
compliance with the O/A model and help put this issue finally to bed.

- NAT Traversal and usage of ICE

[Authors] As Hadriel mentioned, if you have ICE you don't need the
loopback primer. As he also clarified, the loopback situation is
different from standard calls because the mirror will never send a
packet until it receives something from the source. This is certainly
possible for a regular call and calls may fail for that reason, but the
loopback draft is dead without a solution for this problem. Remember
that the primary use case for this draft is service providers wanting to
test to subscriber devices that are almost always behind NATs. The
proposed solution meets the requirements for the dominant use case and
while standard solutions are certainly usable when they are available,
the unfortunate reality is that most of them are not implemented. We can
add clarification text that if available ICE should be used instead of
the loopback primer method.

- The Direct loopback RTP payload format and concerns for multiple
payload types in the same stream
[Authors] The primary attraction of the direct loopback payload format
is to enable very simple mirror implementations. The mirror has to
change a few bits in the source packet and can send it back to the
source. It is true that the source would not be able to say which
response packet corresponds to which source payload, but if that is the
use case the encapsulated payload format can be used. The direct
loopback mode meets the requirements of the major use case; it is also
simple enough that every implementation of the draft we know currently
has it (not so with encapsulated RTP).

- SRTP Consideration

[Authors] We agree with your comment. In the interest of completing this
draft we suggest stating that handling SRTP is for future consideration
and we can address it in the next loopback draft.

Minor topics:

[Authors] Agreed. We will fix this. We will use the "offerer" and
"answerer" more consistently.

[Authors] We will fix this. It will help us if you can point out the
specific text.

[Authors] Agreed. We will fix this.

- Security consideration

[Authors] Per above we think we should leave SRTP for future
consideration.

[Authors] Agreed. We will fix this.

Regards,

Kaynam & Nagarjuna

From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, November 09, 2010 11:49 PM
To: Flemming Andreasen
Cc: mmusic; [email-masked]
Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-14 review and
comments

scenarios. 

OK, so if the draft specified one could use ICE instead of primer, by
the offerer putting both in the offer and the answerer picking ICE if it
supports ICE (and under the constraints for doing so defined in ICE
RFC), but otherwise doing the primer, would that be ok?

Yet, at the same time, the NAT traversal problems that loopback seems to
think it needs to address are somehow not an issue for non-loopback
media streams even though they may exhibit the exact same send/receive
characteristics as a loopback stream. This either doesn't add up or I'm
missing something. 

The only thing you're missing (I think) is that in pkt-loopback mode no
RTP packets are sent by the mirror, ever, until it gets a packet from
the source.  Hence if the mirror is behind a NAT, it needs to send
something out first.

For non-loopback media (ie, normal calls today), the offerer can't send
media until it gets the answer, since clearly it has no address info to
send RTP to.  The answerer can send as soon as it gets the offer, and
once the answer gets back to the offerer, it can send media.  So
regardless of which side is behind a NAT (or both), they'll open up
their respective pinholes.  The SDP will of course have been changed by
the middlebox to be the middlebox, so that the two UAs have a public
address they can reach.  The middlebox latches onto what it gets, and
uses the learned address to send the media back.  Of course that
presumes devices behind NATs send RTP out, which in practice they do.

I'm ok with saying that in the draft, but it seems to be just us two
having this email conversation. :)

	
	It doesn't need to.

How does it know that it needs to generate loopback primer packets then
? 

What I meant was it doesn't need to know, because it won't hurt if it
_always_ sends the primers.  I.e., there's no decision it has to make.

	In what way is it a "much more restricted solution"?  (on the
contrary, mandating ICE would be far more restrictive)  Or are you just
saying that it needs to _allow_ for ICE? 

That's misleading.  ICE only works in scenarios whereby both sides
support ICE, and can both send and receive packets from the public
Internet through their NATs, and have a STUN and/or TURN server
available.  That is not "any scenario".  Just like UPnP doesn't work in
all scenarios.  Of course needing to have a middlebox means you need to
have a middlebox, so that's not universal either.  But my point is there
is no universal magic cure.

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 29 Nov 2010 17:59:13 -0500

On 11/22/10 3:48 PM, Kaynam Hedayat wrote:
> interest in the community to complete this draft and we welcome all 
> the comments. Here is a summary of the major & minor topics raised and 
> our thinking on each of them.
>
> [Authors] Muthu clearly explained the motivation behind the approach 
> in the draft (basically not wanting to do two m= lines for packet 
> loopback). We believe that the proposal made by Flemming to keep all 
> the payload types in the m= line and using the loopback-source and 
Great - thx.

> possible for a regular call and calls may fail for that reason, but 
> the loopback draft is dead without a solution for this problem. 
> Remember that the primary use case for this draft is service providers 
> wanting to test to subscriber devices that are almost always behind 
> NATs. The proposed solution meets the requirements for the dominant 
> use case and while standard solutions are certainly usable when they 
> are available, the unfortunate reality is that most of them are not 
> implemented. We can add clarification text that if available ICE 
> should be used instead of the loopback primer method.
>
Thanks. The draft will also need to clearly explain how the loopback 
primer would work, and in particular what the underlying assumptions are 
(e.g. latching) as well as when it will not work (e.g. when both source 
and mirror are behind a NAT, when you have overlapping IP-addresses and 
ports, etc). In short, the limitations of this approach must be clearly 
documented.

I will also check with our AD as to whether there are any additional 
concerns with specifying such a solution when we already have ICE as the 
Standard.

> response packet corresponds to which source payload, but if that is 
> the use case the encapsulated payload format can be used. The direct 
It would seem even simpler to use the payload format the packet arrived 
in. If we do keep this format, then the above limitation should at a 
minimum be called out. However, I'm still unclear on the motivation for 
this format - can you elaborate ?

> - SRTP Consideration
>
> [Authors] We agree with your comment. In the interest of completing 
> this draft we suggest stating that handling SRTP is for future 
> consideration and we can address it in the next loopback draft.
>
In an upcoming version of the draft or a different RFC altogether ? It 
wouldn't seem that hard to add SRTP considerations, so I would suggest 
the draft will include those before we make it into an RFC.

> [Authors] We will fix this. It will help us if you can point out the 
I'll forward an annotated version of the document off-line.
> [Authors] Agreed. We will fix this.
Thanks.
> [Authors] Per above we think we should leave SRTP for future 
I don't believe it changes anything that's already specified, and since 
I don't think adding SRTP support will require a lot, I'd suggest we add 
that.

Thanks

-- Flemming

> Regards,
>
> Kaynam & Nagarjuna
>
> *From:* Hadriel Kaplan [mailto:[email-masked]]
> *Sent:* Tuesday, November 09, 2010 11:49 PM
> *To:* Flemming Andreasen
> *Cc:* mmusic; [email-masked]
> *Subject:* Re: [MMUSIC] draft-ietf-mmusic-media-loopback-14 review and 
> comments
>
> to think it needs to address are somehow not an issue for non-loopback 
> characteristics as a loopback stream. This either doesn't add up or 
> I'm missing something.
>
> the answerer generates anything (or vice versa), so why is there not a 
>     shortcomings need to be called out and we then need a discussion
>     as to whether people are happy with those shortcomings and believe
>     we should specify a much more restricted solution.
>
>
> available.  That is not "any scenario".  Just like UPnP doesn't work 
> in all scenarios.  Of course needing to have a middlebox means you 
> need to have a middlebox, so that's not universal either.  But my 
> point is there is no universal magic cure.
>
> -hadriel
>