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

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]
> *Sent:* 13 January 2017 21:09
> *To:* Christer Holmberg <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 
> <mailto:christer.holmberg@ericsson.com>> wrote:
>
>     The subject shall be ICE-SDP: Verify decision made…
>
>     *From: *mmusic <mmusic-bounces@ietf.org
>     <mailto:mmusic-bounces@ietf.org>> on behalf of Christer Holmberg
>     <christer.holmberg@ericsson.com
>     <mailto:christer.holmberg@ericsson.com>>
>     *Date: *Friday 13 January 2017 at 13:32
>     *To: *"mmusic@ietf.org <mailto:mmusic@ietf.org>" <mmusic@ietf.org
>     <mailto: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 <mailto:mmusic@ietf.org>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic