Subject: [MMUSIC] RE: RTP/RTCP transport address identification with in a candidate

From: Vavilapalli Srikanth-A19563 <[email-masked]>
Date: Wed, 14 Sep 2005 19:39:32 +0530

Magnus

Thanks a lot for pointing to your previous discussion on this topic. 

We also have come to the decision to make a one-to-one mapping between the
transport addresses belonging to the same candidate in the order they are
published in offer or answer. That is the only way we have to reduce the
number of connectivity checks with the existing ICE spec.

However what you are proposing would avoid the restrictions on the SDP to
list down RTP transport address always first and then RTCP. May be Jonathan
is concerning about the increase in number of fields in the "a=candidate"
attribute. 

Thanks & Regards
Srikanth Vavilapalli

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2005 6:28 PM
To: Vavilapalli Srikanth-A19563
Cc: [email-masked]; [email-masked]
Subject: Re: RTP/RTCP transport address identification with in a candidate

Hi,

Me an Jonathan had a discussion on this on the MMUSIC mailing list 
starting the 1st of August with the subject:
"The indication of candidates belonging to a transport	adress"

My summary of the discussion would be that the candidate number do 
provide a way of determing that several tids belongs together and should 
be handled in union. However it doesn't allow you to explicitly indicate 
that a particial candidate:tid pair shall be used for a specific usage.

If one uses an rule to create an implicit notion that only candidates of 
a particular order in the sequence for each candidate number shall be 
checked then it works, as long as all candidate series has the same need 
for transports.

I would still argue that including an explicit identifier for the 
transport within a candidate would ensure that connectivity checks are 
only performed for meaningful pairings. Thus saving connectivity checks. 
To my understanding such an identifier can even be numeric as its only 
purpose is to ensure that the correct pairing are checked. This is due 
to that the actual protocol TCP or UDP etc are indicated in an other 
place and the answerer can offer the same number of transport usage per 
candidate without knowing initially what they are intended for. Later 
when they are promoted to usage, they will be explictly indicated and 
the answering peer can match the corresponing address with his matching 
one.

Cheers

Magnus

Vavilapalli Srikanth-A19563 wrote:
> Hi All
> 
> How to distinguish the RTP transport address and RTCP transport address in
a
> non active candidate published (in offer or answer) by an ICE compliant
> agent? This is needed to pair up "one-to-one" between transport addresses
of
> a native and remote candidate.
> 
> For an active candidate we can identify them with m/c line and "a=rtcp"
> attribute. But for a non-active candidate the "a=candidate" grammar
doesn't
> indicate if it is for RTP or for RTCP?
> 
> The draft draft-ietf-mmusic-ice-05 says:
> -----------------------------------------
> 
> 1. Section 7.1: Each candidate is composed of a series of transport
> addresses of the same type.  In the case of RTP, the candidate is composed
> of either one or two transport addresses.  Normally there are two - one
for
> RTP, and one for RTCP.
> 
> 2. Section 7.4: Each candidate has a number of transport addresses.  In
the
> case of RTP, there are either one or two.  Within the pairing, the
transport
> addresses of each candidate are linked together one-to-one to form a
> transport address pair.  In the case of RTP, the result will either be one
> or two transport address pairs - one for RTP, and possibly another for
RTCP.
> 
> Can any one clarify this?
> 
> Regards
> Srikanth Vavilapalli
> 
> 

-- 

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: Wed, 14 Sep 2005 22:19:38 -0400

inline.

> number of connectivity checks with the existing ICE spec.

Right. Magnus and I also agreed on a 1-1 mapping based on numeric order 
of the tids. Doing it based on numerical order is better imho, as it 
makes it less depenent on implicit position in the SDP, which has proven 
to be a major weakness in SDP for m-lines.

> is concerning about the increase in number of fields in the "a=candidate"

Well, having something that explicitly said that "this is rtp" and "this 
is rtcp" is RTP specific, and one of the things -05 achieved was making 
candidates not RTP specific. I'd rather just declare in the spec that 
RTP comes first, and RTCP second (where first and second are defined 
based on numerical tid ordering). The only drawback is that you couldn't 
offer a candidate with just RTCP.

I don't feel very strongly on this, so if others think somethig explicit 
is really needed, I can add something. Just remember new values would 
need to be specified for each non-RTP transport. Then again, non-RTP 
transports would need to spceify how to map the ordering to 
sub-components of the stream anyway, so maybe its not saving anything...

-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: Thu, 15 Sep 2005 15:47:32 +0200

> offer a candidate with just RTCP.

The question is what gain you really get from explicit indication of 
what each transport type candidate is for. I get the impression that it 
doesn't really matter unless the answerer would do different candidate 
generation based on knowing what the candidate will be used for.

However it might be that we are on different pages. To me the 
a=candidate attribute would now look like:

a=candidate: candidate-id SP transport-group SP tid SP 
transport-protocol SP qvalue SP address SP port

Where transport-group would be a numerical identifier for grouping of 
different candidate-ids that shall be tested against each other.

An offer could contain the following:

A:a=candidate:1 1 1234567 UDP 0.5 10.10.10.34 22456
B:a=candidate:1 2 2345678 UDP 0.5 10.10.10.34 22457
C:a=candidate:2 1 8765432 UDP 0.3 202.45.12.32 10654
D:a=candidate:2 1 7654321 UDP 0.3 202.45.12.32 10655

Answer:

E:a=candidate:1 1 876543 UDP 1.0 197.32.12.76 16541
F:a=candidate:1 2 765432 UDP 1.0 197.32.12.76 32896
G:a=candidate:2 1 123456 UDP 0.5 10.10.12.43 12344
H:a=candidate:2 2 123456 UDP 0.5 10.10.12.43 12345

Which would then result in that following combinations will be checked 
for transport group 1.

A:E
A:G
C:E
C:G

And for transport group 2

B:F
B:H
D:F
D:H

With this mechanism you could easily promote a candidate and a specific 
transport group to either RTP or RTCP usage. Thus if first when we send 
the reinvite is when we determine what a specific candidate is going to 
be used. For example we could provide the following line in a offer:

m=audio 22457 RTP/AVP 97
c=10.10.10.10.34
a=rtcp:22456

Which was probably not what people expected by the transport-group 
numbering, but I don't see a technical reason to prevent this. Does some 
one do that?

> sub-components of the stream anyway, so maybe its not saving anything...

I also don't have strong opinions on this. However a TID registry would 
need to have reasonable (no stronger than Specification Required) policy 
so that ICE can be used with other protocol combinations.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 16 Sep 2005 11:27:31 -0700

> > However what you are proposing would avoid the restrictions on the
> > SDP to list down RTP transport address always first and then RTCP.
> > May be Jonathan is concerning about the increase in number of
> > fields in the "a=candidate" attribute.
>
> Well, having something that explicitly said that "this is rtp" and
> "this is rtcp" is RTP specific, and one of the things -05 achieved
> was making candidates not RTP specific.  I'd rather just declare in
> the spec that RTP comes first, and RTCP second (where first and
> second are defined based on numerical tid ordering).  The only
> drawback is that you couldn't offer a candidate with just RTCP.

0.0.0.0 might be useful as the RTP candidate in that case.

> sub-components of the stream anyway, so maybe its not saving 

I'm tempted to say we want this:

  a=candidate:1 123 UDP 1.0 1.2.3.4 32767 rtcp=32768

Otherwise you're nearly duplicating an a=candidate line (only the port would
be different).

However, I know that in -05 the username/password is missing and you're
adding that back in.  If you put both RTP and RTCP ports on the same
a=candidate line, you'll have to use the same username/password for them.  I
don't think that's a problem, but wanted to point it out.  I believe using
different username/passwords for the RTCP might well be useful, but I can't
think of a scenario off the top of my head.

Whichever way you go, I wonder if ICE should consider an a=candidate line
"good" (usable) if its associated RTCP candidate fails the connectivity
checks?  I believe you want to consider it usable if RTP passed but RTCP
failed.

-d