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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Dec 2004 23:12:35 -0500

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.

The suggestion is to change the syntax of the candidate attribute so 
that its not RTP specific. It would do this by specifying a potential 
candidate for a particular IP/port that is indicated explicitly. Thus:

  candidate-attribute   = "candidate" ":" id SP qvalue SP
                            user-frag SP password SP
                            unicast-address SP port
                            candidate-addr SP candidate-port

So, for example:
  v=0
  o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
  s=SDP Seminar
  c=IN IP4 1.2.3.4
  a=recvonly
  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

In this example, it means that the RTP IP/port of 1.2.3.4:49170 has an 
alternate of 10.0.1.1:8700, and the RTCP IP/port of 1.2.3.4:49171 has an 
alternate of 10.0.1.1:8765.

The pros/cons of this proposal as I see them are:

Pros
   - makes ICE more RTP independent
   - works better with RFC 2733 and other protocols which might convey 
IP addresses in SDP in other places besides the c/m lines

Cons
   - increases SDP message size for the normal RTP case, since you 
always need to include to a=candidate lines for each media stream (one 
for RTP, one for RTCP)
   - yet another non-backwards compatible change in the grammar with the 
previous draft (not clear it matters)

I'm inclined to make the change. Comments?

-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

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

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 08 Dec 2004 11:02:01 -0500

Since ICE is not RTP-specific, we should make it general. Also, the 2733 
case shows that lack of generality may even be a problem for RTP 
streams. Comparing the -03 attribute definition with the proposal here, 
the overall size increase is not that great (nowhere near a doubling). 
While you could squeeze out a few bytes with some optimizations in the 
definition, I doubt it is worth it. In other words, I agree with the 
proposed change.

Btw, your example shows the same "id" value for the two candidates - is 
this intentional (implying some kind of grouping) ?

-- Flemming

Jonathan Rosenberg wrote:

> 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.
>
> alternate of 10.0.1.1:8700, and the RTCP IP/port of 1.2.3.4:49171 has 
> an alternate of 10.0.1.1:8765.
>
>
>   - yet another non-backwards compatible change in the grammar with 
> the previous draft (not clear it matters)
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 08 Dec 2004 17:51:09 +0100

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 )

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