Subject: Re: [MMUSIC] Empty candidate lists in ice-sip-sdp offers and answers

From: Flemming Andreasen <[email-masked]>
Date: Sun, 12 May 2019 20:34:32 -0400

On 4/29/19 5:27 PM, Roman Shpount wrote:
> On Sat, Apr 27, 2019 at 2:02 PM Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     ...
>
>     >NOTE: Since it is possible that no candidates were provided in
>     the offer,  or that all candidates in the offer
>     >where skipped due to unsupported address type or FQDN name
>     resolution failure, ICE nomination process
>     >can start with no remote candidates. This,  however, does not
>     indicate an immediate ICE nomination failure.
>     >See <<draft-holmberg-ice-pac>> for more details.
>     >
>     >In the Receiving the Initial Answer section I have added the
>     following:
>     >
>     >NOTE: Since it is possible that no candidates were provided in
>     the answer, or that all candidates in the answer
>     >where skipped due to unsupported address type or FQDN name
>     resolution failure, ICE nomination process can
>     >start with no remote candidates. This,  however, does not
>     indicate an immediate ICE nomination failure.
>     >See <<draft-holmberg-ice-pac>> for more details.
>
>     I think the text is confusing, because it starts talking about the
>     ICE nomination process. There are other things that happen before,
>     including the creation of candidate pairs.
>
>     So, I think the text should say that the agent will not be able to
>     create candidate pairs, and it will not be able to start sending
>     connectivity checks. Instead it will wait for the peer agent to
>     start sending connectivity checks, that the agent will then
>     process as peer reflexive candidates.
>
> I will try to come up with some text that uses the same terminology as 
> RFC 8445.
Do you have the suggested text ?
>
>     >I wanted to get the group's opinion regarding:
>     >
>     >1. Allowing offers and answers with no candidates
>
>     I am ok with the principle. There seem to be use-cases for it, so...
>
Agreed.
>
>     >2. Adding a reference to draft-holmberg-ice-pac regarding how
>     such session descriptions or session descriptions where all
>     candidates were rejected are handled.
>
>     The reference in the text above is misleading, because to me it
>     sounds like PAC describes how to process offers/answers without
>     candidates. PAC is only about a timer.
>
>
> Maybe this draft should cover the situation when session description 
> processing did not generate any candidates. The fact that ICE has some 
> minimal run timer is not enough. We still need something that 
> explicitly states that it is acceptable to run ICE nomination process 
> without candidates since, as far as I know, nothing in RFC 8445 
> specifies if this is allowed or not.
I am not in favor of adding a normative dependency to ice-pac at this 
late stage. Why do we need that ?

Thanks

-- Flemming (with chair hat on)
>
> Regards,
> ___________________________________________
> Roman Shpount | CTO | Cell: +1(202) 262-8672
> 4905 Del Ray Ave, Suite 300 | Bethesda, MD 20814
> TurboBridge
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 16 May 2019 13:58:01 -0700

On Sun, May 12, 2019 at 8:40 PM Flemming Andreasen <[email-masked]>
wrote:

> On Sat, Apr 27, 2019 at 2:02 PM Christer Holmberg <
> [email-masked]> wrote:
>
>> ...
>>
>> >NOTE: Since it is possible that no candidates were provided in the
>> offer,  or that all candidates in the offer
>> >where skipped due to unsupported address type or FQDN name resolution
>> failure, ICE nomination process
>> >can start with no remote candidates. This,  however, does not indicate
>> an immediate ICE nomination failure.
>> >In the Receiving the Initial Answer section I have added the following:
>> >
>> >NOTE: Since it is possible that no candidates were provided in the
>> answer, or that all candidates in the answer
>> >where skipped due to unsupported address type or FQDN name resolution
>> failure, ICE nomination process can
>> >start with no remote candidates. This,  however, does not indicate an
>> immediate ICE nomination failure.
>> I think the text is confusing, because it starts talking about the ICE
>> nomination process. There are other things that happen before, including
>> the creation of candidate pairs.
>>
>> So, I think the text should say that the agent will not be able to create
>> candidate pairs, and it will not be able to start sending connectivity
>> checks. Instead it will wait for the peer agent to start sending
>> connectivity checks, that the agent will then process as peer reflexive
>> candidates.
>>
>
> I will try to come up with some text that uses the same terminology as RFC
> 8445.
>

[Suhas] Roman, do you happen to have the suggested text ?

> >2. Adding a reference to draft-holmberg-ice-pac regarding how such
>> session descriptions or session descriptions where all candidates were
>> rejected are handled.
>>
>> The reference in the text above is misleading, because to me it sounds
>> like PAC describes how to process offers/answers without candidates. PAC is
>> only about a timer.
>>
>>
> minimal run timer is not enough. We still need something that explicitly
> states that it is acceptable to run ICE nomination process without
> candidates since, as far as I know, nothing in RFC 8445 specifies if this
> is allowed or not.
>
> I am not in favor of adding a normative dependency to ice-pac at this late
> stage. Why do we need that ?
>
> Thanks
>
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>