Subject: [MMUSIC] sip multiparty conference and ICE

From: Olivier Crête <[email-masked]>
Date: Fri, 16 May 2008 18:12:34 -0400

Hello,

I'm implementing a conferencing-oriented rtp streaming framework[1]. Our
framework makes it possible to have n-to-n conferences without a mixing
server with multicast ou multi-unicast.

I could not find a way to use ICE in a multi-unicast scenario with SIP.
My understand is that it would require sending different candidates to
the different peers. And that would mean sending different SDPs to the
different peers and that does not seem to be supported by SIP. Is it
just not supported? Or did I miss something?

[1] http://farsight.freedesktop.org/

-- 
Olivier Crête
[email-masked]
Collabora Ltd
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 May 2008 23:54:24 -0400

Multi-unicast can be done with SIP/SDP; it requires the focus to do 
third-party call control to add an m-line to the SDP to each existing 
participant when a new one joins. It can therefore work with ICE, once 
you've hacked through the offer/answer procedures.

-Jonathan R.

Olivier Crête wrote:
> ------------------------------------------------------------------------
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Olivier Crête <[email-masked]>
Date: Thu, 22 May 2008 19:52:28 -0400

Does that mean that on client machine, there will be one RTP session for
each remote end instead of having everyone in the same session? Meaning
that the codecs may not be the same across the conference?

---

From: Colin Perkins <[email-masked]>
Date: Fri, 23 May 2008 10:46:48 +0100

On 23 May 2008, at 00:52, Olivier Crête wrote:
> Does that mean that on client machine, there will be one RTP  
> session for each remote end instead of having everyone in the same  
> session? Meaning that the codecs may not be the same across the  
> conference?

Whether there is one RTP session or many is orthogonal to whether the  
codec may vary across the different participants in a conference.

-- 
Colin Perkins
http://csperkins.org/

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 May 2008 22:46:46 -0400

Yes. One m-line per remote-end and thus one RTP session per remote-end.

You can find some discussion of this and even a call flow in:
http://www.watersprings.org/pub/id/draft-ietf-sipping-conferencing-models-01.txt

which eventually evolved into:
http://www.watersprings.org/pub/rfc/rfc4353.txt

but without this more experimental material.

-Jonathan R.

---

From: "Guylain Lavoie" <[email-masked]>
Date: Mon, 26 May 2008 01:27:27 -0400

Hello everyone,

I am sorry to be this late in the process but I was really busy on the
implementation of draft-ietf-mmusic-ice-19.
I have some questions and observations on the document. By the way,
great job! The draft is way better than just a few versions ago.

Best Regards,
Guylain

1.	In section 4.1.1.2, it is written that using a single STUN/TURN
server improves the performance of ICE. How does it improve the
performance? On what basis? Obviously the gathering will be faster, but
I suspect that something else what meant.

2.	In section 5.7.1, it is written that a local candidate is paired
with a remote candidate if the two candidates have the same component ID
and have the same IP address version. The protocol should also be taken
into account.

3.	In section 5.7.1, it is written that number of components is
equal to the minimum across both agents of the maximum component. The
code does not tell what to do if there is no component in common. Since
component ID that are not in common does not create failure, I assume
that the media will be automatically considered as succeeded if no
component ID are in common. Am I right?

4.	In section 5.7.3, it is written that for each pair where the
local candidate is server reflexive, the server reflexive candidate MUST
be replaced by its base. That same should probably be performed for peer
reflexive too. I bring this because in section 7.1.2.2.1, it is written
that it is possible to pair a local peer reflexive candidate with the
remote candidate once the user has sent a new offer. So, I guess that
the pruning should also affect local peer reflexive candidate pairs.

5.	In section 5.7.3, replace "adn" by "and".

6.	In section 6, nothing is said on how to react if the peer does
not support ICE, like it is told in section 5.1.

7.	In section 7.1.2.1, it is written that the candidate pair that
generated the 487 into the triggering check queue. I am wondering why
the role conflict must generate an error 487. Instead of returning an
error, the server side could just return a connectivity check response
with an additional attribute named something like "ROLE-CONFLICT". That
way, the client side would know that there is a role conflict and could
fix it and at the same time it could discover local peer reflexive would
having to perform another connectivity check . Since the client was able
to receive the 487, this means that there is connectivity. Please, can
someone explain why the server side absolutely needed to return an error
instead of just return a normal response with a flag telling "by the
way, there is a role conflict"?

8.	In section 7.1.2.1, there is a rule to make sure that the
response to a connectivity check is received from the same address to
where we sent the connectivity check in the first place. Why must we
enforce this symmetry? What good does it bring us? Would it be because
some codecs assume that the same jitter buffer statistics applies to
both sides of a media?

9.	In section 7.1.2.2.2, it is written the valid pair may be equal
to a different pair in the check list. How can this be?

10.	In section 7.1.2.2.3, the term "any check list" is used a few
times. Should it not be "the check list"? Same for "a check list" that
should maybe be "the check list". Please explain.

11.	In section 7.2.1.1, it is written that if the agent's
tie-breaker is larger than or EQUAL to the contents of the
ICE-CONTROLLING attribute, the agent generates a 487 but retain its
role. Ok fine, but why equal? The specification seems to become brittle
when this happens since both sides will send 487. Would it not be
possible for both sides to keep alternate their role between
ICE-CONTROLLING and ICE-CONTROLLED in an almost endless loop because
both are sending checks paced at 20ms. Ok, you could say that this
condition will be rare but it could probably happen for identical
machines that recently rebooted. Their random generator could for a
while be mostly synchronized.  Maybe I missed something. Please explain.

12.	In section 7.2.1.3, it is written that the agent does not pair a
new remote candidate with any local candidate. However, in the next
section, it says that the agent constructs a pair that includes this new
remote candidate. In section 7.1.2.2.1, there was a note saying that the
pairing will be performed in the next section. Could we add a similar
note there so that the text is less ambiguous?

13.	In section 7.2.1.4, it is written that we must wait the duration
of the transaction timeout for a response. I am maybe slow, but I did
not read this correctly until I read it ten times. Please change the
text to explain that we must wait the duration of the transaction
timeout for a response, and that we must also process the response if
one is received as if it was a response for the new connectivity check,
since it is equivalent. A little clarification would be appreciated.

14.	In section 8.1.1.1, it is written that the new connectivity
check with the USE-CANDIDATE attribute to force the nomination should
succeed. What should we do if it does not work? Should we try the next
valid pair in priority? What if there is none?

15.	Nowhere is it written what to do if a server reflexive
keep-alive returns a different mapped address.

16.	Connectivity check keep-alives are performed with indications.
It is written nowhere what to do if we do not receive a keep-alive or
media packets after TR timeout. I would expect this in cases where our
binding changed for some reason like when the NAT rebooted. Should we
perform a media restart? Should we even bother with that? I think so
because we really need a way to detect if something has gone wrong
without the user intervention.

17.	In section 9.1.3.2, the first paragraph does not make much sense
to me. Should it be the local candidate instead of the remote candidate?

18.	In section 9.3.1.4, It think that "lowest component ID" should
be used instead of "component ID of 1". Left over from a previous draft?

19.	In section 15.1, there seems to be a problem with the grammar.
extension-att-name and extension-att-value are byte-string and delimited
with SP. However, byte-string includes SP. The grammar seems to be
ambiguous.

Guylain Lavoie
Technical Product Manager
M5T, a Division of Media5 Corporation
Web: http://www.m5t.com
Email: [email-masked]
Tel: +1-819-829-1008, ext: 662
Fax: +1-819-829-1342