Subject: [MMUSIC] The indication of candidates belonging to a transport adress

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Aug 2005 20:12:38 +0200

Hi,

I think we should consider if not explicitly indicating which of the 
transport address (RTP or RTCP) a candidate belongs to actually is a 
important optimization as it can reduce the number of checks need from 
N*M to N/2*M/2.

The current way of simple specifying two candidates of the same priority 
level do work. However it does cause you to check RTCP against RTP 
candidates instead of only checking RTP against RTP candidates.

This is a significant gain reducing the number of possible checks with a 
factor of 4. Thus I think it can be worth specifying support in the 
candidate attribute. One proposal would be to have a 
Group:NR_WITHIN_GROUP construct to id the candidates belonging.

I would also like to point out that the current SDP attribute syntax is 
broken. It ends with a SP and does not specify group.

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: Mon, 01 Aug 2005 19:02:47 -0400

inline.

> candidates instead of only checking RTP against RTP candidates.

Hmm, perhaps the draft is not clear on this. It doesn't actually group 
candidates by saying that RTP and RTCP have the same priority. I 
initially wrote some text to do it this way, but quickly found it didnt 
work, and (I thought) removed it, for EXACTLY the reason you are 
pointing out. Rather, RTP and RTCP are grouped through the candidate-id 
attribute:

> candidate-attribute   = "candidate" ":" candidate-id SP tid SP
>                            transport SP
>                            qvalue SP   ;qvalue from RFC 3261
>                            addr SP
>                            port SP
>                              ;addr, port from RFC 2327
>    transport             = "UDP" / "TCP" / transport-extension
>    transport-extension   = token
>    candidate-id          = 1*DIGIT
>    id                    = non-ws-string
> 
> 
>    The candidate-id is used to group together the transport addresses
>    for a particular candidate. 

When you validate a pair of candidates, you "line up" each transport 
address in that candidate. Thus, for RTP, the offerer sends two 
transport addresses (A and B) and the answerer sends its two (C and D). 
The offerer would check connectivity from A to C and B to D, as would 
the answerer. Thus, there are no checks from RTP to RTCP and RTCP to RTP.

> Group:NR_WITHIN_GROUP construct to id the candidates belonging.

This is there - the candidate-id construct.

> broken. It ends with a SP and does not specify group.

Extra SP removed. The grouping is there though.

-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: Tue, 02 Aug 2005 09:18:13 +0200

Hi Jonathan,

Okay, so you are saying that in the case you had two transports that are 
going to be grouped and two different candidate addresses then you would 
  do the following:

Trn 1, Cand-ID 1, Address1
Trn 2, Cand-ID 1, Address2
Trn 1, Cand-ID 2, Address3
Trn 2, Cand-ID 2, Address4

Trn 1 = RTP, Trn 2 = RTCP and they are not signalled.

I can agree that this would work as long as you actually uses the order 
of the candidates within the SDP. I think using this implicitness is 
maybe not the best of things. What is the problem with using explicit 
indicators actually informing which transport in the order you are 
using? IF one starts deploying further SDP extensions having explicit 
indication could make your life much easier.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Aug 2005 20:01:56 -0400

inline.

> Trn 1 = RTP, Trn 2 = RTCP and they are not signalled.

No, it would be like this:

candidate-id: 1, tid: 1, UDP address: rtp-ip:port
candidate-id: 1, tid: 2, UDP address: rtcp-ip:port
candidate-id: 2, tid: 3, TCP address: rtp-ip:port
candidate-id: 2, tid: 4, TCP address: rtcp-ip:port

in other words, the transport ID (tid) is unique. All transport 
addresses that are part of the same candidate (RTP and RTCP) share the 
same candidate-id value.

> indication could make your life much easier.

We actually have all the explicit identifiers we need. So, let me 
propose this. Within a candidate (all transport addresses with the same 
candidate-ID), you order the transport addresses by tid, and they are 
paired up based on their ordering. For RTP, there are two transport 
addresses per candidate, and the RTP one would be the lowest valued tid 
from each side, and the RTCP the next higher one.

Sound OK?

Thanks,
Jonathan R.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Aug 2005 17:32:10 +0200

Jonathan Rosenberg wrote:
> inline.
> 
> Magnus Westerlund wrote:
> 
>> Hi Jonathan,
>>
>> Okay, so you are saying that in the case you had two transports that 
>> are going to be grouped and two different candidate addresses then you 
>> would  do the following:
>>
>> I can agree that this would work as long as you actually uses the 
>> order of the candidates within the SDP. I think using this 
>> implicitness is maybe not the best of things. What is the problem with 
>> using explicit indicators actually informing which transport in the 
>> order you are using? IF one starts deploying further SDP extensions 
>> having explicit indication could make your life much easier.
> 
> 

Maybe, it will work as long as nobody will start messing around with 
having different number of transports for different candidates. Because 
then we get into hell of a problem. The only thing I can think of right 
away that would create this problem would be transports that have an 
extra layer of multiplexing in them. For example if an RTP/RTCP framing 
for TCP (like RTSP's) allow one to run several streams over one 
connection, when other candidates would require multiple transports. In 
these cases the explicit numbering and allowance in the signalling for 
multiple transport id per tid would be required.

Based on this I would still consider if not explicit indicators is an 
benefit.

Cheers

Magnus Westerlund

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Aug 2005 00:26:13 -0400

inline.

Magnus Westerlund wrote:

>>> are going to be grouped and two different candidate addresses then 
>>> you would  do the following:
>>>
>>> implicitness is maybe not the best of things. What is the problem 
>>> with using explicit indicators actually informing which transport in 
>>> the order you are using? IF one starts deploying further SDP 
>>> extensions having explicit indication could make your life much easier.
>>
>>
>>
>> propose this. Within a candidate (all transport addresses with the 
>> same candidate-ID), you order the transport addresses by tid, and they 
>> are paired up based on their ordering. For RTP, there are two 
>> transport addresses per candidate, and the RTP one would be the lowest 
>> valued tid from each side, and the RTCP the next higher one.
>>
>> Sound OK?
>>
> 
> then we get into hell of a problem.

I'm not sure. Remember, the purpose of the candiadtes is just to check 
connectivity between groups of addresses. To actually use them for 
carrying media you promote them to the m/c line, and its there that you 
need to signal whatever your encapsulation and usage is.

  The only thing I can think of right
> multiple transport id per tid would be required.

I don't see why. Lets consider this case. There is a single media 
stream, which is going to be RTP over TCP. It can either mux RTP and 
RTCP onto one connection, or two. The offerer includes a single 
candidate with two TCP addresses. The answerer responds with a single 
candidate with one TCP address. Thus, each side attempts only one 
connection, effectively ignoring the second TCP addressed sent by the 
offerer. A connection from the offerer to answerer succeeds. Now, its 
promoted to the m/c line in a reinvite, and the muxing of RTP and RTCP 
over it is signaled.

If both sides had offered two TCP addresses in the candidates, then 
connections would be attempted for each. If both succeeds, the offerer 
has a choice - it can promote one of them to the m/c line and use muxing 
over that connection, or promote both of them.

What am I missing?

-Jonathan R.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Aug 2005 10:57:31 +0200

> over that connection, or promote both of them.

I will try to explain what I see as the problem. The goal as I see it is 
to avoid testing combinations that can't be used, like A:RTP to B:RTCP. 
Thus we need to correctly indicate the combinations that we like to have 
tested.

Peer A and B, uses several different candidates and have two different 
transports per candidate.

A                                B
Cand  Trn  tid                   Cand Trn  Tid
1     1    A1                    1    1    B1
1     2    A2                    1    2    B2
2     3    A3                    2    3    B3
3     3    A4                    3    3    B4
4     1    A5                    4    1    B5
4     2    A6                    4    2    B6
5     4    A7                    5    4    B7
5     5    A8                    5    5    B8

Transport
1: RTP
2: RTCP
3: TCP: Both RTP and RTCP
4: TCP: RTP
5: TCP: RTCP

With the above list of possibilities we like to to perform the following 
checks:

A1 ->B1
A1 ->B5
A2 ->B2
A2 ->B6
A3 ->B3
A3 ->B4
A4 ->B3
A4 ->B4
A5 ->B1
A5 ->B5
A6 ->B2
A6 ->B6

So far quite simple: However if we only indicate that transport types 
3,4,5 are TCP, ICE would perform in addition to the above the following 
connectivity checks:
A3 ->B7
A3 ->B8
A4 ->B7
A4 ->B8
A7 ->B3
A7 ->B4
A7 ->B7
A7 ->B8
A8 ->B3
A8 ->B4
A8 ->B7
A8 ->B8

Why in reality it would only be possible to connect in addition to the 
top set the much more limited set of combinations:
A7 ->B7
A8 ->B8

Based on the above, I see problems arising if we don't explicitly 
indicate the complete transport type (UDP/RTP, TCP/RTP, 
TCP/RTPInterleaved), or if only specifying transport protocol (UDP or 
TCP, etc) we need explicit indication on what combinations that actually 
are possible using an generic identifier.

I hope this clarifies the issue as I see it. Even if certain of these 
combinations looks a little bit far fetched, I think explicitness would 
make me sleep more comfortable knowing that we can handle anything the 
future may throw at ICE in this regards.

Cheers

Magnus Westerlund