Subject: [MMUSIC] Comments on draft-ietf-mmusic-ice-sip-sdp-16 - The Offer/Answer Edition

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Mar 2018 14:51:20 +0000

Hi,

Some comments on the Offer/Answer procedures (Section 4).

Q0:

The last sentence in section 4.1.1 makes it sound like that only the
default candidates are encoded into the SDP.

Q1:

In section 4.1.1.1 (and possible elsewhere), you don¹t need to describe
what a default candidate it, or how you choose them. Just reference
5245bis. Also, as section 4.1.1.2 is about SDP encoding, this section
should not talk about proto values etc.

Also, whether a stream is in use or not is not specific to default
candidates, so it should be described elsewhere.

Q2:

Section 4.1.2 references section 5.4 of 5245bis for verifying ICE support.
That reference needs to be updated. In addition, if there are SIP and/or
SDP specific information elements used to determine the ICE support, you
need to describe what they are. 5245bis does not describe that.

Q3:

In section 4.1.2.1, I think we shall assume that any implementation of
this spec is 5245bis compliant.

Q4:

I think there should be some generic text saying that, when you send a
subsequent  offer/answer, you include the previously negotiated SDP
candidate attributes etc. You then describe when that does not apply
(e.g., when removing a stream, or when doing a re-start). Because, keep in
mind that the agent may send an subsequent offer/answer because of non-ICE
related reasons.

You DO seem to cover much of that in section 4.2.1.2 and 4.2.1.3, so my
suggestion is to move those sections before the use-case specific
sections. Same comment applies to sections 4.2.2.2 and 4.2.2.3.

Q5:

In section 4.2.3, I don¹t think the text about SBCs belong there. An SBC
removing candidates is not specific to subsequent answers - it can happen
to any offer or answer.

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 18 Mar 2018 17:25:49 +0000

Hello Christer

 Many thanks for the review. Please see my comments inline.

Thanks
Suhas

> default candidates are encoded into the SDP.

[Suhas] How about the following rewording

The offerer shall follow the procedures defined in section 5 of [ICE-BIS]
<https://tools.ietf.org/id/draft-ietf-mmusic-ice-sip-sdp-16.html#ICE-BIS> to
gather, prioritize and eliminate the redundant candidates. It then chooses
the default candidates from the final set of candidates and encodes all of
them in the SDP to be sent to its peer, the answerer.

> should not talk about proto values etc.

[Suhas] The second and 3rd para of section 4.1.1.1 came due to earlier
reviews
from Adam and Roman. Roman specifically wanted this section (para 2) to
align with
SCTP-SDP text when using the transport protocol and we added it for clarity.
 Hence, i am inclined towards not updating it.
However, open to inputs.

> candidates, so it should be described elsewhere.

[Suhas] not sure, i understand. Do you have a suggestion on how can we
achieve this ?

> need to describe what they are. 5245bis does not describe that.

[Suhas] Will update the section reference. Section 8 deals with SIP specific
consideration via the options tag. Doss that satisfy your comment ?

> this spec is 5245bis compliant.

[Suhas] not sure what's the ask here is ?

> removing candidates is not specific to subsequent answers - it can happen

[Suhas] I would let Marc clarify this a bit. Since the 2nd para talks
specifically
about mid-call and thus applicable to subsequent O/As

>
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>