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

[Flemming Andreasen <[e-mail]>]

Thx Roman

-- Flemming

On 2/3/17 12:08 PM, Roman Shpount wrote:
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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
>     <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:[e-mail]]
>>     *Sent:* 13 January 2017 21:09
>>     *To:* Christer Holmberg <[e-mail]>
>>     <mailto:[e-mail]>
>>     *Cc:* [e-mail] <mailto:[e-mail]>
>>     *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
>>     <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         The subject shall be ICE-SDP: Verify decision made…
>>
>>         *From: *mmusic <[e-mail]
>>         <mailto:[e-mail]>> on behalf of Christer
>>         Holmberg <[e-mail]
>>         <mailto:[e-mail]>>
>>         *Date: *Friday 13 January 2017 at 13:32
>>         *To: *"[e-mail] <mailto:[e-mail]>"
>>         <[e-mail] <mailto:[e-mail]>>
>>         *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
>>         <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
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/mmusic
>>         <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
>>
>>     _______________________________________________
>>     mmusic mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>