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

From: Vavilapalli Srikanth-A19563 <[email-masked]>
Date: Tue, 6 Sep 2005 19:54:18 +0530

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Sep 2005 14:57:39 +0200

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

-- 

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]