Subject: [MMUSIC] ICE lite - comment on gathering candidates at answerer (section 5.3)

From: "Elwell, John" <[email-masked]>
Date: Fri, 06 Jul 2007 14:15:45 +0100

Jonathan,

"The process for gathering candidates at the answerer is identical to
   the process for the offerer as described in Section 4.1.1 for full
   implementations and Section 4.2 for lite implementations.  It is
   RECOMMENDED that this process begin immediately on receipt of the
   offer, prior to alerting the user.  Such gathering MAY begin when an
   agent starts."

I think considerations for lite implementations are slightly different
when the offerer is also lite. It would be advantageous for the answerer
to choose just a single candidate that is compatible with one of the
candidates in the offer. In this way it would be safe to override the
recommendation to delay alerting. Alerting can take place, with the
knowledge that when the user answers (or when early media is sent) media
can be sent to the matching candidate from the offer. If alerting takes
place but the answerer has submitted several candidates and not made a
selection, it is unable to send early media or media when the user
answers, unless a further offer has been received in an UPDATE request.
Therefore clipping is likely to occur. If alerting does not commence at
this point, the answerer will need to wait for another offer in an
UPDATE request on the early dialog. This in turns means that
100rel/PRACK has to be used, which is something that we took a decision
to avoid way back. For full ICE (including full-lite interworking)
successful connectivity checks are the trigger to start alerting, but
these do not occur with lite-lite working.

So I would suggest the addition of the following words:
"When both the offerer and the answerer are lite implementations, the
answerer MAY gather just a single candidate that is compatible with one
of the candidates in the offer and alert the user immediately. In this
case it can assume that the offerer will select the compatible candidate
and that media can be sent to that candidate without waiting for a
further offer."

In addition, I think the answerer would need to place the sole candidate
pair into the Valid List when it sends this first SDP answer, in order
to allow media to flow before the second offer arrives. I defer to your
judgement as to which words need changing to reflect this.

John

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 07 Jul 2007 17:55:49 -0400

Elwell, John wrote:
> recommendation to delay alerting.

There is no delayed alerting in the case where both sides are lite. 
Immediately upon receipt of the offer, the answerer can begin to send 
media. Section 8.2.2 has a bug in that it is not clear that the 
procedures there apply to controlled agents also. There are no 
connectivity checks that get sent when both are lite, so ICE is 
basically immediately done.

That said, an implementation is within its rights to include fewer 
candidates in its answer that would have otherwise, based on the offer.

  Alerting can take place, with the
> answers, unless a further offer has been received in an UPDATE request.

See above.

> judgement as to which words need changing to reflect this.

Section 8.2.2 is meant to apply to both controlling and controlled, 
which says:

>  If there is more than one pair per component:
> 
>    o  The agent MUST select a pair based on local policy.  Since this
>       case only arises for IPv6, it is RECOMMENDED that an agent follow
>       the procedures of RFC 3484 [12] to select a single pair.
> 
>    o  The agent adds the selected pair for each component to the valid
>       list.  As described in Section 11.1, this will permit media to
>       begin flowing.  However, it is possible (and in fact likely) that
>       both agents have chosen different pairs.

so this is already there. It just needs to be clarified that its for both.

Now the twist is that it is possible that both agents choose different 
pairs. Thats OK; if both are lite, it should still work. They'll 
converge on a single pair when the re-INVITE comes. But there is no 
media clipping.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com