Subject: [MMUSIC] Media loopback draft and General Need for ICE alternative ?

From: Flemming Andreasen <[email-masked]>
Date: Tue, 05 Jul 2011 19:59:25 -0400

Hi MMUSIC

We haven't seen much list discussion on this one. It would be really 
useful if the WG participants could provide some feedback on the media 
loopback points raised below so we can determine the best way to proceed 
here. In particular, we would like to know if the WG believes that the 
alternative NAT traversal mechanism (latching) proposed in the draft is 
generally applicable outside of the media loopback use case, and/or if 
we in general need an alternative to ICE for NAT traversal.

Please send your comments to the list.

Thanks

-- Flemming
(as MMUSIC co-chair)

-------- Original Message --------
Subject: 	RE: [MMUSIC] Media loopback 
revisited(draft-ietf-mmusic-media-loopback-15.txt)
Date: 	Wed, 1 Jun 2011 07:02:45 -0500
From: 	Kaynam Hedayat <[email-masked]>
To: 	Flemming Andreasen (fandreas) <[email-masked]>, 
<[email-masked]>
CC: 	mmusic <[email-masked]>

Flemming,

Thank you for reviewing the new version of the draft. Some comments from 
the authors below.

Regards,

Kaynam

*From:* [email-masked] [mailto:[email-masked]] *On 
Behalf Of *Flemming Andreasen
*Sent:* Thursday, May 12, 2011 8:06 PM
*To:* [email-masked]
*Cc:* mmusic
*Subject:* [MMUSIC] Media loopback 
revisited(draft-ietf-mmusic-media-loopback-15.txt)

Hi

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

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

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

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

*/[KH] Looking forward to feedback from the group. Please note that 
there are implementations of this mechanism in existing products and in 
use by operators. All implementers are aware that ICE is the preferred 
mechanism and plan to use this mechanism only if ICE is NOT available./*

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

*/[KH] /**/The authors will remove the requirement for the offerer to 
accept the Loopback Pump media format if it did not include it in the 
offer. If the offerer does not have the Loopback Pump media format in 
the offer, the answerer may stay still include it in the response. But 
in this case the offerer is not obligated to accept the call./**//*

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

*/[KH] The authors will explain this behavior in the draft with a MUST./*

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

*/[KH] The authors prefer to keep one draft. Please advise on when is 
the right time to send for PAYLOAD WG review./*

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

Thanks

-- Flemming

---

From: Olivier Crête <[email-masked]>
Date: Tue, 05 Jul 2011 20:23:39 -0400

On Tue, 2011-07-05 at 19:59 -0400, Flemming Andreasen wrote:
> In particular, we would like to know if the WG believes that the
> alternative NAT traversal mechanism (latching) proposed in the draft
> is generally applicable outside of the media loopback use case, and/or
> if we in general need an alternative to ICE for NAT traversal. 

As someone who works on VoIP clients for use over the real Internet (not
a closed network), I'm not so happy by any draft proposing workaround
for people who are too lazy to implement ICE+TURN. Because everything
else is annoyingly unreliable. The proposed latching mechanism will not
work in every case and seems really a poor workaround for not having
ICE. Since any client using media loopback will need both sides to be
updated, there is no reason to not require ICE for any case where a NAT
can exist, obviously ICE may not be needed in a purely client-server
model or in a closed controlled network.

-- 
Olivier Crête
[email-masked]

---

From: Emil Ivov <[email-masked]>
Date: Wed, 06 Jul 2011 19:36:14 +0200

На 06.07.11 02:23, Olivier Crête написа:
> else is annoyingly unreliable. The proposed latching mechanism

I don't see a proposed latching mechanism in the document. What I saw
was a fallback mechanism in case ICE is killed by a proxy that does
latching (which is what the overwhelming majority of the SIP proxies on
the real Internet do).

> will not
> ICE.

Sure, but if you can't use ICE because someone in the middle mangled
your SDP, then I suppose a poor workaround is better than nothing.

> Since any client using media loopback will need both sides to be
> updated,

The problem here does not come from the sides that need to support
loopback. The issue is caused by middle boxes that are loopback
agnostic. As much as I appreciate ICE and what it brings to RTC, and as
much as I'd like to believe that everyone would end up adopting it, it
simply sounds unreasonable to pretend that everyone is already using it.

On a side note, "the chicken and egg" problem described in the draft is
similar to what happens with unidirectional streams (e.g. where one side
starts transmitting video while the other is in recvonly). The solution
proposed in this draft would also be handy in such a situation so it
would probably make sense to have it in a separate document. Of course
such a document would have to be make it clear it only exists for
backward compatibility and that it should only be used if ICE is blocked.

Emil

--
http://jitsi.org

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 06 Jul 2011 16:44:10 -0400

> latching (which is what the overwhelming majority of the SIP proxies on
Please see Section 5.7 in the loopback draft, which defines a latching 
mechanism as an alternative to ICE, not a fallback if ICE is 
blocked/doesn't work.

> your SDP, then I suppose a poor workaround is better than nothing.
The proposed latching mechanism depends on SDP extensions as well, so it 
would seem equally vulnerable to SDP mangling by an intermediary.

> simply sounds unreasonable to pretend that everyone is already using it.
It's not a question of whether everybody is using it. It's a question of 
whether there is a problem with ICE and we need an alternative like this 
proposed latching mechanism.

> backward compatibility and that it should only be used if ICE is blocked.
If I read your comments right, the only issue you have with ICE is that 
it may be blocked whereas another solution (like latching) might not be. 
Is that an accurate summary ?

Thanks

-- Flemming

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

---

From: Emil Ivov <[email-masked]>
Date: Thu, 07 Jul 2011 01:07:45 +0200

> mechanism as an alternative to ICE, not a fallback if ICE is

I suppose I am missing something because in section 5 I read:

    ICE/STUN/TURN provide a general solution ...
    ... Loopback sessions ... SHOULD use these general solutions
    wherever possible ... In scenarios where ICE/STUN/TURN is not
    available [and C1] ... the following solution MAY be adapted.

(I am not sure why C1, requiring that the loopback source has a public
IP address, is necessary here but we can probably come back to this later).

So, the way I understand this is that loopback clients need to have and
use ICE. If ICE is not there they could try to compensate using the
mechanism described in 5.7.

As to the mechanism itself it basically says that mirrors shouldn't wait
to hear from the source and that they should start streaming as soon as
they are ready. To me this sounds quite reasonable. It's basic hole
punching and, as I said in my previous mail, it could also be of use in
other cases.

So here's a scenario where I see this reasonable. S (source) supports
ICE and calls M (mirror) which also supports ICE. They are both behind
NATs and they are both connected to a common SIP server, say iptel.org.
When S's INVITE goes through the iptel.org proxy it replaces the
connection address in the SDP with that of its RTP proxy. This of course
means that even though it would see the entire candidate list M would
have to disable ICE. So in this case, which is not at all uncommon, the
technique in 5.7 would be the only way to get media flowing both ways.

Also, in this case, the only one doing latching is the iptel.org service
(not the endpoints that do loopback) and the mechanism from 5.7 allows
to work around it.

> would seem equally vulnerable to SDP mangling by an intermediary.

Well I guess I must be missing something because I only see regular SDP
in this scenario and nothing that would be vulnerable to a middle box.

> Is that an accurate summary ?

My point is that everyone is using latching and latching disables ICE
and in such cases it would be nice for clients to have something to fall
back to.

I don't see anything in this document being an actual alternative to ICE.

Emil

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 06 Jul 2011 20:39:39 -0400

> mechanism described in 5.7.
ICE is at SHOULD strength, not MUST, and there are no fallback 
procedures defined that says to use ICE first and if it fails, then use 
latching. The way it's written currently is basically an alternative to 
implementations without ICE.

> they are ready.
No - that is not what the draft says. The draft defines a new payload 
type called "loopbkprimer" and associated procedures for using it to 
punch holes and associated latching operation on the RTP endpoint itself 
(latching details are not spelled out in detail in the draft currently).

> To me this sounds quite reasonable. It's basic hole
> have to disable ICE.
- How does the iptel.org proxy know it needs to insert a RTP proxy ?
- How would M know an RTP proxy was inserted and that M needs to disable 
ICE ?
- Why does M need to disable ICE in this case rather than let it run its 
course - is there an assumption that this RTP proxy will not pass ICE 
packets through and trying to do ICE will somehow incur problems ?

> So in this case, which is not at all uncommon, the
ICE enables two endpoints to be behind a NAT as well. It may require 
TURN instead of an RTP proxy as is suggested in this example. The 
advantage of a TURN based solution is that it will work for other types 
of media streams than RTP.

> (not the endpoints that do loopback) and the mechanism from 5.7 allows
That's not clear based on your description. The mechanism in section 5.7 
would require both S and M to be loopback-mirrors and send the loopback 
primer packets to the RTP proxy, which in turn needs to be a 
loopback-source for both endpoints and at this point is no longer a 
proxy (nor is the iptel.org "proxy").

> in this scenario and nothing that would be vulnerable to a middle box.
If you only see regular SDP, then you are not following the mechanism 
defined in the loopback draft (loopback, mirror and source SDP 
attributes and loopbkprimer payload format).

> I don't see anything in this document being an actual alternative to ICE.
It defines a NAT traversal solution different from ICE, and that will 
only work under certain assumptions. The question is whether the WG 
believes we need such a mechanism in general, and if so why.

Thanks

-- Flemming

---

From: Emil Ivov <[email-masked]>
Date: Thu, 07 Jul 2011 07:44:28 +0200

На 07.07.11 02:39, Flemming Andreasen написа:
> latching.

Definitely not. I never meant to imply there were. It is however a
fallback in the case endpoints are prevented from even starting ICE.

> (latching details are not spelled out in detail in the draft currently).

Indeed and this is exactly what I was referring to. The "loopbkprimer"
is the payload type that mirrors "should start streaming as soon as they
are ready" rather than "wait[ing] to hear from the source first".

> - How does the iptel.org proxy know it needs to insert a RTP proxy ?

It either does so unconditionally or it recognizes the addresses in the
SDP as non-public so it replaces them. This how the overwhelming
majority of the Internet VoIP providers out there handle NAT traversal.

> - How would M know an RTP proxy was inserted and that M needs to disable

Because the default candidate (the one inserted by the proxy) is not in
the candidate list.

> course 

Because 5245 says so (Section 5.1):

   The agent will proceed with the ICE procedures defined in this
   specification if, for each media stream in the SDP it received, the
   default destination for each component of that media stream appears
   in a candidate attribute.

   ...

   If this condition is not met, the agent MUST process the SDP based on
   normal RFC 3264 procedures

> is there an assumption that this RTP proxy will not pass ICE

I suppose this would be one of the reasons yes. I didn't follow the
discussions that led to this text back in the time but I'd guess the
assumption was that if someone in the signalling path is taking control
then it would be best not to get in the way.

> proxy (nor is the iptel.org "proxy").

I am not following. Why would both S and M need to be mirrors? S would
start streaming ... it has no reason not to. The RTP proxy in the middle
however won't be able to relay its packets until it hears from M. Until
then, it simply wouldn't know where to relay them to.

> attributes and loopbkprimer payload format).

How are these "irregular" SDP and what reason would a middle box have to
remove them?

> believes we need such a mechanism in general, and if so why.

Well again, I don't see anything in this draft that would allow two
clients, both of which are behind a NAT, to talk to each other. The
relay in the middle does. In that respect I don't see how anyone can
pretend that the loopback primer is an "alternative to ICE". It is not.
 It does not provide means for clients to discover a direct path to each
other. It does not provide relaying. It only helps to resolve a
starvation in the echo use case and in a scenario where a regular
bi-directional voip call would have worked anyway because of the
latching that middle boxes are doing.

Emil

--
http://jitsi.org

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 07 Jul 2011 10:49:53 -0400

Thanks - I now understand your point about ice-mismatch and how latching 
may be a fallback in that case (I'll note that this is not how the 
loopback draft currently describes it though). More below (snipped some 
stuff).

> >> На 06.07.11 22:44, Flemming Andreasen написа:
<snip>

> then, it simply wouldn't know where to relay them to.
You're right. So:
1) M starts sending loopbkprimer packets to R (RTP Proxy), which has no 
idea where to send them yet (since S is behind a NAT). RTP proxy can 
however do latching operation for M at this point.
2) S starts sending loopback packets to R (RTP Proxy), which can forward 
them to M because of the latching operation done in step 1).
3) R can now also do latching operation for S and hence we have a 
two-way path between S and M via R
4) S receives loopback packet and stops sending loopback primer packets 
at this point
5) Loopback between S and M is verified (via R)

> How are these "irregular" SDP and what reason would a middle box have to
My point is that they are just as regular or irregular as any other SDP, 
including ICE. The one difference I do see at this point is that by the 
middle box changing address information in the SDP, it will effectively 
turn off ICE based on the ice-mismatch procedure you pointed out. The 
loopback mechanism will not suffer from this problem, as long as the 
middle box passes through the SDP with whatever parameters it contains 
(i.e. the middle box does not insist on understanding the SDP itself; if 
it did, it would have to support the loopback mechanism including its 
defined SDP extensions and loopback primer payload).

> latching that middle boxes are doing.
I agree with your point above, however it does also provide a limited 
alternative to ICE inasmuch as it defines an alternative NAT traversal 
mechanism that can be used in certain limited deployment scenarios 
(without relays), and the way the draft is written currently, that's the 
way this mechanim is positioned as well. Again, you are bringing up 
another real-life use case that has merit IMO. It would be good to know 
if there are others.

Thanks

-- Flemming

---

From: Emil Ivov <[email-masked]>
Date: Thu, 07 Jul 2011 18:31:16 +0200

Hey Flemming,

На 07.07.11 16:49, Flemming Andreasen написа:

<snip>

> defined SDP extensions and loopback primer payload).

Wel does it really need to support the payload or any loopback-specific
mechanisms? I apologise if I am missing something but, as long as the
middle box is not planning on absolutely decoding media, it should be
OK. According to my experience, it is reasonable to expect that most SIP
proxies would handle this properly.

I am of course only talking about the NAT traversal/latching aspects of
the draft. Obviously the echo-related params may be more exposed to
pruning.

<snip>

> another real-life use case that has merit IMO. It would be good to know

Well, there's also the case of UDP-only SIP proxies. I have yet to see a
real-life audio/video INVITE that can fit into a single ethernet MTU
together with an ICE candidate lists. In such cases clients may again
wish to fall back to an ICEless leap of faith and hope for latching.

Of course, UDP-only proxies being prohibited by 3261, this case may be
considered irrelevant. Still, I thought I' mention it anyway given that
many providers out there choose not to enable TCP regardless of what
3261 says.

Cheers,
Emil

-- 
http://jitsi.org