Subject: Re: [MMUSIC] ICE feature - TCP alternates for a UDP stream

From: Magnus Westerlund <[email-masked]>
Date: Fri, 04 Feb 2005 10:42:03 +0100

Hi Jonathan,

Some questions.

The first problem I see is the signalling:

m=audio 49170 RTP/AVP 0
a=candidate 1 0.4 adsasda 9as8dasd 1.2.3.4 49170 10.0.1.1 8700
a=candidate 1 0.4 asf9fdf8 00d-ffas 1.2.3.4 49171 10.0.1.1 8765

As you need a "m=" line with
m=audio 9 TCP/RTP/AVP 0

to indicate that contrans framing should be used over TCP. Thus you need 
a binding attribute to bind the media blocks together, much like the 
grouping of media lines grouping semantic "ANAT" but now for different 
protocol identifiers.

I know that you proposed another way, however we do need to use explicit 
protocol identifiers for this in my opinion. If I would like to use 
another framing mechanism, or run protocol foo over foo with ICE your 
proposal would block it. Also there is certain mechanism like security 
and that are transport dependent and which parameters are specified on 
media block level. If you group things under the candidate attribute you 
create huge problem deploying current and future mechanism.

Also isn't there a uncertainty in the demultiplexing of contrans frames 
and STUN packets if sent over the same TCP connection. In contrans it is 
quite likely that the first byte is 0, this will be true for all RTP 
packets smaller than 255 bytes, which is most audio. Have you worked out 
if you can end up with a reliable demultiplexing in this case.

I also don't know about standardizing firewall circumvention techniques. 
I do understand most would consider this a solution for the homes that 
run a FW without the knowledge to configure it correctly. However it is 
still going into a questionable land.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Feb 2005 09:36:58 -0500

> As you need a "m=" line with

The m line would be for UDP. The candidate would be the thing that 
indicates TCP:

m=audio 49170 RTP/AVP 0
a=candidate 1 0.4 adsasda 9as8dasd 1.2.3.4 49170 TCP 10.0.1.1 passive
a=candidate 1 0.4 asf9fdf8 00d-ffas 1.2.3.4 49171 UDP 10.0.1.1 8765

where the first candidate lists a TCP alternative to the UDP "primary" 
stream, and the second candidate lists a UDP alternative.

I
> grouping of media lines grouping semantic "ANAT" but now for different 

The idea is that any information about the candidate will go in the line 
that defines the candidate. As such, I don't think there is a need for 
the grouping framework.

> create huge problem deploying current and future mechanism.

OK, I understand your point. I think that it really depends on how much 
of the information that needs to be conveyed is actually transport 
dependent. You mention security. Are the SRTP parameters transport 
dependent? I didnt think so....

> if you can end up with a reliable demultiplexing in this case.

I havent considered it fully yet. I will say, per the discussion with 
Francois, it is not clear that the STUN connectivity checks are really 
needed over TCP, so it may be a moot point.

> still going into a questionable land.

Its not a circumvention technique at all. Circumvention is when you try 
to make one protocol look like another in order to get traffic through a 
more permissive policy that is associated with the other protocol. Here, 
we aren't making RTP look like anything it already isn't. We already 
HAVE a way of transporting RTP over TCP. What we don't have is a way for 
me to usefully figure out whether I should use that mechanism or use RTP 
over UDP. ICE provides that part of the solution.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 04 Feb 2005 17:20:30 +0100

Hi,

See inline

> stream, and the second candidate lists a UDP alternative.

Yes, I assumed already before that something like this what was you 
talked about. However the problem is that it is not obvious that you can 
use the same RTP profiles over different transports. For example there 
might not be the same need for AVPF if you use TCP (In fact we don't 
have AVPF for TCP currently). So if I like to primarily use UDP/RTP/AVPF 
and if that fails TCP/RTP/AVP. That can't be expressed with you 
proposal. I would also like to point out that you need different 
parameters for the different cases.

We have in AVT been burned by how the RFC 2733 FEC session was done. For 
the moment it is impossible to use security or feedback with RFC 2733 
FEC because we can't specify the parameters for it due to the embedding 
of a session instance within the media block. It really creates a real 
problem as soon as you develop new things that can be used in 
conjunction. The whole signalling in SDP is defined around the fact that 
different streams have different "m=" lines. I know that SDP is a 
horrible mess, but it becomes even a bigger one if we don't follow its 
structure and just put things in there without thought.

> dependent? I didnt think so....

I think security is a good example. Currently we don't know what 
security to do over TCP. We haven't defined TCP/RTP/SAVP and 
TCP/TLS/RTP/AVP is proposed. So there is definitely risk that there will 
be different parameters depending on transport. I also hinted on 
feedback related difference. From a RTP perspective TCP isn't quite the 
same as UDP and needs to be handled differently in an implementation. 
For example the handling of the congestion control is a bit different.

> needed over TCP, so it may be a moot point.

Okay.

> over UDP. ICE provides that part of the solution.

I do not fully agree, about if it is circumvention or not. I do 
understand the interest in developing a solution for this. The 
proprietary solutions do handle these cases, and the standard will be 
die if it doesn't work in the same scenarios. What I don't want is a 
short term hack that will cause us twice the amount of problems down the 
road as the original problem.

Cheers

Magnus Westerlund