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

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Feb 2017 20:23:03 +0000

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:[email-masked]]
Sent: 13 January 2017 21:09
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
The subject shall be ICE-SDP: Verify decision made…

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday 13 January 2017 at 13:32
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 3 Feb 2017 08:47:51 -0500

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:
> 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:[email-masked]]
> *Sent:* 13 January 2017 21:09
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* [email-masked]
> *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.
>
> 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 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     *From: *mmusic <[email-masked]
>     <mailto:[email-masked]>> on behalf of Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>>
>     *Date: *Friday 13 January 2017 at 13:32
>     *To: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *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 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.
>
>     [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Fri, 3 Feb 2017 12:08:14 -0500

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 <[email-masked]>
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
>
> 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:[email-masked] <[email-masked]>]
> <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding
> non-supported transport in m- line of answer
>
>
>
> 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.
>
>
>
> 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 <
> [email-masked]> wrote:
>
> *From: *mmusic <[email-masked]> on behalf of Christer Holmberg <
> [email-masked]>
> *To: *"[email-masked]" <[email-masked]>
> *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 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.
>
>
>
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 3 Feb 2017 15:02:43 -0500

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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
>
>>     specifying an MIT transport, which is used as default candidate
>>     (read: ALT #1).
>>
>>     <mailto:[email-masked]>
>>     *Cc:* [email-masked] <mailto:[email-masked]>
>>     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.
>>
>>     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
>>
>>         <mailto:[email-masked]>> on behalf of Christer
>>         Holmberg <[email-masked]
>>         *To: *"[email-masked] <mailto:[email-masked]>"
>>         <[email-masked] <mailto:[email-masked]>>
>>         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.
>>
>>         <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.
>>
>>         <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
>>
>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>