Subject: Re: [MMUSIC] ICE issue: RTP specificity of the candidate attribute

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jan 2005 03:16:36 -0500

Sorry for the huge delay in responding here.

I don't think the approach you are proposing works. Each of the 
candidates can have a different q-value and different usernames and 
ports. Your BNF "factors those out" so that they are common for all 
candidates. Since they differ for each candidate, you'd need to repeat 
them. Thus, nothing would be shared (I think id should be different 
too), and then I don't see what is gained by putting them on the same line.

Using separate lines also makes it easier to extend the candidate line 
in the future. We've discussed allowing to specify tcp as an alternate 
for a udp media stream. Though we decided not to do that now, I think we 
will need to do something like that eventually and I want to leave the 
door open. I think the extensibility is easier if each candidate is its 
own line.

Thanks,
Jonathan R.

Magnus Westerlund wrote:

> Hi Jonathan,
> 
> I think this is the right direction. I do however wonder if it is the 
> right solution. Your current solution indicates multiple lines that are 
> part of the same address candidate. I think using a ABNF that kept each 
> candidate on a single line might be better. As all address for the same 
> candidate is needed, due to the protocols need, like both RTP and RTCP 
> addresses for RTP. The question here is if one should use explicit 
> binding as you propose, or rely on the order defined by the protocol 
> when specifying address. However it might be easier to do the binding 
> explicitly. My proposal for ABNF for a single line solution would be:
> 
> candidate-attribute   = "candidate" ":" id SP qvalue SP
>                          user-frag SP password 1*(SP address-spec)
> address-spec          =  (unicast-address "/" port ";"
>                          candidate-addr "/" candidate-port )
> 
> 
> 
> Jonathan Rosenberg wrote:
> 
>> Folks,
>>
>> I got some private comments on the ICE-03 spec, and in the process of
>> going through them, a few of them were significant enough that they
>> require group discussion.
>>
>> The issue that was raised here is that the SDP candidate attribute is
>> currently very RTP specific. This would make it necessary to define new
>> SDP attributes for other transport protocols that wish to use the ICE
>> framework. It also means that its hard to handle cases like RFC 2733,
>> where there is an IP/port conveyed in an fmtp line.
>>
> 
> I would like to point out that I at least are trying to deprecate that 
> type of usage, due to its unsuitability in SDP. As we have deployed a 
> number of SDP extension, that applies to the media session, specifying 
> another session inside FMTP lines looses all these extensions. Thus my 
> personal opinion is that it is easier to remove the few special cases 
> like RFC 2733 than to get the other mechanisms to work for the special 
> cases. That is why I have argued in the ULP context to change the 
> binding between original data and FEC data.
> 
> 
> 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]
> 

-- 
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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 06 Jan 2005 10:45:24 +0100

Hi Jonathan,

Apparently some confusion here. I am not talking about putting multiple 
candidates on the same line. I am only talking about candidates that in 
fact consist of multiple addresses. My prime example is the RTP and RTCP 
case, where each candidate address has one RTP component and another 
RTCP component. The reason I think this grouping of multiple address 
that a single candidate needs, is that it is not desired to have 
different address components over different candidates. At least for RTP 
and RTCP sending RTCP the long way by a relay and RTP directly will 
provide bad RTCP statistics. Some are using RTCP to at least avoid 
catastrophic congestion, some are even going further. If RTP and RTCP 
already on application level get routed by different paths, this is bad.

I hope you understand my motivation to put multiple addresses in a 
candidate and forcing a grouping of the different protocol components.

So lets start in the more fundamental end of the question: Should one 
group multiple address per candidate and only use a candidate if all 
addresses for that candidate works?

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jan 2005 11:37:37 -0500

Magnus Westerlund wrote:

> fact consist of multiple addresses.

Ah, OK, that wasn't clear to me.

  My prime example is the RTP and RTCP
> different address components over different candidates.

I'm not sure I agree with that. More below.

> At least for RTP 

To be clear, I think the only reason its really problematic is that RTCP 
is used to take RTT measurements for RTP. Beyond that, reporting of loss 
  statistics and sent/received RTP packets could be done on a totally 
separate path.

So, though it is better for RTP, it may not be better for other usages 
of multiple addresses. Its less clear to me that it would matter for 
FEC, for example.

> candidate and forcing a grouping of the different protocol components.

I understand the motivation, yes. Forcing the grouping does mean that 
its possible that a call fails because you couldn't get successful 
checks for all components on the same "bundle" of addresses. In other 
words, if you are advertising STUN addresses for RTP and RTCP, and also 
local interfaces, it could be that the ICE checks succeed for STUN RTP 
and local RTCP. The grouping you propose would cause the call to fail. 
Admittedly, I am hard pressed to think about when this would happen, but 
you never know.

Indeed, if you think it will seldom happen, you can accomplish a loose 
form of the grouping by making sure that the priorities for the 
candidates for RTP and RTCP are in the same relative order. In other 
words, using the same example as above, if I assign priority 1.0 to the 
local interface RTP, 0.8 to the local interface RTCP, 0.5 to the STUn 
RTP and 0.4 to the STUN RTCP, the RTP and RTCP candidates have the same 
relative priorities. If its likely that the local interface ones are 
likely to fail or succeed for BOTH RTCP and RTP, then you end up 
selecting the same transport for both.

Furthermore, if it turns out that, for some oddball reason, it succeeds 
for one and not the other, the call would still go through.

As such, I am inclined to instead suggest that prioritization be used to 
realize the grouping, and then we are free to put each on a separate 
line. I prefer separate lines since I think it makes future 
extensibility easier.

> addresses for that candidate works?

Per above, I would say SHOULD is the right thing here; you want them to 
use the same in some cases (like RTP/RTCP), but its preferable to have 
the call proceed if you can't, than for the call to fail.

-Jonathan R.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Jan 2005 11:14:00 +0100

Hi Jonathan,

I agree that the main problem with sending RTP and RTCP is the RTT 
measurement. It really should go the same path, however I think it is 
okay with the more simplistic grouping based on priorities. If it 
actually shows that the grouping needs to be strict, an attribute using 
the candidate IDs could be used to accomplish this. So we have a way 
forward if it really would be required. However it doesn't seem that 
likely that one candidate would work and not the other.

So the proposed resolution is to write a recommendation into the ICE 
spec for RTP and RTCP to use the same priorities, so that it most likely 
that the same candidate will be used for both. Including the motivation 
that the RTT measurement would otherwise not be correct, if different 
paths where selected.

Is there agreement on this?

Cheers

Magnus Westerlund

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Jan 2005 18:06:19 -0500

Hearing no further comments, I'll go with this approach.

-Jonathan R.