Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

I am fine with this direction, especially since we can make sure that must
implement transport is specified for all protocols that support ICE.

Please keep in mind that ALT #2 will require removal of ICE mismatch or
specifying a fake ICE candidate which matches the transport from m= line. I
think ICE mismatch is only removed for JSEP, not ICE-SDP in general.

Regards,

_____________
Roman Shpount

On Fri, Feb 3, 2017 at 8:47 AM, Flemming Andreasen <fandreas@cisco.com>
wrote:

> We issued a consensus call in the IETF 97 meeting on this which indicated
> a strong consensus for option 2 as well (see https://www.ietf.org/
> proceedings/97/minutes/minutes-97-mmusic-00.html). In lieu of that and
> since we have only seen one person arguing against option 2 here, we
> suggest moving forward with option 2 as well. If anybody objects to this,
> please let us know.
>
> Thanks
>
>     Flemming & Bo (as MMUSIC chairs)
>
>
>
>
>
> On 2/2/17 3:23 PM, Christer Holmberg wrote:
>
> Hi,
>
>
>
> Based on the feedback, my suggestion would be to move forward with ALT #2.
>
>
>
> Now, as I said earlier, that still doesn’t prevent protocols from
> specifying an MIT transport, which is used as default candidate (read: ALT
> #1).
>
>
>
> Regarding documentation, I guess it would at least have impact on ICE-SDP.
> The question is whether something is needed for 3264?
>
>
>
> Chairs?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Roman Shpount [mailto:roman@telurix.com <roman@telurix.com>]
> *Sent:* 13 January 2017 21:09
> *To:* Christer Holmberg <christer.holmberg@ericsson.com>
> <christer.holmberg@ericsson.com>
> *Cc:* mmusic@ietf.org
> *Subject:* Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding
> non-supported transport in m- line of answer
>
>
>
> As I have mentioned before, I think ALT#1 is a better option: If we
> propose mandatory to implement UDP based protocol for each transport
> family, only use the mandatory to implement protocol for the default
> candidate, and the transport mismatch problem will never occur.
>
>
>
> As a bit of background, this issue appeared because of TCP/BFCP, which was
> assumed to be the default protocol for BFCP with ICE. Since then, I think
> we have decided that TCP/BFCP is not going to be used with ICE. For all the
> other protocols that I know (UDP/DTLS/SCTP, UDP/TLS/RTP/SAVPF,
> UDP/DTLS/BFCP, RTP/AVP, etc) there is a clear preference that UDP based
> protocol should be used for backwards compatibility. I also do not see a
> use case which will require that only tcp based candidates would be
> included in the offer or the answer. Because of this, I think mandatory to
> implement transport is a better approach.
>
>
>
> This also have additional benefits of:
>
>
>
> 1. Providing m= and c= line information which will not cause the ICE
> mismatch with older implementations
>
> 2. Not supplying any on the path signaling devices with bogus address
> information required in ALT#2 answer
>
> 3. Improves general chances of negotiation succeeding with end points not
> supporting ICE by picking the protocol more likely to succeed (chance of
> TCP/RTP/AVP succeeding, for instance, are much lower then RTP/AVP).
>
>
>
> Regards,
>
>
> _____________
> Roman Shpount
>
>
>
> On Fri, Jan 13, 2017 at 7:00 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> The subject shall be ICE-SDP: Verify decision made…
>
>
>
> *From: *mmusic <mmusic-bounces@ietf.org> on behalf of Christer Holmberg <
> christer.holmberg@ericsson.com>
> *Date: *Friday 13 January 2017 at 13:32
> *To: *"mmusic@ietf.org" <mmusic@ietf.org>
> *Subject: *[MMUSIC] SIP-SDP: Verify decision made in Seoul regarding
> non-supported transport in m- line of answer
>
>
>
> Hi,
>
>
>
> In Seoul we discussed a number of issues related to ICE-SDP. We made some
> decisions, and I got action points to verify one of those on the list.
>
>
>
> The associated slides can be found here:
>
>
>
> https://www.ietf.org/proceedings/97/slides/slides-
> 97-mmusic-ice-sip-sdp-00.pdf
>
>
>
>
>
> The issue (slides 4-6) was when an answerer receives an offer with a m-
> line transport that it doesn’t support. The current O/A rules say that the
> transport in the answer must match the transport in the offer.
>
>
>
> However, if ICE is used, there may be transports (offered using ICE
> candidates) that the answerer DOES support.
>
>
>
> Based on the discussions, there was strong consensus to go for Alt#2,
> which was allowing a transport in the m- line of the answer even if the
> answerer doesn’t support it, as ICE candidates will be used to determine
> the transport.
>
>
>
> Does anyone object to Alt#2?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
> _______________________________________________
> mmusic mailing listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic
>
>
>