Subject: [MMUSIC] ICE-15: handling check list that completes early

From: Benny Prijono <[email-masked]>
Date: Thu, 05 Apr 2007 23:23:50 +0100

All,

I came across this scenario which I couldn't find the answer in the 
draft. Apologies if this has been discussed before.

What should answerer do when it completes all the check lists before 
receiving any checks from offerer?

This happens on this scenario. The answerer starts the check as soon 
as it sends answer. The offerer receives this check before SDP, and 
it responds with successful response. The answerer receives the 
response, starts other checks, gets the successful response again, 
and so on until finally all check lists are exhausted. And all of 
these happens before offerer receives the SDP answer, or in other 
words, the offerer can't send checks yet.

But although the check lists have completed, the answerer still 
hasn't got a nominated pair yet, since it hasn't received Binding 
request with USE-CANDIDATE yet.

So what should the answerer do here? I think probably it should do 
something like this:

  - it should wait until it receives check with USE-CANDIDATE set
    (what if it never receives this?)

  - when a check with USE-CANDIDATE arrives, it needs to scan the
    valid list for matching pair and set the nominated flag to
    true, and do section 8.2 again.

Comments?

thanks,
  -benny

-- 
Benny Prijono
http://www.pjsip.org

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Apr 2007 09:30:20 -0400

I don't think this case is explicitly called out in the spec, but the 
logic certainly covers it. Once the checks in the check list are 
exhausted, the timer is terminated (section 5.8). This will also cause 
this check list to no longer be active (section 5.7 definition). Other 
than that, there is nothing more to do. THe state of the check list is 
NOT completed, since there have not been nominated pairs yet. So, once 
the request shows up with the USE-CANDIDATE attribute, section 7.2 is 
followed, and 8.2 continues to apply. 8.2 will cause the state to 
eventually move to completed, and then you are done.

So, I do not see that any clarifications are needed. What aspects of the 
  above processing rules do you think are unclear?

-Jonathan R.

Benny Prijono wrote:

> This happens on this scenario. The answerer starts the check as soon as 
> it sends answer. The offerer receives this check before SDP, and it 
> responds with successful response. The answerer receives the response, 
> starts other checks, gets the successful response again, and so on until 
> finally all check lists are exhausted. And all of these happens before 
> offerer receives the SDP answer, or in other words, the offerer can't 
> send checks yet.
> 
> But although the check lists have completed, the answerer still hasn't 
> got a nominated pair yet, since it hasn't received Binding request with 
> USE-CANDIDATE yet.
> 

-- 
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

---

From: Benny Prijono <[email-masked]>
Date: Mon, 09 Apr 2007 16:33:27 +0100

Jonathan Rosenberg wrote:
> THe state of the check list is NOT completed,
> since there have not been nominated pairs yet. So, once 
> eventually move to completed, and then you are done. >
>  

Hmm.. I think the confusion primarily came from the check list state 
definition, because page 35 says that the check list is said to be 
Completed when all checks have been completed, not when it's got a 
nominated pair (although the processing in 8.2 explains this correctly).

So when running 8.2, the processing will make ICE processing 
completes, but no nominated pair was found, hence my program 
concluded that ICE had failed.

Other than this, perhaps we can also clarify in 7.1.2.2.2.  Updating 
Pair States (item 2, first bullet), some sort of "if there is no 
Frozen or Waiting checks in the active checklist, then don't try to 
do anything clever, just wait".

thanks,
  -benny

>> as it sends answer. The offerer receives this check before SDP, and it 
>> starts other checks, gets the successful response again, and so on 
>> until finally all check lists are exhausted. And all of these happens 
>> before offerer receives the SDP answer, or in other words, the offerer 
>> can't send checks yet.
>>
>> got a nominated pair yet, since it hasn't received Binding request 
>> with USE-CANDIDATE yet.
>>

-- 
Benny Prijono
http://www.pjsip.org

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Apr 2007 12:52:56 -0400

inline.

Benny Prijono wrote:

>> since there have not been nominated pairs yet. So, once the request 
>> shows up with the USE-CANDIDATE attribute, section 7.2 is followed, 
>> and 8.2 continues to apply. 8.2 will cause the state to eventually 
>> move to completed, and then you are done. >
>>  
>> So, I do not see that any clarifications are needed. What aspects of 
>> the  above processing rules do you think are unclear?
> 
> 
> 

Yes, OK. Good point. I'll adjust the definition to match the logic. It 
now says:

<t hangText="Completed:"> In this state, ICE checks have produced
nominated pairs for each component of the media stream. Consequently,
ICE has succeeded and media can be sent.
</t>

> 
> So when running 8.2, the processing will make ICE processing completes, 
> but no nominated pair was found, hence my program concluded that ICE had 
> failed.
> 
> Pair States (item 2, first bullet), some sort of "if there is no Frozen 
> or Waiting checks in the active checklist, then don't try to do anything 
> clever, just wait".

Well, this section really deals with the frozen algorithm. I think with 
the above clarification in the definition of Completed we are fine.

-Jonathan R.

---

From: Benny Prijono <[email-masked]>
Date: Mon, 09 Apr 2007 19:17:46 +0100

> ICE has succeeded and media can be sent.

That's good.

It also clears up my other doubt, that is when a check list is 
Completed, how many nominated pairs are there in the check list. One 
(per check list), or one per component.

Of course it's the later, but some other parts of the document may 
sound to suggest the former:

8.1.1
    Consequently, there will be only a single nominated pair in the
    valid list, and when the state of the check list moves to
    completed, that exact pair is selected by ICE for sending and
    receiving media.

I think that should be clarified as:

    Consequently, there will be only a single nominated pair in the
    valid list *for each component*, and when the state of the check
    list moves to completed, that exact pair is selected by ICE for
    sending and receiving media *for that component*.

And similarly 8.1.2:

    With aggressive nomination, the controlling agent includes the
    USE-CANDIDATE attribute in every check it sends.  Once the first
    check for a component succeeds, it will be added to the valid
    list, have its nominated flag set, and then cause ICE processing
    to cease for this check list.

I think the last fragment should say:

    .. and when all components in the check list have a nominated
    pair, it will cause ICE processing to cease for this check list.

thanks,
  -benny

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Apr 2007 09:37:14 -0400

inline.

> (per check list), or one per component.

Per component. Note that these are on the valid list, not the check list.

> 
> Of course it's the later, but some other parts of the document may sound 
> to suggest the former:
> 
> 8.1.1

Yes, fixed.

>    pair, it will cause ICE processing to cease for this check list.

s/check list/valid list, but yes.

Thanks for catching these,
Jonathan R.